I believe the right solution to this, consistent with the intent of
how email header fields work, is to add a sentence (via errata) to RFC
5322 section 2.2 or section 3.6 -- or both -- somewhat like this:
OLD
Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF. A
field name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon.
NEW
Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF. A
field name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. In all cases, field names are interpreted as case-insensitive
strings, so that, for example, "Subject", "SUBJECT", and "SuBjEcT"
are considered to be the same field name.
END
Barry
On Thu, Feb 8, 2018 at 1:23 PM, Dave Crocker <dcrocker(_at_)bbiw(_dot_)net>
wrote:
On 2/8/2018 10:05 AM, Pete Resnick wrote:
RFC 7405 is also useful along these lines.
If those modifications are used, sure. If not, not so much.
So, no error in 5322. As for the erratum below, not having ABNF for the
header field does seem like a miss, though I'm not sure it should be marked
as more than "Hold for document update".
Consider:
1. RFC 5322 specifies ABNF for field names that is in terms of 'allowed'
characters, but has no text constraining the method of defining the specific
characters for specific header-field names.
2. Section 1.2.2 notes that "..." is case insensitive, but that the %... is
inflexible (ie, sensitive.)
3. Nothing in the definition of optional-field requires using the "..."
construct to define the header field name. It merely defines what range of
characteris allowed in a field-name.
fields = *(trace
...
optional-field)
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
4. If a spec defines a field-name using the %... construct, it has
effectively required case sensitivity in processing the field-name.
5. That was most certainly /not/ what was 'intended' for field-name parsing,
going at least back to RFC 733. Violation of 'intent' is the criterion for
an RFC erratum.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html