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

On Wed May 25 2005 18:32, [email protected] 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).