> 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.
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.