Network Working Group B. Lilly
Internet Draft January 2005
Expires: July 14, 2005
Implementer-friendly Specification of Message and MIME-Part
Header Fields and Field Components
draft-lilly-field-specification-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667 [BCP78]. By submitting this Internet-Draft,
the author represents that any applicable patent or other IPR claims
of which he is aware have been or will be disclosed, and any of which
he become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>.
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright Notice
Copyright(C)The Internet Society (2005).
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.
1. Introduction
Internet messages consist of a message header and a body [STD11],
[RFC2822]. MIME content begins with a MIME-part header [RFC2045],
[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
Lilly Expires July 14, 2005 [Page 1]
Internet Draft Specification of Header Fields January 2005
implementers make assumptions in the absence of specifications. This
memo identifies items of potential interest to implementers and
section 4 of this memo may serve as a checklist for specifications of
extension fields and field components.
2. Requirement Levels
The key words "SHOULD", and "SHOULD NOT", in this document are to be
interpreted as described in [BCP14].
3. Scope
This memo is intended to supplement various specifications,
guidelines, and procedures for specification of header fields
[STD11], [BCP9], [RFC2045], [RFC2046], [RFC2822], [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.
4. Specification Items
4.1. Established Conventions
A number of conventions exist for naming and specifying header
fields. It would be unwise to specify a field which conflicts with
those conventions.
4.1.1. Naming Conventions
Several conventions have been established for naming of header
fields.
4.1.1.1. Resent- prefix
Field names beginning with "Resent-" have particular semantics as
given in [STD11] and [RFC2822]. 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.
4.1.1.2. Content- prefix
Field names beginning with "Content-" are MIME extension fields
[RFC2045]. This prefix SHOULD be used for all MIME extension fields
and SHOULD NOT be used for fields which are not MIME extension
fields.
4.2. Common Specification Items
Several items are specified for standard header fields; these items
should also be specified for extension fields.
Lilly Expires July 14, 2005 [Page 2]
Internet Draft Specification of Header Fields January 2005
4.2.1. ABNF
[STD11] is vague about where whitespace is permitted or required in
header field syntax. [RFC2822] addresses that issue by defining
grammar productions such as FWS and CFWS. Extension field ABNF
SHOULD clearly specify where comments, line folding, and whitespace
are prohibited and permitted, and SHOULD use the RFC 2822 grammar
productions in ABNF for that purpose.
All ABNF should be carefully checked for ambiguities and to ensure
that all productions resolve to some combination of terminal
productions provided by a normative reference. [RFC2234] 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 [Errata].
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 [RFC1958]. Keywords
are typically registered by IANA; a specification using registered
keywords SHOULD include an IANA considerations section, and SHOULD
indicate to readers of the specification precisely where IANA has set
up the registry (authors 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).
Provision may be made for experimental or private-use keywords.
These typically begin with a case-insensitive "x-" prefix. Note that
[BCP82] has specific considerations for use of experimental keywords.
If some field content is to be considered human-readable text, there
should be provision for specifying language in accordance with
[BCP18]. Header fields typically use the mechanism specified in
[RFC2047] as amended by [RFC2231] and [Errata] for that purpose.
Note, however, that that mechanism applies only 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 [BCP18].
4.2.2. Minimum and Maximum Instances per Header
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. RFC 2822 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.
Lilly Expires July 14, 2005 [Page 3]
Internet Draft Specification of Header Fields January 2005
4.2.3. Categorization
RFC 2822 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.
4.3. Semantics
In addition to specifying syntax of a field, a specification document
should indicate the semantics of each field. Such semantics are
comprised of several aspects:
4.3.1. Producers, Modifiers, and Consumers
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 [Crocker04].
Other fields comprise trace information which 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.
4.3.2. What's it All About?
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.
4.3.3. Context
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 as well as message
headers, still others might appear in specialized MIME media types.
4.4. Overall Considerations
Several factors should be considered regarding how a field interacts
with the Internet at large, with the applications for which it is
intended, and in interacting with other applications.
4.4.1. Security
Every specification is supposed to include a carefully-considered
Security Considerations section [RFC2223].
4.4.2. Backwards Compatibility
There is a large deployed base of applications which use header
fields. Implementations that comprise that deployed base may change
very slowly. It is therefore critically important to consider 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
Lilly Expires July 14, 2005 [Page 4]
Internet Draft Specification of Header Fields January 2005
or field component, might not be recognizable to deployed
implementations. Depending on the care with which the authors of an
extension have considered such backwards 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 backwards compatible with the deployed base of
implementations.
There are many subtleties and variations that may come into play.
Authors SHOULD very carefully consider backwards compatibility when
devising extensions, and SHOULD clearly describe all known
compatibility issues.
4.4.3. Compatibility With Legacy Content
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 which lacks that
field or field component.
4.4.4. Interaction With Established Mechanisms
Header fields are handled specially by gateways under various
circumstances. Message fragmentation and reassembly [RFC2046] is one
example. If special treatment is required for a header field under
such circumstances, it SHOULD be clearly specified by the author of
the specification. [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
backwards compatible).
5. Acknowledgments
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.
6. Security Considerations
No new security considerations are addressed by this memo. The memo
reinforces the need for careful consideration of security issues.
Lilly Expires July 14, 2005 [Page 5]
Internet Draft Specification of Header Fields January 2005
7. 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.
8. 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 that registries are set up and properly
referenced at the time of publication of an RFC which 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.
Normative References
[BCP9] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[BCP82] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[Errata] RFC-Editor errata page,
http://www.rfc-editor.org/errata.html
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Lilly Expires July 14, 2005 [Page 6]
Internet Draft Specification of Header Fields January 2005
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[STD11] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
Informative References
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[BCP79] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[Crocker04] Crocker, D., "Internet Mail Architecture", Work in
progress
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
Author's Address
Bruce Lilly
Email: blilly@erols.com
Full Copyright Statement
Copyright(C)The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78 [BCP78],
and except as set forth therein, the author retains all his rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE 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 Statement
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 [BCP78] and BCP 79 [BCP79].
Lilly Expires July 14, 2005 [Page 7]
Internet Draft Specification of Header Fields January 2005
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lilly Expires July 14, 2005 [Page 8]
