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
registry.
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.
The
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
include:
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
registry.
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,
Exactly.
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.
Ned