[NNTP] Extension docs snapshots

[Clive D.W. Feather]

> Russ Allbery wrote:
> The comment that it can't be pipelined is in there not for any inherent
> protocol reason,

Right there that says to me that a MUST, or even a SHOULD, is the wrong
thing to do.

> 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.

You don't know that the next thing is going to be a CHECK and, even if so,
why does it matter? Suppose the pipeline depth is 3:

    [C] MODE STREAM
    [C] CHECK <msg.id.1 at example.com>
    [C] CHECK <msg.id.2 at example.com>
    [S] 501 What is MODE STREAM?
    [S] 500 What is CHECK?
    [S] 500 What is CHECK?

Where's the problem? Whereas:

    [C] MODE STREAM
    [C] STAT <msg.id.1 at example.com>
    [C] STAT <msg.id.2 at example.com>
    [S] 501 What is MODE STREAM?
    [S] 223 0 <msg.id.1 at example.com>
    [S] 430 No such article <msg.id.2 at example.com>

might be a useful thing to do.

Can we please go back to basic principles on this? The reason for
pipelining restrictions is that some servers hand off certain commands to
other processes and there is then an issue with which process gets which
data from the socket. That justifies the restriction on MODE READER. The
handshaking of things like IHAVE also mean that pipelining can't work.

But unless there is a protocol interoperability (or security) reason for
not pipelining stuff, we should NOT be restricting it. Even if we can't see
why a client might want to pipeline a command, that is not a good reason
for banning it. Pipelining should be the default.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |