ietf-nntp Currently outstanding issues
chl at clerew.man.ac.uk
Mon May 5 02:30:35 PDT 2003
In <20030502150107.GC45730 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:
>Russ Allbery said:
>> Section 3.4:
>> | OUTSTANDING ISSUE
I tried to reply to this earlier, but my email muddles, and my change of
email address, caused my reply to disappear at Stan's mail server (a
message came back saying the "moderator" would look at it and approve it,
but the "moderator" does not seem to be reading his email :-( ).
>> | A header may be "folded"; that is, a CRLF pair may be placed before any
>> | TAB or space in the line (including the space after the colon after the
>> | header name), except that there MUST be at least one octet other than
>> | %x09 or %x20 between any two CRLF pairs in a header line.
>> The exception isn't required for NNTP; I think we should drop it from this
>> specification. (The line has to contain some character, but
>> whitespace-only lines don't break anything in the NNTP protocol. If RFC
>> 1036 or USEFOR wants to outlaw them separately, that's great.)
No, I don't think that is right. NNTP has exactly the same problem as 1036
and Usefor here. This recently came up again on the Usefor list, and the
opinion seemed to be that our previous decision was correct.
The concern is headers that are folded in such a way that a line contains
nothing but whitespace (and in News, there is the related case where the
first line of the header contains nothing but the header-name and the
colon plus its SP). Even RFC 2822 outlaws the first of those cases.
The problem is that some non-compliant agent truncates trailing
whitespace, so that line looks like the headers/body separator.
Immediately, the system starts to treat all the headers beyond that point
as part of the body.
And this applies to NNTP as much as to any other part of the mail/news
protocols. NNTP NEEDS to know where the headers/body boundary is. For
example, to implement the HDR and OVER commands correctly, or to make sure
it does not miss a Message-ID (yes, we don't mention that explicitly, but
we all know that is how the "oracle" gets hold of the mesg-id of an
So I prefer to leave the wording as it is.
Note also that Usefor does not permit folding before the SP following the
colon. It might be safer not to permit it in NNTP. We know that some
existing software is fussy about that SP (which is why we still insist on
it). Can we be sure that existing NNTP software would not be similarly
>> Section 8:
>> | OUTSTANDING ISSUE
>> | As worded, this forbids commands like MODE SLAVE that servers already
>> | provide but that aren't part of an existing extension. We can't simply
>> | make these illegal.
>> | The wording about starting keywords with an X could be reduced to a
>> | SHOULD, except for backwards compatibility (with a pointer to RFC
>> | 2980). But is that the right answer?
>> If anyone else has any better ideas, speak up. Otherwise, we should go
>> with SHOULD plus an exception for backward compatibility. (MODE STREAM is
>> the example that you want, I think.)
>I'm still thinking about this. The problem with a SHOULD is that it makes
>it impractical to rely on from a client point of view.
>In trying to solve this, how much can we force servers to change?
Wouldn't is be simpler to say that MODE may be followed by any
word-parameter. The only one defined in our document is READER, but
extensions MAY define additional ones. If it is one the implementation
does not recognize, it SHOULD/MUST ignore it.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-nntp