[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5536

Usenet Format Working Group                            K. Murchison, Ed.
Internet-Draft                                        Oceana Matrix Ltd.
Obsoletes: 1036 (if approved)                                 C. Lindsey
Expires: October 8, 2005                        University of Manchester
                                                                 D. Kohn
                                                        Skymoon Ventures
                                                           April 6, 2005


                          News Article Format
                      draft-ietf-usefor-usefor-03

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 October 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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



Murchison, et al.        Expires October 8, 2005                [Page 1]

Internet-Draft             News Article Format                April 2005


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

   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-message> is a verb optionally followed by
      whitespace-separated arguments.





Murchison, et al.        Expires October 8, 2005                [Page 2]

Internet-Draft             News Article Format                April 2005


   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-kohn-news-article-03

   o  Document is now a work product of USEFOR

   o  Added new co-authors

   o  Added some definitions from draft-ietf-usefor-article-13

   o  Removed discussion of message/partial MIME messages.

   o  Removed text that belongs in [USEPRO]

   o  Reorganized header sections

   o  Added Archive, User-Agent, Injection-Date, and Injection-Info
      headers.

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

   o  Removed restrictions on length and start character for Newsgroups.

   o  Added required SP to ABNF of header definitions.

   o  Disallowed comments in Control header.

   o  Xref header allows for non-digit "locations".

   o  Only allow for a single message-id in Supersedes header.

   o  Changes to the References header.

   o  Compatibility changes based on comments from Charles


Changes since draft-ietf-usefor-article-13





Murchison, et al.        Expires October 8, 2005                [Page 3]

Internet-Draft             News Article Format                April 2005


   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  Decide which definitions should go in this document and in
      [USEPRO].

   o  Do we want to discuss message/partial?

   o  Add appendixes for changes from RFC 1036 and differences from RFC
      2822.

   o  IANA considerations (the Klyne message header registry is now
      official as RFC 3864).

   o  Collected Syntax.

   o  Merge more security issues?

   o  Merge acknowledgments?























Murchison, et al.        Expires October 8, 2005                [Page 4]

Internet-Draft             News Article Format                April 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.1  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .   6
     1.2  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3  Requirements Notation  . . . . . . . . . . . . . . . . . .   6
     1.4  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .   7
     1.5  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   7
     1.6  Structure of This Document . . . . . . . . . . . . . . . .   8
   2.   Format . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.1  Base . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.2  Headers  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.3  MIME Conformance . . . . . . . . . . . . . . . . . . . . .  10
   3.   News Headers . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1  Mandatory Headers  . . . . . . . . . . . . . . . . . . . .  11
       3.1.1  From . . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.2  Date . . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.3  Message-ID . . . . . . . . . . . . . . . . . . . . . .  12
       3.1.4  Subject  . . . . . . . . . . . . . . . . . . . . . . .  14
       3.1.5  Newsgroups . . . . . . . . . . . . . . . . . . . . . .  14
       3.1.6  Path . . . . . . . . . . . . . . . . . . . . . . . . .  15
       3.1.7  Injection-Date . . . . . . . . . . . . . . . . . . . .  15
     3.2  Optional Headers . . . . . . . . . . . . . . . . . . . . .  16
       3.2.1  References . . . . . . . . . . . . . . . . . . . . . .  16
       3.2.2  Followup-To  . . . . . . . . . . . . . . . . . . . . .  17
       3.2.3  Expires  . . . . . . . . . . . . . . . . . . . . . . .  17
       3.2.4  Control  . . . . . . . . . . . . . . . . . . . . . . .  17
       3.2.5  Supersedes . . . . . . . . . . . . . . . . . . . . . .  18
       3.2.6  Distribution . . . . . . . . . . . . . . . . . . . . .  18
       3.2.7  Summary  . . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.8  Approved . . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.9  Organization . . . . . . . . . . . . . . . . . . . . .  19
       3.2.10   Xref . . . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.11   Archive  . . . . . . . . . . . . . . . . . . . . . .  20
       3.2.12   User-Agent . . . . . . . . . . . . . . . . . . . . .  20
       3.2.13   Injection-Info . . . . . . . . . . . . . . . . . . .  21
     3.3  Obsolete Headers . . . . . . . . . . . . . . . . . . . . .  23
       3.3.1  Lines  . . . . . . . . . . . . . . . . . . . . . . . .  24
   4.   Internationalization Considerations  . . . . . . . . . . . .  25
   5.   Security Considerations  . . . . . . . . . . . . . . . . . .  26
   6.   References . . . . . . . . . . . . . . . . . . . . . . . . .  27
     6.1  Normative References . . . . . . . . . . . . . . . . . . .  27
     6.2  Informative References . . . . . . . . . . . . . . . . . .  27
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  28
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  30
        Intellectual Property and Copyright Statements . . . . . . .  31





Murchison, et al.        Expires October 8, 2005                [Page 5]

Internet-Draft             News Article Format                April 2005


1.  Introduction

1.1  Basic Concepts

   "Netnews" is a set of protocols for generating, storing and
   retrieving news "articles" (which are a subset of Email messages) and
   for exchanging them 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 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 network news (Netnews) 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 changes and clarifications specified in
   other documents such as [Son-of-1036].

   This is the first in a set of documents that obsolete [RFC1036].
   This document focuses on the syntax and semantics of Netnews
   articles.  [USEPRO] is also a standards-track document, and describes
   the protocol issues of Netnews articles, independent of transport
   protocols such as [NNTP].  An best common practice document,
   [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.  Though some news
   systems locally store articles in this format (which eliminates the
   need for translation between formats) and others use formats that
   differ from the one specified in this standard, local storage is
   outside of the scope of this standard.

1.3  Requirements Notation

   This document uses terms that appear in capital letters.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].






Murchison, et al.        Expires October 8, 2005                [Page 6]

Internet-Draft             News Article Format                April 2005


1.4  Syntax Notation

   Headers defined in this specification use the Augmented Backus-Naur
   Form (ABNF) notation (including the Core Rules) specified in
   [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
   Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of
   <zone> and <msg-id> respectively.

1.5  Definitions

   An "article" is the unit of news, synonymous with an [RFC2822]
   "message".  A "proto-article" is one that has not yet been injected
   into the news system.  In constrast to an "article", a "proto-
   article" may lack some mandatory headers.

   A "message identifier" Section 3.1.3 is a unique identifier for an
   article, usually supplied by the "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 "poster" is the person or software that composes and submits a
   possibly compliant article to a "posting agent".  The poster is
   analogous to [RFC2822]'s author.

   A "posting agent" is the software that assists posters to prepare
   proto-articles, in compliance with this standard.  The proto-article
   is then passed on to an "injecting agent" for final checking and
   injection into the news stream.  If the article is not compliant, or
   is rejected by the injecting agent, then the posting agent informs
   the poster with an explanation of the error.

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

   A "reading agent" is software which presents articles to a reader.



Murchison, et al.        Expires October 8, 2005                [Page 7]

Internet-Draft             News Article Format                April 2005


   A "followup" is an article containing a response to the contents of
   an earlier article (the followup's "precursor").

   A "followup agent" is a combination of reading agent and posting
   agent that aids in the preparation and posting of a followup.

   Posting, reading and followup agents (which are usually just
   different services provided by the same piece of software) are known
   collectively as "user agents".

   An "injecting agent" takes the finished article from the posting
   agent (often via the [NNTP] "post" command) performs some final
   checks and passes it on to a relaying agent for general distribution.

   A "control message" is an article which is marked as containing
   control information; a relaying or serving agent receiving such an
   article may (subject to the policies observed at that site) take
   actions beyond just filing and 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 details the
   headers necessary to make an article suitable for the netnews
   environment.




















Murchison, et al.        Expires October 8, 2005                [Page 8]

Internet-Draft             News Article Format                April 2005


2.  Format

2.1  Base

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

   This specification uses the terms "header", "header name", and
   "header content" which are synonymous with the [RFC2822] terms
   "header field", "field name", and "field body" respectively.

2.2  Headers

   All headers in a news article are compliant with [RFC2822], however
   this specification is less permissive in what can be generated and
   accepted by news agents.  The syntax allowed for news articles is a
   strict subset of the "Internet Message Format", making all messages
   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 headers (even those documented in
   [RFC2822] and [RFC2045]) are listed below and those that apply to
   specific headers are described in the relevent sections of this
   document.

   o  All agents MUST generate headers so that at least one space
      immediately follows the ':' separating the header name and the
      header contents (for compatibility with deployed software).  News
      agents MAY accept headers which do not contain the required space.

   o  The header contents of every header line (including the first and
      any that are subsequently folded) MUST contain at least one non-
      whitespace character.

         NOTE: This means that no header content defined by or
         referenced by this document can be empty.  As a result, this
         document updates the <unstructured> construct from Section
         3.2.6 of [RFC2822] as follows:

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

   o  Compliant software MUST NOT generate (but MAY accept) headers of
      more than 998 octets.  This is the only limit on the length of a
      header line prescribed by this standard.  However, specific rules
      to the contrary may apply in particular cases (for example,



Murchison, et al.        Expires October 8, 2005                [Page 9]

Internet-Draft             News Article Format                April 2005


      according to [RFC2047] header lines containing encoded-words are
      limited to 76 octets).  [USEAGE] includes suggested limits for
      convenience of display by user agents.

         NOTE: There is NO restriction on the number of lines into which
         a header may be split, and hence there is NO restriction on the
         total length of a header (in particular it may, by suitable
         folding, be made to exceed the 998 octets restriction
         pertaining to a single header line).

   o  The character set for headers is US-ASCII.  Where the use of non-
      ASCII characters is required, they MUST be encoded using the MIME
      mechanisms defined in [RFC2047] and [RFC2231].


2.3  MIME Conformance

   User agents MUST meet the definition of MIME-conformance in [RFC2049]
   and MUST also support [RFC2231].  This level of MIME Conformance
   provides support for internationalization and multimedia in message
   bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
   internationalization of headers ([RFC2047], [RFC2231]).  Note that
   [Errata] currently exist for [RFC2046] and [RFC2231].

   For the purposes of Section 5 of [RFC2047], all headers defined in
   Section 3 of this standard are to be considered as "extension message
   header fields" (insofar as they are not already considered under the
   existing Email standards), permitting the use of [RFC2047] encodings
   within any <unstructured> header, or within any <comment> or <phrase>
   permittted within any structured header.

   User agents MAY accept and generate other MIME extension headers, and
   in particular SHOULD accept Content-Disposition [RFC2183] and
   Content-Language [RFC3282].

















Murchison, et al.        Expires October 8, 2005               [Page 10]

Internet-Draft             News Article Format                April 2005


3.  News Headers

   The following news headers extend those defined in section 3.6 of
   [RFC2822]:

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

3.1  Mandatory Headers

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

3.1.1  From

   The From header 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 is the same as that specified in Sections 3.3 and
   3.6.1 of [RFC2822] with the added restrictions detailed in
   Section 2.2.  However, the use of "UT" and "GMT" as time zones (part
   of <obs-zone>), although deprecated, is widespread in news articles
   today.  Therefore, agents MUST accept <date-time> constructs which
   include the updated <zone> construct below.

   orig-date       =  "Date:" SP date-time CRLF




Murchison, et al.        Expires October 8, 2005               [Page 11]

Internet-Draft             News Article Format                April 2005


   zone            =  (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"

   Note that agents SHOULD NOT generate <date-time> constructs which
   include either "UT" or "GMT" and MUST NOT generate <date-time>
   constructs which include any other zone names defined by <obs-zone>,
   some of which have ambiguous interpretations and would have adverse
   effects on the Netnews protocols.

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

3.1.3  Message-ID

   The Message-ID header contains a single unique message identifier.
   This document updates the <msg-id> construct from Section 3.6.4 of
   [RFC2822] so as to ensure that Internet Message Format Message-IDs
   are usable in widely deployed news software.  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.  A revised syntax for <msg-id> is
   given below, but the requirements and descriptive text from Section
   3.6.4 of [RFC2822] still apply.




























Murchison, et al.        Expires October 8, 2005               [Page 12]

Internet-Draft             News Article Format                April 2005


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

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

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

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

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

   no-fold-quote   =  DQUOTE
                         *( mqtext / mquoted-pair )
                         mqspecial
                         *( mqtext / mquoted-pair )
                         DQUOTE

   mqtext          =  %d33 /           ; all of <text> except
                      %d35-61 /        ; controls, SP, HTAB, "\", ">"
                      %d63-91 /        ; and DQUOTE
                      %d93-126

   mquoted-pair    =  "\\" / "\" DQUOTE

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

   no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"

   [[Adjacent dots should not be allowed]]

   mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                      %d63-90 /        ; characters not including
                      %d94-126         ; ">", "[", "]", or "\"

   The msg-id-core MUST 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]) can rely on a bounded length.

   Observe that msg-id-core includes the < and >.

   Observe also that in contrast to the corresponding header in



Murchison, et al.        Expires October 8, 2005               [Page 13]

Internet-Draft             News Article Format                April 2005


   [RFC2822], the syntax does not allow comments within the Message-ID
   header, it ensures that no string of characters is quoted unless
   strictly necessary (it must contain at least one mqspecial) and no
   single character is prefixed by a "\" in the form of a quoted-pair
   unless strictly necessary, and moreover there is no possibility for
   ">" or WSP to occur inside a msg-id-core, whether quoted or not.
   This is to simplify processing by relaying and serving agents and to
   ensure interoperability with existing implementations.  Thus, whereas
   under [RFC2822] the following <msg-id-core>s would be considered
   semantically equivalent,

   <abcd@example.com>
   <"abcd"@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-core>s.

   Also note that this updated ABNF applies wherever <msg-id-core> is
   used, including the References header discussed in Section 3.2.1 and
   the Supersedes header discussed in Section 3.2.5.

3.1.4  Subject

   The Subject header 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 appears in
   [USEPRO] and [USEAGE].

   subject         =  "Subject:" SP unstructured CRLF


3.1.5  Newsgroups

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

   newsgroups      =  "Newsgroups:" SP newsgroup-list CRLF

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

   newsgroup-name  =  component *( "." component )

   component       =  1*component-char

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



Murchison, et al.        Expires October 8, 2005               [Page 14]

Internet-Draft             News Article Format                April 2005


      NOTE: Observe that the syntax does not allow comments within the
      Newsgroups header; this is to simplify processing by relaying and
      serving agents which have a requirement to process this header
      extremely rapidly.

   Components beginning with underline ("_") are reserved for use by
   future versions of this standard and MUST NOT occur in <newsgroup-
   name>s (whether in Newsgroups headers or in newgroup control messages
   [USEPRO]).  However, such names MUST be accepted.

   The specific format and lengths of <newsgroup-name> and <component>
   are discussed in [USEAGE].

3.1.6  Path

   The Path header indicates the route taken by an article since its
   injection into the Netnews system.  Each agent that processes an
   article is required to prepend one (or more) identities to this
   header.  This is primarily to enable relaying agents 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 Usenet statistics.

   path            =  "Path:" SP path-list CRLF

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

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

   tail-entry      =  path-identity

   path-delimiter  =  "!" ; possible other delimiters TBD

   The specific format and use of <path-identity> and <tail-entry> are
   discussed in [USEPRO].

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.

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



Murchison, et al.        Expires October 8, 2005               [Page 15]

Internet-Draft             News Article Format                April 2005


   See the remarks under Section 3.1.2  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
   appears in [USEPRO] and [USEAGE].

   The headers Reply-To, Sender, Comments, and Keywords are used in news
   articles in the same circumstances and with the same meaning as that
   specified in [RFC2822] with the added restrictions detailed in
   Section 2.2.  Multiple occurances of the Keywords header 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

   The MIME headers MIME-Version, Content-Type, Content-Transfer-
   Encoding, Content-Disposition, and Content-Language are used in news
   articles in the same circumstances and with the same meanings as
   those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
   restrictions detailed in Section 2.2.

   All remaining news headers are described below.

3.2.1  References

   The References header is the same as that specified in Section 3.6.4
   of [RFC2822] with the added restrictions detailed in Section 2.2 and
   those listed below:




Murchison, et al.        Expires October 8, 2005               [Page 16]

Internet-Draft             News Article Format                April 2005


   o  The updated <msg-id-core> 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      =  "References:" SP 1*( [CFWS] msg-id-core) [CFWS]
                      CRLF


3.2.2  Followup-To

   The Followup-To header specifies to which newsgroup(s) followups
   should be posted.  The Followup-To header SHOULD NOT appear in a
   message, unless its content is different from the content of the
   Newsgroups header.

   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 header
   (Section 3.1.5, with the exception that the keyword "poster" (which
   is always lowercase) requests that followups should be mailed to the
   article's reply address rather than posted.  Although the keyword
   "poster" is case-sensitive, 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 relevant and could usefully be removed
   ("expired").

   expires         =  "Expires:" SP date-time CRLF

   See the remarks under Section 3.1.2  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



Murchison, et al.        Expires October 8, 2005               [Page 17]

Internet-Draft             News Article Format                April 2005


   specifies the desired actions (additional to the usual ones of
   storing and/or relaying the article).

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

   control-message =  verb *( [FWS] argument )

   verb            =  token

   argument        =  value

   The verb 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.  The legal verbs and respective arguments are
   discussed in the companion document, [USEPRO].

   An article with a Control header MUST NOT also have a Supersedes
   header.

3.2.5  Supersedes

   The Supersedes header contains a message identifier specifying an
   article to be superseded upon the arrival of this one.  An article
   containing a Supersedes header is equivalent to a "cancel" [USEPRO]
   control message for the specified article, followed immediately by
   the new article without the Supersedes header.

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

   NOTE: There is no "c" in Supersedes.

   NOTE: The Supersedes header defined here has no connection with the
   Supersedes header that sometimes appears in Email messages converted
   from X.400 according to [RFC2156]; in particular, the syntax here
   permits only one <msg-id-core> in contrast to the multiple <msg-id-
   core>s in that Email version.

3.2.6  Distribution

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

   distribution    =  "Distribution:" SP distribution-list CRLF

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

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



Murchison, et al.        Expires October 8, 2005               [Page 18]

Internet-Draft             News Article Format                April 2005


   The <dist-name>s "world" and "local" are predefined.  However,
   "world" SHOULD NOT be used explicitly, since it is the default when
   the Distribution header is absent entirely.

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

3.2.7  Summary

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

   summary         =  "Summary:" SP unstructured CRLF


3.2.8  Approved

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

   approved        =  "Approved:" SP mailbox-list CRLF

   Each mailbox contained in the Approved header MUST be that of one of
   the person(s) or entity(ies) in question, and one of those mailboxes
   MUST be that of the actual injector of the article.  Note that this
   standard doesn't provide any means to enforce or verify this
   requirement, but future extensions or standards may provide such a
   facility (e.g. digitial signatures).

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.2.10  Xref

   The Xref header indicates where an article was filed by the last
   serving agent to process it.  The article locations are used to keep
   track of crossposted articles so that reading agents serviced by a
   particular serving agent can mark such articles as read.




Murchison, et al.        Expires October 8, 2005               [Page 19]

Internet-Draft             News Article Format                April 2005


   xref            =  "Xref:" SP [CFWS] server-name
                      1*( CFWS location ) [CFWS] 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
   serving agent generated the header.  The locations specify what
   newsgroups the article was filed under (which may differ from those
   in 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 required 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   =  parameter

   The presence of an "Archive: no" header in an article indicates that
   the poster does not permit redistribution from publicly accessible
   long-term or permanent archives.  The absence of this header, or an
   explicit "Archive: 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.12  User-Agent

   The User-Agent header 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 be suitable for
   use in Email.



Murchison, et al.        Expires October 8, 2005               [Page 20]

Internet-Draft             News Article Format                April 2005


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

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

   product-version =  [CFWS] token

   This header MAY contain multiple product-tokens identifying the agent
   and any subproducts which form a significant part of the posting
   agent, listed in order of their significance for identifying the
   application.

      NOTE: This header supersedes the role performed redundantly by
      experimental headers such as X-Newsreader, X-Mailer, X-Posting-
      Agent, X-Http-User-Agent, and other headers previously used on
      Usenet and in Email for this purpose.  Use of these experimental
      headers SHOULD be discontinued in favor of the single, standard
      User-Agent header.

      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.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.
   It can also specify one or more addresses where complaints concerning
   the poster of the article may be sent.





















Murchison, et al.        Expires October 8, 2005               [Page 21]

Internet-Draft             News Article Format                April 2005


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

   inj-info-param  =  post-host-param /
                      post-account-param /
                      sender-param /
                      logging-param /
                      complainto-param

   [[Each parameter is allowed only once?]]

   [[Should also allow for x-attributes?]]

   post-host-param =  "posting-host" "=" host-value

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

   post-acct-param =  "posting-account" "=" value

   sender-param    =  "sender" "=" sender-value

   sender-value    =  mailbox / "verified"

   logging-param   =  "logging-data" "=" value

   complainto-param=  "complaints-to" "=" address-list


   Although comments and folding of white space are permitted throughout
   the Injection-Info header, it is RECOMMENDED that folding is not used
   within any parameter (but only before or after the ";" separating
   those parameters), and that comments are only used following the last
   parameter.

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

   The "posting-host" parameter specifies the FQDN and/or IP address
   (IPv4address or IPv6address) of the host from which the injecting
   agent 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 true origin of the
      article.




Murchison, et al.        Expires October 8, 2005               [Page 22]

Internet-Draft             News Article Format                April 2005


   The "posting-account" parameter identifies the source from which the
   injecting agent received the article.  For security reasons, it
   SHOULD be in a cryptic notation understandable only by the
   administrator of the injecting agent.

   The "sender" parameter identifies the mailbox of the verified sender
   of the article (alternatively, it uses the token "verified" to
   indicate that at least any addr-spec in the Sender header of the
   article, or in the From header if the Sender header is absent, is
   correct).  If an injecting agent can verify sender of an article, it
   SHOULD use this parameter in favour of the "posting-account"
   parameter.

   The "logging-data" parameter contains information (typically a
   session number or other non-persistent means of identifying a posting
   account) which will enable the true origin of the article to be
   determined by reference to logging information kept by the injecting
   agent.

   The "complaints-to" parameter specifies mailbox(es) for sending
   complaints concerning the behaviour of the poster of the article.

3.3  Obsolete Headers

   Early versions of news software following the modern format sometimes
   generated headers like the following:

   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 relaying agent
   that last processed the article.  Posting-Version contained version
   information about the posting agent that posted the article.  Date-
   Received contained the date when the last relaying agent to process
   the article first saw it (in a slightly nonstandard format).

   In addition, this present standard obsoletes certain headers 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 a control message that was also intended to be
   filed as a normal article.  See-Also listed related articles, but
   without the specific relationship with followups that pertains to the



Murchison, et al.        Expires October 8, 2005               [Page 23]

Internet-Draft             News Article Format                April 2005


   References-header.  Article-Names indicated some special significance
   of that article in relation to the indicated newsgroup.  Article-
   Updates indicated that an earlier article was updated, without at the
   same time being superseded.

   The headers listed above are documented for historical purposes only.
   Articles containing these headers MUST NOT be generated.  Persons
   writing new agents SHOULD ignore any former meanings these headers.

3.3.1  Lines

   The Lines header indicates the number of lines in the body of the
   article.

   lines           =  "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] 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
   headers and the body is not part of the body).  The "body" here is
   the body as found in the posted article as transmitted by the posting
   agent.

   Historically, this header was used by the [NNTP] overview extension,
   but its use for this purpose is now deprecated.  As a result, this
   header is to be regarded as obsolete, and it will likely be removed
   entirely in a future version of this standard.























Murchison, et al.        Expires October 8, 2005               [Page 24]

Internet-Draft             News Article Format                April 2005


4.  Internationalization Considerations

   Internationalization of news article headers and bodies is provided
   using MIME mechanisms discussed in Section 2.3.  Note that the
   generation of internationalized newsgroup names for use in headers is
   not addressed in this document.













































Murchison, et al.        Expires October 8, 2005               [Page 25]

Internet-Draft             News Article Format                April 2005


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-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 (Section 3.1.3) 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.

































Murchison, et al.        Expires October 8, 2005               [Page 26]

Internet-Draft             News Article Format                April 2005


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., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

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



Murchison, et al.        Expires October 8, 2005               [Page 27]

Internet-Draft             News Article Format                April 2005


   [NNTP]     Feather, C., "Network News Transfer Protocol",
              draft-ietf-nntpext-base-*.txt.

   [PGPVERIFY]
              Lawrence, D., "PGPverify", June 1999.

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

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

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

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

   [USEAGE]   Lindsey, C., "Usenet Best Practice",
              draft-ietf-usefor-useage-*.txt.

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


Authors' Addresses

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

   Phone: +1 716 662 8973
   Email: ken@oceana.com







Murchison, et al.        Expires October 8, 2005               [Page 28]

Internet-Draft             News Article Format                April 2005


   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































Murchison, et al.        Expires October 8, 2005               [Page 29]

Internet-Draft             News Article Format                April 2005


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, Henry Spencer, Russ Allbery, and Alexey
   Melnikov.













































Murchison, et al.        Expires October 8, 2005               [Page 30]

Internet-Draft             News Article Format                April 2005


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




Murchison, et al.        Expires October 8, 2005               [Page 31]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/