[NNTP] STREAMING diffs (take 2)
Jeffrey M. Vinocur
jeff at litech.org
Mon Jun 13 16:29:02 PDT 2005
On Jun 13, 2005, at 7:03 PM, Ken Murchison wrote:
> Jeffrey M. Vinocur wrote:
>
>> I agree with Russ. The concept of "locking" is inherent in the
>> protocol; what is the purpose of the 431 response otherwise?
>
> I don't see how anyone reading our document for the first time would
> necessarily think that locking is inherent in the protocol.
That's potentially a flaw in the document, then, rather than the
protocol.
> In fact, if we said that the server SHOULD/MUST do some kind of
> locking, we'd definitely be getting too involved in implementation
> details and I'd object.
For the record, I wouldn't suggest saying anything stronger than MAY.
> The 431 response could mean any number of things. It could mean that
> the database which keeps track of message-ids, is temporarily offline,
> or it has too many outdtanding transactions, or too many concurrent
> connections, etc. I don't see where its "only" meaning is that "we've
> already seen this message-id via IHAVE/CHECK, but haven't received the
> article yet".
Sure, these are ways that you -could- use 431, now that it exists. But
the one and only reason[*] that 431 was created in the first place was
to provide for this locking, because real-world use of CHECK / TAKETHIS
is fatally flawed without it.
[*] not that I was there at the time, but as far as I understand it
> That being said, as evidenced by my alternate suggested text, I'm
> convinced that saying something in the security considerations is
> worthwhile as long as we don't make it too implementation specific.
Maybe we need to hear from some implementors here, about what things
are universal?
--
Jeffrey M. Vinocur
jeff at litech.org
More information about the ietf-nntp
mailing list