RFC 4249

Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components

📅 published January 2006, from ietf

RFC 4249: Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components 🎀✨

  • Number: RFC 4249
  • Who wrote it: B. Lilly, from the Network Working Group
  • When: January 2006
  • Category: Informational 📚
  • Obsoletes / Updates: nothing! This title block doesn't list any RFCs it obsoletes or updates 🫶

Status of This Memo 💅

okay so this memo just gives info to the Internet community. it is NOT an Internet standard of any kind 🙅‍♀️ distribution is totally unlimited, so share it with everyone 🌸

Copyright (C) The Internet Society (2006). 🦋

Abstract ✨

okay this part is the TL;DR 💖 when you're building generators and parsers for header fields, you need certain info about those fields. interop works best when the tech spec spells out ALL of that info explicitly. if it doesn't, implementers gotta guess, and then things break 💀 this memo points out the info that helps implementers of header field generators and parsers 🔥

1. Introduction 🧚

okay so Internet messages are made of a message header and a body [N1.STD11], [N2.RFC2822] 💜 MIME content starts with a MIME-part header [N3.RFC2045], [N4.RFC2046]. both message headers and MIME-part headers are built out of fields 🍓

the Message Format and MIME specs define their overall formats and some specific fields, but they also make room for extension fields. a bunch of extension fields exist now, and some are way more fully specified than others 🙈 when the spec is incomplete or fuzzy, implementers start making assumptions, and that's literally where the interop drama comes from 😭

so this memo points out stuff implementers would find useful. section 3 can work as an informational guide for people writing specs for extension fields and field components ✨

2. Scope 🌈

this memo is a non-binding, informational supplement to a bunch of specs, guidelines, and procedures for writing header field specs: [N1.STD11], [N2.RFC2822], [N3.RFC2045], [N4.RFC2046], [N5.BCP9], [N6.BCP90] 📖 it does NOT get authors off the hook from following any provisions of those or other specs, guidelines, and procedures 🙅‍♀️ what it DOES do is offer clarification and extra suggestions that promote interop, and it can save spec authors from a ton of questions about incomplete header field specs 💖

3. Specification Items 💅

3.1. Established Conventions 👑

there are a bunch of conventions for naming and specifying header fields 🎀 making a field that clashes with those conventions would be unwise and confusing, so don't do it bestie 🙈

3.1.1. Standard Terminology 📚

terms related to the Internet Message Format are defined in [N2.RFC2822] ✨ authors specifying extension header fields SHOULD use those same terms in the same manner, so everything stays clear and nobody gets confused 💜 for example, a "header" [I1.FYI18], [N2.RFC2822] is made of "header fields", and each header field has a "field name" and usually a "field body" 🍓 each message can have multiple "headers", meaning a message header AND MIME-part [N4.RFC2046] headers 🦋

a message header has a Date header field (a field whose field name is "Date") 🌸 BUT there is no "Date header" 💀 using non-standard terms like that is likely to cause confusion, and it could even end in interop failures between implementations 😭

3.1.2. Naming Rules and Conventions 🫶

several rules and conventions exist for naming header fields 🌈 the rules are codified in published RFCs, while the conventions just reflect common use ✨

3.1.2.1. Naming Rules 💎

some RFCs define a specific prefix and reserve it for specific purposes 🔐

3.1.2.1.1. Content- prefix rule 🎀

this prefix MUST be used for all MIME extension fields, and it MUST NOT be used for fields that aren't MIME extension fields [N3.RFC2045] (section 9) 💅

3.1.2.1.2. Resent- prefix rule 🦋

this one is specified for certain standard fields given in [N1.STD11] (it's also used by [N2.RFC2822], even though [N2.RFC2822] doesn't specify it as a prefix) 💜 if a Resent- version of a field applies, an author SHOULD say so explicitly, and SHOULD also provide a comprehensive spec of any differences between the plain field and the Resent- version 🙌

3.1.2.2. Naming Conventions 🌸

some prefixes grew into conventions over time 🍓 they aren't formally specified as reserved prefixes, but they've been used in multiple fields with common semantics for each prefix 💖

3.1.2.2.1. Accept- prefix convention 🧚

this prefix SHOULD be used for all extension fields meant for content negotiation [I2.RFC2616], and SHOULD NOT be used for fields that aren't meant for that 🙅‍♀️ an example is in [I3.RFC3282] ✨

3.1.2.2.2. List- prefix convention 📬

this one indicates info about mailing lists when a list expansion happens 💜 examples of defined fields are in [I4.RFC2369] and [I5.RFC2919] 🌈

3.1.2.2.3. Illegal- prefix convention 🙈

this prefix keeps a record of illegal content in a field when fields get transformed at a gateway [I6.RFC886] 🔥

3.1.2.2.4. Disposition-Notification- prefix convention 🦋

this is for specifying info used alongside Message Disposition Notifications (MDNs) [I7.RFC3798] 💅

3.1.2.2.5. Original- prefix convention 🌸

this one references some content from a related message 🧚 examples include Original-Message-ID (used by [I8.RFC3297] and [I7.RFC3798]), Original-Encoded-Information-Types [I9.RFC2156], Original-Envelope-ID [I10.RFC3464], and Original-Recipient [I7.RFC3798] ✨

3.1.2.2.6. Reporting- prefix 📋

this specifies a host that generated a type of report, like the ones defined in [I7.RFC3798] and [I10.RFC3464] 💖

3.1.2.2.7. X400- prefix convention 🌈

this is used when gateways convert from X.400 environments [I9.RFC2156] 🎀

3.1.2.2.8. Discarded-X400- prefix convention 💜

gateways from X.400 also use this one [I9.RFC2156] 🫶

3.1.2.2.9. P1- prefix convention 🕰️

this was used by X.400 gateways [I11.RFC987] 🍓 (past tense, so it's kinda retired now, iykyk 💀)

3.1.2.2.10. Delivery-Report-Content- prefix convention 📦

this one was also used by legacy X.400 gateways [I11.RFC987] 🦋

3.2. Common Specification Items 🌟

several items are specified for standard header fields, and these items SHOULD also be specified for extension fields 💅 so basically, if the standard fields get the full treatment, your extension fields should too, periodt 👑

okay that's part 1 of 3! 🫶 more of the RFC is coming next, so stay tuned, bestie 🌈

3.2.1. ABNF ✨

okay so [N1.STD11] is kinda vague about where whitespace is allowed or required in header field syntax 🙈 and that's exactly where bugs love to hide. [N2.RFC2822] fixes this by defining grammar productions like FWS and CFWS, used together with formal ABNF [N7.RFC4234] and in line with the need for specificity noted in section 3.1 of [N7.RFC4234]. Extension field ABNF should clearly spell out where comments, line folding, and whitespace are prohibited and permitted, and should use the [N2.RFC2822] grammar productions in ABNF for that purpose 💖

bestie, all ABNF must be carefully checked for ambiguities, and every production has to resolve to some combination of terminal productions from a normative reference [N8.CKLIST] ("All ABNF must be checked") 🔍 [N7.RFC4234] has a few productions that may be useful 🧚 Using suitable productions that are already defined and in use is encouraged, but authors are cautioned that some of them have been amended by later RFCs and/or by formal errata [I12.Errata]. so check before you copy! 💅

authors and designers should be careful not to mix syntax with disparate semantics inside a single field 🙅‍♀️ the classic examples are:

  • [N2.RFC2822] comments, which use parentheses as delimiters
  • [I13.RFC2533] feature sets, which also use parentheses as delimiters but not for comments
  • [I14.RFC3986] Uniform Resource Identifiers (URIs), which permit parentheses in URI text

it is sometimes necessary or desirable to define keywords as protocol elements in structured fields ✨ protocol elements should be case insensitive per the Internet Architecture [I15.RFC1958] (section 4.3) 🎀 keywords are typically registered by IANA. a specification using registered keywords must include an IANA Considerations section [N9.BCP26], [I16.RFC3692], and should tell readers exactly where IANA has set up the registry (authors will need to coordinate this with IANA prior to publication as an RFC) 📋 in lots of cases it's smart to make room for extending the keyword set. you can do that by saying the set may be extended by publication of an RFC, or by specifying a formal review and registration procedure (typically as a BCP RFC) 🌸

if keywords are defined, and there's any chance the set might expand, a registry should be established via IANA 🗂️ if a registry isn't set up at the start, there's a good chance the initially-defined keywords won't get registered, or will later get registered with different semantics (this has happened!) 💀

provision may be made for experimental or private-use keywords 🧪 these typically begin with a case-insensitive x- prefix. note that [N10.BCP82] has specific considerations for the use of experimental keywords ⚠️

if some field content is to be considered human-readable text, there must be provision for specifying language in accordance with [N11.BCP18] (section 4.2) 🌍 header fields typically use the mechanism in [I17.RFC2047], as amended by [I18.RFC2231] and [I12.Errata], for that purpose. but here's the tea: that mechanism only applies to three specific cases: unstructured fields, an RFC 822 "word" in an RFC 822 "phrase", and comments in structured fields 🫶 any internationalization considerations should be detailed in an Internationalization Considerations section of the specification, as specified in [N11.BCP18] (section 6) ✨

some field bodies may include ABNF representing numerical values 🔢 that ABNF, its comments, and the supporting normative text should clearly say whether the number is decimal, octal, hexadecimal, etc.; whether leading and/or trailing zeroes are significant and/or permitted; and how any combination of numeric fields is meant to be interpreted 🧮 for example, two numeric fields separated by a dot, like 001.100, 1.1, 1.075, and 1.75, could be interpreted in several different ways depending on the factors listed above 🙈

while ABNF [N7.RFC4234] is used by [N2.RFC2822] and is mentioned above, alternate formal syntax formats may be used in specifications [I19.Syntax] 🦋

3.2.2. Minimum and Maximum Instances of Fields per Header 🌈

some fields are mandatory, others are optional 📝 it can make sense to allow multiple instances of a field in a given header, while in other cases at most one instance is the sensible call 🎯 [N2.RFC2822] specifies a minimum and maximum count per header for each standard field in a message. specification authors should likewise specify minimum and maximum counts for extension fields 💖

3.2.3. Categorization 🗂️

[N2.RFC2822] defines categories of header fields (e.g., trace fields, address fields) 🏷️ these categories matter because they affect how fields get processed and handled 🔧 a specification author should indicate any applicable categories ✨

3.3. Semantics 🧠

in addition to specifying the syntax of a field, a specification document should indicate the semantics of each field 💜 those semantics are made up of several aspects:

3.3.1. Producers, Modifiers, and Consumers 🎭

some fields are meant for end-to-end communication between the author or sender and the recipient 💌 those fields should not be generated or altered by intermediaries in the transmission chain [I20.Arch] 🙅‍♀️ other fields are trace information that gets added during transport 🕵️‍♀️ so authors should clearly specify who may generate a field, who may modify it in transit, who should interpret it, and who is prohibited from interpreting or modifying it 👑

3.3.2. What's it all about? 🤔

when you introduce a new field or modify an existing one, an author should present a clear description of the problem or situation that the extension or change addresses 💡 no mystery vibes allowed, bestie 🫶

3.3.3. Context 📍

the permitted types of headers the field may appear in should be specified 🗺️ some fields might only be appropriate in a message header, some might appear in MIME-part headers [N4.RFC2046] as well as message headers, and still others might appear in specialized MIME media types 🎀

3.4. Overall Considerations 🌸

several factors should be specified about how a field interacts with the Internet at large, with the applications it's intended for, and with other applications 🌐

3.4.1. Security 🔐

every specification is supposed to include a carefully-considered Security Considerations section [N12.RFC2223] (section 9), [I21.BCP72] 🛡️ no skipping this one!!

3.4.2. Backward Compatibility 🕰️

there is a large deployed base of applications that use header fields 📦 the implementations in that deployed base may change very slowly 🐢 so it is critically important to consider and specify the impact of a new or revised field, or field component, on that deployed base 😭 a new field, or extensions to the syntax of an existing field or field component, might not be recognizable to deployed implementations 👀 depending on how carefully the authors of an extension have thought about backward compatibility, the extension might, for example:

  • a. Cause a deployed implementation to simply ignore the field in its entirety. That is not a problem provided it is a new field and there is no assumption that such deployed implementations will do otherwise 🙈
  • b. Cause a deployed implementation to behave differently from how it would behave without the proposed change, in ways the proposal didn't intend. That is a failure of the proposal to remain backward compatible with the deployed base of implementations 💀

there are many subtleties and variations that may come into play 🌀 authors should very carefully consider backward compatibility when devising extensions, and should clearly describe all known compatibility issues 🫶

3.4.3. Compatibility With Legacy Content 📼

content is sometimes archived for various reasons 🗄️ it's sometimes necessary or desirable to access archived content with its semantics unchanged ⏳ so it's important that the lack of an extension field or field component should not be read (by an extension specification) as giving new semantics to a message or piece of MIME content that lacks that field or field component 🙅‍♀️ any such semantics should be explicitly specified 📝

3.4.4. Interaction With Established Mechanisms 🤝

header fields get handled specially by gateways in various circumstances, e.g., message fragmentation and reassembly [N4.RFC2046] ✂️🧩 if a header field needs special treatment in those circumstances, the author of the specification should clearly specify it 📣 [I7.RFC3798] is an example of how this might be handled. however, because that specification requires deployed RFC 2046-conforming implementations to be modified, it is not strictly backward compatible 😬

4. Acknowledgements 🫶

the author would like to thank members of the ietf-822 mailing list for their helpful comments 💌 in particular, Peter Koch and Keith Moore made useful comments 👑

5. Security Considerations 🚨

no new security considerations are addressed by this memo 😮‍💨 but the memo reinforces the need for careful consideration and specification of security issues. so security stays serious, bestie 🔐🔥

6. Internationalization Considerations 🌍

this memo does not directly have internationalization considerations 🙌 however, it reminds specification authors of the need to consider internationalization of textual field components 🗣️

7. IANA Considerations ✨

while no specific action is required of IANA in regard to this memo, it does note that some coordination between IANA and specification authors who do require IANA to set up registries is at least desirable, if not a necessity 🤝 IANA should also closely coordinate with the RFC Editor, so registries are set up and properly referenced at the time of publication of an RFC that refers to such a registry 📚 IANA is also encouraged to work closely with authors and the RFC Editor to make sure the descriptions of registries IANA maintains are accurate and meaningful 🎀

Appendix A. Disclaimers 💅

this document has exactly one (1) author 🧍‍♂️

in spite of the fact that the author's given name may also be the surname of other individuals, and that the author's surname may also be a given name for some females, the author is, and has always been, male 🙃

the presence of /SHE, their, and authors (plural) in the boilerplate sections of this document is irrelevant 📜 the author of this document is not responsible for the boilerplate text 🙈

comments regarding the silliness, lack of accuracy, and lack of precision of the boilerplate text should be directed to the IESG, not to the author 😭💖

References 📚

Normative References 🔒

These are the must-read docs this one leans on, the ones you can't skip if you want the full picture bestie 💖

  • [N1.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
  • [N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [N3.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [N4.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [N5.BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [N6.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
  • [N7.RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [N8.CKLIST] "Checklist for Internet-Drafts (IDs) submitted for RFC publication", http://www.ietf.org/ID-Checklist.html.
  • [N9.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [N10.BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
  • [N11.BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
  • [N12.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

Informative References 🧠

These ones are the extra reading for when you want the backstory, the glossary, and the vibes of the wider mail world 🌸

  • [I1.FYI18] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
  • [I2.RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [I3.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
  • [I4.RFC2369] 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.
  • [I5.RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
  • [I6.RFC886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
  • [I7.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
  • [I8.RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
  • [I9.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
  • [I10.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
  • [I11.RFC987] Kille, S., "Mapping between X.400 and RFC 822", RFC 987, June 1986.
  • [I12.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html.
  • [I13.RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
  • [I14.RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [I15.RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [I16.RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
  • [I17.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
  • [I18.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
  • [I19.Syntax] Carpenter, B., "Syntax for format definitions", http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt.
  • [I20.Arch] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005.
  • [I21.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

Author's Address 🖊️

Bruce Lilly 💜

EMail: blilly@erols.com

Copyright (C) The Internet Society (2006). 🌈

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.

Okay, the legal part, and I'm keeping it word for word because it matters 🫶

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 on whether 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 are valid or in scope, or whether any license under those rights might or might not be available. It also doesn't claim to have done any independent digging to find such rights. If you want the procedures for rights in RFC documents, go to BCP 78 and BCP 79. 🔍

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📨

Acknowledgement 🎀

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🫶✨

📦 where this page comes from