Usenet Format Working Group C. Lindsey Internet-Draft University of Manchester
Updates: 2822 (if approved) D. KohnObsoletes: 1036 (if approved) Skymoon Ventures Expires: January 9, 2005K. Murchison Expires: March 15, 2005 Oceana Matrix Ltd. July 11,D. Kohn Skymoon Ventures September 14, 2004 News Article Format draft-ietf-usefor-usefor-00.txtdraft-ietf-usefor-usefor-01.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, I certifyeach author represents that any applicable patent or other IPR claims of which I amhe or she is aware have been or will be disclosed, and any of which Ihe 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 January 9,March 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.Abstract This document defines the format of network news articles. Network news articles resemble mail messages but are broadcast to potentially large audiences, using a flooding algorithm that propagates one copy to each interested host (or group thereof), typically stores only one copy per host, and does not require any central administration or systematic registration of interested users. Network news originated as the medium of communication for Usenet, circa 1980. Since then Usenet has grown explosively, and many Internet sites participate in it. In addition, the news technology is now in widespread use for other purposes, on the Internet and elsewhere. This document definesspecifies the formatsyntax of network news articles in the context of the Internet"Internet Message Format,Format" (RFC 2822) and adds Multipurpose"Multipurpose Internet Mail Extensions (MIME) support for multimedia(MIME)" (RFC 2045). This document supersedes RFC 1036, updating it to reflect current practice and internationalized message bodies.incorporating incremental changes specified in other documents. Changes since draft-kohn-news-article-03 o Document is now a work product of USEFORdraft-ietf-usefor-usefor-00 o Added new co-authorsRewrote/reorganized Abstract and Introduction. o Added some definitions from draft-ietf-usefor-article-13 o Removed text that belongs in [usepro]required SP to ABNF of header definitions. o Reorganized header sections o Added Archive and User-Agent headerssections. o Compatibility changes based on comments from CharlesCharles. o Added Injection-Date and Injection-Info headers. Changes since draft-ietf-usefor-article-13 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). Issues to be addressed o More detailed discussion of Control header verbs o Discussion of 78 character limitDecide which definitions should go in headers o Discussion of required space after ':'this document and in headers o Review Message-ID limitations[USEPRO]. o FurtherDecide how much (if any) discussion of newsgroup name character limits o Investigate using MIME parameters for Archive headerInjection-Info content belongs in this document vs. [USEPRO]. o ShouldDo we use the User-Agent specificationwant to discuss message/partial? o Add appendixes for obsolete headers, changes from RFC 1036 and differences from HTTP?RFC 2822. o Review of ABNF TableMerge more security issues? o Merge acknowledgments? Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Scope . . . .Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Requirements NotationScope . . . . . . . . . . . . . . . . . . 5 1.3 Errata. . . . . . . . 4 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.6 Structure of This Document . . . . . . . . . . . . . . . . 65 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 MIME ConformanceHeader Fields . . . . . . . . . . . . . . . . . . . . . . 7 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 8 2.4 Additional MIME Support . . . . . . . . . . . . . . . . . 78 3. Internet Message FormatNews Headers . . . . . . . . . . . . . . 8. . . . . . . . . . 9 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 8 3.2 Optional Headers9 3.1.1 From . . . . . . . . . . . . . . . . . . . . . 8 3.3 Date. . . . 9 3.1.2 Subject . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Message-ID9 3.1.3 Date . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 News Headers. 9 3.1.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . 10 18.104.22.168.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 10 3.5.211 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5.311 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 12 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 11 3.5.413 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.513 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.613 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 14 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 12 3.5.714 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.814 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.915 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 12 3.5.1015 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.11 Supersedes . .15 3.2.11 Archive . . . . . . . . . . . . . . . . . . . 13 3.5.12 Archive. . . 15 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . 13 3.5.13 User-Agent. . 16 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 1316 4. Internationalization Considerations . . . . . . . . . . . . 1418 5. Security Considerations . . . . . . . . . . . . . . . . . . 1519 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 1620 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 1620 6.2 Informative References . . . . . . . . . . . . . . . . . . . 1620 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 1721 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 1923 Intellectual Property and Copyright Statements . . . . . . . 2024 1. Introduction 1.1 ScopeBasic Concepts "Netnews" is a set of protocols for generating, storing and retrieving news "articles" (a subset of the Internet Message Format)(which resemble email messages) and for exchanging them amongamongst 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 shehe 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. This is the first of four documents that obsolete RFC 1036.1.2 Scope This document focuses onspecifies the syntax and semanticsof network news articles. [usepro] is also a standards-track document, and describesarticles 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 incremental changes 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 network news articles. [USEPRO] is also a standards-track document, and describes the protocol issues of network news articles, independent of transmission protocols such as NNTP [RFC0977] and IMAP [RFC3501].[RFC0977]. An informational document, [useage],[USEAGE], describes implementation recommendations to improve interoperability and usability. The fourth document, [useint], an experimental standard, specifies internationalizationThis specification is intended as a definition of message headers. The predecessorwhat article content format is to be passed between systems. Though some news systems locally store articles in this document [RFC1036] said that: "In any situation where this standard conflicts with the Internet [email standard,format (which eliminates the latter] should be considered correctneed for translation between formats) and this standardothers use formats that differ from the one specified in error." The basic philosophythis standard, local storage is outside of the scope of this document follows that previous convention, so asstandard. Note: This standard is not intended to standardizedictate the internal formats used by sites, the specific news article syntax firmly as a subsetsystem features that they are expected to support, or any of the Internet Message Format syntax. Notecharacteristics of user interface programs that create or read articles. In addition, this means that all news articles are suitable for email, butstandard does not specify an encoding of the converse isn't necessarily true. Incharacters for either transport or storage; that is, it does not specify the contextnumber of bits used or how those bits are specifically transferred over the Internet messaging architecture, different protocols (such as IMAP, POP3 [RFC1939], NNTPwire or stored on disk. 1.3 Requirements Notation This document occasionally uses terms that appear in capital letters. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and SMTP [RFC2821])"OPTIONAL" in this document are seento be interpreted as alternative ways of moving arounddescribed in [RFC2119]. 1.4 Syntax Notation Headers defined in this specification use the same content. That content is the Internet Message Format as specified by [RFC2822], including optional enhancements such as MIME [RFC2049]. A user should be able to ingest an article via NNTP, read it via IMAP, forward it off to someone else via SMTP and have them read it via POP3 all without having to alter the content. This document uses a cite by reference methodology, rather than trying to repeat 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. 1.2 Requirements Notation 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]. 1.3 Errata The RFC Editor makes available errata for RFCs at [errata]. Implementers should review that page for normative references, noting in particular that errata currently exist for [RFC2046] and [RFC2231]. 1.4 Syntax Notation Headers defined in this specification use the Augmented Backus-Naur Form (ABNF) notation (includingAugmented Backus-Naur Form (ABNF) notation (including the Core Rules) specified in [RFC2234] and many constructs (specifically <date-time>, <mailbox-list>, <obs-zone>, and <unstructured>)defined in [RFC2822]. Section 22.214.171.124 updates the [RFC2822] definition of <msg-id>. 1.5 Definitions An "article" is the unit of news, analogous tosynonymous with an [RFC 2822][RFC2822] "message". A "proto-article""message identifier" Section 3.1.4 is one that has not yet been injected intoa unique identifier for an article, usually supplied by the news system."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 "gateway""control message" is softwarean article which receives news articles and converts them to messages of some other kind (e.g. mail to a mailing list), or vice versa; in essence itis marked as containing control information; a translatingrelaying or serving agent that straddles boundaries between different methods of message exchange. The most common type of gateway connects newsgroup(s)receiving such an article may (subject to mailing list(s), either unidirectionally or bidirectionally, but there are also gateways between news networks using this standard's news formatthe policies observed at that site) take actions beyond just filing and those using other formats.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 defines some additionaldetails the headers necessary to make an article suitable for the netnews environment. 2. Format 2.1 Base News articles MUST conform to the "legal to generate syntax"syntax specified in Section 3 of [RFC2822]. News agents MAY also accept the obsolete syntax specified in Section 4 of [RFC2822], but they MUST NOT generate such syntax. 2.2 MIME Conformance User agents MUST meet the definition of MIME-conformanceHeader Fields All headers fields in [RFC2049]. This level of MIME Conformance provides support for internationalization and multimediaa news article are compliant with [RFC2822], however this specification is more restrictive in message bodies,what can be generated and supportaccepted by news agents. The syntax allowed for internationalizationnews articles is a strict subset of headers.the "Internet Message Format", making all messages compliant with this specification inherently compliant with [RFC2822]. Note however that the generation of internationalized newsgroup names for use in headersconverse is specified by [useint]. 2.3 Additional MIME Support User agents conformant with this document MAY support receipt (and automatic reassembly) of message/partial MIME messages, as specifiednot guaranteed to be true. General rules which apply to all headers (even those documented in Section 5.2.2 of [RFC2046][RFC2822] and MAY support generation of message/ partial articles for excessively large articles. User agents SHOULD support on receipt[RFC2045]) are listed below and MAY generate MIME extension header fields, including but not limitedthose that apply to Content-Disposition [RFC2183] and Content-Language [RFC3282]. 3. Internet Message Format Headers Following [RFC2822] syntax, thespecific headers definedare described in the relevent sections of this document do not require adocument. User agents MUST generate headers so that at least one space betweenimmediately follows the ":"':' separating the header name and the field'sheader contents. (E.g., "Subject:Hello World" is acceptable,As a result, an <unstructured> header as opposed to requiring "Subject: Hello World".) Todefined in Section 3.2.6 of [RFC2822] MUST NOT be compliant with this specification, newsempty (it will always contain at least a single space). News agents MAY accept headers which do not contain the required space. Compliant software MUST support 0 or more spaces betweenheaders of at least 998 octets. This is the colon andonly limit on the field's contents.length of a header line prescribed by this standard. However, specific rules to maximize compatibility withthe installed basecontrary may apply in particular cases (for example, according to [RFC2047] header lines containing encoded-words are limited to 76 octets). NOTE: There is NO restriction on the number of news agents, implementers SHOULD use exactly one space. 3.1 Mandatory Headers Each news article conformant with this specification MUST have exactly onelines into which a header may be split, and hence there is NO restriction on the total length of eacha header (in particular it may, by suitable folding, be made to exceed the 998 octets restriction pertaining to a single header line). The character set for headers is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the following headers: From, Subject, Date, Message-ID, Newsgroups, and Path. From and Subject are exactly as specifiedMIME mechanisms defined in Sections 3.6.2[RFC2045] and 3.6.5 respectively of [RFC2822]. Further discussion of[RFC2231]. 2.3 MIME Conformance User agents MUST meet the contentdefinition of the Subject header is discussedMIME-conformance in [usepro][RFC2049]. This level of MIME Conformance provides support for internationalization and [useage]. Date is fullymultimedia in message bodies [RFC2045], and support for internationalization of headers [RFC2047]. Note that [Errata] currently exist for [RFC2046] and [RFC2231]. 2.4 Additional MIME Support User agents conformant with [RFC2822], though with extra restrictions detailed in Section 3.3 In Section 3.4,this document updates the <msg-id> construct from [RFC2822] soMAY support reassembly of message/partial MIME messages, as to ensure that Internet Message Format Message-IDs are usable in widely deployed news software. Newsgroups and Path are definedspecified in Section 126.96.36.199.2 of [RFC2046] and Section 3.5.2 respectively. 3.2 Optional Headers The headers Reply-To, Sender, Comments,MAY support generation of message/partial articles for excessively large articles. User agents SHOULD accept and Keywords are often usedMAY generate MIME extension header fields, including but not limited to Content-Disposition [RFC2183] and Content-Language [RFC3282]. 3. News Headers The following news headers (also known as header fields) extend the fields defined in section 3.6 of [RFC2822] as follows: 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 articles andarticle. 3.1 Mandatory Headers Each news article conformant with this specification MUST have exactly one of each of the identical meaningfollowing headers: From, Subject, Date, Message-ID, Newsgroups, Path, and Injection-Date. 3.1.1 From The From header is the same as that specified in [RFC2822]. References and In-Reply-To are also regularly usedSection 3.6.2 of [RFC2822] with the added restrictions detailed in news articles and have sameSection 2.2. 3.1.2 Subject The Subject header is the same meaningas that specified in [RFC2822], except that they useSection 3.6.5 of [RFC2822] with the updated <msg-id> construct definedadded restrictions detailed in Section 3.4. The headers Followup-To, Expires, Control, Distribution, Summary, Approved, Organization, Xref, Supersedes, Archive, and User-Agent are often used2.2. Further discussion of the content of the Subject header is discussed in news articles[USEPRO] and are defined in Section 3.5. 3.3[USEAGE]. 3.1.3 Date The Date header is the same as that specified in Sections 3.3 and 3.6.1 of [RFC2822].[RFC2822] with the added restrictions detailed in Section 2.2. However, the use of "GMT" and "UT" as atime zone,zones, which isare part of <obs-zone>, is widespread in news articles today. Therefore, agents MUST accept, but MUST NOT generate, <date-time> constructs which include <obs-zone>. (AsAs stated in Section 2.1, support for <obs-zone> would otherwise have been SHOULD accept, MUST NOT generate.)generate. Note that these requirements apply wherever <date-time> is used, including Injection-Date and Expires in Section 3.5.4. 188.8.131.52 and Section 3.2.3 respectively. 3.1.4 Message-ID The "Message-ID:" fieldMessage-ID header contains a single unique message identifier. This isdocument updates the only header field definition<msg-id> construct from Section 3.6.4 of [RFC2822] so as to ensure that updates [RFC2822].Internet Message Format Message-IDs are usable in widely deployed news software. The ABNF should be used as below, but the requirements and descriptive text from Section 3.6.4 of [RFC2822] still apply. message-id = "Message-ID:" SP msg-id CRLF msg-id = [CFWS][FWS] msg-id-core [CFWS][FWS] msg-id-core = "<" id-left "@" id-right ">" ; maximum length is 250 octets id-left = dot-atom-text / no-fold-quote / obs-id-left id-right = dot-atom-text / no-fold-literal / obs-id-right no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE no-fold-literal = "[" *( htext / no-space-qp ) "]" no-space-qp = ( "\" ptext ) / obs-qp ptext = %d33-61 / ; Printable characters excluding ">" %d63-126 / obs-text htext = HEXDIG / ; hexadecimal digits, case-insensitive "." / ; IPv4 separator ":" ; IPv6 separator Although compliant agentsThe msg-id-core MUST support [CFWS] betweenNOT 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 [RFC0977]) can rely on a bounded length. Observe that msg-id-core includes the "Message-ID:"< and >. Observe that in contrast to the <msg-id-core>, implementers SHOULD generate exactly one space there,corresponding header in [RFC2822], the syntax does not allow comments within the Message-ID header; this is to maximize compatibilitysimplify processing by relaying and serving agents and to ensure interoperability with the installed base. Noteexisting implementations. Also note that this updated ABNF applies wherever <msg-id> is used, including the In-Reply-To andReferences headers mentionedheader discussed in Section 3.2. 3.5 News Headers3.2.1. 3.1.5 Newsgroups The following news headers (also known asNewsgroups header fields) extendspecifies the fields defined in section 3.6 of [RFC2822] as follows: fields =/ *(newsgroup(s) to which the article is posted. newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroup-list = [FWS] newsgroup-name *( "," [FWS] newsgroup-name ) [FWS] newsgroup-name = component *( "." component ) ; 66 character max component = plain-component plain-component = component-start *29component-rest component-start = ALPHA / path / followup-toDIGIT component-rest = ALPHA / expiresDIGIT / control"+" / distribution"-" / summary"_" A newsgroup name consists of one or more components separated by periods, with no more than 66 characters total. Each component consists of less than 30 or less letters and digits. These limits are discussed further in Section 7.2 of [USEAGE]. 3.1.6 Path The Path header indicates the route taken by an article since its entry into the Netnews system, so that unnecessary redundant transmission can be avoided. path = "Path:" SP path-list CRLF path-list = [FWS] path-identity *( path-delimiter [FWS] path-identity ) [FWS] path-identity = ( ALPHA / approvedDIGIT ) *( ALPHA / organizationDIGIT / xref"-" / supersedes"." / archive":" / user-agent"_" ) Eachpath-delimiter = "!" 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. This header is mandatory for new clients, but all agents SHOULD use the Date header for this purpose if Injection-Date is not present. injection-date = "Injection-Date:" SP date-time CRLF See the remarks under Section 3.1.3 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 is discussed in [USEPRO] and [USEAGE]. The headers may occur at most onceReply-To, Sender, Comments, and Keywords are often used in anews article. 3.5.1 Newsgroupsarticles and have the identical meaning as that specified in [RFC2822] with the added restrictions detailed in Section 2.2. The MIME headers Content-Type and Content-Transfer-Encoding are often used in news articles and have the identical meaning as that specified in [RFC2045] with the added restrictions detailed in Section 2.2. All other commonly used news headers are described below. 3.2.1 References The NewsgroupsReferences header specifies to which newsgroup(s) the articleis posted. newsgroups = "Newsgroups:" newsgroup-list CRLF newsgroup-list = [FWS] newsgroup-name *( "," [FWS] newsgroup-name ) [FWS] newsgroup-name = component *( "." component ) ; 71 character max component = plain-component plain-component = component-start *29component-rest component-start = ALPHA / DIGIT component-rest = ALPHA / DIGIT / "+" / "-" / "_" A newsgroup name consiststhe same as that specified in Section 3.6.4 of one or more components separated by periods,[RFC2822] with no more than 71 characters total. Each component consists of less than 30 or less lettersthe added restrictions detailed in Section 2.2 and digits. 3.5.2 Paththose listed below: o The Path header's content indicates which relayers the article has already visited, so that unnecessary redundant transmissionupdated <msg-id> construct defined in Section 3.1.4 MUST be used. o Message IDs MUST be separated with CFWS. o Comments in CFWS between Message IDs can cause interoperability problems, so comments SHOULD NOT be avoided. path = "Path:" [FWS] *( path-host [FWS] path-delimiter [FWS] ) path-host [FWS] CRLF path-host = ( ALPHA / DIGIT ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) path-delimiter = "!" 3.5.3generated, but MUST be accepted. 3.2.2 Followup-To The Followup-To header specifies to which newsgroup(s) followups should be posted. followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) CRLF poster-text = [FWS] %d184.108.40.206.101.114 [FWS] ; "poster" in lower-case The syntax is the same as that of the Newsgroups content,header (Section 3.1.5, with the exception that the magic word "poster" (which is always lowercase) means that followups should be mailed to the article's reply address rather than posted. 3.5.4In order to improve interoperability with deployed clients, 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 useful and could usefully be removed ("expired"). expires = "Expires:" SP date-time CRLF 3.5.5See the remarks under Section 3.1.3 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). control = "Control:" SP [CFWS] control-message [CFWS] CRLF control-message = <empty> The verbcontrol-message 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. Control messages are furthertaken. The exact syntax for control-message is specified in the companion document, [usepro].companion document, [USEPRO]. 3.2.5 Supersedes The Supersedes header contains a message identifier specifying an article to be superseded upon the arrival of this one. The specified article MUST be treated as though a "cancel" [USEPRO] control = "Control:" verb *( FWS argument ) CRLF Anmessage had arrived for the article with(but observe that a Control header MUST NOT havesite MAY choose not to honor a Supersedes header. 3.5.6"cancel" message, especially if its authenticity is in doubt). supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF NOTE: There is no "c" in Supersedes. 3.2.6 Distribution The Distribution header specifies geographic or organizational limits on an article's propagation. distribution = "Distribution:" SP dist-list CRLF list-list = [FWS] dist-name *( "," [FWS] dist-name ) CRLF[FWS] dist-name = [FWS]ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" ) [FWS]"All" MUST NOT be used as a distribution-name. Distribution-names SHOULD contain at least three characters, except when they are two-letter country names as in [ISO.3166.1988]. Distribution-names are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify the same distribution). 220.127.116.11.7 Summary The Summary header is a short phrase summarizing the article's content. summary = "Summary:" SP unstructured CRLF 18.104.22.168.8 Approved The Approved header indicates the mailing addresses (and possibly the full names) of the moderators approving the article for posting. approved = "Approved:" SP mailbox-list CRLF 22.214.171.124.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. 126.96.36.199.10 Xref The Xref header indicates where an article was filed by the last serverserving agent to process it. xref = "Xref:" SP [CFWS] path-hostserver-name 1*( CFWS location ) [CFWS] CRLF server-name = path-identity location = newsgroup-name ":" 1*16DIGIT 3.5.11 Supersedes The Supersedes header specifies articles to be cancelled. supersedesarticle-locator article-locator = "Supersedes:"1*( [FWS] msg-id-core%x21-27 / %x29-3A / %x3C-7E ) CRLF There; US-ASCII printable characters ; except '(' and ';' The server-name is no "c"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 Supersedes. 3.5.12the 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 = <a parameter with attribute "filename" and any value> 188.8.131.52.12 User-Agent The User-Agent header contains information about the user agent (typically a newsreader) generating the article for statistical purposes and tracingtracing of standards violations to specific software needing correction. Although not one of the mandatory headers, posting agents SHOULD normally include it. It is also intended that this header be suitable for use in Email. user-agent = "User-Agent:" SP 1*product CRLF product = [CFWS] token [CFWS] [ "/" product-version ] product-version = [CFWS] token [CFWS] 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] *( ";" injection-info-parameter ) injection-info-parameter = posting-host-parameter / posting-account-parameter / posting-sender-parameter / posting-logging-parameter posting-host-parameter = <a parameter with attribute "posting-host" and value some host-value> host-value = dot-atom / [ dot-atom ":" ] ( IPv4address / IPv6address ) ; see [RFC 2373] posting-account-parameter = <a parameter with attribute "posting-account" and any value> posting-sender-parameter = <a parameter with attribute "sender" and value some sender-value> sender-value = mailbox / "verified" posting-logging-parameter = <a parameter with attribute "logging-data" and any value> Although comments and folding of standards violations to specific software needing correction. Althoughwhite space are permitted throughout the Injection-Info header, it is RECOMMENDED that folding is not one ofused within any parameter (but only before or after the mandatory headers, posting agents SHOULD normally include it.";" separating those parameters), and that comments are only used following the last parameter. It is also intendedRECOMMENDED that this header be suitable for usesuch parameters as are present are included in Email. user-agent = "User-Agent:" 1*( [CFWS] product [ "/" prod-version ] ) CRLF product = token prod-version = tokenthe 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. 4. Internationalization Considerations Internationalization of news article headers and bodies is provided using MIME mechanisms discussed in Section 2.2. Generation2.3. Note that the generation of internationalized messagenewsgroup names for use in headers is not specifiedaddressed in this document, and is instead specified in the experimental standard, [useint].document. 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-forgery.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 (see Section 3.4)(Section 3.1.4) 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. 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. [RFC2646] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, August 1999.[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. [PGPVERIFY] Lawrence, D., "PGPverify <ftp://ftp.isc.org/pub/pgpcontrol/README.html>","PGPverify", June 1999. [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. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.[RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [errata] "RFC Editor Errata <http://www.rfc-editor.org/errata.html>". [useage] "Usenet Implementation Recommendations (work in progress)". [useint] "Usenet Internationalization (work in progress)". [usepro][Son-of-1036] Spencer, H., "News Article Format and Transmission", June 1994. [USEAGE] Lindsey, C., "Usenet Protocol (work in progress)".Best Practice", draft-ietf-usefor-useage-*.txt. [USEPRO] Lindsey, C., "News Article Architecture and Protocols", draft-ietf-usefor-usepro-*.txt. Authors' Addresses Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Chesire SK8 3JU GB Phone: +44 161 436 6131 EMail: firstname.lastname@example.org Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto, CA 94306 US Phone: +1 650 327 2600 EMail: email@example.comKenneth Murchison Oceana Matrix Ltd. 21 Princeton Place Orchard Park, NY 14127 US Phone: +1 716 662 8973 EMail: firstname.lastname@example.org Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto, CA 94306 US Phone: +1 650 327 2600 EMail: email@example.com 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, and Henry Spencer. 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 firstname.lastname@example.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.