[Top] [All Lists]

Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt

2005-05-25 21:55:00

On Wed May 25 2005 18:32, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
In any case, I agree that these are not
header fields and hence do not belong in the regular header field

Discussion with Graham back when the registry documents were still
in draft form seemed to indicate that it would be reasonable.

That may have been true at the time, but the IESG pushed back hard on having a
single general-purpose registry for all field names. What we ended up with
instead is a more specific registry for header fields in specific protocols.
There's no requirement that new protocols use the registry either.

use could be indicated via the registration form "applicable protocol"
field.  The benefits would be as listed in RFC 3864:

   Benefits of a central registry for message header field names

   o  providing a single point of reference for standardized and
      widely-used header field names;

   o  providing a central point of discovery for established header
      fields, and easy location of their defining documents;

   o  discouraging multiple definitions of a header field name for
      different purposes;

These benefits arise from having a registy, not from having a common

   o  helping those proposing new header fields discern established
      trends and conventions, and avoid names that might be confused
      with existing ones;

   o  encouraging convergence of header field name usage across multiple
      applications and protocols.

These benefits are to some extent linked to having a single registry. The
question, then, is whether these are real benefits for the fields at hand.
I don't think they are.

Technically, of course, these aren't header fields,


but sometimes fields
don't stay put (MTAs insert empty lines, moving message fields into the
body, for example).  And they do use the same syntax.

The behavior of egregiously broken software is hardly relevant.

And note that some fields used in types similar to the one proposed in
the draft under discussion are also used in message header fields (e.g.
Original-Message-ID).  Benefits "discouraging multiple definitions
for different purposes", "...discern established trends...", "encouraging
convergence..." all are applicable.  The draft under discussion re.
"User-Agent" is an example.

With three related types already (DSN, MDN, MTSN), and some already
existing common use (e.g. Original-Recipient, Final-Recipient), the
benefits enumerated in 3864 seem clear.

Not when there's an existing registry, they don't.