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 |