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