Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
RFC 4249
Document | Type |
RFC - Informational
(January 2006; No errata)
Was draft-lilly-field-specification (individual in app area)
|
|
---|---|---|---|
Author | Bruce Lilly | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4249 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | (None) |
Network Working Group B. Lilly Request for Comments: 4249 January 2006 Category: Informational Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. Table of Contents 1. Introduction ....................................................2 2. Scope ...........................................................2 3. Specification Items .............................................3 3.1. Established Conventions ....................................3 3.1.1. Standard Terminology ................................3 3.1.2. Naming Rules and Conventions ........................3 3.2. Common Specification Items .................................5 3.2.1. ABNF ................................................5 3.2.2. Minimum and Maximum Instances of Fields per Header ..6 3.2.3. Categorization ......................................7 3.3. Semantics ..................................................7 3.3.1. Producers, Modifiers, and Consumers .................7 3.3.2. What's it all about? ................................7 3.3.3. Context .............................................7 3.4. Overall Considerations .....................................7 3.4.1. Security ............................................8 3.4.2. Backward Compatibility ..............................8 3.4.3. Compatibility With Legacy Content ...................8 Lilly Informational [Page 1] RFC 4249 Specification of Header Fields January 2006 3.4.4. Interaction With Established Mechanisms .............9 4. Acknowledgements ................................................9 5. Security Considerations .........................................9 6. Internationalization Considerations .............................9 7. IANA Considerations .............................................9 Appendix A. Disclaimers ...........................................10 Normative References ..............................................11 Informative References ............................................11 1. Introduction Internet messages consist of a message header and a body [N1.STD11], [N2.RFC2822]. MIME content begins with a MIME-part header [N3.RFC2045], [N4.RFC2046]. Message headers and MIME-part headers consist of fields. While the Message Format and MIME specifications define their respective overall formats and some specific fields, they also have provision for extension fields. A number of extension fields have been specified, some more or less completely than others. Incomplete or imprecise specification has led to interoperability problems as implementers make assumptions in the absence of specifications. This memo identifies items of potential interest to implementers, and section 3 of this memo may serve as an informational guide for authors of specifications of extension fields and field components. 2. Scope This memo is intended as a non-binding informational supplement to various specifications, guidelines, and procedures for specification of header fields [N1.STD11], [N2.RFC2822], [N3.RFC2045], [N4.RFC2046], [N5.BCP9], [N6.BCP90]. It does not absolve authors of header field specifications from compliance with any provisions of those or other specifications, guidelines, and procedures. It offers clarification and supplementary suggestions that will promote interoperability and may spare specification authors many questions regarding incomplete header field specifications. Lilly Informational [Page 2] RFC 4249 Specification of Header Fields January 2006 3. Specification Items 3.1. Established Conventions A number of conventions exist for naming and specifying header fields. It would be unwise and confusing to specify a field that conflicts with those conventions. 3.1.1. Standard Terminology Terms related to the Internet Message Format are defined inShow full document text