[NNTP] Extension docs snapshots

Russ Allbery rra at stanford.edu
Tue Nov 30 20:01:18 PST 2004


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.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list