ietf-dkim
[Top] [All Lists]

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

2018-02-08 13:30:29
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