From: Usenet News Support (support@prodigy.net)
Date: Tue Jun 03 2003 - 08:23:09 CDT
On Fri, 23 May 2003, Russ Allbery wrote:
> Usenet News Support <support@prodigy.net> writes:
>
> > You did note that I mentioned that some existing software is broken WRT
> > this? I dont regard "INN is broken and needs this" and a good
> > justification for putting a restriction in a standard.
>
> Are people proposing putting a restriction in, or are they proposing
> taking a restriction out?
>
> RFC 1036:
>
> A standard USENET message consists of several header lines, followed
> by a blank line, followed by the body of the message. Each header
> line consist of a keyword, a colon, a blank, and some additional
> information. This is a subset of the Internet standard, simplified
> to allow simpler software to handle it. The "From" line may
> optionally include a full name, in the format above, or use the
> Internet angle bracket syntax. To keep the implementations simple,
> other formats (for example, with part of the machine address after
> the close parenthesis) are not allowed. The Internet convention of
> continuation header lines (beginning with a blank or tab) is
> allowed.
>
> How do you want to read "some additional information"? It sure sounds
> like it requires at least one additional character after the colon-space
> to me, and it looks like a lot of other implementors have also read it
> that way.
>
> I plan on changing INN down the road (it's not an easy change) so that it
> no longer requires this, in the name of maximum compatibility with mail
> and to make mail to news gatewaying easier (since headers with nothing of
> substance on the first header line do occur not infrequently in mail), but
> I maintain that requiring non-whitespace on the first header line is a
> perfectly reasonable interpretation of RFC 1036.
Actually, looking at some code I wrote which read headers, it appears that
in three programs (two reading mail), the continuation lines are read
first, into a maxlen buffer, and then parsed. So continuation is never
even seen by the parser.
Given the other input on this, I would say that a space after the colon
must (or MUST) be present, but after that continuation is allowed. Since
whitespace on the following line will be lost in most implementations, it
seems needed on the first line.
-- bill davidsen SBC/Prodigy Yorktown Heights NY data center Project Leader, USENET news http://newsgroups.news.prodigy.com