summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5536.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5536.txt')
-rw-r--r--doc/rfc/rfc5536.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc5536.txt b/doc/rfc/rfc5536.txt
new file mode 100644
index 0000000..23942a1
--- /dev/null
+++ b/doc/rfc/rfc5536.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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 [RFC5322] and Multipurpose Internet
+ Mail Extensions (MIME) [RFC2045]. This document obsoletes [RFC1036],
+ 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 [RFC1036].
+ This document focuses on the syntax and semantics of Netnews
+ articles. [RFC5537] 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)
+ [RFC3977]. [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 [RFC2119].
+
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 4]
+
+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
+ [RFC5234] as well as many constructs defined in [RFC5322], [RFC2045]
+ as updated by [RFC2231], and [RFC3986]. 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 [RFC5322].
+
+1.5. Definitions
+
+ An "article" is the unit of Netnews, analogous to an [RFC5322]
+ "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]
+
+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]
+
+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 [RFC5322] and to the
+ additional requirements of this specification.
+
+ An article that uses the obsolete syntax specified in Section 4 of
+ [RFC5322] 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 [RFC5322]), 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 [RFC5322]; this grammar is intended to be more
+ restrictive than the [RFC5322] grammar. Articles must conform to the
+
+
+
+
+Murchison, et al. Standards Track [Page 7]
+
+RFC 5536 Netnews Article Format November 2009
+
+
+ ABNF specified in [RFC5322] 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 [RFC5322] calls "header field". This document follows the
+ terminology in Section 2 of [RFC5322] 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 [RFC5322];
+ 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 [RFC5322]. 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 [RFC5322] and [RFC2045]) 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 [RFC3977] 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
+ [RFC5322], this document uses a stricter definition:
+
+ unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
+
+ NOTE: The [RFC5322] 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 [RFC5322]. This is
+
+
+
+Murchison, et al. Standards Track [Page 8]
+
+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 [RFC2047], lines of a header
+ field containing encoded words are limited to 76 octets).
+ [USEAGE] includes suggested limits for convenience of display by
+ user agents.
+
+ NOTE: As stated in [RFC5322], 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 [RFC2047] and [RFC2231].
+
+2.3. MIME Conformance
+
+ User agents MUST meet the definition of MIME conformance in [RFC2049]
+ and MUST also support [RFC2231]. This level of MIME conformance
+ provides support for internationalization and multimedia in message
+ bodies [RFC2045], [RFC2046], and [RFC2231], and support for
+ internationalization of header fields [RFC2047] and [RFC2231]. Note
+ that [Errata] currently exist for [RFC2045], [RFC2046], [RFC2047] and
+ [RFC2231].
+
+ For the purposes of Section 5 of [RFC2047], all header fields defined
+ in Section 3 of this standard are to be considered as "extension
+ message header fields", permitting the use of [RFC2047] 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 [RFC2183]
+ and Content-Language [RFC3282].
+
+3. News Header Fields
+
+ The following news header fields extend those defined in Section 3.6
+ of [RFC5322]:
+
+
+
+Murchison, et al. Standards Track [Page 9]
+
+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 [RFC5322]:
+
+ 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]
+
+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 [RFC5322], 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 [RFC5322], 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 [RFC5322].
+
+ 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 [RFC5322], 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
+ [RFC3977] might have trouble with the full range of possible
+ <msg-id>s permitted by [RFC5322]. This section therefore restricts
+ the syntax of <msg-id> as compared to Section 3.6.4 of [RFC5322].
+ The global uniqueness requirement for <msg-id> in [RFC5322] 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]
+
+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., [RFC3977]) can rely on a bounded length.
+
+ Observe that <msg-id> includes the < and >.
+
+ Observe also that in contrast to the corresponding header field in
+ [RFC5322]:
+
+ 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
+ [RFC3977]. 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]
+
+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 [RFC5322] 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 [RFC5537]). However, such names MUST be accepted by news
+ servers.
+
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 13]
+
+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 [RFC5537]) 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 [RFC5537]; "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]
+
+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 [RFC5537]
+
+ 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 [RFC3696]
+
+ 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]
+
+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 [RFC5537].
+
+ 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 [RFC5322], with the added restrictions detailed above in
+ Section 2.2. Further discussion of the content of the Subject header
+ field appears in [RFC5537] 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 [RFC5537] 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 [RFC5322], 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]
+
+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 [RFC2045], [RFC2183], and [RFC3282], 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 [RFC5537].
+
+ 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]
+
+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
+ [RFC5322]) of the article may also contain details. The legal verbs
+ and respective arguments are discussed in the companion document,
+ [RFC5537].
+
+ 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]
+
+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 [RFC2156].
+
+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]
+
+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 [RFC2045], as
+ amended by [RFC2231]), taken in conjunction with the folding rules
+ of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively
+ allows [CFWS] to occur on either side of the "=" inside a
+ <parameter>.
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 20]
+
+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]
+
+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 [RFC5322], 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]
+
+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"
+ [RFC5537] 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 [RFC2156]; 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]
+
+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: [RFC2616] 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
+ [RFC3977]) is a decimal number, with articles in each newsgroup
+ numbered consecutively starting from 1.
+
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 24]
+
+RFC 5536 Netnews Article Format November 2009
+
+
+3.3. Obsolete Header Fields
+
+ The header fields Date-Received, Posting-Version, and Relay-Version
+ defined in [RFC0850], 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 [RFC5322]) 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 [RFC3977]
+ 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 [RFC3851] or
+ PGP/MIME (Pretty Good Privacy / MIME) [RFC3156], 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]
+
+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 [RFC2046]. Note that
+ the full range of encodings allowed for parameters in [RFC2046] and
+ [RFC2231] permits constructs that simple parsers may fail to parse
+ correctly; examples of hard-to-parse constructs are:
+
+ Content-Type: multipart/mixed
+ (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
+
+ Content-Type: multipart/digest;
+ boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
+
+ Such deficiencies in parsing may be used as part of an attack.
+
+ Further security considerations are discussed in [RFC5537].
+
+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 [RFC3864].
+
+ 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]
+
+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),
+ [RFC5322] (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),
+ [RFC5322] (Section 3.6.1)
+
+ Header field name: Date-Received
+ Applicable protocol: netnews
+ Status: obsoleted
+ Author/change controller: IETF
+ Specification document(s): [RFC0850] (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]
+
+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),
+ [RFC5322] (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),
+ [RFC5322] (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: [RFC3977] (Section 8.1)
+
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 28]
+
+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: [RFC5322] (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): [RFC2980] (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): [RFC0850] (Section 2.1.2)
+
+
+
+
+
+
+
+
+
+Murchison, et al. Standards Track [Page 29]
+
+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),
+ [RFC5322] (Section 3.6.4)
+
+ Header field name: Relay-Version
+ Applicable protocol: netnews
+ Status: obsoleted
+ Author/change controller: IETF
+ Specification document(s): [RFC0850] (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),
+ [RFC5322] (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),
+ [RFC5322] (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),
+ [RFC5322] (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]
+
+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: [RFC2616] (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
+
+ [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.
+
+
+
+
+
+Murchison, et al. Standards Track [Page 31]
+
+RFC 5536 Netnews Article Format November 2009
+
+
+ [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
+ Encoded Word Extensions: Character Sets, Languages,
+ and Continuations", RFC 2231, November 1997.
+
+ [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
+ May 2002.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
+ [RFC5537] 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>.
+
+ [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
+ text messages", STD 11, RFC 822, August 1982.
+
+ [RFC0850] Horton, M., "Standard for interchange of USENET
+ messages", RFC 850, June 1983.
+
+ [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
+ USENET messages", RFC 1036, December 1987.
+
+ [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced
+ Relay): Mapping between X.400 and RFC 822/MIME",
+ RFC 2156, January 1998.
+
+
+
+
+
+Murchison, et al. Standards Track [Page 32]
+
+RFC 5536 Netnews Article Format November 2009
+
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
+ June 1999.
+
+ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
+ April 2001.
+
+ [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980,
+ October 2000.
+
+ [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
+ Roessler, "MIME Security with OpenPGP", RFC 3156,
+ August 2001.
+
+ [RFC3696] Klensin, J., "Application Techniques for Checking and
+ Transformation of Names", RFC 3696, February 2004.
+
+ [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message
+ Specification", RFC 3851, July 2004.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90,
+ RFC 3864, September 2004.
+
+ [RFC3977] 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]
+
+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
+ [RFC1036].
+
+ o The [RFC5322] conventions for parenthesis-enclosed <comment>s in
+ header fields are supported in all newly defined header fields and
+ in header fields inherited from [RFC5322]. 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]
+
+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 [RFC5322].
+
+ The Netnews article format is a strict subset of the Internet Message
+ Format; all Netnews articles conform to the syntax of [RFC5322].
+
+ 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]
+
+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]
+