Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> writes:
Michael Haardt wrote:
Ok, if the specification is to be understood that way, then how about:
Synactically invalid header names cause the same result as syntactically
valid header names that are not present in the message. In particular,
an implementation MUST not cause an error for synactically invalid
header names.
Very nice. I support adding this text to the document. One change:
"MUST not" -> "MUST NOT".
Works for me. 2.4.2.2 now reads:
Headers are a subset of strings. In the Internet Message
Specification [IMAIL], each header line is allowed to have whitespace
nearly anywhere in the line, including after the field name and
before the subsequent colon. Extra spaces between the header name
and the ":" in a header field are ignored.
A header name never contains a colon. The "From" header refers to a
line beginning "From:" (or "From :", etc.). No header will match
the string "From:" due to the trailing colon.
Similarly, synactically invalid header names cause the same result as
syntactically valid header names that are not present in the message.
In particular, an implementation MUST NOT cause an error for
synactically invalid header names.
Folding of long header lines (as described in [IMAIL] 2.2.3) is
removed prior to interpretation of the data. The folding syntax (the
CRLF that ends a line plus any leading whitespace at the beginning of
the next line that indicates folding) are interpreted as if they were
a single space.
<pause>
Hmmm, that last paragraph actually differs from RFC 2822, section 2.2.3,
which says:
Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.
I.e., the leading whitespace should *not* be treated as a single space
but rather be left as is. Unless I hear screams, I'm going to remove
the sentence that starts "The folding syntax..." as conflicting.
Nice catch. No screams from this quarter - this should align with RFC 2822 IMO.
Ned