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. 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;
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.
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.
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.
There's also media features (RFC 2530) over MDN and DSN
(Media-Accept-Features).