Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

[Alessandro Vesely <[e-mail]>]

On Thu 08/Feb/2018 19:23:09 +0100 Dave Crocker 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
>                                           ;  ":".

The above section is referenced by RFC 3868, which in turn is referenced by the
IANA registry.  So, a case sensitive header field name is technically possible.

> 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.

Isn't that the difference between technical and editorial errors?  Since the
intent is clear, I reported the error as editorial.

The question arose because someone had DKIM-Signature changed to Dkim-Signature
by some (presumably DKIM-unaware) tool.  The user thought the culprit was my
signing filter, and reported a bug.  I told him to look somewhere else.  I
wanted to add that that change can be acceptable if canonicalization is
relaxed, but I was unable to point him to a line that explicitly stated or
implied case insensitivity.  I'd have to explain the intent maieutically,
which, in a standard, seems to leave something to be desired...

Ale
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html