diff options
Diffstat (limited to 'doc/rfc/rfc3864.txt')
| -rw-r--r-- | doc/rfc/rfc3864.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3864.txt b/doc/rfc/rfc3864.txt new file mode 100644 index 0000000..661503a --- /dev/null +++ b/doc/rfc/rfc3864.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group G. Klyne +Request for Comments: 3864 Nine by Nine +BCP: 90 M. Nottingham +Category: Best Current Practice BEA + J. Mogul + HP Labs + September 2004 + + + Registration Procedures for Message Header Fields + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This specification defines registration procedures for the message + header fields used by Internet mail, HTTP, Netnews and other + applications. + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et al. Best Current Practice [Page 1] + +RFC 3864 Header Field Registration September 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Structure of this Document . . . . . . . . . . . . . . . 3 + 1.2. Document Terminology and Conventions . . . . . . . . . . 4 + 2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Permanent and Provisional Header Fields. . . . . . . . . 4 + 2.2. Definitions of Message Header Fields . . . . . . . . . . 5 + 2.2.1. Application-specific Message Header Fields. . . . 5 + 2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6 + 3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6 + 4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Header Field Specification . . . . . . . . . . . . . . . 7 + 4.2. Registration Templates . . . . . . . . . . . . . . . . . 7 + 4.2.1. Permanent Message Header Field Registration + Template. . . . . . . . . . . . . . . . . . . . . 7 + 4.2.2. Provisional Message Header Field Submission + Template. . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Submission of Registration . . . . . . . . . . . . . . . 10 + 4.4. Objections to Registration . . . . . . . . . . . . . . . 10 + 4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11 + 4.6. Comments on Header Definitions . . . . . . . . . . . . . 12 + 4.7. Location of Header Field Registry. . . . . . . . . . . . 12 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 8.2. Informative References . . . . . . . . . . . . . . . . . 13 + 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 + 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 + +1. Introduction + + This specification defines registration procedures for the message + header field names used by Internet mail, HTTP, newsgroup feeds and + other Internet applications. It is not intended to be a replacement + for protocol-specific registries, such as the SIP registry [30]. + + 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; + + + + +Klyne, et al. Best Current Practice [Page 2] + +RFC 3864 Header Field Registration September 2004 + + + 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. + + The primary specification for Internet message header fields in email + is the Internet mail message format specification, RFC 2822 [4]. + HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields + (respectively, the HTTP-header and message-header protocol elements) + for use with HTTP. RFC 1036 [5] defines message header elements for + use with Netnews feeds. These specifications also define a number of + header fields, and provide for extension through the use of new + field-names. + + There are many other Internet standards track documents that define + additional header fields for use within the same namespaces, notably + MIME [11] and related specifications. Other Internet applications + that use MIME, such as SIP (RFC 3261 [30]) may also use many of the + same header fields (but note that IANA maintains a separate registry + of header fields used with SIP). + + Although in principle each application defines its own set of valid + header fields, exchange of messages between applications (e.g., mail + to Netnews gateways), common use of MIME encapsulation, and the + possibility of common processing for various message types (e.g., a + common message archive and retrieval facility) makes it desirable to + have a common point of reference for standardized and proposed header + fields. Listing header fields together reduces the chance of an + accidental collision, and helps implementers find relevant + information. The message header field registries defined here serve + that purpose. + +1.1. Structure of this Document + + Section 2 discusses the purpose of this specification, and indicates + some sources of information about defined message header fields. + + Section 4 defines the message header field name repositories, and + sets out requirements and procedures for creating entries in them. + + + + + + + +Klyne, et al. Best Current Practice [Page 3] + +RFC 3864 Header Field Registration September 2004 + + +1.2. Document Terminology and Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [2]. + +2. Message Header Fields + +2.1. Permanent and Provisional Header Fields + + Many message header fields are defined in standards-track documents, + which means they have been subjected to a process of community review + and achieved consensus that they provide a useful and well-founded + capability, or represent a widespread use of which developers should + be aware. Some are defined for experimental use, typically + indicating consensus regarding their purpose but not necessarily + concerning their technical details. Many others have been defined + and adopted ad-hoc to address a locally occurring requirement; some + of these have found widespread use. + + The catalogues defined here are intended to cater for all of these + header fields, while maintaining a clear distinction and status for + those which have community consensus. To this end, two repositories + are defined: + + o A Permanent Message Header Field Registry, intended for headers + defined in IETF standards-track documents, those that have + achieved a comparable level of community review, or are generally + recognized to be in widespread use. The assignment policy for + such registration is "Specification Required", as defined by RFC + 2434 [3], where the specification must be published in an RFC + (standards-track, experimental, informational or historic), or as + an "Open Standard" in the sense of RFC 2026, section 7 [1]. + + o A Provisional Message Header Field Repository, intended for any + header field proposed by any developer, without making any claim + about its usefulness or the quality of its definition. The policy + for recording these is "Private Use", per RFC 2434 [3]. + + Neither repository tracks the syntax, semantics or type of field- + values. Only the field-names, applicable protocols and status are + registered; all other details are specified in the defining documents + referenced by repository entries. Significant updates to such + references (e.g., the replacement of a Proposed Standard RFC by a + Draft Standard RFC, but not necessarily the revision of an Internet- + draft) SHOULD be accompanied by updates to the corresponding + repository entries. + + + + +Klyne, et al. Best Current Practice [Page 4] + +RFC 3864 Header Field Registration September 2004 + + +2.2. Definitions of Message Header Fields + + RFC 2822 [4] defines a general syntax for message headers, and also + defines a number of fields for use with Internet mail. HTTP/1.0 [10] + and HTTP/1.1 [24] do likewise for HTTP. Additional field names are + defined in a variety of standards-track RFC documents, including: RFC + 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14], + RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557 [23], RFC 2227 + [16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC 2421 [21], RFC + 2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912 [27], RFC 2919 + [28], RFC 2965 [29], and RFC 3282 [31]. + +2.2.1. Application-specific Message Header Fields + + Internet applications that use similar message headers include + Internet mail [26] [4], NNTP newsgroup feeds [5], HTTP web access + [24] and any other that uses MIME [11] encapsulation of message + content. + + In some cases (notably HTTP [24]), the header syntax and usage is + redefined for the specific application. This registration is + concerned only with the allocation and specification of field names, + and not with the details of header implementation in specific + protocols. + + In some cases, the same field name may be specified differently (by + different documents) for use with different application protocols; + e.g., The Date: header field used with HTTP has a different syntax + than the Date: used with Internet mail. In other cases, a field name + may have a common specification across multiple protocols (ignoring + protocol-specific lexical and character set conventions); e.g., this + is generally the case for MIME header fields with names of the form + 'Content-*'. + + Thus, we need to accommodate application-specific fields, while + wishing to recognize and promote (where appropriate) commonality of + other fields across multiple applications. Common repositories are + used for all applications, and each registered header field specifies + the application protocol for which the corresponding definition + applies. A given field name may have multiple registry entries for + different protocols; in the Permanent Message Header Field registry, + a given header field name may be registered only once for any given + protocol. (In some cases, the registration may reference several + defining documents.) + + + + + + + +Klyne, et al. Best Current Practice [Page 5] + +RFC 3864 Header Field Registration September 2004 + + +2.2.2. MIME Header Fields + + Some header fields with names of the form Content-* are associated + with the MIME data object encapsulation and labelling framework. + These header fields can meaningfully be applied to a data object + separately from the protocol used to carry it. + + MIME is used with email messages and other protocols that specify a + MIME-based data object format. MIME header fields used with such + protocols are defined in the registry with the protocol "mime", and + as such are presumed to be usable in conjunction with any protocol + that conveys MIME objects. + + Other protocols do not convey MIME objects, but define a number of + header fields with similar names and functions to MIME. Notably, + HTTP defines a number of entity header fields that serve a purpose in + HTTP similar to MIME header fields in email. Some of these header + fields have the same names and similar functions to their MIME + counterparts (though there are some variations). Such header fields + must be registered separately for any non-MIME-carrying protocol with + which they may be used. + + It is poor practice to reuse a header field name from another + protocol simply because the fields have similar (even "very similar") + meanings. Protocols should share header field names only when their + meanings are identical in all foreseeable circumstances. In + particular, new header field names of the form Content-* should not + be defined for non-MIME-carrying protocols unless their specification + is exactly the same as in MIME. + +3. Registry Usage Requirements + + RFCs defining new header fields for Internet mail, HTTP, or MIME MUST + include appropriate header registration template(s) (as given in + Section 4.2) for all headers defined in the document in their IANA + considerations section. Use of the header registry MAY be mandated + by other protocol specifications, however, in the absence of such a + mandate use of the registry is not required. + +4. Registration Procedure + + The procedure for registering a message header field is: + + 1. Construct a header field specification + + 2. Prepare a registration template + + 3. Submit the registration template + + + +Klyne, et al. Best Current Practice [Page 6] + +RFC 3864 Header Field Registration September 2004 + + +4.1. Header Field Specification + + Registration of a new message header field starts with construction + of a proposal that describes the syntax, semantics and intended use + of the field. For entries in the Permanent Message Header Field + Registry, this proposal MUST be published as an RFC, or as an Open + Standard in the sense described by RFC 2026, section 7 [1]. + + A registered field name SHOULD conform at least to the syntax defined + by RFC 2822 [4], section 3.6.8. + + Further, the "." character is reserved to indicate a naming sub- + structure and MUST NOT be included in any registered field name. + Currently, no specific sub-structure is defined; if used, any such + structure MUST be defined by a standards track RFC document. + + Header field names may sometimes be used in URIs, URNs and/or XML. + To comply with the syntactic constraints of these forms, it is + recommended that characters in a registered field name are restricted + to those that can be used without escaping in a URI [20] or URN [13], + and that are also legal in XML [32] element names. + + Thus, for maximum flexibility, header field names SHOULD further be + restricted to just letters, digits, hyphen ('-') and underscore ('_') + characters, with the first character being a letter or underscore. + +4.2. Registration Templates + + The registration template for a message header field may be contained + in the defining document, or prepared separately. + +4.2.1. Permanent Message Header Field Registration Template + + A header registered in the Permanent Message Header Field Registry + MUST be published as an RFC or as an "Open Standard" in the sense + described by RFC 2026, section 7 [1], and MUST have a name which is + unique among all the registered permanent field names that may be + used with the same application protocol. + + The registration template has the following form. + + PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: + + Header field name: + The name requested for the new header field. This MUST conform to + the header field specification details noted in Section 4.1. + + + + + +Klyne, et al. Best Current Practice [Page 7] + +RFC 3864 Header Field Registration September 2004 + + + Applicable protocol: + Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), + "netnews" (RFC 1036), or cite any other standards-track RFC + defining the protocol with which the header is intended to be + used. + + Status: + Specify "standard", "experimental", "informational", "historic", + "obsoleted", or some other appropriate value according to the type + and status of the primary document in which it is defined. For + non-IETF specifications, those formally approved by other + standards bodies should be labelled as "standard"; others may be + "informational" or "deprecated" depending on the reason for + registration. + + Author/Change controller: + For Internet standards-track, state "IETF". For other open + standards, give the name of the publishing body (e.g., ANSI, ISO, + ITU, W3C, etc.). For other specifications, give the name, email + address, and organization name of the primary specification + author. A postal address, home page URI, telephone and fax + numbers may also be included. + + Specification document(s): + Reference to document that specifies the header for use with the + indicated protocol, preferably including a URI that can be used to + retrieve a copy of the document. An indication of the relevant + sections MAY also be included, but is not required. + + Related information: + Optionally, citations to additional documents containing further + relevant information. (This part of the registry may also be used + for IESG comments.) Where a primary specification refers to + another document for substantial technical detail, the referenced + document is usefully mentioned here. + +4.2.2. Provisional Message Header Field Submission Template + + Registration as a Provisional Message Header Field does not imply any + kind of endorsement by the IETF, IANA or any other body. + + The main requirements for a header field to be included in the + provisional repository are that it MUST have a citable specification, + and there MUST NOT be a corresponding entry (with same field name and + protocol) in the permanent header field registry. + + + + + + +Klyne, et al. Best Current Practice [Page 8] + +RFC 3864 Header Field Registration September 2004 + + + The specification SHOULD indicate an email address for sending + technical comments and discussion of the proposed message header. + + The submission template has the following form. + + PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE: + + Header field name: + The name proposed for the new header field. This SHOULD conform + to the field name specification details noted in Section 4.1. + + Applicable protocol: + Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), + "netnews" (RFC 1036), or cite any other standards-track RFC + defining the protocol with which the header is intended to be + used. + + Status: + Specify: "provisional". This will be updated if and when the + header registration is subsequently moved to the permanent + registry. + + Author/Change controller: + The name, email address, and organization name of the submission + author, who may authorize changes to or retraction of the + repository entry. A postal address, home page URI, telephone and + fax numbers may also be included. + If the proposal comes from a standards body working group, give + the name and home page URI of the working group, and an email + address for discussion of or comments on the specification. + + Specification document(s): + Reference to document that specifies the header for use with the + indicated protocol. The document MUST be an RFC, a current + Internet-draft or the URL of a publicly accessible document (so + IANA can verify availability of the specification). An indication + of the relevant sections MAY also be included, but is not + required. + + NOTE: if the specification is available in printed form only, + then an Internet draft containing full reference to the paper + document should be published and cited in the registration + template. The paper specification MAY be cited under related + information. + + Related information: + Optionally, citations to additional documents containing further + relevant information. + + + +Klyne, et al. Best Current Practice [Page 9] + +RFC 3864 Header Field Registration September 2004 + + +4.3. Submission of Registration + + The registration template is submitted for incorporation in one of + the IANA message header field repositories by one of the following + methods: + + o An IANA considerations section in a defining RFC, calling for + registration of the message header and referencing information as + required by the registration template within the same document. + Registration of the header is then processed as part of the RFC + publication process. + + o Send a copy of the template to the designated email discussion + list [33] [34]. Allow a reasonable period - at least 2 weeks - + for discussion and comments, then send the template to IANA at the + designated email address [35]. IANA will publish the template + information if the requested name and the specification document + meet the criteria noted in Section 4.1 and Section 4.2.2, unless + the IESG or their designated expert have requested that it not be + published (see Section 4.4). IESG's designated expert should + confirm to IANA that the registration criteria have been + satisfied. + + When a new entry is recorded in the permanent message header field + registry, IANA will remove any corresponding entries (with the same + field name and protocol) from the provisional registry. + +4.4. Objections to Registration + + Listing of an entry in the provisional repository should not be + lightly refused. An entry MAY be refused if there is some credible + reason to believe that such registration will be harmful. In the + absence of such objection, IANA SHOULD allow any registration that + meets the criteria set out in Section 4.1 and Section 4.2.2. Some + reasonable grounds for refusal might be: + + o There is IETF consensus that publication is considered likely to + harm the Internet technical infrastructure in some way. + + o Disreputable or frivolous use of the registration facilities. + + o The proposal is sufficiently lacking in purpose, or misleading + about its purpose, that it can be held to be a waste of time and + effort. + + o Conflict with some current IETF activity. + + + + + +Klyne, et al. Best Current Practice [Page 10] + +RFC 3864 Header Field Registration September 2004 + + + Note that objections or disagreements about technical detail are not, + of themselves, considered grounds to refuse listing in the + provisional repository. After all, one of its purposes is to allow + developers to communicate with a view to combining their ideas, + expertise and energy to the maximum benefit of the Internet + community. + + Publication in an RFC or other form of Open Standard document (per + RFC 2026 [1], section 7) is sufficient grounds for publication in the + permanent registry. + + To assist IANA in determining whether or not there is a sustainable + objection to any registration, IESG nominates a designated expert to + liaise with IANA about new registrations. For the most part, the + designated expert's role is to confirm to IANA that the registration + criteria have been satisfied. + + The IESG or their designated expert MAY require any change or + commentary to be attached to any registry entry. + + The IESG is the final arbiter of any objection. + +4.5. Change Control + + Change control of a header field registration is subject to the same + condition as the initial registration; i.e., publication (or + reclassification) of an Open Standards specification for a Permanent + Message Header Field, or on request of the indicated author/change + controller for a Provisional Message Header (like the original + submission, subject to review on the designated email discussion list + [33].) + + A change to a permanent message header field registration MAY be + requested by the IESG. + + A change to or retraction of any Provisional Message Header Field + Repository entry MAY be requested by the IESG or designated expert. + + IANA MAY remove any Provisional Message Header Field Repository entry + whose corresponding specification document is no longer available + (e.g., expired Internet-draft, or URL not resolvable). Anyone may + notify IANA of any such cases by sending an email to the designated + email address [35]. Before removing an entry for this reason, IANA + SHOULD contact the registered Author/Change controller to determine + whether a replacement for the specification document (consistent with + the requirements of section Section 4.2.2) is available. + + + + + +Klyne, et al. Best Current Practice [Page 11] + +RFC 3864 Header Field Registration September 2004 + + + It is intended that entries in the Permanent Message Header Field + Registry may be used in the construction of URNs (per RFC 2141 [13]) + which have particular requirements for uniqueness and persistence + (per RFC 1737 [8]). Therefore, once an entry is made in the + Permanent Message Header Registry, the combination of the header name + and applicable protocol MUST NOT subsequently be registered for any + other purpose. (This is not to preclude revision of the applicable + specification(s) within the appropriate IETF Consensus rules, and + corresponding updates to the specification citation in the header + registration.) + +4.6. Comments on Header Definitions + + Comments on proposed registrations should be sent to the designated + email discussion list [33]. + +4.7. Location of Header Field Registry + + The message header field registry is accessible from IANA's web site + http://www.iana.org/assignments/message-headers/ + message-header-index.html + +5. IANA Considerations + + This specification calls for: + + o A new IANA registry for permanent message header fields per + Section 4 of this document. The policy for inclusion in this + registry is described in Section 4.1 and Section 4.2.1. + + o A new IANA repository listing provisional message header fields + per Section 4 of this document. The policy for inclusion in this + registry is described in Section 4.1 and Section 4.2.2. + + o IESG appoints a designated expert to advise IANA whether + registration criteria for proposed registrations have been + satisfied. + + No initial registry entries are provided. + +6. Security Considerations + + No security considerations are introduced by this specification + beyond those already inherent in the use of message headers. + + + + + + + +Klyne, et al. Best Current Practice [Page 12] + +RFC 3864 Header Field Registration September 2004 + + +7. Acknowledgements + + The shape of the registries described here owes much to energetic + discussion of previous versions by many denizens of the IETF-822 + mailing list. + + The authors also gratefully acknowledge the contribution of those who + provided valuable feedback on earlier versions of this memo: Charles + Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle + Cotton. + +8. References + +8.1. Normative References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April + 2001. + +8.2. Informative References + + [5] Horton, M. and R. Adams, "Standard for interchange of USENET + messages", RFC 1036, December 1987. + + [6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for + downgrading messages from X.400/88 to X.400/84 when MIME + content-types are present in the messages", RFC 1496, August + 1993. + + [7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header + Field for Internet Messages", RFC 1505, August 1993. + + [8] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, + October 1995. + + [10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. + + + +Klyne, et al. Best Current Practice [Page 13] + +RFC 3864 Header Field Registration September 2004 + + + [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [13] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [15] Troost, R., Dorner, S., and K. Moore, "Communicating + Presentation Information in Internet Messages: The Content- + Disposition Header Field", RFC 2183, August 1997. + + [16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting + for HTTP", RFC 2227, October 1997. + + [17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word + Extensions: Character Sets, Languages, and Continuations", RFC + 2231, November 1997. + + [18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition + Notification", RFC 3798, May 2004. + + [19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for + Core Mail List Commands and their Transport through Message + Header Fields", RFC 2369, July 1998. + + [20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + + [21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - + version 2 (VPIMv2)", RFC 3801, June 2004. + + [22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, + "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, + February 1999. + + [23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME + Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC + 2557, March 1999. + + + + + + +Klyne, et al. Best Current Practice [Page 14] + +RFC 3864 Header Field Registration September 2004 + + + [24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., + Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + + [25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: + Basic and Digest Access Authentication", RFC 2617, June 1999. + + [26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [27] Klyne, G., "Indicating Media Features for MIME Content", RFC + 2912, September 2000. + + [28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and + Namespace for the Identification of Mailing Lists", RFC 2919, + March 2001. + + [29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", + RFC 2965, October 2000. + + [30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. + + [32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, + "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C + Recommendation xml, October 2000, + <http://www.w3.org/TR/2000/REC-xml-20001006>. + + [33] "Mail address for announcement of new header field submissions", + Mail address: ietf-message-headers@lists.ietf.org + + [34] "Mail address for subscription to ietf-message- + headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO + THE MAILING LIST ITSELF)", Mail address: ietf-message-headers- + request@lists.ietf.org + + [35] "Mail address for submission of new header field templates", + Mail address: iana@iana.org + + + + + + + + + +Klyne, et al. Best Current Practice [Page 15] + +RFC 3864 Header Field Registration September 2004 + + +9. Authors' Addresses + + Graham Klyne + Nine by Nine + + EMail: GK-IETF@ninebynine.org + URI: http://www.ninebynine.net/ + + + Mark Nottingham + BEA Systems + 235 Montgomery St. + Level 15 + San Francisco, CA 94104 + USA + + EMail: mnot@pobox.com + + + Jeffrey C. Mogul + HP Labs + 1501 Page Mill Road + Palo Alto, CA 94304 + US + + EMail: JeffMogul@acm.org + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et al. Best Current Practice [Page 16] + +RFC 3864 Header Field Registration September 2004 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Klyne, et al. Best Current Practice [Page 17] + |