[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4249

Network Working Group                                           B. Lilly
Internet-Draft                                                  May 2005
Intended status: Informational
Expires: November 3, 2005

   Implementer-friendly Specification of Message and MIME-Part Header
                      Fields and Field Components
                   draft-lilly-field-specification-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   Discussion of this document should take place on the ietf-822 mailing
   list.









Lilly                   Expires November 3, 2005                [Page 1]

Internet-Draft       Specification of Header Fields             May 2005

Table of Contents

   1. Introduction...................................................  3
   2. Requirement Levels.............................................  3
   3. Scope..........................................................  3
   4. Specification Items............................................  3
      4.1. Established Conventions...................................  3
         4.1.1. Standard Terminology.................................  3
         4.1.2. Naming Rules and Conventions.........................  4
      4.2. Common Specification Items................................  5
         4.2.1. ABNF.................................................  5
         4.2.2. Minimum and Maximum Instances of Fields per Header...  7
         4.2.3. Categorization.......................................  7
      4.3. Semantics.................................................  7
         4.3.1. Producers, Modifiers, and Consumers..................  7
         4.3.2. What's it All About?.................................  7
         4.3.3. Context..............................................  7
      4.4. Overall Considerations....................................  8
         4.4.1. Security.............................................  8
         4.4.2. Backwards Compatibility..............................  8
         4.4.3. Compatibility With Legacy Content....................  8
         4.4.4. Interaction With Established Mechanisms..............  8
         4.4.5. Architectural Considerations.........................  9
   5. Acknowledgments................................................  9
   6. Security Considerations........................................  9
   7. Internationalization Considerations............................  9
   8. IANA Considerations............................................  9
   Appendix A. Disclaimers...........................................  9
   Appendix B. Change History........................................ 10
   Normative References.............................................. 11
   Informative References............................................ 12
   Author's Address.................................................. 13























Lilly                   Expires November 3, 2005                [Page 2]

Internet-Draft       Specification of Header Fields             May 2005

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 4 of this memo may serve as a checklist for
   specifications of extension fields and field components.

2. Requirement Levels

   The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT", in this
   document are to be interpreted as described in [N5.BCP14].

3. Scope

   This memo is intended to supplement various specifications,
   guidelines, and procedures for specification of header fields
   [N1.STD11], [N2.RFC2822], [N3.RFC2045], [N4.RFC2046], [N6.BCP9],
   [N7.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 and confusing to specify a field which
   conflicts with those conventions.

4.1.1. Standard Terminology

   Terms related to the Internet Message Format are defined in
   [N2.RFC2822].  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" 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.RFC2046] 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.


Lilly                   Expires November 3, 2005                [Page 3]

Internet-Draft       Specification of Header Fields             May 2005

4.1.2. Naming Rules and Conventions

   Several rules and conventions have been established for naming of
   header fields.

4.1.2.1. Naming Rules

   Some RFCs define a particular prefix, reserving use of that prefix
   for specific purposes.

4.1.2.1.1. Content- prefix

   This prefix MUST be used for all MIME extension fields and MUST NOT
   be used for fields which are not MIME extension fields [N3.RFC2045].

4.1.2.1.2. Resent- prefix

   Specified for certain standard fields as given in [N1.STD11] (also
   used by [N2.RFC2822], although not specifed 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.

4.1.2.2. Naming Conventions

   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.

4.1.2.2.1. Accept- prefix

   This prefix SHOULD be used for all extension fields intended for use
   in content negotiation [I1.RFC2295] and SHOULD NOT be used for fields
   which are not intended for such use.

4.1.2.2.2. List- prefix

   Used to indicate information about mailing lists when a list
   expansion takes place.  Examples of defined fields can be found in
   [I2.RFC2369] and [I3.RFC2919].

4.1.2.2.3. Illegal- prefix

   This prefix provides a record of illegal content in a field when
   fields are transformed at a gateway [I4.RFC886].

4.1.2.2.4. Disposition-Notification- prefix

   Specification of information used in conjunction with Message
   Disposition Notifications (MDNs) [I5.RFC3798].





Lilly                   Expires November 3, 2005                [Page 4]

Internet-Draft       Specification of Header Fields             May 2005

4.1.2.2.5. Original- prefix

   Used to reference some content from a related message.  Examples
   include Original-Message-ID as used by [I6.RFC3297] and [I5.RFC3798],
   Original-Encoded-Information-Types [I7.RFC2156], Original-Envelope-ID
   [I8.RFC3464], and Original-Recipient [I5.RFC3798].

4.1.2.2.6. Reporting- prefix

   Specifies a host that generated a type of report, such as those
   defined in [I5.RFC3798], [I8.RFC3464].

4.1.2.2.7. X400- prefix

   Used in conversion from X.400 environments by gateways [I7.RFC2156].

4.1.2.2.8. Discarded-X400- prefix

   Also used by gateways from X.400 [I7.RFC2156].

4.1.2.2.9. P1- prefix

   Was used by X.400 gateways [I9.RFC987].

4.1.2.2.10. Delivery-Report-Content- prefix

   Also used by legacy X.400 gateways [I9.RFC987]

4.2. Common Specification Items

   Several items are specified for standard header fields; these items
   SHOULD also be specified for extension fields.

4.2.1. ABNF

   [N1.STD11] is vague about where whitespace is permitted or required
   in header field syntax.  [N2.RFC2822] addresses that issue by
   defining grammar productions such as FWS and CFWS, in conjunction
   with formal ABNF [N8.RFC2234] and in accordance with the necessity
   for specificity of such issues as noted in section 3.1 of
   [N8.RFC2234].  Extension field ABNF SHOULD clearly specify where
   comments, line folding, and whitespace are prohibited and permitted,
   and SHOULD use the [N2.RFC2822] 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 [N9.CKLIST].  [N8.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 [I10.Errata].



Lilly                   Expires November 3, 2005                [Page 5]

Internet-Draft       Specification of Header Fields             May 2005

   Authors and designers should be careful not to mix syntax with
   disparate semantics within a single field.  Examples of disparate
   semantics are [N2.RFC2822] comments (which use parentheses as
   delimiters), [I11.RFC2533] feature sets (which also use parentheses
   as delimiters, but not for comments), and [I12.RFC3986] 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 [I13.RFC1958].
   Keywords are typically registered by IANA; a specification using
   registered keywords MUST include an IANA considerations section
   [N10.BCP26], [I14.RFC3692], 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).

   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
   [N11.BCP82] 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
   [N12.BCP18].  Header fields typically use the mechanism specified in
   [I15.RFC2047] as amended by [I16.RFC2231] and [I10.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 [N12.BCP18].

   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.



Lilly                   Expires November 3, 2005                [Page 6]

Internet-Draft       Specification of Header Fields             May 2005

4.2.2. Minimum and Maximum Instances of Fields 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.  [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.

4.2.3. Categorization

   [N2.RFC2822] 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 [I17.Crocker05].
   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.

   Internet Message Format [N1.STD11], [N2.RFC2822] message header
   fields are generally part of an end-to-end protocol [I13.RFC1958].
   It is inappropriate to define new message header fields to affect the
   behavior of message transport.  It may, however, be appropriate to
   define new message header fields to affect transport layer components
   which have application layer functions (with authorization from the
   originator or recipient), such as format conversion or content
   filtering mechanisms.

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.


Lilly                   Expires November 3, 2005                [Page 7]

Internet-Draft       Specification of Header Fields             May 2005

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 [N13.RFC2223], [I18.BCP72].

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
   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 [N4.RFC2046] is
   one example.  If special treatment is required for a header field

Lilly                   Expires November 3, 2005                [Page 8]

Internet-Draft       Specification of Header Fields             May 2005

   under such circumstances, it SHOULD be clearly specified by the
   author of the specification.  [I5.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).

4.4.5. Architectural Considerations

   Messages are long-lived; many are archived for decades, and may be
   read at any time.  Messages may be read in an off-line environment.
   Header field content other than address fields SHOULD NOT rely on
   availability of DNS [I19.RFC1034], [I20.RFC1035] or similar
   distributed databases for interpretation of field body content.  DNS
   records are ephemeral; domains come and go frequently, and DNS
   records are subject to change at any time.  DNS is only available to
   applications when online; consequently it is unavailable when
   messages are being read offline.

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.

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.

Appendix A. Disclaimers

   This document has exactly one (1) author.





Lilly                   Expires November 3, 2005                [Page 9]

Internet-Draft       Specification of Header Fields             May 2005

   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 "or she", "/SHE", "each", "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.


Appendix B. Change History

   [[This change history will not be part of a published RFC]]

   -02 to -03 (Last Call comments and final tweaks)

      o  added suggested discussion forum to Abstract

      o  replaced two instances of naked RFC 2822 with reference tags

      o  separated prefix discussion into standardized prefixes and mere
         conventions

      o  clarified requirements for standardized prefixes, with
         references

      o  added several conventional prefixes

      o  clarified specificity of CFWS specification as noted in RFC
         2234

      o  updated date in reference to Crocker mail architecture draft

      o  clarified purpose of message header fields

      o  added disclaimers of boilerplate silliness, etc.

   -01 to -02

      o  added this change history

      o  added text regarding Accept- prefix

      o  added paragraph about mixed semantics within a field

      o  added paragraph regarding initial establishment of keyword
         registry

      o  added paragraph about numerical value semantics

Lilly                   Expires November 3, 2005               [Page 10]

Internet-Draft       Specification of Header Fields             May 2005

      o  updated references

      o  Internationalization Considerations section is emphasized to
         correspond to RFC 2277

      o  revised boilerplate

   -00 to -01

      o  revised reference numbering scheme

      o  updated Requirement Levels text to correspond to text changes

      o  added "and confusing" to introductory text re. Established
         Conventions

      o  Added paragraph about standard terminology

      o  (RFC 2119) emphasis added for common specification items text

      o  minor wording changes

      o  changed ABNF checking to a requirement

      o  IANA Considerations section is a requirement if keywords are
         registered

      o  provision for specifying language of text is a requirement

      o  added architectural considerations regarding DNS etc.

Normative References

   [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.BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [N6.BCP9]     Bradner, S., "The Internet Standards Process --
                 Revision 3", BCP 9, RFC 2026, October 1996.



Lilly                   Expires November 3, 2005               [Page 11]

Internet-Draft       Specification of Header Fields             May 2005

   [N7.BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
                 Procedures for Message Header Fields", BCP 90,
                 RFC 3864, September 2004.

   [N8.RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", RFC 2234, November 1997.

   [N9.CKLIST]   "Checklist for Internet-Drafts (IDs) submitted for RFC
                 publication", http://www.ietf.org/ID-Checklist.html

   [N10.BCP26]   Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26,
                 RFC 2434, October 1998.

   [N11.BCP82]   Narten, T., "Assigning Experimental and Testing Numbers
                 Considered Useful", BCP 82, RFC 3692, January 2004.

   [N12.BCP18]   Alvestrand, H., "IETF Policy on Character Sets and
                 Languages", BCP 18, RFC 2277, January 1998.

   [N13.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
                 Authors", RFC 2223, October 1997.

Informative References

   [I1.RFC2295]    Holtman, K. and A. Mutz, "Transparent Content
                   Negotiation in HTTP", RFC 2295, March 1998.

   [I2.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.

   [I3.RFC2919]    Chandhok, R. and G. Wenger, "List-Id: A Structured
                   Field and Namespace for the Identification of Mailing
                   Lists", RFC 2919, March 2001.

   [I4.RFC886]     Rose, M., "Proposed standard for message header
                   munging", RFC 886, December 1983.

   [I5.RFC3798]    Hansen, T. and G. Vaudreuil, "Message Disposition
                   Notification", RFC 3798, May 2004.

   [I6.RFC3297]    Klyne, G., Iwazaki, R., and D. Crocker, "Content
                   Negotiation for Messaging Services based on Email",
                   RFC 3297, July 2002.

   [I7.RFC2156]    Kille, S., "MIXER (Mime Internet X.400 Enhanced
                   Relay): Mapping between X.400 and RFC 822/MIME",
                   RFC 2156, January 1998.

   [I8.RFC3464]    Moore, K. and G. Vaudreuil, "An Extensible Message
                   Format for Delivery Status Notifications", RFC 3464,
                   January 2003.

Lilly                   Expires November 3, 2005               [Page 12]

Internet-Draft       Specification of Header Fields             May 2005

   [I9.RFC987]     Kille, S., "Mapping between X.400 and RFC 822",
                   RFC 987, June 1986.

   [I10.Errata]    RFC-Editor errata page,
                   http://www.rfc-editor.org/errata.html

   [I11.RFC2533]   Klyne, G., "A Syntax for Describing Media Feature
                   Sets", RFC 2533, March 1999.

   [I12.RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter,
                   "Uniform Resource Identifier (URI): Generic Syntax",
                   STD 66, RFC 3986, January 2005.

   [I13.RFC1958]   Carpenter, B., "Architectural Principles of the
                   Internet", RFC 1958, June 1996.

   [I14.RFC3692]   Narten, T., "Assigning Experimental and Testing
                   Numbers Considered Useful", BCP 82, RFC 3692, January
                   2004.

   [I15.RFC2047]   Moore, K., "MIME (Multipurpose Internet Mail
                   Extensions) Part Three: Message Header Extensions for
                   Non-ASCII Text ", RFC 2047, November 1996.

   [I16.RFC2231]   Freed, N. and K. Moore, "MIME Parameter Value and
                   Encoded Word Extensions: Character Sets, Languages,
                   and Continuations", RFC 2231, November 1997.

   [I17.Crocker05] Crocker, D., "Internet Mail Architecture", Work in
                   progress (March 2005).

   [I18.BCP72]     Rescorla, E. and B. Korver, "Guidelines for Writing
                   RFC Text on Security Considerations", BCP 72,
                   RFC 3552, July 2003.

   [I19.RFC1034]   Mockapetris, P., "Domain names - concepts and
                   facilities", STD 13, RFC 1034, November 1987.

   [I20.RFC1035]   Mockapetris, P., "Domain names - implementation and
                   specification", STD 13, RFC 1035, November 1987.

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, and except as set forth therein, the authors
   retain all their rights.

Lilly                   Expires November 3, 2005               [Page 13]

Internet-Draft       Specification of Header Fields             May 2005

   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 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 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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Lilly                   Expires November 3, 2005               [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/