ietf-dkim
[Top] [All Lists]

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

2018-02-08 13:30:19
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. - +1 (858)651-4478
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html