Usenet Format Working Group K. Murchison, Ed. Internet-Draft Oceana Matrix Ltd. Obsoletes: 1036 (if approved) C. Lindsey Expires: May 24, 2005 University of Manchester D. Kohn Skymoon Ventures November 23, 2004 News Article Format draft-ietf-usefor-usefor-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Murchison, et al. Expires May 24, 2005 [Page 1]
Internet-Draft News Article Format November 2004 and incorporating incremental changes specified in other documents. 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 <obs-zone>. o Used Charles' ABNF for <msg-id> and <unstructured>. 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 <control-message> 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", and "filename" in Archive header. o Added "Obsolete Headers" section. o Miscellaneous editorial changes Changes since draft-kohn-news-article-03 o Document is now a work product of USEFOR o Added new co-authors o Added some definitions from draft-ietf-usefor-article-13 o Removed discussion of message/partial MIME messages. o Removed text that belongs in [USEPRO] o Reorganized header sections o Added Archive, User-Agent, Injection-Date, and Injection-Info headers. o Used Charles' ABNF for <msg-id> and <unstructured>. o Removed restrictions on length and start character for Newsgroups. o Added required SP to ABNF of header definitions. o Disallowed comments in Control header. o Xref header allows for non-digit "locations". o Only allow for a single message-id in Supersedes header. o Changes to the References header. o Compatibility changes based on comments from Charles Changes since draft-ietf-usefor-article-13 Murchison, et al. Expires May 24, 2005 [Page 2]
Internet-Draft News Article Format November 2004 o The Mail-Copies-To, Posted-And-Mailed and Complaints-To 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. Issues to be addressed o Decide which definitions should go in this document and in [USEPRO]. o Decide how much (if any) discussion of Injection-Info content belongs in this document vs. [USEPRO]. o Do we want to discuss message/partial? o Add appendixes for changes from RFC 1036 and differences from RFC 2822. 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 May 24, 2005 [Page 3]
Internet-Draft News Article Format November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Structure of This Document . . . . . . . . . . . . . . . . 7 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 9 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 10 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 11 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 13 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 14 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 17 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 17 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 18 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 19 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 19 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 20 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 21 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Internationalization Considerations . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . 24 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 6.2 Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 29 Murchison, et al. Expires May 24, 2005 [Page 4]
Internet-Draft News Article Format November 2004 1. Introduction 1.1 Basic Concepts "Netnews" is a set of protocols for generating, storing and retrieving news "articles" (which are a subset of 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 network news articles, independent of transport protocols such as [NNTP]. An 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 May 24, 2005 [Page 5]
Internet-Draft News Article Format November 2004 1.4 Syntax Notation Headers 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.2 and Section 3.1.3 update the [RFC2822] definitions of <zone> and <msg-id> respectively. 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. A "message identifier" Section 3.1.3 is a unique identifier for an article, usually supplied by the "posting agent" which posted it or, failing that, by the "injecting agent". 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 headers. 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 "posting agent". The poster is analogous to [RFC2822]'s author. A "posting agent" is the software that assists posters to prepare proto-articles, in compliance with this standard. The proto-article is then passed on to an "injecting agent" for final checking and injection into the news stream. If the article is not compliant, or is rejected by the injecting agent, then the posting agent informs the poster with an explanation of the error. A "reader" is the person or software reading news articles. A "reading agent" is software which presents articles to a reader. Murchison, et al. Expires May 24, 2005 [Page 6]
Internet-Draft News Article Format November 2004 A "followup" is an article containing a response to the contents of an earlier article (the followup's "precursor"). A "followup agent" is a combination of reading agent and posting agent that aids in the preparation and posting of a followup. Posting, reading and followup agents (which are usually just different services provided by the same piece of software) are known collectively as "user agents". An "injecting agent" takes the finished article from the posting agent (often via the [NNTP] "post" command) performs some final checks and passes it on to a relaying agent for general distribution. A "control message" is an article which is marked as containing control information; a relaying or serving agent receiving such an article may (subject to the policies observed at that site) take actions beyond just filing and passing on the article. 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 headers necessary to make an article suitable for the netnews environment. Murchison, et al. Expires May 24, 2005 [Page 7]
Internet-Draft News Article Format November 2004 2. Format 2.1 Base News articles MUST conform to the syntax specified in Section 3 of [RFC2822]. Netnews agents MAY also accept the obsolete syntax specified in Section 4 of [RFC2822], but they MUST NOT generate such syntax. This specification uses the terms "header", "header name", and "header content" which are synonymous with the [RFC2822] terms "header field", "field name", and "field body" respectively. 2.2 Headers All headers in a news article are compliant with [RFC2822], however this specification is less permissive in what can be 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 headers (even those documented in [RFC2822] and [RFC2045]) are listed below and those that apply to specific headers are described in the relevent sections of this document. o All agents MUST generate headers so that at least one space immediately follows the ':' separating the header name and the header contents (for compatibility with deployed software). News agents MAY accept headers which do not contain the required space. o The header contents of every header line (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character. NOTE: This means that no header content defined by or referenced by this document can be empty. As a result, this document updates the <unstructured> construct from Section 3.2.6 of [RFC2822] as follows: unstructured = 1*( [FWS] utext ) [FWS] o Compliant software MUST NOT generate (but MAY accept) headers of more than 998 octets. This is the only limit on the length of a header line prescribed by this standard. However, specific rules to the contrary may apply in particular cases (for example, according to [RFC2047] header lines containing encoded-words are limited to 76 octets). [USEAGE] includes suggested limits for Murchison, et al. Expires May 24, 2005 [Page 8]
Internet-Draft News Article Format November 2004 convenience of display by user agents. NOTE: There is NO restriction on the number of lines into which a header may be split, and hence there is NO restriction on the total length of a header (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 headers is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2045] and [RFC2231]. 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 headers ([RFC2047], [RFC2231]). Note that [Errata] currently exist for [RFC2046] and [RFC2231]. For the purposes of Section 5 of [RFC2047], all headers defined in Section 3 of this standard are to be considered as "extension message header fields" (insofar as they are not already considered under the existing Email standards), permitting the use of [RFC2047] encodings within any <unstructured> header, or within any <comment> or <phrase> permittted within any structured header. User agents MAY accept and generate other MIME extension headers, and in particular SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282]. Murchison, et al. Expires May 24, 2005 [Page 9]
Internet-Draft News Article Format November 2004 3. News Headers The following news headers 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 headers may occur at most once in a news article. 3.1 Mandatory Headers Each news article conformant with this specification MUST have exactly one of each of the following headers: From, Date, Message-ID, Subject, Newsgroups, Path, and Injection-Date. 3.1.1 From The From header 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 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 "UT" and "GMT" as time zones (part of <obs-zone>), although deprecated, is widespread in news articles today. Therefore, agents MUST accept <date-time> constructs which include the updated <zone> construct below. orig-date = "Date:" SP date-time CRLF Murchison, et al. Expires May 24, 2005 [Page 10]
Internet-Draft News Article Format November 2004 zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" Note that agents SHOULD NOT generate <date-time> constructs which include either "UT" or "GMT" and MUST NOT generate <date-time> constructs which include any other zone names defined by <obs-zone>, some of which have ambiguous interpretations and would have adverse effects on Netnews protocols. Also note that these requirements apply wherever <date-time> is used, including Injection-Date and Expires in Section 3.1.7 and Section 3.2.3 respectively. 3.1.3 Message-ID The Message-ID header contains a single unique message identifier. This document updates the <msg-id> construct from Section 3.6.4 of [RFC2822] so as to ensure that Internet Message Format Message-IDs are usable in widely deployed news software. The global uniqueness requirement for <msg-id> in [RFC2822] is to be understood as applying across all protocols using such message identifiers, and across both Email and Netnews in particular. The ABNF should be used as below, but the requirements and descriptive text from Section 3.6.4 of [RFC2822] still apply. Murchison, et al. Expires May 24, 2005 [Page 11]
Internet-Draft News Article Format November 2004 message-id = "Message-ID:" SP msg-id CRLF msg-id = [FWS] msg-id-core [FWS] msg-id-core = "<" 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 / "\\" / "\" DQUOTE ) mqspecial *( mqtext / "\\" / "\" DQUOTE ) DQUOTE mqtext = NO-WS-CTL / ; all of <text> except %d33 / ; SP, HTAB, "\", ">" %d35-61 / ; and DQUOTE %d63-91 / %d93-126 mqspecial = "(" / ")" / ; same as specials except "<" / ; "\" and DQUOTE quoted "[" / "]" / ; and ">" omitted ":" / ";" / "@" / "\\" / "," / "." / "\" DQUOTE no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" mdtext = NO-WS-CTL / ; Non white space controls %d33-61 / ; The rest of the US-ASCII %d63-90 / ; characters not including %d94-126 ; ">", "[", "]", or "\" The msg-id-core 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-core includes the < and >. Observe also that in contrast to the corresponding header in [RFC2822], the syntax does not allow comments within the Message-ID Murchison, et al. Expires May 24, 2005 [Page 12]
Internet-Draft News Article Format November 2004 header, it ensures that no string of characters is quoted unless strictly necessary (it must contain at least one mqspecial) and no single character is prefixed by a "\" in the form of a quoted-pair unless strictly necessary, and moreover there is no possibility for ">" or WSP to occur inside a msg-id-core, whether quoted or not. This is to simplify processing by relaying and serving agents and to ensure interoperability with existing implementations. Thus, whereas under [RFC2822] the following <msg-id-core> would be considered semantically equivalent, <abcd@example.com> <"abcd"@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 <msg-id-core>. Also note that this updated ABNF applies wherever <msg-id-core> are used, including the References header discussed in Section 3.2.1 and the Supersedes header discussed in Section 3.2.5. 3.1.4 Subject The Subject header 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 appears in [USEPRO] and [USEAGE]. subject = "Subject:" SP unstructured CRLF 3.1.5 Newsgroups The Newsgroups header 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 / "+" / "-" / "_" Murchison, et al. Expires May 24, 2005 [Page 13]
Internet-Draft News Article Format November 2004 NOTE: Observe that the syntax does not allow comments within the Newsgroups header; this is to simplify processing by relaying and serving agents which have a requirement to process this header extremely rapidly. Components beginning with underline ("_") are reserved for use by future versions of this standard and MUST NOT occur in <newsgroup-name>s (whether in Newsgroups headers or in newgroup control messages [USEPRO]). However, such names MUST be accepted. The specific format and lengths of <newsgroup-name> and <component> are discussed in [USEAGE]. 3.1.6 Path The Path header 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. This is primarily to enable relaying agents 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. path = "Path:" SP path-list CRLF path-list = [FWS] *( path-identity [FWS] path-delimiter [FWS] ) tail-entry [FWS] path-identity = ( ALPHA / DIGIT ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) tail-entry = path-identity path-delimiter = "!" ; possible other delimiters TBD The specific format and use of <path-identity> and <tail-entry> are discussed in [USEPRO]. 3.1.7 Injection-Date The Injection-Date header 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 relaying or serving agent. injection-date = "Injection-Date:" SP date-time CRLF Murchison, et al. Expires May 24, 2005 [Page 14]
Internet-Draft News Article Format November 2004 See the remarks under Section 3.1.2 regarding the syntax of date-time and the requirements and recommendations to which it is subject. NOTE: The date-time in this header would normally be expected to be later than the date-time in the Date header, 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 injecting agent should just insert the correct time as it sees it. This header is intended to replace the currently-used but undocumented "NNTP-Posting-Date" header, whose use is now deprecated. 3.2 Optional Headers None of the headers appearing in this section is required to appear in every article but some of them are required in certain types of article, such as followups. Further discussion of these requirements appears in [USEPRO] and [USEAGE]. The headers 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 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 headers 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 headers are described below. 3.2.1 References The References header 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: Murchison, et al. Expires May 24, 2005 [Page 15]
Internet-Draft News Article Format November 2004 o The updated <msg-id-core> 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 1*( [CFWS] msg-id-core) [CFWS] CRLF 3.2.2 Followup-To The Followup-To header specifies to which newsgroup(s) followups should be posted. The Followup-To header SHOULD NOT appear in a message, unless its content is different from the content of the Newsgroups header. 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 (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, followup agents MAY choose to recognize case-insensitive forms such as "Poster". 3.2.3 Expires The Expires header 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 date-time and the requirements and recommendations to which it is subject. 3.2.4 Control The Control header marks the article as a control message, and specifies the desired actions (additional to the usual ones of storing and/or relaying the article). Murchison, et al. Expires May 24, 2005 [Page 16]
Internet-Draft News Article Format November 2004 control = "Control:" SP [FWS] control-message [FWS] CRLF control-message = 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 MUST NOT also have a Supersedes header. 3.2.5 Supersedes The Supersedes header contains a message identifier specifying an article to be superseded upon the arrival of this one. An article containing a Supersedes header is equivalent to a "cancel" [USEPRO] control message for the specified article, followed immediately by the new article without the Supersedes header. supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF NOTE: There is no "c" in Supersedes. NOTE: The Supersedes header defined here has no connection with the Supersedes header that sometimes appears in Email messages converted from X.400 according to [RFC2156]; in particular, the syntax here permits only one <msg-id-core> in contrast to the multiple <msg-id-core>s in that Email version. 3.2.6 Distribution The Distribution header specifies geographic or organizational limits on an article's propagation. distribution = "Distribution:" SP distribution-list CRLF dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" ) The <dist-name>s "world" and "local" are predefined. However, "world" SHOULD NOT be used explicitly, since it is the default when Murchison, et al. Expires May 24, 2005 [Page 17]
Internet-Draft News Article Format November 2004 the Distribution header is absent entirely. "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain at least three characters, except when they are two-letter country names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify the same distribution). 3.2.7 Summary The Summary header is a short phrase summarizing the article's content. summary = "Summary:" SP unstructured CRLF 3.2.8 Approved The Approved header indicates the mailing addresses (and possibly the full names) of the persons or entities approving the article for posting. approved = "Approved:" SP mailbox-list CRLF Each mailbox contained in the Approved header 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 injector of the article. Note that this standard doesn't provide any means to enforce or verify this requirement, but future extensions or standards may provide such a facility (e.g. digitial signatures). 3.2.9 Organization The Organization header is a short phrase identifying the poster's organization. organization = "Organization:" SP unstructured CRLF There is no "s" in Organization. 3.2.10 Xref The Xref header indicates where an article was filed by the last serving agent to process it. The article locations are used to keep track of crossposted articles so that reading agents serviced by a particular serving agent can mark such articles as read. Murchison, et al. Expires May 24, 2005 [Page 18]
Internet-Draft News Article Format November 2004 xref = "Xref:" SP [CFWS] server-name 1*( CFWS location ) [CFWS] 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 <server-name> is included so that software can determine which serving agent generated the header. The locations specify what newsgroups the article was filed under (which may differ from those in the Newsgroups header) and where it was filed under them. The exact form of an article-locator is implementation-specific. NOTE: The traditional form of an article-locator (as used by [NNTP]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1. 3.2.11 Archive The Archive header provides an indication of the poster's intent regarding preservation of the article in publicly accessible long-term or permanent storage. archive = "Archive:" SP [CFWS] ("no" / "yes") *( [CFWS] ";" archive-param ) CRLF archive-param = "filename=" value The presence of an "Archive: no" header in an article indicates that the poster does not permit redistribution from publicly accessible long-term or permanent archives. The absence of this header, or an explicit "Archive: yes", indicates that the poster is willing for such redistribution to take place. The optional "filename" parameter can then be used to suggest a filename under which the article should be stored. Further extensions to this standard may provide additional parameters for administration of the archiving process. 3.2.12 User-Agent The User-Agent header 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 be suitable for use in Email. Murchison, et al. Expires May 24, 2005 [Page 19]
Internet-Draft News Article Format November 2004 user-agent = "User-Agent:" SP 1*product CRLF product = [CFWS] token [CFWS] [ "/" product-version ] product-version = [CFWS] token [CFWS] This header MAY contain multiple product-tokens identifying the agent and any subproducts which form a significant part of the posting agent, listed in order of their significance for identifying the application. NOTE: This header supersedes the role performed redundantly by experimental headers such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and other headers previously used on Usenet and in Email for this purpose. Use of these experimental headers SHOULD be discontinued in favor of the single, standard User-Agent header. NOTE: [RFC2616] describes a similar facility for the HTTP protocol. This specification differs in that "{" and "}" are allowed in tokens (<product> and <product-version>) and comments are permitted wherever whitespace is allowed. 3.2.13 Injection-Info The Injection-Info header provides information as to how an article entered the Netnews system and to assist in tracing its true origin. injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] *( ";" inj-info-para ) CRLF inj-info-param = post-host-param / post-account-param / sender-param / logging-param post-host-param = "posting-host=" host-value host-value = dot-atom / [ dot-atom ":" ] ( IPv4address / IPv6address ) ; see [RFC 2373] post-acct-param = "posting-account=" value sender-param = "sender=" sender-value sender-value = mailbox / "verified" logging-param = "logging-data=" value Murchison, et al. Expires May 24, 2005 [Page 20]
Internet-Draft News Article Format November 2004 Although comments and folding of white space are permitted throughout the Injection-Info header, it is RECOMMENDED that folding is not used within any parameter (but only before or after the ";" separating those parameters), and that comments are only used following the last parameter. It is also RECOMMENDED that such parameters as are present are included in the order in which they have been defined in the syntax above. This header is intended to replace various currently-used but undocumented headers such as "NNTP-Posting-Host" and "X-Trace". These headers are now deprecated. 3.3 Obsolete Headers Early versions of news software following the modern format sometimes generated headers 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 relaying agent that last processed the article. Posting-Version contained version information about the posting agent that posted the article. Date-Received contained the date when the last relaying agent to process the article first saw it (in a slightly nonstandard format). In addition, this present standard obsoletes certain headers defined in [Son-of-1036]: Also-Control: cancel <9urrt98y53@site.example> See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example> Article-Names: comp.foo:charter Article-Updates: <i4g587y@site1.example> 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. 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 headers listed above are documented for historical purposes only. Articles containing these headers MUST NOT be generated. Persons writing new agents SHOULD ignore any former meanings these headers. Murchison, et al. Expires May 24, 2005 [Page 21]
Internet-Draft News Article Format November 2004 3.3.1 Lines The Lines header indicates the number of lines in the body of the article. lines = "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] 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 headers 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 posting agent. Historically, this header was used by the [NNTP] overview extension, but its use for this purpose is now deprecated. As a result, this header is to be regarded as obsolete, and it will likely be removed entirely in a future version of this standard. Murchison, et al. Expires May 24, 2005 [Page 22]
Internet-Draft News Article Format November 2004 4. Internationalization Considerations Internationalization of news article headers and bodies is provided using MIME mechanisms discussed in Section 2.3. Note that the generation of internationalized newsgroup names for use in headers is not addressed in this document. Murchison, et al. Expires May 24, 2005 [Page 23]
Internet-Draft News Article Format November 2004 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 [RFC2633] 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-IDs (Section 3.1.3) in news are required to be unique; articles are refused (in server-to-server transfer) if the ID has already been seen. So if you can predict the ID of a message, you can preempt it by posting a message (possibly to a quite different group) with the same ID, stopping your target message from propagating. Agents that generate message-ids for news articles SHOULD ensure that they are unpredictable. The filename parameter of the Archive-header (Section 3.2.11) can be used to attempt to store archived articles in inappropriate locations. Archiving sites should be suspicious of absolute filename parameters, as opposed to those relative to some location of the archiver's choosing. Murchison, et al. Expires May 24, 2005 [Page 24]
Internet-Draft News Article Format November 2004 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. 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 May 24, 2005 [Page 25]
Internet-Draft News Article Format November 2004 [NNTP] Feather, C., "Network News Transfer Protocol", draft-ietf-nntpext-base-*.txt. [PGPVERIFY] Lawrence, D., "PGPverify", June 1999. [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. [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [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. Authors' Addresses Kenneth Murchison (editor) Oceana Matrix Ltd. 21 Princeton Place Orchard Park, NY 14127 US Phone: +1 716 662 8973 EMail: ken@oceana.com Murchison, et al. Expires May 24, 2005 [Page 26]
Internet-Draft News Article Format November 2004 Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Chesire 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 May 24, 2005 [Page 27]
Internet-Draft News Article Format November 2004 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 May 24, 2005 [Page 28]
Internet-Draft News Article Format November 2004 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 (2004). 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 May 24, 2005 [Page 29]
