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

[Pete Resnick <[e-mail]>]

On 8 Feb 2018, at 10:23, Dave Crocker wrote:

> On 2/8/2018 10:05 AM, Pete Resnick wrote:
>
>> 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
>                                           ;  ":".

Ah! I completely misunderstood: When you said, "RFC 5322 ... does not 
enforce case insensitity in the syntax", you were referring to 
optional-field. 5322 of course does enforce case-insensitivity in all of 
the other field names. My apologies.

That said, let's remember that, for better or worse (and in my 
aforementioned advancing age, I lean more toward worse every year), 5322 
does not have a multi-stage parser in the way that 733 or 822 did. So 
when you say:

> 4. If a spec defines a field-name using the %... construct, it has 
> effectively required case sensitivity in processing the field-name.

Well, sort of. I believe the expectation was that when syntactically 
processing a message, a field name would only match the field-name in 
optional-field if it failed to match any other defined field that the 
implementation understood, and therefore the semantic processing of the 
field would follow the instruction in 3.6.8:

    For the purposes of this specification, any optional field is
    uninterpreted.

The optional-field construct wasn't intended to define the syntactic 
processing of fields defined in other documents. I think it was assumed 
that other documents would syntactically extend 5322's syntax with new 
field names and implementations would update their parsers to include 
the new field names and therefore never process any recognized field 
name in a case-sensitive manner. That is, I believe the intent was to 
process any *recognized* field name in a case-insensitive manner.

> 5. That was most certainly /not/ what was 'intended' for field-name 
> parsing, going at least back to RFC 733.

Given the difference in how messages are parsed between 733 and 5322, I 
think their respective intents are still being honored. However, I now 
do see your point.

> Violation of 'intent' is the criterion for an RFC erratum.

Of that there's no doubt.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html