ietf-nntp Pipelining

[Stan O. Barber]

"Clive D.W. Feather" wrote:
> 
> Definition:
> 
> A pipelining server is one that will correctly handle the situation when
> a client sends a command before the server has sent its response to the
> previous command.
> 
> Discussion:
> 
> Pipelining is, in general, a good thing because it eliminates the turnround
> time between commands. Many NNTP clients already assume that pipelining
> works. For example, they will issue a bunch of ARTICLE commands before
> looking for the response to the first one, then issue another ARTICLE every
> time a response is received.
> 
> In most situations, a server written in the obvious manner will be fully
> pipelining, since the TCP input buffer will hold the next command until
> the server is ready for it. However, RFC 1854 indicates that there are two
> major problems with SMTP servers:
> 
> (1) Some servers flush the TCP input buffer when an error occurs.
> 
> (2) When a server does an internal process handoff, the TCP input buffer
> may be emptied as a side effect.
> 
> I suspect that both of these are much less of a problem with NNTP because
> of the wide deployment of pipelining clients. So I suggest that pipelining
> should not be an extension but rather defined as part of the core protocol
> since it represents current practice.
> 
> When the topic was discussed before, nobody was able to list a server that
> got this wrong.
> 

I remain concerned about this type of change given the charter of clarifying
RFC977. 

Does this clarify RFC977 or does it actually change the protocol specified in
RFC977?

If the former, great. Let's do it. If the later, then it should not be done
unless we explicitly say in the document that this is a change relative to the
original document and there is considerable consensus to make it so. Based on
the past discussions, there is not considerable consensus to make it so,
however, I am quite open to reevaluating the consensus.