Skip to main content

Registration Procedures for Message Header Fields
draft-klyne-msghdr-registry-07

Revision differences

Document history

Date Rev. By Action
2004-02-17
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-02-17
07 Amy Vezza IESG state changed to Approved-announcement sent
2004-02-17
07 Amy Vezza IESG has approved the document
2004-02-17
07 (System) Ballot writeup text was added
2004-02-17
07 (System) Last call text was added
2004-02-17
07 (System) Ballot approval text was added
2004-02-17
07 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2004-02-16
07 Ned Freed [Note]: 'Discuss response now sent to relevant ADs; now waiting
for them to follow up.' has been cleared by Ned Freed
2004-02-06
07 (System) Removed from agenda for telechat - 2004-02-05
2004-02-05
07 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Amy Vezza
2004-01-26
07 Ned Freed Placed on agenda for telechat - 2004-02-05 by Ned Freed
2004-01-26
07 Ned Freed
Discuss response sent 2-Jan-2004:

Time to get back to work on this... Allison, Jon, you have the two discusses on
this specification. In response to …
Discuss response sent 2-Jan-2004:

Time to get back to work on this... Allison, Jon, you have the two discusses on
this specification. In response to your comments:

  This document conflicts with RFC 3427, the SIP Change BCP, because it
  seems to open up the provisional registry for new SIP headers,
  based on internet-drafts or other sources, whereas under the
  BCP they may not be registered without an RFC publication. This is
  because SIP headers can strongly affect even the security
  characteristics of the call, as well as interoperability. State the
  registry policies as applying to any given protocol with message headers
  ONLY if it does not have applicable IANA registry policies already in place.

This has been done in the revised version; it now states that this document
does not replace other protocol-specific registries such as the one for SIP.

  There is evidently a benefit to establishing a single registry for http,
  mime and mail headers, and establishing these IANA considerations for them,
  however the IANA considerations are very open. Should MIME headers be thrown
  so widely open? Anyone can write an i-d and add a new arbitrary one to the
  provisional registry. This is looser than the current situation and perhaps
  not a good development for MIME. (I'm not saying that mail and http need
  this kind of care anymore).

First, although it is a "single" registry, the specific places a given field is
used is noted in the registration entries.

Second, as far as the added potential for abuse of MIME goes, if anything this
proposal will decrease abuse, not increase it. Right now there is no registry
so people who come up with some new field simply do so and deploy it. When
others encounter the field they have to guess at its meaning, with a
nonnegligable chance of getting it wrong. (If you want a good example of the
consequences of getting it wrong, consider X-X-Sender. Eudora decided to use
X-Sender rather than Sender: because too many agents interpreted Sender: as an
address. But without a specification for X-Sender: agents started treating its
content as an address as well, forcing Eudora to switch to using X-X-Sender. By
now they may have moved to X-X-X-Sender...)

A registry offers us the ability to try and get a handle on this mess. But to
the extent the registry is hard to use people will simply not use it. We had
exactly this problem with MIME media types - the original registration
procedures were seen by most as being too dificult, with the result that people
simply went ahead and made up their own content types rather than registering
them. Not only did this lead to a large number of unregistered types being
enshrined in implementations, it also created a pattern of behavior where many
people don't bother to register the types they use - a pattern that continues
to this day.

Now, you can argue that a registry being defined as late in the game as this
one is has little chance of being adopted anyway. But if anything this makes it
even more imperative that we avoid overly difficult  procedures. We have, at
the very best, one shot at this.

The document clearly states that entries in the provisional registry are not
endorsed by the IETF in any way. We can make sure this point is reiterated in
the registry itself, which should make it difficult for people to miss seeing
it. And to the extent that they do miss it and believe a provisional entry is
somehow blessed, well, I'd rather take this small risk than compromise the
ability to capture information about the fields that are in use and let the
community provide feedback about them, which is exactly what a stricter policy
will do.

One final note. I try and track the fields I see in use in email, and my list
currently has no fewer than 537 entries on it. (I'm sure that others who are
more diligent than I have even longer lists.) Only a fraction of any of these
fields have publicly available specifications. Of those some 30 appear to be
MIME-related fields. This is a truly wretched state of affairs.

  I should think the msghdr registry could be conceived as both the
  registry described here, and in another way, as a cross-registry from
  the individual protocols' registries. Could this be so instructed to the
  IANA to allow users still to have per-protocol resources?

I guess a cross-registry would have been one way to do it, but it isn't the
course that was chosen. I would also worry that a complicated cross-registry
scheme is exactly the sort of thing IANA has difficulty operating. (Indeed, I
worry about the present scheme being confusing to IANA, but I see no good way
of simplifying it further without loosing semantics I regard as essential.)
As for per-protocol resources, hopefully the document now makes it
clear that this is no replacement for other registries set up for
other protocols.

  The largest issue I have with this document is I'm unsure what degree of
  compliance is anticipated. Is this document a mandate that all existing
  protocols must register their headers in the Permanent Message Field
  Registry? Or only all specifications published from this point forward? What
  about protocols that already have existing IANA registries for headers - are
  they expected/required to publish twice, or to deprecate their existing
  registries?

If memory serves, this issue was discussed a bit, and the conclusion was that
it is up to the defining protocol specifications to specify whether or not use
of this registry is mandatory. (More specifically, I believe there was
considerable resistance to having a registry specification that imposes
mandates on other protocol specifications after the fact.) As luck would have
it discussion has just started on 2822bis; one of the things I'd like to see
added to 2822bis is a pointer to the registry and a discussion of whether or
not its use is mandatory. Similarly, I plan to add similar words to the next
revision of the MIME specification, and I'd hope we can do the same for HTTP as
well now that a revision to that specification is out as  a draft.

  The document says that IANA should pre-provision the Permanent Message Field
  Registry with values from draft-klyne-hdrreg-mail and
  draft-nottingham-hdrreg-http. Both are expired since 2002 (though the
  latter, at least, is still in the I-D repository). I suppose these should
  have gone forward with this document as a bundle? I also wonder, though,
  that given the extensive list of RFCs in section 2.2, examples from mail and
  http alone would have been investigated here.

Agreed, it would have been better for these to go forward as a group, but
that's just not how it played out. Hopefully once this specification is
approved we can get the base registration documents done in fairly short order.

  I think this document is a bit dated. For one thing, the listings of RFCs in
  2.2 only go up to around RFC3000; consequently, it lists some obsolete
  specifications (like RFC2543 instead of RFC3261) and probably omits some
  newer specifications that should fall under its yoke.

This and various other references have now been updated.

  The IANA procedures for SIP header registrations purposefully preclude
  registration of experimental headers (this was at the request of iesg). That
  seems at odds with the provisional mechanism in this draft. I don't know how
  to reconcile these two views.

I don't know the rationale the IESG had for prohibiting experimental
registrations for SIP, but I can guess: They wanted to avoid creating the sort
of mess we now have in email and to a lesser extent in HTTP. If we were just
starting out on email or HTTP a strict policy  might make sense (although the
MIME experience with content-types makes me doubt it), but we're coming to this
literally two decades late and this in turn argues for a very different
approach. So think of it as a matter of timing.

Anyway, please examine the revised specification and the above response
and see whether or not it addresses your concerns.

                                Ned

P.S. Ted, I hopefully have addressed your two nits through an RFC Editor
note.
2004-01-02
07 Ned Freed State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Ned Freed
2004-01-02
07 Ned Freed [Note]: 'Discuss response now sent to relevant ADs; now waiting
for them to follow up.' added by Ned Freed
2003-11-02
07 Ned Freed [Note]: 'Revision posted; AD followup needed' added by Ned Freed
2003-11-02
07 Ned Freed State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Ned Freed
2003-10-28
07 (System) New version available: draft-klyne-msghdr-registry-07.txt
2003-10-14
07 Ned Freed Updated note and corrected author address
2003-10-14
07 Ned Freed State Change Notice email list have been change to , , from , ,
2003-10-14
07 Ned Freed [Note]: 'Waiting for author revision' added by Ned Freed
2003-10-14
07 Michael Lee State Change Notice email list have been change to , , from , ,
2003-10-02
07 Ned Freed State Change Notice email list have been change to , , from , ,
2003-10-02
07 Ned Freed State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead::Point Raised - writeup needed by Ned Freed
2003-06-13
07 Jacqueline Hargest State Changes to Waiting for AD Go-Ahead  :: Point Raised - writeup needed from IESG Evaluation - Defer by Hargest, Jacqueline
2003-06-04
07 Michael Lee State Changes to IESG Evaluation - Defer from IESG Evaluation by Lee, Michael
2003-05-23
07 Ned Freed
The IESG has approved the Internet-Draft 'Registration procedures for
message header fields'  as a BCP.
This has been reviewed in the IETF but is not …
The IESG has approved the Internet-Draft 'Registration procedures for
message header fields'  as a BCP.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.  The IESG contact persons are Ned Freed and Ted Hardie.

Technical Summary

This specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications.

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.

Working Group Summary

This has been reviewed in the IETF but is not the product of an IETF
Working Group.

Protocol Quality

Ned Freed reviewed the document for the iESG.

RFC Editor note

The IPR boilerplate is missing from this document and needs to be added.
2003-05-23
07 Dinara Suleymanova State Changes to IESG Evaluation from Waiting for Writeup by Suleymanova, Dinara
2003-01-20
06 (System) New version available: draft-klyne-msghdr-registry-06.txt
2002-12-05
07 Stephen Coya State Changes to Waiting for Writeup from In Last Call by Coya, Steve
2002-11-04
07 Jacqueline Hargest Due date has been changed to 2002-12-4 from 
by Hargest, Jacqueline
2002-11-04
07 Jacqueline Hargest State Changes to In Last Call from AD Evaluation by Hargest, Jacqueline
2002-11-04
07 (System) Last call sent
2002-06-12
07 Ned Freed Intended Status has been changed to BCP from None
2002-06-12
07 Ned Freed Asked for RFC publication
2002-06-12
07 Ned Freed Draft Added by freed
2002-06-10
05 (System) New version available: draft-klyne-msghdr-registry-05.txt
2002-03-27
04 (System) New version available: draft-klyne-msghdr-registry-04.txt
2002-02-20
03 (System) New version available: draft-klyne-msghdr-registry-03.txt
2002-01-29
02 (System) New version available: draft-klyne-msghdr-registry-02.txt
2002-01-10
01 (System) New version available: draft-klyne-msghdr-registry-01.txt
2001-09-27
00 (System) New version available: draft-klyne-msghdr-registry-00.txt