The RFC Archive
 The RFC Archive   RFC 5536   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 5536

Netnews Article Format

Last modified on Sunday, November 29th, 2009

Permanent link to RFC 5536
Search GitHub Wiki for RFC 5536
Show other RFCs mentioning RFC 5536







Network Working Group                                  K. Murchison, Ed.
Request for Comments: 5536                    Carnegie Mellon University
Obsoletes: 1036                                               C. Lindsey
Category: Standards Track                     University of Manchester
                                                                 D. Kohn
                                                      Healing Thresholds
                                                           November 2009


                         Netnews Article Format

 Abstract

   This document specifies the syntax of Netnews articles in the context
   of the Internet Message Format (RFC 5322) and Multipurpose Internet
   Mail Extensions (MIME) (RFC 2045).  This document obsoletes RFC 1036,
   providing an updated specification to reflect current practice and
   incorporating incremental changes specified in other documents.

 Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

 Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling



Murchison, et al.           Standards Track                  PAGE 1 top


RFC 5536 Netnews Article Format November 2009 the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Murchison, et al. Standards Track PAGE 2 top

RFC 5536 Netnews Article Format November 2009 Table of Contents 1. Introduction ....................................................4 1.1. Basic Concepts .............................................4 1.2. Scope ......................................................4 1.3. Requirements Notation ......................................4 1.4. Syntax Notation ............................................5 1.5. Definitions ................................................5 1.6. Structure of This Document .................................7 2. Format ..........................................................7 2.1. Base .......................................................7 2.2. Header Fields ..............................................8 2.3. MIME Conformance ...........................................9 3. News Header Fields ..............................................9 3.1. Mandatory Header Fields ...................................10 3.1.1. Date ...............................................11 3.1.2. From ...............................................11 3.1.3. Message-ID .........................................11 3.1.4. Newsgroups .........................................13 3.1.5. Path ...............................................14 3.1.6. Subject ............................................16 3.2. Optional Header Fields ....................................16 3.2.1. Approved ...........................................17 3.2.2. Archive ............................................17 3.2.3. Control ............................................17 3.2.4. Distribution .......................................18 3.2.5. Expires ............................................19 3.2.6. Followup-To ........................................19 3.2.7. Injection-Date .....................................20 3.2.8. Injection-Info .....................................20 3.2.9. Organization .......................................22 3.2.10. References ........................................22 3.2.11. Summary ...........................................23 3.2.12. Supersedes ........................................23 3.2.13. User-Agent ........................................23 3.2.14. Xref ..............................................24 3.3. Obsolete Header Fields ....................................25 3.3.1. Lines ..............................................25 4. Internationalization Considerations ............................25 5. Security Considerations ........................................25 6. IANA Considerations ............................................26 7. References .....................................................31 7.1. Normative References ......................................31 7.2. Informative References ....................................32 Appendix A. Acknowledgments ......................................34 Appendix B. Differences from RFC 1036 and Its Derivatives ........34 Appendix C. Differences from RFC 5322 ............................35 Murchison, et al. Standards Track PAGE 3 top

RFC 5536 Netnews Article Format November 2009 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 that 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 who are able to access that server. 1.2. Scope This document specifies the syntax of Netnews articles in the context of the Internet Message Format [RFC 5322] and Multipurpose Internet Mail Extensions (MIME) [RFC 2045]. This document obsoletes [RFC 1036], updating the syntax of Netnews articles 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 [RFC 1036]. This document focuses on the syntax and semantics of Netnews articles. [RFC 5537] is also a Standards Track document and describes the protocol issues of Netnews articles, independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC 3977]. [USEAGE], "Usenet Best Practice", 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. Although many news systems locally store articles in this format (which eliminates the need for translation between formats), local storage is outside of the scope of this standard. 1.3. 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 [RFC 2119]. Murchison, et al. Standards Track PAGE 4 top

RFC 5536 Netnews Article Format November 2009 1.4. Syntax Notation Header fields defined in this specification use the Augmented Backus- Naur Form (ABNF) notation (including the Core Rules) specified in [RFC 5234] as well as many constructs defined in [RFC 5322], [RFC 2045] as updated by [RFC 2231], and [RFC 3986]. Specifically: token = <see RFC 2045 Section 5.1> value = <see RFC 2045 Section 5.1> parameter = <see RFC 2231 Section 7> attribute = <see RFC 2231 Section 7> FWS = <see RFC 5322 Section 3.2.2> comment = <see RFC 5322 Section 3.2.2> CFWS = <see RFC 5322 Section 3.2.2> atext = <see RFC 5322 Section 3.2.3> dot-atom-text = <see RFC 5322 Section 3.2.3> phrase = <see RFC 5322 Section 3.2.5> date-time = <see RFC 5322 Section 3.3> mailbox = <see RFC 5322 Section 3.4> mailbox-list = <see RFC 5322 Section 3.4> address-list = <see RFC 5322 Section 3.4> body = <see RFC 5322 Section 3.5> fields = <see RFC 5322 Section 3.6> IPv6address = <see RFC 3986 Section 3.2.2> IPv4address = <see RFC 3986 Section 3.2.2> ALPHA = <see RFC 5234 Appendix B.1> CRLF = <see RFC 5234 Appendix B.1> DIGIT = <see RFC 5234 Appendix B.1> DQUOTE = <see RFC 5234 Appendix B.1> SP = <see RFC 5234 Appendix B.1> VCHAR = <see RFC 5234 Appendix B.1> Additionally, Section 3.1.3 specifies a stricter definition of <msg-id> than the syntax in Section 3.6.4 of [RFC 5322]. 1.5. Definitions An "article" is the unit of Netnews, analogous to an [RFC 5322] "message". A "proto-article" is one that has not yet been injected into the news system. In contrast 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 that posted it or, failing that, by the "news server". It distinguishes the article Murchison, et al. Standards Track PAGE 5 top

RFC 5536 Netnews Article Format November 2009 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 forum having a name and that is 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 potentially compliant article to a user agent. A "reader" is the person or software reading Netnews articles. A "followup" is an article containing a response to the contents of 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 that 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. An agent is said to "generate" a construct if it did not exist before the agent created it. Examples are when a user agent creates a message from text and addressing information supplied by a user, or when a news server creates an "Injection-Info" header field for a newly posted message. Murchison, et al. Standards Track PAGE 6 top

RFC 5536 Netnews Article Format November 2009 An agent is said to "accept" a construct if some other entity generates it and passes it to the agent in question, and the agent processes it without treating it as a format or protocol error. 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 Netnews articles. Section 3 details the header fields necessary to make an article suitable for the Netnews environment. 2. Format 2.1. Base An article is said to be conformant to this specification if it conforms to the format specified in Section 3 of [RFC 5322] and to the additional requirements of this specification. An article that uses the obsolete syntax specified in Section 4 of [RFC 5322] is NOT conformant to this specification, except for the following two cases: o Articles are conformant if they use the <obs-phrase> construct (use of a phrase like "John Q. Public" without the use of quotes, see Section 4.1 of [RFC 5322]), but agents MUST NOT generate productions of such syntax. o Articles are conformant if they use the "GMT" <zone>, as specified in Section 3.1.1. This document, and specifications that build upon it, specify 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 [RFC 5322]; this grammar is intended to be more restrictive than the [RFC 5322] grammar. Articles must conform to the Murchison, et al. Standards Track PAGE 7 top

RFC 5536 Netnews Article Format November 2009 ABNF specified in [RFC 5322] and also to the restrictions specified here, both those that are expressed as text and those that are expressed as ABNF. NOTE: Other specifications use the term "header" as a synonym for what [RFC 5322] calls "header field". This document follows the terminology in Section 2 of [RFC 5322] 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 Netnews article are compliant with [RFC 5322]; this specification, however, is less permissive in what can be generated and accepted by agents. The syntax allowed for Netnews article headers is a strict subset of the Internet Message Format headers, making all headers compliant with this specification inherently compliant with [RFC 5322]. Note however that the converse is not guaranteed to be true in all cases. General rules that apply to all header fields (even those documented in [RFC 5322] and [RFC 2045]) are listed below, and those that apply to specific header fields are described in the relevant 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 [RFC 3977] servers). News agents MAY accept header fields that 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, rather than using the <unstructured> syntax from Section 3.2.5 of [RFC 5322], this document uses a stricter definition: unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP NOTE: The [RFC 5322] specification sometimes uses [FWS] at the beginning or end of ABNF describing header field content. This specification uses *WSP in such cases, also in cases where this specification redefines constructs from [RFC 5322]. This is Murchison, et al. Standards Track PAGE 8 top

RFC 5536 Netnews Article Format November 2009 done for consistency with the restriction described here, but the restriction applies to all header fields, not just those where ABNF is defined in this document. o Compliant software MUST NOT generate (but MAY accept) header field lines of more than 998 octets. This is the only limit on the length of a header field line prescribed by this standard. However, specific rules to the contrary may apply in particular cases (for example, according to [RFC 2047], 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: As stated in [RFC 5322], 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-octet restriction pertaining to a single header field 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 [RFC 2047] and [RFC 2231]. 2.3. MIME Conformance User agents MUST meet the definition of MIME conformance in [RFC 2049] and MUST also support [RFC 2231]. This level of MIME conformance provides support for internationalization and multimedia in message bodies [RFC 2045], [RFC 2046], and [RFC 2231], and support for internationalization of header fields [RFC 2047] and [RFC 2231]. Note that [Errata] currently exist for [RFC 2045], [RFC 2046], [RFC 2047] and [RFC 2231]. For the purposes of Section 5 of [RFC 2047], all header fields defined in Section 3 of this standard are to be considered as "extension message header fields", permitting the use of [RFC 2047] encodings within any <unstructured> header field, or within any <comment> or <phrase> permitted within any structured header field. User agents MAY accept and generate other MIME extension header fields, and in particular SHOULD accept Content-Disposition [RFC 2183] and Content-Language [RFC 3282]. 3. News Header Fields The following news header fields extend those defined in Section 3.6 of [RFC 5322]: Murchison, et al. Standards Track PAGE 9 top

RFC 5536 Netnews Article Format November 2009 fields =/ *( approved / archive / control / distribution / expires / followup-to / injection-date / injection-info / lines / newsgroups / organization / path / summary / supersedes / user-agent / xref ) Each of these header fields MUST NOT occur more than once in a news article. The following header fields defined in this document do not allow <comment>s (i.e., they use FWS rather than CFWS). Control Distribution Followup-To Lines Newsgroups Path Supersedes Xref This also applies to the following header field defined in [RFC 5322]: Message-ID Most of these header fields are mainly of interest to news servers, and news servers often need to process these fields very rapidly. Thus, some header fields prohibit <comment>s. 3.1. Mandatory Header Fields Each Netnews article conformant with this specification MUST have exactly one of each of the following header fields: Date, From, Message-ID, Newsgroups, Path, and Subject. Murchison, et al. Standards Track PAGE 10 top

RFC 5536 Netnews Article Format November 2009 3.1.1. Date The Date header field is the same as that specified in Sections 3.3 and 3.6.1 of [RFC 5322], with the added restrictions detailed above in Section 2.2. However, the use of "GMT" as a time zone (part of <obs-zone>), although deprecated, is widespread in Netnews articles today. Therefore, agents MUST accept <date-time> constructs that use the "GMT" zone. orig-date = "Date:" SP date-time CRLF NOTE: This specification does not change [RFC 5322], which says that agents MUST NOT generate <date-time> constructs that include any zone names defined by <obs-zone>. Software that accepts dates with unknown timezones SHOULD treat such timezones as equivalent to "-0000" when comparing dates, as specified in Section 4.3 of [RFC 5322]. Also note that these requirements apply wherever <date-time> is used, including Injection-Date and Expires (Sections 3.2.7 and 3.2.5, respectively). 3.1.2. From The From header field is the same as that specified in Section 3.6.2 of [RFC 5322], with the added restrictions detailed above in Section 2.2. from = "From:" SP mailbox-list CRLF 3.1.3. Message-ID The Message-ID header field contains a unique message identifier. Netnews is more dependent on message identifier uniqueness and fast comparison than Email is, and some news software and standards [RFC 3977] might have trouble with the full range of possible <msg-id>s permitted by [RFC 5322]. This section therefore restricts the syntax of <msg-id> as compared to Section 3.6.4 of [RFC 5322]. The global uniqueness requirement for <msg-id> in [RFC 5322] is to be understood as applying across all protocols using such message identifiers, and across both Email and Netnews in particular. message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF msg-id = "<" msg-id-core ">" ; maximum length is 250 octets Murchison, et al. Standards Track PAGE 11 top

RFC 5536 Netnews Article Format November 2009 msg-id-core = id-left "@" id-right id-left = dot-atom-text id-right = dot-atom-text / no-fold-literal 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 that accept message identifiers as a parameter when referencing an article (e.g., [RFC 3977]) can rely on a bounded length. Observe that <msg-id> includes the < and >. Observe also that in contrast to the corresponding header field in [RFC 5322]: o The syntax does not allow comments within the Message-ID header field. o There is no possibility for ">" or WSP to occur inside a <msg-id>. o Even though commonly derived from <domain>s, <id-rights>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 [RFC 3977]. A simple comparison of octets will always suffice to determine the identity of two <msg-id>s. Also note that this updated ABNF applies wherever <msg-id> is used, including the References header field discussed in Section 3.2.10 and the Supersedes header field discussed in Section 3.2.12. Some software will try to match the <id-right> of a <msg-id> in a case-insensitive fashion; some will match it in a case-sensitive fashion. Implementations MUST NOT generate a Message-ID where the only difference from another Message-ID is the case of characters in the <id-right> part. Murchison, et al. Standards Track PAGE 12 top

RFC 5536 Netnews Article Format November 2009 When generating a <msg-id>, implementations SHOULD use a domain name as the <id-right>. NOTE: Section 3.6.4 of [RFC 5322] recommends that the <id-right> 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. Newsgroups The Newsgroups header field specifies the newsgroup(s) to which the article is posted. newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroup-list = *WSP newsgroup-name *( [FWS] "," [FWS] newsgroup-name ) *WSP newsgroup-name = component *( "." component ) component = 1*component-char component-char = ALPHA / DIGIT / "+" / "-" / "_" Not all servers support optional FWS in the list of newsgroups. In particular, folding the Newsgroups header field over several lines has been shown to harm propagation significantly. Optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted. A <component> SHOULD NOT consist solely of digits and SHOULD NOT contain uppercase letters. Such <component>s MAY be used only to refer to existing groups that do not conform to this naming scheme, but MUST NOT be used otherwise. NOTE: All-digit <component>s 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 <newsgroup-name>s. <component>s beginning with underline ("_") are reserved for use by future versions of this standard and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages as defined by [RFC 5537]). However, such names MUST be accepted by news servers. Murchison, et al. Standards Track PAGE 13 top

RFC 5536 Netnews Article Format November 2009 <component>s beginning with "+" and "-" are reserved for private use and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages [RFC 5537]) without a private prior agreement to do so. However, such names MUST be accepted by news servers. The following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup: o Groups whose first (or only) <component> is "example" o The group "poster" The following <newsgroup-name>s have been used for specific purposes in various implementations and protocols and therefore MUST NOT be used for the names of normal newsgroups. They MAY be used for their specific purpose or by local agreement. o Groups whose first (or only) component is "to" o Groups whose first (or only) component is "control" o Groups that contain (or consist only of) the component "all" o Groups that contain (or consist only of) the component "ctl" o The group "junk" NOTE: "example.*" is reserved for examples in this and other standards; "poster" has a special meaning in the Followup-To header field; "to.*" is reserved for certain point-to-point communications in conjunction with the "ihave" control message as defined in [RFC 5537]; "control.*" and "junk" have special meanings in some news servers; "all" is used as a wildcard in some implementations; and "ctl" was formerly used to indicate a <control-command> within the Newsgroups header field. 3.1.5. 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 at least one <path-identity> to this header field body. This is primarily so that news servers are able to avoid sending articles to sites already known to have them, in particular the site they came from. Additionally, it permits gathering statistics and tracing the route articles take in moving over the network. Murchison, et al. Standards Track PAGE 14 top

RFC 5536 Netnews Article Format November 2009 path = "Path:" SP *WSP path-list tail-entry *WSP CRLF path-list = *( path-identity [FWS] [path-diagnostic] "!" ) path-diagnostic = diag-match / diag-other / diag-deprecated diag-match = "!" ; another "!" diag-other = "!." diag-keyword [ "." diag-identity ] [FWS] diag-deprecated = "!" IPv4address [FWS] diag-keyword = 1*ALPHA ; see [RFC 5537] diag-identity = path-identity / IPv4address / IPv6address tail-entry = path-nodot ; may be the string "not-for-mail" path-identity = ( 1*( label "." ) toplabel ) / path-nodot path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names label = alphanum [ *( alphanum / "-" ) alphanum ] toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / ( label 1*( "-" ) label ) alphanum = ALPHA / DIGIT ; compare [RFC 3696] A <path-identity> is a name identifying a site. It takes the form of a domain name having two or more components separated by dots, or a single name with no dots (<path-nodot>). Each <path-identity> in the <path-list> (which does not include the <tail-entry>) indicates, from right to left, the successive agents through which the article has passed. The use of the <diag-match>, which appears as "!!", indicates that the agent to its left verified the identity of the agent to its right before accepting the article (whereas the <path-delimiter> "!" implies no such claim). NOTE: Historically, the <tail-entry> indicated the name of the sender. If not used for this purpose, the string "not-for-mail" is often used instead (since at one time the whole path could be used as a mail address for the sender). Murchison, et al. Standards Track PAGE 15 top

RFC 5536 Netnews Article Format November 2009 NOTE: Although case-insensitive, it is intended that the <diag-keyword>s should be in uppercase, to distinguish them from the <path-identity>s, which are traditionally in lowercase. A <path-diagnostic> is an item inserted into the Path header field for purposes other than to indicate the name of a site. The use of these is described in [RFC 5537]. NOTE: One usage of a <path-diagnostic> is to record an IP address. The fact that <IPv6address>es are allowed means that the colon (:) is permitted; note that this may cause interoperability problems at older sites that regard ":" as a <path-delimiter> and have neighbors whose names have 4 or fewer characters, and where all the characters are valid HEX digits. NOTE: Although <IPv4address>es have occasionally been used in the past (usually with a diagnostic intent), their continued use is deprecated (though it is still acceptable in the form of the <diag-deprecated>). 3.1.6. Subject The Subject header field is the same as that specified in Section 3.6.5 of [RFC 5322], with the added restrictions detailed above in Section 2.2. Further discussion of the content of the Subject header field appears in [RFC 5537] and [USEAGE]. subject = "Subject:" SP unstructured CRLF 3.2. Optional Header Fields None of the header fields appearing in this section are 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 [RFC 5537] and [USEAGE]. The header fields Comments, Keywords, Reply-To, and Sender are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC 5322], with the added restrictions detailed above in Section 2.2. Multiple occurrences of the Keywords header field are not permitted. comments = "Comments:" SP unstructured CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF Murchison, et al. Standards Track PAGE 16 top

RFC 5536 Netnews Article Format November 2009 reply-to = "Reply-To:" SP address-list CRLF sender = "Sender:" SP mailbox CRLF The MIME header fields MIME-Version, Content-Type, Content-Transfer- Encoding, Content-Disposition, and Content-Language are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC 2045], [RFC 2183], and [RFC 3282], with the added restrictions detailed above in Section 2.2. All remaining news header fields are described below. 3.2.1. 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; see [RFC 5537]. approved = "Approved:" SP mailbox-list CRLF 3.2.2. 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. archive = "Archive:" SP [CFWS] ("no" / "yes") *( [CFWS] ";" [CFWS] archive-param ) [CFWS] 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. A field body of "yes" indicates that the poster permits such redistribution. No <parameter>s are currently defined; if present, they can be ignored. Further discussion of the use of the Archive header field appears in [USEAGE]. 3.2.3. Control The Control header field marks the article as a control message and specifies the desired actions (in addition to the usual actions of storing and/or relaying the article). Murchison, et al. Standards Track PAGE 17 top

RFC 5536 Netnews Article Format November 2009 control = "Control:" SP *WSP control-command *WSP CRLF control-command = verb *( 1*WSP argument ) verb = token argument = 1*( %x21-7E ) The verb indicates what action should be taken, and the argument(s) (if any) supply details. In some cases, the <body> (as defined in [RFC 5322]) of the article may also contain details. The legal verbs and respective arguments are discussed in the companion document, [RFC 5537]. An article with a Control header field MUST NOT also have a Supersedes header field. 3.2.4. Distribution The Distribution header field specifies geographic or organizational limits on an article's propagation. distribution = "Distribution:" SP dist-list CRLF dist-list = *WSP dist-name *( [FWS] "," [FWS] dist-name ) *WSP dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" ) The <dist-name>s "world" and "local" are reserved. "world" indicates unlimited distribution and SHOULD NOT be used explicitly, since it is the default when the Distribution header field is absent entirely. "local" is reserved for indicating distribution only to the local site, as defined by local software configuration. "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 codes drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e., "US", "Us", "uS", and "us" all specify the same distribution). Optional FWS in the <dist-list> SHOULD NOT be generated, but MUST be accepted. Murchison, et al. Standards Track PAGE 18 top

RFC 5536 Netnews Article Format November 2009 3.2.5. Expires The Expires header field specifies a date and time when the poster deems the article to be no longer relevant and could usefully be removed ("expired"). NOTE: This header field is useful when the poster desires an unusually long or an unusually short expiry time. expires = "Expires:" SP date-time CRLF See the remarks under Section 3.1.1 regarding the syntax of <date-time> and the requirements and recommendations to which it is subject. NOTE: The Expires header field is also sometimes used in Email with a similar meaning; see [RFC 2156]. 3.2.6. Followup-To The Followup-To header field specifies to which newsgroup(s) the poster has requested that followups are to 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 = *WSP %d112.111.115.116.101.114 *WSP ; "poster" in lowercase The syntax is the same as that of the Newsgroups (Section 3.1.4) header field, with the exception that the keyword "poster" requests that followups should be emailed directly to the article's poster (using the addresses contained in the Reply-To header field if one exists, otherwise using the addresses contained in the From header field) rather than posted to any newsgroups. Agents MUST generate the keyword "poster" in lowercase, but MAY choose to recognize case- insensitive forms such as "Poster". As in the Newsgroups (Section 3.1.4) header field, optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted. Murchison, et al. Standards Track PAGE 19 top

RFC 5536 Netnews Article Format November 2009 3.2.7. Injection-Date The Injection-Date header field contains the date and time that the article was injected into the network. Its purpose is to enable news servers, when checking for "stale" articles, to use a <date-time> that was added by a news server at injection time rather than one added by the user agent at message composition time. 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.1 regarding the syntax of <date-time> and the requirements and recommendations to which it is subject. NOTE: Since clocks on various agents are not necessarily synchronized, the <date-time> in this header field might not be a later value than that in the Date header field. Agents MUST NOT alter a pre-existing Date header field when adding an Injection- Date header field. This header field is intended to replace the currently used but undocumented "NNTP-Posting-Date" header field, whose use is now deprecated. 3.2.8. Injection-Info The Injection-Info header field contains information provided by the injecting news server as to how an article entered the Netnews system; it assists in tracing the article's 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] *( ";" [CFWS] parameter ) [CFWS] CRLF NOTE: The syntax of <parameter> (Section 5.1 of [RFC 2045], as amended by [RFC 2231]), taken in conjunction with the folding rules of [RFC 822] (note: not [RFC 2822] or [RFC 5322]), effectively allows [CFWS] to occur on either side of the "=" inside a <parameter>. Murchison, et al. Standards Track PAGE 20 top

RFC 5536 Netnews Article Format November 2009 The following table gives the <attribute> and the format of the <value> for each <parameter> defined for use with this header field. At most, one occurrence of each such <parameter> is allowed. <attribute> format of <value> -------------------- ----------------- "posting-host" a <host-value> "posting-account" any <value> "logging-data" any <value> "mail-complaints-to" an <address-list> where host-value = dot-atom-text / IPv4address / IPv6address / (dot-atom-text ":" ( IPv4address / IPv6address )) NOTE: Since any such <host-value> or <address-list> also has to be a syntactically correct <value>, it will usually be necessary to encapsulate it as a <quoted-string>, for example: posting-host = "posting.example.com:192.0.2.1" Other <attribute>s SHOULD NOT be used unless defined in extensions to this standard. If non-standards-based <attribute>s are used, they MUST begin with an "x-". Although comments and folding of whitespace are permitted throughout the Injection-Info header field, folding SHOULD NOT be used within any <parameter>. Folding SHOULD only occur before or after the ";" separating <parameter>s, and comments SHOULD only be used following the last <parameter>. 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 generates an Injection-Info header field, it should have no need to send these non-standard header fields. The "posting-host" <parameter> specifies the Fully Qualified Domain Name (FQDN) and/or IP address (IPv4address or IPv6address) of the host from which the news server received the article. NOTE: If the "posting-host" <parameter> fails to deterministically identify the host (e.g., dynamic IP address allocation), the "posting-account" or "logging-data" <parameter> may provide additional information about the true origin of the article. Murchison, et al. Standards Track PAGE 21 top

RFC 5536 Netnews Article Format November 2009 The "posting-account" <parameter> identifies the source from which that news server received the article, in a notation that can be interpreted by the news server administrator. This notation can include any information the administrator deems pertinent. In order to limit the exposure of personal data, it SHOULD be given in a form that cannot be interpreted by other sites. However, to make it useful for rate limiting and abuse detection, two messages posted from the same source SHOULD have the same value of "posting-account", and two messages from different sources SHOULD have differing values of "posting-account". The exact definition of "source" is left to the discretion of the news server administrator. The "logging-data" <parameter> contains information (typically a session number or other non-persistent means of identifying a posting account) that 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" <parameter> specifies one or more mailboxes for sending complaints concerning the behavior of the poster of the article. It is a matter of local policy which of the above <parameter>s to include. Some pieces of information have privacy implications; this is discussed in [USEAGE]. 3.2.9. Organization The Organization header field is a short phrase identifying the poster's organization. organization = "Organization:" SP unstructured CRLF NOTE: There is no "s" in Organization. 3.2.10. References The References header field is the same as that specified in Section 3.6.4 of [RFC 5322], with the added restrictions detailed above in Section 2.2 and those listed below: o The updated <msg-id> construct defined in Section 3.1.3 MUST be used. o Message identifiers MUST be separated with CFWS. Murchison, et al. Standards Track PAGE 22 top

RFC 5536 Netnews Article Format November 2009 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.11. Summary The Summary header field is a short phrase summarizing the article's content. summary = "Summary:" SP unstructured CRLF 3.2.12. 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" [RFC 5537] control message for the specified article, followed immediately by the new article without the Supersedes header field. supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF NOTE: There is no "c" in Supersedes. 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 [RFC 2156]; in particular, the syntax here permits only one <msg-id> in contrast to the multiple <msg-id>s in that Email version. 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 in need of 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 Murchison, et al. Standards Track PAGE 23 top

RFC 5536 Netnews Article Format November 2009 This header field MAY contain multiple <product> tokens identifying the user agent and any subproducts that 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 generates a User-Agent header field, it should have no need to send these non-standard header fields. NOTE: [RFC 2616] describes a similar facility for the HTTP protocol. The Netnews article format differs in that "{" and "}" are allowed in tokens (<product> and <product-version>) and comments are permitted wherever white space is allowed. 3.2.14. Xref The Xref header field indicates where an article was filed by the last news server to process it. User agents often use the information in the Xref header field to avoid multiple processing of crossposted articles. xref = "Xref:" SP *WSP server-name 1*( FWS location ) *WSP 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 news server generated the header field. The locations specify where the article is filed -- i.e., under which newsgroups (which may differ from those in the Newsgroups header field), and where under those newsgroups. The exact form of an <article-locator> is implementation-specific. NOTE: The traditional form of an <article-locator> (as required by [RFC 3977]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1. Murchison, et al. Standards Track PAGE 24 top

RFC 5536 Netnews Article Format November 2009 3.3. Obsolete Header Fields The header fields Date-Received, Posting-Version, and Relay-Version defined in [RFC 850], as well as Also-Control, Article-Names, Article-Updates, and See-Also defined in [Son-of-1036] are declared obsolete. See the cited specification documents for further information on their original use. These header fields MUST NOT be generated and SHOULD be ignored. 3.3.1. Lines The Lines header field indicates the number of lines in the <body> (as defined in [RFC 5322]) of the article. lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF The line count is the number of CRLF separators in the <body>. Historically, this header field was used by the NNTP [RFC 3977] overview facility, 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. All agents SHOULD ignore it and SHOULD NOT generate it. 4. Internationalization Considerations Internationalization of Netnews article header fields and bodies is provided using the MIME mechanisms discussed in Section 2.3. Note that the generation of internationalized <newsgroup-name>s for use in header fields is not addressed in this document. 5. Security Considerations The Netnews 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 [RFC 3851] or PGP/MIME (Pretty Good Privacy / MIME) [RFC 3156], or below, using secure versions of news transport protocols. Additionally, several currently non-standardized protocols such as [PGPVERIFY] may be standardized in the near future. Message identifiers (Section 3.1.3) in Netnews articles are required to be unique; articles may be refused (in server-to-server transfer) if the identifier has already been seen. If a malicious agent can predict the identifier of an article, it can preempt the article by posting its own article (possibly to a quite different group) with Murchison, et al. Standards Track PAGE 25 top

RFC 5536 Netnews Article Format November 2009 the same message identifier, thereby preventing the target article from propagating. Therefore, agents that generate message identifiers for Netnews articles SHOULD ensure that they are unpredictable. MIME security considerations are discussed in [RFC 2046]. Note that the full range of encodings allowed for parameters in [RFC 2046] and [RFC 2231] 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 deficiencies in parsing may be used as part of an attack. Further security considerations are discussed in [RFC 5537]. 6. IANA Considerations IANA has registered the following header fields in the Permanent Message Header Field Repository, in accordance with the procedures set out in [RFC 3864]. Header field name: Also-Control Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.15) Header field name: Approved Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.1) Header field name: Archive Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.2) Murchison, et al. Standards Track PAGE 26 top

RFC 5536 Netnews Article Format November 2009 Header field name: Article-Names Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.17) Header field name: Article-Updates Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.18) Header field name: Comments Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC 5322] (Section 3.6.5) Header field name: Control Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.3) Header field name: Date Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.1), [RFC 5322] (Section 3.6.1) Header field name: Date-Received Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC 850] (Section 2.2.4) Header field name: Distribution Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.4) Murchison, et al. Standards Track PAGE 27 top

RFC 5536 Netnews Article Format November 2009 Header field name: Expires Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.5) Header field name: Followup-To Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.6) Header field name: From Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.2), [RFC 5322] (Section 3.6.2) Header field name: Injection-Date Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.7) Header field name: Injection-Info Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.8) Header field name: Keywords Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC 5322] (Section 3.6.5) Header field name: Lines Applicable protocol: netnews Status: deprecated Author/change controller: IETF Specification document(s): This document (Section 3.3.1) Related information: [RFC 3977] (Section 8.1) Murchison, et al. Standards Track PAGE 28 top

RFC 5536 Netnews Article Format November 2009 Header field name: Message-ID Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.3) Related information: [RFC 5322] (Section 3.6.4) Header field name: Newsgroups Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.4) Header field name: NNTP-Posting-Date Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): none Header field name: NNTP-Posting-Host Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC 2980] (Section 3.4.1) Header field name: Organization Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.9) Header field name: Path Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.5) Header field name: Posting-Version Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC 850] (Section 2.1.2) Murchison, et al. Standards Track PAGE 29 top

RFC 5536 Netnews Article Format November 2009 Header field name: References Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.10), [RFC 5322] (Section 3.6.4) Header field name: Relay-Version Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC 850] (Section 2.1.1) Header field name: Reply-To Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC 5322] (Section 3.6.2) Header field name: See-Also Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.16) Header field name: Sender Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC 5322] (Section 3.6.2) Header field name: Subject Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.6), [RFC 5322] (Section 3.6.5) Header field name: Summary Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.11) Murchison, et al. Standards Track PAGE 30 top

RFC 5536 Netnews Article Format November 2009 Header field name: Supersedes Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.12) Header field name: User-Agent Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.13) Related information: [RFC 2616] (Section 14.43) Header field name: Xref Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.14) 7. References 7.1. Normative References [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC 2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. Murchison, et al. Standards Track PAGE 31 top

RFC 5536 Netnews Article Format November 2009 [RFC 2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC 3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. [RFC 3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC 5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC 5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC 5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, November 2009. 7.2. Informative References [Errata] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997. [PGPVERIFY] Lawrence, D., "Authentication of Usenet Group Changes (pgpverify)", June 1999, <ftp://ftp.isc.org/pub/pgpcontrol/README.html>. [RFC 822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC 850] Horton, M., "Standard for interchange of USENET messages", RFC 850, June 1983. [RFC 1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987. [RFC 2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. Murchison, et al. Standards Track PAGE 32 top

RFC 5536 Netnews Article Format November 2009 [RFC 2616] 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. [RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000. [RFC 3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC 3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004. [RFC 3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC 3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC 3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006. [Son-of-1036] Spencer, H., "Son of 1036: News Article Format and Transmission", Work in Progress, May 2009. [USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005. Murchison, et al. Standards Track PAGE 33 top

RFC 5536 Netnews Article Format November 2009 Appendix A. Acknowledgments As this document is the result of an eight-year effort, the number of people that have contributed to its content are too numerous to mention individually. Many thanks go out to all past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and its accompanying mailing list. 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 [RFC 1036]. o The [RFC 5322] conventions for parenthesis-enclosed <comment>s in header fields are supported in all newly defined header fields and in header fields inherited from [RFC 5322]. They are, however, still disallowed for performance and/or compatibility reasons in the Control, Distribution, Followup-To, Lines, Message-ID, Newsgroups, Path, Supersedes, and Xref header fields. o Multiple addresses are allowed in the From header field. o [FWS] is permitted in Newsgroups header fields. o 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. o Only one (1) message identifier is allowed in the Supersedes header field. o MIME is recognized as an integral part of Netnews. o There is a new Injection-Date header field to make the rejection of stale articles more precise and to minimize spurious rejections. o There are several new optional header fields defined, notably Archive, Injection-Info, and User-Agent, leading to increased functionality. o Certain header fields, notably Lines, have been deprecated or made obsolete (Section 3.3). o The convention to interpret subjects starting with the word "cmsg" as a control message was removed. Murchison, et al. Standards Track PAGE 34 top

RFC 5536 Netnews Article Format November 2009 o There are numerous other small changes, clarifications, and enhancements. Appendix C. Differences from RFC 5322 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 [RFC 5322]. The Netnews article format is a strict subset of the Internet Message Format; all Netnews articles conform to the syntax of [RFC 5322]. The following restrictions are important: o A SP (space) is REQUIRED after the colon (':') following a header field name. o A slightly restricted syntax of <msg-id> (to be used by the Message-ID, References, and Supersedes header fields) is defined. o The length of a <msg-id> MUST NOT exceed 250 octets. o Comments are not allowed in the Message-ID header field. o The CFWS between <msg-id>s in the References header field is not optional. o It is legal for a parser to reject obsolete syntax, except that: * The <obs-phrase> construct MUST be accepted. * The obsolete <zone> "GMT" MUST be accepted within a <date-time>. 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. This means that an empty header field body is illegal. Murchison, et al. Standards Track PAGE 35 top

RFC 5536 Netnews Article Format November 2009 Authors' Addresses Kenneth Murchison (editor) Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 U.S.A. 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 U.K. Phone: +44 161 436 6131 EMail: chl@clerew.man.ac.uk Dan Kohn Healing Thresholds 211 N End Ave Apt 22E New York, NY 10282 U.S.A. Phone: +1 415 233 1000 EMail: dan@dankohn.com Murchison, et al. Standards Track PAGE 36 top

Netnews Article Format RFC TOTAL SIZE: 71817 bytes PUBLICATION DATE: Sunday, November 29th, 2009 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 5536: The IETF Trust, Sunday, November 29th, 2009
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement