Usenet Format Working Group K. Murchison, Ed. Internet-Draft Carnegie Mellon University Obsoletes: 1036 (if approved) C. Lindsey Expires: June 19, 2006 University of Manchester D. Kohn Skymoon Ventures December 16, 2005 Netnews Article Format draft-ietf-usefor-usefor-06 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. This Internet-Draft will expire on June 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the syntax of network news (Netnews) articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document supersedes RFC 1036, updating it to reflect current practice and incorporating incremental changes specified in other documents. Murchison, et al. Expires June 19, 2006 [Page 1] Internet-Draft Netnews Article Format December 2005 Note to the RFC Editor The normative reference to RFC 2234 and the informative reference to RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and draft-ietf-nntpext-base respectively should one or both of those of those documents reach RFC status before this one. Changes since draft-ietf-usefor-usefor-05 o Resolved ticket #1003 (msg-id). o Resolved ticket #1021 (Newsgroups description and exceptions). o Resolved ticket #1028 (fixed ABNF for orig-date). o Began adding text for ticket #1032 (diff from RFC 1036). o Resolved ticket #1046 (MIME boundary security considerations). o Addressed ticket #1047 (Path header field delimiters and components) using Harald's suggested text -- Still an open issue. o Resolved ticket #1052 (diffs from RFC 2822). o Resolved ticket #1053 (relationship to RFC 2822). o Resolved ticket #1079 (header fields which don't permit CFWS). o Applied text from ticket #1080 (Injection-Info MIME params). o Resolved ticket #1082 (Approved header field semantics). o Resolved ticket #1088 (Injection-Date mandatory/optional). o Resolved ticket #1102 (Definition of "agents", etc). o Removed RFC 0821 as a normative reference. o Miscellaneous editorial changes. Changes since draft-ietf-usefor-usefor-04 o Resolved ticket #1002 (updated references). o Applied text from ticket #1003 (ABNF cleanup for msg-id). Murchison, et al. Expires June 19, 2006 [Page 2] Internet-Draft Netnews Article Format December 2005 o Resolved ticket #1004 (deprecate X- headers). o Resolved ticket #1008 (followups & References header field). o Applied text from ticket #1021 (Newsgroups ABNF and description). o Resolved ticket #1022 (obs-phrase). o Applied text from ticket #1028 (GMT timezone for Date). o Applied text from ticket #1042 (Newsgroups folding). o Resolved ticket #1043 (RFC 2822 terms for header fields). o Starting to resolve ticket #1052 (differences from RFC 2822). o Miscellaneous editorial changes. Changes since draft-ietf-usefor-usefor-03 o Reworked ABNFs of several headers. o Used Charles' ABNF for . o Disallowed comments in Supersedes header. o Disallowed comments in Xref header. o Disallowed comments in Message-Id header. o CFWS between msg-ids in References header is not optional. o Compatibility changes based on comments from Charles. o Miscellaneous editorial changes. Changes since draft-ietf-usefor-usefor-02 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) o Changed "network news" to "Netnews" throughout. o Prohibit NO-WS-CTL in msg-id. o Complaints-To header is now an Injection-Info parameter. Murchison, et al. Expires June 19, 2006 [Page 3] Internet-Draft Netnews Article Format December 2005 o Added descriptions of Injection-Info parameters. o Removed "filename" parameter from Archive header. o Added CFWS to User-Agent header. o Miscellaneous editorial changes. Changes since draft-ietf-usefor-usefor-01 o Removed half-hearted discussion of internal format and 8-bit clean transport. o Added definitions of "proto-article", "posting agent", "followup", "followup-agent", "user-agent", and "injecting agent". o Removed discussion of message/partial MIME messages. o Noted that the header contents in every line MUST NOT be empty. o Merged MIME sections. o Only allow "UT" and "GMT" in Date header; disallow all other . o Used Charles' ABNF for and . o Removed restrictions on length and start character for Newsgroups. o More verbose description of Path header. o Disallowed comments in Control header. o Specified that is a verb optionally followed by whitespace-separated arguments. o Noted that Supersedes header is different from [Son-of-1036]. o More exact ABNF for Archive and Injection-Info parameters. o Discussed meaning of "yes", "no" in Archive header. o Added "Obsolete Headers" section. o Miscellaneous editorial changes Murchison, et al. Expires June 19, 2006 [Page 4] Internet-Draft Netnews Article Format December 2005 Changes since draft-ietf-usefor-article-13 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to other documents. o Dropped MIME parameters, as there is no WG consensus (per Chair). o More exact ABNF for Archive and Injection-Info parameters. o Complaints-To header is now an Injection-Info parameter. Issues to be addressed o Ticket #1047: Path header field delimiters and components. o IANA considerations (the Klyne message header registry is now official as RFC 3864)?. o Collected Syntax? o Merge more security issues? o Merge acknowledgments? Murchison, et al. Expires June 19, 2006 [Page 5] Internet-Draft Netnews Article Format December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Structure of This Document . . . . . . . . . . . . . . . . 9 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 10 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 12 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 13 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 17 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 20 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 20 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 21 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 21 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 22 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 23 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 24 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 25 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 27 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Internationalization Considerations . . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Normative References . . . . . . . . . . . . . . . . . . . 31 6.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 Appendix B. Differences from RFC 1036 and its derivatives . . . . 34 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Murchison, et al. Expires June 19, 2006 [Page 6] Internet-Draft Netnews Article Format December 2005 1. Introduction 1.1. Basic Concepts "Netnews" is a set of protocols for generating, storing and retrieving news "articles" (whose format is a subset of that for Email messages) and for exchanging them amongst a readership which is potentially widely distributed. It is organized around "newsgroups", with the expectation that each reader will be able to see all articles posted to each newsgroup in which he participates. These protocols most commonly use a flooding algorithm which propagates copies throughout a network of participating servers. Typically, only one copy is stored per server, and each server makes it available on demand to readers able to access that server. 1.2. Scope This document specifies the syntax of network news (Netnews) articles in the context of the "Internet Message Format" [RFC2822] and "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This document supersedes [RFC1036], updating it to reflect current practice and incorporating changes and clarifications specified in other documents such as [Son-of-1036]. This is the first in a set of documents that obsolete [RFC1036]. This document focuses on the syntax and semantics of Netnews articles. [USEPRO] is also a standards-track document, and describes the protocol issues of Netnews articles, independent of transport protocols such as [NNTP]. A best common practice document, [USEAGE], describes implementation recommendations to improve interoperability and usability. This specification is intended as a definition of what article content format is to be passed between systems. Though some news systems locally store articles in this format (which eliminates the need for translation between formats) and others use formats that differ from the one specified in this standard, local storage is outside of the scope of this standard. 1.3. Requirements Notation This document uses terms that appear in capital letters. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Murchison, et al. Expires June 19, 2006 [Page 7] Internet-Draft Netnews Article Format December 2005 1.4. Syntax Notation Header fields defined in this specification use the Augmented Backus- Naur Form (ABNF) notation (including the Core Rules) specified in [RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. Section 3.1.3 updates the [RFC2822] definition of . The following constructs referenced by this document are defined in [RFC2822]: , , , , , , , , , and . The following constructs referenced by this document are defined in [RFC2045] (as amended by [RFC2231]): , , . 1.5. Definitions An "article" is the unit of news, synonymous with an [RFC2822] "message". A "proto-article" is one that has not yet been injected into the news system. In constrast to an "article", a "proto- article" may lack some mandatory header fields. A "message identifier" (Section 3.1.3) is a unique identifier for an article, usually supplied by the "user agent" which posted it or, failing that, by the "news server". It distinguishes the article from every other article ever posted anywhere. Articles with the same message identifier are treated as if they are the same article regardless of any differences in the body or header fields. A "newsgroup" is a single news forum, a logical bulletin board, having a name and nominally intended for articles on a specific topic. An article is "posted to" a single newsgroup or several newsgroups. When an article is posted to more than one newsgroup, it is said to be "crossposted"; note that this differs from posting the same text as part of each of several articles, one per newsgroup. A newsgroup may be "moderated", in which case submissions are not posted directly, but mailed to a "moderator" for consideration and possible posting. Moderators are typically human but may be implemented partially or entirely in software. A "poster" is the person or software that composes and submits a possibly compliant article to a "user agent". The poster is analogous to [RFC2822]'s author. A "reader" is the person or software reading news articles. A "followup" is an article containing a response to the contents of Murchison, et al. Expires June 19, 2006 [Page 8] Internet-Draft Netnews Article Format December 2005 an earlier article, its "precursor". Every followup includes a "References" header field identifying that precursor (but note that non-followup articles may also use a References header field). A "control message" is an article which is marked as containing control information; a news server receiving such an article may (subject to the policies observed at that site) take actions beyond just filing and passing on the article. A "news server" is software that may accept articles from a "user agent", and/or make articles available to user agents, and/or exchange articles with other news servers. A "user agent" is software that may help posters submit proto- articles to a news server, and/or fetch articles from a news server and present them to a reader, and/or assist the reader in creating articles and followups. The generic term "agent" is used when describing requirements that apply to both user agents and news servers. 1.6. Structure of This Document This document uses a cite by reference methodology, rather than repeating the contents of other standards, which could otherwise result in subtle differences and interoperability challenges. Although this document is as a result rather short, it requires complete understanding and implementation of the normative references to be compliant. Section 2 defines the format of news articles. Section 3 details the header fields necessary to make an article suitable for the Netnews environment. Murchison, et al. Expires June 19, 2006 [Page 9] Internet-Draft Netnews Article Format December 2005 2. Format 2.1. Base An article is said to be conformant to this specification if it conforms to the format specified in [RFC2822] section 3 and to the additional requirements of this specification. An article that uses the obsolete syntax specified in section 4 of [RFC2822], except for the two exceptions mentioned below, is NOT conformant to this specification. Articles are conformant if they use the construct (use of a phrase like "John Q. Public" without the use of quotes, see [RFC2822] section 4.1) but agents MUST NOT generate productions of such syntax. Articles are conformant if they use the "GMT" , as specified in Section 3.1.2. This document, and specifications that build upon it, specifies how to handle conformant articles. Handling of non-conformant articles is outside the scope of this specification. Agents conforming to this specification MUST generate only conformant articles. The text below uses ABNF to specify restrictions on the syntax specified in [RFC2822]; this grammar is intended to be more restrictive than the [RFC2822] grammar. Articles must conform to the ABNF specified in [RFC2822]. Articles must also conform to the restrictions specified here, both those that are expressed as text and those that are expressed as ABNF. NOTE: Older Netnews specifications used the term "header" as a synonym for what [RFC2822] calls "header field". This document follows the terminology in Section 2 of [RFC2822] in using the terms "line", "header field", "header field name", "header field body", and "folding", based on a belief that consistent terminology among specifications that depend on each other makes the specifications easier to use in the long run. 2.2. Header Fields All header fields in a news article are compliant with [RFC2822], however this specification is less permissive in what can be Murchison, et al. Expires June 19, 2006 [Page 10] Internet-Draft Netnews Article Format December 2005 generated and accepted by news agents. The syntax allowed for news articles is a strict subset of the "Internet Message Format", making all messages compliant with this specification inherently compliant with [RFC2822]. Note however that the converse is not guaranteed to be true in all cases. General rules which apply to all header fields (even those documented in [RFC2822] and [RFC2045]) are listed below and those that apply to specific header fields are described in the relevent sections of this document. o All agents MUST generate header fields so that at least one space immediately follows the ':' separating the header field name and the header field body (for compatibility with deployed software, including [NNTP] servers). News agents MAY accept header fields which do not contain the required space. o Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non- whitespace character. NOTE: This means that no header field body defined by or referenced by this document can be empty. As a result, this document updates the construct from Section 3.2.6 of [RFC2822] as follows: unstructured = 1*( [FWS] utext ) [FWS] o Compliant software MUST NOT generate (but MAY accept) header fields of more than 998 octets. This is the only limit on the length of a header field prescribed by this standard. However, specific rules to the contrary may apply in particular cases (for example, according to [RFC2047] lines of a header field containing encoded-words are limited to 76 octets). [USEAGE] includes suggested limits for convenience of display by user agents. NOTE: There is NO restriction on the number of lines into which a header field may be split, and hence there is NO restriction on the total length of a header field (in particular it may, by suitable folding, be made to exceed the 998 octets restriction pertaining to a single header line). o The character set for header fields is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2047] and [RFC2231]. Murchison, et al. Expires June 19, 2006 [Page 11] Internet-Draft Netnews Article Format December 2005 2.3. MIME Conformance User agents MUST meet the definition of MIME-conformance in [RFC2049] and MUST also support [RFC2231]. This level of MIME Conformance provides support for internationalization and multimedia in message bodies ([RFC2045], [RFC2046], [RFC2231]), and support for internationalization of header fields ([RFC2047], [RFC2231]). Note that [Errata] currently exist for [RFC2046] and [RFC2231]. For the purposes of Section 5 of [RFC2047], all header fields defined in Section 3 of this standard are to be considered as "extension message header fields" (insofar as they are not already so considered under the existing Email standards), permitting the use of [RFC2047] encodings within any header field, or within any or permittted within any structured header field. User agents MAY accept and generate other MIME extension header fields, and in particular SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282]. Murchison, et al. Expires June 19, 2006 [Page 12] Internet-Draft Netnews Article Format December 2005 3. News Header Fields The following news header fields extend those defined in section 3.6 of [RFC2822]: fields =/ *( newsgroups / path / injection-date / followup-to / expires / control / supersedes / distribution / summary / approved / organization / xref / archive / user-agent / injection-info ) Each of these header fields may occur at most once in a news article. The following header fields defined in this document do not allow comments (CFWS): Newsgroups Path Followup-to Control Supersedes Distribution Xref Lines This also applies to the following header field defined in [RFC2822]: Message-ID Several of these headers are mainly of interest to servers, and servers often need to process these fields very rapidly. 3.1. Mandatory Header Fields Each news article conformant with this specification MUST have exactly one of each of the following header fields: From, Date, Message-ID, Subject, Newsgroups, Path. Murchison, et al. Expires June 19, 2006 [Page 13] Internet-Draft Netnews Article Format December 2005 3.1.1. From The From header field is the same as that specified in Section 3.6.2 of [RFC2822] with the added restrictions detailed in Section 2.2. from = "From:" SP mailbox-list CRLF 3.1.2. Date The Date header field is the same as that specified in Sections 3.3 and 3.6.1 of [RFC2822] with the added restrictions detailed in Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in news articles today. Therefore, agents MUST accept constructs which use the "GMT" zone. orig-date = "Date:" SP date-time CRLF NOTE: This specification does not change [RFC2822], which says that agents MUST NOT generate constructs which include any zone names defined by . Software that accepts dates with unknown timezones SHOULD treat such timezones as equivalent to "-0000" when comparing dates, as specified in [RFC2822] section 4.3. Also note that these requirements apply wherever is used, including Injection-Date and Expires in Section 3.2.1 and Section 3.2.4 respectively. 3.1.3. Message-ID The Message-ID header field contains a single unique message identifier. Netnews is more dependent on message identifier uniqueness and fast comparison than Email is, and some news software and standards [RFC0977] might have trouble with the full range of possible s permitted by [RFC2822]; this section therefore restricts the syntax of as compared to Section 3.6.4 of [RFC2822]. The global uniqueness requirement for in [RFC2822] is to be understood as applying across all protocols using such message identifiers, and across both Email and Netnews in particular. Murchison, et al. Expires June 19, 2006 [Page 14] Internet-Draft Netnews Article Format December 2005 message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF msg-id = "<" id-left "@" id-right ">" ; maximum length is 250 octets id-left = dot-atom-text / no-fold-quote id-right = dot-atom-text / no-fold-literal no-fold-quote = DQUOTE ( "." *mqtext / *mqtext "." / *mqtext mqspecial *mqtext ) DQUOTE mqtext = atext / "." / mqspecial mqspecial = "(" / ")" / ; same as specials except "<" / ; "\" and DQUOTE quoted "[" / "]" / ; "." doubled and ">" omitted ":" / ";" / "@" / "," / ".." / "\\" / "\" DQUOTE no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" mdtext = %d33-61 / ; The rest of the US-ASCII %d63-90 / ; characters not including %d94-126 ; ">", "[", "]", or "\" The msg-id MUST NOT be more than 250 octets in length. NOTE: The length restriction ensures that systems which accept message identifiers as a parameter when retrieving an article (e.g. [NNTP]) can rely on a bounded length. Observe that msg-id includes the < and >. Observe also that in contrast to the corresponding header field in [RFC2822]: o the syntax does not allow comments within the Message-ID header field, o it ensures that no string of characters is quoted if it was already a (it MUST start or end with a ".", or contain at least one ), Murchison, et al. Expires June 19, 2006 [Page 15] Internet-Draft Netnews Article Format December 2005 o it ensures that no single character is prefixed by a "\" in the form of a unless strictly necessary, o it excludes all control characters, o there is no possibility for ">" or WSP to occur inside a , whether quoted or not, and o even though commonly derived from s, s are case-sensitive (and thus, once created, are not to be altered during subsequent transmission or copying) This is to simplify processing by news servers and to ensure interoperability with existing implementations and compliance with [NNTP]. Thus, whereas under [RFC2822] the following s would be considered semantically equivalent, <"ab.cd"@example.com> <"ab.\cd"@example.com> only the first of them is syntactically permitted by this standard, and hence a simple comparison of octets will always suffice to determine the identity of two s. Also note that this updated ABNF applies wherever is used, including the References header field discussed in Section 3.2.2 and the Supersedes header field discussed in Section 3.2.6. Some software will try to match the of a in a case-insensitive fashion; some will match it in a case-sensitive fashion. Implementations MUST NOT generate two Message-IDs where the only difference is the case of characters in the part. When generationg a , implementations SHOULD use a domain name as the . NOTE: Section 3.6.4 of [RFC2822] recommends that the should be a domain name or a domain literal. Domain literals are troublesome since many IP addresses are not globally unique; domain names are more likely to generate unique Message-IDs. 3.1.4. Subject The Subject header field is the same as that specified in Section 3.6.5 of [RFC2822] with the added restrictions detailed in Section 2.2. Further discussion of the content of the Subject header field appears in [USEPRO] and [USEAGE]. Murchison, et al. Expires June 19, 2006 [Page 16] Internet-Draft Netnews Article Format December 2005 subject = "Subject:" SP unstructured CRLF 3.1.5. Newsgroups The Newsgroups header field specifies the newsgroup(s) to which the article is posted. newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroup-list = [FWS] newsgroup-name *( [FWS] "," [FWS] newsgroup-name ) [FWS] newsgroup-name = component *( "." component ) component = 1*component-char component-char = ALPHA / DIGIT / "+" / "-" / "_" Folding the Newsgroups header field over several lines has been shown to harm propagation significantly. Folded Newsgroups header fields SHOULD NOT be generated, but MUST be accepted. A newsgroup component SHOULD NOT consist of digits only, and SHOULD NOT contain uppercase letters. Such components MAY be used only to refer to existing groups that do not conform to this naming scheme. NOTE: All-digit components conflict with one widely used storage scheme for articles. Mixed case groups cause confusion between systems with case sensitive matching and systems with case insensitive matching of s. s beginning with underline ("_") are reserved for use by future versions of this standard and MUST NOT be generated by user agents (whether in Newsgroups header fields or in newgroup control messages [USEPRO]). However, such names MUST be accepted by news servers. s beginning with "+" and "-" are reserved for private use and MUST NOT be generated by user agents (whether in Newsgroups header fields or in newgroup control messages [USEPRO]) without a private prior agreement to do so. However, such names MUST be accepted by news servers. The following s are reserved, and MUST NOT be used as the name of a newsgroup: o Groups whose first (or only) component is "example" Murchison, et al. Expires June 19, 2006 [Page 17] Internet-Draft Netnews Article Format December 2005 o The group "poster" The following within the Subject header field. 3.1.6. Path The Path header field indicates the route taken by an article since its injection into the Netnews system. Each agent that processes an article is required to prepend one (or more) identities to this header field body. This is primarily to enable news servers to avoid sending articles to sites already known to have them, in particular the site they came from, and additionally to permit tracing the route articles take in moving over the network, and for gathering Usenet statistics. Murchison, et al. Expires June 19, 2006 [Page 18] Internet-Draft Netnews Article Format December 2005 path = "Path:" SP path-list CRLF path-list = [FWS] *( ( path-identity / path-keyword / path-diagnostic ) [FWS] path-delimiter [FWS] ) tail-entry [FWS] path-identity = ( ALPHA / DIGIT ) *( ALPHA / DIGIT / "-" / "." / "_" ) path-keyword = "POSTED" / "MISMATCH" path-diagnostic = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) tail-entry = path-identity path-delimiter = "!" / "!!" A is a name identifying a site. It takes the form of a domain name having one or more components separated by dots. Each in the (excluding the one in the ) indicates, from right to left, the successive agents through which the article has passed. The "POSTED" indicates that the agent to its left injected the article. The use of the "!!" indicates that the agent to its left claims that the agent to its right was the verified source of the article (whereas the "!" implies no such claim). The "MISMATCH" indicates that the agent to its right failed to be so verified. NOTE: Although case-insensitive, it is intended that the s "POSTED" and "MISMATCH" should be in upper case, to distinguish them from the s which are traditionally in lower case. A is an item inserted into the Path header for purposes other than to indicate the name of a site. One commonly observed usage is to insert an IP address. The colon (":") is permitted in order to allow IPv6 addresses to be inserted; note that this will cause interoperability problems at older sites that regard ":" as a and have neighbors whose names have 4 or fewer characters, and where all the characters are valid HEX digits. Murchison, et al. Expires June 19, 2006 [Page 19] Internet-Draft Netnews Article Format December 2005 3.2. Optional Header Fields None of the header fields appearing in this section is required to appear in every article but some of them may be required in certain types of articles. Further discussion of these requirements appears in [USEPRO] and [USEAGE]. The header fields Reply-To, Sender, Comments, and Keywords are used in news articles in the same circumstances and with the same meaning as that specified in [RFC2822] with the added restrictions detailed in Section 2.2. Multiple occurances of the Keywords header field are not permitted. sender = "Sender:" SP mailbox CRLF reply-to = "Reply-To:" SP address-list CRLF comments = "Comments:" SP unstructured CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF The MIME header fields MIME-Version, Content-Type, Content-Transfer- Encoding, Content-Disposition, and Content-Language are used in news articles in the same circumstances and with the same meanings as those specified in [RFC2045], [RFC2183], and [RFC3282] with the added restrictions detailed in Section 2.2. All remaining news header fields are described below. 3.2.1. Injection-Date The Injection-Date header field contains the date and time that the article was injected into the network. Its purpose is to prevent the reinjection into the news stream of "stale" articles which have already expired by the time they arrive at some news server. This header field MUST be inserted whenever an article is injected. However, software that predates this standard does not use this header, and therefore agents MUST accept articles without the Injection-Date header field. injection-date = "Injection-Date:" SP date-time CRLF See the remarks under Section 3.1.2 regarding the syntax of and the requirements and recommendations to which it is subject. Murchison, et al. Expires June 19, 2006 [Page 20] Internet-Draft Netnews Article Format December 2005 NOTE: The in this header field would normally be expected to be later than the in the Date header field, but differences between the clocks on the various agents and other special circumstances might vitiate that; no provision is made for any such discrepancy to be corrected - better that the news server should just insert the correct time as it sees it. This header field is intended to replace the currently-used but undocumented "NNTP-Posting-Date" header field, whose use is now deprecated. 3.2.2. References The References header field is the same as that specified in Section 3.6.4 of [RFC2822] with the added restrictions detailed in Section 2.2 and those listed below: o The updated construct defined in Section 3.1.3 MUST be used. o Message identifiers MUST be separated with CFWS. o Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated, but MUST be accepted. references = "References:" SP [CFWS] msg-id *(CFWS msg-id) [CFWS] CRLF 3.2.3. Followup-To The Followup-To header field specifies to which newsgroup(s) followups should be posted. The Followup-To header field SHOULD NOT appear in a message, unless its content is different from the content of the Newsgroups header field. followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) CRLF poster-text = [FWS] %d112.111.115.116.101.114 [FWS] ; "poster" in lower-case The syntax is the same as that of the Newsgroups header field (Section 3.1.5, with the exception that the keyword "poster" (which is always lowercase) requests that followups should be mailed to the article's reply address rather than posted. Although the keyword "poster" is case-sensitive, user agents MAY choose to recognize case- Murchison, et al. Expires June 19, 2006 [Page 21] Internet-Draft Netnews Article Format December 2005 insensitive forms such as "Poster". 3.2.4. Expires The Expires header field specifies a date and time when the article is deemed to be no longer relevant and could usefully be removed ("expired"). expires = "Expires:" SP date-time CRLF See the remarks under Section 3.1.2 regarding the syntax of and the requirements and recommendations to which it is subject. 3.2.5. Control The Control header field marks the article as a control message, and specifies the desired actions (additional to the usual ones of storing and/or relaying the article). control = "Control:" SP [FWS] control-command [FWS] CRLF control-command = verb *( [FWS] argument ) verb = token argument = value The verb indicates what action should be taken, and the argument(s) (if any) supply details. In some cases, the body of the article may also contain details. The legal verbs and respective arguments are discussed in the companion document, [USEPRO]. An article with a Control header field MUST NOT also have a Supersedes header field. 3.2.6. Supersedes The Supersedes header field contains a message identifier specifying an article to be superseded upon the arrival of this one. An article containing a Supersedes header field is equivalent to a "cancel" [USEPRO] control message for the specified article, followed immediately by the new article without the Supersedes header field. supersedes = "Supersedes:" SP [FWS] msg-id [FWS] CRLF NOTE: There is no "c" in Supersedes. Murchison, et al. Expires June 19, 2006 [Page 22] Internet-Draft Netnews Article Format December 2005 NOTE: The Supersedes header field defined here has no connection with the Supersedes header field that sometimes appears in Email messages converted from X.400 according to [RFC2156]; in particular, the syntax here permits only one in contrast to the multiple s in that Email version. 3.2.7. Distribution The Distribution header field specifies geographic or organizational limits on an article's propagation. distribution = "Distribution:" SP dist-list CRLF dist-list = [FWS] dist-name *( [FWS] "," [FWS] dist-name ) [FWS] dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" ) The s "world" and "local" are predefined. However, "world" SHOULD NOT be used explicitly, since it is the default when the Distribution header field is absent entirely. "All" MUST NOT be used as a . s SHOULD contain at least three characters, except when they are two-letter country names as in [ISO.3166.1988]. s are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify the same distribution). 3.2.8. Summary The Summary header field is a short phrase summarizing the article's content. summary = "Summary:" SP unstructured CRLF 3.2.9. Approved The Approved header field indicates the mailing addresses (and possibly the full names) of the persons or entities approving the article for posting. Its principal uses are in moderated articles and in group control messages [USEPRO]. approved = "Approved:" SP mailbox-list CRLF Each mailbox contained in the Approved header field MUST be that of one of the person(s) or entity(ies) in question, and one of those mailboxes MUST be that of the actual sender of the article. Note that this standard does not provide any means to enforce or verify Murchison, et al. Expires June 19, 2006 [Page 23] Internet-Draft Netnews Article Format December 2005 this requirement, but future extensions or standards may provide such a facility (e.g. digitial signatures). 3.2.10. Organization The Organization header field is a short phrase identifying the poster's organization. organization = "Organization:" SP unstructured CRLF There is no "s" in Organization. 3.2.11. Xref The Xref header field indicates where an article was filed by the last news server to process it. The article locations are used to keep track of crossposted articles so that user agents serviced by a particular news server can mark such articles as read. xref = "Xref:" SP [FWS] server-name 1*( FWS location ) [FWS] CRLF server-name = path-identity location = newsgroup-name ":" article-locator article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) ; US-ASCII printable characters ; except '(' and ';' The is included so that software can determine which news server generated the header field. The locations specify what newsgroups the article was filed under (which may differ from those in the Newsgroups header field) and where it was filed under them. The exact form of an is implementation-specific. NOTE: The traditional form of an (as required by [NNTP]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1. 3.2.12. Archive The Archive header field provides an indication of the poster's intent regarding preservation of the article in publicly accessible long-term or permanent storage. Murchison, et al. Expires June 19, 2006 [Page 24] Internet-Draft Netnews Article Format December 2005 archive = "Archive:" SP [CFWS] ("no" / "yes") *( [CFWS] ";" archive-param ) CRLF archive-param = parameter The presence of an Archive header field in an article with a field body of "no" indicates that the poster does not permit redistribution from publicly accessible long-term or permanent archives. The absence of this header field, or the presence of this header field with a field body of "yes", indicates that the poster is willing for such redistribution to take place. Further extensions to this standard may provide parameters for administration of the archiving process. 3.2.13. User-Agent The User-Agent header field contains information about the user agent (typically a newsreader) generating the article, for statistical purposes and tracing of standards violations to specific software needing correction. It is intended that this header field be suitable for use in Email. user-agent = "User-Agent:" SP 1*product [CFWS] CRLF product = [CFWS] token [ [CFWS] "/" product-version ] product-version = [CFWS] token This header field MAY contain multiple product-tokens identifying the user agent and any subproducts which form a significant part of it, listed in order of their significance for identifying the application. NOTE: Some of this information has previously been sent in non- standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent uses User-Agent, it should have no need to send these non-standard header fields. NOTE: [RFC2616] describes a similar facility for the HTTP protocol. This specification differs in that "{" and "}" are allowed in tokens ( and ) and comments are permitted wherever whitespace is allowed. 3.2.14. Injection-Info The Injection-Info header field contains information provided by the injecting news server as to how an article entered the Netnews system Murchison, et al. Expires June 19, 2006 [Page 25] Internet-Draft Netnews Article Format December 2005 and to assist in tracing its true origin. It can also specify one or more addresses where complaints concerning the poster of the article may be sent. injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] *(';' parameter) CRLF NOTE: The syntax of ([RFC2045] as amended by [RFC2231]), taken in conjunction with the folding rules of [RFC0822], effectively allows [CFWS] to occur both before and after the , and also on either side of its "=". The following table gives the and the format of the for each defined for use with this header field. At most one occurrence of each such is allowed. format of -------------------- ----------------- "posting-host" a "posting-account" any "sender" a "logging-data" any "mail-complaints-to" an where host-value = dot-atom-text / [ dot-atom-text ":" ] ( IPv4address / IPv6address ) ; see [RFC 3986] sender-value = mailbox / "verified" NOTE: Since any such >, or has also to be a syntactically correct , it will usually be necessary to encapsulate is as a , for example: sender = "\"Joe Q. Public\" " Additionally, any other whose starts with "x-" MAY be used where the defined ones appear to be unsuitable, but other unlisted s SHOULD NOT be used unless defined in extensions to this standard. Although comments and folding of white space are permitted throughout the Injection-Info header field, it is RECOMMENDED that folding is not used within any (but only before or after the ";" separating those s), and that comments are only used following the last . Murchison, et al. Expires June 19, 2006 [Page 26] Internet-Draft Netnews Article Format December 2005 NOTE: Some of this information has previously been sent in non- standardized header fields such as NNTP-Posting-Host, X-trace, X-Complaints-To, and others. Once a news server uses Injection- Info, it should have no need to send these non-standard header fields. The "posting-host" specifies the FQDN and/or IP address (IPv4address or IPv6address) of the host from which the news server received the article. NOTE: If the "posting-host" identifies a dial-up point-of-presence, the "posting-account" or the "logging-data" may provide additional information about true origin of the article. The "posting-account" identifies the source from which that news server received the article. For security reasons, it SHOULD be in a cryptic notation understandable only by the administrator of the news server. The "sender" identifies the mailbox of the verified sender of the article (alternatively, it uses the token "verified" to indicate that at least any addr-spec in the Sender header field of the article, or in the From header field if the Sender header field is absent, is correct). If a news server can verify the sender of an article, it SHOULD use this in favor of the "posting- account" . The "logging-data" contains information (typically a session number or other non-persistent means of identifying a posting account) which will enable the true origin of the article to be determined by reference to logging information kept by the news server. The "mail-complaints-to" specifies mailbox(es) for sending complaints concerning the behavior of the poster of the article. 3.3. Obsolete Header Fields Early versions of news software following the modern format sometimes generated header fields like the following: Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Date-Received: Friday, 19-Nov-82 16:59:30 EST Relay-Version contained version information about the news server Murchison, et al. Expires June 19, 2006 [Page 27] Internet-Draft Netnews Article Format December 2005 that last processed the article. Posting-Version contained version information about the user agent that posted the article. Date- Received contained the date when the last news server to process the article first saw it (in a slightly nonstandard format). In addition, this present standard obsoletes certain header fields defined in [Son-of-1036]: Also-Control: cancel <9urrt98y53@site.example> See-Also: Article-Names: comp.foo:charter Article-Updates: Also-Control indicated a control message that was also intended to be filed as a normal article. See-Also listed related articles, but without the specific relationship with followups that pertains to the References header field. Article-Names indicated some special significance of that article in relation to the indicated newsgroup. Article-Updates indicated that an earlier article was updated, without at the same time being superseded. The header fields listed above are documented for historical purposes only. Articles containing these header fields MUST NOT be generated. Persons writing new agents SHOULD ignore any former meanings of these header fields. 3.3.1. Lines The Lines header field indicates the number of lines in the body of the article. lines = "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF The line count includes all body lines, including the signature if any, including empty lines (if any) at the beginning or end of the body, and including the whole of all MIME message and multipart parts contained in the body (the single empty separator line between the header fields and the body is not part of the body). The "body" here is the body as found in the posted article as transmitted by the user agent. Historically, this header field was used by the [NNTP] overview extension, but its use for this purpose is now deprecated. As a result, this header field is to be regarded as obsolescent, and it is likely to be removed entirely in a future version of this standard. Servers and clients SHOULD ignore it, and SHOULD NOT generate it. Murchison, et al. Expires June 19, 2006 [Page 28] Internet-Draft Netnews Article Format December 2005 4. Internationalization Considerations Internationalization of news article header fields and bodies is provided using MIME mechanisms discussed in Section 2.3. Note that the generation of internationalized s for use in header fields is not addressed in this document. Murchison, et al. Expires June 19, 2006 [Page 29] Internet-Draft Netnews Article Format December 2005 5. Security Considerations The news article format specified in this document does not provide any security services, such as confidentiality, authentication of sender, or non-repudiation. Instead, such services need to be layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME [RFC3156], or below, using secure versions of news transport protocols. Additionally, several currently non-standardized protocols [PGPVERIFY] will hopefully be standardized in the near future. Message identifiers (Section 3.1.3) in news are required to be unique; articles are refused (in server-to-server transfer) if the identifier has already been seen. So if you can predict the identifier of a message, you can preempt it by posting a message (possibly to a quite different group) with the same message identifier, stopping your target message from propagating. Agents that generate message identifiers for news articles SHOULD ensure that they are unpredictable. MIME security considerations are discussed in [RFC2046]. Note that the full range of encodings allowed for parameters in [RFC2046] and [RFC2231] permits constructs that simple parsers may fail to parse correctly; examples of hard-to-parse constructs are: Content-Type: multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") Content-Type: multipart/digest; boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy Such differences in parsing may be used as part of an attack. Murchison, et al. Expires June 19, 2006 [Page 30] Internet-Draft Netnews Article Format December 2005 6. References 6.1. Normative References [Errata] "RFC Editor Errata". [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. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 6.2. Informative References [ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988. Murchison, et al. Expires June 19, 2006 [Page 31] Internet-Draft Netnews Article Format December 2005 [NNTP] Feather, C., "Network News Transfer Protocol", draft-ietf-nntpext-base-*.txt. [PGPVERIFY] Lawrence, D., "PGPverify", June 1999. [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986. [RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987. [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. [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. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [Son-of-1036] Spencer, H., "News Article Format and Transmission", June 1994. [USEAGE] Lindsey, C., "Usenet Best Practice", draft-ietf-usefor-useage-*.txt. [USEPRO] Lindsey, C., "News Article Architecture and Protocols", draft-ietf-usefor-usepro-*.txt. Murchison, et al. Expires June 19, 2006 [Page 32] Internet-Draft Netnews Article Format December 2005 Appendix A. Acknowledgements Comments and/or text were provided by Mark Crispin, Claus Faerber, Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey Melnikov. Murchison, et al. Expires June 19, 2006 [Page 33] Internet-Draft Netnews Article Format December 2005 Appendix B. Differences from RFC 1036 and its derivatives This appendix contains a list of changes that have been made in the Netnews Article Format from earlier standards, specifically [RFC1036]. The [RFC2822] conventions for parenthesis-enclosed s in header fields are supported in all newly defined header fields and in header fields inherited from [RFC2822]. They are, however, still disallowed for performance and/or compatibility reasons in the Message-ID, Newsgroups, Path, Followup-To, Control, Supersedes, Distribution, Xref and Lines header fields. Whitespace is permitted in Newsgroups header fields. An enhanced syntax for the Path header field enables the injection point of, and the route taken by an article to be determined with more precision. MIME is recognized as an integral part of Netnews. There is a new Injection-Date header to make the rejection of stale articles more precise and to minimize spurious rejections. There are several new optional header fields defined, notably Archive, Injection-Info and User-Agent, leading to increased functionality. Certain header fields, notably Lines, have been made obsolete (Section 3.3). There are numerous other small changes, clarifications and enhancements. Murchison, et al. Expires June 19, 2006 [Page 34] Internet-Draft Netnews Article Format December 2005 Appendix C. Differences from RFC 2822 This appendix lists the differences between the syntax allowed by the Netnews Article Format (this document) as compared to the Internet Message Format, as specified in [RFC2822]. The Netnews article format is a strict subset of the Internet Message Format; all Netnews articles conform to the syntax of [RFC2822]. The following restrictions are important: A SP (space) is REQUIRED after the colon (':') following header field name. A more restricted syntax of (to be used by the Message-ID, References, and Supersedes header fields) is defined. The length of a msg-id MUST NOT exceed 250 octets. Comments are not allowed in the Message-ID header field. The CFWS between s in the References header field is not optional. It is legal for a parser to not accept obsolete syntax, except that: The construct MUST be accepted. The obsolete "GMT" MUST be accepted within a . Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non- whitespace character. This means that an empty header field body is illegal. Murchison, et al. Expires June 19, 2006 [Page 35] Internet-Draft Netnews Article Format December 2005 Authors' Addresses Kenneth Murchison (editor) Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 US Phone: +1 412 268 2638 Email: murch@andrew.cmu.edu Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU GB Phone: +44 161 436 6131 Email: chl@clw.cs.man.ac.uk Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto, CA 94306 US Phone: +1 650 327 2600 Email: dan@dankohn.com Murchison, et al. Expires June 19, 2006 [Page 36] Internet-Draft Netnews Article Format December 2005 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Murchison, et al. Expires June 19, 2006 [Page 37]