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