News Article
INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format
                        draft-ietf-usefor-article-02
                            USEFOR Working Group                  University of Manchester
                                             February 2000

                          News Article Format
                   <draft-ietf-usefor-article-03.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

     This document is an Internet-Draft.

   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.

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

     To view the entire

   The list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).

          It is hoped that this document will obsolete RFC 1036 and will
          become an Internet standard.

          This document is a successor to Henry Spencer's "Son of 1036"
          Draft, and has been referred to as "Grandson of 1036".

          Distribution of this memo is unlimited. can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This Draft defines the format of network news articles, and
          defines roles and responsibilities for humans and software.

          Network news Netnews 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 specifies
   the medium  of  communication  for  Usenet,  circa  1980.

          The term "Usenet" refers requirements to the protocols established in RFC
          1036 and successors; the be met by software implementing those protocols;
          the network of hosts exchanging traffic using that software;
          and also the traffic itself. Cooperating subnets are possible;
          these are groups of hosts which agree to hold each other originates,
   distributes, stores and
          themselves to an internally adopted set of standards concerning
          protocol details or implementations. When a cooperating subnet
          does not exchange traffic with general Usenet hosts, then it displays them. It is no longer a part of Usenet, but intended as a separate entity.
   standards track document, superseding RFC 1036, which itself dates
   from 1987.

   Since  then the 1980s, Usenet has grown explosively, and most many Internet and
   non-Internet sites participate in it. now participate. In addition, the  news this technology is
   now in widespread use for other purposes, on the Internet
          and elsewhere.

          This document is intended to provide a definitive guide to the
          article format and interpretations thereof. purposes.

   Backward compatibility is has been a major goal, but goal of this endeavour, but
   where this document standard and earlier documents or practices collide, conflict, this document
   standard should be
          used.

Table of Contents

1. Introduction

1.1 Scope and Objectives

          "Netnews" followed. In most such cases, current practice is a set
   already compatible with these changes.

[The use of protocols the words "this standard" within this document when
referring to itself do not imply that enables news "articles"
          (which resemble mail messages) this draft yet has pretensions to
be broadcast to
          potentially-large audiences, using a flooding algorithm which
          propagates copies throughout a network of participating hosts,
          typically storing only one copy per host standard, but rather indicates what will become the case if and making
when it
          available on demand to readers able to access that host.
          Articles are grouped, for convenience of access, into
          "newgroups", and the newsgroups themselves are arranged into
          "hierarchies". An important characteristic of Netnews is accepted as an RFC with the
          lack status of any requirement for a central administration proposed or for draft
standard.]
                          News Article Format              February 2000

[Remarks enclosed in square brackets and aligned with the establishment left margin,
such as this one, are not part of any controlling host to manage the
          network. A network which limits participation this draft, but are editorial notes to some
          restricted set of hosts (within some company, for example) is
          a "closed" network; otherwise it is an "open" network. A set
          of hosts within a network which, by mutual arrangement,
          operates some variant (whether more
explain matters amongst ourselves, or less restrictive) of
          the Netnews protocols is a "cooperating subnet".

          "Usenet" is a particular worldwide open network based upon the
          Netnews protocols. Anybody can join (it is simply necessary to
          negotiate an exchange of articles with one point out alternatives, or more other
          participating hosts). Usenet "belongs" to those who administer
          the hosts of which it is comprised. There is no Cabal with
          overall authority to direct what is
indicate work yet to be be allowed.
          Nevertheless, there do exist agencies within Usenet done.]

[Please note that have
          authority to establish policies and to perform administrative
          functions, but such authority derives solely from the consent
          of those sites which choose to recognise it (and who can
          decline to exchange articles with sites which choose not this Draft describes "Work in Progress". Much remains
to
          recognise it). Usually, be done, though the authority of such an agency is
          restricted to a particular hierarchy, or group of hierarchies.

          A "policy" material included so far is a rule intended unlikely to facilitate the smooth
          operation of a network by establishing parameters which
          restrict behaviour that, whilst technically unexceptionable,
          would nevertheless contravene some accepted standard of "Good
          Netkeeping". Since the ultimate beneficiaries of a network are
          its human readers, who will be less tolerant of poorly
          designed interfaces than mere computers, articles change in breach of
          established policy can cause considerable annoyance to their
          recipients.

          Policies may well vary from network to network, from hierarchy
          to hierarchy within one network, and even between individual
          newgroups within one hierarchy. It is assumed, for the
          purposes of this document, that agencies with the proper
          authority to establish such policies will exist. However, for
          the benefit
any major way.]

                           Table of networks Contents

1.  Introduction ..................................................    5
  1.1.  Basic Concepts ............................................    5
  1.2.  Objectives ................................................    6
  1.3.  Historical Outline ........................................    6
  1.4.  Transport .................................................    6
2.  Definitions, Notations and hierarchies without such agencies, Conventions ........................    7
  2.1.  Definitions.  .............................................    7
  2.2.  Textual Notations .........................................    8
  2.3.  Relation To Mail and MIME .................................    9
  2.4.  Syntax Notation ...........................................   10
  2.5.  Language ..................................................   12
3.  Changes to provide a basis upon which such agencies can build,
          this present document often provides default policy
          parameters, usually introducing them by a phrase such as "As a
          matter of policy ...".
[If we follow this route, then that phrase (or one like it, perhaps
using the word "default") can be introduced at various places in the existing text, for example when discussing the lengths of lines in
articles, when discussing the lengths of components protocols .............................   13
  3.1.  Principal Changes .........................................   13
  3.2.  Transitional Arrangements .................................   13
4.  Basic Format ..................................................   15
  4.1.  Syntax of newsgroup names, News Articles ...................................   15
  4.2.  Headers ...................................................   16
    4.2.1.  Names and when discussing Mime Content-Types, Contents ....................................   16
    4.2.2.  Header Properties .....................................   17
      4.2.2.1.  Experimental Headers ..............................   17
      4.2.2.2.  Inheritable Headers ...............................   18
      4.2.2.3.  Local Headers .....................................   18
      4.2.2.4.  Variant Headers ...................................   18
    4.2.3.  White Space and also in connection with the
Checkpolicies header, if we decide to have it.]

          The purpose of this present document is Continuations .........................   18
    4.2.4.  Comments ..............................................   19
    4.2.5.  Undesirable Headers ...................................   20
  4.3.  Body ......................................................   20
    4.3.1.  Body Format Issues ....................................   20
    4.3.2.  Body Conventions ......................................   21
  4.4.  Characters and Character Sets .............................   23
    4.4.1.  Character Sets within Article Headers .................   23
    4.4.2.  Character Sets within Article Bodies ..................   24
  4.5.  Size Limits ...............................................   24
  4.6.  Example ...................................................   25
5.  Mandatory Headers .............................................   26
  5.1.  Date ......................................................   26
    5.1.1.  Examples ..............................................   27
  5.2.  From ......................................................   27
    5.2.1.  Examples:  ............................................   27
                          News Article Format              February 2000

  5.3.  Message-ID ................................................   27
  5.4.  Subject ...................................................   28
    5.4.1.  Examples ..............................................   29
  5.5.  Newsgroups ................................................   29
    5.5.1.  Forbidden newsgroup names .............................   31
  5.6.  Path ......................................................   32
    5.6.1.  Format ................................................   32
    5.6.2.  Adding a path-identity to define the
          protocols to be used for Netnews in general, Path header .............   32
    5.6.3.  The tail-entry ........................................   34
    5.6.4.  Delimiter Summary .....................................   34
    5.6.5.  Suggested Verification Methods ........................   35
    5.6.6.  Example ...............................................   36
6.  Optional Headers ..............................................   37
  6.1.  Reply-To ..................................................   37
    6.1.1.  Examples ..............................................   37
  6.2.  Sender ....................................................   38
  6.3.  Organization ..............................................   38
  6.4.  Keywords ..................................................   38
  6.5.  Summary ...................................................   38
  6.6.  Distribution ..............................................   38
  6.7.  Followup-To ...............................................   40
  6.8.  References ................................................   40
    6.8.1.  Examples ..............................................   41
  6.9.  Expires ...................................................   41
  6.10.  Archive ..................................................   41
  6.11.  Control ..................................................   41
  6.12.  Approved .................................................   42
  6.13.  Replaces / Supersedes ....................................   42
    6.13.1.  Syntax and for Usenet in
          particular, Semantics .................................   43
    6.13.2.  Message-ID version procedure .........................   44
      6.13.2.1.  Message version numbers ..........................   44
      6.13.2.2.  Implementation and to set standards to be followed by software
          that implements those protocols.

          It is NOT Use Note ......................   46
      6.13.2.3.  The Message-Version NNTP extension ...............   47
      6.13.2.4.  Examples .........................................   48
  6.14.  Xref .....................................................   49
  6.15.  Lines ....................................................   50
  6.16.  User-Agent ...............................................   50
    6.16.1.  Examples .............................................   51
  6.17.  MIME headers .............................................   51
    6.17.1.  Syntax ...............................................   51
    6.17.2.  Content-Transfer-Encoding ............................   52
    6.17.3.  Content-Type .........................................   52
      6.17.3.1.  Message/partial ..................................   53
      6.17.3.2.  Message/rfc822 ...................................   53
      6.17.3.3.  Message/external-body ............................   54
      6.17.3.4.  Multipart types ..................................   54
    6.17.4.  Character Sets .......................................   54
    6.17.5.  Content Disposition ..................................   55
    6.17.6.  Definition of some new Content-Types .................   55
      6.17.6.1.  Application/news-transmission ....................   55
      6.17.6.2.  Message/news withdrawn ...........................   56
  6.18.  Obsolete Headers .........................................   56
7.  Control Messages ..............................................   57
  7.1.  The 'newgroup' Control Message ............................   57
                          News Article Format              February 2000

    7.1.1.  The Body of the purpose 'newgroup' Control Message ............   58
    7.1.2.  Application/news-groupinfo ............................   58
    7.1.3.  Initial Articles ......................................   60
    7.1.4.  Example ...............................................   61
  7.2.  The 'rmgroup' Control Message .............................   62
    7.2.1.  Example ...............................................   62
  7.3.  The 'mvgroup' Control Message .............................   62
    7.3.1.  Single group ..........................................   62
    7.3.2.  Multiple Groups .......................................   63
    7.3.3.  Examples ..............................................   64
  7.4.  The 'checkgroups' Control Message .........................   65
    7.4.1.  Application/news-checkgroups ..........................   66
  7.5.  Cancel ....................................................   66
  7.6.  Ihave, sendme .............................................   68
  7.7.  Obsolete control messages.  ...............................   69
8.  Duties of this document Various Agents ......................................   69
  8.1.  General principles to define how the
          authority be followed .........................   69
  8.2.  Duties of various agencies an Injecting Agent ..............................   70
    8.2.1.  Proto-articles ........................................   70
    8.2.2.  Procedure to exercise control or oversight be followed by Injecting Agents ..........   70
  8.3.  Duties of the various parts a Relaying Agent ................................   72
  8.4.  Duties of Usenet is established (that is itself a matter Serving Agent .................................   73
  8.5.  Duties of policy). Nevertheless, it a Posting Agent .................................   73
  8.6.  Duties of a Followup Agent ................................   74
  8.7.  Duties of a Gateway .......................................   74
9.  Security Considerations .......................................   74
  9.1.  Attacks ...................................................   75
10.  References ...................................................   75
11.  Acknowledgements .............................................   77
12.  Contact Addresses ............................................   77
13.  Intellectual Property Rights .................................   78
Appendix A.1 - A-News Article Format ..............................   79
Appendix A.2 - Early B-News Article Format ........................   79
Appendix B - Collected Syntax .....................................   79
                          News Article Format              February 2000

1.  Introduction

1.1.  Basic Concepts

   "Netnews" is assumed that such
          authorities will exist, and tools are provided within the
          protocols for their use.

1.2 Historical Outline

          Network news originated as the medium a set of communication protocols for
          Usenet, circa 1980.  Since then Usenet has grown explosively, generating, storing and many Internet sites participate in it.  In addition, the
   retrieving news technology "articles" (which resemble mail messages) and for
   exchanging them amongst a readership which is now 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 widespread which he participates. These protocols most
   commonly use for other purposes,
          on the Internet a flooding algorithm which propagates copies throughout
   a network of participating servers.  Typically, only one copy is
   stored per server, and elsewhere.

          The earliest news interchange used each server makes it available on demand to
   readers able to access that server.

   An important characteristic of Netnews is the so-called "A News"
          article format.  Shortly thereafter, an article format vaguely
          resembling Internet mail was devised and used briefly.  Both lack of those formats are completely obsolete; they are documented
          in appendix A any requirement
   for historical reasons only.  With publication a central administration or for the establishment of [RFC-850] in 1983, news articles came any
   controlling host to manage the network. A network which limits
   participation to closely resemble
          Internet mail messages, with some restrictions and restricted set of hosts (within some
          additional headers.  [RFC-1036] in 1987 updated [RFC-850]
          without making major changes. company,
   for example) is a "closed" network; otherwise it is an "open"
   network. A Draft popularly referred to as "Son set of 1036" [RFC-1036BIS]
          was written in 1994 hosts within a network which, by Henry Spencer. That document formed mutual
   arrangement, operates some variant (whether more or less restrictive)
   of the
          original basis for this document. Much Netnews protocols is taken directly from
          Son of 1036, and it a "cooperating subnet".

   "Usenet" is hoped that we have followed its spirit
          and intentions.

1.3 Transport

          As in this document's predecessors, a particular worldwide open network based upon the exact means used
   Netnews protocols, with the newsgroups being organised into
   recognized "hierarchies".  Anybody can join (it is simply necessary
   to
          transmit negotiate an exchange of articles from with one host or more other
   participating hosts). Usenet "belongs" to another is not specified.
          NNTP [RFC-977] is the most common transmission method on the
          Internet, but much transmission takes place entirely
          independent of the Internet. Other methods in use include the
          UUCP protocol [RFC-976] extensively used in those who administer the early days
   hosts of
          Usenet, FTP, downloading via satellite, tape archives, and
          physically delivered magnetic and optical media.

2. Definitions, Notations and Conventions

2.1 Definitions.

          An "article" which it is the unit of news, analogous to a [MAIL]
          "message".

          A "poster" comprised. There is the person or software that composes and submits
          a possibly compliant article no Cabal with overall
   authority to an injecting agent. The poster direct what is analogous to [MAIL]'s author(s).

          A "posting agent" is software be be allowed. Nevertheless, there do
   exist agencies within Usenet that assists posters have authority to prepare
          articles, including adding required headers establish
   policies and determining
          whether the final article is compliant to this standard. If perform administrative functions, but such authority
   derives solely from the article is compliant consent of those sites which choose to
   recognise it passes the article on (and who can decline to an
          injecting agent for final checking and injection into the news
          stream.  If the article is exchange articles with sites
   which choose not compliant or rejected by the
          injecting agent then the posting agent informs to recognise it). Usually, the poster with
          an explanation authority of the error.

          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 such an
   agency is restricted to a relaying agent for
          general distribution. particular hierarchy, or group of
   hierarchies.

   A "relaying agent" "policy" is software a rule intended to facilitate the smooth operation of a
   network by establishing parameters which receives allegedly
          compliant restrict behaviour that,
   whilst technically unexceptionable, would nevertheless contravene
   some accepted standard of "Good Netkeeping". Since the ultimate
   beneficiaries of a network are its human readers, who will be less
   tolerant of poorly designed interfaces than mere computers, articles
   in breach of established policy can cause considerable annoyance to
   their recipients.

   Policies may well vary from  injecting  agents and/or other
          relaying agents, and possibly passes copies on network to other
          relaying agents and serving agents.

          A "serving agent" takes an article network, from a relaying agent hierarchy to
   hierarchy within one network, and
          files it in a "news database" . even between individual newsgroups
   within one hierarchy. It also provides an interface is assumed, for reading agents to access the news database.

          A "reader" is purposes of this
   standard, that agencies with varying degrees of authority to
   establish such policies will exist, and that where they do not,
   policy will be established by mutual agreement.  For the person or software reading news articles.

          A "reading agent" is software which presents articles benefit of
                          News Article Format              February 2000

   networks and hierarchies without such established agencies, and to
   provide a
          reader.

          A "newsgroup" is a single news  forum, basis upon which all agencies can build, this present
   standard often provides default policy parameters, usually
   introducing them by a  logical  bulletin
          board,  having phrase such as "As a name matter of policy ...".

1.2.  Objectives

   The purpose of this present standard is to define the protocols to be
   used for Netnews in general, 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 Usenet in particular, and to more than
          one newsgroup, it is said set
   standards to be  "crossposted"; note followed by software that
          this differs from posting implements those protocols.

   It is NOT the same text as part of each purpose of
          several articles, one per newsgroup.  A  "hierarchy" is this standard to define how the
          set authority of all newsgroups whose names share a first component.

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

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

          A "followup agent" Usenet is established (that is itself a combination matter of reading agent, and
          posting agent policy).
   Nevertheless, it is assumed that aids in the preparation such authorities will exist, and posting of a
          followup.

          A "reply agent" is a combination
   tools are provided within the protocols for their use.

1.3.  Historical Outline

   Network news originated as the medium of reading agent communication for Usenet,
   circa 1980.  Since then, Usenet has grown explosively, and mailer
          that aids many
   Internet and non-Internet sites participate in it.  In addition, the preparation and posting of an email response
          to an article.

          A "message ID"
   news technology is a unique identifier now in widespread use for an  article, usually
          supplied by the posting agent which posted it.  It
          distinguishes the article from every other article ever posted
          anywhere.  Articles with purposes, on the same message ID are treated as
          identical copies of
   Internet and elsewhere.

   The earliest news interchange used the same so-called "A News" article even if
   format.  Shortly thereafter, an article format vaguely resembling
   Internet mail was devised and used briefly.  Both of those formats
   are completely obsolete; they are not documented in
          fact identical.

          A  "gateway"  is  software  which receives A.1 for historical
   reasons only.  With publication of [RFC 850] in 1983, news articles and
          converts them
   came to messages closely resemble Internet mail messages, with some
   restrictions and some additional headers. [RFC 1036] in 1987 updated
   [RFC 850] without making major changes.
[There should also be some mention of B News and its Appendix.
Alternatively, these appendices may go into some other kind (e.g. mail separate informational
RFC.]

   A Draft popularly referred to a
          mailing list), or vice versa; as "Son of 1036" [Son-of-1036] was
   written in essence it 1994 by Henry Spencer. That document formed the original
   basis for this standard. Much is a translating
          relaying agent that straddles boundaries between different
          methods of message exchange.  The most common type taken directly from Son of gateway
          connects newsgroup(s) to mailing list(s),  either
          unidirectionally  or  bidirectionally,  but  there are also
          gateways between news networks using this  document's  news
          format 1036, and those using other formats.

          A  "control  message"  is an article which
   it is marked as
          containing control information; a relaying or serving agent
          receiving such an article may (subject to permissions  etc.)
          take actions beyond just filing hoped that we have followed its spirit and passing on intentions.

1.4.  Transport

   As in this standard's predecessors, the article.

          An article's "reply address" exact means used to transmit
   articles from one host to another is not specified. NNTP [NNTP] is
   the address to which mailed
          replies should be sent. This is most common transmission method on the address specified Internet, but much
   transmission takes place entirely independent of the Internet. Other
   methods in use include the
          article's From header (see section 5.2), unless it also has a
          Reply-To header (see section 6.3).

2.2 Textual UUCP protocol [RFC 976] extensively used
   in the early days of Usenet, FTP, downloading via satellite, tape
   archives, and physically delivered magnetic and optical media.

                          News Article Format              February 2000

2.  Definitions, Notations

          Throughout this document, [MAIL] and Conventions

2.1.  Definitions.

   An "article" is short for "the current
          RFCs governing electronic mail formats, beginning with the
          historical [RFC-822] and continuing unit of news, analogous to its modern successors".
          "ASCII" is short for "the ANSI X3.4 character set" [ANSI-
          X3.4].  While "ASCII" a [MESSFOR] "message".
   A "proto-article" is often misused to refer to various
          character sets somewhat similar to X3.4, in this document
          "ASCII" means X3.4 and only X3.4. ASCII one that has not yet been injected into the news
   system.

   A "message identifier",) is a 7 bit character
          set. Please note that this document requires that all agents
          be 8 bit clean; that is, they must accept and transmit data
          without changing or omitting unique identifier for an article,
   usually supplied by the 8th bit.

          Certain words used to define "posting agent" which posted it or, failing
   that, by the significance of individual
          requirements are capitalized.  "MUST", "SHOULD", "MAY" and "injecting agent".  It distinguishes the article from
   every other article ever posted anywhere.  Articles with the same words followed by "NOT" should be read
   message identifier are treated as having if they are the same
          meaning as article
   regardless of any differences in [RFC-2119]. In particular, to be fully compliant
          with this document, software must satisfy every relevant
          "MUST" requirement. Software that satisfies every relevant
          "SHOULD" requirement but not every "MUST" requirement the body or headers.

   A "newsgroup" is
          partially compliant.

[However, we could step back from 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 by requiring less rigour in
observing "SHOULD" in differs from posting the case
   same text as part of "matters each of policy". Or perhaps we
could introduce an "OUGHT" category.]

          This document contains explanatory notes using the following
          format. These several articles, one per newsgroup.

   A newsgroup may be skipped by persons interested solely in
          the content of the specification.  The purpose of the notes is
          to explain why choices were made, to place them "moderated", in context, or which case submissions are not
   posted directly, but mailed to suggest a "moderator" for consideration and
   possible implementation techniques.

          NOTE: While such explanatory notes posting.  Moderators are typically human but may seem superfluous be
   implemented partially or entirely in
          principle, they often help the less-than-omniscient reader
          grasp software.

   A "hierarchy" is the purpose set of all newsgroups whose names share a first
   component (as defined in 5.5).  The term "sub-hierarchy" is also used
   where several initial components are shared.

   A "poster" is the specification person or software that composes and submits a
   possibly compliant article to a "posting agent". The poster is
   analogous to [MESSFOR]'s author(s).

   A "posting agent" is the constraints
          involved.  Given the limitations of natural language for
          descriptive purposes, this improves the probability software that
          implementors and users will understand the true intent of the
          specification in cases where the wording is not entirely
          clear.

[Remarks enclosed in square brackets, such as this one, are not part of
this document, but are editorial notes to explain matters amongst
ourselves, or to point out alternatives, or to indicate work yet assists posters to be
done.]

          All numeric values are given prepare
   proto-articles, in decimal unless otherwise
          indicated.  Octets are assumed compliance with this standard. The proto-article
   is then passed on to be unsigned values an "injecting agent" for this
          purpose.

          Throughout this document we will give examples of various
          definitions, headers final checking and other specifications. It MUST be
          remembered that these samples are for
   injection into the aid 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 reader
          only and do NOT define any specification themselves. In order error.

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

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

   A "followup" is an article containing a response to prevent possible conflict with "Real World" entities and
          people the top level domain contents of ".example"
   an earlier article (the followup's "precursor").

   A "followup agent" is used a combination of reading agent and posting
   agent that aids in all
          sample domains the preparation and addresses.  The hierarchy posting of example.* is
          also used as a sample hierarchy. Information on followup.

                          News Article Format              February 2000

   An article's "reply address" is the ".example"
          top level domain address to which mailed replies
   should be sent. This is the address specified in [TEST-TLDS].

2.3 Relation To Mail and MIME

          The primary intent of this document is to describe the news
          article format.  Insofar as news articles are article's From
   header (5.2), unless it also has a subset of
          [MAIL]'s message format augmented by some new headers, this
          document incorporates many (though not all) of the provisions
          of [MESSFOR], with the aim Reply-To header (6.1).

   A "reply agent" is a combination of enabling news articles to pass
          through mail systems reading agent and vice versa, provided only mailer that they
          contain the minimum headers required for
   aids in the mode preparation and posting of transport
          being used. Unfortunately, the match an email response to an
   article.

   A "sender" is not perfect, the person or software (usually, but it is not always, the intention of this document that gateways between [MAIL]
          and news should be able to operate with
   same as the minimum poster) responsible for the operation of
          tinkering.
[This document has been designed the posting
   agent or, which amounts to fit on top of the drafts currently
in preparation same thing, for Mail [MESSFOR]. It passing the article to
   the injecting agent. The sender is expected that those drafts will
have progressed analogous to [MESSFOR]'s sender.

   An "injecting agent" takes the RFC stage by finished article from the time posting
   agent (often via the present document in
complete, at NNTP "post" command) performs some final checks
   and passes it on to a relaying agent for general distribution.

   A "relaying agent" is software which time all references receives allegedly compliant
   articles from injecting agents and/or other relaying agents, and
   possibly passes copies on to [MESSFOR] in other relaying agents and serving
   agents.

   A "news database" is the present text
will be replaced set of articles and related strutural
   information stored by references to that RFC.]

          Likewise, this document incorporates many (though not all) of
          the provisions of the MIME standards [RFC-2045 et seq] which,
          though designed with [MAIL] a serving agent and made available for access
   by reading agents.

   A "serving agent" receives an article from a relaying agent and files
   it in mind, are mostly applicable a news database. It also provides an interface for reading
   agents to
          news.

2.4 Syntax Notation

          This document uses access the Augmented Backus Naur Form described in
          [RFC-2234]. news database.

   A discussion of this "control message" is outside the bounds of
          this document, but it an article which is expected that implementors will be
          able to quickly understand it with reference marked as containing
   control information; a relaying or serving agent receiving such an
   article may (subject to the defining
          document.

          Much of the syntax in this document is incorporated directly
          from policies observed at that given in [MESSFOR] or in the Mime specifications
          [RFC-2045 et seq], but with appropriate modifications to
          permit site) take
   actions beyond just filing and passing on the use of full 8bit characters, article.

   A "gateway" is software which receives news articles and converts
   them to remove those
          parts messages of the syntax given some other kind (e.g. mail to a mailing list), or
   vice versa; in [MESSFOR] essence it is a translating relaying agent that are regarded as
          "obsolete". Full details
   straddles boundaries between different methods of this are explained in section 4.1.
[Alternatively, we could move some parts message exchange.
   The most common type of 4.1 forward gateway connects newsgroup(s) to here.]

          NOTE:  News parsers historically have been much less
          permissive than [MAIL] parsers, and this is reflected in the
          modifications referred to, and in some further specific rules.

          NOTE: Following [RFC-2234], literal text included in mailing
   list(s), either unidirectionally or bidirectionally, but there are
   also gateways between news networks using this standard's news format
   and those using other formats.

2.2.  Textual Notations

   This standard contains explanatory NOTEs using the
          syntax is to following format.
   These may be regarded as case-insensitive. However, skipped by persons interested solely in
          contradistinction to [MAIL], the NetNews protocols are
          sensitive content of
   the specification.  The purpose of the notes is to case in some instances (as in newsgroup names,
          some header parameters, etc.). Care has been taken explain why
   choices were made, to indicate
          this explicitly where required.

2.5 Language

          Various constant strings in this document, such as header names
          and  month  names,  are derived from English words.  Despite
          their derivation, these words do NOT change when the  poster
          or  reader employing place them is interacting in a language other
          than English.  Posting and reading agents  MAY translate
          as  appropriate in  their  interaction  with  the poster context, or
          reader, but the forms that actually appear to suggest possible
   implementation techniques.

                          News Article Format              February 2000

        NOTE: While such explanatory notes may seem superfluous in  articles
          MUST be
        principle, they often help the English-derived ones defined in this document.

3. Changes to less-than-omniscient reader grasp
        the existing protocols

          This document prescribes many changes, clarifications and new
          features since purpose of the protocols described in [RFC-1036] specification and
          [RFC-1036BIS]. It is the intention constraints involved.
        Given the limitations of natural language for descriptive
        purposes, this improves the probability that they can be
          assimilated into Usenet as it presently operates without major
          interruption to implementors and
        users will understand the service, though some true intent of the new features
          may not begin to show benefit until they become widely
          implemented. This sections summarizes the main changes, and
          comments on some features of specification in
        cases where the transition.

3.1 Principal Changes

            o The [MAIL] conventions wording is not entirely clear.

   "ASCII" is short for parenthesis-enclosed comments
              in headers are supported.
            o Whitespace "the ANSI X3.4 character set" [ANSI X3.4].
   While "ASCII" is permitted often misused to refer to various character sets
   somewhat similar to X3.4, in Newsgroups headers, permitting
              folding of such headers. Indeed, this standard "ASCII" means X3.4 and
   only X3.4. ASCII is a 7 bit character set. Please note that this
   standard requires that all news headers can now agents be folded.
            o An enhanced syntax for 8 bit clean; that is, they must
   accept and transmit data without changing or omitting the Path header enables 8th bit.

   Certain words, when capitalized, are used to define the
              injection point significance
   of individual requirements. The key words "MUST", "SHOULD", "MAY" and
   the route taken same words followed by an article "NOT" are to be
              determined with certainty.
            o Netnews is firmly established as an 8bit medium.
            o Large parts of MIME are recognized interpreted as an integral part of
              Netnews.
            o described
   in [RFC 2119].

        NOTE: The charset for headers is use of "MUST" always UTF-8. This will, inter
              alia, permit newsgroup-names with non-ASCII characters.
            o There is implies a new Control command 'mvgroup' requirement that would
        lead to facilitate
              group renaming.
            o There are several new headers defined, such as Replaces
              and Author-Ids, leading interoperability problems if not followed, but the word
        "SHOULD", especially when it is applied to increased functionality.
            o There are numerous other small changes, clarifications actions of posting
        and
              enhancements.
[Doubtless many other changes should be listed, but there is little
point in doing so until our text is nearing completion. The above gives similar agents which the flavour individual poster may easily
        override, is often used where a violation would do no more than
        breach established policy, or accepted standards of what should be said.]

3.2 Transitional Arrangements

          An important distinction must be made between serving and "Good
        Netkeeping". Moreover, even a "MUST" requirement imposed on a
        relaying agents which are responsible or serving agent applies only to articles actually
        processed by that agent (since such an agent may always reject
        any article entirely for the distribution and
          storage reasons of news articles, and user agents which site policy).

   All numeric values are
          responsible for interactions with users. It is important that
          the former should be upgraded to conform given in decimal unless otherwise indicated.
   Octets are assumed to be unsigned values for this document as
          soon as possible purpose.

   Throughout this standard we will give examples of various
   definitions, headers and other specifications. It needs to provide be be
   remembered that these samples are for the benefit aid of the enhanced
          facilities.  Fortunately, reader only and
   do NOT define any specification themselves.  In order to prevent
   possible conflict with "Real World" entities and people the number top level
   domain of distinct
          implementations ".example" is used in all sample domains and addresses.
   The hierarchy of such agents example.* is rather small, at least so
          far also used as a sample hierarchy.
   Information on the main "backbone" of Usenet ".example" top level domain is concerned, in [RFC 2606].

2.3.  Relation To Mail and many MIME

   The primary intent of this standard is to describe the new features are already supported. Contrariwise, there news article
   format.  Insofar as news articles are a great number of implementations of user agents,
          installed on a vastly greater number subset of small sites.
          Therefore, the Mail message
   format augmented by some new functionality has been designed so that
          existing agents may continue to be used, although the full
          benefits may headers, this standard incorporates many
   (though not be realised until a substantial proportion all) of
          them have been upgraded.

          In the list which follows, care has been taken to distinguish provisions of [MESSFOR], with the implications for both kinds aim of agent.

            o [MAIL] style comments in headers do not affect serving
   enabling news articles to pass through mail systems and
              relaying agents (note vice versa,
   provided only that they contain the Newsgroups and Path minimum headers
              do not contain them). They are unlikely to hinder their
              proper display in existing user agents except in required for the case
   mode of transport being used. Unfortunately, the References header in agents which thread articles.
              Therefore, match is not
   perfect, but it is provided the intention of this standard that they SHOULD NOT gateways
   between Mail and News should be
              generated except where permitted by able to operate with the previous
              standards.
            o Because minimum of its importance
                          News Article Format              February 2000

   tinkering.
[This standard has been designed to all serving agents, fit on top of the
              extension permitting whitespace and folding drafts currently
in Newsgroup
              headers SHOULD NOT be used unless the user preparation for Mail [MESSFOR].  It is willing expected that those drafts
will have progressed to
              take the risk of misprocessed articles. It is believed most
              existing implementations handle correctly, but this is not
              certain. User agents are unaffected.
            o The new style of Path header is already consistent with
              the previous standards. However, the intention is that
              relaying agents should henceforth reject articles in RFC stage by the
              old style, and so this should be offered as a configurable
              option for relaying agents. User agents are unaffected.
            o The vast majority of serving, relaying and transport
              agents are believed to be already 8bit clean (in time the
              slightly restricted sense present standard
in complete, at which that term is used time all references to [MESSFOR] in the MIME standards). User agents present
text will be replaced by references to that do RFC.]

   Likewise, this standard incorporates many (though not implement
              MIME may be disadvantaged, but no more so than at present
              when faced with 8bit characters (which currently abound in
              spite all) of the previous standards).
            o The introduction
   provisions of MIME reflects a practice that is
              already widespread.  Articles in strict compliance with the previous MIME standards (using strict ASCII) will be
              unaffected. Many user agents already support it, at least [RFC 2045] et seq which, though
   designed with Mail in mind, are mostly applicable to News.

2.4.  Syntax Notation

   This standard uses the extent Augmented Backus Naur Form described in [RFC
   2234].  A discussion of widely used charsets such as ISO8859-1.
              Users expecting to read articles using this is outside the more exotic
              charsets will need to acquire suitable reading agents. It bounds of this standard,
   but it is not intended, in general, expected that any single user agent implementors will be able to display every charset known quickly
   understand it with reference to IANA, but
              all such agents MUST support ASCII. Serving and relaying
              agents are not affected.
            o The use of the UTF-8 charset for headers will not affect
              any existing usage, since ASCII is a strict subset of
              UTF-8. Insofar as newsgroup names containing non-ASCII
              characters can now be expected to arise, support from
              serving and relaying agents will be necessary. It is
              believed that the customary storage structure used by
              serving agents can already cope (perhaps not ideally) with
              such names. Note that it is not necessary for serving and
              relaying agents to understand all the characters available
              in UTF-8, though it is desirable for them to be
              displayable for diagnostic purposes via some escape
              mechanism using, for example, the visible subset of ASCII.
              For users expecting to use the more exotic charsets
              available under UTF-8, the remarks already made in
              connection with MIME will apply.
            o The new Control: mvgroup command will need to be
              implemented in serving agents. It SHOULD be used in
              conjunction with pairs of matching rmgroup and newgroup
              commands (injected shortly after the mvgroup) until such
              time as mvgroup is widely implemented. The new Replaces
              header is also effectively a Control command, and
              transitional arrangements are provided which should be
              used in the meantime. User agents are unaffected.
            o The headers newly introduced by this document can safely
              be ignored by existing software, albeit with loss of the
              new functionality.

4. Basic Format

4.1 Overall Syntax defining document.

   Much of the syntax of News Articles is based on the corresponding
   syntax defined by [MESSFOR], in [MESSFOR] or in the Mime specifications [RFC 2045]
   et seq, which is deemed to have been incorporated into this standard
   as required.  However, there are some important differences arising
   from the fact that [MESSFOR] does not recognise anything other than
   US-ASCII characters, that it does not recognise the MIME headers [RFC2045], [RFC
   2045], and that it includes much syntax described as "obsolete".

          The following syntactic forms supersede the corresponding
          rules given in [MESSFOR]

        NOTE:  News parsers historically have been much less permissive
        than Mail parsers, and [RFC2045]: this is reflected in the modifications
        referred to, and in some further specific rules.

   The following syntactic forms therefore supersede the corresponding
   rules given in [MESSFOR] and [RFC 2045], thus allowing UTF-8
   characters [RFC 2044] to appear in certain contexts (the four rules
   begining with "strict-" reflect the corresponding original rules from
   [MESSFOR]).

      UTF8-xtra-head  = %d192-253
      UTF8-xtra-tail  = %d128-191
      UTF8-xtra-char  = UTF8-xtra-head 1*UTF8-xtra-tail
      text            = %d1-9 /            ; all octets UTF-8 characters except
                        %d11-12 /          ; US-ASCII NUL, CR and LF
                            %d14-255
                        %d14-127 /
                        UTF8-xtra-char
      ctext           = NO-WS-CTL /        ; all of <text> except
                        %d33-39 /          ; SP, HTAB, "(", ")"
                        %d42-91 /          ; and "\"
                            %d93-255
                        %d93-126 /
                        UTF8-xtra-char
      qtext           = NO-WS-CTL /        ; all of <text> except
                        %d33 /             ; SP, HTAB, "\" and <"> DQUOTE
                        %d35-91 /
                            %d93-255
          ftext
                        %d93-126 /
                        UTF8-xtra-char
                          News Article Format              February 2000

      utext           = %d33-57 NO-WS-CTL /        ; all octets except
                            %d59-126 Non white space controls
                        %d33-126 /         ; CTL, SP and ":"
                            %d128-255
          token           = 1*<any ftext except tspecials>
          tspecials The rest of US-ASCII
                        UTF8-xtra-char
      strict-text     = "(" / ")" / "<" / ">" / "@"
                            "," / ";" %d1-9 / ":"            ; text restricted to
                        %d11-12 / "
                            "/"          ; US-ASCII
                        %d14-127
      strict-qtext    = NO-WS-CTL / "["        ; qtext restricted to
                        %d33 / "]"             ; US-ASCII
                        %d35-91 / "?"
                        %d93-127
      strict-quoted-pair
                      = "\" strict-text
      strict-quoted-string
                      = [CFWS] DQUOTE
                           *([FWS] (strict-qtext / "=" strict-quoted-pair))
                           [FWS] DQUOTE [CFWS]

        NOTE: There are sequences of octets which cannot legitimately
        occur in UTF-8, even a few permitted by the above syntax.  These
        SHOULD NOT be generated by posting agents but, where they occur
        inadavertently, they SHOULD be passed on untouched by other
        agents.

   Wherever in this standard the syntax is stated to be taken from
   [MESSFOR], it is to be understood as the syntax defined by [MESSFOR]
   after making the above changes, but NOT including any syntax defined
   in section 4 ("Obsolete syntax") of [MESSFOR].  Software compliant
   with this standard MUST NOT generate any of the syntactic forms
   defined in that Obsolete Syntax, although it MAY accept such
   syntactic forms. Certain syntax from the MIME specifications [RFC2045 [RFC
   2045] et seq] seq is also considered a part of this Standard standard (see ...). 6.17).

   The following syntactic forms, taken from [RFC2234] [RFC 2234] or from
   [MESSFOR], are repeated here for convenience only:

      ALPHA           = %x41-5A /          ; A-Z
                        %x61-7A            ; a-z
      CR              = %x0D               ; carriage return
      CRLF            = CR LF
      DIGIT           = %x30-39            ; 0-9
      HTAB            = %x09               ; horizontal tab
      LF              = %x0A               ; line feed
      SP              = %x20               ; space
      NO-WS-CTL       = %d1-8 /            ; US-ASCII control characters
                        %d11 /             ; which do not include the
                        %d12 /             ; carriage return, line feed,
                            %d14-41
                        %d14-31 /          ; and whitespace characters
                        %d127
      WSP             = SP / HTAB          ; Whitespace characters
      FWS             = ([*WSP CRLF] 1*WSP)   ; 1*WSP); Folding whitespace
                          News Article Format              February 2000

      atext           = ALPHA / DIGIT /
                        "!" / "#" /        ; Any character except
                        "$" / "%" /        ; controls SP, and specials.
                        "&" / "'" /        ; Used for atoms
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "}" /
                        "|" / "}" /
                        "~"
      atom            = [CFWS] 1*atext [CFWS]
      dot-atom        = [CFWS] dot-atom-text [CFWS]
      dot-atom-text   = 1*atext *( "." 1*atext )
      comment         = "(" *([FWS]
                           (ctext / quoted-pair / comment)) [FWS] ")"
      CFWS            = *([FWS] comment) (([FWS] comment) / FWS )
          <">
      DQUOTE          = %d34              ; quote mark
      quoted-pair     = "\" text
      quoted-string   = *CFWS <"> *(FWS [CFWS] DQUOTE
                           *([FWS] (qtext / quoted-pair)) <"> *CFWS
                           [FWS] DQUOTE [CFWS]
      unstructured    = *( [FWS] text utext )

4.2. Syntax of News Articles

          The overall [FWS]

        NOTE: CFWS occurs at many places in the syntax of a news article is:

          article         = 1*header separator body
          header          = header-name ":" SP header-content CRLF
          header-name     = 1*name-character *( "-" 1*name-character )
          name-character  = ALPHA / DIGIT
          header-content  = usenet-header-content / unstructured
          usenet-header-content
               = <a header-content specifically defined in this standard>
          separator       = CRLF
          body            = *( *998text CRLF )
          nonblank-text   = 1*( [FWS] nbtext )
          nbtext          = qtext /           ; all of <text> except
                            "\" / <">         ; SP and HTAB

          An article consists of some headers followed by a body. An
          empty line separates the two. The headers contain structured
          information about the article and its transmission. A header
          begins with a header-name identifying it, order to allow
        comments and can extra whitespace to be continued
          onto subsequent lines as described in section 4.3.2. inserted almost anywhere.
        The body syntax is largely unstructured text significant only in fact ambiguous insofar as it may be impossible
        to the poster
          and the readers.

          NOTE: Terminology here follows the current custom tell in the news
          community, rather than the [MESSFOR] convention which of referring
          to what is here called a "header" as several possible ways a "header-field" given comment or
          "field".

          Note that the separator line must be truly empty, WS
        was produced. However, this does not just lead to semantic ambiguity
        because, unless specifically stated otherwise, the presence of
        absence of a
          line containing white space. Further empty lines following comment or additional WS has no semantic meaning
        and, in particular, it
          are is a matter of indifference whether it
        forms a part of the body, as are empty lines at the end of syntactic construct preceding it or the
          article. one
        following it.

        NOTE: The syntax above defines Following [RFC 2234], literal text included in the canonical form of a news article syntax
        is to be regarded as a
sequence of lines each terminated by CRLF. This does not prevent serving
agents or transport agents from storing or handling the article in other
formats (e.g. using a single LF case-insensitive.  However, in place of CRLF) so long as
        contradistinction to [MESSFOR], the overall
effects achieved Netnews protocols are as defined by
        sensitive to case in some instances (as in newsgroup names, some
        header parameters, etc.). Care has been taken to indicate this document when operating on the
canonical form.

4.3. Headers

4.3.1. Names
        explicitly where required.

2.5.  Language

   Various constant strings in this standard, such as header names and Contents
   month  names,  are derived from English words.  Despite their
   derivation, these words do NOT change when the restrictions on header-name syntax imposed by the
          grammar, relayers  poster or  reader
   employing them is interacting in a language other than English.
   Posting and reading agents SHOULD tolerate header
          names containing any ASCII printable character other than
          colon (":", ASCII 58).  [That brings it into line with
          <optional-field>  MAY translate as given in [MESSFOR].]

          Header-names SHOULD be either those defined  appropriate  in this standard,  their
   interaction  with  the poster or those defined reader, but the forms that actually
   appear in [MESSFOR], or those  articles MUST be the English-derived ones defined in any
          extension to either of these standards, or other names
          beginning with "X-".  Software SHOULD NOT attempt to interpret
          headers not described in this
   standard.

                          News Article Format              February 2000

3.  Changes to the existing protocols

   This standard or prescribes many changes, clarifications and new
   features since the protocols described in its extensions.
          Relaying agents MUST pass them on unaltered [RFC 1036] and reading agents
          MUST enable them to [Son-of-
   1036].  It is the intention that they can be displayed, at least optionally.

          Posters wishing assimilated into Usenet
   as it presently operates without major interruption to convey non-standard information in headers
          SHOULD use header-names beginning with "X-". No standard
          header name will ever be of this form. Reading agents SHOULD
          ignore "X-" headers, or at least treat them with great care.

          The order the service,
   though some of headers in an article is the new features may not significant.
          However, posting agents are encouraged begin to put mandatory
          headers (see section 5) first, followed by optional headers
          (see show benefit until
   they become widely implemented. This section 6), followed by "X-" headers and headers not
          defined in this standard or its extensions. Relaying agents
          MUST NOT change summarizes the order main
   changes, and comments on some features of the headers transition.

3.1.  Principal Changes

     o The [MESSFOR] conventions for parenthesis-enclosed comments in an article.

          Header-names
       headers are case-insensitive. There supported.
     o Whitespace is a preferred case
          convention, which posters and posting agents SHOULD use:
          each hyphen-separated "word" has its initial letter (if any)
          in uppercase and the rest permitted in lowercase, except that some
          abbreviations have Newsgroups headers, permitting folding
       of such headers. Indeed, all letters uppercase (e.g. "Message-ID"
          and "MIME-Version"). The forms used in this standard are the
          preferred forms news headers can now be folded.
     o An enhanced syntax for the headers described herein. Relaying and
          reading agents MUST, however, tolerate articles not obeying
          this convention.

[I thought we were doing away with Path header classes, except to
discuss eXperimental. Consensus, please?]

4.3.2 Header Classes

          There are four special classes enables the injection
       point of headers that may be present
          in an article:  Experimental, Persistent, Comment, and
          Variant.  All other headers are ephemeral.  These classes are
          significant in how newsreaders and servers should treat them
          when encountered.

4.3.3 Experimental Headers

          Experimental headers are headers which begin with "X-".  They
          are to be used the route taken by newsreaders proposing new headers for some
          utility or for comments an article to be propogated determined with the article.
          There are no established headers that are considered
          experimental headers; an
       certainty.
     o Netnews is firmly established header cannot be
          experimental.

          Attempts to create new headers that are to be adopted as
          standard headers MUST begin their lives as experimental
          headers.

4.3.4 Persistent Headers

          Persistent headers an 8bit medium.
     o Large parts of MIME are headers which begin with "P-" (or
          "X-P-", hereafter referred to simply recognised as "P- headers") which
          persist across followups either identically or by simple
          modification.  Headers with this behavior include:

          Newsgroups
          Content is carried over into all followups. Modified by
          content an integral part of Followup-To header.

          Subject
          Content
       Netnews.
     o The charset for headers is carried over into all followups. Modified by
          prefixing with "Re: " if not already present. Also modified by
          user, often always UTF-8. This will, inter alia,
       permit newsgroup-names with a "(was: )" phrase preserving the previous
          content.

          References
          Content non-ASCII characters.
     o There is carried over into all followups. Modified by
          appending content of Message-ID header.

          NOTE: Though traditionally old newsreaders would treat
          Keywords as a persistent header, it is not new Control command 'mvgroup' to facilitate moving a persistent
          header.  More modern newsreaders do not treat it as such.

4.3.5. Variant Headers

          Variant Headers are headers that are modified on articles when
          they are propogated.  Variant headers have
       group to a "V-" prefix.
          Variant headers may be experimental ("X-V-"), persistent
          ("P-V-"), or both ("X-P-V-").

4.3.6. Header Classes different place (name) in a hierarchy.
     o There are four special classes of several new headers that may be present
          in an article:  Experimental, Persistent, Comment, defined, such as Replaces and
          Variant.  All other headers are ephemeral.  These classes
       Author-Ids, leading to increased functionality.
     o There are
          significant in how newsreaders numerous other small changes, clarifications and servers
       enhancements.
[Doubtless many other changes should treat them
          when encountered.

4.3.6.1 Experimental Headers

          Experimental headers are headers be listed, but there is little
point in doing so until our text is nearing completion. The above gives
the flavour of what should be said.]

3.2.  Transitional Arrangements

   An important distinction must be made between serving and relaying
   agents which begin with "X-".  They are to be used by newsreaders proposing new headers for some
          utility or responsible for comments to be propogated with the article.
          There distribution and storage of news
   articles, and user agents which are no established headers responsible for interactions with
   users. It is important that are considered
          experimental headers; an established header cannot the former should be
          experimental.

          Attempts upgraded to create new headers that are conform
   to be adopted as this standard headers MUST begin their lives as experimental
          headers.

4.3.6.2 Persistent Headers

          Persistent headers are headers which begin with "P-" (or
          "X-P-", hereafter referred to simply soon as "P- headers") which
          persist across followups either identically or by simple
          modification. Headers with this behavior include:

          Newsgroups

          Content is carried over into all followups. Modified by
          content possible to provide the benefit of Followup-To header.

          Subject

          Content the
   enhanced facilities.  Fortunately, the number of distinct
   implementations of such agents is carried over into all followups. Modified by
          prefixing with "Re: " if not already present. Also modified by
          user, often with a "(was: )" phrase preserving rather small, at least so far as
   the previous
          content.

          References

          Content main "backbone" of Usenet is carried over into all followups. Modified by
          appending content concerned, and many of Message-ID header.

          NOTE: Though traditionally old newsreaders would treat
          Keywords as the new
   features are already supported. Contrariwise, there are a persistent header, it is great
   number of implementations of user agents, installed on a vastly
   greater number of small sites. Therefore, the new functionality has
   been designed so that existing agents may continue to be used,
   although the full benefits may not be realised until a persistent
          header.  More modern newsreaders substantial
   proportion of them have been upgraded.

   In the list which follows, care has been taken to distinguish the
   implications for both kinds of agent.

                          News Article Format              February 2000

     o [MESSFOR] style comments in headers do not treat it as such.

4.3.6.3 Examples

Newsgroups: alt.test
Subject: Persistent Header Example
Message-ID: <001@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique>
User-Agent: experimental/0.1g (P-Author-ID Compliant)

From: jane@site.invalid (Jane Smith)
Newsgroups: alt.test
Followup-To: misc.test
Subject: Re: Persistent Header Example
Message-ID: <002@news.site.example>
References: <001@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique>
User-Agent: modern/1.2 (Author-ID non-Compliant; P- header compliant)
Keywords: persistance, good ideas

From: andrew@isp.invalid
Newsgroups: misc.test
Subject: Further example (was: Re: Persistent Header Example)
Message-ID: <001@news.isp.example>
References: <001@news.site.example> <002@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique> <andrew@isp.example>
User-Agent: codeveloper/2.0b (Author-ID Compliant)

4.3.6.4 Comment Headers

          Comment headers are headers affect serving and
       relaying agents (note that are strictly local the Newsgroups and MUST
          NOT be propogated outside of a restricted subnet for local
          testing purposes.  Comment Path headers have a prefix of "C-".  Due do not
       contain them). They are unlikely to hinder their limited scope, proper display
       in existing user agents except in the case of the References
       header in agents which thread articles. Therefore, it is provided
       that they MUST SHOULD NOT be combined with any
          other prefix, such as "X-C-" headers.  Headers with this
          behavior include:

          Xref

          Used generated except where permitted by servers to keep track the
       previous standards.
     o Because of crossposted articles' article
          numbers in its importance to all serving agents, the crossposted-to news groups extension
       permitting whitespace and folding in the local news
          spool as an aid to newsreaders marking such articles as read.

4.3.6.5. Variant Headers

          Variant Headers are Newsgroup headers that are modified on articles when
          they are propogated.  Variant headers have a "V-" prefix.
          Variant headers may SHOULD NOT
       be experimental ("X-V-"), persistent
          ("P-V-"), or both ("X-P-V-").

4.3.7. White Space and Continuations

          [The following text is taken from [MESSFOR], adapted to the
          different terminology used for this standard.]

          Each until it has been widely deployed amongst relaying
       agents. User agents are unaffected.
     o The new style of Path header is logically a single line of characters
          comprising the header-name, the colon already consistent with its following
          SP, and the header-content. For convenience, however,
       previous standards. However, the
          header-content can be split into a multiple line
          representation; this is called "folding". The general rule intention is that wherever relaying
       agents should henceforth reject articles in the old style, and so
       this standard allows should be offered as a configurable option for FWS (which includes
          CFWS, but not simply SP or HTAB) relaying
       agents. User agents are unaffected.
[Should that "should" be a CRLF followed by AT
          LEAST one SP "SHOULD" or HTAB may instead be inserted.  For example,
          the header:

          Approved: modname@modsite.com(Acting Moderator of
          comp.foo.bar)

          can be represented as:

          Approved: modname@modsite.com
               (Acting Moderator a "MAY".]

     o The vast majority of comp.foo.bar)

          NOTE: Though header-contents serving, relaying and transport agents are defined
       believed to be already 8bit clean (in the slightly restricted
       sense in such a way which that
          folding can take place between many of term is used in the lexical tokens,
          folding SHOULD MIME standards). User
       agents that do not implement MIME may be limited to placing the CRLF disadvantaged, but no
       more so than at higher-level
          syntactic breaks. For instance, if present when faced with 8bit characters (which
       currently abound in spite of the previous standards).
     o The introduction of MIME reflects a header-content practice that is defined
          as comma-separated values, it is recommended that folding
          occur after already
       widespread.  Articles in strict compliance with the comma separating previous
       standards (using strict US-ASCII) will be unaffected. Many user
       agents already support it, at least to the structured items, even if
          it extent of widely used
       charsets such as ISO-8859-1. Users expecting to read articles
       using the more exotic charsets will need to acquire suitable
       reading agents. It is allowed elsewhere.

          Folding MUST NOT be carried out not intended, in such a way general, that any line of
          a header is made up entirely of WSP characters and nothing
          else.  [That is taken from a rather unsatisfactory line in
          section 3.2.4 of [MESSFOR] (which seems single
       user agent will be able to allow WSP-only
          lines display every charset known to arise from FWS IANA,
       but all such agents MUST support US-ASCII. Serving and relaying
       agents are not from CFWS). affected.
     o The situation
          could arise where two FWS or CFWS could be adjacent, according
          to use of the syntax (I believe this is possible in [MESSFOR], which
          goes to show how sloppy their syntax is), or where FWS or CFWS UTF-8 charset for headers will not affect any
       existing usage, since US-ASCII is allowed at the end of a line.]

          The colon following the header name on the start-line MUST strict subset of UTF-8.
       Insofar as newsgroup names containing non-ASCII characters can
       now be
          followed by white space, even if the header expected to arise, support from serving and relaying
       agents will be necessary. It is empty. If believed that the
          header customary
       storage structure used by serving agents can already cope
       (perhaps not ideally) with such names. Note that it is not empty, at least some of the content MUST appear
          on the start-line. Posting agents MUST enforce these
          restrictions, but relaying agents SHOULD accept even articles
          that violate them.

          Posters
       necessary for serving and posting relaying agents SHOULD use SP, not HTAB, where
          white space is desired in headers (some existing software
          expects this), and MUST use SP immediately following to understand all the
          colon after a header-name (this was an RFC 1036 requirement).
          Relaying agents SHOULD accept HTAB
       characters available in all such cases, however.

          Since UTF-8, though it is desirable for them to
       be displayable for diagnostic purposes via some escape mechanism
       using, for example, the white space beginning a continuation line remains a
          part visible subset of US-ASCII. For users
       expecting to use the logical line, headers can more exotic charsets available under UTF-8,
       the remarks already made in connection with MIME will apply.
     o The new Control: mvgroup command will need to be "broken" into
          multiple lines only at FWS or CFWS. Posting agents implemented in
       serving agents. It SHOULD not
          break headers unnecessarily (but see section 4.6).

4.3.8 Comments

          Strings of characters which are treated as comments may be
          included used in header contents wherever the syntactic element
          CFWS occurs. They consist conjunction with pairs of characters enclosed in
          parentheses. Such strings are considered comments so long
       matching rmgroup and newgroup commands (injected shortly after
       the mvgroup) until such time as
          they do not appear within mvgroup is widely implemented.
       The new Replaces header is also effectively a quoted-string. Comments may Control command,
       and transitional arrangements are provided which should be
          nested.

          A comment is normally used to provide some human readable
          informational text, except at
       in the end of an <address> which
          contains no <phrase>, as in

               fred@foo.bar.com (Fred Bloggs)

          as opposed to

               "Fred Bloggs" <fred@foo.bar.com>

          The former is a deprecated, but commonly encountered, usage
          and reading meantime. User agents SHOULD take special note are unaffected.

                          News Article Format              February 2000

     o The headers newly introduced by this standard can safely be
       ignored by existing software, albeit with loss of such comments
          as indicating the name new
       functionality.

4.  Basic Format

4.1.  Syntax of News Articles

   The overall syntax of the person whose <address> it is. In
          all other situations a comment is semantically interpreted as
          a single SP. Since a comment is allowed to contain FWS,
          folding is permitted within it as well as immediately
          preceding and immediately following it. Also note that, since
          quoted-pair is allowed news article is:

      article           = 1*header separator body
      header            = header-name ":" 1*SP header-content CRLF
      header-name       = 1*name-character *( "-" 1*name-character )
      name-character    = ALPHA / DIGIT
      header-content    = USENET-header-content
                               *( ";" header-parameter ) /
                          other-header-content
      USENET-header-content
                        = <the header-content defined in this standard
                           (or an extension of it) for a comment, the parenthesis and
          backslash characters may appear specific
                           USENET header>
      other-header-content
                        = <a header-content defined (explicitly or
                           implicitly) by some other standard>
      header-parameter  = USENET-header-parameter /
                          other-header-parameter
      USENET-header-parameter
                        = <an other-header-parameter defined in
                           this standard for use in conjunction with
                           a comment so long as they
          appear as a quoted-pair. Semantically, the enclosing
          parentheses are not part of the comment token; the specific USENET-header-content>
      other-header-parameter
                        = attribute "=" value
      attribute         = USENET-token / iana-token / x-token
      value             = token is
          what is contained between the two parentheses.

          Since comments have not hitherto been permitted / quoted-string
      USENET-token      = <A token defined in news
          articles, except this standard for
                           use in conjunction with a few specified places, posters and
          posting-agents SHOULD NOT insert them except in those places.
          However, compliant software MUST accept them specific
                           USENET-header-parameter>
      iana-token        = <A token defined in all places
          where they are syntactically allowed.

4.3.9. Undesirable Headers

          A header whose content is empty is said to be an empty header.
          Relaying experimental
                           or standards-track RFC and reading agents SHOULD NOT consider presence registered with
                           IANA>
      x-token           = [CFWS] <the two characters "X-" or
          absence "x-"
                           followed, with no intervening white space,
                           by any token>
      token             = [CFWS] 1*<any (US-ASCII) CHAR except SP,
                                    CTLs or tspecials> [CFWS]
      tspecials         = "(" / ")" / "<" / ">" / "@" /
                          "," / ";" / ":" / "\" / DQUOTE /
                          "/" / "[" / "]" / "?" / "="
      separator         = CRLF
      body              = *( *998text CRLF )

   An article consists of an some headers followed by a body. An empty header to alter line
   separates the two. The headers contain structured information about
   the semantics of an article (although syntactic rules, such as requirements that
          certain header names appear at most once in an article, MUST
          still be satisfied). Posting and injecting agents SHOULD
          delete empty headers from articles before posting them;
          relaying agents MUST pass them untouched.

          Headers that merely state defaults explicitly (e.g., a
          Followup-To its transmission. A header begins with the same content as the Newsgroups
          header, or a MIME Content-Type header with contents
          "text/plain; charset=us-ascii") or state information that
          reading agents header-name
                          News Article Format              February 2000

   identifying it, and can typically determine easily themselves (e.g.
          the length of the body be continued onto subsequent lines as
   described in octets) are redundant and posters
          and posting agents SHOULD NOT include them.

4.4. Body

4.4.1. Body Format Issues section 4.2.3.  The body of an article MAY be empty, although posting agents
          SHOULD consider this an error condition (meriting returning
          the article to the poster for revision). A posting or
          injecting agent which does not reject such an article SHOULD
          issue a warning message is largely unstructured text
   significant only to the poster and supply the readers.

        NOTE: Terminology here follows the current custom in the news
        community, rather than the [MESSFOR] convention of referring to
        what is here called a non-empty
          body. "header" as a "header-field" or "field".

   Note that the separator line MUST must be present even if truly empty, not just a line
   containing white space. Further empty lines following it are part of
   the
          body is empty.

          NOTE: Some existing news software is known to react badly to
          body-less articles, hence body, as are empty lines at the request for posting and
          injecting agents to insert a body in such cases. end of the article.

        NOTE: The sentence
          "This article was probably generated by syntax above defines the canonical form of a buggy news reader"
          has traditionally been used is this situation.

          Note that an
        article body is as a sequence of lines each terminated by
          CRLFs, not arbitrary binary data, and in particular it MUST
          end with a CRLF. However, relaying This
        does not prevent serving agents SHOULD treat or transport agents from storing
        or handling the
          body of an article as an uninterpreted sequence in other formats (e.g. using a single LF
        in place of octets
          (except CRLF) so long as mandated the overall effects achieved are as
        defined by changes of CRLF representation this standard when operating on the canonical form.

4.2.  Headers

4.2.1.  Names and Contents

   Despite the restrictions on header-name syntax imposed by
          control-message processing) the
   grammar, relayers and SHOULD avoid imposing
          constraints on it. See also section 4.6.

4.4.2. Body Conventions

          A body is by default an uninterpreted sequence of octets reading agents SHOULD tolerate header names
   containing any US-ASCII printable character other than colon (":",
   ASCII 58).
[To bring it into line with <optional-field> as given in [MESSFOR].]

   Header-names SHOULD be either those for
          most which a USENET-header-content
   is defined in this standard, or those defined in [MESSFOR], or those
   defined in any extension to either of these standards including, in
   particular, the purposes of Mime standards [RFC 2045] et seq., or experimental
   headers beginning with "X-" (as defined in 4.2.2.1).  Software SHOULD
   NOT attempt to interpret headers not described in this standard. However, a MIME
          Content-Type header may impose some structure standard or intended
          interpretation upon it, and may also specify the character set in accordance with which the octets are
   its extensions, but relaying agents MUST pass them on unaltered and
   reading agents MUST enable them to be interpreted.

          NOTE: displayed, at least optionally.

   The syntax does not permit the NUL octet possibility of allowing header-parameters to appear in a
          body, and the octets CR and LF MUST ONLY occur together as
          CRLF.  See also section 4.6 for limits on the length of a
          line.

          It all
   headers is a common practice provided mainly for followup agents to enable the
          incorporation purpose of the followed-up article (the "precursor")
          as allowing future
   extensions to existing headers, since only a quotation. This SHOULD be done by prefacing each line
          of the quoted text (even if it is empty) with the character
          ">" (or preferably with "> "). This will result very few USENET-header-
   parameters are actually defined in multiple
          levels of ">" when quoted content itself contains quoted
          content. The followup agent SHOULD also precede the quoted
          content by an "attribution line" incorporating at least the
          name of the precursor's poster.

          The following convention this standard. Observe that such
   header-parameters do not, in general, occur in headers defined in
   other standards, except for attribution lines, whilst not
          mandated the Mime standards [RFC 2045] et seq. and
   their extensions. Nevertheless, compliant software MUST accept all
   such header-parameters in headers defined by this Standard, is intended to facilitate their
          automatic recognition standard and processing by sophisticated reading
          agents. The following fields describing the precursor SHOULD, its
   extensions (ignoring them if present, be their meaning is unknown) and SHOULD
   accept (and ignore) them in all headers.
[but what about
address = mailbox / group
group = phrase ":" [mailbox-list] ";"
Does the given order.

          A single Newsgroup name (the one from which following NOTE cover the followup is
          being made) enclosed within <...> or <news:...>

          The precursor's Message-ID enclosed within <...> or <news:...>

          The precursor's poster's Name enclosed within "..."

          The precursor's poster's Email address enclosed within <...> or
          <mailto:...> situation?]
                          News Article Format              February 2000

        NOTE: The fields may be separated by arbitrary text, they may be
          folded presence of a ";" in a header-content does not
        indicate the same way as headers, and they should be
          terminated by presence of a ":" followed by two CRLFs. Example:

          On <comp.foo> header-parameter in <12345678@foo.com> on 24 Dec 1997 16:40:20 +0000
          "Joe D. Bloggs" <jdbloggs@foo.bar> wrote:

          NOTE: The use of the standard character ">" facilitates
          automatic analysis of articles. The inclusion few
        situations where it can be parsed as part of some USENET-
        header-content or other-header-content.

   On the
          Message-ID in the attribution would enable reading agents to
          retrieve the precursor by clicking on it. However, readers are
          warned not to assume that attributions are accurate,
          especially within multiply nested quotations.

          NOTE: Posters SHOULD edit quoted context to trim it down to
          the minimum necessary. However, followup other hand, posting agents SHOULD NOT
          attempt to enforce this beyond issuing generate them (even
   those using x-tokens) except in those headers for which a warning (past
          attempts to do so have USENET-
   header-parameter has been found defined, or where that usage is permitted
   by some other standard (notably one of the Mime standards). This
   restriction is likely to be notably
          counter-productive).

          A "personal signature" removed in a future version of this
   standard.

        NOTE: The given syntax is ambiguous insofar as a short closing text automatically
          added USENET-header-
        content that is defined to be <unstructured> could contain,
        within that <unstructured>, text of the end form <*(";" header-
        parameter)>. The intention is therefore that any such apparent
        header-parameters are to be regarded as part of articles by posting agents, identifying the poster and giving his network addresses, etc. If a poster
          or posting agent
        <unstructured>. This standard therefore does append such a signature not (and extensions
        to an article, it MUST SHOULD NOT) define any USENET-header-parameter to be preceded
        associated with a delimiter line containing (only)
          two hyphens (ASCII 45) followed by one SP (ASCII 32). such an unstructured USENET-header-content.

   The
          signature is considered to extend from the last occurrence of
          that delimiter up to the end order of the headers in an article (or up is not significant. However,
   posting agents are encouraged to put mandatory headers (section 5)
   first, followed by optional headers (section 6), followed by
   experimental headers and headers not defined in this standard or its
   extensions. Relaying agents MUST NOT change the end order of the part in the case of a multipart MIME body). Followup
          agents, when incorporating quoted text from a precursor,
          SHOULD NOT include the signature headers
   in an article, though they MAY add additional headers, preferably
   either before or after all the quotation. Posting
          agents SHOULD discourage (at least with a warning) signatures
          of excessive length (4 lines existing ones.

   Header-names are case-insensitive. There is a commonly accepted limit).

4.5. Characters And Character Sets

          Transmission paths for news articles MUST treat news articles
          as uninterpreted sequences of octets, excluding the values 0
          (ASCII NUL) preferred case
   convention, which posters and 13 posting agents SHOULD use: each
   hyphen-separated "word" has its initial letter (if any) in uppercase
   and 10 (ASCII CR the rest in lowercase, except that some abbreviations have all
   letters uppercase (e.g. "Message-ID" and LF, which MUST only
          appear "MIME-Version"). The forms
   used in the combination <CRLF> which denotes a line
          separator).

          NOTE: this correspponds to standard are the range of octets permitted preferred forms for
          MIME "8bit data" [RFC-2045].

          An octet, or a sequence of octets, the headers
   described herein. Relaying and reading agents MUST, however, tolerate
   articles not obeying this convention.

4.2.2.  Header Properties

   There are four special properties that may represent apply to particular
   headers, namely: "experimental", "inheritable", "local", and
   "variant". When a character header is defined, in some Coded Character Set (CCS) [RFC-2130] this (or any future)
   standard, as determined by
          some Character Encoding Scheme (CES) [RFC-2130].

          If it comes to a relaying agent's attention that having one (or possibly more) of these properties, it is being
          asked to pass an article using the Content-Transfer-Encoding
          "8bit"
   subject to a relaying agent that does not support it, it SHOULD
          report this error special treatment, as indicated below.

4.2.2.1.  Experimental Headers

   Experimental headers are those whose header-names begin with "X-".
   They are to its administrator. It MUST refuse be used for experimental Netnews features, or for
   enabling additional material to pass
          the article and MUST NOT re-encode it be propagated with different MIME
          encodings. an article. There
   are no established headers that are considered experimental headers;
   an established header cannot be experimental.

                          News Article Format              February 2000

        NOTE: This strategy will do little harm. The target relaying
          agent is unlikely to Some such headers may eventually be able to make use of the article on its
          own servers, and the usual flooding algorithm will likely find adopted as standard by
        some alternative route to get the article extension to destinations
          where it is needed.

4.5.1. Character Sets within Article this standard, at which point they will lose
        their "X-" prefix.

4.2.2.2.  Inheritable Headers

          Within article headers,

   Subject only to the CES is UTF-8 [ISO-10646 or
          RFC-2279] and hence overriding ability of the CCS is poster to determine the Universal Multiple-Octet
          Coded Character Set (UCS) [ISO-10646] (which is essentially a
          superset
   contents of Unicode [UNICODE] and expected to remain so).
          However, interpreting the octets directly as ASCII characters
          should ensure correct behaviour headers in most situations.

          NOTE: UTF-8 is an encoding for 16bit (and even 32bit)
          character sets a proto-article, headers with the
   inheritable property that any octet less than 128
          immediately represents the corresponding ASCII character, thus
          ensuring upwards compatibility with previous practice.
          Non-ASCII characters from UCS are represented by sequences of
          octets greater than 127. Only those octet sequences explicitly
          permitted MUST be copied by [RFC 2079] shall followup agents (perhaps with
   some modification) into the followup article, and headers without
   that property MUST NOT be used. UCS includes all
          characters so copied.  Examples include:
     o Newsgroups (5.5) - copied from the ISO-8859 series of characters sets
          [ISO-8859] (which includes all Greek and Arabic characters) as
          well as precursor, subject to any
       Followup-To header.
     o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
       copied from the more elaborate characters used in Japan and China.
          See precursor.
     o References (6.8) - copied from the following section for precursor, with the appropriate treatment addition
       of UCS
          characters by reading agents.

          Notwithstanding the great flexibility permitted by UTF-8,
          there precursor's Message-ID.
     o Distribution (6.6) - copied from the precursor.

        NOTE: The Keywords header is need for restraint in its use in order that not inheritable, though some older
        newsreaders treated it as such.

4.2.2.3.  Local Headers

   Headers with the
          essential components local property are significant only to a particular
   serving agent (or perhaps a cooperating group of headers may such agents). They
   MAY be discerned using
          reading removed by relaying agents that cannot present the full UCS range. In
          particular, header-names MUST be in ASCII, and certain other
          components of headers, as defined elsewhere in this standard -
          notably <identifier>s (as in <message-id>s), <date-time>s,
          <domain>s <addr-spec>s before propagation, and <path-item>s - MUST be in ASCII.
          <Comment>s, <phrase>s (as in <address>es) and <unstructured>s
          (as in <subject>s)
   removed (and replaced as necessary) by serving agents when received.
   The replaced header MAY use other character sets. For
          <newsgroup-name>s see below.

          Where be placed anywhere within the use of non-ASCII characters, encoded in UTF-8, headers (though
   placing it first is
          permitted recommended). The principle example is:
     o Xref (6.14) - used to keep track of the article locators of
       crossposted articles so that newsreaders can mark such articles
       as above, they read.

4.2.2.4.  Variant Headers

   Headers with the variant property are modified as articles are
   propagated. The modified header MAY also be encoded using placed anywhere within the MIME
          mechanism defined in RFC-2047 [RFC-2047], but this usage
   headers (though placing it first is
          deprecated within news articles (even though it is required in
          mail messages) since it recommended). The principle
   example is:
     o Path (5.6) - augmented at each relaying agent that an article
       passes through.

4.2.3.  White Space and Continuations

[The following text is less legible in older reading
          agents which support neither it nor UTF-8. Nevertheless,
          reading agents SHOULD support taken from [MESSFOR], adapted to the different
terminology used for this usage, but only in those
          contexts explicitly mentioned in [RFC-2047].

4.5.2 Character Sets within Article Bodies

          Within article bodies, standard.]

   Each header is logically a single line of characters comprising the CES and CCS implied by any
          Content-Transfer-Encoding
   header-name, the colon with its following SP, and Content-Type headers [RFC-2045]
          SHOULD be applied by reading agents. In the absence of such
          headers, reading agents cannot be relied upon to display
          correctly more than header-content.
   For convenience, however, the ASCII characters.  [Observe header-content can be split into a
   multiple line representation; this is called "folding". The general
   rule is that
          reading agents are wherever this standard allows for FWS or CFWS (but not forbidden to "guess",
   simply SP or to interpret
          as UTF-8 regardless, which would HTAB) a CRLF may be inserted before any WSP. For
                          News Article Format              February 2000

   example, the simplest course for
          them to take.]

          NOTE: It is not expected that reading agents will necessarily header:
      Approved: modname@modsite.example (Moderator of comp.foo.bar)
   can be able to present characters represented as:
      Approved: modname@modsite.example
         (Moderator of comp.foo.bar)

        NOTE: Though header-contents are defined in all possible character sets,
          although they MUST be able to present all ASCII characters.
          For example, such a reading agent might be able to present only way that
        folding can take place between many of the
          ISO-8859-1 (Latin 1) characters [ISO-8859], in which case it
          SHOULD present undisplayable characters using lexical tokens (and
        even within some distinctive
          glyph, or by exhibiting a suitable warning. Older reading
          agents that do not understand MIME headers or UTF-8 should of them), folding SHOULD be
          able limited to display bodies in ASCII (with some loss of human
          comprehensibility) except possibly when placing
        the
          Content-Transfer-Encoding CRLF at higher-level syntactic breaks, and SHOULD also avoid
        leaving trailing WSP on the preceding line. For instance, if a
        header-content is "8bit".

          NOTE: Be warned defined as comma-separated values, it is
        recommended that folding occur after the comma separating the
        structured items, even if it will never is allowed elsewhere.

   Folding MUST NOT be safe to send raw binary
          data carried out in the body such a way that any line of news articles, because the presence a
   header is made up entirely of
          ASCII NUL WSP characters and changes of <CRLF> representation will inevitably
          corrupt it. Such data nothing else.

   The colon following the header name on the first line MUST be encoded (e.g.
   followed by using
          Content-Transfer-Encoding: base64).

          Posters SHOULD avoid using control characters in ASCII (or
          other CCSs) except for tab (ASCII 9), formfeed (ASCII 12), and
          backspace (ASCII 8). Tab signifies sufficient horizontal white
          space a WSP, even if the header is empty. If the header is not
   empty, at least some of the content MUST appear on the first line
   (this is to reach avoid the next possibility of harm by any non-compliant agent
   that might eliminate a set of fixed positions; posters
          are warned trailing SP). Posting agents MUST enforce
   these restrictions, but relaying agents SHOULD accept even articles
   that there is no violate them.

        NOTE: This standard set of positions, so tabs
          should be avoided if precise spacing is essential. Formfeed
          signifies a point at which a reading agent SHOULD pause and
          await reader interaction before displaying further text.
          Backspace SHOULD be used only for underlining, done by a
          sequence of underscores (ASCII 95) followed by an equal number
          of backspaces, signifying differs from [MESSFOR] in requiring that WSP
        followng the same number of text
          characters following are to be underlined. colon (it was also an [RFC 1036] requirement).

   Posters are warned
          that underlining is not available on all output devices and is
          best not relied on for essential meaning. Reading posting agents SHOULD recognize underlining use SP, not HTAB, where white space
   is desired in headers (some existing software expects this), and translate it to the
          appropriate commands for devices that support it. Reading
          agents MUST NOT pass other control characters or escape
          sequences unaltered to
   use SP immediately following the output device.

          Followup colon after a header-name. Relaying
   agents MUST be careful to apply appropriate encodings
          to SHOULD accept HTAB in all such cases, however.

   Since the outbound followup. A followup to an article containing
          non-ASCII material is very likely to contain non-ASCII
          material itself.

4.6. Size Limits

          The syntax provides for white space beginning a continuation line remains a part of
   the logical line, headers can be "broken" into multiple lines only at
   FWS or CFWS. Posting agents SHOULD NOT break headers unnecessarily
   (but see 4.5).

4.2.4.  Comments

   Strings of a body to characters which are treated as comments may be up to 998
          octets included
   in length, not including header-contents wherever the CRLF. All software
          compliant with this standard MUST support lines of at least
          that length, both in headers and in bodies, and all such
          software SHOULD support lines of arbitrary length. In
          particular, relaying agents MUST transmit lines of arbitrary
          length without truncation or any other modification.

          NOTE: The limit syntactic element CFWS occurs. They
   consist of 998 octets is consistent with the
          corresponding limit characters enclosed in [MESSFOR].

           In plain-text messages (those with no MIME headers, or those
           with parentheses. Such strings are
   considered comments so long as they do not appear within a MIME Content-Type of text/plain) posting agents SHOULD
           endeavour quoted-
   string. Comments may be nested.

   A comment is normally used to keep provide some human readable
   informational text, except at the length end of body lines within some
           reasonable limit. an address which contains no
   phrase, as in
      fred@foo.bar.example (Fred Bloggs)
   as opposed to
      "Fred Bloggs" <fred@foo.bar.example> .

                          News Article Format              February 2000

   The size of this limit former is a matter of
           policy, the default being to keep within 79 characters at
           most, deprecated, but commonly encountered, usage and preferably within 72 characters (to allow room for
           quoting in followups).  However, posting
   reading agents MUST permit
           the poster to include longer lines if he so insists.

           NOTE: Plain-text messages are intended to be displayed "as-is"
           without any SHOULD take special action (such note of such comments as automatic line splitting)
           on
   indicating the part name of the recipient. The policy limit (e.g. 72 or 79)
           should be expressed person whose address it is. In all other
   situations a comment is semantically interpreted as a number of characters (as they will be
           displayed by single SP.
   Since a reading agent) rather than as the number of
           octets used to encode them.

          Posting agents SHOULD fold headers by inserting CRLF followed
          by 1*WSP at positions (preferably higher-level ones - see
          4.3.2) where this comment is syntactically allowed so as to keep, so
          far as contain FWS, folding is possible, all header lines permitted
   within 79 characters.
          Likewise, injecting agents SHOULD fold any headers generated
          automatically by themselves. Relaying agents MUST NOT fold
          header lines (i.e. they must pass on the folding it as received).

          NOTE: There well as immediately preceding and immediately following
   it. Also note that, since quoted-pair is NO restriction on the number of lines into
          which allowed in a header may be split, comment, the
   parenthesis and hence there is NO restriction
          on backslash characters may appear in a comment so long
   as they appear as a quoted-pair. Semantically, the total length enclosing
   parentheses are not part of the comment content; the content is what
   is contained between the two parentheses.

   Since comments have not hitherto been permitted in news articles,
   except in a header (in particular it may, by
          suitable folding, be made few specified places, posters and posting-agents SHOULD
   NOT insert them except in those places, namely following addresses in
   From and similar headers, and to exceed indicate the 998 octets
          restriction pertaining name of the timezone in
   Date headers.  However, compliant software MUST accept them in all
   places where they are syntactically allowed.

4.2.5.  Undesirable Headers

   A header whose content is empty is said to a single be an empty header.
   Relaying and reading agents SHOULD NOT consider presence or absence
   of an empty header line).

          NOTE: This standard provides no upper bound on to alter the overall
          size semantics of a single article, but neither does it forbid relaying an article (although
   syntactic rules, such as requirements that certain header names
   appear at most once in an article, MUST still be satisfied). Posting
   and injecting agents SHOULD delete empty headers from dropping articles of excessive length. It is,
          however, suggested that any limits thought appropriate by
          particular before
   posting them; relaying agents would be more appropriately expressed in
          megabytes than in kilobytes.

4.7. Example

          Here is a sample article:

Path: server.example,unknown.site2.example@site2.example,
  relay.site.example,site.example,injector.site.example%jsmith
Newsgroups: example.announce,example.chat
Message-ID: <9urrt98y53@site.example>
From: Ann Example <a.example@site1.invalid>
Subject: Announcing MUST pass them untouched.

   Headers that merely state defaults explicitly (e.g., a new sample article.
Date: Fri, 27 Mar 1998 12:12:50 +1300
Approved: example.announce moderator <jsmith@site.invalid>
Followup-To: example.chat
Reply-To: Ann Example <a.example+replies@site1.example>
Expires: Wed, 22 Apr 1998 12:12:50 -0700
Organization: Site1, The Number one site for examples.
User-Agent: ExampleNews/3.14 (Unix)
Keywords: example, announcement, standards, RFC 1036, Usefor
Summary: The URL for Followup-To
   header with the next standard.

Just same content as the Newsgroups header, or a quick announcemnt Mime
   Content-Type header with contents "text/plain; charset=us-ascii") or
   state information that a new standard example article has been
released; it is in reading agents can typically determine easily
   themselves (e.g.  the new USEFOR draft obtainable from ftp.ietf.org.

Ann.

--
Ann Example <a.example@site1.invalid>       Sample Poster to length of the Stars
"The opinions body in this article octets) are bloody good ones" - from J Clarke.

5. Mandatory Headers

          An article MUST have one, redundant and only one, of each
   posters and posting agents SHOULD NOT include them.

4.3.  Body

4.3.1.  Body Format Issues

   The body of an article MAY be empty, although posting agents SHOULD
   consider this an error condition (meriting returning the
          following headers: Date, From, Message-ID, Subject,
          Newsgroups, Path.

          NOTE: [MAIL] specifies (if read most carefully) that there
          must be exactly one Date header and exactly one From header,
          but otherwise article to
   the poster for revision). A posting or injecting agent which does not  restrict multiple appearances  of
          headers.   (Notably, it permits multiple Message-ID
          headers!)    This appears singularly useless,  or even
          harmful, in
   reject such an article SHOULD issue a warning message to the context of news, poster
   and much current  news
          software  will  not tolerate multiple appearances of mandatory
          headers. supply a non-empty body.  Note also that there are situations, discussed in the
          relevant parts  of  section  6,  where  References,  Sender,
          or Approved headers are mandatory. In control articles,
          specific values are required for certain headers.

          In the discussions of the individual headers, separator line MUST be
   present even if the content of
          each body is specified using the syntax notation.  The convention
          used empty.

        NOTE: Some existing news software is that known to react badly to
        body-less articles, hence the content of, request for example, the Subject header
          is defined as <Subject-content>.

          NOTE: see also Section 7.1.1

5.1. Date

          The Date header contains the date posting and time that the injecting
        agents to insert a body in such cases. The sentence "This
        article was submitted for transmission.  The content syntax probably generated by a buggy news reader" has
        traditionally been used is
          defined in the Message this situation.

                          News Article Format Standard [MESSFOR].

               Date-content = date-time

5.2. From

          The From header contains the electronic address(es), and
          possibly the full name, of the article's author(s) . The
          format of the From header              February 2000

   Note that an article body is defined in the Message Format
          Standard [MESSFOR].

          All mailboxes a sequence of lines terminated by CRLFs,
   not arbitrary binary data, and in the From-content field particular it MUST either belong to end with a CRLF.
   However, relaying agents SHOULD treat the
          posters(s) body of the an article ( or the poster(s) are authorized as an
   uninterpreted sequence of octets (except as mandated by
          the owners to use the mailboxes) or end in the top level
          domain changes of ".invalid".

               From-content = mailbox-list

5.2.1 Examples:

From: John Smith <jsmith@site.example>
From: John Smith <jsmith@site.example>, dave@isp.example
From: John Smith <jsmith@site.example>, andrew@isp.example,
   fred@site2.example
From: Jan Jones <jan@please_setup_your_software_correctly.invalid>
From: Jan Jones <joe@anonymous.invalid>
From: dave@isp.example (Dave Smith)

          NOTE: the last example is
   CRLF representation and by control-message processing) and SHOULD
   avoid imposing constraints on it. See also section 4.5.

   Posters SHOULD avoid using control characters in an obsolete syntax.

5.3. Message-ID

          The  Message-ID  header contains US-ASCII (or other
   CCSs) except for tab (ASCII 9), formfeed (ASCII 12), and backspace
   (ASCII 8). Tab signifies sufficient horizontal white space to reach
   the article's message ID, next of a
          unique identifier  distinguishing  the  article  from  every
          other article. The format set of the Message-ID header fixed positions; posters are warned that there
   is defined
          in the Message Format Standard [MESSFOR] . An article's
          message ID MUST no standard set of positions, so tabs should be unique avoided if precise
   spacing is essential. Formfeed (which is sometimes referred to as the
   "spoiler character") signifies a point at which a reading agent
   SHOULD pause and MUST NEVER await reader interaction before displaying further
   text.  Backspace SHOULD be reused.

               Message-ID-content = msg-id

5.4. Subject

          The Subject field contains used only for underlining, done by a short string identifying the
          topic
   sequence of the message. When used in a followup, the field body
          SHOULD start with the string "Re: " ( a "back reference" ) underscores (ASCII 95) followed by the contents an equal number of
   backspaces, signifying that the pure-subject same number of the precursor.

          subject-content = [ back-reference ] pure-subject CRLF
          pure-subject = nonblank-text
          back-reference = %x52.65.3A.20        ; which text characters
   following are to be underlined. Posters are warned that underlining
   is a case-sensitive
                                                 "Re: "

          The pure-subject not available on all output devices and is best not relied on for
   essential meaning. Reading agents SHOULD recognize underlining and
   translate it to the appropriate commands for devices that support it.
   Reading agents MUST NOT begin with "Re: ". The default
          subject-content of a followup is pass other control characters or escape
   sequences unaltered to the string "Re: " followed output device.

4.3.2.  Body Conventions

   A body is by
          the contents default an uninterpreted sequence of octets for most of
   the pure-subject purposes of this standard. However, a Mime Content-Type header
   may impose some structure or intended interpretation upon it, and may
   also specify the precursor. Any leading
          "Re: " character set in accordance with which the pure-subject MUST octets
   are to be stripped.

          Followup interpreted.

   It is a common practice for followup agents MAY remove instances to enable the
   incorporation of non-standard
          back-reference (such the followed-up article (the "precursor") as "Re(2): ", "Re:", "RE: ", or "Sv: ")
          from a
   quotation. This SHOULD be done by prefacing each line of the subject-content when composing quoted
   text (even if it is empty) with the subject character ">" (or perhaps with
   "> " in the case of a
          followup and add a correct back-reference previously unquoted line). This will result in front
   multiple levels of ">" when quoted content itself contains quoted
   content, and it will also facilitate the
          result. automatic analysis of
   articles.

        NOTE: that would be "SHOULD remove instances" except that we
          cannot find a sufficiently robust and simple algorithm Posters should edit quoted context to trim it down to do the necessary natural language processing.

          Followup
        minimum necessary. However, followup agents MUST SHOULD NOT use any other string except "Re: " as
          a back reference. Specifically, a translation of "Re: " into attempt
        to enforce this beyond issuing a
          local language or usage MUST NOT warning (past attempts to do so
        have been found to be used.

          Agents notably counter-productive).

   The followup agent SHOULD NOT depend on nor enforce also precede the use of back
          references quoted content by followup agents.  For compatibility with legacy
          news software the subject-content of a control message MAY
          start with the string "cmsg ", non-control messages MUST NOT
          start with the string "cmsg ".

5.4.1 Examples:

          In the following examples, please note an
   "attribution line" (however, readers are warned not to assume that only "Re: " is
   they are accurate, especially within multiply nested quotations). The
   following convention for such lines, whilst not mandated by this DRAFT. "was: "
   standard, is a convention used by many
          English-speaking posters intended to signal a change facilitate their automatic recognition and
   processing by sophisticated reading agents. The attribution SHOULD
   contain the name or the email address of the precursor's poster, as
                          News Article Format              February 2000

   in subject matter.
          Software should be able to deduce this information
      Joe D. Bloggs <jdbloggs@foo.example> wrote:
   or
      Helmut Schmidt <helmut@bar.example> schrieb:

   The attribution MAY contain also a single Newsgroup name (the one
   from
          References.

Subject: Film at 11.
Subject: Re: Film at 11
Subject: Use of Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11)

5.5. Newsgroups

          The Newsgroups header's content specifies which newsgroup(s) the article followup is posted to:

Newsgroups-content  = newsgroup-name
                          *( ng-delim *FWS newsgroup-name ) *FWS
newsgroup-name      = component
                          *( "." component )
component           = component-start
                          *( component-start / component-other )
component-start     = Un-lowercase / Un-digit
Un-lowercase        = <Unicode Letter, Lowercase> /
                      <Unicode Letter, Other>
Un-uppercase        = <Unicode Letter, Uppercase> /
                      <Unicode Letter, Titlecase>
Un-digit            = <Unicode Number, Decimal Digit> /
                      <Unicode Number, Other>
component-other     = "+" / "-" / "_"
ng-delim            = ","

          where being made), the <Unicode ...> items precursor's Message-ID
   and/or the precursor's Date and Time. Any of these that are as described in [UNICODE].

          An article's Newsgroups header may not contain a duplicated
          newsgroup-name component.

          The present,
   SHOULD precede the name and/or email address. However, the inclusion
   or not of folding white space within a newsgroup-name
          is a newly introduced feature in this standard. It MUST such fields SHOULD always be
          accepted by all conforming implementations (relaying agents,
          serving agents under the control of the
   poster.

   To enable this line, and the Message-ID and the Email address within
   it, to be recognised (for example to enable suitable reading agents). Posting agents should be
          aware that except for experimental posting
   to 'test' newsgroups retrieve the precursor or email its poster by clicking on them),
   the following conventions SHOULD be observed:
     o The precursor's Message-ID SHOULD be enclosed within <...> or
       <news:...>
     o The precursor's poster's Email address SHOULD be enclosed within cooperating subnets, such postings
       <...>
     o The various fields may be rejected separated by
          overly-critical old-style relaying agents. When a sufficient
          number of relay agents are in conformance, posting agents
          SHOULD generate such whitespace arbitrary text and they
       may be folded in the form of <CRLF WS> so same way as headers, but attributions SHOULD
       always be terminated by a ":" followed by CRLF.

   Further examples:

      On comp.foo in <1234@bar.example> on 24 Dec 1997 16:40:20 +0000,
         Joe D. Bloggs <jdbloggs@bar.example> wrote:

      Am 24. Dez 1997 schrieb Helmut Schmidt <helmut@bar.example>:

   A "personal signature" is a short closing text automatically added to keep
   the length end of lines in articles by posting agents, identifying the relevant headers (notably
          Newsgroups poster and Followup-To) to no more than than 79 characters
          (or other agreed policy limit - see 4.6). Before such critical
          mass occurs, injecting agents MAY reformat
   giving his network addresses, etc. If a poster or posting agent does
   append such headers by removing
          whitespace inserted a signature to an article, it MUST be preceded with a
   delimiter line containing (only) two hyphens (ASCII 45) followed by
   one SP (ASCII 32). The signature is considered to extend from the posting agent, but relaying agents
          MUST NOT do so.

          A newsgroup name consists
   last occurrence of one or more components.
          Components MAY contain non-ASCII letters, but these MUST be
          encoded in UTF-8 and not according that delimiter up to RFC-2047. A component
          MUST contain at least one letter (and must, according the end of the article (or up
   to the
          syntax, begin and end with of the part in the case of a letter or digit). Components multipart Mime body).
   Followup agents, when incorporating quoted text from a precursor,
   SHOULD begin NOT include the signature in the quotation. Posting agents
   SHOULD discourage (at least with a letter. Composite characters (made by
          overlaying one character with another) and format characters,
          as allowed in certain parts of Unicode and needed by certain
          languages, must use whatever canonical conventions apply to
          those parts of Unicode (such conventions are not
          defined in this Standard). The use warning) signatures of "_" in excessive
   length (4 lines is a component commonly accepted limit).

        NOTE: It is
          deprecated. Serving agents MAY refuse undesirable to accept newsgroups
          using that component.

          NOTE: Components composed entirely of digits would cause
          problems for the commonly used implementation technique of
          using have more than one personal signature
        in an article body (even though the component as rule above admits the name of a directory, whilst also
          using sequential numbers to distinguish
        possibility by recognising only the articles within last one). If, for some
        reason, a
          group.

          NOTE: Uppercase letters MUST NOT be used. Although converting
          ASCII uppercase letters to their lowercase counterparts second signature is
          straightforward enough, considered necessary, it would MAY be unreasonable to expect
          software
        preceded by a different delimiter (e.g.  "--- ").
[That is Clive's suggestion. Not to do be included without further
support.]
                          News Article Format              February 2000

4.4.  Characters and Character Sets

   Transmission paths for news articles MUST treat news articles as
   uninterpreted sequences of octets, excluding the same values 0 (ASCII NUL)
   and 13 and 10 (ASCII CR and LF, which MUST ONLY appear in parts of Unicode for the
   combination CRLF which it was
          not configured (in general, denotes a table lookup would be required).
          Thus software MAY attempt to convert Un-uppercase letters
          according to the mappings defined by [UNICODE], but line separator).

        NOTE: this
          behaviour is not required.

          Whilst there is no longer any technical reason correspponds to limit the
          length range of a component (formerly, it was limited to 14
          characters) nor to limit the total length of a newsgroup-name,
          it should octets permitted for
        Mime "8bit data" [RFC 2045].  Thus raw binary data cannot be noted that these names are also used
        transmitted in the
          newsgroups line (6.6.1.2) where an overall limit applies, and
          moreover excessively long names can be exceedingly
          inconvenient in practical use.  Agencies responsible for
          individual hierarchies SHOULD therefore, as a matter of
          policy, set reasonable limits for article body except by the length of a component
          and use of a newsgroup name. In the absence of Content-
        Transfer-Encoding such explicit
          policies, the default figures are 30 characters and 72
          characters respectively.

          NOTE: The newsgroup-name as encoded base64.

   An octet, or a sequence of octets, may represent a character in UTF-8 should be
          regarded some
   Coded Character Set (CCS) as the canonical form. Reading agents may convert determined by some Character Encoding
   Scheme (CES) [RFC 2130].

   If it comes to whatever character set they are able to display (see 4.5.2)
          and serving agents may possibly need to convert a relaying agent's attention that it is being asked to some
          form more suitable as a filename. Simple algorithms for both
          kinds of conversion are readily available.

          Posters SHOULD use only the names of existing newsgroups in
   pass an article using the Newsgroups header, because newsgroups are Content-Transfer-Encoding "8bit" to a
   relaying agent that does not created
          simply by being posted to. However, support it, it is legitimate SHOULD report this error
   to
          cross-post its administrator. It MUST refuse to newsgroup(s) which do not exist on the posting
          agent's host, provided that at least one of pass the newsgroups
          DOES exist there, article and followup agents MUST accept this
          (posting agents MAY accept it, but SHOULD at least alert the
          poster to the situation and request confirmation). Relaying
          agents MUST NOT rewrite Newsgroups headers in any way, even if
          some or all of the newsgroups
   re-encode it with different Mime encodings.

        NOTE: This strategy will do not exist on the relaying
          agent's host.

5.5.1 Forbidden newsgroup names little harm. The following newsgroup-names MUST NOT be used:

          Newsgroup-names having only one component (reserved for
          newsgroups whose propagation target relaying
        agent is restricted unlikely to a single host,
          or local network, and for pseudo-newsgroups such as "poster"
          (because it has special meaning in the Followup-To header (see
          section 6.1)), "newsgroups" (likewise), "junk" (frequently
          used for pseudo-newsgroups internal be able to serving agents)
           and "control" (likewise).

          Any newsgroup-name beginning with "control." (Used as a
          pseudo-newsgroup by many serving agents.)

          Any newsgroup-name containing make use of the component "ctl" (likewise)

          "to" or any newsgroup-name beginning with "to." (reserved for
          test messages sent article on an essentially point-to-point basis (see
          also the ihave/sendme protocol described in section 7.2)

          Any newsgroup-name containing its
        own servers, and the component "all" (because
          this is used as a wildcard in usual flooding algorithm will likely find
        some implementations)

          A newsgroup MUST NOT appear more than once in the Newsgroups
          header. The order of newsgroup names in alternative route to get the Newsgroups
          header article to destinations where
        it is not significant.

5.6 Path

          The Path header shows needed.

4.4.1.  Character Sets within Article Headers

   Within article headers, the route a message took from its entry
          into CES is UTF-8 [ISO 10646] or [RFC 2279]
   and hence the USENET system to CCS is the current system. It Universal Multiple-Octet Coded Character Set
   (UCS) [ISO 10646] (which is essentially a list superset of
          site identifiers with the origin on Unicode
   [UNICODE] and expected to remain so). However, interpreting the right. Each relaying,
          injecting or serving agent
   octets directly as US-ASCII characters should ensure correct
   behaviour in most situations.

        NOTE: UTF-8 is an encoding for 16bit (and even 32bit) character
        sets with the property that processes any octet less than 128 immediately
        represents the article adds one
          or more entries to this header.  Aside corresponding US-ASCII character, thus ensuring
        upwards compatibility with previous practice.  Non-ASCII
        characters from tracing UCS are represented by sequences of octets
        satisfying the route
          articles take in moving over syntax of a UTF8-xtra-char (2.4).  Only those
        octet sequences explicitly permitted by [RFC 2044] shall be
        used.  UCS includes all characters from the network, Path is ISO-8859 series of
        characters sets [ISO 8859] (which includes all Greek and Arabic
        characters) as well as the more elaborate characters used
          primarily to allow relaying systems to not send articles to
          sites known to already have them, in particular
        Japan and China. See the site they
          came from.  This improves following section for the efficiency appropriate
        treatment of links.  Path UCS characters by reading agents.

   Notwithstanding the great flexibility permitted by UTF-8, there is
          also used
   need for USENET statistics gathering and flow tracking.
          Finally restraint in its use in order that the presence essential components
   of a "%" delimiter in headers may be discerned using reading agents that cannot present
   the Path header can full UCS range. In particular, header-names and tokens MUST be used to identify an article injected in conformance with
          this standard.

5.6.1
                          News Article Format

          path-content    =       old-path / new-path

          old-id          =       1*( ALPHA / digit / "-" | "." | "_")
          old-path        =       old-id *(punctuation old-id)
          punctuation     =       LWSP / %x21-2f / %x3a-40 / %x5b-60 / %x7b-7f
                                              ; These are ! " # $ % & ' ( ) *
                                              ;   + , - . / : ; < = > ? @ [ \
                                              ;   ] ^ _ ` { | } ~ DEL
          new-delims      =       [FWS] ("@" / "/" / "," ) [FWS]
          new-path        =       post-injection "%" pre-injection
          delim-plus-id   =       [FWS] "!" [FWS] old-id
                                  / new-delims site-id
          post-injection  =       *(site-id 1*new-delims) site-id
          pre-injection   =       site-id *delim-plus-id
          site-id         =       ALPHA word      ; UUCP name
                                  / ALPHA         ; for "x" tail entry
                                  / "." word      ;              February 2000

   US-ASCII, and certain other registered name
                                  / <FQDN>        ; components of headers, as per RFC 1034
                                  / <dotted-quad> ; numeric IP address rep
                                                  ; specified defined
   elsewhere in rfc820 etc.
                                  / "[" dotted-quad "]"
                                  / "[" <ipv6-numeric> "]" ; per RFC1884
          word            =       1*(ALPHA / digit / "-" / "_")

5.6.2 Adding an entry to the Path header.

         When a system receives a message from another system, it MUST
         add its own unique name (path-identity or site-id) this standard - notably msg-ids, date-times, dot-atoms,
   domains and a
         delimiter to the beginning of the Path string. In addition, if
         needed, folding-whitespace MAY be added.

         The path-identity added path-identities - MUST be unique. To this end it should
         be one of:

         1. A name registered previously in the UUCP maps database
         (found US-ASCII.  Comments, phrases
   (as in addresses) and unstructureds (as in Subject headers) MAY use
   the newsgroup comp.mail.maps), containing no dot
         character.

         3. The fully qualified domain name or MX record, retrievable
         via full range of UTF-8 characters. For newsgroup-names see 5.5.

   Where the Internet DNS service.

         4. An encoding use of an IP address -- dotted quad or for IPv6 as
         per RFC1884. These encodings using SHOULD NOT be used prior to
         draft-implementation-date.

         Whichever form non-ASCII characters, encoded in UTF-8, is chosen, a site SHOULD use a form which can permitted
   as above, they MAY also be
         verified encoded using one of the schemes described below by all sites
         to which it will forward Mime mechanism defined
   in [RFC 2047], but this usage is deprecated within news articles. If all forwarding articles
   (even though it is by
         NNTP or other internet based protocols, then required in mail messages) since it is less
   legible in older reading agents which support neither it nor UTF-8.
   Nevertheless, reading agents SHOULD support this usage, but only in
   those contexts explicitly mentioned in [RFC 2047].

4.4.2.  Character Sets within Article Bodies

   Within article bodies, the FQDN or IP
         address encodings are advised. For CES and CCS implied by any Content-
   Transfer-Encoding and Content-Type headers [RFC 2045] SHOULD be
   applied by reading agents. In the purposes absence of comparison,
         FQDN entries should such headers, reading
   agents cannot be put in an all-lower-case canonical form.

         Because RFC1036 specified any punctuation relied upon to display correctly more than the US-
   ASCII characters.
[Observe that reading agents are not forbidden to "guess", or whitespace could
         act to
interpret as delimiter, programs SHOULD accept this, with UTF-8 regardless, which would be the
         exception simplest course for
them to take.]

        NOTE: It is not expected that IPv6 addresses containing colons reading agents will necessarily be
        able to present characters in all possible character sets,
        although they MUST be treated
         as able to present all US-ASCII characters.
        For example, a single unit. Modern programs MUST generate reading agent might be able to present only the set
         "!,%@" plus optional additional whitespace.

         When a site receives an article from another site,
        ISO-8859-1 (Latin 1) characters [ISO 8859], in which case it
        SHOULD
         (and eventually MUST) verify the identity of
         the source site. When processing an article from present undisplayable characters using some distinctive
        glyph, or by exhibiting a source, the
         leftmost entry of the Path line suitable warning. Older reading agents
        that do not understand Mime headers or UTF-8 should be extracted, converted
         to a canonical form, and tested able to see if    it matches the
         canonical form of the verified identity
        display bodies in US-ASCII (with some loss of human
        comprehensibility) except possibly when the source. If it
         does, a "," should be used as the delimiter, and thus the
         comma, and then the receiving site's path-identity Content-Transfer-
        Encoding is "8bit".

   Followup agents MUST be
         prepended careful to apply appropriate encodings to the Path line.

         The method of verification
   outbound followup. A followup to an article containing non-ASCII
   material is up very likely to the site. Any method of contain non-ASCII material itself.

4.5.  Size Limits

   Posting agents SHOULD endeavour to keep all header lines, so far as
   is possible, within 79 characters by folding them at suitable authenticity may be chosen, with the consideration
         that in places
   (see 4.2.3).  However, posting agents MUST permit the event poster to
   include longer headers if he so insists, and compliant software MUST
   support headers of problems at least 998 octets. Likewise, injecting agents
   SHOULD fold any headers generated automatically by themselves.
   Relaying agents MUST NOT fold headers (i.e. they must pass on the source site,
   folding as received).

                          News Article Format              February 2000

        NOTE: There is NO restriction on the relaying
         site number of lines into which
        a header may be called upon to reliably identify it.

         If the leftmost entry does not match split, and hence there is NO restriction on the verified identity
        total length of
         the source, then the receiving site should prepend an "@"
         delimiter, then a simple form of the verified identity of header (in particular it may, by suitable
        folding, be made to exceed the
         source, then 998 octets restriction pertaining
        to a "," delimiter and then single header line).

   The syntax provides for the receiving site's own
         path-identity.  This adding lines of two identities to the line
         MUST NOT a body to be done if up to 998 octets in
   length, not including the provided CRLF. All software compliant with this
   standard MUST support lines of at least that length, both in headers
   and verified identities
         match.  For articles received from an internet source, the
         unique IPv4 (or IPv6) address in bodies, and all such software SHOULD support lines of
   arbitrary length. In particular, relaying agents MUST transmit lines
   of arbitrary length without truncation or properly verified FQDN, whichever
         is shorter, is encouraged for the generated ID.

5.6.3 any other modification.

        NOTE: The tail Entry

         For historical reasons, limit of 998 octets is consistent with the rightmost entry
        corresponding limit in the Path string
         generated by most systems is not a site name, but [MESSFOR].

   In plain-text messages (those with no Mime headers, or those with a "user
         name". However, the Path string is not an E-mail address and
         MUST NOT be used
   Mime Content-Type of text/plain) posting agents SHOULD endeavour to contact
   keep the user.  Injecting agents MAY
         place any string here that length of body lines within some reasonable limit. The size
   of this limit is not a path-identity. If no
         meaning is anticipated the string "x" SHOULD be used.

         RFC1036 suggested that matter of policy, the last entry could be a site name,
         requiring software default being to check it when feeding, but said it also
         should have a user-id keep within
   79 characters at most, and preferably within 72 characters (to allow
   room for very old systems. As quoting in followups).  Exceptionally, posting agents SHOULD
   NOT adjust the length of this
         specification, quoted lines in followups unless they are
   able to reformat them in a systems consistent manner.  Moreover, posting
   agents MUST NOT treat permit the tail entry as a
         path-identity.

         Typically this field will poster to include longer lines if he so
   insists.

        NOTE: Plain-text messages are intended to be the only entry displayed "as-is"
        without any special action (such as automatic line splitting) on
        the Path string
         generated by a poster, or if not generated by the
         posting-agent, by the injecting agent, which will prepend a "%"
         and then its own verifiable path-identity.  The percent divides
         the verified part of the Path line from any entries provided
         prior to injection into the news network.  There may recipient. The policy limit (e.g. 72 or 79)
        should be more
         than one entry to the left expressed as a number of the percent, and all but the last
         are to characters (as they will be treated
        displayed by a reading agent) rather than as sites.

         Injecting Agents SHOULD use the tail entry for local
         authentication information on the source number of an article. For
         example, if they wish
        octets used to store an encoding of encode them.

        NOTE: This standard provides no upper bound on the IP address overall size
        of a source machine connecting to do the injection, and/or the UID single article, but neither does it forbid relaying agents
        from dropping articles of an invoking user or excessive length. It is, however,
        suggested that any other such information, they may
         encode it limits thought appropriate by particular
        agents would be more appropriately expressed in the tail entry, provided they do so megabytes than
        in a manner
         that will not match any site identifier. (e.g. ending with a
         dot) .

5.6.4 The Injecting Agent Entry

          The injecting agent's path identity kilobytes.

4.6.  Example

   Here is a special case. This
          identity MUST be a FQDN which can be used as sample article:

      Path: server.example/unknown.site2.example@site2.example/
        relay.site.example/site.example/injector.site.example%jsmith
      Newsgroups: example.announce,example.chat
      Message-ID: <9urrt98y53@site.example>
      From: Ann Example <a.example@site1.example>
      Subject: Announcing a domain new sample article.
      Date: Fri, 27 Mar 1998 12:12:50 +1300
      Approved: example.announce moderator <jsmith@site.example>
      Followup-To: example.chat
                          News Article Format              February 2000

      Reply-To: Ann Example <a.example+replies@site1.example>
      Expires: Wed, 22 Apr 1998 12:12:50 -0700
      Organization: Site1, The Number one site for
          E-mail connections (ie. examples.
      User-Agent: ExampleNews/3.14 (Unix)
      Keywords: example, announcement, standards, RFC 1036, Usefor
      Summary: The URL for the next standard.

      Just a quick announcemnt that a new standard example article has
      been released; it should is in the new USEFOR draft obtainable from
      ftp.ietf.org.
      Ann.

      --
      Ann Example <a.example@site1.example>   Sample Poster to the Stars
      "The opinions in this article are bloody good ones" - J. Clarke.

5.  Mandatory Headers

   An article MUST have either an A one, and only one, of each of the following
   headers: Date, From, Message-ID, Subject, Newsgroups, Path.

   Note also that there are situations, discussed in the relevant parts
   of section 6, where References, Sender, or MX
          record). See Approved headers are
   mandatory. In control messages, specific values are required for
   certain headers.

   For the Duties overall syntax of an Injection Agents headers, see section 7.1
          and RFC 2142.

5.6.5 Delimiter Summary

          A summary 4.1.  In the
   discussions of delimiters and the meaning they imply for individual headers, the
          name on content of each is
   specified using the right, or in addition, syntax notation. The convention used is that the name to
   content of, for example, the left.

          , Verified or generated identity.

          @ Name failed verification test. Name on left Subject header is identity
            generated defined as <Subject-
   content>.

   A proto-article (see 8.2.1) may lack some of these mandatory headers,
   but they MUST then be supplied by site further to the left.

          % Optional pre-injection entries followed by tail entry.
            Commonly just injecting agent.

5.1.  Date

   The Date header contains the tail entry, either "x" or an encoding
            of login identity. Name on left is FQDN of site date and time that
            handles mail for Injecting Agent. The presence of two "%"
            in a path indicates a double-injected error.

          ! Entry is unverified. Identity on left is an old-style
            system not conformant with this specification.

          Folding Whitespace MUST NOT be used as the sole delimiter.

          Other Treat as "!" as per RFC1036

          "/" Reserved for future use, treat as ","

          ; Semicolon is reserved article was
   prepared by the poster ready for transmission and SHOULD express the generation of extensible headers.

          :
   poster's local time. The colon is a valid delimiter for legacy systems, however,
            inside an IPv6 numeric address, surrounded content syntax makes use of syntax defined
   in square brackets,
            it [MESSFOR].

      Date-content        = date-time

        NOTE: It is a part of the path-identifier.

          _ This should not be treated as punctuation (a delimiter),
            contrary useful convention to RFC1036. Treat as part of identifiers.

5.6.6 Other formatting Issues

           The Path header MUST NOT be truncated.

           Whitespace MAY be present in follow the Path to make it easier to
           represent. However, there is no requirement to do so.
           Whitespace MUST not be used as a delimiter.

5.6.6.1 Use of "!"

           Old USENET relaying and injecting programs almost all delimit
           Path: entries date-time with a
        comment containing the "!" delimiter, and these entries are
           not verified. As such, the presence time zone in human-readable form. The use
        of "%" as folding in a delimiter
           will indicate the article was injected date-time is deprecated, even though permitted
        by software conforming [MESSFOR].

   In order to this standard, and prevent the presence reinjection of "!" as a delimiter will
           indicate expired articles into the message passed through systems developed prior
           to this standard. Prior to news
   stream, relaying and serving agents MUST refuse articles whose Date
   header predates the draft-implementation-date,
           messages with mixed sets earliest articles of delimiters will be common. After which they normally keep
   record, or which is more than 24 hours into the future (though they
                          News Article Format              February 2000

   MAY use a margin less than that date, all messages SHOULD 24 hours). Relaying agents MUST NOT have "!" delimiters prior
           to
   modify the "%" delimiter.

5.6.7 Suggested Verification Methods

          Sites attempting Date header in transit.

5.1.1.  Examples

      Date: Fri, 2 Apr 1999 20:20:51 -0500 (EST)
      Date: 26 May 1999 16:13 +0000

5.2.  From

   The From header contains the electronic address(es), and possibly the
   full name, of the article's author(s). The content syntax makes use
   of syntax defined in [MESSFOR], subject to verify an incoming entry SHOULD take the following approaches for common transports. They are not
          required, but not following them may lead revised
   definition of local-part.

      From-content        = mailbox-list
      addr-spec           = local-part "@" domain
      local-part          = dot-atom / strict-quoted-string

        NOTE: This syntax ensures that the local-part of an addr-spec is
        restricted to wasteful
          double-entry Path additions.

          If pure US-ASCII (and is thus in strict compliance
        with [MESSFOR]), whilst allowing any UTF-8 character to be used
        in a preceding quoted-string containing the incoming article arrives through author's full name.
        If some protocol local future extension to the site, such as UUCP, that protocol Mail protocols should relax this
        restriction, one would expect the Netnews protocols to follow.

   Any mailbox in the From-content MUST include a means belong to one of
          verifying the article source site, and this should match. In
          UUCP implementations, commonly each incoming connection has a
          unique login name and password; that login name could poster(s)
   of the article, or be used
          to build a suitable verified identifier.

          Here mailbox which he is authorized by its owner
   to use, or be an example of a suitable verification method for an
          article arriving via address which ends in the top level domain of
   ".invalid" [RFC 2606].

5.2.1.  Examples:

      From: John Smith <jsmith@site.example>
      From: "John Smith" <jsmith@site.example>, dave@isp.example
      From: "John D. Smith" <jsmith@site.example>, andrew@isp.example,
         fred@site2.example
      From: Jan Jones <jan@please_setup_your_system_correctly.invalid>
      From: Jan Jones <joe@guess-where.invalid>
      From: dave@isp.example (Dave Smith)

        NOTE: the last example shows a TCP/IP protocol such as via NNTP:

          1. If it is an encoding now deprecated convention of
        putting an IP address, it should be decoded
          into author's full name in a canonical form. If that address does not match comment following the
          source's IP,
        mailbox, rather than in a reverse-DNS (in-addr.arpa PTR record) lookup
          should be done on phrase at the provided address, followed by a regular
          DNS "A" record lookup on start of that mailbox.
        Observe that the returned name. That A record may
          contain several IP addresses. So long as one matches quotes around the IP
          address from "John D. Smith" example were
        required, on account of the path, '.' character, and another matches they would also
        have been required had any UTF8-xtra-char been present.

5.3.  Message-ID

   The Message-ID header contains the source IP
          address, this is considered a match.

          2. If it is article's message identifier, a internet DNS style FQDN, then
   unique identifier distinguishing the name should be
          looked up with DNS. article from every other
   article. The A records MUST contain an IP address
          that is the verified address content syntax makes use of syntax defined in [MESSFOR],
   subject to the source.

          3. (It should be noted following revised definition of no-fold-quote.

                          News Article Format              February 2000

      Message-ID-content = msg-id
      id-left            = dot-atom-text / no-fold-quote
      no-fold-quote      = DQUOTE *( strict-qtext / strict-quoted-pair )

           NOTE: This syntax ensures that when generating a name after a
          non-match, if an FQDN msg-id is desired, simply doing a reverse DNS
          (PTR) lookup on restricted to pure
           US-ASCII (and is thus in strict compliance with [MESSFOR]).

   Following the IP address provisions of [MESSFOR], an agent generating an
   article's message identifier MUST ensure that it is not sufficient to generate unique and that
   it is NEVER reused. Moreover, even though commonly derived from the FQDN.  The returned
   domain name must be mapped back to A records
          to assure it matches of the source's IP address.)

5.6.8 Issues

         There is no firm originating site (and domain names are case-
   insensitive), a message identifier MUST NOT be altered in any way to tell
   during transport, or when copied (as into a path entry generated by new
         software, References header), and one generated by old software assuming that any
         delimiter is valid.  However, use
   thus a simple (case-sensitive) comparison of "!" by octets will always
   suffice to recognise that same message identifier wherever it
   subsequently reappears.

        NOTE: some old software has
         become effectively universal.

         Sites are not strictly required to use a standard form for may treat message identifiers that
        differ only in case within their path entry, but if they don't, path lines out id-right part as equivalent,
        and implementors of agents that
         site get longer due to generate message identifiers
        should be aware of this.

5.4.  Subject

   The Subject header contains a short string identifying the adding topic of
   the identity. However,
         groups message. This is an inheritable header (4.2.2.2) to be copied
   into the Subject header of associated sites wanting a common identity may decide any followup, in which case the new
   header-content SHOULD then default to use that and let the receiver add string "Re: " (a "back
   reference") followed by the specific site.

6. Optional Headers

          The headers appearing contents of the pure-subject of the
   precursor. Any leading "Re: " in this section have established
          meanings. They the pure-subject MUST be interpreted according to the
          definitions made in this document. None of them are required to
          appear in every article. All of the headers appearing in this
          document stripped.

      Subject-content     = [ back-reference ] pure-subject
      pure-subject        = 1*( [FWS] utext )
      back-reference      = %x52.65.3A.20
                                    ; which is a case-sensitive "Re: "

   The pure-subject MUST NOT appear more than once begin with "Re: ".

        NOTE: The given syntax differs from that prescribed in an article.  Headers [MESSFOR]
        insofar as it does not appearing in this document (i.e. X-headers, headers defined
          by cooperating subnets) are exempt from this requirement. See
          "Responsibilities of Agents" for permit a clear picture.

6.1 Followup-To

          The Followup-To header contents specify  which  newsgroup(s)
          followups should content to be posted to:

               Followup-To-content = Newsgroups-content / "poster"

          The syntax is the same as that completely
        empty, or to consist of WSP only (see remarks in 4.2.5
        concerning undesirable headers).

   Followup agents MAY remove instances of non-standard back-reference
   (such as "Re(2): ", "Re:", "RE: ", or "Sv: ") from the Newsgroups content, with Subject-
   content when composing the exception that subject of a followup and add a correct
   back-reference in front of the magic word "poster" means result.

        NOTE: that
          followups should would be  mailed "SHOULD remove instances" except that we
        cannot find a sufficiently robust and simple algorithm to do the article's reply address
          rather than posted. In the absence
        necessary natural language processing.

                          News Article Format              February 2000

   Followup agents MUST NOT use any other string except "Re: " as a back
   reference. Specifically, a translation of Followup-To, the default
          newsgroup(s) for "Re: " into a followup are those in the Newsgroups header
          and local
   language or usage MUST NOT be used.

        NOTE: "Re" is an abbreviation for this reason the Followup-To header should not be
          included if it just duplicates the Newsgroups header.

6.2 Sender

	    The Sender header specifies Latin "In re", meaning "in
        the email address matter of", and not an abbreviation of the entity
	    which actually sent this article, if that entity "Reference" as is different
	    from the From header. This header
        sometimes erroneously supposed.

   Agents SHOULD NOT appear in an
          article unless the sender is different from depend on nor enforce the author. This
          header is appropriate for use of back references by automatic
   followup agents. For compatibility with legacy news software the
   Subject-content of a control message (i.e. an article posters.
          See [DRUMS] for

               Sender-content = mailbox-list

6.3 Expires

          The  Expires  header  content specifies that also
   contains a date Control header) MAY start with the string "cmsg ", and time when
   non-control messages MUST NOT start with the article string "cmsg ". See also
   section 6.11.

5.4.1.  Examples

   In the following examples, please note that only "Re: " is deemed mandated
   by this standard. "was: " is a convention used by many English-
   speaking posters to be no longer useful and signal a change in subject matter.  Software
   should be
          removed ("expired"). able to deduce this information from References.

      Subject: Film at 11
      Subject: Re: Film at 11
      Subject: Godwin's law considered harmful (was: Film at 11)
      Subject: Godwin's law (was: Film at 11)
      Subject: Re: Godwin's law (was: Film at 11)

5.5.  Newsgroups

   The Newsgroups header's content syntax is the same as that of
          the Date content specifies which is defined in newsgroup(s) the Message Format
          Standard [MESSFOR] .

               expires-content = date-time

          A Expires header SHOULD only be used in an
   article if the
          requested expiry time is earlier or later than posted to. It is an inheritable header (4.2.2.2) which
   SHOULD then become the default
          would normally be for that article. Local policy for each
          serving agent will dictate when this header is obeyed and
          authors SHOULD NOT depend on it being completely followed.

6.3. Reply-To

          The Reply-To Newsgroups header content specifies a reply address(es) to
          be used for personal replies for the author(s) of the article
          when this any followup,
   unless a Followup-To header is different from present to prescribe otherwise.

      Newsgroups-content  = newsgroup-name
                               *( *FWS ng-delim *FWS newsgroup-name )
                               *FWS
      newsgroup-name      = component *( "." component )
      component           = component-start
                               *( component-start / component-other )
      component-start     = Un-lowercase / Un-digit
      Un-lowercase        = <Unicode Letter, Lowercase> /
                            <Unicode Letter, Other>
      Un-digit            = <Unicode Number, Decimal Digit> /
                            <Unicode Number, Other>
      component-other     = "+" / "-" / "_"
      ng-delim            = ","
   where the author's address(es) given <Unicode ...> items are as described in
          the From header. [UNICODE].

   The format inclusion of the Reply-To header folding white space within a Newsgroups-content is defined a
   newly introduced feature in the Message this standard. It MUST be accepted by all
   conforming implementations (relaying agents, serving agents and
   reading agents).  Posting agents should be aware that such postings
                          News Article Format Standard [MESSFOR] .

          In the absence              February 2000

   may be rejected by overly-critical old-style relaying agents. When a
   sufficient number of Reply-To, the reply address(es) is the
          address(es) relaying agents are in the From header.  For this reason a Reply-To conformance, posting
   agents SHOULD NOT be included if it just duplicates generate such whitespace in the From header.

          Use form of a Reply-To header is preferable <CRLF WS> so as
   to including a similar
          request in keep the article body, because reply agents can take
          account length of Reply-To automatically.

          "Reply-To: <> " MAY be used to indicate that lines in the poster does
          not wish relevant headers (notably
   Newsgroups and Followup-To) to recieve email replies.

                Reply-To-content = From-content

6.3.1 Examples:

Reply-To: John Smith <jsmith@site.example>
Reply-To: John Smith <jsmith@site.example>, dave@isp.example
Reply-To: John Smith <jsmith@site.example>, andrew@isp.example,
   fred@site2.example
Reply-To: Please not not reply <>

6.4. References

          The References header content lists optionally CFWS-separated
          message ids of precursors. The format of the References header
          is defined in no more than than 79 characters (or
   other agreed policy limit - see 4.5).  Before such critical mass
   occurs, injecting agents MAY reformat such headers by removing
   whitespace inserted by the Message Format Standard [MESSFOR]. posting agent, but relaying agents MUST
   NOT do so.

   A followup newsgroup-name consists of one or more components. Components MAY
   contain non-ASCII letters, but these MUST have a References header, be encoded in UTF-8 and an article that
          is not a followup
   according to [RFC 2047].  A component MUST NOT have a References header. In a
          followup, if contain at least one
   letter (and MUST, according to the precursor did not have syntax, begin with a References header,
          the followup's References content MUST be formed letter or
   digit). Components SHOULD begin with a letter.  Composite characters
   (made by the
          message ID overlaying one character with another) and format
   characters, as allowed in certain parts of the precursor. A followup to an article which
          had a References header MUST have a References header
          containing the precursor's References content, plus the
          precursor's message ID appended Unicode and needed by
   certain languages, must use whatever canonical conventions apply to the end
   those parts of the list
          (separated from it by optional CFWS).

          Followup Agents SHOULD NOT trim message ids out of the
          References content unless the number Unicode (such conventions are not defined in this
   Standard). The use of message ids exceeds 31 "_" in which case message ids SHOULD be trimmed until there are
          only 31.

          Trimming SHOULD be done by removing a component is deprecated. Serving
   agents MAY refuse to accept newsgroups using such a component.

        NOTE: Components composed entirely of digits would cause
        problems for the sixth (6th) message-id
          and any incomplete or otherwise broken message-ids. If
          Followup Agents trim any message-ids out commonly used implementation technique of using
        the References
          content, then they MUST leave component as the first five and name of a directory, whilst also using
        sequential numbers to distinguish the last nine
          message ids articles within a group.
        Components containing other non-permitted characters could cause
        problems when newsgroup-names appear in URLs [RFC 1738] (for
        example an '@' character would prevent distinguishing between
        newsgroup-names and they SHOULD also leave any message ids
          mentioned in the body of the article intact. identifiers).

        NOTE: Software writers should be aware that According to the number of
          messages ids syntax, uppercase letters cannot occur in
        newsgroup-names, but this header may exceed 31 and standard imposes no requirement on
        software must be
          able to handle check this without problem.

                References-content = msg-id [msg-id...]

6.4.1 Examples:

References: <i4g587y@site1.example>
References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
References: <i4g587y@site1.example><kgb2231+ee@site2.example>
   <222@site1.example><87tfbyv@site7.example><67jimf@site666.example>
References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
   <tisjits@smeghead.example>

6.5. Control

          The Control header content marks the article as condition, since it would be unreasonable
        to expect it to do so in parts of Unicode for which it was not
        configured (in general, a control
          message, and specifies the desired actions (other than table lookup is required). Rather, it
        is the
          usual ones responsibility of filing and passing on the article):

          Control-content = verb *( FWS argument ) verb = 1*( ALPHA /
          DIGIT ) argument = 1* ftext

          The verb indicates what action should those creating new newsgroups (7.1) not
        to violate it. It is, moreover, to be taken, and the
          argument(s) (if any) supply details. In some cases, expected that a newsgroup
        created in violation of this condition will not be propagated
        particularly well.

   Whilst there is no longer any technical reason to limit the body length of
   a component (formerly, it was limited to 14 characters) nor to limit
   the article may total length of a newsgroup-name, it should be noted that these
   names are also contain details. The next section
          describes the standard verbs.

6.6. Control Messages

          The following sections document the group control messages.
          "Message" is used herein as a synonym in the newsgroups line (7.1.2) where an overall
   policy limit applies, and moreover excessively long names can be
   exceedingly inconvenient in practical use.  Agencies responsible for "article" unless
          context indicates otherwise.  Group control messages are
   individual hierarchies SHOULD therefore, as a
          special class matter of control messages, that request policy, set
   reasonable limits for the group
          configuration on length of a server be updated.

          All component and of a newsgroup-
   name. In the group control messages MUST have an Approved header
          (section 6.10). They SHOULD use one absence of such explicit policies, the authentication
          mechanisms defined in section TBD.

          The execution of default figures
   are 30 characters and 71 characters respectively.
[If the actions requested by control messages checkpolicies proposal is
          subject to local administrative restrictions, which MAY deny
          requests or refer them to an administrator for approval. The
          descriptions below are generally phrased included in terms suggesting
          mandatory actions, but any or all of these MAY the Standard, there should
be subject a reference to
          local administrative approval (either it here.]
                          News Article Format              February 2000

        NOTE: The newsgroup-name as a class or
          case-by-case). Analogously, where the description below
          specifies that a message or portion thereof is to encoded in UTF-8 should be ignored,
          this action MAY include reporting regarded
        as the canonical form. Reading agents may convert it to an administrator.

          Relaying Agents MUST propagate even control messages whatever
        character set they do
          not understand.

          In the following sections, each type of control message is
          defined syntactically by defining its arguments and its body.
          For example, "cancel" is defined by defining cancel-arguments are able to display (see 4.4.1) and cancel-body.

6.6.1 The "newgroup" Control Message

          newgroup-ctrl         = "newgroup" FWS groupname [ FWS flags ]
          flags                 = "moderated"
          groupname             ; defined in [NEWS]

          The "newgroup" control message requests the specified group be
          created or changed. The text "moderated" is appended serving
        agents may possibly need to mark
          the group convert it to some form more
        suitable as moderated. The message contains a
          "multipart/news-groupinfo" (section 6.6.1 body) part containing
          machine- and human-readable information about filename. Simple algorithms for both kinds of
        conversion are readily available.  Observe that the group.

          The newgroup command syntax does
        not allow comments within the Newsgroups header; this is also used to update
        simplify processing by relaying and serving agents which have a
        requirement to process this header extremely rapidly.

   Posters SHOULD use only the description
          line or moderation status names of a group.

          NOTE: It existing newsgroups in the
   Newsgroups header. However, it is also possible legitimate to send newgroups for existing
          groups that don't change anything cross-post to ensure the group
   newsgroup(s) which do not exist on
          all systems ("booster" newgroups). Implementations might want
          to test for this condition before attempting to update their
          configuration.

6.6.1.1 multipart/news-groupinfo

          The "multipart/news-groupinfo" body structure contains
          information about a (new) newsgroup.

          The MIME content type definition the posting agent's host, provided
   that at least one of "multipart/news-groupinfo"
          is:

          MIME type name:           multipart
          MIME subtype name:        news-groupinfo
          Required parameters:      boundary (see [MIME2])
          Optional parameters:      none
          Encoding considerations: "7bit" or "8bit" is sufficient the newsgroups DOES exist there, and
                                    MUST be used to maintain compatibility.
          Security considerations:  to be added

          A "multipart/news-groupinfo" body part contains followup
   agents SHOULD accept this (posting agents MAY accept it, but SHOULD
   at least alert the following
          subparts:

          1. An "application/news-groupinfo" part (section 6.6.1.2)
          containing poster to the name situation and description line request confirmation).
   Relaying agents MUST NOT rewrite Newsgroups headers in any way, even
   if some or all of the group(s). This
          part is mandatory.

          2. Other parts containing useful information about newsgroups do not exist on the relaying agent's
   host. Serving agents MUST NOT create new newsgroups simply because an
   unrecognised newsgroup-name occurs in a Newsgroups header (see 7.1
   for the
          backgrounds correct method of newsgroup message.

          3. Parts containing initial named articles creation).

   The Newsgroups header is intended for use in Netnews articles rather
   than in mail messages. It MAY be used in a mail message to indicate
   that it is a copy also posted to the
          newsgroup. See section 6.6.1.3 for details.

6.6.1.2 application/news-groupinfo

          The "application/news-groupinfo" body part contains listed newsgroups, but it SHOULD
   NOT be used in a short
          information on mail-only reply to a newsgroup, i.e. Netnews article (thus the group's name, it's
          description
   "inheritable" property of this header applies only to followups to a
   newsgroup, and not to followups to the moderation flag.

          NOTE: This part has poster). Moreover, if a format that makes
   newsgroup-name contains any non-ASCII character, it MAY be encoded
   using the whole
          "multipart/news-groupinfo" structure compatible with [1036BIS].

          The MIME content type definition of "application/news-groupinfo"
          is:

          MIME type name:            application
          MIME subtype name:         news-groupinfo
          Optional parameters:       none
          Encoding considerations:  "7bit" or "8bit" mechanism defined in [RFC 2047] when sent by mail but, if
   it is sufficient and
                                     MUST be used subsequently returned to maintain compatibility.
                                     Note that the descriptions may use [MIME3].
          Security considerations: to Netnews environment, it MUST then
   be added re-encoded into UTF-8.

5.5.1.  Forbidden newsgroup names

   The content following forms of newsgroup-name MUST NOT be used except for the "application/news-groupinfo" body part is
          defined as:

          groupinfo-body     = descriptor-tag CRLF 1*( description-line CRLF )
          descriptor-tag     = %x46.6F.72 SP %x79.6F.75.72 SP
                               %x6E.65.77.73.67.72.6F.75.70.73 SP
                               %x66.69.6C.6E.3A
                             ; case sensitive "For your
   specific purposes indicated:

     o Newsgroup-names having only one component. These are reserved for
       newsgroups file:"
         description-line    = newsgroup-name [ 1*WSP description ]
         description         = nonblank-text
         moderation-flags    = [ moderated-literal ]
         moderated-literal   = %x28.4D.6F.64.65.72.61.74.65.64.29
                                ; case sensitive "(Moderated)"

         The "application/news-groupinfo" whose propagation is used restricted to a single host or
       local network, and for pseudo-newsgroups such as "poster" (which
       has special meaning in conjunction with the
         "newgroup" (section 6.6.1) Followup-To header - see section 6.7),
       "junk" (often used by serving agents), "control" (likewise),
       "revise" and "mvgroup" control messages (section
         6.6.3) "repost" (which have special meanings in the Xref
       header - see 6.14)

     o Any newsgroup-name beginning with "control." (used as part of a "multipart/news-groupinfo" (section 6.6.1) MIME
         structure.

         Moderated pseudo-
       newsgroups MUST be marked by appending the case
         sensitive text " (Moderated)" at the end. It is NOT recommended
         that many serving agents)
     o Any newsgroup-name containing the moderator's email address be included in component "ctl" (likewise)
     o "to" or any newsgroup-name beginning with "to." (reserved for the description.

         Although,
       ihave/sendme protocol described in accordance with [NNTP], [MESSFOR] section 7.6, and 4.6 of this
	 document, a description line could have a maximum length of 998
	 octets, for test
       messages sent on an essentially point-to-point basis)
     o Any newsgroup-name containing the component "all" (because this
       is used as a matter of policy a far lower limit, expressed wildcard in
	 characters, some implementations)
                          News Article Format              February 2000

   A newsgroup-name SHOULD be set. By default, NOT appear more than once in the absence Newsgroups
   header. The order of
	 explicit policies, the description length SHOULD be limited newsgroup names in
	 such a way that the newsgroup name, Newsgroups header is not
   significant, except for determining which moderator to send the tab (interpreted as an
	 8-character tab that takes one at least
   article to column 24) and if one of the
	 description (excluding flags) fit groups is moderated (see 8.2).

5.6.  Path

   The Path header shows the route taken by a message since its entry
   into the first 79 characters.

         NOTE: Servers Netnews system. It is a variant header (4.2.2.4), each agent
   that use processes an "newsgroups" file will store article being required to add one (or more) entries
   to it. This is primarily to enable relaying agents to avoid sending
   articles to sites already known to have them, in particular the
         group descritpions there as is, i.e. without any conversion of
         charsets   or encoding.

         NOTE: The descriptions will also be used with site
   they came from, and additionally to permit tracing the [NNTP] LIST
         NEWSGROUPS command. The descriptions will be sent as is, i.e.
         without any conversion of charsets or encoding.

6.6.1.3 Initial Named Articles

         Some parts route articles
   take in moving over the network, and for gathering Usenet statistics.
   Finally the presence of a multipart/news-groupinfo structure MAY contain
         an initial set of named articles. These parts are identified by '%' delimiter in the Article-Name Path header just like normal named can be
   used to identify an article
         postings.  The named articles are filed separately as single
         postings, where injected in conformance with this
   standard.

5.6.1.  Format

      Path-content        = *( path-identity [FWS] delimiter [FWS] )
                               tail-entry *FWS
      path-identity       = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
      delimiter           = "/" / "?" / "%" / "," / "!"
      tail-entry          = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

        NOTE: A Path-content will inevitably contain at least one path-
        identity, except possibly in the headers case of a proto-article that
        has not yet been injected onto the enclosing control message
         are copied to every part network.

        NOTE: Observe that contains a named article except
         that:

         Content-* and Article-* headers MUST be taken from the body part.

         The message id MUST be changed by inserting /partX before syntax does not allow comments within the @
         sign, where X
        Path header; this is the number of the body part, starting with 0.
         The Control header of the enclosing message header MUST be
         stripped.  It MAY be replaced to simplify processing by relaying and
        injecting agents which have a "Control: named" header.
         Signatures (Auth, X-Auth...) of the enclosing message requirement to process this header
        extremely rapidly.

   A relaying agent SHOULD NOT pass an article to another relaying agent
   whose path-identity (or some known alias thereof) already appears in
   the Path-content. Since the comparison may be
         stripped.  They MAY be replaced by either case sensitive
   or case insensitive, relaying agents SHOULD NOT generate a signature name which
   differs from that of the another site only in terms of case.

   A relaying agent MAY decline to accept an article if its own site.

         The resulting path-
   identity is already present in the Path-content or if the Path-
   content contains some path-identity whose articles are for internal use of the server and its
         users only, they MUST NOT, repeat MUST NOT be forwarded to other
         sites.

         Nested multipart/* structures are allowed, they are relaying agent
   does not
         recursively expanded to separate articles.

6.6.2 The "rmgroup" Control Message

         rmgroup-ctrl  = "rmgroup" FWS groupname

         The "rmgroup" control message requests the specified group be
         removed from the list of valid groups. The Content-Type want, as a matter of the
         body is unspecified; it MAY contain anything, usually an
         explaining text. local policy.

        NOTE: It is also possible to send rmgroups for nonexisting,
         bogus groups to ensure the group This last facility is removed on all systems
         ("booster" rmgroups). Implementations might want to test for
         this before attempting sometimes used to update their configuration.

6.6.3 The "mvgroup" Control Message

         mvgroup-ctrl  = "mvgroup" FWS ( mvgrp-groups / mvgrp-hrchy)
         mvgrp-groups  = groupname [ FWS groupname ]
         mvgrp-hrchy   = groupnamepart ".*" FWS groupnamepart
         groupnamepart = groupname    ; syntactically

6.6.3.1 Single group

         The "mvgroup" detect and decline
        control message requests the first specified
         group messages (notably cancel messages) which have been
        deliberately seeded with a path-identity to be moved "aliased out" by
        sites not wishing to the second group. The message contains act upon them.

5.6.2.  Adding a
         "multipart/news-groupinfo" (section 6.6.1.2) body part containing
         machine- and human-readable information about path-identity to the new group. Path header
                          News Article Format              February 2000

   When this message is received, the new group SHOULD be created
         and all articles, including named articles, SHOULD be copied an injecting, relaying or
         moved serving agent receives an article, it
   MUST prepend its own path-identity followed by a delimiter to the new group, then
   beginning of the old, now empty group Path-content. In addition, it SHOULD be
         deleted.

         NOTE: For servers that use then add CRLF
   and WSP if it would otherwise result in a file system directory structure line longer than 79
   characters.

   The path-identity added MUST be unique to
         organize message storage, this operation is quite efficiently
         implemented as that agent. To this end it
   SHOULD be one of:

   1. A fully qualified domain name (FQDN) associated (by the Internet
      DNS service [RFC 1034]) with an A record, which SHOULD identify
      the actual machine prepending this path-identity. Ideally, this
      FQDN should also be "mailable" in the sense that it enables the
      construction of a single directory rename operation.

         If valid E-mail address of the old group does not exist, form "usenet@<FQDN>"
      or "news@<FQDN>" [RFC 2142] whereby the message is ignored unless administrators of that
      agent may be reached.

   2. A fully qualified domain name (FQDN) associated (by the new group does not exist either, in Internet
      DNS service) with an MX record which case MUST then enable the new
         group is created just as for
      construction of a "newgroup" message.

         An indication that valid E-mail address of the old group was replaced by form "usenet@<FQDN>"
      or "news@<FQDN>" whereby the new group
         MAY administrators of that agent may be left back
      reached.

   3. A name registered previously in the server's configuration and UUCP maps database (found in
      the newsgroup comp.mail.maps), containing no '.' character.

   4. An encoding of an IP address - <dotted-quad> [RFC 820] or <ipv6-
      numeric> [RFC 2373] (the requirement to be made
         available able to clients.

         NOTE: For servers that use an "active" file this means an entry
         in the form "oldgroup xxx yyy =newgroup" <ipv6-
      numeric> is created.

         NOTE: If the old group did not exist, this is considered reason for including ':' as an allowed character
      within a
         local configuration error. Therefore it is path-identity).

   5. A '.' followed by an arbitrary name not in the best UUCP maps database,
      but believed to correct
         this error when a mvgroup is received.

         If the old group does not exist, be unique and registered at least with all sites
      immediately downstream from the message is ignored unless given site.

   Of the new group does not exist either, in which case above options, nos. 1 to 3 are much to be preferred, unless
   there are strong technical reasons dictating otherwise. In
   particular, the new
         group is created just injecting agent's path-identity MUST, as for a "newgroup" message.

         If both groups exist, the groups MAY be "merged". If this is
         done, it MUST special
   case, be done correctly, i.e. implementations MUST take
         care that an FQDN mailable address in the messages sense defined under option
   1, or with an associated MX record as in option 2.

   The injecting agent's path-identity MUST be followed by the group being deleted are
         renumbered accordingly special
   delimiter '%' which serves to avoid overwriting articles in one
         group with those of separate the other pre-injection and that crossposted articles
         don't appear twice. Otherwise, post-
   injection regions of the old group is just deleted. Path-content (see 5.6.3).

   In all cases, information transported in the
         "multipart/news-groupinfo" body part is applied to case of a relaying or serving agent, the new group.

         Named articles are taken from delimiter is chosen
   as follows.  When such an agent receives an article, it MUST
   establish the mvgroup message, identity of the new
         group (if already existent) source and compare it with the old group in this
         precedence.

         As leftmost
   path-identity of the Path-content. If it matches, a special case, '/' should be
   used as the second name, i.e. delimiter when prepending the one of agent's own path-identity.
   If it does not match then the new
         group MAY be omitted. In this case, only agent should prepend two entries to the information
   Path-content; firstly the true established path-identity of the
         group is updated according
   source followed by a '?'  delimiter, and then, to the contained
         "multipart/news-groupinfo".

	 Until most relay agents conform to this document, whenever left of that,
   the agent's own path-identity followed by a mvgroup
       control message for a single group is issued, a corresponding pair '/' delimiter as usual.

                          News Article Format              February 2000

   This prepending of
       rmgroup and newgroup control messages two entries SHOULD NOT be issued a few days later.

6.6.3.2 Multiple Groups

         If done if the first name ends with provided and
   established identities match.

   Any method of establishing the character sequence ".*", identity of the
         newgroup message requests a whole (sub)hierarchy to source may be moved.
         The same procedure as for single groups (section 6.6.3.1) applies
         to every matched group; however, some systems might used
   (but see 5.6.5 below), with the consideration that, in the event of
   problems, the agent concerned may be able called upon to
         optimize the process. justify it.

        NOTE: For servers that The use a file system directory structure to
         organize message storage, this process can be optimized by
         renaming the parent directory instead of every group's
         directory.

         To avoid recursion, the new groups' names MUST NEVER match '%' delimiter marks the
         old groups name pattern; i.e. moving a whole (sub)hierarchy to
         a subhierarchy position of the original hierarchy is explicitly
         disallowed.

	 Until a critical mass of relay agents are
        injecting agent in compliance, whenever the chain. In normal circumstances there
        should therefore be only one `%` delimiter present, and
        injecting agents MAY choose to reject proto-articles with a mvgroup control message '%'
        already in them. If, for multiple groups whatever reason, more than one '%' is issued, a
       corresponding set
        found, then the path-identity in front of rmgroup and newgroup control messages for all the affected groups SHOULD leftmost '%' is to
        be issued a few days later.

6.6.4 The "checkgroups" Control Message regarded as the true injecting agent.

5.6.3.  The "checkgroups" control message contains a list of all valid
         groups tail-entry

   For historical reasons, the tail-entry (i.e. the rightmost entry in a complete hierarchy. The "Control:" header has
   the
         following format:

         checkgroup-ctrl = "checkgroups" [ FWS chkscope ] [ FWS chksernr ]
         chkscope        = 1*( ["!"] newsgroup-name-part )
         chksernr        = "#" 1*DIGIT

         The chkscope parameter(s) specifies the (sub)hierarchy(s) for
         which this "checkgroups" message applies.

6.6.4.1 Example:
Control: checkgroups de !de.alt #248

         NOTE: "Old" software Path-content) is known to ignore the "chkscope"
         parameter.  Thus regarded as a "checkgroups" message SHOULD also contain "user name", and therefore MUST
   NOT be interpreted as a site through which the groups of other subhierarchies article has already
   passed. Moreover, the sender Path-content is not
         responsible for. "New" software an E-mail address and MUST ignore groups which don't
         fall into the scope of
   NOT be used to contact the "checkgroups" message.

         If no scope for poster. Posting and/or injecting agents
   MAY place any string here. When it is not an actual user name, the checkgroups message
   string "not-for-mail" is given, it applies to
         all hierarchies for which group statements appear often used, but in the
         message.

         "Checkgroups" messages MAY also contain fact a serial number, which
         can simple "x" would
   be sufficient.

   Often this field will be any positive integer (i.e. just numbered or the date only entry in
         YYYYMMDD).  It SHOULD increase by an arbitrary value with every
         change the region (known as the
   pre-injection region) after the '%', although there may be entries
   corresponding to machines traversed between the group list posting agent and MUST NOT ever decrease.

         NOTE: This was added to circumvent security problems in
         situations where the Date header can not be signed.

         The body
   injecting agent proper. In particular, injecting agents that receive
   articles from many sources SHOULD include the identity of the message is an "application/news-checkgroups" part
         containing source
   machine connecting to do the list injection, and possibly other
   information enabling them to establish the circumstances of ALL valid groups (and MAYBE deletion
         confirmations) for the specified hierarchies.

6.6.5 application/news-checkgroups

         The "application/news-checkgroups" body part contains a complete
         list of all newsgroups in a top level hierarchy, their
         description lines and moderation status.
   injection (provided it does not conflict with any genuine site
   identifier). The MIME content type definition of
         "application/news-checkgroups:" is:

         MIME type name:           application
         MIME subtype name:        news-checkgroups
         Optional parameters:      none
         Encoding considerations:  "7bit" or "8bit" is sufficient and
                                   MUST '!'  delimiter may be used freely within the pre-
   injection region, although '/' and '?' are also appropriate if used
   correctly.
[If/when we invent some form of Injector-Info header, we may want to maintain compatibility.
                                   Note
revisit that paragraph.]

5.6.4.  Delimiter Summary

   A summary of the descriptions may use [MIME3].
         Security considerations: various delimiters. The name immediately to the left
   of the delimiter is always that of the machine which added the
   delimiter.

   '/' The name immediately to the right is known to be the identity of
       the machine from which the article was received (either because
       the entry was made by that machine and we have verified it, or
       because we have added it ourselves).

   '?' The content name immediately to the right is the claimed identity of the "application/news-checkgroups" body part
       machine from which the article was received, but we were unable
       to verify it (and have prepended our own view of where it came
                          News Article Format              February 2000

       from, and then a '/').

   '%' Everything to the right is
         defined as:

         checkgroups-body = *( invalidation CRLF ) 1*( valid-group CRLF )
         invalidation     = "!" groupname *( "," *WSP groupname )
         valid-group      = description-line
         description-line      ; see section 6.6.1.2 the pre-injection region followed by
       the tail-entry.  The "application/news-checkgroups" content type name on the left is used the FQDN of the
       injecting agent. The presence of two '%'s in
         conjunction with a path indicates a
       double-injection (see 8.2.2).

   '!' The name immediately to the "checkgroups" control message (section
         6.6.1.3.1).

6.6.5.1 Examples

         A "newgroup" with bilingual charter and policy information:

From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups,example.admin.announce
Date: 27 Feb 1997 12:50:22 +14:00 (EST)
Subject: Group example.admin.info created.
Approved: admin@example.invalid
Control: newgroup example.admin.info moderated
Message-ID: <newgroup-example.admin.info-19970227@example.invalid>
Content-Type: multipart/news-groupinfo; boundary="nxtprt"
Content-Transfer-Encoding: 8bit

This right is a MIME control message.
--nxtprt
Content-Type: application/news-groupinfo

For your newsgroups file:
example.admin.info Information on the example.* hierarchy <info@news.org>
(Moderated)

--nxtprt
Content-Type: multipart/alternative ;
differences = content-language ;
boundary = nxtlang
Article-Name: example.admin.info: charter

--nxtlang
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Language: en unverified. The group example.admin.info contains regularly posted information on
the example.* hierarchy.
--nxtlang
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Content-Language: de

Die Gruppe example.admin.info enthõlt regelmõ~Kig versandte
Informationen ³ber die example.*-Hierarchie.
--nxtlang--
--nxtprt--

plain "rmgroup":

From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups, example.admin.announce
Date: 4 Jul 1997 22:04 +02:00 (PST)
Subject: Deletion presence of example.admin.obsolete
Message-ID: <rmgroup-example.admin.obsolete-19970730@example.invalid>
Approved: admin@example.invalid
Control: rmgroup example.admin.obsolete

The group example.admin.obsolete is obsolete. Please remove it from
your system.

plain "mvgroup":

From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 +02:00 (CEST)
Subject: Moving example.oldgroup to example.newgroup
Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid>
Approved: admin@example.invalid
Control: mvgroup example.oldgroup example.newgroup
Content-Type: multipart/news-groupinfo; boundary=nxt

--nxt
Content-Type: application/newgroupinfo

For your newsgroups file:
example.newgroup The new replacement group.
--nxt

The group example.oldgroup is replaced by example.newgroup.
Please update your configuration.
--nxt--

more complex "mvgroup" for
       a whole hierarchy:

The charter '!' to the left of the group example.talk.jokes contained a reference '%' indicates that the identity to
example.talk.jokes.d, which is also being moved. So the charter
       left is
updated.

From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 +02:00 (PST)
Subject: Deletion that of example.admin.obsolete
Message-ID: <mvgroup-example.talk-19970730@example.invalid>
Approved: admin@example.invalid
Control: mvgroup example.talk.* example.conversation
Content-Type: multipart/news-groupinfo; boundary=nxt; chartas=1

--nxt
Content-Type: application/newgroupinfo

For your newsgroups file:
example.conversation.boring Boring conversations.
example.conversation.interesting Interesting conversations.
example.conversation.jokes Jokes and funny stuff.
example.conversation.jokes.d Discussion about example.conversation.jokes.

Article-Name: example.conversation.jokes: charter

This group is to publish jokes and other funny stuff.
Discussions about the articles posted here an old-style system not conformant with this
       standard.

   ',' Reserved for future use, treat as '/'.

   Other
       Old software may possibly use other delimiters, which should be redirected
to example.conversation.jokes.d; adding a Followup-to: header
is recommended.
--nxt--

6.6.6 Cancel

         The cancel message requests
       treated as '!'.  But note in particular that one or more target articles be
         "canceled" ie be withdrawn from circulation or access. This
         message MAY be issued by entities which processed the target
         article(s) while it was still a proto-article (ie posters,
         posting agents, moderators ':', '-' and injecting agent. See also
         Gateways[2.1] ). Other entities '_' are
       components of names, not delimiters, and FWS on its own MUST NOT use this method to
         remove articles.

         NOTE: A separate method for other entities to cancel articles
         will
       be defined in a later draft.

               cancel-arguments  = 1*( message-id CFWS )
               cancel-body       = body

         The argument(s) identify used as the article(s) to be cancelled, by
         message-id.  The body SHOULD contain an indication sole delimiter.

        NOTE: Old Netnews relaying and injecting programs almost all
        delimit Path entries with the '!' delimiter, and these entries
        are not verified. As such, the presence of why '%' as a delimiter
        will indicate that the
         cancellation article was requested. The cancel message SHOULD be posted injected by software
        conforming to this standard, and the same newsgroup(s), with the same distribution(s), presence of '!' as the
         article(s) it is attempting to cancel.

         In order for a cancel message
        delimiter to remove an article either:

         1. The mailing addresses from the From line left of a '%' will indicate that the cancel message and the target article match and the target article
        passed through systems developed prior to this standard. It is
         otherwise unauthenticated.

         2. At least one authentication method of the target article
         MUST be matched by
        anticipated that relaying agents will reject articles in the cancel message plus old
        style once this new standard has been widely adopted.

5.6.5.  Suggested Verification Methods

   The following approaches for common transports are suggested in order
   to meet a site's verification obligations. They are not required, but
   following them should avoid the mailing addresses
         from necessity for wasteful double-entry
   Path additions.

   If the From line incoming article arrives through some TCP/IP protocol such as
   NNTP, the IP address of the cancel message source will be known, and the target article
         MAY match.

         NOTE: The Sender, From will likely
   already have been checked against a list of known FQDNs or Approved headers MUST NOT be used as
         an "authentication method" within IP
   addresses that the meaning receiving site has agreed to peer with (this will
   have involved a DNS lookup of a known FQDN, following CNAME chains as
   required, to find an A record containing that source IP).

   1. Where the previous
         paragraph.  If path-identity is an FQDN (or even an arbitrary name
      starting with a '.') it is now a simple matter to check that it is
      the above conditions are satisfied then proper FQDN for the
         relaying source, or serving agent SHOULD delete some known registered alias
      thereof. Alternatively, where the target article
         completely and immediately (or at FQDN in the minimum make path-identity has an
      associated A record, an immediate DNS lookup as above can be used
      to verify it.

   2. Where the article
         unavailable for relaying or serving) and also SHOULD reject any
         copies path-identity is an encoding of this article that appear. See also section 7 on
         duties of Serving and Relaying agents.

6.6.7 ihave, sendme

        The  ihave  and  sendme  control  messages implement a crude
        batched predecessor an IP address which does
      not immediately match the known IP address of the NNTP [rrr]  protocol. They are
        largely obsolete  in source, a
      reverse-DNS (in-addr.arpa PTR record) lookup may be done on the Internet, but still see use in
                          News Article Format              February 2000

      provided address, followed by a regular DNS "A" record lookup on
      the UUCP
        environment, especially returned name. There may be A records for backup feeds that  normally are
        active only when a primary feed path has failed.

        NOTE:  The  ihave and sendme messages defined here have
        ABSOLUTELY NOTHING TO DO WITH  NNTP,  despite similarities several IP
      addresses, of
        terminology.

        The two messages share the same syntax:

               ihave-arguments   = *( message-id space ) relayer-name
               sendme-arguments  = ihave-arguments
               ihave-body        = *( message-id CRLF )
               sendme-body       = ihave-body

        Message IDs MUST appear in either which one should match the arguments or path-identity and another
      should match the body, but
        NOT both.  Relayers SHOULD  generate source.

   3. If the  form  putting message
        IDs  in path-identity fails to match any known alias for the  body, but source
      (requiring the other form MUST be supported insertion of an extra path-identity for
        backward compatibility.

        The ihave message states that the named relaying agent has
        received articles with true
      source followed by a '?'), simply doing a reverse DNS (PTR) lookup
      on the specified message IDs, which may be
        of interest source IP address is not sufficient to generate the relaying agents receiving the ihave message. true
      FQDN. The sendme message requests that the agent receiving returned name must be mapped back to A records to assure
      it send
        the articles having matches the specified message IDs to source's IP address.

   If the named
        relaying agent.

        These control messages are normally sent essentially incoming article arrives through some other protocol, such as
        point-to-point messages, by using "to." newsgroups (see section
        5.5.1)
   UUCP, that are sent only to the relaying agent the messages are
        intended  for.  The two relaying agents protocol MUST be neighbors,
        exchanging news directly with each other.  Each relaying agent
        advertises its new arrivals to include a means of verifying the other using ihave messages,
        and source
   site. In UUCP implementations, commonly each uses sendme messages to request the articles it lacks.

        To reduce overhead, ihave incoming connection has
   a unique login name and sendme messages SHOULD be sent
        relatively  infrequently password, and SHOULD that login name (or some alias
   registered for it) would be expected as the path-identity.
[The above description may still contain reasonable numbers
        of message IDs.  If ihave and sendme are being used more detail that we would wish.
My aim so far was to implement retain everything in Brad's original, but expressed
in a  backup  feed, more palatable manner. We can now decide how much of it we want to
keep.]

5.6.6.  Example

      Path: foo.isp.example/
         .foo-server/bar.isp.example?10.123.12.2/old.site.example!
         barbaz/baz.isp.example%dialup123.baz.isp.example!x

        NOTE: That article was injected into the news stream by
        baz.isp.example (complaints may be desirable addressed to insert a delay between
        reception of an  ihave  and generation of a sendme, so
        usenet@baz.isp.example). The injector has taken care to record
        that it got it from dialup123.baz.isp.example. "x" is the
        default tail entry, though sometimes a
        slightly slow primary feed will not cause large numbers of
        articles to be requested unnecessarily via sendme.

6.6.8 Obsolete control messages. real userid is put there.

        The following forms of control messages are declared obsolete article was relayed, perhaps by this document:

          sendsys
          version
          whogets
          senduuname

6.7. Distribution

6.7.1 Historical Note

        The original Distribution header provided a means UUCP, to limit the distribution of articles to a subset of machine known
        in the sites which
        received UUCP maps database as "barbaz".

        Barbaz relayed it to old.site.example, which does not yet
        conform to this standard (hence the newsgroups '!' delimiter). So one
        cannot be sure that it really came from barbaz.

        Old.site.example relayed it was posted to.  It was designed to control a feed.  Each site feeding other sites would, for
        each feed, configure claiming to have the list of distributions appropriate IP
        address [10.123.12.2], and claiming (by using the '/' delimiter)
        to send have verified that it came from old.site.example.

        [10.123.12.2] relayed it to ".foo-server" which, not being
        convinced that site.  If an article had it truly came from [10.123.12.2], did a Distribution
        header, reverse
        lookup on the actual source and concluded it was known as
        bar.isp.example (that is not to say that [10.123.12.2] was not a check would
        correct IP address for bar.isp.example, but simply that that
        connection could not be made substantiated by .foo-server).  Observe
        that .foo-server has now added two entries to see if any of the
        distributions in the header matched the distribution list
        for the feed.

        Sadly, this list was often configured in Path.

                          News Article Format              February 2000

        ".foo-server" is a locally significant name (observe the form "all
        distributions except
        presence of the following" where '.')  within the local
        distributions would be listed.

        This mean an unknown distribution, leaked from an external
        site, would match complex site of many machines
        run by foo.isp.example, so the "all distributions" latter should have no problem
        recognizing .foo-server and get fed out.
        This meant that once an article leaked out from using a
        distribution's subnet, it flooded the entire net, or at
        least '/' delimiter.  Presumably
        foo.isp.example then delivered the very large subset article to its direct
        clients.

        It appears that used "all but these" style
        of configuring the feed.

        Indeed, many sites deliberately wanted this flood.  Hub
        sites at national foo.isp.example and multinational ISPs wanted old.site.example decided to receive
        all the local distributions, for the use of their users in
        the individual geographic regions.  This assured netwide
        propagation of all distributions, defeating
        fold the purpose of line, on the header.  It became close grounds that it seemed to valueless.

6.7.1.1 New Semantics

        While distributions SHOULD still control feeds as they do,
        they SHOULD also be associated with the site.  Each site
        SHOULD maintain getting a list of the distributions
        little too long.

6.  Optional Headers

   The headers appearing in this section have established meanings and
   MUST be interpreted according to which it is a
        "member."  Newsreaders SHOULD also allow the user to
        maintain a list definitions given here. None of distributions
   them is required to which appear in every article but some of them are
   required in certain types of article, such as followups. Any header
   defined in this (or any other) standard MUST NOT appear more than
   once in an article unless specifically stated otherwise.
   Experimental headers (4.2.2.1) and headers defined by cooperating
   subnets are exempt from this requirement.  See section 8 "Duties of
   Various Agents" for the user is full picture.

6.1.  Reply-To

   The Reply-To header specifies a
        member.

        Newsreaders MAY also keep track reply address(es) to be used for
   personal replies for the author(s) of distributions the user
        wishes to belong to.  In article when this event, they should examine is
   different from the
        Distribution headers author's address(es) given in the From header. The
   content syntax makes use of articles to be presented syntax defined in [MESSFOR], but subject
   to the
        user, and revised definition of local-part given in section 5.2.

      Reply-To-content    = From-content  ; see 5.2

   In the absence of Reply-To, the reply address(es) is the address(es)
   in the From header. For this reason a Reply-To SHOULD not display them NOT be included
   if it just duplicates the user does not
        belong to any From header.

        NOTE: Use of a Reply-To header is preferable to including a
        similar request in the distributions named.

6.7.1.2 Planned Uses

        Distributions article body, because reply agents can now
        take account of Reply-To automatically.

   An address of "<>" in the Reply-To header MAY be used to define rigid subsets of the
        net indicate
   that sites can "subscribe" to.  For example, say a party
        wishes to issue 3rd party cancel messages that delete spam
        or net abuse at sites which the poster does not wish to listen to that
        canceller.  These messages would now be posted to a specific
        distribution.  They might still reach recieve email replies.

6.1.1.  Examples

      Reply-To: John Smith <jsmith@site.example>
      Reply-To: John Smith <jsmith@site.example>, dave@isp.example
      Reply-To: John Smith <jsmith@site.example>,andrew@isp.example,
         fred@site2.example
      Reply-To: Please do not reply <>
                          News Article Format              February 2000

6.2.  Sender

   The Sender header specifies the entire net, and
        would make it to hubs, but they would only have effect at
        sites which explicitly took membership in mailbox of the distribution,
        even without authentication.

        However, as these might be very high volume messages --
        especially entity which actually
   sent this article, if there are many such 3rd party cancel services
        -- it remains possible for sites to ask their feeders to not
        even feed articles that entity is different from that given in this distribution, thus making the
        system efficient.

6.7.2 Definition

          The Distribution
   From header specifies geographical or
          organizational limits to an article's propagation:

          Distribution-content = distribution *( dist-delim distribution)
          dist-delim = ","
          distribution = positive-distribution / negative-distribution
          positive-distribution = *FWS distribution-name *FWS
          negative-distribution = *FWS "!" distribution-name *FWS
          distribution-name = 1*letter

          [That is if more restrictive than Henry, omitting '+', '-' and
          '_', but more liberal in allowing uppercase letters, which in
          fact are commonly used, and one address appears in not specifying any 14 character
          limit.]

          A distribution is case-insensitive (i.e. "US", "Us" and "us"
          all specify the same distribution). In the absence of a
          Distribution header, the default Distribution-content is
          "world". However, "world" From header.
   This header SHOULD NOT be explicitly mentioned appear in an article unless a negative-distribution the sender is also present, as in
          Distribution: world, !us "All" MUST NOT be used as a
          distribution-name.

          Articles MUST NOT be passed between relaying agents unless the
          sending agent has been configured to supply and the receiving
          agent has requested to receive BOTH of (a) at least one of the
          newsgroups in
   different from the article's Newsgroups header, and (b) at
          least one author. This header is appropriate for use by
   automatic article posters. The content syntax makes use of the positive-distributions syntax
   defined in the article's
          Distribution [MESSFOR].

      Sender-content      = mailbox

6.3.  Organization

   The Organization header and none of the negative-distributions.
          Exceptionally, ALL relaying agents are deemed willing to
          supply or accept the distribution "world", and NO relaying
          agent should supply or accept is a short phrase identifying the distribution "local". author's
   organization.

      Organization-content= 1*( [FWS] utext )

        NOTE: Posting and injecting  agents SHOULD NOT provide are discouraged from
        providing a default Distribution value for this header without giving the poster an opportunity unless it is
        acceptable to override
          it. Followup agents SHOULD initially supply the same
          Distribution all posters using those agents. Unless this header as found in the precursor.

          All the two-letter country names (e.g. "us") commonly used as
          top-level domain names may be used as distributions, but
        contains useful information (including some indication of the
          common non-country top-level domain names (such as "edu" and
          "com") are NOT distributions, moreover top-level
          newsgroup-names (such as "comp" and "soc")
        authors physical location) posters are NOT
          distributions. Apart discouraged from the above, distribution-names are a
          matter for negotiation between the relaying agents or
          cooperating subnets involved.

6.8.
        including it.

6.4.  Keywords

   The Keywords field contains a comma separated list of important words
   and phrases intended to describe some aspect of the content of the
   article. The format content syntax makes use of the Keywords
          header is syntax defined in the Message Format Standard [MESSFOR] . [MESSFOR].

      Keywords-content    = phrase *( "," phrase )

        NOTE: The list is comma seperated separated NOT space seperated.

6.9. separated.

6.5.  Summary

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

            summary-content

      Summary-content     =  non-blank-text CRLF
            non-blank-text = 1*(FWS text) 1*( [FWS] utext )

   The summary SHOULD be terse. Authors SHOULD avoid trying to cram
   their entire article into the headers; even the simplest query
   usually benefits from a sentence or two of elaboration and context,
   and not all reading agents display all headers. On the other hand the
   summary should give more detail than the Subject.

6.10. Approved

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

          Approved-content = From-content

          An Approved

6.6.  Distribution

   The Distribution header is required in all postings to moderated
          newsgroups. If this an inheritable header is not present then (see 4.2.2.2) which
   specifies geographical or organizational limits to an article's
   propagation.

                          News Article Format              February 2000

      Distribution-content= distribution *( dist-delim distribution )
      dist-delim          = ","
      distribution        = positive-distribution /
                               negative-distribution
      positive-distribution
                          = *FWS distribution-name *FWS
      negative-distribution
                          = *FWS "!" distribution-name *FWS
      distribution-name   = letter 1*distribution-rest
      distribution-rest   = letter / "+" / "-" / "_"

   Articles MUST NOT be passed between relaying and agents or to serving
   agents MUST reject unless the article.

          An Approved header is also required in certain control
          messages, sending agent has been configured to reduce supply and the probability of accidental posting
   receiving agent to receive BOTH of
          same; see the relevant parts
       (a) at least one of section 6.6.

          Please see section 7.1 on how injecting agents should treat
          posts to moderated groups that do not contain this header.

6.11 Lines

          The Lines header content indicates the number of lines newsgroups in the
          body article's Newsgroups
       header, and
       (b) at least one of the article:

          Lines-content = 1*digit

          The line count includes all body lines, including the
          signature if any, including empty lines positive-distributions (if any) at beginning
          or end of the body. (The single empty separator line between in the headers
       article's Distribution header and none of the body is negative-
       distributions.
   Additionally, reading agents MAY be configured so that unwanted
   distributions do not part get displayed.

        NOTE: Although it would seem redundant to filter out unwanted
        distributions at both ends of a relaying link (and it is clearly
        more efficient to do so at the body) . The "body"
          here is the body as found in the posted article as transmitted
          by the posting agent.

          Software SHOULD NOT use the value of Lines for any purpose other
          than sending end), many sending sites
        have been reluctant, historically speaking, to display an estimate apply such
        filters (except to humans. This header will be
          deprecated in a future RFC.

6.12 Xref

          The Xref header content indicates where ensure that distributions local to their own
        site or cooperating subnet did not escape); moreover they tended
        to configure their filters on an article was filed
          by the last server "all but those listed" basis,
        so that new and hitherto unheard of distributions would not be
        caught. Indeed many "hub" sites actually wanted to process it:

               Xref-content = server 1*( CFWS location )
               server = server-name
               location = newsgroup-name ":" article-locator
               article-locator  = 1*

          The serving agent's name is included receive all
        possible distributions 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 they could feed on to their
        clients in the Newsgroups header) and
          where all possible geographical (or organizational)
        regions.

        Therefore, it was filed under them. The exact form of an article
          locator is implementation-specific.

          NOTE: The traditional form desirable to provide facilities for rejecting
        unwanted distributions at the receiving end. Indeed, it may be
        simpler to do so locally than to inform each sending site of an article locator
        what is a decimal
          number, with articles required, especially in each newsgroup numbered consecutively
          starting from 1.  NNTP demands that the case of specialized
        distributions (for example for control messages, such a model be
          provided, and there may be other software as cancels
        from certain issuers) which expects it,
          but it seems desirable might need to permit flexibility be added at short
        notice.  Tha possibility for unorthodox
          implementations.

          An agent inserting an Xref header into an article MUST delete
          any previous Xref header(s). A relaying agent MUST only create
          and/or relay an Xref header if it correct on all the receiving reading agents to filter
        distributions has been provided for the article is forwarded to. Serving same reason.

   Exceptionally, ALL relaying agents SHOULD
          insert this header unless the information in it (apart from are deemed willing to supply or
   accept the serving name) is correct in which case it should be left
          unchanged.

          An distribution "world", and NO relaying agent MUST use should supply
   or accept the same name in Xref headers as distribution "local".  However, "world" SHOULD NEVER be
   mentioned explicitly since it uses in
          Path headers.

6.13 Organization

          The Organization is the default when the Distribution
   header content is absent entirely.  "All" MUST NOT be used as a short phrase identifying
   distribution-name.  Distribution-names SHOULD contain at least three
   characters, except when they are two-letter country names as in [ISO
   3166].  Distribution-names are case-insensitive (i.e. "US", "Us" and
   "us" all specify the author's organization:

          organization-content = nonblank-text CRLF same distribution).

                          News Article Format              February 2000

        NOTE: "Distribution: !us" can be used to cause an article to go
        to the whole of "world" except for "us".

   Posting and injection agents are discouraged from
          providing SHOULD NOT provide a default value for this Distribution header unless it is
          acceptable
   without giving the poster an opportunity to all posters using these agents. Unless this override it. Followup
   agents SHOULD initially supply the same Distribution header contains useful information ( including some indication
          of as found
   in the authors physical location) posters are discouraged from
          including it.

6.14 User-Agent precursor.

6.7.  Followup-To

   The User-Agent Followup-To header contains information about the user
          agent (typically a newsreader) generating the article. This specifies which newsgroup(s) followups should
   be posted to.

      Followup-To-content = Newsgroups-content / "poster"

   The syntax is
          for statistical purposes and tracing the same as that of standards violations
          to specific software needing correction. Although OPTIONAL,
          user agents SHOULD include this header the Newsgroups-content, with the articles they
          generate.

          The field MAY contain multiple product tokens and comments
          identifying
   exception that the agent and any subproducts which form a
          significant part magic word "poster" is allowed. In the absence of
   a Followup-To header, the user agent such as external agents
          used default newsgroup(s) for message composition, separated injecting agents (such
          as those used by offline newsreaders), and significant
          libraries that are part of such agents. The products a followup are
          listed
   those in order of their significance for identifying the
          application, not necessarily in chronological order of
          handling prior to injection. Injecting agents MAY include
          product information Newsgroups header, and for servers (such as INN/1.7.2), but
          servers MUST NOT generate or modify this reason the Followup-To
   header to list
          themselves.

          User-Agent MUST NOT be modified after injection, but MAY be
          stripped or have its contents replaced prior to re-injection
          by another user agent such as an anonymizing gateway.

          User-Agent = "User-Agent:" SP User-Agent-content
          User-Agent-content = product *(CFWS product) [CFWS]

          At least one product MUST be present. The first token MUST SHOULD NOT be a comment. Comments relate to included if it just duplicates the previously named product,
          not Newsgroups
   header.

   A Followup-To header consisting of the product following it.

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

          Product tokens should magic word "poster" indicates
   that the author requests no followups to be short and sent in response to this
   article, only personal replies to the point -- they MUST
          NOT be used for information beyond the canonical name article's reply address.

6.8.  References

   The References header lists optionally CFWS-separated message
   identifiers of the
          product and it's version. Although any token character MAY
          appear in a product-version, this token SHOULD be used only
          for a version identifier (i.e., successive versions precursors. The content syntax makes use of the
          same product SHOULD differ only syntax
   defined in [MESSFOR].

      References-content  = msg-id *( CFWS msg-id )

        NOTE: This differs from the product-version portion syntax of [MESSFOR] by requiring at
        least one CFWS between the product value). Product tokens msg-ids (this was an [RFC 1036]
        requirement).

   A followup MUST identify products.

          NOTE: Variations from RFC 1945:

          1. product token is required have a References header, and an article that is not
   a followup MUST NOT have a References header. In a followup, if the
   precursor did not have a References header, the followup's
   References-content MUST be first,

          2. use of other text in formed by the syntactic usage message identifier of the product
          token
   precursor. A followup to an article which is not had a token is forbidden,

          3. comment allows quoted-pair,

          4. "{" and "}" are allowed in token (product and
          product-version) in news,

          5. octets from character sets other than ASCII are allowed.

          NOTE: Comments should be restricted to information regarding References header
   MUST have a References header containing the product named precursor's References-
   content (subject to their left such as platform information
          and should be concise. Use trimming as an advertising medium (in described below) plus the
          mundane sense) is discouraged.

          Recipients precursor's
   message identifier appended to the end of header field TEXT containing octets outside the
          US-ASCII character set may assume that they represent UTF-8
          characters.

          NOTE: Variation list (separated from RFC 1945: UTF-8 replaced ISO-8859-1 as
          charset assumption.

6.14.1 Examples:

User-Agent: tin/1.2-PL2
User-Agent: tin/1.3-950621beta-PL0 (Unix)
User-Agent: tin/unoff-1.3-BETA-970813 (UNIX) (Linux/2.0.30 (i486))
User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486))
User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712)
User-Agent: Microsoft-Internet-News/4.70.1161
User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest")
User-Agent: Pluto/1.05h (RISC-OS/3.1) NewsHound/1.30
User-Agent: inn/1.7.2
User-Agent: inews
User-Agent: telnet

          NOTE: Some current web proxy applications append their product
          information to the list in the User-Agent field. This is not
          recommended on the web and is forbidden for news, since it
          makes machine interpretation
   by CFWS).

   Followup agents SHOULD NOT trim message identifiers out of these fields ambiguous.
          User-Agent is not intended to be a total audit trail
   References header unless the number of what
          software has handled message identifiers exceeds
   21, at which time trimming SHOULD be done by removing sufficient
   identifiers starting with the article.

          NOTE: Some existing web clients fail to restrict themselves second so as to bring the product token syntax within the User-Agent field when
          using this header on the web. Such abuses are forbidden for
          news.

          NOTE: This total down to
   21. However, it would be wrong to assume that References headers
   containing more than 21 message identifiers will not occur.

                          News Article Format              February 2000

6.8.1.  Examples

      References: <i4g587y@site1.example>
      References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
      References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
         <222@site1.example> <87tfbyv@site7.example>
         <67jimf@site666.example>
      References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
         <tisjits@smeghead.example>

6.9.  Expires

   The  Expires  header supersedes specifies a date and time when the role performed redundantly by
          "X-" headers such as X-Newsreader, X-Mailer, X-Posting-Agent,
          X-Http-User-Agent, article is
   deemed to be no longer relevant and other headers previously used on USENET
          for this purpose. Use of these "X-" headers SHOULD  could usefully  be
          discontinued in favor removed
   ("expired"). The content syntax makes use of the single, standard User-Agent syntax defined in
   [MESSFOR].

      Expires-content     = date-time

   An Expires header which is to should only be used freely both in news and mail.

          NOTE: There are slight changes to an article if the original HTTP defined
          format to requested
   expiry time is earlier or later than the User-Agent header as noted, but headers in
          strict, common-sense compliance with RFC 1945 are compliant time typically to be
   expected for such articles. Local policy for each serving agent will
   dictate whether and when this specification. The syntax from RFC 1945 header is preferred,
          including the requirement that products obeyed and comments be
          separated by authors SHOULD NOT
   depend on it being completely followed.

6.10.  Archive

   This optional header is a space.

6.15 MIME headers

6.15.1 Syntax signal to automatic archival agents on
   whether this article is available for long-term storage.

      Archive-content     = [CFWS] ("no" | "yes" ) [CFWS]
      Archive-header-parameter
                          = Filename-token "=" value
                            ; for USENET-header-parameters see 4.1
      Filename-token      = [CFWS] "filename" [CFWS]

   Agents which see "Archive: no" MUST NOT keep the article past the
   Expires date. "Archive: yes" merely confirms what is already the
   default state. The following headers, as defined within [RFC-2045] and its
        extensions, may optional Filename parameter MAY then be used within articles conforming to this
        Document.

             MIME-Version:
             Content-Type:
             Content-Transfer-Encoding:
             Content-ID:
             Content-Description:
             Content-Disposition:
             Content-MD5:

        Insofar as
   suggest a filename under which the syntax article should be archived.
   Further extensions to this standard may provide additional parameters
   for these headers, administration of the archiving process.

6.11.  Control

   The Control header marks the article as given in [RFC-
        2045], does not specify precisely where whitespace a control message, and
        comments may occur (whether in
   specifies the form desired actions (other than the usual ones of WS, FWS or CFWS), storing
   and/or relaying the usage article).

      Control-content     = CONTROL-verb CONTROL-argument
      CONTROL-verb        = <the verb defined in this Document, and failing that standard
                               (or an extension of it) for a specific
                               CONTROL message>
      verb                = token
                          News Article Format              February 2000

      CONTROL-arguments   = <the argument defined in
        [MESSFOR], and failing this standard
                               (or an extension of it) for a specific
                               CONTROL message>
      arguments           = *( CFWS value )  ; see 4.1
[Observe that in [RFC-822] MUST <value> reqires the use of a quoted-string if any
tspecials or NON-ASCII characters are involved. This is a restriction on
present usage, but follows Mime practice.]

   The verb indicates what action should be followed. taken, and the argument(s)
   (if any) supply details. In
        particular, there some cases, the body of the article may
   also contain details. Section 7 describes all of the standard verbs.

   An article with a Control header MUST NOT be any WS between also have a header-name and Replaces or
   Supersedes header.

        NOTE: The presence of a Subject header starting with the following colon string
        "cmsg " and there followed by a Control-content MUST NOT be construed,
        in the absence of a SPACE following proper Control header, as a request to
        perform that
        colon. control action (as may have occurred in some legacy
        software). See also section 5.4.

6.12.  Approved

   The meaning Approved header indicates the mailing addresses (and possibly the
   full names) of the various MIME headers is as defined in [RFC-
        2045] and [RFC-2046], and in extensions registered in
        accordance with [RFC-2048]. However, their usage is restricted
        as described in persons or entities approving the following sections.

6.15.2 Content-Transfer-Encoding

        Posting agents SHOULD specify "Content-Transfer-Encoding:
        8bit" article for all articles not written
   posting.

      Approved-content    = From-content  ; see 5.2

   Each mailbox contained in pure ASCII and not
        requiring full binary. They MAY use "8bit" encoding even when
        "7bit" encoding would have sufficed. They SHOULD specify
        "base64" when the content type implies binary (i.e. content
        intended for machine, rather than human, consumption).

        NOTE: If a future extension to Approved-content MUST be that of the MIME standards were
   person or entity in question, and one of those mailboxes MUST be that
   of the actual injector of the article.
[This is the start of an attempt to
        provide strengthen this header. It should be
a more compact encoding TOSSable offence to put a dummy or invalid address in here. Later,
when we have some form of binary suited authentication, I would hope to transport
        over an 8bit channel, it could be considered as an alternative able to base64 once it had gained widespread acceptance.

        Posting agents SHOULD NOT specify encoding "quoted-printable",
        but reading agents MUST interpret that encoding correctly.
        Encoding "binary" MUST NOT be used (except say
more.]

   An Approved header is required in closed networks
        with alternative transport arrangements) because all postings to moderated
   newsgroups. If this Document
        does header is not mandate a transport mechanism that could support it.

        Injecting and present in such postings, then
   relaying and serving agents MUST NOT change reject the encoding of
        articles passed article. Please see
   section 8.2.2 for how injecting agents should treat postings to them. Gateways SHOULD ONLY change the
        encoding if absolutely necessary.

6.15.3 Content-Type

        There exist many content types which, whilst being technically
        unexceptionable, are politically undesirable. It is therefore
        anticipated
   moderated groups that agencies having the proper authority will, as
        a matter of policy, place restrictions upon the content types do not contain this header.

   An Approved header is also required in certain control messages, to be used within particular hierarchies or particular groups.
        In
   reduce the absence risk of such explicit policies, accidental posting of same; see the following
        defaults are provided as an indication relevant parts
   of section 7.

6.13.  Replaces / Supersedes

   These two headers contain one or more message identifiers that the
   current best
        practice.

        The Content-Type: "text/plain" article is the default type for any
        news article. Other text types (such as "HTML") are thus
        inappropriate unless and until policy expected to replace or custom has
        established otherwise.

        In the event that such other text types do get used then, supersede. All listed
   articles MUST be treated as though a "cancel" control message had
   arrived for the benefit article (but observe that a site MAY choose not to
                          News Article Format              February 2000

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

6.13.1.  Syntax and Semantics

   The  Replaces and Supersedes headers specify articles to be cancelled
   on arrival of readers who this one. The content syntax makes use of syntax
   defined in [MESSFOR].

      Replaces-content    = msg-id *( CFWS msg-id )
      Replaces-header-parameter
                          = Usage-token "=" Usage-value
                            ; for USENET-header-parameters see it only 4.1
      Usage-token         = [CFWS] "usage" [CFWS]
      Usage-value         = [CFWS] ("replace" / "revise" / "repost" )
                               [CFWS]
      Supersedes-content  = msg-id

        NOTE: There is no "c" in its transmitted
        form, "Supersedes".
[I could be persuaded of a better token than "usage". I did wonder about
"disposition". Observe that "usage" is also now used also in
message/news-transmission.]

   If an article contains a Replaces header, then the material old articles
   mentioned SHOULD simply be "pretty-printed" so deleted by the serving agent, as in a
   cancel message (7.5), and the new article inserted into the system as to keep it
        (including
   any sequences which control other new article would be.

   A Replaces-header-parameter is only meaningful when it occurs within
   a Replaces-content. If its layout Usage-value is "revise" or style)
        within "repost" (or if
   the recommendations and limits on line lengths set out
        in section 4.6, and so as to keep such sequences, as far as Replaces-header-parameter is
        possible, separate from absent, then by default) reading
   agents SHOULD NOT show the meaningful text.

        Content-Types requiring special processing for their display,
        such article as "application", "image", "audio", "video" and
        "multipart/related" are deprecated an "unread" article unless the
   replaced article(s) were themselves all unread, except in groups
        specifically intended (by policy when the
   reader has configured his reading agent otherwise.

   Moreover, if a Usage-value is "revise" or custom) to "repost", serving agents
   that generate a local Xref header MUST then include them.
        Exceptionally, those application types defined additional
   "revise" or "repost" information as set out in [RFC-2015]
        and elsewhere for use within "multipart/signed" articles, and
        the type "application/pgp-keys" (or other similar types
        containing digital certificates) may section 6.14.

        NOTE: A replacement with "usage=replace" is intended to be used freely.

        Reading agents SHOULD NOT, unless explicitly configured
        otherwise, act automatically on Application types which could
        change the state of that agent (e.g. by writing or modifying
        files), except
        in the case of those prescribed for use in
        control messages (6.5).

        The Content-Type "message/partial" MAY be used to split a long
        news an article into several smaller ones, but this usage that is
        deprecated on the grounds sufficiently different from
        its predecessors that modern transport agents should
        have no difficulty in handling articles of arbitrary length.

        IF this feature it is used, then the "id" parameter SHOULD advisable for readers to see it
        again.  A replacement with "usage=revise" is intended to be used
        in the form case of a unique message-id (but different from minor change, unworthy of being brought to the
        Message-ID
        attention of any a reader who has already read one of the parts).  Contrary its
        predecessors. A replacement with "usage=repost" is intended to the requirements
        specified in [RFC-2046], the Transfer-Encoding SHOULD
        be set
        to 8bit at least used in each part that requires it.  The second
        and subsequent parts SHOULD contain References headers
        referring the case of an article identical to all the previous parts, thus enabling reading
        agents with threading capabilities to present them in the
        correct order. Reading agents MAY then provide a facility to
        recombine the parts into a single article one replaced
        (but this document
        does not require them to do so).

        The Content-Type "message/external-body" could be apropriate
        for texts which it would be uneconomic (in view of possibly being reposted because the earlier one had likely
        readership) to distribute
        expired).

        NOTE: A reader who elects to ignore all the entire network.

        The Content-Type: "multipart/mixed" (also
        "multipart/parallel") may be used freely articles available
        in news articles.

        By default, the use of the Content-Type:
        "multipart/alternative" is deprecated (on account of the extra
        bandwidth consumed and a newsgroup (perhaps on the difficulty occasion of quoting in
        followups).

        The Content-Type: "multipart/digest" is commended accessing that
        newsgroup for any
        article composed of multiple messages more conveniently viewed the first time) will likely have them all marked
        as separate entities. The "boundary" should be composed of 28
        hyphens (ASCII 45) (which makes each boundary delimiter 30
        hyphens, or 32 for "already read", unless the final one) so reading agent provides a distinct
                          News Article Format              February 2000

        mark such as "never offered". This could lead to accord a later
        replacement with current
        practice "revise" or "repost" for digests [RFC-1153].
[Actually, this conflicts one of those articles
        being missed.

   The Supersedes header is obsolescent, is provided only for
   compatibility with some present digest usage (such as the
news.answers rules), but should still existing software, and may be the right way to go. I
suggest removed entirely in
   some future version of this standard. Its meaning is left in for now (just to stake a claim), while we
discuss the matter same as that
   of a corresponding Replaces header with the news.answers moderators its Replaces-header-parameter
   set to "usage=replace", and the faq-
maintainers.]

        The Content-Type: "multipart/signed" [RFC-1847, RFC-2015] whenever a Supersedes header is provided
   a matching Replaces header SHOULD be provided as well. Observe that
   the preferred method Supersedes header makes provision for only a single msg-id.

   Until the bodies of news articles that are
        to Replaces header has become widely implemented, software
   SHOULD generate Replaces headers with only one msg-id, and cancel
   control messages SHOULD be digitally signed.  However, encryption (as in
        "multipart/encrypted") is deprecated.

6.15.4 Character Sets

        In principle, issued if needed for further identifiers.
   Moreover, until that time, any character set may article containing a Replaces header
   SHOULD contain also a Supersedes header (or alternatively be specified in
   accompanied by a Control cancel message) for that same msg-id, to
   ensure that older systems still at least remove the
        "charset=" parameter of predecessor.

   When a content type. However, character
        sets other than "us-ascii", "iso-8859-1" (and message contains both a Replaces and a Supersedes header they
   MUST be for the
        corresponding parts of UTF-8) ought only same msg-id.  Furthermore, to be used in
        hierarchies where resolve any doubt, the language customarily used so requires
        (and whose readers could
   Replaces header shall be expected to possess agents capable
        of displaying them).

6.15.5 Definition of some new Content-Types

        This document defines (or redefines) several new Content-
        Types, which require deemed to be registered with IANA as provided
        for in [RFC-2048]. For "multipart/news-groupinfo" see 6.6.1.1,
        for "application/news-groupinfo" see 6.6.1.2, for
        "application/news-checkgroups" see 6.6.5, and take priority.

   Whatever security or authentication mechanisms are required for the
        remainder see this present section.

6.15.5.1 Application/news-transmission

        The Content-Type "application/news-transmission" is intended a
   Control cancel message MUST also be required for an article with a
   Replaces or Supersedes header. In the encapsulation absence or failure of complete news articles where the
        intention is that such
   checks, the recipient should then inject them into
        Netnews. This Application type article SHOULD be used when mailing
        articles discarded, or at most stored as an
   ordinary article.
[We can write something more constructive in here as soon as the
situation with regard to moderators cancel-locks and signed headers has been
clarified.]

6.13.2.  Message-ID version procedure

   Whilst this procedure is not essential for the operation of Netnews,
   it SHOULD be supported by all serving agents. However, for the
   procedure to mail-to-news gateways.
[The remarks work, all the msg-ids in the Replaces-content MUST be
   those of successive replacements of the same original article, and
   all be generated as described below.
[Whilst the procedure about sending articles to moderators should perhaps be
made in described will undoubtedly work, it
must be pointed out that life would be much simpler if there was only a more appropriate place
single msg-id allowed in our standard.]

        NOTE: The benefit of such encapsulation is that it removes
        possible conflict between news and email headers and it
        provides a convenient way Replaces-content.]

6.13.2.1.  Message version numbers

   According to [MESSFOR], and omitting the obsolete forms, the syntax
   of the left hand side of "tunnelling" a news article
        through msg-id (the part before the "@") is given
   by:

      id-left-side        = dot-atom-text / no-fold-quote
                          News Article Format              February 2000

   Consider this to be replaced by:

      id-left-side        = ( atom-text / no-fold-quote )
                               *( dollars-sequence )
      dollars-sequence    = version-number / random-dollars-sequence
      version-number      = "$" %d118 "=" 1*DIGIT ; $v=digits
      random-dollars-sequence
                          = "$" 1*atom-text

   Whilst this is admittedly ambiguous ("$" is already a transport medium that possible value
   of atom-text) and does not support 8bit
        characters.

        The MIME content type definition of "application/news-
        transmission" is:

        MIME type name:           application
        MIME subtype name:        news-transmission
        Required parameters:      none
        Optional parameters:      moderate; inject; relay
        Encoding considerations:  A transfer-encoding (such in fact change what is allowable as
                                  Quoted-Printable or Base64) different
                                  from an
   id-left-side, it does serve to allow dollars-sequences such as
   version-number (and any others that of the article transmitted
                                  MAY may be supplied (perhaps en route) added by extensions to
   this standard) to
                                  ensure correct transmission over some
                                  7bit transport medium.
        Security considerations:  A news article may be distinguished within a "control
                                  message", message identifier and
   utilized by agents which could have effects on
                                  the recipient host's system beyond
                                  just storage of the article. However,
                                  such control messages also can understand them.  Observe that no-fold-
   quotes cannot occur in
                                  normal news flow, so most hosts will
                                  already be suitably defended against
                                  undesired effects.
        Published specification:  [USEFOR]
        Body part:                A complete article or proto-article,
                                  ready for injection into Netnews, or within a
                                  batch of such articles.

        NOTE: It is likely dollars-sequence.

   Posters and/or posting agents when replacing (or superseding)
   articles SHOULD arrange that the recipient of an
        "application/news-transmission" will be a specialised gateway
        (e.g. a moderator's submission address) able to accept
        articles with only one message identifier of the three parameter types
        "moderate", "inject" and "relay", hence
   replacement follows the reason why they following convention, generating what are optional, being redundant in most situations.
        Nevertheless, they MAY be used
   known as "version-number" message identifiers. This is to signify enable the originator's
        intention with regard
   new version of the article to be retrieved by its original message
   identifier, notably when it occurs in a URL of the transmission, so removing any
        possible doubt.

        When form
   <news:message-identifier> [RFC 1738].

   1. If the parameter "relay" id-left-side of the most recent predecessor's message
      identifier contains a leftmost version-number "$v=<n>", where <n>
      is used, an integer version number, possibly followed by one or implied, more
      random-dollars-sequences, the body part
        MAY replacement message identifier
      should be obtained by replacing the <n> with the integer <n+1> and
      providing a batch different random-dollars-sequence(s). For example
      <foo$v=3$XYZ@faq-site.example> becomes <foo$v=4$PQR@faq-
      site.example>.

   2. If the id-left-side of articles to be transmitted together, in
        which case the following syntax MUST be used.

        batch        = 1*( batch-header article )
        batch-header = "#!" SPACE "rnews" SPACE article-size CRLF
        article-size = 1*digit

        where the "rnews" is case-sensitive. Thus a batch is predecessor's message identifier does
      not contain a
        sequence of articles, each prefixed version-number, the replacement message identifier
      should be obtained by appending the string "$v=1", preferably
      followed by a header line random-dollars-sequence(s), to that
        includes its size. id-left-side.
      For example <foo@faq-site.example> becomes <foo$v=1$ABC@faq-
      site.example>.

   Any random-dollars-sequence so added MUST NOT start with "$<l>=" for
   any letter <l>.

        NOTE: The article-size is a decimal count of the
        octets in the article, counting each CRLF as one octet
        regardless presence of how it is actually represented.

        NOTE: Despite a random-dollars-sequence following the similarity of this format to an executable
        UNIX script, it
        version-number is EXTREMELY unwise intended to feed such a batch into
        a command interpreter in anticipation of it running prevent a command
        named "rnews"; malicious poster from
        preempting the security implications posting of so doing would be
        disastrous.

6.15.5.2 Application/news-message
[WARNING: The application/mews-message type as described here has been
subject to much adverse criticism. Thus it is liable a replacement article by guessing its
        likely message identifier.

   Attempts to be fetch a replaced (or superseded) article by
an alternative method of encapsulation in its message
   identifier SHOULD retrieve instead its most recent successor which
   has used the version-number convention. Some indication that a future draft of this
document.]

        The Content-Type "application/news-message" newer
   version than was asked for has been delivered SHOULD be provided.
   This is intended for
        the encapsulation of complete news articles which have already to ensure that "news:" URLs [RFC-1738] will continue
                          News Article Format              February 2000

   to work even when an article has been posted replaced, but agents SHOULD
   then draw attention to Netnews and which are for the information of fact that the recipient, message identifier retrieved
   differed from that requested.

6.13.2.2.  Implementation and do not constitute a request to repost them.
        This Message type SHOULD be used when a courtesy copy Use Note

[Here is the implementation technique that we discussed, based on the
use of a
        followup conventional History file. This is mailed a sanity check for our own
use, not intended to go in the author final text.

1. Ensure that the implementation of its precursor, DBZ is not upset if the same key is
attempted to be stored a second time, and when
        gatewaying from news-to-mail.

        NOTE: The benefits of that such encapsulation are
        a) a key always
retrieves the latest record indexed by that it will be apparent key.

2. Additions to the recipient that what he sees
        is a copy of History file are always made at the end. Removals or
changes to existing entries are only made by the expire program. An
entry for a news Replaced (or otherwise cancelled) article rather than an original email;
        b) that it will survive tramsmission intact even when remain until,
first, the
        transport medium does not support 8bit characters and has expire program removes the links to
        employ some special Content-Transfer-Encoding;
        c) likewise, that UTF-8 characters in headers will survive
        transmission;
        c) likewise, the articles that any digital signature applied are no
longer stored, and later on removes the entire entry according to it its
expiry date. For every entry containing a '$v=n' followed by random-
dollars-sequences there will
        survive tramsmission intact.

        The MIME content type definition be an immediately following entry identical
but for the omission of "application/news-message"
        is:

        MIME type name:           application
        MIME subtype name:        news-message
        Required parameters:      none
        Optional parameters:      none
        Encoding considerations:  A transfer-encoding (such as
                                  Quoted-Printable or Base64) different
                                  from that '$v=n' and of the article transmitted
                                  MAY random-dollars-sequences.
Thus there may be supplied (perhaps en route) several entries with identical message-ids but,
because of the change to
                                  ensure correct transmission over some
                                  7bit transport medium.
        Disposition:              By default, presentation agents SHOULD
                                  display news-messages inline, DBZ just described, only the most recent will
ever be seen except
                                  where overriden by a
                                  Content-Disposition header.
        Published specification:  [USEFOR]
        Body part:                A complete news article, as already
                                  injected into Netnews.

6.15.5.3 Message/news obsoleted
[WARNING: In view pf the possible withdrawal of the proposed
application/news-message (see above), it should not be assumed programs that access the obsoletion of message/news will necessarily remain in future
drafts of this document.]

        The Content-Type "message/news", as previously registered with
        IANA, History file directly,
rather than by its index.

3. When an article is hereby obsoleted and should be withdrawn. The reason Replaced, at the same time as the successor
article is that, according to RFC-2045, it entered into the History file, with '$v=7' say, a duplicate
entry (same article list) is expressly forbidden for entered under the same key, modified by
removing any "message" type to use leftmost '$v=n' and the following random-dollars-sequences
from it.

4. Provide a transfer-encoding other than
        "7bit", "8bit" or "binary", thus preventing call to a news article
        which makes full use of UTF-8 characters in its headers, or
        which uses (as routine which, if asked to retrieve any message
identifier with '$v=n' and finding it SHOULD) "8bit" as missing (or rather linked to no
stored groups), immediately tries again without the '$v=n' and its own transfer-encoding,
        from being passed through a 7bit transport medium (recall that
        it is not permitted by
random-dollars-sequences.  NOTE. We don't want this document for the transfer-encoding
        of a news behaviour when
checking whether we already have an article offered to us by IHAVE, only
in response to an ARTICLE command. So this needs to be changed).

6.15.6 MIME within headers

        Since the headers of news articles are expected an extra call in
DBZ, in addition to use the
        UTF-8 character set, they SHOULD NOT normally 'fetch' or 'dbzfetch' calls, to be encoded using
        the MIME mechanism defined used in [RFC-2047]. Nevertheless,
        reading agents SHOULD support the
proposed extension to the NNTP ARTICLE command. Observe that usage.

        It if the
requested '$v=n' is present and linked to stored articles (for whatever
reason) then you will be noted, however, given exactly that RFC-2047 encoding would be
        required were a news article to be transmitted as a mail
        message without first encapsulating it as an
        "application/news-message" version, even if later ones
are stored as suggested above.

6.16 Supersedes / Replaces

          These two headers take a list well.

5. NOTE that I have dropped the idea of message-ids (msgid-list) having '$v=0', because you can
never be sure that the current article is expected very first issue of the FAQ used it, so you have
to replace or supersede. All
          listed articles MUST be treated provide the versionless root as though a "cancel" control
          message had arrived well. If someone asks for '$v=0' (or
any '$v=n') the message, except as detailed below.

          These headers are essentially synonyms, with a change in
          behavior - Replaces uses algorithm I gave will still find it via the old article's message-id for root. So we
don't care what people put in URLs.

6. You are supposed to cancel the more recently arrived article, rather than creating a
          new replaced/superseded article.

          The  Supersedes header content specifies articles If you
REALLY want to be
          cancelled on arrival of this one:

               Supersedes-content = message-id *( FWS message-id )

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

          Older software supported only Supersedes, and with only one
          Message-ID. Software MUST be aware of the possibility that keep the new-style of Supersedes may old ones around a little longer, then this
implementation will not be interpreted correctly,
          and MAY wish work if you want the latest to generate Supersedes with only one Message-ID,
          and cancel control messages SHOULD be issued if needed for other
          IDs, until such time as retrieved
                          News Article Format              February 2000

automatically - you will have to invent something much more complicated.

7. Having said all that, here follows a critical mass brief account of compliant relay agents
          exists.

          If the header is "Replaces" the new successor article SHOULD
          effectively over-write the predecessor(s) so that any attempt same thing,
but short enough to read them shows the successor. Newsreaders should not show
          the article as an "unread" article unless the replaced
          articles were themselves all unread. A be included in our document (the convention being
that implementation issues are hinted at, rather than being described in
full detail).]

   Typically, a news database will index a Replacement is
          considered article both by
   its "version-number" message identifier (containing a minor change, unworthy of being brought to "$v=" tag
   followed by a random-dollars-sequence) and by its "root" version
   (without the
          attention of "$v=" tag or any following random-dollars-sequence).
   Thus when a person who read one of request for an article comes in that is not present under
   the predecessors.
          Newsreaders version-number requested, any article that is present and database systems MAY provide access indexed
   by the corresponding root version can be retrieved instead. The
   indexing mechanism needs to
          predecessors of articles if they wish, but this should not be
          part of such that, although the course of normal newsreading, and root version
   may have at times referred to many different articles, it is in fact
          discouraged.

          Systems MAY treat Replaces as a synonym for Supersedes, if
          they do not implement always
   the semantics latest that is retrieved.

        NOTE: The presence of Replaces.

          If a version-number in the message identifier
        of an article without a Replaces or Supersedes header causes no
        extra action (it is "Supersedes" then just an ordinary article). Observe also that
        if an article with the old articles SHOULD
          simply be deleted, as in exact message identifier (even though it
        contains a cancel, and version-number) is, for whatever reason, already
        present on the new serving agent, that article
          inserted into will always be
        retrieved in preference to the system like one indexed by any new article.

          Attempts root version.

6.13.2.3.  The Message-Version NNTP extension

   The following Service Extension to fetch a replaced or superseded article either by
          number or by Message-ID SHOULD retrieve instead the most
          recent successor. Some indication that a newer version than
          was asked for has been delivered MAY be provided. It is
          particularly encouraged that NNTP servers implement delivery
          of successor upon requests by message-IDs so that WWW "news:"
          and "msg:" URLs continue to work even when an article has a
          successor.

          It protocol is expected that "Replaces" will become defined in
   accordance with the common header
          for routine article changes framework set out in [NNTP], and corrections, with Supersedes
          used for periodic postings (possibly every N periodic
          postings) or updates that make major changes is to an article.

          As be
   registered with a cancel, systems MUST NOT delete or replace articles
          unless the poster IANA.

   Name of the successor is authorized to cancel extension:                             Message-Version
   Extension Label (for the
          predecessor.

6.16.1 Message-ID version numbers chain procedure.

NOTE: Sections 6.16.1 - 6.16.4 may be published as LIST EXTENSIONS command): MESSAGE-VERSION
   Additional keywords, syntax and parameters:        None

   In a separate
      recommendations document.

          Tools superseding or replacing messages should arrange so that server supporting this extension, the Message-ID behaviour of a replacement follows the following set of
          rules, generating what are known ARTICLE,
   HEAD, BODY and STAT commands when the parameter is a <message-id> is
   modified as "version-number"
          Message-IDs.

           1. follows.

   If the Local-Part of specified article is available on the predecessor's Message-ID ends server then it (or its
   Head, Body or Status as appropriate) is returned in
           "%v=<n>", the normal
   manner.  Otherwise, if a leftmost id-left-side of the <message-id>
   (the part before the '@') contains "$v=<n>", where <n> is an integer
   version number, that "$v=<n>"and everything following it is stripped
   from that id-left-side and the new
           message-ID should replace the <n> article (Head, Body or Status) with
   the integer <n+1>.

Example:
Message-ID <foo%v=3@example.invalid> stripped <message-id> is replaced by
<foo%v=4@example.invalid>.

           2. returned instead.  Otherwise (no article
   is available under the original, or any stripped, <message-id>), a
   430 response is given as usual.

        NOTE: If the Local-Part of client is concerned to know whether the predecessor's Message-ID does not
           end in "%v=<n>", then article
        found was exactly the string "%v=1" should be appended one requested or a replacement article
        corresponding to
           the Local-Part a stripped <message-id>, then it has only to generate
        compare the successor Message-ID.

Example:
Message-ID <foo@example.invalid> is replaced by
<foo%v=1@example.invalid>.

6.16.2 Implementation and Use Note

          Typically a news database will store a "pointer" of some sort
          between replaced/superseded articles and their immediate
          successor or most recent successor. Such pointers may be
          expired along <message-id> requested with other records that returned in a news system's message-id
          lookup database. In addition, if a "version-number" Message-ID
          is found, and the "root" version (without the "%v=" tag, 220
                          News Article Format              February 2000

        (221, 222, or
          with a "%v=0" tag) 223) response. The intent of this extension is not present on the server, a pointer
          from that root to
        enable the most recent successor SHOULD also be
          stored, and kept so long as there is a current successor in
          the system. (Systems should check for both root forms, trying
          the "%v=0" form first, and retrieval of the tagless form 2nd.)

          Thus when a request for current version of an article comes in that is not
          present (due to superseding or replacement) (such
        as a check can be
          made for regularly posted FAQ) referenced by a pointer record for that Message-ID, or failing
          that, if "news:" URL [RFC-
        1738] which quotes the ID <message-id> of an earlier version.

        NOTE: This extension has a version-number, for a pointer record for
          the root versionless ID. Such pointers can be followed to no effect on the
          most recent successor.

6.16.3 Transition

          Until a sufficient percentage IHAVE command.

6.13.2.4.  Examples

   Example 1. The first edition of relay agents a FAQ is compliant, posted with a message may contain both
   identifier of the form:  <examplegroup-faq@faq-site.example>. The
   next (but identical) version, a Replaces field and month later, has:

      Message-ID: <examplegroup-faq$v=1$A1b@faq-site.example>
      Replaces: <examplegroup-faq@faq-site.example> ; usage=repost
      Supersedes: <examplegroup-faq@faq-site.example>
   Observe the inclusion of a Supersedes field.
          This MUST be treated header as a Replaces, with the Supersedes added
          to assure well, it being
   presumed that older systems still at least remove the predecessor.

6.16.4 Replaced-by

          This Replaces header takes a message-id as argument.

          If there is a need to support older systems which only understand
          a single ID in Supersedes by use of a simple Cancel control message,
          then such control messages may contain a "Replaced-by" header
          indicating the Message-ID of the successor the message that was
          cancelled. Systems maintaining pointers from predecessors to
          successors should use this record to update their pointers.

          Note this header goes only on the cancel control message, not
          the successor. The successor should have a Replaces and/or
          Supersedes listing the most immediate predecessor.

6.16.5.1 Examples

          The first edition of an FAQ is posted with a Message-ID of the
          form: <examplegroup-faq@example.invalid>. The next version, a week
          later, has:

Message-ID:     <examplegroup-faq%v=1@example.invalid>
Supersedes:     <examplegroup-faq@example.invalid> yet widely implemented at
   that time.

   The next one, another week month later (and with some significant changes
   justifying the use of "replace" rather than "repost") has:

      Message-ID:     <examplegroup-faq%v=2@example.invalid> <examplegroup-faq$v=2$B2b@faq-site.example>
      Replaces: <examplegroup-faq$v=1$A1b@faq-site.example>
         <examplegroup-faq@faq-site.example> ; usage=replace
      Supersedes:     <examplegroup-faq%v=1@example.invalid>
<examplegroup-faq@faqsite.com> <examplegroup-faq$v=1$A1b@faq-site.example>

   The next one, another week later month later, has:

      Message-ID:     <examplegroup-faq%v=3@example.invalid> <examplegroup-faq$v=3$C3c@faq-site.example>
      Replaces: <examplegroup-faq$v=2$B2b@faq-site.example>
         <examplegroup-faq$v=1$A1b@faq-site.example> ; usage=repost
      Supersedes:     <examplegroup-faq%v=2@example.invalid>
<examplegroup-faq@example.invalid> <examplegroup-faq$v=2$B2b@faq-site.example>

   Note that the long spacing between issues means only reason to include more than one message identifier
   in the
          multi-entry Supersedes Replaces is there primarily to preserve pointer
          records at sites not using in case a site had missed the version-number system for
          message-ids. previous
   Replacement. It is hardly necessary with such a long interval between
   the postings.

   Under the above, requests for the root (original) message-ID
          will return the most recent FAQ. On on systems using the version-number system (which is
   optional) requests for any
          Message-ID message identifier in the chain will
   always return the most recent, for all
          time. recent. As such the URL "news:groupname-faq@faqsite.com" "news:examplegroup-
   faq@faq-site.example" will always work, making it suitable to appear
   in HTML.

6.16.5.2 HTML documents.

   Example 2. A user posts a message <myuniquepart@mysite.com> <myuniquepart@mysite.example> to
   the net.  She notices a typo, and typo and, 2 minutes later, posts with:

      Message-ID:     <myuniquepart%v=1@example.invalid> <myuniquepart$v=1$xxx@mysite.example>
      Replaces:       <myuniquepart@example.invalid> <myuniquepart@mysite.example> ; usage=revise
                          News Article Format              February 2000

   3 minutes later she sees another typo, and posts:

      Message-ID:     <myuniquepart%v=2@example.invalid> <myuniquepart$v=2$yyy@mysite.example>
      Replaces:       <myuniquepart%v=1@example.invalid>
<myuniquepart@example.invalid> <myuniquepart$v=1$xxx@mysite.example>
         <myuniquepart@mysite.example> ; usage=revise

   The two bad versions will be replaced with the 3rd, even if a site
   never sees the 2nd due to batching or feed problems, and
          requests problems (thus the use of
   two message identifiers is quite useful in this case, in
   contradistinction to the first example). Requests for the original
   will return the 3rd.

          During transition, she adds a Supersedes

6.14.  Xref

   The Xref header to the 3rd
          message, with the first (direct predecessor) ID. She issues is a
          Cancel message as well:

Control: cancel <myuniquepart@example.invalid> Replaced-by:
<myuniquepart%v=2@example.invalid>

6.16.7 Issues

          [No syntax for the internals of message-ids has been declared
          on local header (4.2.2.3) which indicates where an
   article was filed by the net. However, there last server to process it, and whether it is no harm if
   a conforming
          message-id matches the syntax. The syntax has been designed Replacement (6.13) for an earlier article.

      Xref-content      = [CFWS] server-name 1*( CFWS location )
      server-name       = path-identity  ; see 5.6.1
      location          = newsgroup-name ":" article-locator
                             [ CFWS ( "revise" / "repost" )
                               ":" article-locator ]
      article-locator   = 1*( %x21-7E ) ; US-ASCII printable characters

   The server-name is included so that additional flags software can determine which
   serving agent generated the header. The locations specify what
   newsgroups the article was filed under (which may be added to 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 is a message-id if desired, decimal
        number, with articles in each newsgroup numbered consecutively
        starting from 1. NNTP demands that such a general "%keyword=value" form prior model be provided, and
        much other software expects it, but it seems desirable to the at-sign.

          Permanent message-ids as permit
        flexibility for unorthodox implementations.

   Whenever an Xref header is created by this system may even be
          implemented by smart NNTP servers an agent for an article which fetch old messages
          from other servers, increasing
   includes a Replaces header with "usage=revise" or "usage=repost"
   (6.13), it SHOULD include, within the availability location field of USENET
          messages considerably.

          Unfortunately, it will be some time until any new feature is
          widely deployed.]

6.17 Archive

          This optional each
   newsgroup in the Newsgroups header of whichever of the old articles
   referenced in that Replaces header is still current, a signal to automatic archival agents
          on whether this article is available corresponding
   "revise:<old-article-locator>" or "repost:<old-article-locator>" for long-term storage.
          Agents which see "Archive: no" MUST NOT keep
   the oldest article past
          the Expires date. Any other text indicates conditions that an
          agent SHOULD follow in order known to archive be being replaced, where <old-article-
   locator> is the article.

          Archive-content = "no" | CFWS

6.18. Obsolete Headers

          Persons writing new agents SHOULD ignore any former meanings
          of these headers.

          Also-Control
          See-Also
          Article-Names
          Article-Updates

7. Duties of Various Agents

          The following section sets out the duties of various Agents
          involved in the creation, relaying and serving of Usenet
          articles.

          Agents article-locator under which write to that oldest article was
   filed. If the Path Replaces header has a "usage=replace" (explicit or
   implicit) the Xref header MUST conform to RFC2142
          with respect NOT include any such reference to contact addresses especially the "usenet" and
          "abuse" addresses.

7.1 Duties of an Injecting Agent.

          An injection agent
   <old-article-locator>.

        NOTE: This is responsible to enable reading agents to avoid showing that
        article to users who have already read any of those older
        articles (see 6.13).  Because several replacements for taking a proto-article
          from given
        article may arrive in the period between attempts by a posting agent and either forwarding it reader to
        read a moderator
          of injecting given newsgroup, it into the relaying system for access by
          readers.

          As such a Injecting Agent is considered responsible for
          ensuring that any useful to include the oldest one
                          News Article Format              February 2000

        in the Xref header. The information necessary to determine this
        article it injects conform with can be obtained from the policies
          and rules Xref header of this document and any newsgroups that an the current
        version of the article just before it is posted to.

          To this end injection agents MAY cancel articles which they
          have previously injected.

7.1.1 Proto-articles.

          A proto-article is one deleted. Observe that is created by a posting agent and
          has not been injected into the news system by an injecting
          agent. Only
        server that never received one copy of a proto-article MUST exist. A
          proto-article has the same format as a normal article except
          that some of the compulsory headers MAY be missing.  A
          proto-injected article MAY have the following headers missing:
          "Message-Id: " , "Date: " replaced articles can
        still generate suitable information from whichever earlier
        version it actually has. This is why it is useful for a Replaces
        header to mention more than one earlier article, especially when
        replacements are being issued in quick succession.

        NOTE: "revise" and "Path: " . These "repost" are case-insensitive.

   An agent inserting an Xref header into an article MUST not
          contain invalid values, they MUST either be correct or not
          present at all. delete any
   previous Xref header(s). A proto-article MUST NOT contain the "!" or "%" character in
          the Path header.

          Proto-articles relaying agent MAY delete it before
   relaying, but otherwise it SHOULD NOT contain the Originator-Info header.
          See reference [draft-newman-msgheader-originfo-x.txt] on this
          header for more information.

7.1.2 Procedure followed be ignored (and usually replaced)
   by Injecting Agents.

          A injecting agent receives proto-articles from posting and
          followup agents. It verifies them, adds headers where required
          and then either forwards them to a moderator any relying or injects them
          by passing them to serving or relaying agents. An injecting agent SHOULD only accept articles from trusted agents. receiving it.

   An injecting agent MAY reject articles in which headers contain
          "forged" email addresses, that is, addresses which are not
          valid for MUST use the known source, and do not end same serving-name in ".invalid".

          If an injecting agent receives an otherwise valid article that
          has already been injected it SHOULD either act Xref headers as if the path-
   identity it is a
          relaying agent or pass uses in Path headers.

6.15.  Lines

   The Lines header indicates the article on to a relaying agent
          completely unaltered. It MUST NOT forward an already injected
          article to a moderator. Articles SHOULD NOT be injected twice.

          An injecting agent accepts a proto-article checks it and does
          one number of lines in the following:

          (a) If the article is invalid, incorrectly formatted or
          unacceptable due to site policy the posting agent MUST be
          informed (such as via a [NNTP] 44x response code) that posting
          has failed and the article MUST NOT be injected nor forwarded
          to a moderator.

          (b) If body of the Newsgroups
   article.

      Lines-content       = [CFWS] 1*digit

   The line contains one or more moderated
          groups and count includes all body lines, including the article does NOT contain an Approved header
          then signature if
   any, including empty lines (if any) at the injecting agent MUST forward beginning or end of the article to
   body, and including the
          moderator whole of the first (leftmost) moderated group listed all Mime message and multipart parts
   contained in the Newsgroups body (the single empty separator line via email. The injecting agent MUST also
          add between the
   headers as detailed below.

          (c) If and the proto-article body is not posted to any moderated
          newsgroups or part of the Approved header body). The "body" here is correctly present then the injecting agent should convert
   body as found in the proto-article to an
          injected posted article (see below) and forwarded it to one or more
          relaying or serving agents.

7.1.3 Headers added as transmitted by Injecting Agents.

          When an injecting agent forwards and article the posting
   agent.

   This header is to a moderator or
          injects it be regarded as obsolete, and it MUST do the do will likely be
   removed entirely in a future version of this standard. In the following:
   meantime, its use is deprecated.

6.16.  User-Agent

   The message-id and Date headers (and their content) MUST be
          added if not already present. The Path User-Agent header MUST be
          correctly added if contains information about the article is being injected but SHOULD
          NOT be added if it is being forwarded to user agent
   (typically a moderator.

          If the Originator-Info header is already present in newsreader) generating the
          proto-article then it MUST be removed if incorrect article, for statistical
   purposes and a
          correct one tracing of standards violations to specific software
   needing correction. Although optional, posting agents SHOULD normally
   include this header.

      User-Agent-content  = product-token *( CFWS product-token )
      product-token       = value ["/" product-version]  ; see 4.1
      product-version     = value

   This header MAY added.

          The Injecting Agent MUST verify contain multiple product-tokens identifying the poster in some way. The
          Path header (section 5.6) MUST be correctly used agent
   and some
          other secure standard method  (such as any subproducts which form a significant part of the Originator-info
          header) MAY be used.

          The Injecting Agent MAY add other headers not posting
   agent, listed in this
          draft but MUST NOT alter, delete or reorder any headers
          already present in order of their significance for identifying the article except
   application. Product-tokens should be short and to the Originator-Info
          header (see above). The Injecting Agent point - they
                          News Article Format              February 2000

   MUST NOT alter be used for information beyond the
          body canonical name of the article in any way.

7.2 Duties of a Relaying Agent

          A relaying Agent accepts injected articles from injecting
   product and
          other relaying its version.  Injecting agents MAY include product
   information for servers (such as INN/1.7.2), but serving and passes them on to relaying
   agents MUST NOT generate or
          serving agents according modify this header to mutually agreed policy. Relaying
          Agents SHOULD only accept articles list themselves.

        NOTE: Variations from trusted agents.

          A relaying agent MAY reject articles in which headers contain
          "forged" email addresses, that is, addresses [RFC 2616] which are not
          valid describes a similar
        facility for the known source, HTTP protocol:

           1. use of arbitrary text or octets from character sets other
              than US-ASCII in a product-token may require the use of a
              quoted-string,

           2. "{" and do not end "}" are allowed in ".invalid".

          A relaying agent MUST perform checks on an article a value (product-token and
              product-version) in Netnews,

           3. UTF-8 replaces ISO-8859-1 as charset assumption.

        NOTE: Comments should be restricted to ensure
          it complies with this standard. If information regarding the article is invalid,
          unwanted (see below) or unacceptable due
        product named to site policy the
          agent that passed their left such as platform information and
        should be concise. Use as an advertising medium (in the article to mundane
        sense) is discouraged.

6.16.1.  Examples

      User-Agent: tin/1.2-PL2
      User-Agent: tin/1.3-950621beta-PL0 (Unix)
      User-Agent: tin/unoff-1.3-BETA-970813 (UNIX) (Linux/2.0.30 (i486))
      User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486))
      User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712)
      User-Agent: Microsoft-Internet-News/4.70.1161
      User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest")
      User-Agent: Pluto/1.05h (RISC-OS/3.1) NewsHound/1.30
      User-Agent: inn/1.7.2
      User-Agent: telnet

        NOTE: This header supersedes the relaying agent SHOULD be
          informed (such role performed redundantly by
        experimental headers such as via a [NNTP] 43x response code) that
          relaying failed. In order to prevent a large number of error
          messages being sent to one location relaying agent MUST NOT
          inform any X-Newsreader, X-Mailer, X-Posting-
        Agent, X-Http-User-Agent, and other external entity that an article was not
          relayed UNLESS that external entity has specificly requested
          that it be informed headers previously used on
        Usenet for this purpose. Use of these errors.

          In order to prevent overloading relaying agents experimental headers
        SHOULD NOT
          query an external entity (such as a key-server) be discontinued in order to
          verify an article.

          When an article is received the relaying agent MUST verify favor of the
          previous entry in this single, standard User-
        Agent header which can be used freely both in Netnews and add their own entry(s)
          according mail.

6.17.  MIME headers

6.17.1.  Syntax

   The following headers, as defined within [RFC 2045] and its
   extensions, may be used within articles conforming to this standard.

        MIME-Version:
        Content-Type:
        Content-Transfer-Encoding:
        Content-ID:
        Content-Description:

                          News Article Format              February 2000

        Content-Disposition:
        Content-MD5:

   Insofar as the syntax defined for these headers, as given in [RFC 2045], does
   not specify precisely where whitespace and comments may occur
   (whether in the Path section 5.6.
          Relaying agents MUST NOT alter,   deleted or rearrange any
          part form of an article expect for WSP, FWS or CFWS), the Path usage defined in this
   standard, and Xref Headers.

          Article which match mutually agreed criteria should be passed
          onto neighboring relaying failing that in [MESSFOR], and serving agents.

          NOTE: It is usual for relaying failing that in [RFC
   822] MUST be followed. In particular, there MUST NOT be any WSP
   between a header-name and serving agents to restrict the Newsgroups, Distributions, age and size of articles they
          wish to receive.

7.2.1 Unwanted following colon and Invalid articles

          Relaying Agents there MUST reject all articles be a SP
   following that do not have all
          mandatory colon.

   The meaning of the various MIME headers present is as defined in [RFC 2045]
   and [RFC 2046], and in extensions registered in accordance with legal contents or which have
          illegal contents [RFC
   2048].  However, their usage is curtailed as described in optional headers.

          Relaying Agents the
   following sections.

6.17.2.  Content-Transfer-Encoding

   Posting agents SHOULD reject any articles that have already
          been sent to it (a database message-ids of recent messages is
          usually kept specify "Content-Transfer-Encoding: 8bit" for
   all articles not written in pure US-ASCII and matched against) or which are too old (from not requiring full
   binary. They MAY use "8bit" encoding even when "7bit" encoding would
   have sufficed. They SHOULD specify "base64" when the Date header) content type
   implies binary (i.e. content intended for it machine, rather than human,
   consumption).

        NOTE: If a future extension to determine if they have already been
          sent the MIME standards were to it. Relaying Agents
        provide a more compact encoding of binary suited to transport
        over an 8bit channel, it could be considered as an alternative
        to base64 once it had gained widespread acceptance.

   Posting agents SHOULD NOT forward specify encoding "quoted-printable", but
   reading agents MUST interpret that encoding correctly.  Encoding
   "binary" MUST NOT be used (except in cooperating subnets with
   alternative transport arrangements) because this standard does not
   mandate a transport mechanism that could support it.

   Injecting and relaying agents MUST NOT change the encoding of
   articles passed to
          sites whose path-identity them. Gateways SHOULD ONLY change the encoding if
   absolutely necessary.

6.17.3.  Content-Type

   The Content-Type: "text/plain" is already in the Path header.

          Relaying Agents SHOULD also reject default type for any articles that have been
          Canceled, Superseded or Replaced by their author or another
          trusted entity.

7.3 Duties of a Serving Agent

          A Serving Agent takes an article from a relaying or injecting
          agent news
   article, but the recommendations and files it limits on line lengths set out
   in section 4.5 SHOULD be observed. The acceptability of other
   subtypes of Content-Type: "text" (such as "text/html") is a "news database" . It also provides an
          interface for reading agents to access the news database. This
          database is normally indexed by newsgroup with with articles
          in each newsgroup numbered consecutively starting from 1. See
          [NNTP] for more information on this format.

          NOTE: Control messages are usually filed matter of
   policy (see 1.1), and posters SHOULD NOT use them unless established
   policy or custom in the separate
          pseudo-newsgroup "control" particular hierarchies or a pseudo-newsgroup groups involved so
   allows. Moreover, even in a
          hierarchy under "control." (ie "control.cancel" ) . Serving
          Agents SHOULD do this if they serve articles via NNTP.

          Serving Agents are encouraged to only allow access to trusted
          reading agents.

          Serving Agents SHOULD generate a correct Xref header those cases, the material SHOULD, for
          crossposted articles and MUST prepend a correct path-identity
          into the Path header
   benefit of all articles.

7.3.1 Unwanted articles

          Serving Agents MUST reject all articles that do not have all
          mandatory headers present with legal contents or which have
          illegal contents readers who see it only in optional headers.

          Serving Agents SHOULD reject any articles that have already
          been sent its transmitted form, be
   "pretty-printed" so as to keep it (a database message-ids of recent messages is
          usually kept and matched against) or which are too old (from within the Date header) for it to determine if they have already been
          sent line lengths recommended
   in section 4.5, and to it.

          Serving Agents SHOULD also reject keep any articles that have been
          Canceled, Superseded sequences which control its layout or Replaced by
   style separate from the meaningful text.

                          News Article Format              February 2000

   In the same way, Content-Types requiring special processing for their author or another
          trusted entity and delete any of these articles that they
          already have
   display, such as "application", "image", "audio", "video" and
   "multipart/related" are discouraged except in their news database.

7.4 Duties of a Posting Agent.

          A posting agent is used groups specifically
   intended (by policy or custom) to assist the poster include them. Exceptionally, those
   application types defined in creating a
          valid proto-article [RFC 1847] and forwarding it [RFC 2015] for use within
   "multipart/signed" articles, and the type "application/pgp-keys" (or
   other similar types containing digital certificates) may be used
   freely but, contrary to an injecting agent.

          Postings Agents SHOULD ensure that proto-articles they create
          are valid usenet articles according [RFC 2015] and unless the article is intended
   to be sent by mail also, the standards of this
          document and other policies.

          Posting Content-Transfer-Encoding SHOULD be left
   as "8bit" (or "7bit" as appropriate).

   Reading agents meant for use by ordinary posters SHOULD reject
          any attempt to post an article NOT, unless explicitly configured otherwise,
   act automatically on Application types which cancels, Supersedes or
          Replaces another article if could change the target article not state
   of that agent (e.g. by writing or modifying files), except in the
          poster.

7.5 Duties of a Followup Agent

          A followup Agent is a special
   case of a Posting Agent those prescribed for use in control messages (7.1.2 and as
          such
  ).

6.17.3.1.  Message/partial

   The Content-Type "message/partial" MAY be used to split a long news
   article into several smaller ones, but this usage is bound by all discouraged on
   the Posting Agent's requirements plus
          additional ones.  Followup Agents MUST create valid followups,
          Followups grounds that modern transport agents should have additional requirements from normal no difficulty in
   handling articles
          for the syntax of arbitrary length.

   However, IF this feature is used, then the References and Subject headers and the
          body format.

          Followup Agents MUST by default follow "id" parameter SHOULD be
   in the FollowUp-To header
          when deciding which newsgroups form of a followup is posted to,
          however unique message identifier (but different from that
   in the poster MAY override Message-ID header of any of the default if they wish.

          Followup Agents MUST NOT attempt parts).  Contrary to send email the
   requirements specified in [RFC 2046], the Transfer-Encoding SHOULD be
   set to any address
          ending "8bit" at least in ".invalid".

          Followup Agents each part that requires it. The second and
   subsequent parts SHOULD NOT email copies of contain References headers referring to all
   the followup previous parts, thus enabling reading agents with threading
   capabilities to present them in the
          author of correct order. Reading agents MAY
   then provide a facility to recombine the precursor (or any other person) unless parts into a single article
   (but this has
          been explicitly requested.

7.6 Duties standard does not require them to do so).

6.17.3.2.  Message/rfc822

   The Content-Type "message/rfc822" should be used for the
   encapsulation (whether as part of another news article or, more
   usually, as part of a Gateway

NOT DONE

8. Propagation and Processing

          Most aspects mail message) of complete news propagation articles which
   have already been posted to Netnews and processing which are
          implementation-specific.   The  basic propagation algorithms,
          and certain details for the information
   of how they  are  implemented,
          nevertheless need to be standard.

          There  are  two  important principles that news implementors
          (and administrators) need to keep in mind.  The first is the
          well-known Internet Robustness Principle:

               Be liberal in what you accept, recipient, and conservative in what
               you send.

          However, in do not constitute a request to repost them.

   In the case of news there is an even more important
          principle, derived from a much older code of  practice, where the
          Hippocratic  Oath  (we encapsulated article has Content-Transfer-
   Encoding "8bit", it will  thus call this the Hippocratic
          Principle):

               First, do no harm.

          It be necessary to change that encoding if it
   is VITAL to realize be forwarded over some mail transport that decisions which might only supports
   "7bit". However, this should not be  merely
          suboptimal  in a smaller context can become devastating
          mistakes when amplified by necessary for any mail transport
   that supports the actions of  thousands  of
          hosts within a few hours.

          In 8BITMIME feature [SMTP].  Moreover, where the case
   headers of gateways, the primary corollary encapsulated article contain any UTF8-xtra-chars
   (2.4), it may not be possible to this is:

               Cause no loops.

9. Security And Related Issues

          There transport them over mail transports
   even where 8BITMIME is no security. Don't fool yourself. USENET supported. In such cases, it will be necessary
   to encode those headers as provided in [RFC 2047] (notwithstanding
   that such usage is a prime
          example deprecated for news headers by this standard, and
   actually forbidden in the case of an Internet Adhocratic-Anarchy; the Newsgroups header).

                          News Article Format              February 2000

   In the event that is, an
          environment in which trust forms the basis encapsulated article has to be encoded for
   either of all agreements.
          It works.

          Articles which are intended these reasons, it may be necessary to reverse that encoding
   if certain forms of digital signatures have restricted distribution
          are dependent on been employed, or if the goodwill of every site receiving them.
          The "X-No-Archive: yes" header
   article is widely recognized as a
          signal to automated archivers not to file an article, but that
          cannot be guaranteed.

          The Distribution header makes provisions for articles which reintroduced into some Netnews system (however, in
   the latter case, the Content-Type "application/news-transmission"
   should have been used instead).

        NOTE: It is likely, though not be guaranteed, that headers
        containing UTF8-xtra-chars will pass safely through mail
        transports supporting 8BITMIME if the "message/rfc822" object is
        sent as an attachment (i.e.  as a part of a multipart) rather
        than as the top-level body of the mail message. Moreover, it is
        anticipated that future extensions to the mail standards will
        permit headers containing UTF8-xtra-chars to be carried without
        further ado over conforming transports.
[In fact, of current transports supporting 8BITMIME, only sendmail will
have problems with UTF-8 in top-level headers.]

6.17.3.3.  Message/external-body

   The Content-Type "message/external-body" could be apropriate for
   texts which it would be uneconomic (in view of the likely readership)
   to distribute to the entire network.

6.17.3.4.  Multipart types

   The Content-Types "multipart/mixed", "multipart/parallel" and
   "multipart/signed" may be used freely in news articles.  However,
   except where policy or custom so allows, the Content-Type:
   "multipart/alternative" SHOULD NOT be used, on account of the extra
   bandwidth consumed and the difficulty of quoting in followups, but
   reading agents MUST accept it.

   The Content-Type: "multipart/digest" is commended for any article
   composed of multiple messages more conveniently viewed as separate
   entities. The "boundary" should be composed of 28 hyphens (US-ASCII
   45) (which makes each boundary delimiter 30 hyphens, or 32 for the
   final one) so as to accord with current practice for digests [RFC
   1153].
[Actually, this conflicts with some present digest usage (such as the
news.answers rules), but should still be the right way to go. I suggest
this is left in for now (just to stake a claim), while we discuss the
matter with the news.answers moderators and the faq-maintainers.]

6.17.4.  Character Sets

   In principle, any character set may be specified in the "charset="
   parameter of a content type. However, character sets other than "us-
   ascii", "iso-8859-1" (and the corresponding parts of UTF-8) ought
   only to be used in hierarchies where the language customarily used so
   requires (and whose readers could be expected to possess agents
   capable of displaying them).

                          News Article Format              February 2000

6.17.5.  Content Disposition

   Reading agents SHOULD honour any Content-Disposition header that is
   provided (in particular, they SHOULD display any part of a multipart
   for which the disposition is "inline", possibly distinguished from
   adjacent parts by some suitable separator). In the absence of such a
   header, the body of an article or any part of a multipart with
   Content-Type "text" SHOULD be displayed inline. Followup agents which
   quote parts of a precursor (see 4.3.2) SHOULD initially include all
   parts of the precursor that were displayed inline, as if they were a
   single part.

6.17.6.  Definition of some new Content-Types

   This standard defines (or redefines) several new Content-Types, which
   require to be registered with IANA as provided for in [RFC 2048].
   For "application/news-groupinfo" see 7.1.2, for "application/news-
   checkgroups" see 7.4.1, and for "application/news-transmission" see
   the following section.

6.17.6.1.  Application/news-transmission

   The Content-Type "application/news-transmission" is intended for the
   encapsulation of complete news articles where the intention is that
   the recipient should then inject them into Netnews. This Application
   type SHOULD be used when mailing articles to moderators and to mail-
   to-news gateways (see 8.2.2).

        NOTE: The benefit of such encapsulation is that it removes
        possible conflict between news and email headers and it provides
        a convenient way of "tunnelling" a news article through a
        transport medium that does not support 8bit characters.

   The MIME content type definition of "application/news-transmission"
   is:

   MIME type name:           application
   MIME subtype name:        news-transmission
   Required parameters:      none
   Optional parameters:      usage=moderate
                             usage=inject
                             usage=relay
   Encoding considerations:  A transfer-encoding (such as Quoted-
                             Printable or Base64) different from that of
                             the article transmitted MAY be supplied
                             (perhaps en route) to ensure correct
                             transmission over some 7bit transport
                             medium.
   Security considerations:  A news article may be a "control message",
                             which could have effects on the recipient
                             host's system beyond just storage of the
                             article. However, such control messages
                             also occur in normal news flow, so most
                             hosts will already be suitably defended
                          News Article Format              February 2000

                             against undesired effects.
   Published specification:  [USEFOR]
   Body part:                A complete article or proto-article, ready
                             for injection into Netnews, or a batch of
                             such articles.

        NOTE: It is likely that the recipient of an "application/news-
        transmission" will be a specialised gateway (e.g. a moderator's
        submission address) able to accept articles with only one of the
        three usage parameters "moderate", "inject" and "relay", hence
        the reason why they are optional, being redundant in most
        situations. Nevertheless, they MAY be used to signify the
        originator's intention with regard to the transmission, so
        removing any possible doubt.

   When the parameter "relay" is used, or implied, the body part MAY be
   a batch of articles to be transmitted together, in which case the
   following syntax MUST be used.

      batch             = 1*( batch-header article )
      batch-header      = "#!" SP "rnews" SP article-size CRLF
      article-size      = 1*digit

   where the "rnews" is case-sensitive. Thus a batch is a sequence of
   articles, each prefixed by a header line that includes its size. The
   article-size is a decimal count of the octets in the article,
   counting each CRLF as one octet regardless of how it is actually
   represented.

        NOTE: Despite the similarity of this format to an executable
        UNIX script, it is EXTREMELY unwise to feed such a batch into a
        command interpreter in anticipation of it running a command
        named "rnews"; the security implications of so doing would be
        disastrous.

6.17.6.2.  Message/news withdrawn

   The Content-Type "message/news", as previously registered with IANA,
   is hereby obsoleted and should be withdrawn. It was never widely
   implemented, and its default treatment as "application/octet-stream"
   by agents that did not recognise it was counter productive. The
   Content-Type "message/rfc822" SHOULD be used in its place, as already
   described above.

6.18.  Obsolete Headers

   Persons writing new agents SHOULD ignore any former meanings of the
   following headers:

        Also-Control
        See-Also
        Article-Names
        Article-Updates
                          News Article Format              February 2000

7.  Control Messages

   The following sections document the control messages.  "Message" is
   used herein as a synonym for "article" unless context indicates
   otherwise.  Group control messages are the sub-class of control
   messages that request some update to the configuration of the groups
   known to a serving agent, namely "newgroup".  "rmgroup", "mvgroup"
   and "checkgroups", plus any others created by extensions to this
   standard.

   All of the group control messages MUST have an Approved header
   (6.12).  Moreover, in those hierarchies where appropriate
   administrative agencies exist (see 1.1), group control messages
   SHOULD NOT be issued except as authorized by those agencies.
[They SHOULD also use one of the authentication mechanisms which we
shall define when we get a Round Tuit.]

   The Newsgroups header of each control message MUST include the
   newsgroup-name(s) for the group(s) affected (i.e. groups to be
   created, modified or removed, or containing articles to be canceled).
   This is to ensure that the message progagates to all sites which
   receive (or would receive) that group(s). It MAY include other
   newsgroup-names so as to improve propagation (but this practice
   should be regarded as exceptional rather than normal).

   The descriptions below are generally phrased in terms suggesting
   mandatory actions, but any or all of these MAY be subject to local
   administrative restrictions, and MAY be denied or referred to an
   administrator for approval (either as a class or on a case-by-case
   basis). Analogously, where the description below specifies that a
   message or portion thereof is to be ignored, this action MAY include
   reporting it to an administrator.

   Relaying Agents MUST propagate even control messages that they do not
   understand.

   In the following sections, each type of control message is defined
   syntactically by defining its verb, its arguments, and possibly its
   body.

7.1.  The 'newgroup' Control Message

      newgroup-verb       = "newgroup"
      newgroup-arguments  = CFWS newsgroup-name [ CFWS newgroup-flag ]
      newgroup-flag       = "moderated"

   The "newgroup" control message requests that the specified group be
   created or changed. The newgroup-flag "moderated" is appended to mark
   the group as moderated. The absence of this flag marks the group as
   unmoderated. "Moderated" is the only such flag defined by this
   standard; other flags MAY be defined for use in cooperating subnets,
   but newgroup messages containing them MUST NOT be acted on outside of
   those subnets.

                          News Article Format              February 2000

        NOTE: Specifically, some alternative flags such as "y" and "m",
        which are sent and recognised by some current software, are NOT
        part of this standard.  Moreover, some existing implementations
        treat any flag other than "moderated" as indicating an
        unmoderated newsgroup. Both of these usages are contrary to this
        standard.

   The message body comprises or includes a "application/news-groupinfo"
   (7.1.2) part containing machine- and human-readable information about
   the group.

   The newsgroup-name MUST conform to all requirements set out in
   section 5.5, and it is the responsibility of the newgroup message
   issuer to ensure this (since some of those requirements are hard to
   enforce mechanically). Moreover, the newsgroup-name SHOULD conform to
   whatever policies have been established by the administrative agency,
   if any, for that hierarchy.

   The newgroup command is also used to update the newsgroups-line or
   the moderation status of a group.

7.1.1.  The Body of the 'newgroup' Control Message

   The body of the newgroup message contains the following subparts,
   preferably in the order shown:

   1. An "application/news-groupinfo" part (7.1.2) containing the name
      and newsgroups-line of the group(s). This part MUST be present.

   2. Other parts containing useful information about the background of
      the newsgroup message (typically of type "text/plain").

   3. Parts containing initial articles for the newsgroup. See section
      7.1.3 for details.

   In the event that there is only the single (i.e. application/news-
   groupinfo) subpart present, it will suffice to include a "Content-
   Type:  application/news-groupinfo" amongst the headers of the control
   message.  Otherwise, a "Content-Type: multipart/mixed header" will be
   needed, and each separate part will then need its own Content-Type
   header.

7.1.2.  Application/news-groupinfo

   The "application/news-groupinfo" body part contains brief information
   about a newsgroup, i.e. the group's name, it's newsgroup-description
   and the moderation-flag.

        NOTE: The presence of the newsgroups-tag "For your newsgroups
        file:" is intended to make the whole newgroup message compatible
        with current practice as described in [Son-of-1036].

                          News Article Format              February 2000

   The MIME content type definition of "application/news-groupinfo" is:

   MIME type name:           application
   MIME subtype name:        news-groupinfo
   Required parameters:      none
   Disposition:              by default, inline
   Encoding considerations:  "7bit" or "8bit" is sufficient and MUST be
                             used to maintain compatibility.
   Security considerations:  this type MUST NOT be used except as part
                             of a control message for the creation or
                             modification of a Netnews newsgroup
   Published specification:  [USEFOR]

   The content of the "application/news-groupinfo" body part is defined
   as:

      groupinfo-body      = [ newsgroups-tag CRLF ]
                               1*( newsgroups-line CRLF )
      newsgroups-tag      = %x46.6F.72 SP %x79.6F.75.72 SP
                               %x6E.65.77.73.67.72.6F.75.70.73 SP
                               %x66.69.6C.65.3A
                               ; case sensitive
                               ; "For your newsgroups file:"
      newsgroups-line     = newsgroup-name
                               [ 1*HTAB newsgroup-description ]
                               [ 1*WSP moderation-flag ]
      newsgroup-description
                          = 1*( [WSP] utext)
      moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
                               ; case sensitive "(Moderated)"
   The whole groupinfo-body is intended to be interpreted as a text
   written in the UTF-8 character set.

   The "application/news-groupinfo" is used in conjunction with the
   "newgroup" (7.1) and "mvgroup" (7.3) control messages.  The
   newsgroup-name(s) in the newsgroups-line MUST agree with the
   newsgroup-name(s) in the "newgroup" or "mvgroup" control message (and
   thus there cannot be more than a single newsgroups-line except in the
   case of a "mvgroup" control message affecting a whole (sub-
   )hierarchy).  The Content-Type "application/news-groupinfo" MUST NOT
   be used except as a part of such control messages.  Although
   optional, the newsgroups-tag SHOULD be included until such time as
   this standard has been widely adopted, to ensure compatibility with
   present practice.

   Moderated newsgroups MUST be marked by appending the case sensitive
   text " (Moderated)" at the end. It is NOT recommended that the
   moderator's email address be included in the newsgroup-description as
   has sometimes been done.

   Although, in accordance with [MESSFOR] and section 4.5 of this
   standard, a newsgroups-line could have a maximum length of 998
   octets, as a matter of policy a far lower limit, expressed in
   characters, SHOULD be set. The current convention is to limit its
                          News Article Format              February 2000

   length so that the newsgroup-name, the HTAB(s) (interpreted as 8-
   character tabs that takes one at least to column 24) and the
   newsgroup-description (excluding any moderation-flag) fit into 79
   characters.  However, this standard does not seek to enforce any such
   rule, and reading agents SHOULD therefore enable a newsgroups-line of
   any length to be displayed, e.g. by wrapping it as required.

        NOTE: The newsgroups-line is intended to provide a brief
        description of the newsgroup, written in the UTF-8 character
        set.  Since newsgroup-names are required to be expressed in
        UTF-8 when they appear in headers, and since [NNTP] requires the
        use of UTF-8 when such a description is transmitted by the LIST
        NEWSGROUPS command, it would also be convenient for servers that
        keep a "newsgroups" file to store them in that form, so as to
        avoid unnecessary conversions.

7.1.3.  Initial Articles

   Some subparts of a "newgroup" or "mvgroup" control message MAY
   contain an initial set of articles to be posted to the affected
   newsgroup(s) as soon as it has been created. These parts are
   identified by having the Content-Type "application/news-
   transmission", possibly with the parameter "usage=inject".  The body
   of each such part should be a complete proto-article, ready for
   posting. This feature is intended for the posting of charters,
   initial FAQs and the like to the newly formed group(s).

   The Newsgroups header of the proto-article MUST include the
   newsgroup-name of the newly created group (or one of them, if more
   than one). It MAY include other newsgroup-names. If the proto-article
   includes a Message-ID header, the message indentifier in it MUST be
   different from that of any existing article and from that of the
   control message as a whole, though it MAY be derived from it by
   appending "$p=<n>", where <n> is an integer part number (see also
   6.13.2.1), immediately after its id-left-side (i.e.  before the "@").
   Alternatively such a message identifier MAY be derived by the
   injecting agent when the proto-article is posted. The proto-article
   SHOULD include the header "Distribution: local".

   The proto-article SHOULD be injected at the serving agent that
   processes the control message AFTER the newsgroup(s) in question has
   been created. It MUST NOT be injected if the newsgroup is not, in
   fact, created (for whatever reason). It MUST NOT be submitted to any
   relaying agent for transmission beyond the server(s) upon which the
   newsgroup creation has just been effected (in other words, it is to
   be treated as having a "Distribution: local" header, whether such a
   header is actually present or not).

        NOTE: The "$p=<n>" convention, if applied uniformly, should
        ensure that initial articles relayed beyond the local server in
        contravention of the above prohibition will not propagate in
        competition with similar copies injected at other local servers.

                          News Article Format              February 2000

        NOTE: It is not precluded that the proto-article is itself a
        control message or other type of special article, to be
        activated only upon creation of the new newsgroup. However,
        except as might arise from that possibility, any
        "application/news-transmission" within some nested "multipart/*"
        structure within the proto-article is not to be activated.
[Observe the possibility for initial Named articles (whatever they may
turn out to be) here.]

7.1.4.  Example

   A "newgroup" with bilingual charter and policy information:

      From: "example.all Administrator" <admin@example.invalid>
      Newsgroups: example.admin.groups,example.admin.announce
      Date: 27 Feb 1997 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: admin@example.invalid
      Control: newgroup example.admin.info moderated
      Message-ID: <ng-example.admin.info-19970227@example.invalid>
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

      This is a MIME control message.
      --nxtprt
      Content-Type: application/news-groupinfo

      For your newsgroups file:
      example.admin.info      About the example.* groups (Moderated)

      --nxtprt
      Content-Type: application/news-transmission

      Newsgroups: example.admin.info
      From: "example.all Administrator" <admin@example.invalid>
      Subject: Charter for example.admin.info
      Message-ID: <ng-example.admin.info-19970227$p=1@example.invalid>
      Distribution: local
      Content-Type: multipart/alternative ;
         differences = content-language ;
         boundary = nxtlang

      --nxtlang
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit
      Content-Language: en

      The group example.admin.info contains regularly posted
      information on the example.* hierarchy.

      --nxtlang
      Content-Type: text/plain; charset=iso-8859-1
      Content-Transfer-Encoding: 8bit
                          News Article Format              February 2000

      Content-Language: de

      Die Gruppe example.admin.info enthaelt regelmaessig versandte
      Informationen ueber die example.*-Hierarchie.
      --nxtlang--
      --nxtprt--

7.2.  The 'rmgroup' Control Message

      rmgroup-verb        = "rmgroup"
      rmgroup-arguments   = CFWS newsgroup-name

   The "rmgroup" control message requests that the specified group be
   removed from the list of valid groups. The Content-Type of the body
   is unspecified; it MAY contain anything, usually an explanatory text.

        NOTE: It is entirely proper for a serving agent to retain the
        group until all the articles in it have expired, provided that
        it ceases to accept new articles.

7.2.1.  Example

   Plain "rmgroup":

      From: "example.all Administrator" <admin@example.invalid>
      Newsgroups: example.admin.groups, example.admin.announce
      Date: 4 Jul 1997 22:04 -0900 (PST)
      Subject: cmsg rmgroup example.admin.obsolete
      Message-ID: <rm-example.admin.obsolete-19970730@example.invalid>
      Approved: admin@example.invalid
      Control: rmgroup example.admin.obsolete

      The group example.admin.obsolete is obsolete. Please remove it
      from your system.

7.3.  The 'mvgroup' Control Message

      mvgroup-verb      = "mvgroup"
      mvgroup-arguments = CFWS ( mvgrp-groups / mvgrp-hrchy )
      mvgrp-groups      = newsgroup-name
                             CFWS newsgroup-name [ CFWS newgroup-flag ]
      mvgrp-hrchy       = groupnamepart ".*" CFWS groupnamepart ".*"
      groupnamepart     = newsgroup-name    ; syntactically
[The possibility remains of introducing an "unmoderated" version of the
newgroup-flag. As it stands now, a moderated group might inadvertently
become unmoderated as it was moved (if the issuer of the mvgroup was not
paying attention). But the same thing could as easily happen if
"unmoderated" was allowed, but not used, unless the flag was declared
not optional in a mvgroup.]

7.3.1.  Single group
                          News Article Format              February 2000

   The "mvgroup" control message requests that the first specified group
   be moved to the second specified group. The message body MUST contain
   a "application/news-groupinfo" (7.1.2) containing machine- and
   human-readable information about the new group, and possibly other
   subparts as for a newgroup control message.

   When this message is received, the new group SHOULD be created (and
   MUST be moderated if a newgroup-flag "moderated" is present) and all
   existing articles SHOULD be copied or moved to the new group; then
   the old, now empty group SHOULD be removed.

   If the old group does not exist, the message is ignored unless the
   new group does not exist either, in which case the message SHOULD be
   treated as if it had been an equivalent "newgroup" message.

   If both groups exist, the groups MAY be "merged". If this is done, it
   MUST be done correctly, i.e. implementations MUST take care that the
   messages in the group being deleted are renumbered accordingly to
   avoid overwriting articles in one group with those of the other, and
   that crossposted articles do not appear twice. Otherwise, the old
   group is just removed.

        NOTE: Due to the severe difficulties of implementing this
        merging, those proposing to merge existing groups using this
        control message should be aware that it may not be implemented
        on many (if not most) sites, and should therefore be prepared
        for such disruption as may ensue.

   An indication that the old group was replaced by the new group MAY be
   retained by the serving agent so that continuity of service may be
   maintained, and clients made aware of the new arrangements.

        NOTE: Some serving agents that use an "active" file permit an
        entry of the form "oldgroup xxx yyy =newgroup", which enables
        any articles arriving for oldgroup to be diverted to newgroup,
        and could even enable users already subscribed to oldgroup to
        receive articles from newgroup instead.

   In all cases, the information conveyed in the "application/news-
   groupinfo" body part is applied to the new group.

   Until most serving agents conform to this standard, whenever a
   mvgroup control message for a single group is issued, a corresponding
   pair of rmgroup and newgroup control messages SHOULD be issued a few
   days later.

7.3.2.  Multiple Groups

   If the two names ends with the character sequence ".*", the newgroup
   message requests that a whole (sub)hierarchy be moved.  The same
   procedure as for single groups (7.3.1) applies to each matched group,
   except that the moderation status of each old group MUST be copied to
   the corresponding new group.

                          News Article Format              February 2000

   To avoid recursion, the new groups' names MUST NEVER match the old
   groups' name pattern; i.e., moving a whole (sub)hierarchy to a
   subhierarchy of the original hierarchy is explicitly disallowed.

   Until most serving agents conform to this standard, whenever a
   mvgroup control message for multiple groups is issued, a
   corresponding set of rmgroup and newgroup control messages for all
   the affected groups SHOULD be issued a few days later.

7.3.3.  Examples

   Plain "mvgroup":

      From: "example.all Administrator" <admin@example.invalid>
      Newsgroups: example.admin.groups, example.admin.announce
      Date: 30 Jul 1997 22:04 -0500 (EST)
      Subject: cmsg mvgroup example.oldgroup example.newgroup moderated
      Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid>
      Approved: admin@example.invalid
      Control: mvgroup example.oldgroup example.newgroup moderated
      Content-Type: multipart/mixed; boundary=nxt

      --nxt
      Content-Type: application/newgroupinfo

      For your newsgroups file:
      example.newgroup        The new replacement group (Moderated)

      --nxt

      The moderated group example.oldgroup is replaced by
      example.newgroup. Please update your configuration.
      --nxt--

   More complex "mvgroup" for a whole hierarchy:

   The charter of  the group example.talk.jokes contained a reference to
   example.talk.jokes.d, which is also being moved. So the charter is
   updated.

      From: "example.all Administrator" <admin@example.invalid>
      Newsgroups: example.admin.groups, example.admin.announce
      Date: 30 Jul 1997 22:04 -0500 (EST)
      Subject: cmsg mvgroup example.talk.* example.conversation
      Message-ID: <mvgroup-example.talk-19970730@example.invalid>
      Approved: admin@example.invalid
      Control: mvgroup example.talk.* example.conversation
      Content-Type: multipart/mixed; boundary=nxt

      --nxt
      Content-Type: application/news-groupinfo

      For your newsgroups file:
      example.conversation.boring     Boring conversations
                          News Article Format              February 2000

      example.conversation.better     Better conversations
      example.conversation.jokes      Funny stuff
      example.conversation.jokes.d    Discussion of funny stuff

      --nxt
      Content-Type: application/news-transmission

      Newsgroups: example.conversation.jokes
      From: "example.all Administrator" <admin@example.invalid>
      Subject: Charter for renamed group example.conversation.jokes
      Distribution: local
      Message-ID: <mvgroup-example.talk-19970730$p=1@example.invalid>

      This group is to publish jokes and other funny stuff.
      Discussions about the articles posted here should be redirected
      to example.conversation.jokes.d; adding a Followup-To: header
      is recommended.

      --nxt--

7.4.  The 'checkgroups' Control Message

   The "checkgroups" control message contains a list of all the valid
   groups in a complete hierarchy.

      checkgroup-verb     = "checkgroups"
      checkgroup-arguments= [ chkscope ] [ chksernr ]
      chkscope            = 1*( CFWS ["!"] newsgroup-name )
      chksernr            = CFWS "#" 1*DIGIT

   The chkscope parameter(s) specifies the (sub)hierarchy(s) for which
   this "checkgroups" message applies. The chksernr parameter is a
   serial number, which can be any positive integer (e.g. just numbered
   or the date in YYYYMMDD).  It SHOULD increase by an arbitrary value
   with every change to the group list and MUST NOT ever decrease.

        NOTE: This was added to circumvent security problems in
        situations where the Date header cannot be authenticated.

   Example:

      Control: checkgroups de !de.alt #248

        NOTE: Some existing software does not support the "chkscope"
        parameter.  Thus a "checkgroups" message SHOULD also contain the
        groups of other subhierarchies the sender is not responsible
        for. "New" software MUST ignore groups which do not fall into
        the scope of the "checkgroups" message.
[What systems, if any, currently support the chkscope parameter?]

   If no scope for the checkgroups message is given, it applies to all
   hierarchies for which group statements appear in the message.

                          News Article Format              February 2000

   The body of the message has the Content-Type "application/news-
   checkgroups".  It asserts that the newsgroups it lists are the only
   newsgroups in the specified hierarchies.

        NOTE: The checkgroups nessage is intended to synchronize the
        list of newsgroups stored by a serving agent, and their
        newsgroup-descriptions, with the lists stored by other serving
        agents throughout the network. However, it might be inadvisable
        for the serving agent actually to create or delete any
        newsgroups without first obtaining the approval of its
        administrators for such proposed actions.

7.4.1.  Application/news-checkgroups

   The "application/news-checkgroups" body part contains a complete list
   of all the newsgroups in a hierarchy, their newsgroup-descriptions
   and their moderation status.

   The MIME content type definition of "application/news-checkgroups"
   is:

   MIME type name:           application
   MIME subtype name:        news-checkgroups
   Required parameters:      none
   Disposition:              by default, inline
   Encoding considerations:  "7bit" or "8bit" is sufficient and MUST be
                             used to maintain compatibility.
   Security considerations:  this type MUST NOT be used except as part
                             of a checkgroups control message

   The content of the "application/news-checkgroups" body part is
   defined as:

      checkgroups-body    = *( valid-group CRLF )
      valid-group         = newsgroups-line ; see 7.1.2
   The whole checkgroups-body is intended to be interpreted as a text
   written in the UTF-8 character set.

   The "application/news-checkgroups" content type is used in
   conjunction with the "checkgroups" control message (7.4).

        NOTE: The possibility of removing a complete hierarchy by means
        of an "invalidation" line beginning with a '!' is no longer
        provided by this standard. The intent of the feature was widely
        misunderstood and it was misused more often than it was used
        correctly. The same effect, if required, can now be obtained by
        the use of an appropriate chkscope argument in conjunction with
        an empty checkgroups-body.

7.5.  Cancel

   The cancel message requests that a target article be "canceled" i.e.
   be withdrawn from circulation or access. A cancel message may be
   issued in the following circumstances.

                          News Article Format              February 2000

   1. The poster of an article (or, more specifically, any entity
      mentioned in the From header or the Sender header, whether or not
      that entity was the actual poster) is ALWAYS entitled to issue a
      cancel message for that article, and serving agents SHOULD honour
      such requests. Posting agents SHOULD facilitate the issuing of
      cancel messages by posters fulfilling these criteria.

   2. The agent which injected the article onto the network (more
      specifically, the entity identified by the path-identity in front
      of the leftmost '%' delimeter in the Path header) and, where
      appropriate, the moderator (more specifically, any entity
      mentioned in the Approved header) is ALWAYS entitled to issue a
      cancel message for that article, and serving agents SHOULD honour
      such requests.

   3. Other entities MAY be entitled to issue a cancel message for that
      article, in circumstances where established policy for any
      hierarchy or group in the Newsgroup header, or established custom
      within Usenet, so allows (such policies and customs are not
      defined by this standard). Such cancel messages MUST include an
      Approved header identifying the responsible entity. Serving agents
      MAY honour such requests, but SHOULD first take steps to verify
      their appropriateness.
[I think that accords with the accepted norms for 1st, 2nd and 3rd party
cancels (or is a moderator a 1st party?). Observe the use of an Approved
header in place of the present X-Cancelled-By (I cannot see that we need
a new header for that when Approved is available). The definitions given
are sufficient to establish which category a cancel was in, assuming
that nobody told any lies, and to establish who had committed abuse
otherwise. So far so good, but we now need authentication methods on top
of all that.]

[A future draft of this standard will contain provisions for a Cancel-
Lock header to enable verification of the authenticity of 1st (and even
2nd) party cancels, and means for digital signatures to establish the
authenticity of 3rd party cancels.]

[A future draft of this standard may also contain provision for a "block
cancel" message, with a list of messages to be canceled contained in its
body rather than in the headers. Whether this needs to have a Control
header at all, and whether the existing "nocem-on-spool" is adequate for
this purpose, and indeed whether NOCEM as such should be part of this,
or some other, standard are issues that are yet to be addressed.]

      cancel-verb         = "cancel"
      cancel-arguments    = CFWS message-id

   The argument identifies the article to be cancelled by its message
   identifier.  The body SHOULD contain an indication of why the
   cancellation was requested. The cancel message SHOULD be posted to
   the same newsgroup(s), with the same distribution(s), as the article
   it is attempting to cancel.

                          News Article Format              February 2000

   A serving agent that elects to honour a cancel message SHOULD delete
   the target article completely and immediately (or at the minimum make
   the article unavailable for relaying or serving) and also SHOULD
   reject any copies of this article that appear subsequently. See also
   sections 8.3 and 8.4.

        NOTE: The former requirement [RFC 1036] that the From and/or
        Sender headers of the cancel message should match those of the
        original article has been removed from this standard, since it
        only encouraged cancel issuers to conceal their true identity,
        and it was not usually checked or enforced by canceling
        software.  Therefore, both the From and/or Sender headers and
        any Approved header should now relate to the entity responsible
        for issuing the cancel message.

7.6.  Ihave, sendme

   The "ihave" and "sendme" control messages implement a crude batched
   predecessor of the NNTP [NNTP] protocol. They are largely obsolete on
   the Internet, but still see use in conjunction with some transort
   protocols such as UUCP, especially for backup feeds that normally are
   active only when a primary feed path has failed. There is no
   requirement for relaying agents that do not support such transport
   protocols to implement them.

        NOTE: The ihave and sendme messages defined here have ABSOLUTELY
        NOTHING TO DO WITH NNTP, despite similarities of terminology.

   The two messages share the same syntax:

      ihave-arguments     = *( msg-id SP ) relayer-name
      sendme-arguments    = ihave-arguments
      relayer-name        = path-identity  ; see 5.6.1
      ihave-body          = *( msg-id CRLF )
      sendme-body         = ihave-body

   Msg-ids MUST appear in either the arguments or the body, but NOT
   both. Relayers SHOULD generate the form putting msg-ids in the body,
   but the other form MUST be supported for backward compatibility.

   The ihave message states that the named relaying agent has received
   articles with the specified message identifiers, which may be of
   interest to the relaying agents receiving the ihave message.  The
   sendme message requests that the agent receiving it send the articles
   having the specified message identifiers to the named relaying agent.

   These control messages are normally sent essentially as point-to-
   point messages, by using newgroups-names in the Newsgroups header of
   the form "to." followed by one of more components in the form of a
   relayer-name (see section 5.5.1 which forbids "to" as the first
   component of a newgroup-name). The control message SHOULD then be
   delivered ONLY to the relaying agent(s) identitifed by that relayer-
   name, and any relaying agent receiving such a message which includes
   its own relayer-name MUST NOT propagate it further. Each pair of
                          News Article Format              February 2000

   relaying agent(s) sending and receiving these messages MUST be
   immediate neighbors, exchanging news directly with each other. Each
   relaying agent advertises its new arrivals to the other using ihave
   messages, and each uses sendme messages to request the articles it
   lacks.

   To reduce overhead, ihave and sendme messages SHOULD be sent
   relatively infrequently and SHOULD contain reasonable numbers of
   message IDs. If ihave and sendme are being used to implement a backup
   feed, it may be desirable to insert a delay between reception of an
   ihave and generation of a sendme, so that a slightly slow primary
   feed will not cause large numbers of articles to be requested
   unnecessarily via sendme.

7.7.  Obsolete control messages.

   The following control message verbs are declared obsolete by this
   standard:

        sendsys
        version
        whogets
        senduuname
[There have been requests for some of these to be reinstated, but there
is no consensus, and in any case we would need authentication first.]

8.  Duties of Various Agents

   The following section sets out the duties of various agents involved
   in the creation, relaying and serving of Usenet articles.

   In this section, the word "trusted", as applied to the source of some
   article, means that an agent processing that article has verified, by
   some means, the identity of that source (which may be another agent
   or a poster).

        NOTE: In many implementations, a single agent may perform
        various combinations of the injecting, relaying and serving
        functions. Its duties are then the union of the various duties
        concerned.

8.1.  General principles to be followed

   There are two important principles that news implementors (and
   administrators) need to keep in mind. The first is the well-known
   Internet Robustness Principle:

        Be liberal in what you accept, and conservative in what you
        send.

   However, in the case of news there is an even more important
   principle, derived from a much older code of practice, the
   Hippocratic Oath (we will thus call this the Hippocratic Principle):

                          News Article Format              February 2000

        First, do no harm.

   It is VITAL to realize that decisions which might be merely
   suboptimal in a smaller context can become devastating mistakes when
   amplified by the actions of thousands of hosts within a few minutes.

   In the case of gateways, the primary corollary to this is:

        Cause no loops.

8.2.  Duties of an Injecting Agent

   An Injecting Agent is responsible for taking a proto-article from a
   posting agent and either forwarding it to a moderator or injecting it
   into the relaying system for access by readers.

   As such, an injecting agent is considered responsible for ensuring
   that any article it injects conforms with the rules of this standard
   and the policies of any newsgroups or hierarchies that the article is
   posted to. It is also expected to bear some responsibility towards
   the rest of the network for the behaviour of its posters (and
   provision is therefore made for it to be easily contactable by
   email).

   To this end injecting agents MAY cancel articles which they have
   previously injected (see 7.5).

8.2.1.  Proto-articles

   A proto-article is one that has been created by a posting agent and
   has not yet been injected into the news system by an injecting agent.
   It SHOULD NOT be propagated in that form to other than injecting
   agents.  A proto-article has the same format as a normal article
   except that some of the following mandatory headers MAY be omitted:
   Message-Id, Date and Path. These headers MUST NOT contain invalid
   values; they MUST either be correct or not present at all.

   A proto-article SHOULD NOT contain the '%' delimiter in any Path
   header, except in the rare cases where an article gets injected
   twice. It MAY contain path-identities with other delimiters in the
   pre-injection portion of the Path header (5.6.3).

8.2.2.  Procedure to be followed by Injecting Agents

   A injecting agent receives proto-articles from posting and followup
   agents. It verifies them, adds headers where required and then either
   forwards them to a moderator or injects them by passing them to
   serving or relaying agents.

   If an injecting agent receives an otherwise valid article that has
   already been injected it SHOULD either act as if it is a relaying
   agent or else pass the article on to a relaying agent completely
   unaltered. Exceptionally, it MAY reinject the article, perhaps as a
   part of some complex gatewaying process (in which case it will add a
                          News Article Format              February 2000

   second '%' delimiter to the Path header).  It MUST NOT forward an
   already injected article to a moderator.

   An injecting agent processes articles as follows:

   1. It SHOULD verify that the article is from a trusted source.
      However, it MAY allow articles in which headers contain "forged"
      email addresses, that is, addresses which are not valid for the
      known and trusted source, especially if they end in ".invalid".

   2. It MUST reject any article whose Date header is more than 24 hours
      into the past or into the future (cf. 5.1).

   3. It MUST reject any article that does not have the correct
      mandatory headers for a proto-article (5 and 8.2.1) present, or
      which contains any header that does not have legal contents.

   4. If the article is rejected, or is otherwise incorrectly formatted
      or unacceptable due to site policy, the posting agent MUST be
      informed (such as via an NNTP 44x response code) that posting has
      failed and the article MUST NOT then be processed further.

   5. The Message-ID and Date headers (and their content) MUST be added
      when not already present.

   6. A Path header with a tail-entry (5.6.3) MUST be correctly added if
      not already present (except that it SHOULD NOT be added if the
      article is to be forwarded to a moderator).

   7. The path-identity of the injecting agent with a '%' delimiter
      (5.6.2) MUST be prepended to the Path header; moreover, that
      path-identity MUST be an FQDN mailable address (5.6.2).
[At this point, we should mention the Injector-Info header if/when we
invent it.]

   8. The injecting agent MAY add other headers not already provided by
      the poster, but SHOULD NOT alter, delete or reorder any headers
      already present in the article (except for headers intended for
      tracing purposes). The injecting agent MUST NOT alter the body of
      the article in any way.
[An Injector-Info header would be mentioned as an example of tracing.]

   9. If the Newsgroups line contains one or more moderated groups and
      the article does NOT contain an Approved header, then the
      injecting agent MUST forward it to the moderator of the first
      (leftmost) moderated group listed in the Newsgroups line via
      email. The complete article SHOULD be encapsulated (headers and
      all) within the email, preferably using the Content-Type
      "application/news-transmission" (6.17.6.1).

   10.Otherwise, the injecting agent forwards the article to one or more
      relaying or serving agents.

                          News Article Format              February 2000

8.3.  Duties of a Relaying Agent

   A Relaying Agent accepts injected articles from injecting and other
   relaying agents and passes them on to relaying or serving agents
   according to mutually agreed policy. Relaying agents SHOULD accept
   articles ONLY from trusted agents.

   A relaying agent processes articles as follows:

   1. It MUST verify the leftmost entry in the Path header and then
      prepend its own path-identity with a '/' delimiter, and possibly
      also the verified path-identity of its source with a '?' delimiter
      (5.6.2).

   2. It MUST reject any article whose Date header is stale (see 5.1).

   3. It MUST reject any article that does not have the correct
      mandatory headers (section 5) present with legal contents.

   4. It SHOULD reject any article whose optional headers (section 6) do
      not have legal contents.

   5. It SHOULD reject any article that has already been sent to it (a
      database of message identifiers of recent messages is usually kept
      and matched against).

   6. It SHOULD reject any article that has already been Canceled,
      Superseded or Replaced by its author or by another trusted entity.

   7. It MAY reject any article without an Approved header posted to
      newsgroups known to be moderated (this practice is strongly
      recommended, but the information necessary to do it may not be
      available to all agents).

   8. It then passes articles which match mutually agreed criteria on to
      neighboring relaying and serving agents. However, it SHOULD NOT
      forward articles to sites whose path-identity is already in the
      Path header.

        NOTE: It is usual for relaying and serving agents to restrict
        the Newsgroups, Distributions, age and size of articles that
        they wish to receive.

   If the article is rejected as being invalid, unwanted or unacceptable
   due to site policy, the agent that passed the article to the relaying
   agent SHOULD be informed (such as via an NNTP 43x response code) that
   relaying failed. In order to prevent a large number of error messages
   being sent to one location, relaying agents MUST NOT inform any other
   external entity that an article was not relayed UNLESS that external
   entity has explicitly requested that it be informed of such errors.

   In order to prevent overloading, relaying agents SHOULD NOT routinely
   query an external entity (such as a key-server) in order to verify an
   article.

                          News Article Format              February 2000

[But do we want to say that it is OK if you then keep a decent-sized
cache?]

   Relaying agents MUST NOT alter, delete or rearrange any part of an
   article expect for the Path and Xref Headers.

8.4.  Duties of a Serving Agent

   A Serving Agent takes an article from a relaying or injecting agent
   and files it in a "news database". It also provides an interface for
   reading agents to access the news database. This database is normally
   indexed by newsgroup with articles in each newsgroup identified by an
   article-locater (usually in the form of a decimal number - see 6.14).

        NOTE: Since control messages are often of interest, but should
        not be displayed as normal articles in regular newsgroups, it is
        common for serving agents to make them available in a pseudo-
        newsgroup named "control" or in a pseudo-newsgroup in a sub-
        hierarchy under "control." (e.g. "control.cancel").

   A serving agent processes articles as follows:

   1. It MUST verify the leftmost entry in the Path header and then
      prepend its own path-identity with a '/' delimiter, and possibly
      also the verified path-identity of its source with a '?' delimiter
      (5.6.2).

   2. It MUST reject any article whose Date header is stale (see 5.1).

   3. It MUST reject any article that does not have the correct
      mandatory headers (section 5) present, or which contains any
      header that does not have legal contents.

   4. It SHOULD reject any article that has already been sent to it (a
      database of message identifiers of recent messages is usually kept
      and matched against).

   5. It SHOULD reject any article that has already been Canceled,
      Superseded or Replaced by its author or by another trusted entity,
      and delete any of such article that it already has in its news
      database.

   6. It MUST reject any article without an Approved header posted to
      any moderated newsgroup which it is configured to receive, and it
      MAY reject such articles for any newgroup it knows be moderated.

   7. It SHOULD generate a correct Xref header (6.14) for each article.

   8. Finally, it stores the article in its news database.

8.5.  Duties of a Posting Agent
                          News Article Format              February 2000

   A Posting Agent is used to assist the poster in creating a valid
   proto-article and forwarding it to an injecting agent.

   Postings agents SHOULD ensure that proto-articles they create are
   valid Netnews articles according to this standard and other
   applicable policies.

   Posting agents meant for use by ordinary posters SHOULD reject any
   attempt to post an article which cancels, Supersedes or Replaces
   another article of which the poster is not the author.

8.6.  Duties of a Followup Agent

   A Followup Agent is a special case of a posting agent and as such is
   bound by all the posting agent's requirements plus additional ones.
   Followup agents MUST create valid followups, in particular by
   providing correctly adjusted forms of those headers described as
   inheritable (4.2.2.2), notably the Newgroups header (5.5), the
   Subject header (5.4) and the References header (6.8), and they SHOULD
   observe appropriate quoting conventions in the body (see 4.3.2).

   Followup agents MUST by default follow the Followup-To header when
   deciding which newsgroups a followup is posted to; however posters
   MAY override the default if they wish.

   Followup agents MUST NOT attempt to send email to any address ending
   in ".invalid".  Followup agents SHOULD NOT email copies of the
   followup to the author of the precursor (or any other person) unless
   this has been explicitly requested.
[Mention the Mail-Copies-To header if/when we have that.]

8.7.  Duties of a Gateway

   NOT DONE
[Volunteers to write it? There is lots of useful material in [Son-of-
1036].]

9.  Security Considerations

[The following is taken from our previous draft, and is a much cut down
version of material in Son-of-1036. What else should be said, and should
more of the Son-of-1036 material be rescued?]

   There is no security. Don't fool yourself. Usenet is a prime example
   of an Internet Adhocratic-Anarchy; that is, an environment in which
   trust forms the basis of all agreements.  It works.

   Articles which are intended to have restricted distribution are
   dependent on the goodwill of every site receiving them.  The
   "Archive: no" header is available as a signal to automated archivers
   not to file an article, but that cannot be guaranteed.

                          News Article Format              February 2000

   The Distribution header makes provisions for articles which should
   not be propagated beyond a cooperating subnet. The key
          security word here cooperating subnet. The key security word
   here is "cooperating". When a machine is not configured properly, it
   may become uncooperative and tend to distribute all articles.

9.1.  Attacks

   The two categories of attack that news is most vulnerable to are
   Denial-of-Service and exploitations of particular implementations.
   Many have argued that "spam", massively crossposted or reposted
   articles constitutes a DoS attack in its own regard. This may be so.

   Sending off-topic messages is a matter for individual hierarchies and
   newsgroups to control. It is "cooperating". When a machine violation of this standard to "forge"
   an email address, that is, to use a valid email address which you are
   not entitled to use. All invalid email addresses used in headers MUST
   end in the ".invalid" top-level-domain. This facility is provided
   primarily for those who wish to remain anonymous, but do not
          configured properly, it care to
   take the additional precautions of using more sophisticated anonymity
   measures.

   It is possible that legal penalties may become uncooperative apply to sending unsolicited
   commercial email and/or news articles. Check with your local legal
   authorities.

10.  References

   [ANSI X3.4] "American National Standard for Information Systems -
      Coded Character Sets - 7-Bit American National Standard Code for
      Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.

   [ISO 10646] "International Standard - Information technology -
      Universal Multiple-Octet Coded Character Set (UCS) - Part 1:
      Architecture and Basic Multilingual Plane", ISO/IEC 10646-1, 1993.

   [ISO 3166] "Codes for the representation of names of countries and
      their subdivisions -- Part 1: Country codes", ISO 3166, 1997.

   [ISO 8859] International Standard - Information Processing - 8-bit
      Single-Byte Coded Graphic Character Sets.  Part 1: Latin alphabet
      No. 1, ISO 8859-1, 1987 Part 2: Latin alphabet No. 2, ISO 8859-2,
      1987 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988 Part 4: Latin
      alphabet No. 4, ISO 8859-4, 1988 Part 5: Latin/Cyrillic alphabet,
      ISO 8859-5, 1988 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987
      Part 7: Latin/Greek alphabet, ISO 8859-7, 1987 Part 8:
      Latin/Hebrew alphabet, ISO 8859-8, 1988

   [MESSFOR] P. Resnick, "Internet Message Format Standard", draft-
      ietf-drums-msg-fmt-07.txt, March 1998.

   [NNTP] S. Barber, "Network News Transport Protocol", draft-ietf-
      nntpext-base-*.txt.

                          News Article Format              February 2000

   [RFC 1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
      RFC 1034, November 1987.

   [RFC 1036] M. Horton and tend to
          distribute all articles.

9.1 Attacks

          The two categories R. Adams, "Standard for Interchange of attacks that news is most vulnerable to
          are Denial-of-Service
      USENET Messages", RFC 1036, December 1987.

   [RFC 1153] F. Wancho, "Digest Message Format", RFC 1153, April 1990.

   [RFC 1738] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform
      Resource Locators (URL)", RFC 1738, December 1994.

   [RFC 1847] J. Galvin, S. Murphy, S. Crocker, and exploitations of particular
          implementations. Many have argued that "spam", massively
          crossposted or reposted articles constitutes a DoS attack in
          its own regard. This may be so.

          Sending off-topic messages is a matter N. Freed, "Security
      Multiparts for individual hierarchies MIME: Multipart/Signed and newsgroups to control. It is Miltipart/Encrypted",
      RFC 1847, October 1995.

   [RFC 2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)",
      RFC 2015, October 1996.

   [RFC 2044] F. Yergeau, "UTF-8, a violation transformation format for Unicode
      and ISO 10646", RFC 2044, October 1996.

   [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part One: Format of this DRAFT to
          "forge" an email address, that is, to Internet Message Bodies",
      RFC 2045, November 1996.

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

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

   [RFC 2048] N. Freed, J. Klensin, and J. Postel, "Multipurpose
      Internet Mail Extensions (MIME) Part Four: Registration
      Procedures", RFC 2048, November 1996.

   [RFC 2119] S. Bradner, "Key words for use a valid email address
          which you are not entitled to use. All invalid email addresses
          used in headers MUST end in the ".invalid" top-level-domain.
          This facility is provided primarily for those who wish to remain
          anonymous, but do not care RFCs to take the additional precautions Indicate
      Requirement Levels", RFC 2119, March 1997.

   [RFC 2130] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.
      Atkinson, M. Crispin, and P. Svanberg, "The Report of
          using more sophisticated anonymity measures.

          It is possible that legal penalties may apply to sending
          unsolicited commercial email and/or news articles. Check with
          your local legal authorities.

10. Security Considerations

          Section 9 discusses security considerations.

11. References:

 [TEST-TLDS]
   Eastlake, the IAB
      Character Set Workshop held 29 February - 1 March, 1996", RFC
      2130, April 1997.

   [RFC 2142] D. Crocker, "Mailbox Names for Common Services, Roles and
      Functions", RFC 2142, May 1997.

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

   [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
      RFC 2279, January 1998.

   [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing
                          News Article Format              February 2000

      Architecture", RFC 2373, July 1998.

   [RFC 2606] D. Eastlake and A. Reserved Panitz, "Reserved Top Level DNS Names,
   draft-ietf-dnsind-test-tlds-xx.txt, May 1998

 [ANSI-X3.4] US-ASCII
   American National Standard Names",
      RFC 2606, June 1999.

   [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
      P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol --
      HTTP/1.1", RFC 2616, June 1999.

   [RFC 820] J. Postel and J. Vernon, "Assigned Numbers", RFC 820,
      January 1983.

   [RFC 822] D. Crocker, "Standard for Information Systems - Coded
   Character Sets - 7-Bit American National Standard Code the Format of ARPA Internet Text
      Messages.", STD 11, RFC 822, August 1982.

   [RFC 850] Mark R. Horton, "Standard for
   Information Interchange (7-Bit ASCII). ANSI X3.4, interchange of Usenet
      messages", RFC 850, June 1983.

   [RFC 976] Mark R. Horton, "UUCP mail interchange format standard",
      RFC 976, February 1986.

 [ISO-8859]
   International Standard - Information Processing - 8-bit
   Single-Byte Coded Graphic Character Sets - Part 1: Latin
   alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet
   No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO
   8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4,
   1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
   Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
   Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
   Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
   alphabet No. 5, ISO 8859-9, 1990. Part 10: Latin alphabet
   No. 6, ISO 8859-10, 1992.

 [ISO-10646]
   International

   [SMTP] John C. Klensin and Dawn P. Mann, "Simple Mail Transfer
      Protocol", draft-ietf-drums-smtpupd-*.txt.

   [Son-of-1036] Henry Spencer, "News article format and transmission",
      <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.

   [UNICODE] The Unicode Consortium, "The Unicode Standard - Information Version
      2.0", Addison-Wesley, 1996.

   [USEFOR] Charles H. Lindsey, "News Article Format", draft-ietf-
      usefor-article-format-*.txt.

11.  Acknowledgements

[It is intended to insert a list of those who have been prominent
contributors to the mailing list of the working group at this point.]

12.  Contact Addresses

Editor

      Charles. H. Lindsey
      5 Clerewood Avenue
      Heald Green
      Cheadle
      Cheshire SK8 3JU
      United Kingdom
      Phone: +44 161 437 4506
      Email: chl@clw.cs.man.ac.uk
                          News Article Format              February 2000

Working group chair

      David Barr
      Digital Island
      Email: barr@visi.com

   Comments on this draft should preferably be sent to the mailing list
   of the Usenet Format Working Group at

      usenet-format@landfield.com.

   This draft expires six months after the date of publication (see Page
   1) (i.e. in August 2000).

13.  Intellectual Property Rights

[The following are taken from RFC 2026. It is not entirely clear whether
all of this is necessary at this stage. Please can someone explain it to
me?]

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology -
   Universal Multiple-Octet Coded Character Set (UCS) - Part
   1: Architecture described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and Basic Multilingual Plane. ISO/IEC
   10646-1, 1993.

 [MESSFOR]

 [Originator-Info]
   draft-newman-msgheader-originfo-x.txt
   chris.newman@innosoft.com

 [RFC-822] e-mail message format
   Crocker, David H.: Standard
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the format result of ARPA
   Internet text messages. RFC 822, 1982-08-13.

 [RFC-850] netnews message format (obsolete)
   Horton, Mark R.: Standard an attempt made to
   obtain a general license or permission for interchange the use of Usenet
   messages. RFC 850, 1983-06.

 [RFC-976] UUCP mail interchange
   Horton, Mark R.: UUCP mail interchange format such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.
   RFC 976, 1986-02.

 [RFC-977] NNTP
   Kantor, Brian; Lapsley, Phil: Network news transfer
   protocol - a proposed standard for  Please address the stream-based
   transmission information to the IETF Executive
   Director.

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

   This document and translations of news. RFC 977, 1986-02.

 [RFC-1036] netnews message format
   Horton, Mark R.; Adams, R.: Standard for interchange it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of
   Usenet messages. RFC 1036, 1987-12.

 [RFC-1036BIS] netnews message format (memo)
   Spencer, Henry: News article format any kind,
   provided that the above copyright notice and transmission.
   1994-06-02.

 [RFC-1884] IP v6
   Hinden, Robert M.; Deering, Stephen E.: IP version 6
   addressing architecture. RFC 1884, 1995-12.

 [RFC-2045] MIME, part 1
   Freed, Ned; Borenstein, Nathaniel S.: Multipurpose this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet mail extensions (MIME), part 1: format Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet message bodies. RFC 2045, 1996-11.

 [RFC-2119] MUST/SHOULD/MAY
   Bradner, Scott: Key words standards in which case the procedures for use
   copyrights defined in RFCs the Internet Standards process must be
   followed, or as required to indicate
   requirement levels. RFC 2119, 1997-03.

 [RFC-2130] character-set memo
   Weider, Chris; Preston, Cecilia; Simonsen, Keld;
   Alvestrand, Harald T.; Atkinson, Randall; Crispin, Mark;
   Svanberg, Peter: translate it into languages other than
                          News Article Format              February 2000

   English.

   The report of limited permissions granted above are perpetual and will not be
   revoked by the IAB character set
   workshop. RFC 2130, 1997-04.

 [RFC-2142] standard mailbox names
   Crocker, David H.: Mailbox names for common services,
   roles Internet Society or its successors or assigns.

   This document and functions. RFC 2142, 1997-05.

 [RFC-2234] ABNF
   Crocker, David H.; Overell, Paul: Augmented BNF for syntax
   specifications: ABNF. RFC 2234, 1997-11.

 [RFC-2279] UTF-8
   Yergeau, Francois: UTF-8, the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Appendix A.1 - A-News Article Format

[There is some text present in Son-of-1036 at this point which may well
be removed to a transformation format of ISO
   10646. separate informational RFC 2279, 1998-01.

 [UNICODE] Unicode
  The Unicode Consortium: The Unicode Standard giving a proper historical
background.]

Appendix A.2 - Version 2.0.
  Addison-Wesley, 1996.

          Author's Address

          The Usenet Early B-News Article Format Working Group (usenet-format@clari.net)

          Deliberations were archived

[The same applies to this.]

[Son-of-1036 also had appendices on "Obsolete Headers" and "Obsolete
Control Messages". Do we want these? There are already mentioned at
          http://www.landfield.com/usefor/

          Chair:      Simon Lyall,  simon@darkmere.gen.nz
          Editor:     Dan Ritter,   dsr@bbn.com

          Members (alphabetical):

A. Deckers (Alain.Deckers@man.ac.uk)
Ade Lovett (ade@demon.net)
Andrew Gierth (andrew@erlenstar.demon.co.uk)
Bill Davidsen (davidsen@prodigy.com)
Bill McQuillan (mcquillan@mpa15ab.mv.unisys.com)
Brad Templeton (brad@clari.net)
Brian Hernacki (bhern@netscape.com)
Brian Kelly (bkelly@sulaco.com)
Bryan Ford (baford@sleepless.com)
Buddha Buck (bmbuck@acsu.buffalo.edu)
Charles Lindsey (chl@clw.cs.man.ac.uk)
Chris Newman (chris+ietf-usenet@iosoft.com)
Christian Weisgerber (naddy@mips.rhein-neckar.de)
Christopher Sedore (cmsedore@maxwell.syr.edu)
Claus Andre Farber (lists/usenet-format/clari.net@faerber.muc.de)
Clive D.W.  Feather (clive@demon.net)
Curt Welch (curt@kcwc.com)
D. J.  Bernstein (djb@koobera.math.uic.edu)
Dave Barr (barr@math.psu.edu)
Dave Hayes (dave@kachina.jetcafe.org)
Dave Mack (dmack@corp.webtv.net)
David C Lawrence (tale@isc.org)
David desJardins (desj@rt.com)
Denis McKeon (DMckeon@swcp.com)
Dirk Nimmich (dirk@roxel.ms.sub.org)
Doug Royer [N6AAW] (dougr@basilisk.Eng.Sun.COM)
Egil Kvaleberg (egil@kvaleberg.no)
Eivind Tagseth (eivindt@multinet.no)
Erik van der Poel (erik@netscape.com)
Erland Sommarskog (sommar@algonet.se)
Evan Champion (evanc@synapse.net)
Fergus Henderson (fjh@cs.mu.oz.au)
Frederic SENIS (fs@caduceus.frmug.org)
Fredric Logren (Fredric.Lonngren@uab.ericsson.se)
Greg Berigan (gberigan@cse.unl.edu)
Harald Alvestrand (Harald.T.Alvestrand@uninett.no)
Heiko Schlichting (heiko@cis.fu-berlin.de)
Heiko W.Rupp (hwr@pilhuhn.de)
Hrvoje Niksic (hniksic@srce.hr)
Ian Davis (iand@fdc.co.uk)
Ian G Batten (I.G.Batten@batten.eu.org)
John Moreno (phenix@interpath.com)
John Stanley (stanley@peak.org)
Jon Ribbens (jon@oaktree.co.uk)
Jonathan Grobe (grobe@netins.net)
Kai Heingsen (kai@khms.westfalen.de)
Karl Kleinpaste (karl@jprc.com)
Keeth Herron (kherron@campus.mci.net)
Kent Landfield (kent@landfield.com)
Kristian =?ISO-8859-1?Q?K=F6hntopp?= (KRIS@koehntopp.de)
Lars Magne Ingebrigtsen (lmi@gnus.org)
Leonid Yegoshin (egoshin@genesyslab.com)
Mark Hittinger (bugs@freebsd.netcom.com)
Mark Sidell (Mark.Sidell@forteinc.com)
Martin Forssen (maf@math.chalmers.se)
Martin J. Duerst (mduerst@ifi.unizh.ch)
Maurizio Codogno (mau@beatles.cselt.it)
Mick Brown (Mick.Brown@worldnet.att.net)
Mustafa Soysal MS57 (msoysal@mistik.express.net)
Oo Hovers (onno@surfer.xs4all.nl)
Paul Eggert (eggert@twinsun.com)
Paul Overell (richard@pillar.turnpike.com)
Per Abrahamsen (abraham@dina.kvl.dk)
Pete Resnick (presnick@qualcomm.com)
Peter =?ISO-8859-1?Q?Br=FClls?= (pb@Ecce-Terram.DE)
Peter Heirich (peter@heirich.in-berlin.de)
Ralph Babel <rbabel@babylon.pfm-mainz.de>
Richard Clayton (richard@pillar.turnpike.com)
Robert Elz (kre@muari.OZ.AU)
Russ Allbery (rra@stanford.edu)
R. Kelley Cook (kcook@ibm.net)
Seth Breidbart (sethb@panix.com)
Shmuel Metz (shmuel@os2bbs.com)
Simon Fraser (smfr@santafe.edu)
Stan Barber (sob@academ.com)
Sylvan Butler (SBUTLER@hpbs2024.boi.hp.com)
Terje Bless (link@tss.no)
Thomas Roessler (roessler+1036@sobolev.iam.uni-bo.de)
Tim Skirvin (tskirvin@math.uiuc.edu)
Todd Michel McComb (mccomb@best.com)
Tom Hughes (tom@compton.demon.co.uk)
Vera Heinau (heinau@cis.fu-berlin.de)
Wayne Davison (wayne@clari.net)
Wolfgang Schelongowski (skaranyi@xivic.ruhr.de)
appropriate places in the draft.]

Appendix B - Collected Syntax

   TO BE DONE