[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