On Thu, Jun 30, 2005 at 03:44:04PM -0700, Ned Freed wrote:
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.
If users
write "From:", most likely they made a mistake. Should that really not
cause an error?
If we were specifying this for the first time, yes, absolutely. But we're
not
doing that.
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".
(1) What to do about "incorrect" encoded words, where the "incorrectness"
manifests as them being syntactically invalid according to RFC 2047.
In this case I believe RFC 2047 rules should apply: This is simply
literal text, not encoded words.
Agreed, that is specified clearly.
(2) What to do about "incorrect" encoded words where the encoded payload
doesn't match up with the rules for the specified encoding. From what
I can tell RFC 2047 is silent on this issue. However, RFC 2047 does
suggest that encoded-words that specify an unrecognized encoding might
best be treated as ordinary text. I think it appropriate to suggest, but
not require, this handling for encoded words with busted encoded
content.
What do you mean by ordinary text? Treating them literally or decoding, but
not converting them?
Treating them literally. Hard to decode something you don't understand the
encoding for.
We do case-sensitive matches on require strings, so this is OK as far as
we're
concerned. Hopefully there isn't a popular implementation that has spawned a
corpus of require "ENVELOPE"; scripts out there.
The only feedback I got when I changed it from caseless to caseful was that
a regression test failed that used FILEINTO. That was easily fixed.
I was frankly surprised that I coded it using a case-sensitive comparison and
that nobody has complained about it. Had I thought about it I probably would
have used a case-insensitive comparison.
Sometimes you get lucky, that's all.
Ned