ietf-nntp HTML->TXT translation of voting document for the HTML impared

[sob at academ.com]

All votes here are relative to draft-ietf-nntp-base-14.txt. If you have not 
read this document, please don't participate in this vote. You will have 
opportunities to participate in the next one.

 

1. Please write your email address here:____________________________

 

Do you want to be added to the WG mailing list?  YES NO (circle one) 

 

2. Streaming in the base NNTP specification. Clive Feather has suggested that 
the following text be added as part of the base spec. He has suggested that it 
go in section 4. 

 
4.X Streaming
 
NNTP is designed to operate over a reliable bi-directional connection such as 
TCP. Therefore, if a command does not depend on the response to the previous 
one, it should not matter if it is sent before that response is received. Doing 
this is called "streaming". However, certain server implementations throw away 
all text received from the client following certain commands before sending 
their response. If this happens, streaming will be affected because one or more 
commands will have been ignored or misinterpreted, and the client will be 
matching the wrong responses to each command.
 
Since there are significant benefits to streaming, but also circumstances where 
it is reasonable or common for servers to behave in the above manner, this 
document puts certain requirements on both clients and servers.
 
Except where stated otherwise, a client MAY use streaming. That is, it may send 
a command before receiving the response for the previous command. The server 
MUST allow streaming and MUST NOT throw away any text received after a command.
 
If the specific description of a command describes it as "not streamable", that 
command MUST end any stream of commands. That is, the client MUST NOT send any 
following command until receiving the CRLF at the end of the response from the 
command. The server MAY ignore any data received after the command and before 
the CRLF at the end of the response is sent to the client.
 
The initial connection must not be part of a stream; that is, the client MUST 
NOT send any command until receiving the CRLF at the end of the greeting.
 
If the client uses blocking system calls to send commands, it MUST ensure that 
the amount of text sent in streaming does not cause a deadlock between 
transmission and reception. The amount of text involved will depend on window 
sizes in the transmission layer, and is typically 4k bytes for TCP.
 
 
AGREE             DISAGREE
 
3. Streaming part 2. If there is agreement on adding the steaming above, then 
some command descriptions should be modified to indicate that they are “not 
streamable.” For each of the following indicate if you agree or disagree if 
they should be “not streamable”.
 
LIST EXTENSIONS      AGREE                               DISAGREE
QUIT                 AGREE                               DISAGREE
MODE READER          AGREE                               DISAGREE
POST                 AGREE                               DISAGREE