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 <dcroc...@bbiw.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
