4249
INFORMATIONAL
Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
Authors: B. Lilly
Date: January 2006
Working Group: NON WORKING GROUP
Stream: IETF
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. This memo provides information for the Internet community.
RFC 4249
INFORMATIONAL
Network Working Group B. Lilly
Request for Comments: 4249 January 2006
Category: Informational
<span class="h1">Implementer-Friendly Specification of Message and MIME-Part Header</span>
<span class="h1">Fields and Field Components</span>
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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Scope ...........................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Specification Items .............................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Established Conventions ....................................<a href="#page-3">3</a>
<a href="#section-3.1.1">3.1.1</a>. Standard Terminology ................................<a href="#page-3">3</a>
<a href="#section-3.1.2">3.1.2</a>. Naming Rules and Conventions ........................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Common Specification Items .................................<a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. ABNF ................................................<a href="#page-5">5</a>
<a href="#section-3.2.2">3.2.2</a>. Minimum and Maximum Instances of Fields per Header ..6
<a href="#section-3.2.3">3.2.3</a>. Categorization ......................................<a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Semantics ..................................................<a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Producers, Modifiers, and Consumers .................<a href="#page-7">7</a>
<a href="#section-3.3.2">3.3.2</a>. What's it all about? ................................<a href="#page-7">7</a>
<a href="#section-3.3.3">3.3.3</a>. Context .............................................<a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Overall Considerations .....................................<a href="#page-7">7</a>
<a href="#section-3.4.1">3.4.1</a>. Security ............................................<a href="#page-8">8</a>
<a href="#section-3.4.2">3.4.2</a>. Backward Compatibility ..............................<a href="#page-8">8</a>
<a href="#section-3.4.3">3.4.3</a>. Compatibility With Legacy Content ...................<a href="#page-8">8</a>
<span class="grey">Lilly Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<a href="#section-3.4.4">3.4.4</a>. Interaction With Established Mechanisms .............<a href="#page-9">9</a>
<a href="#section-4">4</a>. Acknowledgements ................................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Internationalization Considerations .............................<a href="#page-9">9</a>
<a href="#section-7">7</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Disclaimers ...........................................<a href="#page-10">10</a>
Normative References ..............................................<a href="#page-11">11</a>
Informative References ............................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Internet messages consist of a message header and a body [<a href="#ref-N1.STD11" title=""Standard for the format of ARPA Internet text messages"">N1.STD11</a>],
[N2.<a href="./rfc2822">RFC2822</a>]. MIME content begins with a MIME-part header
[N3.<a href="./rfc2045">RFC2045</a>], [N4.<a href="./rfc2046">RFC2046</a>]. 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 <a href="#section-3">section 3</a> of this memo may serve as an
informational guide for authors of specifications of extension fields
and field components.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scope</span>
This memo is intended as a non-binding informational supplement to
various specifications, guidelines, and procedures for specification
of header fields [<a href="#ref-N1.STD11" title=""Standard for the format of ARPA Internet text messages"">N1.STD11</a>], [N2.<a href="./rfc2822">RFC2822</a>], [N3.<a href="./rfc2045">RFC2045</a>],
[N4.<a href="./rfc2046">RFC2046</a>], [<a href="#ref-N5.BCP9" title=""The Internet Standards Process -- Revision 3"">N5.BCP9</a>], [<a href="#ref-N6.BCP90" title=""Registration Procedures for Message Header Fields"">N6.BCP90</a>]. 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.
<span class="grey">Lilly Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Specification Items</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Established Conventions</span>
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.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Standard Terminology</span>
Terms related to the Internet Message Format are defined in
[N2.<a href="./rfc2822">RFC2822</a>]. Authors specifying extension header fields should use
the same terms in the same manner in order to provide clarity and
avoid confusion. For example, a "header" [<a href="#ref-I1.FYI18" title=""Internet Users' Glossary"">I1.FYI18</a>], [N2.<a href="./rfc2822">RFC2822</a>] is
comprised of "header fields", each of which has a "field name" and
usually has a "field body". Each message may have multiple
"headers", viz. a message header and MIME-part [N4.<a href="./rfc2046">RFC2046</a>] headers.
A message header has a Date header field (i.e., a field with field
name "Date"). However, there is no "Date header"; use of such non-
standard terms is likely to lead to confusion, possibly resulting in
interoperability failures of implementations.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Naming Rules and Conventions</span>
Several rules and conventions have been established for naming of
header fields. Rules are codified in published RFCs; conventions
reflect common use.
<span class="h5"><a class="selflink" id="section-3.1.2.1" href="#section-3.1.2.1">3.1.2.1</a>. Naming Rules</span>
Some RFCs define a particular prefix, reserving use of that prefix
for specific purposes.
<span class="h6"><a class="selflink" id="section-3.1.2.1.1" href="#section-3.1.2.1.1">3.1.2.1.1</a>. Content- prefix rule</span>
This prefix must be used for all MIME extension fields and must not
be used for fields that are not MIME extension fields [N3.<a href="./rfc2045">RFC2045</a>]
(<a href="#section-9">section 9</a>).
<span class="h6"><a class="selflink" id="section-3.1.2.1.2" href="#section-3.1.2.1.2">3.1.2.1.2</a>. Resent- prefix rule</span>
Specified for certain standard fields as given in [<a href="#ref-N1.STD11" title=""Standard for the format of ARPA Internet text messages"">N1.STD11</a>] (also
used by [N2.<a href="./rfc2822">RFC2822</a>], although not specified as a prefix therein).
If a Resent- version of a field is applicable, an author should say
so explicitly and should provide a comprehensive specification of any
differences between the plain field and the Resent- version.
<span class="grey">Lilly Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h5"><a class="selflink" id="section-3.1.2.2" href="#section-3.1.2.2">3.1.2.2</a>. Naming Conventions</span>
Some prefixes have developed as conventions. Although not formally
specified as reserved prefixes, these conventions are or have been in
use in multiple fields with common semantics for each prefix.
<span class="h6"><a class="selflink" id="section-3.1.2.2.1" href="#section-3.1.2.2.1">3.1.2.2.1</a>. Accept- prefix convention</span>
This prefix should be used for all extension fields intended for use
in content negotiation [I2.<a href="./rfc2616">RFC2616</a>] and should not be used for fields
that are not intended for such use. An example may be found in
[I3.<a href="./rfc3282">RFC3282</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.2" href="#section-3.1.2.2.2">3.1.2.2.2</a>. List- prefix convention</span>
Used to indicate information about mailing lists when a list
expansion takes place. Examples of defined fields can be found in
[I4.<a href="./rfc2369">RFC2369</a>] and [I5.<a href="./rfc2919">RFC2919</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.3" href="#section-3.1.2.2.3">3.1.2.2.3</a>. Illegal- prefix convention</span>
This prefix provides a record of illegal content in a field when
fields are transformed at a gateway [I6.<a href="./rfc886">RFC886</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.4" href="#section-3.1.2.2.4">3.1.2.2.4</a>. Disposition-Notification- prefix convention</span>
Specification of information used in conjunction with Message
Disposition Notifications (MDNs) [I7.<a href="./rfc3798">RFC3798</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.5" href="#section-3.1.2.2.5">3.1.2.2.5</a>. Original- prefix convention</span>
Used to reference some content from a related message. Examples
include Original-Message-ID as used by [I8.<a href="./rfc3297">RFC3297</a>] and [I7.<a href="./rfc3798">RFC3798</a>],
Original-Encoded-Information-Types [I9.<a href="./rfc2156">RFC2156</a>], Original-Envelope-ID
[I10.<a href="./rfc3464">RFC3464</a>], and Original-Recipient [I7.<a href="./rfc3798">RFC3798</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.6" href="#section-3.1.2.2.6">3.1.2.2.6</a>. Reporting- prefix</span>
Specifies a host that generated a type of report, such as those
defined in [I7.<a href="./rfc3798">RFC3798</a>], [I10.<a href="./rfc3464">RFC3464</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.7" href="#section-3.1.2.2.7">3.1.2.2.7</a>. X400- prefix convention</span>
Used in conversion from X.400 environments by gateways [I9.<a href="./rfc2156">RFC2156</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.8" href="#section-3.1.2.2.8">3.1.2.2.8</a>. Discarded-X400- prefix convention</span>
Also used by gateways from X.400 [I9.<a href="./rfc2156">RFC2156</a>].
<span class="grey">Lilly Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h6"><a class="selflink" id="section-3.1.2.2.9" href="#section-3.1.2.2.9">3.1.2.2.9</a>. P1- prefix convention</span>
Was used by X.400 gateways [I11.<a href="./rfc987">RFC987</a>].
<span class="h6"><a class="selflink" id="section-3.1.2.2.10" href="#section-3.1.2.2.10">3.1.2.2.10</a>. Delivery-Report-Content- prefix convention</span>
Also used by legacy X.400 gateways [I11.<a href="./rfc987">RFC987</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Common Specification Items</span>
Several items are specified for standard header fields; these items
should also be specified for extension fields.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. ABNF</span>
[<a id="ref-N1.STD11">N1.STD11</a>] is vague about where whitespace is permitted or required
in header field syntax. [N2.<a href="./rfc2822">RFC2822</a>] addresses that issue by
defining grammar productions such as FWS and CFWS, in conjunction
with formal ABNF [N7.<a href="./rfc4234">RFC4234</a>] and in accordance with the necessity
for specificity of such issues as noted in <a href="#section-3.1">section 3.1</a> of
[N7.<a href="./rfc4234">RFC4234</a>]. Extension field ABNF should clearly specify where
comments, line folding, and whitespace are prohibited and permitted,
and should use the [N2.<a href="./rfc2822">RFC2822</a>] grammar productions in ABNF for that
purpose.
All ABNF must be carefully checked for ambiguities and to ensure that
all productions resolve to some combination of terminal productions
provided by a normative reference [<a href="#ref-N8.CKLIST" title=""Checklist for Internet-Drafts (IDs) submitted for RFC publication"">N8.CKLIST</a>] ("All ABNF must be
checked"). [N7.<a href="./rfc4234">RFC4234</a>] provides several productions that may be
useful. While use of suitable productions defined and in use is
encouraged, specification authors are cautioned that some such
productions have been amended by subsequently issued RFCs and/or by
formal errata [<a href="#ref-I12.Errata">I12.Errata</a>].
Authors and designers should be careful not to mix syntax with
disparate semantics within a single field. Examples of disparate
semantics are [N2.<a href="./rfc2822">RFC2822</a>] comments (which use parentheses as
delimiters), [I13.<a href="./rfc2533">RFC2533</a>] feature sets (which also use parentheses
as delimiters, but not for comments), and [I14.<a href="./rfc3986">RFC3986</a>] 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.<a href="./rfc1958">RFC1958</a>] (<a href="#section-4.3">section</a>
<a href="#section-4.3">4.3</a>). Keywords are typically registered by IANA; a specification
using registered keywords must include an IANA Considerations section
[<a href="#ref-N9.BCP26" title="">N9.BCP26</a>], [I16.<a href="./rfc3692">RFC3692</a>], and should indicate to readers of the
specification precisely where IANA has set up the registry (authors
<span class="grey">Lilly Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
will need to coordinate this with IANA prior to publication as an
RFC). In many cases, it will be desirable to make provision for
extending the set of keywords; that may be done by specifying that
the set may be extended by publication of an RFC, or a formal review
and registration procedure may be specified (typically as a BCP RFC).
If keywords are defined, and if there is any chance that the set of
keywords might be expanded, a registry should be established via
IANA. If a registry is not established initially, there is a good
chance that initially-defined keywords will not be registered or will
subsequently be 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
[<a href="#ref-N10.BCP82" title=""Assigning Experimental and Testing Numbers Considered Useful"">N10.BCP82</a>] has specific considerations for 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
[<a href="#ref-N11.BCP18" title=""IETF Policy on Character Sets and Languages"">N11.BCP18</a>] (<a href="#section-4.2">section 4.2</a>). Header fields typically use the mechanism
specified in [I17.<a href="./rfc2047">RFC2047</a>] as amended by [I18.<a href="./rfc2231">RFC2231</a>] and
[<a href="#ref-I12.Errata">I12.Errata</a>] for that purpose. Note, however, that that mechanism
applies only to three specific cases: unstructured fields, an <a href="./rfc822">RFC 822</a>
"word" in an <a href="./rfc822">RFC 822</a> "phrase", and comments in structured fields.
Any internationalization considerations should be detailed in an
Internationalization Considerations section of the specification as
specified in [<a href="#ref-N11.BCP18" title=""IETF Policy on Character Sets and Languages"">N11.BCP18</a>] (<a href="#section-6">section 6</a>).
Some field bodies may include ABNF representing numerical values.
Such ABNF, its comments, and supporting normative text should clearly
indicate whether such a numerical value is decimal, octal,
hexadecimal, etc.; whether or not leading and/or trailing zeroes are
significant and/or permitted; and how any combinations of numeric
fields are intended to be interpreted. For example, two numeric
fields separated by a dot, exemplified by "001.100", "1.1", "1.075",
and "1.75", might be interpreted in several ways, depending on
factors such as those enumerated above.
While ABNF [N7.<a href="./rfc4234">RFC4234</a>] is used by [N2.<a href="./rfc2822">RFC2822</a>] and is mentioned
above, alternate formal syntax formats may be used in specifications
[<a href="#ref-I19.Syntax" title=""Syntax for format definitions"">I19.Syntax</a>].
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Minimum and Maximum Instances of Fields per Header</span>
Some fields are mandatory, others are optional. It may make sense to
permit multiple instances of a field in a given header; in other
cases, at most a single instance is sensible. [N2.<a href="./rfc2822">RFC2822</a>] specifies
<span class="grey">Lilly Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
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.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Categorization</span>
[N2.<a href="./rfc2822">RFC2822</a>] defines categories of header fields (e.g., trace fields,
address fields). Such categories have implications for processing
and handling of fields. A specification author should indicate any
applicable categories.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Semantics</span>
In addition to specifying syntax of a field, a specification document
should indicate the semantics of each field. Such semantics are
composed of several aspects:
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Producers, Modifiers, and Consumers</span>
Some fields are intended for end-to-end communication between author
or sender and recipient; such fields should not be generated or
altered by intermediaries in the transmission chain [<a href="#ref-I20.Arch" title=""Internet Mail Architecture"">I20.Arch</a>].
Other fields comprise trace information that is added during
transport. Authors should clearly specify who may generate a field,
who may modify it in transit, who should interpret such a field, and
who is prohibited from interpreting or modifying the field.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. What's it all about?</span>
When introducing a new field or modifying an existing field, an
author should present a clear description of what problem or
situation is being addressed by the extension or change.
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Context</span>
The permitted types of headers in which the field may appear should
be specified. Some fields might only be appropriate in a message
header, some might appear in MIME-part headers [N4.<a href="./rfc2046">RFC2046</a>] as well
as message headers, still others might appear in specialized MIME
media types.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Overall Considerations</span>
Several factors should be specified regarding how a field interacts
with the Internet at large, with the applications for which it is
intended, and in interacting with other applications.
<span class="grey">Lilly Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Security</span>
Every specification is supposed to include a carefully-considered
Security Considerations section [N12.<a href="./rfc2223">RFC2223</a>] (<a href="#section-9">section 9</a>),
[<a href="#ref-I21.BCP72" title=""Guidelines for Writing RFC Text on Security Considerations"">I21.BCP72</a>].
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Backward Compatibility</span>
There is a large deployed base of applications that use header
fields. Implementations that comprise that deployed base may change
very slowly. It is therefore 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 the care with which the
authors of an extension have considered such backward compatibility,
such an extension might, for example:
a. Cause a deployed implementation to simply ignore the field in its
entirety. That is not a problem provided that it is a new field
and that there is no assumption that such deployed implementations
will do otherwise.
b. Cause a deployed implementation to behave differently from how it
would behave in the absence of the proposed change, in ways that
are not intended by the proposal. 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.
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. Compatibility With Legacy Content</span>
Content is sometimes archived for various reasons. It is sometimes
necessary or desirable to access archived content, with the semantics
of that archived content unchanged. It is therefore important that
lack of presence of an extension field or field component should not
be construed (by an extension specification) as conferring new
semantics on a message or piece of MIME content that lacks that field
or field component. Any such semantics should be explicitly
specified.
<span class="grey">Lilly Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>. Interaction With Established Mechanisms</span>
Header fields are handled specially by gateways under various
circumstances, e.g., message fragmentation and reassembly
[N4.<a href="./rfc2046">RFC2046</a>]. If special treatment is required for a header field
under such circumstances, it should be clearly specified by the
author of the specification. [I7.<a href="./rfc3798">RFC3798</a>] is an example of how this
might be handled (however, because that specification requires
deployed <a href="./rfc2046">RFC 2046</a>-conforming implementations to be modified, it is
not strictly backward compatible).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Acknowledgements</span>
The author would like to acknowledge the helpful comments provided by
members of the ietf-822 mailing list. In particular, Peter Koch and
Keith Moore have made useful comments.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
No new security considerations are addressed by this memo. The memo
reinforces the need for careful consideration and specification of
security issues.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Internationalization Considerations</span>
This memo does not directly have internationalization considerations;
however, it reminds specification authors of the need to consider
internationalization of textual field components.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
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 that 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 ensure that descriptions of registries maintained
by IANA are accurate and meaningful.
<span class="grey">Lilly Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Disclaimers</span>
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 the fact 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.
<span class="grey">Lilly Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
Normative References
[<a id="ref-N1.STD11">N1.STD11</a>] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, <a href="./rfc822">RFC 822</a>, August 1982.
[N2.<a href="./rfc2822">RFC2822</a>] Resnick, P., "Internet Message Format", <a href="./rfc2822">RFC 2822</a>, April
2001.
[N3.<a href="./rfc2045">RFC2045</a>] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", <a href="./rfc2045">RFC 2045</a>, November 1996.
[N4.<a href="./rfc2046">RFC2046</a>] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC</a>
<a href="./rfc2046">2046</a>, November 1996.
[<a id="ref-N5.BCP9">N5.BCP9</a>] Bradner, S., "The Internet Standards Process --
Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
[<a id="ref-N6.BCP90">N6.BCP90</a>] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", <a href="https://www.rfc-editor.org/bcp/bcp90">BCP 90</a>, <a href="./rfc3864">RFC</a>
<a href="./rfc3864">3864</a>, September 2004.
[N7.<a href="./rfc4234">RFC4234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
[<a id="ref-N8.CKLIST">N8.CKLIST</a>] "Checklist for Internet-Drafts (IDs) submitted for RFC
publication", <a href="http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Checklist.html</a>.
[<a id="ref-N9.BCP26">N9.BCP26</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC</a>
<a href="./rfc2434">2434</a>, October 1998.
[<a id="ref-N10.BCP82">N10.BCP82</a>] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", <a href="https://www.rfc-editor.org/bcp/bcp82">BCP 82</a>, <a href="./rfc3692">RFC 3692</a>, January 2004.
[<a id="ref-N11.BCP18">N11.BCP18</a>] Alvestrand, H., "IETF Policy on Character Sets and
Languages", <a href="https://www.rfc-editor.org/bcp/bcp18">BCP 18</a>, <a href="./rfc2277">RFC 2277</a>, January 1998.
[N12.<a href="./rfc2223">RFC2223</a>] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", <a href="./rfc2223">RFC 2223</a>, October 1997.
Informative References
[<a id="ref-I1.FYI18">I1.FYI18</a>] Malkin, G., "Internet Users' Glossary", FYI 18, <a href="./rfc1983">RFC</a>
<a href="./rfc1983">1983</a>, August 1996.
<span class="grey">Lilly Informational [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
[I2.<a href="./rfc2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[I3.<a href="./rfc3282">RFC3282</a>] Alvestrand, H., "Content Language Headers", <a href="./rfc3282">RFC 3282</a>,
May 2002.
[I4.<a href="./rfc2369">RFC2369</a>] Neufeld, G. and J. Baer, "The Use of URLs as Meta-
Syntax for Core Mail List Commands and their Transport
through Message Header Fields", <a href="./rfc2369">RFC 2369</a>, July 1998.
[I5.<a href="./rfc2919">RFC2919</a>] Chandhok, R. and G. Wenger, "List-Id: A Structured
Field and Namespace for the Identification of Mailing
Lists", <a href="./rfc2919">RFC 2919</a>, March 2001.
[I6.<a href="./rfc886">RFC886</a>] Rose, M., "Proposed standard for message header
munging", <a href="./rfc886">RFC 886</a>, December 1983.
[I7.<a href="./rfc3798">RFC3798</a>] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", <a href="./rfc3798">RFC 3798</a>, May 2004.
[I8.<a href="./rfc3297">RFC3297</a>] Klyne, G., Iwazaki, R., and D. Crocker, "Content
Negotiation for Messaging Services based on Email", <a href="./rfc3297">RFC</a>
<a href="./rfc3297">3297</a>, July 2002.
[I9.<a href="./rfc2156">RFC2156</a>] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and <a href="./rfc822">RFC 822</a>/MIME", <a href="./rfc2156">RFC 2156</a>,
January 1998.
[I10.<a href="./rfc3464">RFC3464</a>] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", <a href="./rfc3464">RFC 3464</a>,
January 2003.
[I11.<a href="./rfc987">RFC987</a>] Kille, S., "Mapping between X.400 and <a href="./rfc822">RFC 822</a>", <a href="./rfc987">RFC</a>
<a href="./rfc987">987</a>, June 1986.
[<a id="ref-I12.Errata">I12.Errata</a>] RFC-Editor errata page,
<a href="https://www.rfc-editor.org/errata.html">http://www.rfc-editor.org/errata.html</a>
[I13.<a href="./rfc2533">RFC2533</a>] Klyne, G., "A Syntax for Describing Media Feature
Sets", <a href="./rfc2533">RFC 2533</a>, March 1999.
[I14.<a href="./rfc3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, <a href="./rfc3986">RFC 3986</a>, January 2005.
[I15.<a href="./rfc1958">RFC1958</a>] Carpenter, B., "Architectural Principles of the
Internet", <a href="./rfc1958">RFC 1958</a>, June 1996.
<span class="grey">Lilly Informational [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
[I16.<a href="./rfc3692">RFC3692</a>] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", <a href="https://www.rfc-editor.org/bcp/bcp82">BCP 82</a>, <a href="./rfc3692">RFC 3692</a>, January 2004.
[I17.<a href="./rfc2047">RFC2047</a>] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", <a href="./rfc2047">RFC 2047</a>, November 1996.
[I18.<a href="./rfc2231">RFC2231</a>] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages, and
Continuations", <a href="./rfc2231">RFC 2231</a>, November 1997.
[<a id="ref-I19.Syntax">I19.Syntax</a>] Carpenter, B., "Syntax for format definitions",
<a href="http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt">http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt</a>
[<a id="ref-I20.Arch">I20.Arch</a>] Crocker, D., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Internet+Mail+Architecture%22'>"Internet Mail Architecture"</a>, Work in
Progress, March 2005.
[<a id="ref-I21.BCP72">I21.BCP72</a>] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", <a href="https://www.rfc-editor.org/bcp/bcp72">BCP 72</a>, <a href="./rfc3552">RFC 3552</a>,
July 2003.
Author's Address
Bruce Lilly
EMail: [email protected]
<span class="grey">Lilly Informational [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4249">RFC 4249</a> Specification of Header Fields January 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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
[email protected].
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lilly Informational [Page 14]
Annotations
Select text to annotate