From: Bruce Lilly (blilly@erols.com)
Date: Sat Jul 03 2004 - 16:46:05 CDT
Russ Allbery wrote:
> I don't know if anything strange happened with tab conversions there, but
> if that was meant to be a sequence of spaces
Nope; it was a series of spaces.
>>>Tab and space are defined explicitly in the draft, yes.
>
>
>>The question was about charset, not "Tab and space". FYI there exist
>>charsets where the space character (N.B. not capitalized) does not have
>>hex value 0x20.
>
>
> Yes, and as I said, tab and space are defined explicitly in the draft.
> Perhaps you didn't understand that explicitly meant that they were defined
> in ABNF with reference to what octets they are. It's made quite explicit
> in the draft that space means 0x20.
The typical way to define the space character in ABNF would be to refer
to RFC 2234 and to use "SP", which is provided for the purpose, rather
than "space".
>>Exactly what is inaccurate; RFC 822 has no limit on the length of a
>>message-id. RFCs 850 and 1036 adopted RFC 822 syntax, with some
>>restrictions on characters, but none on length. Along comes NNTP, after
>>822 and 850 -- clearly no limit on the length of a message-id in either
>>-- and in a spectacular example of poor design imposes a command line
>>length limit *and* requires message-ids to be part of certain command
>>lines (rather than data following the command line).
>
>
> Why do you think the limit came from NNTP originally? Did you see Henry's
> message about the length limits in dbz?
I didn't say it was solely an NNTP issue, and yes the dbz limit is the
one that conflicts with the limit on domain names, but the NNTP limit
is a case of poor design that shouldn't have happened given the lack
of any limit in RFCs 822 and 850.
>>I see no such *requirement* in RFC 1036. I see a description of a
>>typical case.
>
>
> Then your bias is affecting your reading and you should try reading again
> without preconceptions or preferences about what you want to read.
>
> 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.
>
> It would be hard to be more explicit without using RFC 2119 language,
> which had not become common yet. (Other than, as mentioned, explicitly
> defining blank.)
It wouldn't be hard at all; insertion of the word "mandatory" or
"required" in the appropriate place would have been clear. And while
I can understand that reducing the variety of representations of
addresses (including full names), excluding comments in some places,
etc. permit simpler parsing, I don't see how that would result from
a mandatory space after the colon (indeed interpretation of that as a
requirement seems to have resulted in greater complexity than would
otherwise be required in some code that I've been looking at lately ;-).
Failing explicit indication of a requirement, interpretation *as* a
requirement requires at least as much "bias" as not doing so. Recently,
clarification of RFC 1036 was possible by examining B news 2.11 source
code. If there is in fact some sort of requirement, I would expect to
see some code there enforcing it. I looked, but could find none.
Perhaps you see something in that source code that I missed; if so point
me to it.