GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5536

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5536.txt · Last modified: 2009/11/29 03:08 (external edit)