[NNTP] Extension docs snapshots

[Ken Murchison]

Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
>>Clive D.W. Feather wrote:
> 
> 
>>>streaming, section 2.3.1, why is MODE STREAM "MUST NOT be pipelined"? I
>>>understand the reasoning with MODE READER, but I don't understand it
>>>here (of course, the client needs to be careful what it does
>>>immediately afterwards, but if it pipelined a sequence of CHECKs would
>>>it hurt?).
> 
> 
>>Don't know.  Someone more familiar with streaming (Andrew?) needs to
>>chime in here.  I don't recall when this came into the document.  It
>>seems to me that any argument that can be made for MODE READER can be
>>made for MODE STREAM and vice versa.
> 
> 
> You can't make the same argument for MODE STREAM as for MODE READER
> because the thing about MODE READER is that it hands the connection off to
> another binary.  I'm unaware of anyone who implemented streaming that way,
> or of any purpose served in doing so.
> 
> The comment that it can't be pipelined is in there not for any inherent
> protocol reason, but because it doesn't make any sense to do so.  The
> thing you're going to want to do next is issue a CHECK or TAKETHIS
> command, and until MODE STREAM returns, you don't know if you actually can
> or if you need to use IHAVE instead.  It's an extension negotiation
> command, and therefore it doesn't make any sense to queue up use of the
> extension before you're aware that the extension is there.
> 
> It doesn't really matter, but I'd be inclined to leave in the prohibition;
> it's going to quickly become irrelevant since MODE STREAM is only an issue
> when dealing with legacy implementations.

Would it be better if I changed the text to say "SHOULD NOT be pipelined"?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp