summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4249.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4249.txt')
-rw-r--r--doc/rfc/rfc4249.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4249.txt b/doc/rfc/rfc4249.txt
new file mode 100644
index 0000000..ceb0560
--- /dev/null
+++ b/doc/rfc/rfc4249.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group B. Lilly
+Request for Comments: 4249 January 2006
+Category: Informational
+
+
+ Implementer-Friendly Specification of Message and MIME-Part Header
+ Fields and Field Components
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ Implementation of generators and parsers of header fields requires
+ certain information about those fields. Interoperability is most
+ likely when all such information is explicitly provided by the
+ technical specification of the fields. Lacking such explicit
+ information, implementers may guess, and interoperability may suffer.
+ This memo identifies information useful to implementers of header
+ field generators and parsers.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Scope ...........................................................2
+ 3. Specification Items .............................................3
+ 3.1. Established Conventions ....................................3
+ 3.1.1. Standard Terminology ................................3
+ 3.1.2. Naming Rules and Conventions ........................3
+ 3.2. Common Specification Items .................................5
+ 3.2.1. ABNF ................................................5
+ 3.2.2. Minimum and Maximum Instances of Fields per Header ..6
+ 3.2.3. Categorization ......................................7
+ 3.3. Semantics ..................................................7
+ 3.3.1. Producers, Modifiers, and Consumers .................7
+ 3.3.2. What's it all about? ................................7
+ 3.3.3. Context .............................................7
+ 3.4. Overall Considerations .....................................7
+ 3.4.1. Security ............................................8
+ 3.4.2. Backward Compatibility ..............................8
+ 3.4.3. Compatibility With Legacy Content ...................8
+
+
+
+Lilly Informational [Page 1]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+ 3.4.4. Interaction With Established Mechanisms .............9
+ 4. Acknowledgements ................................................9
+ 5. Security Considerations .........................................9
+ 6. Internationalization Considerations .............................9
+ 7. IANA Considerations .............................................9
+ Appendix A. Disclaimers ...........................................10
+ Normative References ..............................................11
+ Informative References ............................................11
+
+1. Introduction
+
+ Internet messages consist of a message header and a body [N1.STD11],
+ [N2.RFC2822]. MIME content begins with a MIME-part header
+ [N3.RFC2045], [N4.RFC2046]. Message headers and MIME-part headers
+ consist of fields. While the Message Format and MIME specifications
+ define their respective overall formats and some specific fields,
+ they also have provision for extension fields. A number of extension
+ fields have been specified, some more or less completely than others.
+ Incomplete or imprecise specification has led to interoperability
+ problems as implementers make assumptions in the absence of
+ specifications. This memo identifies items of potential interest to
+ implementers, and section 3 of this memo may serve as an
+ informational guide for authors of specifications of extension fields
+ and field components.
+
+2. Scope
+
+ This memo is intended as a non-binding informational supplement to
+ various specifications, guidelines, and procedures for specification
+ of header fields [N1.STD11], [N2.RFC2822], [N3.RFC2045],
+ [N4.RFC2046], [N5.BCP9], [N6.BCP90]. It does not absolve authors of
+ header field specifications from compliance with any provisions of
+ those or other specifications, guidelines, and procedures. It offers
+ clarification and supplementary suggestions that will promote
+ interoperability and may spare specification authors many questions
+ regarding incomplete header field specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 2]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+3. Specification Items
+
+3.1. Established Conventions
+
+ A number of conventions exist for naming and specifying header
+ fields. It would be unwise and confusing to specify a field that
+ conflicts with those conventions.
+
+3.1.1. Standard Terminology
+
+ Terms related to the Internet Message Format are defined 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" [I1.FYI18], [N2.RFC2822] 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.
+
+3.1.2. Naming Rules and Conventions
+
+ Several rules and conventions have been established for naming of
+ header fields. Rules are codified in published RFCs; conventions
+ reflect common use.
+
+3.1.2.1. Naming Rules
+
+ Some RFCs define a particular prefix, reserving use of that prefix
+ for specific purposes.
+
+3.1.2.1.1. Content- prefix rule
+
+ This prefix must be used for all MIME extension fields and must not
+ be used for fields that are not MIME extension fields [N3.RFC2045]
+ (section 9).
+
+3.1.2.1.2. Resent- prefix rule
+
+ Specified for certain standard fields as given in [N1.STD11] (also
+ used by [N2.RFC2822], 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.
+
+
+
+
+Lilly Informational [Page 3]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+3.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.
+
+3.1.2.2.1. Accept- prefix convention
+
+ This prefix should be used for all extension fields intended for use
+ in content negotiation [I2.RFC2616] and should not be used for fields
+ that are not intended for such use. An example may be found in
+ [I3.RFC3282].
+
+3.1.2.2.2. List- prefix convention
+
+ Used to indicate information about mailing lists when a list
+ expansion takes place. Examples of defined fields can be found in
+ [I4.RFC2369] and [I5.RFC2919].
+
+3.1.2.2.3. Illegal- prefix convention
+
+ This prefix provides a record of illegal content in a field when
+ fields are transformed at a gateway [I6.RFC886].
+
+3.1.2.2.4. Disposition-Notification- prefix convention
+
+ Specification of information used in conjunction with Message
+ Disposition Notifications (MDNs) [I7.RFC3798].
+
+3.1.2.2.5. Original- prefix convention
+
+ Used to reference some content from a related message. Examples
+ include Original-Message-ID as 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
+
+ Specifies a host that generated a type of report, such as those
+ defined in [I7.RFC3798], [I10.RFC3464].
+
+3.1.2.2.7. X400- prefix convention
+
+ Used in conversion from X.400 environments by gateways [I9.RFC2156].
+
+3.1.2.2.8. Discarded-X400- prefix convention
+
+ Also used by gateways from X.400 [I9.RFC2156].
+
+
+
+Lilly Informational [Page 4]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+3.1.2.2.9. P1- prefix convention
+
+ Was used by X.400 gateways [I11.RFC987].
+
+3.1.2.2.10. Delivery-Report-Content- prefix convention
+
+ Also used by legacy X.400 gateways [I11.RFC987].
+
+3.2. Common Specification Items
+
+ Several items are specified for standard header fields; these items
+ should also be specified for extension fields.
+
+3.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 [N7.RFC4234] and in accordance with the necessity
+ for specificity of such issues as noted in section 3.1 of
+ [N7.RFC4234]. 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 [N8.CKLIST] ("All ABNF must be
+ checked"). [N7.RFC4234] 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 [I12.Errata].
+
+ 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), [I13.RFC2533] feature sets (which also use parentheses
+ as delimiters, but not for comments), and [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 indicate to readers of the
+ specification precisely where IANA has set up the registry (authors
+
+
+
+Lilly Informational [Page 5]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+ 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
+ [N10.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
+ [N11.BCP18] (section 4.2). Header fields typically use the mechanism
+ specified in [I17.RFC2047] as amended by [I18.RFC2231] and
+ [I12.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 [N11.BCP18] (section 6).
+
+ 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.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 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
+
+
+
+Lilly Informational [Page 6]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+ 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). Such categories have implications for processing
+ and handling of fields. A specification author should indicate any
+ applicable categories.
+
+3.3. Semantics
+
+ 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:
+
+3.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 [I20.Arch].
+ 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.
+
+3.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.
+
+3.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 [N4.RFC2046] as well
+ as message headers, still others might appear in specialized MIME
+ media types.
+
+3.4. Overall Considerations
+
+ 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.
+
+
+
+
+
+Lilly Informational [Page 7]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+3.4.1. Security
+
+ Every specification is supposed to include a carefully-considered
+ Security Considerations section [N12.RFC2223] (section 9),
+ [I21.BCP72].
+
+3.4.2. Backward Compatibility
+
+ 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.
+
+3.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 that lacks that field
+ or field component. Any such semantics should be explicitly
+ specified.
+
+
+
+
+
+
+
+Lilly Informational [Page 8]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+3.4.4. Interaction With Established Mechanisms
+
+ Header fields are handled specially by gateways under various
+ circumstances, e.g., message fragmentation and reassembly
+ [N4.RFC2046]. If special treatment is required for a header field
+ under such circumstances, it should be clearly specified by the
+ author of the specification. [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 acknowledge the helpful comments provided by
+ members of the ietf-822 mailing list. In particular, Peter Koch and
+ Keith Moore have made useful comments.
+
+5. Security Considerations
+
+ No new security considerations are addressed by this memo. The memo
+ reinforces the need for careful consideration and specification of
+ security issues.
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 9]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 10]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+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.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
+
+ [I1.FYI18] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
+ 1983, August 1996.
+
+
+
+
+
+Lilly Informational [Page 11]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+ [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.
+
+
+
+Lilly Informational [Page 12]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 13]
+
+RFC 4249 Specification of Header Fields January 2006
+
+
+Full Copyright Statement
+
+ 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.
+
+ 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Lilly Informational [Page 14]
+