Usenet Format Working Group                                   C. Lindsey
Internet-Draft                                  University of Manchester
Updates: 2822 (if approved)                                      D. Kohn
Obsoletes: 1036 (if approved)                           Skymoon Ventures
Expires: January 9, 2005                               K. Murchison
Expires: March 15, 2005                               Oceana Matrix Ltd.
                                                           July 11,
                                                                 D. Kohn
                                                        Skymoon Ventures
                                                      September 14, 2004

                          News Article Format
                    draft-ietf-usefor-usefor-00.txt
                    draft-ietf-usefor-usefor-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on January 9, March 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines the format of network news articles.

   Network news articles resemble mail messages but are broadcast to
   potentially large audiences, using a flooding algorithm that
   propagates one copy to each interested host (or group thereof),
   typically stores only one copy per host, and does not require any
   central administration or systematic registration of interested
   users.  Network news originated as the medium of communication for
   Usenet, circa 1980.  Since then Usenet has grown explosively, and
   many Internet sites participate in it.  In addition, the news
   technology is now in widespread use for other purposes, on the
   Internet and elsewhere.

   This document defines specifies the format syntax of network news articles in the
   context of the Internet "Internet Message Format, Format" (RFC 2822) and adds Multipurpose "Multipurpose
   Internet Mail Extensions (MIME) support for multimedia (MIME)" (RFC 2045).  This document
   supersedes RFC 1036, updating it to reflect current practice and
   internationalized message bodies.
   incorporating incremental changes specified in other documents.

Changes since draft-kohn-news-article-03

   o  Document is now a work product of USEFOR draft-ietf-usefor-usefor-00

   o  Added new co-authors  Rewrote/reorganized Abstract and Introduction.
   o  Added some definitions from draft-ietf-usefor-article-13
   o  Removed text that belongs in [usepro] required SP to ABNF of header definitions.
   o  Reorganized header sections
   o  Added Archive and User-Agent headers sections.
   o  Compatibility changes based on comments from Charles Charles.
   o  Added Injection-Date and Injection-Info headers.

Changes since draft-ietf-usefor-article-13

   o  The Mail-Copies-To, Posted-And-Mailed and Complaints-To headers
      have been moved to other documents.
   o  Dropped MIME parameters, as there is no WG consensus (per Chair).

Issues to be addressed

   o  More detailed discussion of Control header verbs
   o  Discussion of 78 character limit  Decide which definitions should go in headers
   o  Discussion of required space after ':' this document and in headers
   o  Review Message-ID limitations
      [USEPRO].
   o  Further  Decide how much (if any) discussion of newsgroup name character limits
   o  Investigate using MIME parameters for Archive header Injection-Info content
      belongs in this document vs.  [USEPRO].
   o  Should  Do we use the User-Agent specification want to discuss message/partial?
   o  Add appendixes for obsolete headers, changes from RFC 1036 and
      differences from HTTP? RFC 2822.
   o  Review of ABNF

Table  Merge more security issues?
   o  Merge acknowledgments?

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1  Scope  . . . .  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .   4
     1.2  Requirements Notation  Scope  . . . . . . . . . . . . . . . . . .   5
     1.3  Errata . . . . . . . .   4
     1.3  Requirements Notation  . . . . . . . . . . . . . . . . . .   5
     1.4  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .   5
     1.5  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   5
     1.6  Structure of This Document . . . . . . . . . . . . . . . .   6   5
   2.   Format . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1  Base . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.2  MIME Conformance  Header Fields  . . . . . . . . . . . . . . . . . . . . . .   7
     2.3  MIME Conformance . . . . . . . . . . . . . . . . . . . . .   8
     2.4  Additional MIME Support  . . . . . . . . . . . . . . . . .   7   8
   3.   Internet Message Format   News Headers . . . . . . . . . . . . . .   8 . . . . . . . . . .   9
     3.1  Mandatory Headers  . . . . . . . . . . . . . . . . . . . .   8
     3.2  Optional Headers   9
       3.1.1  From . . . . . . . . . . . . . . . . . . . . .   8
     3.3  Date . . . .   9
       3.1.2  Subject  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4  Message-ID   9
       3.1.3  Date . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.5  News Headers .   9
       3.1.4  Message-ID . . . . . . . . . . . . . . . . . . . . . .  10
       3.5.1
       3.1.5  Newsgroups . . . . . . . . . . . . . . . . . . . . . .  10
       3.5.2  11
       3.1.6  Path . . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.5.3  11
       3.1.7  Injection-Date . . . . . . . . . . . . . . . . . . . .  12
     3.2  Optional Headers . . . . . . . . . . . . . . . . . . . . .  12
       3.2.1  References . . . . . . . . . . . . . . . . . . . . . .  13
       3.2.2  Followup-To  . . . . . . . . . . . . . . . . . . . . .  11
       3.5.4  13
       3.2.3  Expires  . . . . . . . . . . . . . . . . . . . . . . .  11
       3.5.5  13
       3.2.4  Control  . . . . . . . . . . . . . . . . . . . . . . .  11
       3.5.6  13
       3.2.5  Supersedes . . . . . . . . . . . . . . . . . . . . . .  14
       3.2.6  Distribution . . . . . . . . . . . . . . . . . . . . .  12
       3.5.7  14
       3.2.7  Summary  . . . . . . . . . . . . . . . . . . . . . . .  12
       3.5.8  14
       3.2.8  Approved . . . . . . . . . . . . . . . . . . . . . . .  12
       3.5.9  15
       3.2.9  Organization . . . . . . . . . . . . . . . . . . . . .  12
       3.5.10  15
       3.2.10   Xref . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.5.11   Supersedes . .  15
       3.2.11   Archive  . . . . . . . . . . . . . . . . . . .  13
       3.5.12   Archive . . .  15
       3.2.12   User-Agent . . . . . . . . . . . . . . . . . . .  13
       3.5.13   User-Agent . .  16
       3.2.13   Injection-Info . . . . . . . . . . . . . . . . . . .  13  16
   4.   Internationalization Considerations  . . . . . . . . . . . .  14  18
   5.   Security Considerations  . . . . . . . . . . . . . . . . . .  15  19
   6.   References . . . . . . . . . . . . . . . . . . . . . . . . .  16  20
   6.1  Normative References . . . . . . . . . . . . . . . . . . . .  16  20
   6.2  Informative References . . . . . . . . . . . . . . . . . . .  16  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17  21
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  19  23
        Intellectual Property and Copyright Statements . . . . . . .  20  24

1.  Introduction

1.1  Scope  Basic Concepts

   "Netnews" is a set of protocols for generating, storing and
   retrieving news "articles" (a subset of the Internet Message Format) (which resemble email messages) and for
   exchanging them among amongst a readership which is potentially widely
   distributed.  It is organized around "newsgroups", with the
   expectation that each reader will be able to see all articles posted
   to each newsgroup in which she 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.

   This is the first of four documents that obsolete RFC 1036.

1.2  Scope

   This document focuses on specifies the syntax and semantics of network news
   articles.  [usepro] is also a standards-track document, and describes articles in the
   context of the "Internet Message Format" [RFC2822] and "Multipurpose
   Internet Mail Extensions (MIME)" [RFC2045].  This document supersedes
   [RFC1036], updating it to reflect current practice and incorporating
   incremental changes specified in other documents such as
   [Son-of-1036].

   This is the first in a set of documents that obsolete [RFC1036].
   This document focuses on the syntax and semantics of network news
   articles.  [USEPRO] is also a standards-track document, and describes
   the protocol issues of network news articles, independent of
   transmission protocols such as NNTP [RFC0977] and IMAP [RFC3501]. [RFC0977].  An informational
   document, [useage], [USEAGE], describes implementation recommendations to
   improve interoperability and usability.  The
   fourth document, [useint], an experimental standard, specifies
   internationalization

   This specification is intended as a definition of message headers.

   The predecessor what article
   content format is to be passed between systems.  Though some news
   systems locally store articles in this document [RFC1036] said that: "In any
   situation where this standard conflicts with the Internet [email
   standard, format (which eliminates the latter] should be considered correct
   need for translation between formats) and this standard others use formats that
   differ from the one specified in error."  The basic philosophy this standard, local storage is
   outside of the scope of this document follows that
   previous convention, so as standard.

   Note: This standard is not intended to standardize dictate the internal formats
   used by sites, the specific news article syntax firmly
   as a subset system features that they are
   expected to support, or any of the Internet Message Format syntax.  Note characteristics of user interface
   programs that create or read articles.  In addition, this
   means that all news articles are suitable for email, but standard
   does not specify an encoding of the converse
   isn't necessarily true.

   In characters for either transport
   or storage; that is, it does not specify the context number of bits used or
   how those bits are specifically transferred over the Internet messaging architecture, different
   protocols (such as IMAP, POP3 [RFC1939], NNTP wire or stored
   on disk.

1.3  Requirements Notation

   This document occasionally uses terms that appear in capital letters.
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and SMTP [RFC2821]) "OPTIONAL" in this
   document are
   seen to be interpreted as alternative ways of moving around described in [RFC2119].

1.4  Syntax Notation

   Headers defined in this specification use the same content.  That
   content is the Internet Message Format as specified by [RFC2822],
   including optional enhancements such as MIME [RFC2049].  A user
   should be able to ingest an article via NNTP, read it via IMAP,
   forward it off to someone else via SMTP and have them read it via
   POP3 all without having to alter the content.

   This document uses a cite by reference methodology, rather than
   trying to repeat the contents of other standards, which could
   otherwise result in subtle differences and interoperability
   challenges.  Although this document is as a result rather short, it
   requires complete understanding and implementation of the normative
   references to be compliant.

1.2  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.3  Errata

   The RFC Editor makes available errata for RFCs at [errata].
   Implementers should review that page for normative references, noting
   in particular that errata currently exist for [RFC2046] and
   [RFC2231].

1.4  Syntax Notation

   Headers defined in this specification use the Augmented Backus-Naur
   Form (ABNF) notation (including Augmented Backus-Naur
   Form (ABNF) notation (including the Core Rules) specified in
   [RFC2234] and many constructs (specifically <date-time>,
   <mailbox-list>, <obs-zone>, and <unstructured>) defined in [RFC2822].  Section 3.4 3.1.4
   updates the [RFC2822] definition of <msg-id>.

1.5  Definitions

   An "article" is the unit of news, analogous to synonymous with an [RFC 2822] [RFC2822]
   "message".

   A "proto-article" "message identifier" Section 3.1.4 is one that has not yet been injected
   into a unique identifier for an
   article, usually supplied by the news system. "posting agent" which posted it or,
   failing that, by the "injecting agent".  It distinguishes the article
   from every other article ever posted anywhere.  Articles with the
   same message identifier are treated as if they are the same article
   regardless of any differences in the body or headers.

   A "newsgroup" is a single news forum, a logical bulletin board,
   having a name and nominally intended for articles on a specific
   topic.  An article is "posted to" a single newsgroup or several
   newsgroups.  When an article is posted to more than one newsgroup, it
   is said to be "crossposted"; note that this differs from posting the
   same text as part of each of several articles, one per newsgroup.

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

   A "gateway" "control message" is software an article which receives news articles and converts
   them to messages of some other kind (e.g.  mail to a mailing list),
   or vice versa; in essence it is marked as containing
   control information; a translating relaying or serving agent that
   straddles boundaries between different methods of message exchange.
   The most common type of gateway connects newsgroup(s) receiving such an
   article may (subject to mailing
   list(s), either unidirectionally or bidirectionally, but there are
   also gateways between news networks using this standard's news format the policies observed at that site) take
   actions beyond just filing and those using other formats. passing on the article.

1.6  Structure of This Document

   This document uses a cite by reference methodology, rather than
   repeating the contents of other standards, which could otherwise
   result in subtle differences and interoperability challenges.

   Although this document is as a result rather short, it requires
   complete understanding and implementation of the normative references
   to be compliant.

   Section 2 defines the format of news articles.  Section 3 defines
   some additional details the
   headers necessary to make an article suitable for the netnews
   environment.

2.  Format

2.1  Base

   News articles MUST conform to the "legal to generate syntax" syntax specified in Section 3 of
   [RFC2822].  News agents MAY also accept the obsolete syntax specified
   in Section 4 of [RFC2822], but they MUST NOT generate such syntax.

2.2  MIME Conformance

   User agents MUST meet the definition of MIME-conformance  Header Fields

   All headers fields in
   [RFC2049].  This level of MIME Conformance provides support for
   internationalization and multimedia a news article are compliant with [RFC2822],
   however this specification is more restrictive in message bodies, what can be
   generated and support accepted by news agents.  The syntax allowed for internationalization news
   articles is a strict subset of headers. the "Internet Message Format", making
   all messages compliant with this specification inherently compliant
   with [RFC2822].  Note however that the generation of
   internationalized newsgroup names for use in headers converse is specified by
   [useint].

2.3  Additional MIME Support

   User agents conformant with this document MAY support receipt (and
   automatic reassembly) of message/partial MIME messages, as specified not guaranteed to
   be true.

   General rules which apply to all headers (even those documented in Section 5.2.2 of [RFC2046]
   [RFC2822] and MAY support generation of message/
   partial articles for excessively large articles.

   User agents SHOULD support on receipt [RFC2045]) are listed below and MAY generate MIME extension
   header fields, including but not limited those that apply to Content-Disposition
   [RFC2183] and Content-Language [RFC3282].

3.  Internet Message Format Headers

   Following [RFC2822] syntax, the
   specific headers defined are described in the relevent sections of this document do
   not require a
   document.

   User agents MUST generate headers so that at least one space between
   immediately follows the ":" ':' separating the header name and the field's header
   contents.  (E.g.,
   "Subject:Hello World" is acceptable,  As a result, an <unstructured> header as opposed to requiring
   "Subject: Hello World".)  To defined in
   Section 3.2.6 of [RFC2822] MUST NOT be compliant with this specification,
   news empty (it will always contain
   at least a single space).  News agents MAY accept headers which do
   not contain the required space.

   Compliant software MUST support 0 or more spaces between headers of at least 998 octets.  This
   is the colon and only limit on the
   field's contents. length of a header line prescribed by this
   standard.  However, specific rules to maximize compatibility with the
   installed base contrary may apply in
   particular cases (for example, according to [RFC2047] header lines
   containing encoded-words are limited to 76 octets).

      NOTE: There is NO restriction on the number of news agents, implementers SHOULD use exactly one
   space.

3.1  Mandatory Headers

   Each news article conformant with this specification MUST have
   exactly one lines into which a
      header may be split, and hence there is NO restriction on the
      total length of each a header (in particular it may, by suitable
      folding, be made to exceed the 998 octets restriction pertaining
      to a single header line).

   The character set for headers is US-ASCII.  Where the use of
   non-ASCII characters is required, they MUST be encoded using the following headers: From, Subject, Date,
   Message-ID, Newsgroups, and Path.

   From and Subject are exactly as specified MIME
   mechanisms defined in Sections 3.6.2 [RFC2045] and 3.6.5
   respectively of [RFC2822].  Further discussion of [RFC2231].

2.3  MIME Conformance

   User agents MUST meet the content definition of the
   Subject header is discussed MIME-conformance in [usepro]
   [RFC2049].  This level of MIME Conformance provides support for
   internationalization and [useage].

   Date is fully multimedia in message bodies [RFC2045], and
   support for internationalization of headers [RFC2047].  Note that
   [Errata] currently exist for [RFC2046] and [RFC2231].

2.4  Additional MIME Support

   User agents conformant with [RFC2822], though with extra
   restrictions detailed in Section 3.3

   In Section 3.4, this document updates the <msg-id> construct from
   [RFC2822] so MAY support reassembly of
   message/partial MIME messages, as to ensure that Internet Message Format Message-IDs
   are usable in widely deployed news software.

   Newsgroups and Path are defined specified in Section 3.5.1 5.2.2 of
   [RFC2046] and Section 3.5.2
   respectively.

3.2  Optional Headers

   The headers Reply-To, Sender, Comments, MAY support generation of message/partial articles for
   excessively large articles.

   User agents SHOULD accept and Keywords are often used MAY generate MIME extension header
   fields, including but not limited to Content-Disposition [RFC2183]
   and Content-Language [RFC3282].

3.  News Headers

   The following news headers (also known as header fields) extend the
   fields defined in section 3.6 of [RFC2822] as follows:

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

   Each of these headers may occur at most once in a news articles and article.

3.1  Mandatory Headers

   Each news article conformant with this specification MUST have
   exactly one of each of the identical meaning following headers: From, Subject, Date,
   Message-ID, Newsgroups, Path, and Injection-Date.

3.1.1  From

   The From header is the same as that specified in
   [RFC2822].  References and In-Reply-To are also regularly used Section 3.6.2 of
   [RFC2822] with the added restrictions detailed in
   news articles and have same Section 2.2.

3.1.2  Subject

   The Subject header is the same meaning as that specified in
   [RFC2822], except that they use Section 3.6.5 of
   [RFC2822] with the updated <msg-id> construct
   defined added restrictions detailed in Section 3.4.

   The headers Followup-To, Expires, Control, Distribution, Summary,
   Approved, Organization, Xref, Supersedes, Archive, and User-Agent are
   often used 2.2.
   Further discussion of the content of the Subject header is discussed
   in news articles [USEPRO] and are defined in Section 3.5.

3.3 [USEAGE].

3.1.3  Date

   The Date header is the same as that specified in Sections 3.3 and
   3.6.1 of [RFC2822]. [RFC2822] with the added restrictions detailed in Section
   2.2.  However, the use of "GMT" and "UT" as a time zone, zones, which
   is are
   part of <obs-zone>, is widespread in news articles today.  Therefore,
   agents MUST accept, but MUST NOT generate, <date-time> constructs
   which include <obs-zone>.  (As  As stated in Section 2.1, support for
   <obs-zone> would otherwise have been SHOULD accept, MUST NOT generate.)
   generate.  Note that these requirements apply wherever <date-time> is
   used, including Injection-Date and Expires in Section 3.5.4.

3.4 3.1.7 and
   Section 3.2.3 respectively.

3.1.4  Message-ID

   The "Message-ID:" field Message-ID header contains a single unique message identifier.
   This is document updates the only header field definition <msg-id> construct from Section 3.6.4 of
   [RFC2822] so as to ensure that updates [RFC2822]. Internet Message Format Message-IDs
   are usable in widely deployed news software.  The ABNF should be used
   as below, but the requirements and descriptive text from Section
   3.6.4 of [RFC2822] still apply.

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

   msg-id          =  [CFWS]  [FWS] msg-id-core [CFWS] [FWS]

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

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

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

   no-fold-quote   =  DQUOTE *( qtext / no-space-qp ) DQUOTE

   no-fold-literal =  "[" *( htext / no-space-qp ) "]"

   no-space-qp     =  ( "\" ptext ) / obs-qp

   ptext           =  %d33-61 /  ; Printable characters excluding ">"
                      %d63-126 /
                      obs-text

   htext           =  HEXDIG /  ; hexadecimal digits, case-insensitive
                      "." /     ; IPv4 separator
                      ":"       ; IPv6 separator

   Although compliant agents

   The msg-id-core MUST support [CFWS] between NOT be more than 250 octets in length.

      NOTE: The length restriction ensures that systems which accept
      message identifiers as a parameter when retrieving an article
      (e.g.  NNTP [RFC0977]) can rely on a bounded length.  Observe that
      msg-id-core includes the
   "Message-ID:" < and >.

   Observe that in contrast to the <msg-id-core>, implementers SHOULD generate
   exactly one space there, corresponding header in [RFC2822],
   the syntax does not allow comments within the Message-ID header; this
   is to maximize compatibility simplify processing by relaying and serving agents and to
   ensure interoperability with the installed
   base.

   Note existing implementations.

   Also note that this updated ABNF applies wherever <msg-id> is used,
   including the In-Reply-To and References headers mentioned header discussed in Section
   3.2.

3.5  News Headers 3.2.1.

3.1.5  Newsgroups

   The following news headers (also known as Newsgroups header fields) extend specifies the
   fields defined in section 3.6 of [RFC2822] as follows:

   fields          =/ *( newsgroup(s) to which the article
   is posted.

   newsgroups      =  "Newsgroups:" SP newsgroup-list CRLF

   newsgroup-list  =  [FWS] newsgroup-name
                      *( "," [FWS] newsgroup-name ) [FWS]

   newsgroup-name  =  component *( "." component ) ; 66 character max

   component       =  plain-component

   plain-component =  component-start *29component-rest

   component-start =  ALPHA /
                         path /
                         followup-to DIGIT

   component-rest  =  ALPHA /
                         expires DIGIT /
                         control "+" /
                         distribution "-" /
                         summary "_"

   A newsgroup name consists of one or more components separated by
   periods, with no more than 66 characters total.  Each component
   consists of less than 30 or less letters and digits.  These limits
   are discussed further in Section 7.2 of [USEAGE].

3.1.6  Path

   The Path header indicates the route taken by an article since its
   entry into the Netnews system, so that unnecessary redundant
   transmission can be avoided.

   path            =  "Path:" SP path-list CRLF

   path-list       =  [FWS] path-identity
                      *( path-delimiter [FWS] path-identity ) [FWS]

   path-identity   =  ( ALPHA /
                         approved DIGIT )
                      *( ALPHA /
                         organization DIGIT /
                         xref "-" /
                         supersedes "." /
                         archive ":" /
                         user-agent "_" )

   Each

   path-delimiter  =  "!"

3.1.7  Injection-Date

   The Injection-Date header contains the date and time that the article
   was injected into the network.  Its purpose is to prevent the
   reinjection into the news stream of "stale" articles which have
   already expired by the time they arrive at some relaying or serving
   agent.

   This header is mandatory for new clients, but all agents SHOULD use
   the Date header for this purpose if Injection-Date is not present.

   injection-date  =  "Injection-Date:" SP date-time CRLF

   See the remarks under Section 3.1.3  regarding the syntax of
   date-time and the requirements and recommendations to which it is
   subject.

      NOTE: The date-time in this header would normally be expected to
      be later than the date-time in the Date header, but differences
      between the clocks on the various agents and other special
      circumstances might vitiate that; no provision is made for any
      such discrepancy to be corrected - better that the injecting agent
      should just insert the correct time as it sees it.

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

3.2  Optional Headers

   None of the headers appearing in this section is required to appear
   in every article but some of them are required in certain types of
   article, such as followups.  Further discussion of these requirements
   is discussed in [USEPRO] and [USEAGE].

   The headers may occur at most once Reply-To, Sender, Comments, and Keywords are often used
   in a news article.

3.5.1  Newsgroups articles and have the identical meaning as that specified in
   [RFC2822] with the added restrictions detailed in Section 2.2.

   The MIME headers Content-Type and Content-Transfer-Encoding are often
   used in news articles and have the identical meaning as that
   specified in [RFC2045] with the added restrictions detailed in
   Section 2.2.

   All other commonly used news headers are described below.

3.2.1  References

   The Newsgroups References header specifies to which newsgroup(s) the article is
   posted.

   newsgroups      =  "Newsgroups:" newsgroup-list CRLF

   newsgroup-list  =  [FWS] newsgroup-name
                      *( "," [FWS] newsgroup-name ) [FWS]

   newsgroup-name  =  component *( "." component ) ; 71 character max

   component       =  plain-component

   plain-component =  component-start *29component-rest

   component-start =  ALPHA / DIGIT

   component-rest  =  ALPHA / DIGIT / "+" / "-" / "_"

   A newsgroup name consists the same as that specified in Section 3.6.4
   of one or more components separated by
   periods, [RFC2822] with no more than 71 characters total.  Each component
   consists of less than 30 or less letters the added restrictions detailed in Section 2.2 and digits.

3.5.2  Path
   those listed below:

   o  The Path header's content indicates which relayers the article has
   already visited, so that unnecessary redundant transmission updated <msg-id> construct defined in Section 3.1.4 MUST be
      used.
   o  Message IDs MUST be separated with CFWS.
   o  Comments in CFWS between Message IDs can cause interoperability
      problems, so comments SHOULD NOT be
   avoided.

   path            =  "Path:" [FWS]
                      *( path-host [FWS] path-delimiter [FWS] )
                      path-host [FWS] CRLF

   path-host       =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

   path-delimiter  =  "!"

3.5.3 generated, but MUST be
      accepted.

3.2.2  Followup-To

   The Followup-To header specifies to which newsgroup(s) followups
   should be posted.

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

   poster-text     =  [FWS] %d112.111.115.116.101.114 [FWS]
                      ; "poster" in lower-case

   The syntax is the same as that of the Newsgroups content, header (Section
   3.1.5, with the exception that the magic word "poster" (which is
   always lowercase) means that followups should be mailed to the
   article's reply address rather than posted.

3.5.4  In order to improve
   interoperability with deployed clients, followup agents MAY choose to
   recognize case-insensitive forms such as "Poster".

3.2.3  Expires

   The Expires header specifies a date and time when the article is
   deemed to be no longer useful and could usefully be removed
   ("expired").

   expires         =  "Expires:" SP date-time CRLF

3.5.5

   See the remarks under Section 3.1.3  regarding the syntax of
   date-time and the requirements and recommendations to which it is
   subject.

3.2.4  Control

   The Control header marks the article as a control message, and
   specifies the desired actions (additional to the usual ones of
   storing and/or relaying the article).

   control         =  "Control:" SP [CFWS] control-message [CFWS] CRLF

   control-message = <empty>

   The verb control-message indicates what action should be taken, and the argument(s) (if any) supply details.  In
   some cases, the body of the article may also contain details.
   Control messages are further taken.  The exact
   syntax for control-message is specified in the companion document,
   [usepro]. companion document,
   [USEPRO].

3.2.5  Supersedes

   The Supersedes header contains a message identifier specifying an
   article to be superseded upon the arrival of this one.  The specified
   article MUST be treated as though a "cancel" [USEPRO] control         =  "Control:" verb *( FWS argument ) CRLF

   An message
   had arrived for the article with (but observe that a Control header MUST NOT have site MAY choose not
   to honor a Supersedes header.

3.5.6 "cancel" message, especially if its authenticity is in
   doubt).

   supersedes      =  "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF

   NOTE: There is no "c" in Supersedes.

3.2.6  Distribution

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

   distribution    =  "Distribution:" SP dist-list CRLF

   list-list       =  [FWS] dist-name *( "," [FWS] dist-name ) CRLF [FWS]

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

   "All" MUST NOT be used as a distribution-name.  Distribution-names
   SHOULD contain at least three characters, except when they are
   two-letter country names as in [ISO.3166.1988].  Distribution-names
   are case-insensitive (i.e.  "US", "Us", "uS", and "us" all specify
   the same distribution).

3.5.7

3.2.7  Summary

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

   summary         =  "Summary:" SP unstructured CRLF

3.5.8

3.2.8  Approved

   The Approved header indicates the mailing addresses (and possibly the
   full names) of the moderators approving the article for posting.

   approved        =  "Approved:" SP mailbox-list CRLF

3.5.9

3.2.9  Organization

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

   organization    =  "Organization:" SP unstructured CRLF

   There is no "s" in Organization.

3.5.10

3.2.10  Xref

   The Xref header indicates where an article was filed by the last
   server
   serving agent to process it.

   xref            =  "Xref:" SP [CFWS] path-host server-name
                      1*( CFWS location ) [CFWS] CRLF

   server-name     =  path-identity

   location        =  newsgroup-name ":" 1*16DIGIT

3.5.11  Supersedes

   The Supersedes header specifies articles to be cancelled.

   supersedes article-locator

   article-locator =  "Supersedes:"  1*( [FWS] msg-id-core %x21-27 / %x29-3A / %x3C-7E ) CRLF

   There
                      ; US-ASCII printable characters
                      ; except '(' and ';'

   The server-name is no "c" included so that software can determine which
   serving agent generated the header.  The locations specify what
   newsgroups the article was filed under (which may differ from those
   in Supersedes.

3.5.12 the Newsgroups-header) and where it was filed under them.  The
   exact form of an article-locator is implementation-specific.

   NOTE: The traditional form of an article-locator (as used by NNTP) is
   a decimal number, with articles in each newsgroup numbered
   consecutively starting from 1.

3.2.11  Archive

   The Archive header provides an indication of the poster's intent
   regarding preservation of the article in publicly accessible
   long-term or permanent storage.

   archive         =  "Archive:" SP [CFWS] ("no" / "yes")
                      *( [CFWS] ";" archive-param ) CRLF

   archive-param   =  <a parameter with attribute "filename"
                       and any value>

3.5.13

3.2.12  User-Agent

   The User-Agent header contains information about the user agent
   (typically a newsreader) generating the article for statistical
   purposes and tracing tracing of standards violations to specific software
   needing correction.  Although not one of the mandatory headers,
   posting agents SHOULD normally include it.  It is also intended that
   this header be suitable for use in Email.

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

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

   product-version =  [CFWS] token [CFWS]

3.2.13  Injection-Info

   The Injection-Info header provides information as to how an article
   entered the Netnews system and to assist in tracing its true origin.

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity [CFWS]
                      *( ";" injection-info-parameter )

   injection-info-parameter
                   =  posting-host-parameter /
                      posting-account-parameter /
                      posting-sender-parameter /
                      posting-logging-parameter

   posting-host-parameter
                   =  <a parameter with attribute "posting-host"
                       and value some host-value>

   host-value      =  dot-atom / [ dot-atom ":" ]
                      ( IPv4address / IPv6address ) ;  see [RFC 2373]

   posting-account-parameter
                   =  <a parameter with attribute "posting-account"
                       and any value>

   posting-sender-parameter
                   =  <a parameter with attribute "sender"
                       and value some sender-value>

   sender-value    =  mailbox / "verified"

   posting-logging-parameter
                   =  <a parameter with attribute "logging-data"
                       and any value>

   Although comments and folding of standards violations to specific software
   needing correction.  Although white space are permitted throughout
   the Injection-Info header, it is RECOMMENDED that folding is not one of used
   within any parameter (but only before or after the mandatory headers,
   posting agents SHOULD normally include it. ";" separating
   those parameters), and that comments are only used following the last
   parameter.  It is also intended RECOMMENDED that
   this header be suitable for use such parameters as are
   present are included in Email.

   user-agent      =  "User-Agent:"
                       1*( [CFWS] product [ "/" prod-version ] ) CRLF

   product         =  token
   prod-version    =  token the order in which they have been defined in
   the syntax above.

   This header is intended to replace various currently-used but
   undocumented headers such as "NNTP-Posting-Host" and "X-Trace".
   These headers are now deprecated.

4.  Internationalization Considerations

   Internationalization of news article headers and bodies is provided
   using MIME mechanisms discussed in Section 2.2.  Generation 2.3.  Note that the
   generation of internationalized message newsgroup names for use in headers is
   not specified addressed in this document, and is instead specified
   in the experimental standard, [useint]. document.

5.  Security Considerations

   The news article format specified in this document does not provide
   any security services, such as confidentiality, authentication of
   sender, or non-forgery. non-repudiation.  Instead, such services need to be
   layered above, using such protocols as S/MIME [RFC2633] or PGP/MIME
   [RFC3156], or below, using secure versions of news transport
   protocols.  Additionally, several currently non-standardized
   protocols [PGPVERIFY] will hopefully be standardized in the near
   future.

   Message-IDs (see Section 3.4) (Section 3.1.4) in news are required to be unique;
   articles are refused (in server-to-server transfer) if the ID has
   already been seen.  So if you can predict the ID of a message, you
   can preempt it by posting a message (possibly to a quite different
   group) with the same ID, stopping your target message from
   propagating.  Agents that generate message-ids for news articles
   SHOULD ensure that they are unpredictable.

   The filename parameter of the Archive-header (Section 3.2.11) can be
   used to attempt to store archived articles in inappropriate
   locations.  Archiving sites should be suspicious of absolute filename
   parameters, as opposed to those relative to some location of the
   archiver's choosing.

6.  References

6.1  Normative References

   [Errata]   "RFC Editor Errata".

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

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

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

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

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

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

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

   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2646]  Gellens, R., "The Text/Plain Format Parameter", RFC 2646,
              August 1999.

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

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282, May
              2002.

6.2  Informative References

   [ISO.3166.1988]
              International Organization for Standardization, "Codes for
              the representation of names of countries, 3rd edition",
              ISO Standard 3166, August 1988.

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

   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
              Protocol", RFC 977, February 1986.

   [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
              USENET messages", RFC 1036, December 1987.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2633]  Ramsdell, B., "S/MIME Version 3 Message Specification",
              RFC 2633, June 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R. and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

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

   [useage]   "Usenet Implementation Recommendations (work in
              progress)".

   [useint]   "Usenet Internationalization (work in progress)".

   [usepro]

   [Son-of-1036]
              Spencer, H., "News Article Format and Transmission", June
              1994.

   [USEAGE]   Lindsey, C., "Usenet Protocol (work in progress)". Best Practice",
              draft-ietf-usefor-useage-*.txt.

   [USEPRO]   Lindsey, C., "News Article Architecture and Protocols",
              draft-ietf-usefor-usepro-*.txt.

Authors' Addresses

   Charles H. Lindsey
   University of Manchester
   5 Clerewood Avenue
   Heald Green
   Cheadle
   Chesire  SK8 3JU
   GB

   Phone: +44 161 436 6131
   EMail: chl@clw.cs.man.ac.uk
   Dan Kohn
   Skymoon Ventures
   3045 Park Boulevard
   Palo Alto, CA  94306
   US

   Phone: +1 650 327 2600
   EMail: dan@dankohn.com

   Kenneth Murchison
   Oceana Matrix Ltd.
   21 Princeton Place
   Orchard Park, NY  14127
   US

   Phone: +1 716 662 8973
   EMail: ken@oceana.com
   Dan Kohn
   Skymoon Ventures
   3045 Park Boulevard
   Palo Alto, CA  94306
   US

   Phone: +1 650 327 2600
   EMail: dan@dankohn.com

Appendix A.  Acknowledgements

   Comments and/or text were provided by Mark Crispin, Claus Faerber,
   Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson,
   Bruce Lilly, Pete Resnick, and Henry Spencer.

Intellectual Property Statement

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

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   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 (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.