Usenet Format Working Group                            K. Murchison, Ed.
Internet-Draft                                Carnegie Mellon University
Obsoletes: 1036 (if approved)                                 C. Lindsey
Expires: November 23, 2006
Intended status: Standards Track                University of Manchester
Expires: March 1, 2007                                           D. Kohn
                                                           FlyDash, Inc.
                                                            May 22,
                                                         August 28, 2006

                         Netnews Article Format
                      draft-ietf-usefor-usefor-08
                      draft-ietf-usefor-usefor-09

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 23, 2006. March 1, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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

Note to RFC Editor

   Please remove all of the "Changes since ..." sections before
   publication.

Changes since draft-ietf-usefor-usefor-08

   o  Removed "Issues to be addressed" section.

   o  Header fields are now listed and described in alphabetical order
      (as suggested by Richard Clayton).

   o  Consistently use "Netnews article(s)" throughout document.

   o  Clarified that the 998 octet limit is for header field lines, not
      the entire header field.

   o  Added <comment> to ABNF imports.

   o  Added header fields specified in RFC 850 and RFC 2980 to IANA
      section.  Also rewrote Obsolete Header Fields section to reference
      RFC 850 and RFC 2980 instead of listing and describing obsolete
      header fields (ticket #1156).

   o  Added definitions for "generate" and "accept" (ticket #1299).

   o  Added note explaining <diag-deprecated> in Path header field
      (ticket #1305).

   o  Noted that agents MUST NOT (rather than SHOULD NOT) alter the Date
      header field when adding an Injection-Date header field (ticket
      #1306).

   o  Replaced reference to ISO3166 with ISO3166-1.  Also refined
      description of "world" and "local" in Distribution header field.
      (ticket #1309)

   o  Removed restriction on mailbox-list in Approved header field
      (ticket #1310).

   o  Refined discussion of Archive header field body (ticket #1311).

   o  Changed definition of Line count to number of CRLF in <body>
      (ticket #1312).

   o  Changed wording in Header Fields section 2.2 to discuss only
      headers, not entire messages (ticket #1313).

   o  Reworded text regarding use of special chars in newsgroups names
      (ticket #1314).

   o  Removed analogy to RFC 2822 article from "poster" definition
      (ticket #1315).

   o  Reworded the purpose of Injection-Date header field (ticket
      #1335).

   o  Reworded the description of Expires header field (ticket #1336).

   o  Clarified to which Email addresses followups to "poster" are sent.

   o  Numerous editorial changes from Ralph Babel, Richard Clayton, and
      Charles Lindsey.

Changes since draft-ietf-usefor-usefor-07

   o  Reworked ABNF for Path header field keywords (ticket #1047).

   o  Removed definition of "sender" in Injection-Info header field
      (ticket #1159).

   o  Reworded description of "posting-account" in Injection-Info header
      field (ticket #1159).

   o  Discussed the use of [FWS] in Newsgroups, Followup-To, and
      Distribution header fields (ticket #1178).

   o  Further clarification of *WSP vs. [FWS] in Section 2.2 (ticket
      #1179).

   o  Miscellaneous editorial changes from Dan Kohn.

Changes since draft-ietf-usefor-usefor-06

   o  Reworked ABNF for Path header field delimiters and components
      (ticket #1047).

   o  Imported ABNF elements from reference docs (ticket #1155).

   o  Added IANA registration for header fields per RFC 3864 (ticket
      #1156).

   o  New ABNF for Control header field (ticket #1157).

   o  Better ABNF for <host-value> (ticket #1158).

   o  Added new definitions and advice on sender vs. posting-account in
      Injection-Info header field (ticket #1159).

   o  New ABNF for Archive and Injection-Info header fields, including
      note regarding CFWS and <parameter> (ticket #1177).

   o  Replaced leading/trailing [FWS] with *WSP in header field ANBF
      (ticket #1179).

   o  Using RFC 4234 as a reference instead of RFC 2234.

   o  Removed reference to RFC 0977 -- using only
      draft-ietf-nntpext-base.

   o  Added note about Expires being defined by RFC 2156.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-05

   o  Finalized ABNF for <msg-id> (ticket #1003).

   o  Further cleanup of description for Newsgroups header field (ticket
      #1021).

   o  Fixed ABNF for <orig-date> (ticket #1028).

   o  Began adding text for differences from RFC 1036 (ticket #1032).

   o  Added text regarding hard-to-parse MIME boundaries (ticket #1046).

   o  Reworked/redefined Path header field delimiters and components
      (ticket #1047).

   o  Added more differences from RFC 2822 (ticket #1052).

   o  Added text for relationship to RFC 2822 (ticket #1053).

   o  Listed header fields which don't permit CFWS (ticket #1079).

   o  Applied text from ticket #1080 (Injection-Info MIME params).

   o  Added more text Approved header field semantics (ticket #1082).

   o  Added text regarding Injection-Date being mandatory/optional
      (ticket #1088).

   o  Reworked definitions of "agents", etc (ticket #1102).

   o  Removed RFC 2821 as a normative reference.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-04

   o  Updated to newer references (ticket #1002).

   o  Cleaned up ABNF for <msg-id> (ticket #1003).

   o  Deprecated X- headers (ticket #1004).

   o  Clarified relationship between followups and References header
      field (ticket #1008).

   o  Cleaned up ABNF and description for Newsgroups header field
      (ticket #1021).

   o  Tweaked language regarding the use of <obs-phrase> (ticket #1022).

   o  Tweaked language regarding GMT timezone and Date header field
      (ticket #1028).

   o  Added language warning against folding Newsgroups header field
      (ticket #1042).

   o  Use RFC 2822 term "header field" instead of "header" (ticket
      #1043).

   o  Starting adding differences from RFC 2822 (ticket #1052).

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-03

   o  Reworked ABNFs of several headers.

   o  Used Charles' ABNF for <msg-id>.

   o  Disallowed comments in Supersedes header.

   o  Disallowed comments in Xref header.

   o  Disallowed comments in Message-Id header.

   o  CFWS between msg-ids in References header is not optional.

   o  Compatibility changes based on comments from Charles.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-02

   o  Changed to RFC 3978 boilerplate (xml2rfc v1.29)

   o  Changed "network news" to "Netnews" throughout.

   o  Prohibit NO-WS-CTL in msg-id.

   o  Complaints-To header is now an Injection-Info parameter.

   o  Added descriptions of Injection-Info parameters.

   o  Removed "filename" parameter from Archive header.

   o  Added CFWS to User-Agent header.

   o  Miscellaneous editorial changes.

Changes since draft-ietf-usefor-usefor-01

   o  Removed half-hearted discussion of internal format and 8-bit clean
      transport.

   o  Added definitions of "proto-article", "posting agent", "followup",
      "followup-agent", "user-agent", and "injecting agent".

   o  Removed discussion of message/partial MIME messages.

   o  Noted that the header contents in every line MUST NOT be empty.

   o  Merged MIME sections.

   o  Only allow "UT" and "GMT" in Date header; disallow all other <obs-
      zone>.

   o  Used Charles' ABNF for <msg-id> and <unstructured>.

   o  Removed restrictions on length and start character for Newsgroups.

   o  More verbose description of Path header.

   o  Disallowed comments in Control header.

   o  Specified that <control-command> is a verb optionally followed by
      whitespace-separated arguments.

   o  Noted that Supersedes header is different from [Son-of-1036].

   o  More exact ABNF for Archive and Injection-Info parameters.

   o  Discussed meaning of "yes", "no" in Archive header.

   o  Added "Obsolete Headers" section.

   o  Miscellaneous editorial changes

Changes since draft-ietf-usefor-article-13

   o  The Mail-Copies-To, Posted-And-Mailed headers have been moved to
      other documents.

   o  Dropped MIME parameters, as there is no WG consensus (per Chair).

   o  More exact ABNF for Archive and Injection-Info parameters.

   o  Complaints-To header is now an Injection-Info parameter.

Issues to be addressed

   o  Path header field delimiters and components ABNF (ticket #1047).

   o  Whitespace in Path header field (ticket #1178).  Editor isn't
      clear on what the issue actually is.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  9 15
     1.1.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .  9 15
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  9 15
     1.3.  Requirements Notation  . . . . . . . . . . . . . . . . . .  9 15
     1.4.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  9 16
     1.5.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . 10 16
     1.6.  Structure of This Document . . . . . . . . . . . . . . . . 11 18
   2.  Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 19
     2.1.  Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 19
     2.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 13 20
     2.3.  MIME Conformance . . . . . . . . . . . . . . . . . . . . . 15 21
   3.  News Header Fields . . . . . . . . . . . . . . . . . . . . . . 16 22
     3.1.  Mandatory Header Fields  . . . . . . . . . . . . . . . . . 16 22
       3.1.1.  From  Date . . . . . . . . . . . . . . . . . . . . . . . . . 17 23
       3.1.2.  Date  From . . . . . . . . . . . . . . . . . . . . . . . . . 17 23
       3.1.3.  Message-ID . . . . . . . . . . . . . . . . . . . . . . 17 23
       3.1.4.  Subject  .  Newsgroups . . . . . . . . . . . . . . . . . . . . . . 19 26
       3.1.5.  Newsgroups  Path . . . . . . . . . . . . . . . . . . . . . . 20
       3.1.6.  Path . . . 27
       3.1.6.  Subject  . . . . . . . . . . . . . . . . . . . . . . . 21 29
     3.2.  Optional Header Fields . . . . . . . . . . . . . . . . . . 23 29
       3.2.1.  Injection-Date  Approved . . . . . . . . . . . . . . . . . . . . 23 . . . 30
       3.2.2.  References  Archive  . . . . . . . . . . . . . . . . . . . . . . 24 . 30
       3.2.3.  Followup-To  Control  . . . . . . . . . . . . . . . . . . . . . 24
       3.2.4.  Expires . . 31
       3.2.4.  Distribution . . . . . . . . . . . . . . . . . . . . . 25 31
       3.2.5.  Control  Expires  . . . . . . . . . . . . . . . . . . . . . . . 25 32
       3.2.6.  Supersedes .  Followup-To  . . . . . . . . . . . . . . . . . . . . . 26 32
       3.2.7.  Distribution .  Injection-Date . . . . . . . . . . . . . . . . . . . . 26 33
       3.2.8.  Summary  . . .  Injection-Info . . . . . . . . . . . . . . . . . . . . 27 33
       3.2.9.  Approved . .  Organization . . . . . . . . . . . . . . . . . . . . . 27 35
       3.2.10. Organization . References . . . . . . . . . . . . . . . . . . . . 27
       3.2.11. Xref . . 35
       3.2.11. Summary  . . . . . . . . . . . . . . . . . . . . . . . 27 36
       3.2.12. Archive  . Supersedes . . . . . . . . . . . . . . . . . . . . . . 28 36
       3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 28 36
       3.2.14. Injection-Info Xref . . . . . . . . . . . . . . . . . . . . 29 . . . . . 37
     3.3.  Obsolete Header Fields . . . . . . . . . . . . . . . . . . 31 37
       3.3.1.  Lines  . . . . . . . . . . . . . . . . . . . . . . . . 32 38
   4.  Internationalization Considerations  . . . . . . . . . . . . . 33 39
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34 40
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35 41
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 46
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 40 46
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 41 47
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 43 49
   Appendix B.  Differences from RFC 1036 and its derivatives . . . . 44 50
   Appendix C.  Differences from RFC 2822 . . . . . . . . . . . . . . 45 51
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 52
   Intellectual Property and Copyright Statements . . . . . . . . . . 47 53

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) messages), and for exchanging them amongst a readership which 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 able to access that server.

1.2.  Scope

   This document specifies the syntax of Netnews articles in the context
   of the "Internet Message Format" [RFC2822] and "Multipurpose Internet
   Mail Extensions (MIME)" [RFC2045].  This document supersedes obsoletes
   [RFC1036], updating it the syntax of Netnews articles to reflect current
   practice and incorporating changes and clarifications specified in
   other documents such as [Son-
   of-1036]. [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.  [I-D.ietf-usefor-usepro] is also a standards-track
   document,
   document and describes the protocol issues of Netnews articles,
   independent of transport protocols such as [I-D.ietf-nntpext-base].
   A best common practice best-common-practice document, [I-D.ietf-usefor-useage], describes
   implementation recommendations to improve interoperability and
   usability.

   This specification is intended as a definition of what article
   content format is to be passed between systems.  Although some 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].

1.4.  Syntax Notation

   Header fields defined in this specification use the Augmented Backus-
   Naur Form (ABNF) notation (including the Core Rules) specified in
   [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
   updated by [RFC2231], and [RFC3986], specifically:

   token         = <see RFC2045 Section 5.1>
   dot-atom-text
   value         = <see RFC2045 Section 5.1>
   parameter     = <see RFC2231 Section 7>
   attribute     = <see RFC2231 Section 7>

   FWS           = <see RFC2822 Section 3.2.3>
   comment       = <see RFC2822 Section 3.2.3>
   CFWS          = <see RFC2822 Section 3.2.3>
   atext         = <see RFC2822 Section 3.2.4>
   dot-atom-text = <see RFC2822 Section 3.2.4>
   phrase        = <see RFC2822 Section 3.2.6>
   utext         = <see RFC2822 Section 3.2.6>
   date-time     = <see RFC2822 Section 3.3>
   mailbox       = <see RFC2822 Section 3.4>
   mailbox-list  = <see RFC2822 Section 3.4>
   address-list  = <see RFC2822 Section 3.4>
   body          = <see RFC2822 Section 3.5>
   fields        = <see RFC2822 Section 3.6>

   IPv6address   = <see RFC3986 Section 3.2.2>
   IPv4address   = <see RFC3986 Section 3.2.2>

   ALPHA         = <see RFC4234 Appendix B.1>
   CRLF          = <see RFC4234 Appendix B.1>
   DIGIT         = <see RFC4234 Appendix B.1>
   DQUOTE        = <see RFC4234 Appendix B.1>
   SP            = <see RFC4234 Appendix B.1>

   Additionally, Section 3.1.3 specifies a stricter definition of
   <msg-id> than the syntax in [RFC2822] Section 3.6.4.

1.5.  Definitions

   An "article" is the unit of Netnews, analogous to an [RFC2822]
   "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
   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 single forum having a name and intended for articles on a
   specific topic.  An article is "posted to" a single newsgroup or
   several newsgroups.  When an article is posted to more than one
   newsgroup, it is said to be "crossposted"; note that this differs
   from posting the same text as part of each of several articles, one
   per newsgroup.

   A newsgroup may be "moderated", in which case submissions are not
   posted directly, but mailed to a "moderator" for consideration and
   possible posting.  Moderators are typically human but may be
   implemented partially or entirely in software.

   A "poster" is the person or software that composes and submits a
   possibly
   potentially compliant article to a "user agent".  The poster is
   analogous to an [RFC2822] author.

   A "reader" is the person or software reading news Netnews articles.

   A "followup" "follow-up" 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 which 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.

   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 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 [RFC2822] Section 3 and to the
   additional requirements of this specification.

   An article that uses the obsolete syntax specified in Section 4 of
   [RFC2822] 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 [RFC2822] Section 4.1) 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.2. 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 [RFC2822]; this grammar is intended to be more
   restrictive than the [RFC2822] grammar.  Articles must conform to the
   ABNF specified in [RFC2822].

   Articles must also conform 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 [RFC2822] calls "header field".  This document follows the
      terminology in Section 2 of [RFC2822] 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 news Netnews article are compliant with [RFC2822],
   however [RFC2822];
   this specification specification, however, is less permissive in what can be
   generated and accepted by news agents.  The syntax allowed for news
   articles Netnews
   article headers is a strict subset of the "Internet Message Format", Format"
   headers, making all messages headers compliant with this specification
   inherently compliant with [RFC2822].  Note however that the converse
   is not guaranteed to be true in all cases.

   General rules which apply to all header fields (even those documented
   in [RFC2822] and [RFC2045]) are listed below 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 [I-D.ietf-nntpext-base] servers).  News agents MAY
      accept header fields which 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.6 of
         [RFC2822], this document uses a stricter definition:

   unstructured    =  *WSP utext *( [FWS] utext ) *WSP

         NOTE: The [RFC2822] 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 [RFC2822].  This is
         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
      fields 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] [RFC2047], lines of a header
      field containing encoded-words are limited to 76 octets).
      [I-D.ietf-usefor-useage] includes suggested limits for convenience
      of display by user agents.

         NOTE: There As stated in [RFC2822], 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 octets 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 MIME conformance in [RFC2049]
   and MUST also support [RFC2231].  This level of MIME Conformance conformance
   provides support for internationalization and multimedia in message
   bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
   internationalization of header fields ([RFC2047], [RFC2231]).  Note
   that [Errata] currently exist for [RFC2046] 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 [RFC2822]:

   fields          =/ *( newsgroups approved /
                         path
                         archive /
                         injection-date
                         control /
                         followup-to
                         distribution /
                         expires /
                         control
                         followup-to /
                         supersedes
                         injection-date /
                         distribution
                         injection-info /
                         summary
                         lines /
                         approved
                         newsgroups /
                         organization /
                         xref
                         path /
                         archive
                         summary /
                         user-agent
                         supersedes /
                         injection-info
                         user-agent /
                         lines
                         xref )

   Each of these header fields may occur at most once in a news article.

   The following header fields defined in this document do not allow
   comments (CFWS):

   Control
   Distribution
   Newsgroups
   Path
   Followup-To
   Control
   Lines
   Path
   Supersedes
   Distribution
   Xref
   Lines

   This also applies to the following header field defined in [RFC2822]:

   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 comments. <comment>s.

3.1.  Mandatory Header Fields

   Each news Netnews article conformant with this specification MUST have
   exactly one of each of the following header fields: From, Date, From,
   Message-ID, Subject, Newsgroups, Path. Path, Subject.

3.1.1.  From

   The From header field is the same as that specified in Section 3.6.2
   of [RFC2822] with the added restrictions detailed in Section 2.2.

   from            =  "From:" SP mailbox-list CRLF

3.1.2.  Date

   The Date header field is the same as that specified in Sections 3.3
   and 3.6.1 of [RFC2822] 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 news 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 [RFC2822], which says
      that agents MUST NOT generate <date-time> constructs which 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 [RFC2822] Section 4.3.

   Also note that these requirements apply wherever <date-time> is used,
   including Injection-Date and Expires in Section 3.2.1 3.2.7 and
   Section 3.2.4 3.2.5, respectively.

3.1.2.  From

   The From header field is the same as that specified in Section 3.6.2
   of [RFC2822] 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 single unique message identifier.
   Netnews is more dependent on message identifier uniqueness and fast
   comparison than Email is, and some news software and standards
   [I-D.ietf-nntpext-base] might have trouble with the full range of
   possible <msg-id>s permitted by [RFC2822].  This section therefore
   restricts the syntax of <msg-id> as compared to Section 3.6.4 of
   [RFC2822].  The global uniqueness requirement for <msg-id> in
   [RFC2822] is to be understood as applying across all protocols using
   such message identifiers, and across both Email and Netnews in
   particular.

   message-id      =  "Message-ID:" SP *WSP msg-id *WSP CRLF

   msg-id          =  "<" id-left "@" id-right msg-id-core ">"
                      ; maximum length is 250 octets

   msg-id-core     =  id-left "@" id-right

   id-left         =  dot-atom-text / no-fold-quote

   id-right        =  dot-atom-text / no-fold-literal

   no-fold-quote   =  DQUOTE
                         ( "." *mqtext /
                           *mqtext "." /
                           *mqtext mqspecial *mqtext )
                         DQUOTE

   mqtext          =  atext / "." / mqspecial

   mqspecial       =  "(" / ")" /      ; same as specials except
                      "<" /            ; "\" and DQUOTE quoted
                      "[" / "]" /      ; "." doubled and ">" omitted
                      ":" / ";" /
                      "@" / "," /
                      ".." / "\\" / "\" DQUOTE

   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 retrieving referencing an article
      (e.g.  [I-D.ietf-nntpext-base]) can rely on a bounded length.

   Observe that msg-id includes the < and >.

   Observe also that in contrast to the corresponding header field in
   [RFC2822]:

   o  the syntax does not allow comments within the Message-ID header
      field,

   o  it ensures that no string of characters is quoted if it were
      already a <dot-atom-text> (it MUST start or end with a ".", or
      contain at least one <mqspecial>),

   o  it ensures that no single character is prefixed by a "\" in the
      form of a <quoted-pair> unless strictly necessary,

   o  it excludes all control characters,

   o  there is no possibility for ">" or WSP to occur inside a <msg-id>,
      whether quoted or not, and

   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
   [I-D.ietf-nntpext-base].  Thus, whereas under [RFC2822] the following
   <msg-id>s would be considered semantically equivalent,

   <ab.cd@example.com>
   <"ab.cd"@example.com>
   <"ab.\cd"@example.com>

   only the first of them is syntactically permitted by this standard,
   and hence a simple comparison of octets will always suffice to
   determine the identity of two <msg-id>s.

   Also note that this updated ABNF applies wherever <msg-id> is used,
   including the References header field discussed in Section 3.2.2 3.2.10 and
   the Supersedes header field discussed in Section 3.2.6. 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 two Message-IDs where the
   only difference is the case of characters in the <id-right> part.

   When generating a <msg-id>, implementations SHOULD use a domain name
   as the <id-right>.

      NOTE: Section 3.6.4 of [RFC2822] 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.  Subject

   The Subject header field is the same as that specified in Section
   3.6.5 of [RFC2822] with the added restrictions detailed in
   Section 2.2.  Further discussion of the content of the Subject header
   field appears in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-
   useage].

   subject         =  "Subject:" SP unstructured CRLF

3.1.5.  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 [FWS] in the list of newsgroups.  In
   particular, folding the Newsgroups header field over several lines
   has been shown to harm propagation significantly.  [FWS] in the
   <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.

   A newsgroup component SHOULD NOT consist of digits only, only and SHOULD
   NOT contain uppercase letters.  Such components MAY be used only to
   refer to existing groups that do not conform to this naming scheme. scheme,
   but MUST NOT be used otherwise.

      NOTE: All-digit components conflict with one widely used storage
      scheme for articles.  Mixed case  Mixed-case groups cause confusion between
      systems with case sensitive case-sensitive matching and systems with case case-
      insensitive matching of <newsgroup-name>s.

   <component>s beginning with underline ("_") are reserved for use by
   future versions of this standard and MUST SHOULD NOT be generated by user
   agents (whether in Newsgroups header fields or in newgroup control messages as
   defined by [I-D.ietf-usefor-usepro]).  However, such names MUST be
   accepted by news servers.

   <component>s beginning with "+" and "-" are reserved for private use
   and MUST SHOULD NOT be generated by user agents (whether in Newsgroups header fields
   or in newgroup control messages [I-D.ietf-usefor-
   usepro]) [I-D.ietf-usefor-usepro]) without a
   private prior agreement to do so.  However, such names MUST be
   accepted by news servers.

   The following <newsgroup-name>s are reserved, reserved and MUST NOT be used as
   the name of a newsgroup:

   o  Groups whose first (or only) component <component> is "example"
   o  The group "poster"

   The following <newsgroup-name>s have been used for specific purposes
   in various implementations and protocols, protocols and therefore MUST NOT be
   used for the names of normal newsgroups.  They MAY be used for their
   specific purpose, 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 which contain (or consist only of) the component "all"

   o  Groups which 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 [I-D.ietf-usefor-usepro]; "control.*" and "junk" have
      special meanings in some news-servers; news servers; "all" is used as a wildcard
      in some implementations; and "ctl" was formerly used to indicate a
      <control-command> within the Subject Newsgroups header field.

3.1.6.

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 to enable so that news servers are able
   to avoid sending articles to sites already known to have them, in
   particular the site they came from, and additionally to permit
   tracing the route articles take in moving over the network, and for
   gathering statistics.

   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 USEPRO [I-D.ietf-usefor-usepro]

   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).

      NOTE: Although case-insensitive, it is intended that the <path- <diag-
      keyword>s should be in upper case, upper-case, to distinguish them from the
      <path-identity>s which are traditionally in lower case.

   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 [I-D.ietf-usefor-usepro].

      NOTE: One usage of a <path-diagnostic> is to record an IP address.
      The fact that IPv6 addresses <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.

3.2.  Optional Header Fields

   None of the header fields appearing in this section is required to
   appear

      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 [RFC2822] with the added restrictions detailed above in
   Section 2.2.  Further discussion of the content of the Subject header
   field appears in [I-D.ietf-usefor-usepro] and
   [I-D.ietf-usefor-useage].

   subject         =  "Subject:" SP unstructured CRLF

3.2.  Optional Header Fields

   None of the header fields appearing in this section is required to
   appear in every article article, but some of them may be required in certain
   types of articles. article.  Further discussion of these requirements appears
   in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

   The header fields Reply-To, Sender, Comments, Keywords, Reply-To, and Keywords Sender are used
   in news Netnews articles in the same circumstances and with the same meaning
   meanings as that those specified in [RFC2822] with the added restrictions
   detailed above in Section 2.2.  Multiple occurances occurrences of the Keywords
   header field are not permitted.

   sender          =  "Sender:" SP mailbox CRLF

   reply-to        =  "Reply-To:" SP address-list CRLF

   comments        =  "Comments:" SP unstructured CRLF

   keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

   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 news
   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.  Injection-Date  Approved

   The Injection-Date Approved header field contains the date and time that the
   article was injected into the network.  Its purpose is to prevent indicates the
   reinjection into mailing addresses (and
   possibly the news stream full names) of "stale" articles which have
   already expired by the time they arrive at some news server.

   This header field MUST be inserted whenever an persons or entities approving the
   article is injected.
   However, software that predates this standard does not use this
   header, and therefore agents MUST accept for posting.  Its principal uses are in moderated articles without the
   Injection-Date header field.

   injection-date
   and in group control messages; see [I-D.ietf-usefor-usepro].

   approved        =  "Injection-Date:"  "Approved:" SP date-time mailbox-list CRLF

   See

3.2.2.  Archive

   The Archive header field provides an indication of the remarks under Section 3.1.2 poster's
   intent regarding the syntax preservation of
   <date-time> and the requirements and recommendations to which it is
   subject.

      NOTE: Since clocks on various agents may not be synchronized, the
      <date-time> article in this 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 may in an article with a field
   body of "no" indicates that the poster does not be later than permit redistribution
   from publicly accessible long-term or permanent archives.  A field
   body of "yes" indicates that the Date
      header field, as would poster permits such redistribution.

   No <parameter>s are currently defined; if present, they can be expected.  Agents SHOULD use
   ignored.  Further discussion of the <date-
      time> they believe is correct when adding Inject-Info but SHOULD
      NOT alter content of the pre-existing Date header field.

   This Archive header
   field is intended to replace the currently-used but
   undocumented "NNTP-Posting-Date" header field, whose use is now
   deprecated.

3.2.2.  References appears in [I-D.ietf-usefor-useage].

3.2.3.  Control

   The References Control header field is marks the same article as that specified in Section
   3.6.4 a control message and
   specifies the desired actions (additional to the usual ones of [RFC2822] with
   storing and/or relaying the added restrictions detailed 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.

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

   references article).

   control         =  "References:"  "Control:" SP [CFWS] msg-id *(CFWS msg-id)
                      [CFWS] *WSP control-command *WSP CRLF

3.2.3.  Followup-To

   control-command =  verb *( 1*WSP argument )

   verb            =  token

   argument        =  1*( %x21-7E )

   The Followup-To header field specifies to which newsgroup(s)
   followups verb indicates what action should be posted. taken, and the argument(s)
   (if any) supply details.  In some cases, the <body> (as defined in
   [RFC2822]) of the article may also contain details.  The Followup-To legal verbs
   and respective arguments are discussed in the companion document,
   [I-D.ietf-usefor-usepro].

   An article with a Control header field SHOULD MUST NOT
   appear in also have a message, unless its content is different from the content
   of the Newsgroups
   Supersedes header field.

   followup-to

3.2.4.  Distribution

   The Distribution header field specifies geographic or organizational
   limits on an article's propagation.

   distribution    =  "Followup-To:"  "Distribution:" SP ( newsgroup-list / poster-text ) dist-list CRLF

   poster-text

   dist-list       =  *WSP %d112.111.115.116.101.114 dist-name
                      *( [FWS] "," [FWS] dist-name ) *WSP
                      ; "poster" in lower-case

   dist-name       =  ALPHA / DIGIT
                      *( ALPHA / DIGIT / "+" / "-" / "_" )

   The syntax <dist-name>s "world" and "local" are reserved. "world" indicates
   unlimited distribution and SHOULD NOT be used explicitly, since it is
   the same as that of default when the Newsgroups (Section 3.1.5) Distribution header field, with the exception that the keyword "poster" requests
   that followups should be mailed field is absent entirely.
   "local" is reserved for indicating distribution only to the article's reply address rather
   than posted.  Agents local
   site, as defined by local software configuration.

   "All" MUST generate the keyword "poster" in lower-
   case, but MAY choose to recognize case-insensitive forms such NOT be used as
   "Poster".

   As in a <dist-name>. <dist-name>s SHOULD contain
   at least three characters, except when they are two-letter country
   names drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e.
   "US", "Us", "uS", and "us" all specify the Newsgroups (Section 3.1.5) header field, same distribution).

   [FWS] in the
   <newsgroup-list> <dist-list> SHOULD NOT be generated, but MUST be
   accepted.

3.2.4.

3.2.5.  Expires

   The Expires header field specifies a date and time when the poster
   deems the article
   is deemed 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.2 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 meaning; see [RFC2156].

3.2.5.  Control

3.2.6.  Followup-To

   The Control Followup-To header field marks the article as a control message, and specifies the desired actions (additional to which newsgroup(s) the usual ones of
   storing and/or relaying the article).

   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
   poster has requested that followups are to be taken, and the argument(s)
   (if any) supply details.  In some cases, the body of the article may
   also contain details. posted.  The legal verbs and respective arguments are
   discussed in the companion document, [I-D.ietf-usefor-usepro].

   An article with a Control
   Followup-To header field MUST SHOULD NOT also have a
   Supersedes header field.

3.2.6.  Supersedes

   The Supersedes header field contains a message identifier specifying
   an article to be superseded upon the arrival of this one.  An article
   containing appear in a Supersedes header field message, unless its
   content is equivalent to a "cancel"
   [I-D.ietf-usefor-usepro] control message for the specified article,
   followed immediately by different from the new article without content of the Supersedes Newsgroups header field.

   supersedes

   followup-to     =  "Supersedes:"  "Followup-To:" SP ( newsgroup-list / poster-text )
                      CRLF

   poster-text     =  *WSP msg-id %d112.111.115.116.101.114 *WSP CRLF

      NOTE: There is no "c"
                      ; "poster" in Supersedes.

      NOTE: lower-case

   The Supersedes syntax is the same as that of the Newsgroups (Section 3.1.4)
   header field defined here has no connection field, with the Supersedes header field exception that sometimes appears in Email
      messages converted from X.400 according the keyword "poster" requests
   that followups should be emailed directly to [RFC2156]; the article's poster
   (using the addresses contained in
      particular, the syntax here permits only Reply-To header field if one <msg-id> in contrast
      to
   exists, otherwise using the multiple <msg-id>s addresses contained in that Email version.

3.2.7.  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 predefined.  However,
   "world" SHOULD NOT be used explicitly, since it is the default when the Distribution From header field is absent entirely.

   "All"
   field) rather than posted to any newsgroups.  Agents MUST NOT be used generate
   the keyword "poster" in lower-case, but MAY choose to recognize case-
   insensitive forms such as a <dist-name>. <dist-name>s SHOULD contain
   at least three characters, except when they are two-letter country
   names drawn from [ISO.3166.1988]. <dist-name>s are case-insensitive
   (i.e.  "US", "Us", "uS", and "us" all specify "Poster".

   As in the same distribution). Newsgroups (Section 3.1.4) header field, [FWS] in the <dist-list>
   <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.

3.2.8.  Summary

   The Summary header field is a short phrase summarizing the article's
   content.

   summary         =  "Summary:" SP unstructured CRLF

3.2.9.  Approved

3.2.7.  Injection-Date

   The Approved Injection-Date header field indicates the mailing addresses (and
   possibly the full names) of contains the persons or entities approving date and time that the
   article for posting. was injected into the network.  Its principal uses are in moderated articles
   and in group control messages [I-D.ietf-usefor-usepro].

   approved        =  "Approved:" SP mailbox-list CRLF

   Each mailbox contained in 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 Approved user agent at message composition time.

   This header field MUST be inserted whenever an article is injected.
   However, software that of
   one of the person(s) or entity(ies) in question, and one of those
   mailboxes MUST be that of the actual sender of the article.  Note
   that predates this standard does not provide any means 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 enforce or verify which it is
   subject.

      NOTE: Since clocks on various agents are not necessarily
      synchronized, the <date-time> in this requirement, but future extensions or standards header field may provide such not be
      later than the Date header field, as be expected.  Agents MUST NOT
      alter a facility (e.g. digitial signatures).

3.2.10.  Organization

   The Organization pre-existing Date header field when adding an Injection-
      Date header field.

   This header field is a short phrase identifying intended to replace the
   poster's organization.

   organization    =  "Organization:" SP unstructured CRLF

   NOTE: There currently-used but
   undocumented "NNTP-Posting-Date" header field, whose use is no "s" in Organization.

3.2.11.  Xref now
   deprecated.

3.2.8.  Injection-Info

   The Xref Injection-Info header field indicates where an article was filed contains information provided by the
   last
   injecting news server as to process it.  The how an article locations are used entered the Netnews system
   and to
   keep track of crossposted articles so that user agents serviced by a
   particular news server assist in tracing its true origin.  It can mark such articles as read.

   xref also specify one or
   more addresses where complaints concerning the poster of the article
   may be sent.

   injection-info  =  "Xref:"  "Injection-Info:" SP *WSP server-name
                      1*( FWS location [CFWS] path-identity
                      [CFWS] *( ";" [CFWS] parameter ) *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 what
   newsgroups the article was filed under (which may differ from those
   in the Newsgroups header field) and where it was filed under them.
   The exact form of an <article-locator> is implementation-specific.

      NOTE: The traditional form of an <article-locator> (as required by
      [I-D.ietf-nntpext-base]) is a decimal number, with articles in
      each newsgroup numbered consecutively starting from 1.

3.2.12.  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.  The
   absence of this header field, or the presence of this header field
   with a field body of "yes", indicates that the poster is willing for
   such redistribution to take place.  Further extensions to this
   standard may provide parameters for administration of the archiving
   process.

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
   needing 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

   This header field MAY contain multiple product-tokens identifying the
   user agent and any subproducts which 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
      uses User-Agent, it should have no need to send these non-standard
      header fields.

      NOTE: [RFC2616] describes a similar facility for the HTTP
      protocol.  This specification differs in that "{" and "}" are
      allowed in tokens (<product> and <product-version>) and comments
      are permitted wherever whitespace is allowed.

3.2.14.  Injection-Info

   The Injection-Info header field contains information provided by the
   injecting news server as to how an article entered the Netnews system
   and to assist in tracing its 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] [CFWS] CRLF

      NOTE: The syntax of <parameter> ([RFC2045] Section 5.1 as amended
      by [RFC2231]), taken in conjunction with the folding rules of
      [RFC0822], effectively allows [CFWS] to occur on either side of
      the "=" inside a <parameter>.

   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.168.0.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 white space 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-Trace,
      X-Complaints-To, and others.  Once a news server uses Injection-
      Info, it should have no need to send these non-standard header
      fields.

   The "posting-host" <parameter> specifies the 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> identifies a dial-up
      point-of-presence, the "posting-account" or the "logging-data"
      <parameter> may provide additional information about the true
      origin true
      origin of the article.

   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 [I-D.ietf-usefor-useage].

3.2.9.  Organization

   The Organization header field is a short phrase identifying the article.
   poster's organization.

   organization    =  "Organization:" SP unstructured CRLF

      NOTE: There is no "s" in Organization.

3.2.10.  References

   The "posting-account" <parameter> identifies References header field is the source from which same as that news server received specified in Section
   3.6.4 of [RFC2822] with the article, added restrictions detailed above in a notation that can
   Section 2.2 and those listed below:

   o  The updated <msg-id> construct defined in Section 3.1.3 MUST be
   interpreted by the news server administrator.  This notation
      used.

   o  Message identifiers MUST be separated with CFWS.

   o  Comments in CFWS between message identifiers can
   include any information 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 administrator deems pertinent.  In order article's
   content.

   summary         =  "Summary:" SP unstructured CRLF

3.2.12.  Supersedes

   The Supersedes header field contains a message identifier specifying
   an article to limit be superseded upon the exposure arrival of personal data, it SHOULD be given in this one.  An article
   containing a form
   that can't be interpreted by other sites.  However, Supersedes header field is equivalent to make it useful a "cancel"
   [I-D.ietf-usefor-usepro] control message for rate limiting and abuse detection, two messages posted from the
   same source SHOULD have 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 same value of "posting-account", and two Supersedes header field that sometimes appears in Email
      messages converted from different sources SHOULD have differing values of
   "posting-account".  The exact definition of "source" is left X.400 according to [RFC2156]; in
      particular, the
   discretion of syntax here permits only one <msg-id> in contrast
      to the news server administrator. multiple <msg-id>s in that Email version.

3.2.13.  User-Agent

   The "logging-data" <parameter> User-Agent header field contains information about the user agent
   (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 newsreader) generating the news
   server.

   The "mail-complaints-to" <parameter> specifies one or more mailboxes article, for sending complaints concerning the behavior of the poster statistical
   purposes and tracing of the
   article. standards violations to specific software
   needing correction.  It is a matter of local policy which <parameter>s to include.  Some
   pieces of information have privacy implications; intended that this is discussed header field be
   suitable for use in
   [I-D.ietf-usefor-useage].

3.3.  Obsolete Header Fields

   Early Netnews software sometimes generated Email.

   user-agent      =  "User-Agent:" SP 1*product [CFWS] CRLF

   product         =  [CFWS] token [ [CFWS] "/" product-version ]

   product-version =  [CFWS] token

   This header fields such as:

   Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
   Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
   Date-Received: Friday, 19-Nov-82 16:59:30 EST

   Relay-Version contained version information about the news server
   that last processed field MAY contain multiple <product> tokens identifying
   the article.  Posting-Version contained version
   information about user agent and any subproducts which 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 that posted the article.  Date-
   Received contained the date when the last news server to process the
   article first saw
      uses User-Agent, it (in a slightly nonstandard format).

   These header fields are mentioned for historical purposes only.
   Agents MUST NOT generate articles containing should have no need to send these non-standard
      header fields.

   In addition, this standard obsoletes certain header fields defined in
   [Son-of-1036]:

   Also-Control: cancel <9urrt98y53@site.example>
   See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
   Article-Names: comp.foo:charter
   Article-Updates: <i4g587y@site1.example>

   Also-Control indicated

      NOTE: [RFC2616] describes a control message 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 whitespace is allowed.

3.2.14.  Xref

   The Xref header field indicates where an article was also intended to be filed as a normal article.  See-Also listed related articles, but
   without by the specific relationship with followups that pertains
   last news server to process it.  User agents often use the
   References
   information in the Xref header field.  Article-Names indicated some special
   significance 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 what
   newsgroups the article was filed under (which may differ from those
   in relation to the indicated newsgroup.
   Article-Updates indicated that Newsgroups header field) and where it was filed under them.
   The exact form of an earlier article was updated,
   without at the same time being superseded. <article-locator> is implementation-specific.

      NOTE: The traditional form of an <article-locator> (as required by
      [I-D.ietf-nntpext-base]) is a decimal number, with articles in
      each newsgroup numbered consecutively starting from 1.

3.3.  Obsolete Header Fields

   The header fields listed above 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 documented declared
   obsolete.  See the cited specification documents for historical purposes
   only. 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 <body>
   (as defined in [RFC2822]) of the article.

   lines           =  "Lines:" SP *WSP 1*DIGIT *WSP CRLF

   The line count includes all body lines, including the signature if
   any, including empty lines (if any) at the beginning or end of the
   body, and including the whole of all MIME message and multipart parts
   contained in the body (the single empty separator line between the
   header fields and the body is not part of the body).  The "body" here is the body as found number of CRLF separators in the posted article as transmitted by the user
   agent. <body>.

   Historically, this header field was used by the [I-D.ietf-nntpext-
   base] Overview
   [I-D.ietf-nntpext-base] 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.  Servers and clients  All agents SHOULD ignore it, it and
   SHOULD NOT generate it.

4.  Internationalization Considerations

   Internationalization of news Netnews article header fields and bodies is
   provided using 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 news 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 [RFC3156], or below, using secure versions of news transport
   protocols.  Additionally, several currently non-standardized
   protocols such as [PGPVERIFY] will hopefully may be standardized in the near future.

   Message identifiers (Section 3.1.3) in news are required to be
   unique; articles are may be refused (in server-to-server transfer) if the
   identifier has already been seen.  So if you can predict the
   identifier of a message, you can preempt it by posting a message
   (possibly to a quite different group) with the same message
   identifier, stopping your target message from propagating.  Agents
   that generate message identifiers for news 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 differences deficiencies in parsing may be used as part of an attack.

   Further security considerations are discussed in
   [I-D.ietf-usefor-usepro].

6.  IANA Considerations

   IANA is requested to register 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.9) 3.2.1)

      Header field name: Archive
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2.12) 3.2.2)

      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),
      [RFC2822] (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.5) 3.2.3)
      Header field name: Date
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.1.2), 3.1.1),
      [RFC2822] (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.7) 3.2.4)

      Header field name: Expires
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2.4) 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.3) 3.2.6)

      Header field name: From
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.1.1), 3.1.2),
      [RFC2822] (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.1) 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.14) 3.2.8)

      Header field name: Keywords
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2),
      [RFC2822] (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: [I-D.ietf-nntpext-base] (Section 8.1)

      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: [RFC2822] (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.5) 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): none [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.10) 3.2.9)
      Header field name: Path
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.1.6) 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)

      Header field name: References
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2.2), 3.2.10),
      [RFC2822] (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),
      [RFC2822] (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),
      [RFC2822] (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.4), 3.1.6),
      [RFC2822] (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.8) 3.2.11)

      Header field name: Supersedes
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2.6) 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.11) 3.2.14)

7.  References

7.1.  Normative References

   [Errata]   "RFC Editor Errata". Errata",
               http://www.rfc-editor.org/errata.html.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183, August 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [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.

   [RFC4234]  Crocker, D. D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

7.2.  Informative References

   [I-D.ietf-nntpext-base]
              Feather, C., "Network News Transfer Protocol",
              draft-ietf-nntpext-base-27 (work in progress), June 2005.

   [I-D.ietf-usefor-useage]
              Lindsey, C., "Usenet Best Practice",
              draft-ietf-usefor-useage-01 (work in progress),
              March 2005.

   [I-D.ietf-usefor-usepro]
              Lindsey, C., "News Article Architecture and Protocols",
              draft-ietf-usefor-usepro-05 (work in progress),
              January 2006.

   [ISO.3166.1988]

   [ISO3166-1]
              International Organization for Standardization, "Codes "ISO 3166-
              1:1997. Codes for the representation of names of countries, 3rd edition",
              ISO Standard 3166, August 1988. countries
              and their subdivisions -- Part 1: Country codes", 1997.

   [PGPVERIFY]
              Lawrence, D., "PGPverify",
               ftp://ftp.isc.org/pub/pgpcontrol/README.html, June 1999.

   [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.

   [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.

   [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.

   [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.

   [Son-of-1036]
              Spencer, H., "News Article Format and Transmission",
               ftp://ftp.zoo.toronto.edu/pub/news.txt.Z, June 1994.

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 the 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 [RFC2822] conventions for parenthesis-enclosed <comment>s in
      header fields are supported in all newly defined header fields and
      in header fields inherited from [RFC2822].  They are, however,
      still disallowed for performance and/or compatibility reasons in
      the Control, Distribution, Followup-To, Lines, Message-ID,
      Newsgroups, Path, Followup-To, Control, Supersedes, Distribution, Xref and Lines Xref header fields.

   o  Whitespace  Multiple addreses 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 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 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.

   o  There are numerous other small changes, clarifications clarifications, and
      enhancements.

Appendix C.  Differences from RFC 2822

   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 [RFC2822].

   The Netnews article format is a strict subset of the Internet Message
   Format; all Netnews articles conform to the syntax of [RFC2822].

   The following restrictions are important:

   o  A SP (space) is REQUIRED after the colon (':') following a header
      field name.

   o  A more 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.

Authors' Addresses

   Kenneth Murchison (editor)
   Carnegie Mellon University
   5000 Forbes Avenue
   Cyert Hall 285
   Pittsburgh, PA  15213
   US
   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
   GB
   U.K.

   Phone: +44 161 436 6131
   Email: chl@clw.cs.man.ac.uk chl@clerew.man.ac.uk

   Dan Kohn
   FlyDash, Inc.
   425 Alma St. #411
   Palo Alto, CA  94301
   US
   U.S.A.

   Phone: +1 415 233 1000
   Email: dan@dankohn.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).