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

Lee Kindness lkindness at csl.co.uk
Wed Dec 12 01:35:28 PST 2001


I'm not 'html impared' I just don't like getting malformed MIME
messages with machine generated HTML which is mostly unrequired
padding. I can handle, but don't like, valid MIME messages containing
HTML. Nevertheless...

Vote follows:

sob at academ.com writes:
 > 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:____________________________

As header, lkindness at csl.co.uk

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

N/A

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

AGREE

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

AGREE (not streamable)

 > QUIT                 AGREE                               DISAGREE


DISAGREE (streamable) - but I can't see the point, you just drop
the connection after...

 > MODE READER          AGREE                               DISAGREE

DISAGREE (streamable

 > POST                 AGREE                               DISAGREE

AGREE (not streamable)

Regards, Lee Kindness.



More information about the ietf-nntp mailing list