INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             January
                                             November 2006

                News Article Architecture and Protocols
                   <draft-ietf-usefor-usepro-05.txt>
                   <draft-ietf-usefor-usepro-06.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
    .QP Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working groups.
   Note that other groups may also distribute working documents as
   Internet-Drafts.

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

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

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

   This Internet-Draft will expire in July 2006. May 2007.

Abstract

   This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

   This Standard defines the architecture of Netnews systems and
   specifies the requirements to be met by software which originates,
   distributes, stores and displays Netnews articles.

   Backward compatibility has been a major goal of this endeavour, but
   where this standard and earlier documents or practices conflict, this
   standard should be followed. In most such cases, current practice is
   already compatible with these changes.

   A companion Best Current Practice document [USEAGE], addressing
   requirements which are present for Social rather than Normative
   reasons is in preparation.

[This is the latest in the line of USEPRO drafts. However, the USEFOR
Working Group is currently considering the possibility of a complete
rewrite of this document.]
                News Article Architecture and Protocols    November 2006

[The use of the words "this standard" within this document when
referring to itself does not imply that this draft yet has pretensions
to be a standard, but rather indicates what will become the case if and
                News Article Architecture and Protocols     January 2006
when it is accepted as an RFC with the status of a proposed or draft
standard.]

[Remarks enclosed in square brackets and aligned with the left margin,
such as this one, are not part of this draft, but are editorial notes to
explain matters amongst ourselves, or to point out alternatives, or to
assist the RFC Editor.]

[In this draft, references to [NNTP] are to be replaced by references to
the RFC arising from the series of drafts draft-ietf-nntpext-base-*.txt,
which has now passed its IETF last call.]

                           Table of Contents

1.  Introduction ..................................................    4
  1.1.  Basic Concepts ............................................    4
  1.2.  Objectives ................................................    4
  1.3.  Historical Outline ........................................    5
2.  Definitions, Notations and Conventions ........................    5
  2.1.  Definitions ...............................................    5
  2.2.  Defining the Architecture .................................    6    5
  2.3.  Identification of news servers ............................    7    6
  2.4.  Variant Header Fields .....................................    8
  2.5.  Textual Notations .........................................    8
3.  Changes to the existing protocols .............................    9
  3.1.  Protocol Changes ..........................................    9
  3.2.  Transitional Arrangements .................................   10
4.  Transport .....................................................   11
5.    9
4.  Definition of new Media Types .................................   12
  5.1.   10
  4.1.  Application/news-transmission .............................   12
  5.2.   10
  4.2.  Message/news obsoleted ....................................   13
  5.3.   11
  4.3.  Application/news-groupinfo ................................   13
  5.4.   11
  4.4.  Application/news-checkgroups ..............................   14
6.   12
5.  Control Messages ..............................................   15
  6.1.   13
  5.1.  Digital Signature of Header Fields ........................   16
  6.2.   14
  5.2.  Group Control Messages ....................................   16
    6.2.1.   14
    5.2.1.  The 'newgroup' Control Message ........................   16
      6.2.1.1.   15
      5.2.1.1.  The Body of the 'newgroup' Control Message ........   17
      6.2.1.2.   15
      5.2.1.2.  Initial Articles ..................................   17
      6.2.1.3.   15
      5.2.1.3.  Example ...........................................   18
    6.2.2.   16
    5.2.2.  The 'rmgroup' Control Message .........................   19
      6.2.2.1.   17
      5.2.2.1.  Example ...........................................   19
    6.2.3.   17
    5.2.3.  The 'mvgroup' Control Message .........................   19
      6.2.3.1.   17
      5.2.3.1.  Example ...........................................   21
    6.2.4.   19
    5.2.4.  The 'checkgroups' Control Message .....................   21
  6.3.   20
  5.3.  Cancel ....................................................   23
  6.4.   21
  5.4.  Ihave, sendme .............................................   23
  6.5.   22
  5.5.  Obsolete control messages.  ...............................   25
7.   23
6.  Duties of Various Agents ......................................   25
  7.1.   23
  6.1.  General principles to be followed .........................   26
  7.2.   24
  6.2.  Duties of an Injecting Agent ..............................   26
    7.2.1.   24
    6.2.1.  Proto-articles ........................................   27
    7.2.2.   25
    6.2.2.  Procedure to be followed by Injecting Agents ..........   27
                News Article Architecture and Protocols     January 2006

    7.2.3.   25
    6.2.3.  Procedure for Forwarding to a Moderator ...............   29
  7.3.   28
  6.3.  Duties of a Relaying Agent ................................   30
    7.3.1.   28
    6.3.1.  Path Header Field Example .............................   33
  7.4.   32
  6.4.  Duties of a Serving Agent .................................   34
  7.5.   33
                News Article Architecture and Protocols    November 2006

  6.5.  Duties of a Posting Agent .................................   35
  7.6.
  6.6.  Duties of a Followup Agent ................................   36
    7.6.1.   35
    6.6.1.  Construction of the References header field ...........   36
  7.7.
  6.7.  Duties of a Reading Agent .................................   37
  7.8.
  6.8.  Duties of a Moderator .....................................   37
  7.9.
  6.9.  Duties of a Gateway .......................................   39
    7.9.1.
    6.9.1.  Duties of an Outgoing Gateway .........................   40
    7.9.2.
    6.9.2.  Duties of an Incoming Gateway .........................   41
    7.9.3.   40
    6.9.3.  Example ...............................................   43
8.   42
7.  Security and Related Considerations ...........................   44
  8.1.   43
  7.1.  Leakage ...................................................   44
  8.2.   43
  7.2.  Attacks ...................................................   44
    8.2.1.
    7.2.1.  Denial of Service .....................................   44
    8.2.2.
    7.2.2.  Compromise of System Integrity ........................   46
  8.3.   45
  7.3.  Liability .................................................   47
9.   46
8.  IANA Considerations ...........................................   47
10.
9.  References ................................................... ....................................................   47
  10.1.
  9.1.  Normative References ..................................... ......................................   47
  10.2.
  9.2.  Informative References ................................... ....................................   48
11.
10.  Acknowledgements .............................................   49
12.   48
11.  Contact Address ..............................................   49
Appendix A - Obsolete Control Messages ............................   49
Appendix B - Notices .............................................. Differences from the Protocols in RFC 1036 and its
derivatives .......................................................   50
Appendix C - Transitional Arrangements ............................   50
Appendix D - Notices ..............................................   51
Appendix E - Change Log ...........................................   51   52
                News Article Architecture and Protocols     January    November 2006

1.  Introduction

1.1.  Basic Concepts

   "Netnews" is a set of protocols for generating, storing and
   retrieving news "articles" (which resemble email messages) and for
   exchanging them amongst a readership which is potentially widely
   distributed. It is organized around "newsgroups", with the
   expectation that each reader will be able to see all articles posted
   to each newsgroup in which he participates. These protocols most
   commonly use a flooding algorithm which propagates copies throughout
   a network of participating servers.  Typically, only one copy is
   stored per server, and each server makes it available on demand to
   readers able to access that server.

   "Usenet" "articles", as introduced in F-1.1.

   "Usenet" is a particular worldwide publicly accessible network based
   upon the Netnews protocols, with the newsgroups being organized into
   recognized "hierarchies".  Anybody can join (it is simply necessary
   to negotiate an exchange of articles with one or more other
   participating hosts).

   An important characteristic of Usenet is the lack of any requirement
   for a central administration or for the establishment of any
   controlling host to manage the network. Nevertheless, administrative
   agencies do exists with varying degrees of authority to establish
   "policies" applicable to particular parts of Usenet.

   A "policy" is a rule intended 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
   in breach of established policy can cause considerable annoyance to
   their recipients.
[Could omit that last sentence.] sentence, and perhaps even the whole paragraph?]

1.2.  Objectives

   The purpose of this present standard is to define the overall
   architecture and the protocols to be used for Netnews in general, and
   for Usenet in particular, and to set standards to be followed by
   software that implements those protocols. A The companion standard
   [USEFOR] sets out the canonical format of news articles exchanged
   between the various agents comprising that architecture. In this
   standard, references to individual sections in the companion [USEFOR]
   are prefixed with "F-".

   A set of hosts within a network which, by mutual arrangement,
   operates some variant (whether more or less restrictive) of the
   Netnews protocols is a "cooperating subnet".
[It is not clear whether we still need that definition.]
                News Article Architecture and Protocols     January 2006

   It is NOT the purpose of this standard to settle matters of policy,
   nor aspects of software behaviour which do not impinge upon the
   generation, transmission, storage and reception of articles, nor how
   the authority of various agencies to create such policies and to
   exercise control or oversight of the various parts of Usenet is
   established. For these purposes, a separate Best Current Practice
   document [USEAGE] is being provided.

                News Article Architecture and Protocols    November 2006

   Nevertheless, it is assumed that such agencies with the necessary
   authority will exist, and tools are provided within the protocols for
   their use.

1.3.  Historical Outline

   Network news originated as the medium of communication for Usenet,
   circa 1980.  Since then, Usenet has grown explosively, and many
   Internet and non-Internet sites participate in it.  In addition, the
   news technology is now in widespread use for other purposes, on the
   Internet and elsewhere.

   For an account of the earlier formats used in Netnews prior to [RFC
   1036], see Henry Spencer's 1994 draft, popularly referred to as "Son
   of 1036" [Son-of-1036], which has recently been republished as an
   Informational RFC.
[That is a tentative statement, which may need revision.]

   Although never adopted as a formal standard, [Son-of-1036] had a
   considerable effect on the development of Netnews and hence on these
   present standards, and it is hoped that we have followed its spirit
   and intentions.
    .nr H1 1

2.  Definitions, Notations and Conventions

2.1.  Definitions

   All the technical terms defined in F-1.5 are to be considered as
   defined also, with the same meaning, in this standard.  In addition,
   some further terms are defined here, and in the following section.

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

   The "semantic content" (often abbreviated to just "content" when the
   context is clear) of a header field is its semantic interpretation;
   i.e. what remains after unfolding it and removing its field name with
   its colon and any leading and trailing whitespace and, in the case of
   structured header fields only, ignoring comments and other
   semantically invisible items and replacing white space by a single
   SP.

                News Article Architecture and Protocols     January 2006 See 6.6.1 for the use of this term.

2.2.  Defining the Architecture

   A Netnews system is a distributed database composed of agents of
   various types which, acting together according to the protocols
   defined in section 7 6 of this standard, causes articles to be
   propagated throughout the system and to be made available to its
   readers. The protocols ensure that all copies of a given article,
   wherever stored, are identical apart from those header fields defined
   as variant (2.4).  For explaining the working of the protocols, it is
   convenient to define particular sub-categories of agent as follows:

                News Article Architecture and Protocols    November 2006

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

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

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

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

   A "relaying agent" is software which receives allegedly compliant
   articles from injecting agents and/or other relaying agents, and
   possibly passes copies on to other relaying agents and "serving "storage
   agents".

   A "serving "storage agent" receives an article from a relaying agent and files
   it in a "news database". It also provides an interface for reading
   agents to access the news database.
[There is a suggestion that "serving agent" should be changed to
"storage agent" throughout.]

   A "news database" is the set of articles and related structural
   information stored by a serving storage agent and made available for access
   by reading agents.

   A "gateway" is software which receives news articles and converts
   them to messages of some other kind (e.g. mail to a mailing list), or
   vice versa; in essence it is a translating relaying agent that
   straddles boundaries between different methods of message exchange.
   The most common type of gateway connects newsgroup(s) to mailing
   list(s), either unidirectionally or bidirectionally, but there are
   also gateways between news networks using the [USEFOR] news format
   and those using other formats.

   Posting, reading and followup agents (which are usually just
   different services provided by the same piece of software) together
   comprise the "user agents" defined in F-1.5.

                News Article Architecture and Protocols     January 2006

   Likewise, injecting, relaying and serving storage agents (which are often
   just different services provided by the same piece of software)
   together comprise the "news servers".

2.3.  Identification of news servers

[The format of the Path header is still under discussion (ticket #1047).
Hence the following texts are tentative, and will need to be changed (as
will the associated protocols in 7.3).  Moreover, there

[There are two alternative texts which have been proposed:]

   In order to record the passage of articles through the network, news
   servers need to identify themselves by means of a <path-identity>
   (F-3.1.6),
   (F-3.1.5), which can appear in Path, Injection-Info and Xref header
   fields. Whatever <path-identity> is used in the Path header field
                News Article Architecture and Protocols    November 2006

   SHOULD be used also in any Injection-Info header field (and it would
   be normal to use it in any Xref header field also).
[Maybe that last sentence moves elsewhere.]

        NOTE: Such <path-identity>s may also be suitable for sending
        email to news server administrators (see [USEAGE]).

[1st alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. 1. A fully qualified domain name (FQDN) that SHOULD be resolvable in
      the DNS (whether via an A, AAAA or MX record or an equivalent
      CNAME), thus guaranteeing a unique identity. Ideally, it will also
      provide a means to contact the administrators by email (according
      to [RFC 2142], the forms "usenet@server" and "news@server" are
      common addresses for a news server administrator).

   2. Some other (arbitrary) name in the form of a <path-nodot>, and
      believed to be unique and registered at least with all other news
      servers sending articles directly to the given one. This option
      SHOULD NOT be used unless the earlier option is unavailable (e.g.
      because the server in question is not connected to the Internet),
      or unless it is of longstanding usage and cessation would be
      unduly disruptive, or unless the earlier option is provided as
      well.

[2nd alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that can be resolved to an
      email server via an MX, A or AAAA record according to the
      procedures of [RFC 2821]; this guarantees that the name is unique,
      and makes it easy to contact the administrators if needed.

                News Article Architecture and Protocols     January 2006

   2. A fully qualified domain name (FQDN) that is guaranteed to be
      unique by the administrators of the domain; for instance, the
      uniqueness of "server.example.org" could be guaranteed by the
      administrator of "example.org" even if nothing is stored in the
      DNS for that name.

   3. Some other (arbitrary) name in the form of a <path-nodot>, and
      believed to be unique and registered at least with all other
      news-servers sending articles directly to the given one. This
      option SHOULD NOT be used unless the earlier options are
      unavailable, or unless the name is of longstanding usage and
      cessation would be unduly disruptive, or unless one of the earlier
      options is provided as well.

                News Article Architecture and Protocols    November 2006

   According to [RFC 2142]], the forms "usenet@server" and "news@server"
   are common addresses for a news server administrator.
[end of alternatives]

        NOTE: Although domain names are case insensitive and it is
        intended that <path-nodot>s should also be so, it is customary
        to render them all in lowercase, since many implementations
        compare them case sensitively for reasons of efficiency.

        NOTE: A news server administrator who chooses a name <path-nodot>
        which turns out not to be unique (disregarding case) will have
        to bear the consequences.

        NOTE: The An IP address is not permitted as a <path-identity>,
        although it may still appear in a <diag-identity>. Since the
        syntax permits the a colon character (which, (":"  which, prior to this standard, was a <path-delimiter>)
        an alternative to the "!"  delimiter) within any <path-
        identity> <diag-identity>
        which is in takes the form of an <IPv6address>.  It <IPv6address>, it would
        therefore be unwise to choose,
        choose as such a name, <path-nodot> anything composed solely from four (or less) or
        less hexadecimal digits.

2.4.  Variant Header Fields

   Header fields with the variant property may differ between (or even
   be completely absent from) copies of the same article as stored or
   relayed throughout a Netnews system. The manner of the difference (or
   absence) MUST be as specified in this (or some future) standard.
   Typically, these header fields are modified as articles are
   propagated, or they reflect the status of the article on a particular
   serving
   storage agent, or cooperating group of such agents. A variant header
   field MAY be placed anywhere within the header fields (though placing
   it first is recommended).

   The following header fields are classified as "variant":
     o Path (F-3.1.6) (F-3.1.5) - augmented at each relaying agent that an article
       passes through.
     o Xref (F-3.2.11) (F-3.2.14) - used to keep track of the <article-locator>s of
       crossposted articles so that reading agents serviced by a
       particular serving storage agent can mark such articles as read.
     o Injection-Info (F-3.2.14) (F-3.2.8) is also considered variant in some
       special situations involving reinjection (7.2 (6.2 and 7.2.2). 6.2.2).

2.5.  Textual Notations

   This standard contains explanatory NOTEs using the following format.
   These 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 in context, or to suggest possible
   implementation techniques.

                News Article Architecture and Protocols     January 2006

        NOTE: While such explanatory notes may seem superfluous in
        principle, they often help the less-than-omniscient reader grasp
        the purpose of the specification and the constraints involved.
        Given the limitations of natural language for descriptive
                News Article Architecture and Protocols    November 2006

        purposes, this improves the probability that implementors and
        users will understand the true intent of the specification in
        cases where the wording is not entirely clear.

   "US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4].
   US-ASCII is a 7 bit character set. Please note that this standard
   requires that all agents be 8 bit clean; that is, they must accept
   and transmit data without changing or omitting the 8th bit.

   Certain words, when capitalized, are used to define the significance
   of individual requirements. The key words "MUST", "REQUIRED",
   "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
   associated with the word "NOT", are to be interpreted as described in
   [RFC 2119].

        NOTE: A requirement imposed on a relaying or serving storage agent
        regarding some particular article should be understood as
        applying only if that article is actually accepted for
        processing (since any agent may always reject any article
        entirely, for reasons of site policy).

   Wherever the context permits, use of the masculine includes the
   feminine and use of the singular includes the plural, and vice versa.

   Throughout this standard we will give examples of various
   definitions, header fields and other specifications. It needs to be
   remembered that these samples are for the aid of the reader only and
   do NOT define any specification themselves.  In order to prevent
   possible conflict with "Real World" entities and people the top level
   domain ".example" is used in all sample domains and addresses. The
   hierarchy "example.*" is also used as a sample hierarchy.
   Information on the ".example" top level domain is in [RFC 2606].

3.  Changes to the existing protocols

   This standard prescribes many changes, clarifications and new
   features since the protocols described  Transport

   As in this standard's predecessors, the exact means used to transmit
   articles from one host to another is not specified. NNTP [RFC 1036] and [Son-of-
   1036].  It 3977]
   is the intention that they can be assimilated into Usenet
   as it presently operates without major interruption to most common transmission method on the service
   (3.2), though some Internet, but much
   transmission takes place entirely independent of the new features may not begin to show benefit
   until they become widely implemented.  Changes Internet. Other
   methods in use include the syntax and
   format are documented UUCP protocol [RFC 976] extensively used
   in F-Appendix B the early days of Usenet, FTP, tunneling through email using
   application news/transmission, downloading via satellite, tape
   archives, and changes to control messages physically delivered magnetic and optical media.

   Transmission paths for news articles MUST treat news articles as
   uninterpreted sequences of octets, excluding the protocols are documented below.

3.1.  Protocol Changes

     o There is a new Control message 'mvgroup' to facilitate moving a
       group to a different place (name) in a hierarchy.
     o Certain Control messages (Appendix A) have been made obsolete, values 0 (US-ASCII
   NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the special significance of "cmsg" when at
   combination CRLF which denotes a line separator).

        NOTE: this corresponds to the start range of a
                News Article Architecture and Protocols     January 2006

       Subject header field has been removed (section 6).
     o Additional media types are defined octets permitted for better structuring of
       control messages (5.3 and 5.4).
     o Distributions are expected to MIME
        "8bit data" [RFC 2045].  Thus raw binary data cannot be checked at the receiving end, as
       well as
        transmitted in an article body except by the sending end, use of a relaying link.
     o There are numerous other small changes, clarifications Content-
        Transfer-Encoding such as base64.

                News Article Architecture and
       enhancements.

3.2.  Transitional Arrangements

   An important distinction must be made between news servers, which are
   responsible for Protocols    November 2006

   In particular, transmission paths MUST convey all header fields
   (including body part header fields and header fields within
   message/rfc822 objects) intact, even if they contain octets in the distribution
   range 128 to 255.  Furthermore, relaying agents MUST, and other
   agents SHOULD, convey lines even if they exceed 998 characters in
   length, especially in article bodies. These requirements include the
   transmissiom paths between posting agents, injecting agents, relaying
   agents, storage of news articles, agents and
   user reading agents, which are responsible for interactions with users. It is
   important that but NOT the former should paths
   traversed by Netnews articles that have been gatewayed into Email
   (6.9.1).
[At some point it will be upgraded to conform necessary for the IMAP standards to this catch up
with these requirements.]

4.  Definition of new Media Types

   This standard as soon as possible defines (or redefines) several new Media Types, which
   require to provide be registered with IANA as provided for in [RFC 4288].

4.1.  Application/news-transmission

   The Media Type "application/news-transmission" is intended for the benefit
   encapsulation of complete news articles where the enhanced
   facilities.  Fortunately, intention is that
   the number of distinct implementations of
   such servers recipient should then inject them into Netnews. This Application
   type provides one of the methods for mailing articles to moderators
   (see 6.2.2) and it is rather small, at least so far as also the main "backbone" preferred method when sending to an
   email-to-news gateway (see 6.9.2).

        NOTE: The benefit of Usenet such encapsulation is concerned, that it removes
        possible conflict between news and many of the new features are already
   supported. Contrariwise, there are email header fields and it
        provides a great number of implementations convenient way of user agents, installed on "tunnelling" a vastly greater number news article through
        a transport medium that does not support 8bit characters.

   The MIME Media Type definition of small sites.
   Therefore, the new functionality has been designed so "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 existing
   user agents may continue to be used, although of
                             the full benefits article transmitted MAY be supplied
                             (perhaps en route) to ensure correct
                             transmission over some 7bit transport
                             medium.
   Security considerations:  A news article may
   not be realised until a substantial proportion of them have been
   upgraded.

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

     o [RFC 2822] style <comment>s could have been prohibited in the case of
       those header fields of particular concern to news servers. They
       are unlikely to hinder their proper display in existing reading
       agents except in effects on the case recipient
                             host's system beyond just storage of the References header field in
       agents which thread articles. [USEFOR] therefore provides that
       they SHOULD NOT
                             article. However, such control messages
                             also occur in normal news flow, so most
                             hosts will already be generated suitably defended
                             against undesired effects.
   Published specification:  [USEPRO]
                News Article Architecture and Protocols    November 2006

   Body part:                A complete article or proto-article, ready
                             for injection into Netnews, or a batch of
                             such articles in the batch format described
                             in section 5.4.

        NOTE: It is likely that case.
     o Because the recipient of its importance an "application/news-
        transmission" will be a specialized gateway (e.g. a moderator's
        submission address) able to all serving agents, accept articles with only one of the whitespace
        three usage parameters "moderate", "inject" and folding in Newsgroups header fields newly permitted by
       [USEFOR] SHOULD NOT be generated (though it MUST be accepted);
       this restriction may well be removed "relay", hence
        the reason why they are optional, being redundant in a future version of this
       standard.
[That last bit needs discussion. It should probably most
        situations. Nevertheless, they MAY be moved to USEFOR
if it is used to be retained.]
     o The new style of Path header field, using "!!" as a <path-
       delimiter>, is already consistent signify the
        originator's intention with regard to the previous standards.
       However, transmission, so
        removing any possible doubt.

   When the intention parameter "relay" is that relaying agents should eventually
       reject articles in used, or implied, the old style, and so this possibility should body part MAY be offered as
   a configurable option in relaying agents. User
       agents are unaffected.
     o The introduction by [USEFOR] batch of MIME reflects a practice that is
       already widespread.  Articles articles to be transmitted together, in strict compliance with which case the
       previous standards (using strict US-ASCII) will be unaffected.
       Many user agents already support it, at least to the extent of
       widely used charsets such as ISO-8859-1. Users expecting to read
       articles using other charsets will need to acquire suitable
       reading agents. It is not intended,
   batch format defined in general, that any single
                News Article Architecture and Protocols     January 2006

       user agent will section 5.4 MUST be able to display every charset known to used.

4.2.  Message/news obsoleted

   The Media Type "message/news", as previously registered with IANA,
       but all such agents MUST support US-ASCII. Serving is
   hereby declared obsolete. It was never widely implemented, and relaying its
   default treatment as "application/octet-stream" by agents are that did
   not affected.
     o recognize it was counter productive. The new Control: mvgroup command will need to Media Type
   "message/rfc822" SHOULD be implemented used in
       serving agents. For the benefit of older serving agents it its place.

4.3.  Application/news-groupinfo

   The "application/news-groupinfo" is
       therefore RECOMMENDED that it be followed shortly by a
       corresponding newgroup command used in conjunction with the
   "newgroup" (5.2.1) and it "mvgroup" (5.2.3) control messages.  The
   <newsgroup-name> in the <newsgroups-line> MUST always be followed by
       a rmgroup command for agree with the old group after
   <newsgroup-name> in the "newgroup" or "mvgroup" control message.  The
   Media Type "application/news-groupinfo" MUST NOT be used except as a reasonable overlap
       period. An implementation
   part of such control messages.

   The "application/news-groupinfo" body part contains brief information
   about a newsgroup, i.e. the mvgroup command as an alias for group's name, it's <newsgroup-
   description> and the newgroup command would thus be minimally conforming. User
       agents are unaffected.
     o Provision <moderation-flag>.

        NOTE: The presence of the <newsgroups-tag> "For your newsgroups
        file:" is made for relaying and serving agents intended to use the Date
       header field in make the case whole newgroup message compatible
        with current practice as described in [Son-of-1036].

   The MIME Media Type definition of articles injected through existing
       agents which do not yet provide an Injection-Date header field.
     o All the header fields newly introduced "application/news-groupinfo" is:

   MIME type name:           application
   MIME subtype name:        news-groupinfo
   Required parameters:      none
   Disposition:              by [USEFOR] can safely default, inline
   Encoding considerations:  "7bit" or "8bit" is sufficient and MUST be
       ignored by existing software, albeit with loss of the new
       functionality.

4.  Transport

   As in this standard's predecessors, the exact means
                             used to transmit
   articles from one host to another is not specified. NNTP [NNTP] 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 the early days of Usenet, FTP, downloading via satellite, tape
   archives, and physically delivered magnetic and optical media.

   Transmission paths for news articles maintain compatibility.
   Security considerations:  this type MUST treat news articles NOT be used except as
   uninterpreted sequences part
                             of octets, excluding the values 0 (US-ASCII
   NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the
   combination CRLF which denotes a line separator).

        NOTE: this corresponds to the range of octets permitted control message for MIME
        "8bit data" [RFC 2045].  Thus raw binary data cannot be
        transmitted in an article body except by the use creation or
                             modification of a Content-
        Transfer-Encoding such as base64.

   In particular, transmission paths MUST convey all header fields
   (including body part header fields Netnews newsgroup
                News Article Architecture and header fields within
   message/rfc822 objects) intact, even if they Protocols    November 2006

   Published specification:  [USEPRO]

   The content of the "application/news-groupinfo" body part is defined
   as:

      groupinfo-body      = [ newsgroups-tag CRLF ]
                               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
                          = utext *( *WSP utext )
      moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
                               ; case sensitive "(Moderated)"

   The <newsgroup-description> MUST NOT contain octets in any occurrence of the
   range 128
   string "(Moderated)" within it.  Although optional, the <newsgroups-
   tag> SHOULD be included until such time as this standard has been
   widely adopted, to 255.  Furthermore, relaying agents MUST, and other
   agents SHOULD, convey lines even if they exceed 998 characters in
   length, especially in article bodies. These requirements include ensure compatibility with present practice.

   Moderated newsgroups MUST be marked by appending the
   transmissiom paths between posting agents, injecting agents, relaying
   agents, serving agents and reading agents, but NOT case sensitive
   text " (Moderated)" at the paths
   traversed by Netnews articles end. It is NOT recommended that have been gatewayed into Email
   (7.9.1).
[At some point it will be necessary for the IMAP standards to catch up
with these requirements.]
                News Article Architecture and Protocols     January 2006

5.  Definition of new Media Types

   This standard defines (or redefines) several new Media Types, which
   require to
   moderator's email address be registered with IANA as provided for included in [RFC 2048].

5.1.  Application/news-transmission

   The Media Type "application/news-transmission" the <newsgroup-description>
   as has sometimes been done.

        NOTE: There is intended no provision for the
   encapsulation use of complete news articles where the intention is that
   the recipient should then inject them into Netnews. This Application
   type provides one of the methods for mailing articles charsets other than
        US-ASCII within a <newsgroup-description>. Such a facility may
        be provided in a future extension to moderators
   (see 7.2.2) this standard.
[That may seem harsh, but if we make any such provision now, it will
make life more complicated and restrict our freedom when it is also comes to the preferred method when sending
proposed I18N extension. Therefore I resisted the temptation to an
   email-to-news gateway (see 7.9.2).

        NOTE: include
any charset parameter with this Media Type. Note that this also applies
to the checkgroups message further on.]

4.4.  Application/news-checkgroups

   The benefit of such encapsulation "application/news-checkgroups" Media Type is that it removes
        possible conflict between news and email header fields and it
        provides used in conjunction
   with the "checkgroups" control message (5.2.4).  It MUST NOT be used
   except as a convenient way part of "tunnelling" such control messages.

   The "application/news-checkgroups" body part contains a news article through complete list
   of all the newsgroups in a transport medium that does not support 8bit characters. (sub)hierarchy, their <newsgroup-
   description>s and their moderation status.

   The MIME Media Type definition of "application/news-transmission" "application/news-checkgroups" is:

   MIME type name:           application
   MIME subtype name:        news-transmission        news-checkgroups
   Required parameters:      none
   Optional parameters:      usage=moderate
                             usage=inject
                             usage=relay
                News Article Architecture and Protocols    November 2006

   Disposition:              by default, inline
   Encoding considerations:  A transfer-encoding (such as Quoted-
                             Printable  "7bit" or Base64) different from that of
                             the article transmitted MAY "8bit" is sufficient and MUST be supplied
                             (perhaps en route)
                             used to ensure correct
                             transmission over some 7bit transport
                             medium. maintain compatibility.
   Security considerations:  A news article may  this type MUST NOT be used except as part
                             of a "control message",
                             which could have effects on the recipient
                             host's system beyond just storage of the
                             article. However, such checkgroups control messages
                             also occur in normal news flow, so most
                             hosts will already be suitably defended
                             against undesired effects. message
   Published specification:  [USEPRO]
   Body part:                A complete article or proto-article, ready
                             for injection into Netnews, or a batch

   The content of
                             such articles in the batch format described
                             in section 6.4.

        NOTE: It "application/news-checkgroups" body part is likely that
   defined as:

      checkgroups-body    = *( valid-group CRLF )
      valid-group         = newsgroups-line ; see 4.3

5.  Control Messages

   The following sections document the recipient of an "application/news-
        transmission" will be control messages.  "Message" is
   used herein as a specialized gateway (e.g. synonym for "article" unless context indicates
   otherwise.

   Each <control-command> comprises a moderator's
        submission address) able to accept articles with only one of the
        three usage parameters "moderate", "inject" and "relay", hence <verb>, which indicates the reason why they are optional, being redundant in most
        situations. Nevertheless, they MAY be used action
   to signify be taken, and <argument>(s), which supply the
        originator's intention with regard to details (see F-
   3.2.3).  The following sections contain syntactic definitions for the transmission, so
        removing any possible doubt.

                News Article Architecture
   <verb>, <argument>s, and Protocols     January 2006

   When possibly the parameter "relay" is used, or implied, body, for each type of control
   message.

   The Newsgroups header field of each control message SHOULD include
   the body part MAY <newsgroup-name>(s) for the group(s) affected (i.e. groups to be
   a batch of
   created, modified or removed, or containing articles to be transmitted together, in which case canceled).
   This is to ensure that the
   batch format defined in section 6.4 MUST be used.

5.2.  Message/news obsoleted

   The Media Type "message/news", as previously registered with IANA, is
   hereby declared obsolete. message propagates to all sites which
   receive (or would receive) that group(s). It was never widely implemented, and its
   default treatment MAY include other
   <newsgroup-name>s so as "application/octet-stream" by agents that did to improve propagation (but this practice may
   cause the control message to propagate also to places where it is
   unwanted, or even cause it not recognize to propagate where it was counter productive. The Media Type
   "message/rfc822" SHOULD should, so it
   should not be used in its place.

5.3.  Application/news-groupinfo

   The "application/news-groupinfo" without good reason).

        NOTE: Propagation is used in conjunction with the
   "newgroup" (6.2.1) controlled by relaying agents, and "mvgroup" (6.2.3) it may
        be necessary for relaying agents to take special steps to ensure
        that control messages. messages such as newgroup messages for not-yet-
        existent newsgroups are propagated correctly (see 6.3).

   The
   <newsgroup-name> in the <newsgroups-line> MUST agree presence of a Subject header field whose content starts with the
   <newsgroup-name> in the "newgroup" or "mvgroup" control message.  The
   Media Type "application/news-groupinfo" MUST NOT be used except
   string "cmsg " followed by a <control-command> was construed under
   [RFC 1036] as a
   part of such request to perform that control messages.

   The "application/news-groupinfo" body part contains brief information
   about a newsgroup, i.e. the group's name, it's <newsgroup-
   description> action (even if no
   genuine Control header field was present). Indeed, some
   implementations went further and added the implied Control header
   field before injecting. Likewise, the <moderation-flag>.

        NOTE: The presence of a <newsgroup-name>
   ending in ".ctl" in the <newsgroups-tag> "For your newsgroups
        file:" is intended to make Newsgroups header field caused the whole newgroup message compatible Subject
   header field content (not starting with current practice as described "cmsg" in [Son-of-1036].

   The MIME Media 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 this case) to be
                             used
   interpreted as a <control-command>.

   All these practices, which have already largely fallen into disuse,
   are now declared to maintain compatibility.
   Security considerations:  this type be Obsolete, and Subject header fields MUST NOT
   now be used except interpreted as part
                             of a control message for the creation or
                             modification of a Netnews newsgroup
   Published specification:  [USEPRO]

   The content of the "application/news-groupinfo" body part is defined
   as:

      groupinfo-body      = [ newsgroups-tag CRLF ]
                               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:" <control-command>s under any circumstances.

                News Article Architecture and Protocols     January    November 2006

      newsgroups-line     = newsgroup-name
                               [ 1*HTAB newsgroup-description ]
                               [ 1*WSP moderation-flag ]
      newsgroup-description
                          = utext *( *WSP utext )
      moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
                               ; case sensitive "(Moderated)"

   The <newsgroup-description> MUST NOT contain any occurrence

[Possible addtional text:]

   In order to prevent continuing interpretation of the
   string "(Moderated)" within it.  Although optional, the <newsgroups-
   tag> SHOULD be included until such time as Subject header
   fields in this standard has been
   widely adopted, to ensure compatibility with present practice.

   Moderated newsgroups MUST be marked way by appending the case sensitive
   text " (Moderated)" at existing agents, posting and injecting agents
   SHOULD detect and decline to post articles in which the end. It is NOT recommended that Subject
   header field starts with the
   moderator's email address be included word "cmsg" and in the <newsgroup-description>
   as has sometimes been done.

        NOTE: There which there is no provision for the use of charsets other than
        US-ASCII within a <newsgroup-description>. Such a facility may
   Control header field.

   The descriptions below set out REQUIREMENTS to be provided in a future extension followed by sites
   that receive control messages and choose to this standard.
[That may seem harsh, but if we make honour them. However,
   nothing in these descriptions should be taken as overriding the right
   of any such provision now, it will
make life more complicated and restrict our freedom when it comes site, in accordance with its local policy, to the
proposed I18N extension. Therefore I resisted the temptation refuse to include
   honour any charset parameter with this Media Type. Note that this also applies particular control message, or to the checkgroups message further on.]

5.4.  Application/news-checkgroups

   The "application/news-checkgroups" Media Type refer it to an
   administrator for approval (either as a class or on a case-by-case
   basis).

5.1.  Digital Signature of Header Fields

   It is used most desirable that group control messages (5.2) in conjunction particular
   be authenticated by incorporating them within some digital signature
   scheme that encompasses other header fields closely associated with
   them (including at least Approved, Message-ID and Date). At the "checkgroups" control message (6.2.4).  It MUST NOT be used
   except as a part time
   of such control messages.

   The "application/news-checkgroups" body part contains a complete list writing, this is usually done by means of all the newsgroups in a (sub)hierarchy, their <newsgroup-
   description>s protocol known as
   "PGPverify" ([PGPVERIFY]), and their moderation status.

   The MIME Media Type definition continued usage 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" this is sufficient encouraged
   at least as an interim measure.

   However, PGPverify is not considered suitable for standardization in
   its present form, for various technical reasons. It is therefore
   expected that an early extension to this standard will provide a
   robust and MUST be
                             used general purpose digital authentication mechanism with
   applicability to all situations requiring protection against
   malicious use of, or interference with, header fields.  That
   extension would also address other Netnews security issues.

5.2.  Group Control Messages

   "Group control messages" are the sub-class of control messages that
   request some update to the configuration of the groups known to a
   storage agent, namely "newgroup", "rmgroup", "mvgroup" and
   "checkgroups", plus any others created by extensions to maintain compatibility.
   Security considerations: this type
   standard.

   Group control messages that attempt to create groups with names that
   are deprecated or reserved according to F-3.1.4 MUST NOT be used issued,
   except as part by prior agreement within some cooperating subnet.  Moreover,
   sites receiving such control messages SHOULD check them for
   conformance before honouring them.

   All of a checkgroups the group control message
   Published specification:  [USEPRO] messages MUST have an Approved header field
   (F-3.2.1) which, in those hierarchies where appropriate
   administrative agencies exist (see 1.1), identifies the appropriate
   person or entity as authorized by those agencies.  The content of authorized
   person or entity SHOULD adhere to any conventions and restrictions on
   the "application/news-checkgroups" body part is
   defined as: format of <newsgroup-name>s established for those hierarchies
                News Article Architecture and Protocols     January    November 2006

      checkgroups-body    = *( valid-group CRLF )
      valid-group         = newsgroups-line ; see 5.3

6.  Control Messages

   [USEAGE].

5.2.1.  The following sections document the control messages.  "Message" is
   used herein as a synonym for "article" unless context indicates
   otherwise.

   Each <control-command> comprises a <verb>, which indicates the action
   to be taken, and <argument>(s), which supply the details (see F-
   3.2.5).  The following sections contain syntactic definitions for the
   <verb>, <argument>s, and possibly the body, for each type of control
   message.
[The term <control-command> is now used to denote the syntactic object
within the 'newgroup' Control header field, to distinguish it from "control
message", which refers to the whole article.] Message

      control-command     =/ Newgroup-command
      Newgroup-command    = "newgroup" Newgroup-arguments
      Newgroup-arguments  = FWS newsgroup-name [ FWS newgroup-flag ]
      newgroup-flag       = "moderated"

   The Newsgroups header field of each "newgroup" control message SHOULD include
   the <newsgroup-name>(s) for requests that the group(s) affected (i.e. groups to specified group be
   created, modified
   created or removed, have its moderation status or containing articles to be canceled).
   This is to ensure that <newsgroups-line> changed.
   When the message propagates to all sites which
   receive (or would receive) that group(s). It MAY include other
   <newsgroup-name>s so as to improve propagation (but this practice may
   cause request is honoured, if the control message to propagate also to places where it <newgroup-flag> "moderated" is
   unwanted, or even cause it not to propagate where it should, so it
   should not
   present then the status of the group SHOULD be used without good reason).

        NOTE: Propagation marked as moderated,
   and vice versa.  "Moderated" is controlled the only such flag defined by relaying agents, and it may this
   standard; other flags MAY be necessary defined for relaying agents to take special steps to ensure
        that control messages such as use in cooperating subnets,
   but newgroup messages for not-yet-
        existent newsgroups are propagated correctly (see 7.3).

   The presence containing them MUST NOT be acted on outside of a Subject header field whose content starts with the
   string "cmsg " followed by a <control-command> was construed under
   [RFC 1036]
   those subnets.

        NOTE: Specifically, some alternative flags such as a request to perform that control action (even if no
   genuine Control header field was present). Indeed, "y" and "m",
        which are sent and recognized by some current software, are NOT
        part of this standard.  Moreover, some existing implementations went further
        treat any flag other than "moderated" as indicating an
        unmoderated newsgroup. Both of these usages are contrary to this
        standard and added control messages with such non-standard flags
        should be ignored.

5.2.1.1.  The Body of the implied 'newgroup' Control header
   field before injecting. Likewise, the presence Message

   The body of a <newsgroup-name>
   ending in ".ctl" in the Newsgroups header field caused newgroup message contains the Subject
   header field content (not starting with "cmsg" following subparts,
   preferably in this case) to be
   interpreted as a <control-command>.

   All these practices, which have already largely fallen into disuse,
   are now declared to be Obsolete, the order shown:

   1. An "application/news-groupinfo" part (4.3) containing the name and Subject header fields
      <newsgroups-line> (4.3) of the group. This part MUST NOT
   now be interpreted as <control-command>s under any circumstances.

[Possible addtional text:]

   In order to prevent continuing interpretation of Subject header
   fields in this way by existing agents, posting present
      and injecting agents SHOULD detect and decline be used to post articles in which update any copy of the Subject
   header field starts with <newsgroups-line>
      maintained by the word "cmsg" and in which storage agent.

   2. Other parts containing useful information about the background of
      the newgroup message (typically of type "text/plain").

   3. Parts containing initial articles for the newsgroup. See section
      5.2.1.2 for details.

   In the event that there is no
   Control only the single (i.e. application/news-
   groupinfo) subpart present, it will suffice to include a "Content-
   Type:  application/news-groupinfo" amongst the header fields of the
   control message.  Otherwise, a "Content-Type: multipart/mixed" header
   field will be needed, and each separate part will then need its own
   Content-Type header field.

5.2.1.2.  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 as soon as it has been created or modified. These parts are
                News Article Architecture and Protocols     January    November 2006

   identified by having the Media Type "application/news-transmission",
   possibly with the parameter "usage=inject".  The descriptions below set out REQUIREMENTS to body of each such
   part should be followed by sites
   that receive control messages a complete proto-article, ready for posting. This
   feature is intended for the posting of charters, initial FAQs and choose the
   like to honour them. However,
   nothing in these descriptions should be taken as overriding the right newly formed group.

   The Newsgroups header field of any such site, the proto-article MUST include the
   <newsgroup-name> of the newly created or modified group. It MAY
   include other <newsgroup-name>s. If the proto-article includes a
   Message-ID header field, the message identifier in accordance with its local policy, to refuse to
   honour it MUST be
   different from that of any particular existing article and from that of the
   control message, or to refer it to an
   administrator for approval (either message as a class or on whole.  Alternatively such a case-by-case
   basis).

6.1.  Digital Signature of Header Fields

   It message identifier
   MAY be derived by the injecting agent when the proto-article is most desirable
   posted. The proto-article SHOULD include the header field
   "Distribution: local".

   The proto-article SHOULD be injected at the storage agent that group
   processes the control messages (6.2) message AFTER the newsgroup in particular question has
   been created or modified.  It MUST NOT be authenticated by incorporating them within some digital signature
   scheme that encompasses other header fields closely associated with
   them (including at least Approved, Message-ID and Date). At injected if the time
   of writing, this newsgroup
   is usually done by means of a protocol known as
   "PGPverify" ([PGPVERIFY]), and continued usage of this not, in fact, created (for whatever reason). It MUST NOT be
   submitted to any relaying agent for transmission beyond the storage
   agent(s) upon which the newsgroup creation has just been effected (in
   other words, it is encouraged
   at least to be treated as an interim measure.

   However, PGPverify having a "Distribution:  local"
   header field, whether such a field is not considered suitable for standardization in
   its actually present form, for various technical reasons. or not).

        NOTE: It is therefore
   expected not precluded that an early extension to this standard will provide the proto-article is itself a
   robust and general purpose digital authentication mechanism with
   applicability to all situations requiring protection against
   malicious use of,
        control message or interference with, header fields.  That
   extension would also address other Netnews security issues.

6.2.  Group Control Messages

   "Group control messages" are the sub-class type of control messages that
   request some update special article, to the configuration be
        activated only upon creation of the groups known to a
   serving agent, namely "newgroup", "rmgroup", "mvgroup" and
   "checkgroups", plus any others created by extensions to this
   standard.

   Group control messages that attempt to create groups with names that
   are deprecated or reserved according to F-3.1.5 MUST NOT be issued, new newsgroup. However,
        except by prior agreement as might arise from that possibility, any
        "application/news-transmission" within some cooperating subnet.  Moreover,
   sites receiving such control messages SHOULD check them for
   conformance before honouring them.

   All of nested "multipart/*"
        structure within the group proto-article is not to be activated.

5.2.1.3.  Example

   A "newgroup" with its charter:

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.admin.info,example.admin.announce
      Date: 27 Feb 2006 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: admin@noc.example
      Control: newgroup example.admin.info moderated
      Message-ID: <ng-example.admin.info-20060227@noc.example>
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

      This is a MIME control messages MUST have an Approved header field
   (F-3.2.9) which, in those hierarchies where appropriate
   administrative agencies exist (see 1.1), identifies message.
      --nxtprt
      Content-Type: application/news-groupinfo

      For your newsgroups file:

                News Article Architecture and Protocols    November 2006

      example.admin.info      About the appropriate
   person or entity as authorized by those agencies. example.* groups (Moderated)

      --nxtprt
      Content-Type: application/news-transmission

      Newsgroups: example.admin.info
      From: "example.all Administrator" <admin@noc.example>
      Subject: Charter for example.admin.info
      Message-ID: <charter-example.admin.info-20020227@noc.example>
      Distribution: local
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit

      The authorized
   person or entity SHOULD adhere to any conventions and restrictions group example.admin.info contains regularly posted
      information on the format of <newsgroup-name>s established for those hierarchies
   [USEAGE].

6.2.1. example.* hierarchy.

      --nxtprt--

5.2.2.  The 'newgroup' 'rmgroup' Control Message

      control-command     =/ Newgroup-command
      Newgroup-command Rmgroup-command
      Rmgroup-command     = "newgroup" Newgroup-arguments
      Newgroup-arguments "rmgroup" Rmgroup-arguments
      Rmgroup-arguments   = FWS newsgroup-name [ FWS newgroup-flag ]
      newgroup-flag       = "moderated"
                News Article Architecture and Protocols     January 2006

   The "newgroup" "rmgroup" control message requests that the specified group be
   created or have its moderation status or <newsgroups-line> changed.
   When the request is honoured, if the <newgroup-flag> "moderated" is
   present then
   removed from the status list of valid groups. The Media Type of the group SHOULD be marked as moderated,
   and vice versa.  "Moderated" body is the only such flag defined by this
   standard; other flags
   unspecified; it MAY be defined contain anything, usually an explanatory text.

        NOTE: It is entirely proper for use a storage agent to retain the
        group until all the articles in cooperating subnets,
   but newgroup messages containing them MUST NOT be acted on outside of
   those subnets.

        NOTE: Specifically, some alternative flags such as "y" and "m",
        which are sent and recognized 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 it have expired, provided that
        it ceases to this
        standard and control messages with such non-standard flags
        should be ignored.

6.2.1.1. accept new articles.

5.2.2.1.  Example

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.admin.obsolete, example.admin.announce
      Date: 4 Apr 2006 22:04 -0900 (PST)
      Subject: cmsg rmgroup example.admin.obsolete
      Message-ID: <rm-example.admin.obsolete-20060404@noc.example>
      Approved: admin@noc.example
      Control: rmgroup example.admin.obsolete

      The Body of the 'newgroup' group example.admin.obsolete is obsolete. Please remove it
      from your system.

5.2.3.  The 'mvgroup' Control Message

      control-command   =/ Mvgroup-command
      Mvgroup-command   = "mvgroup" Mvgroup-arguments
      Mvgroup-arguments = FWS newsgroup-name FWS newsgroup-name
                             [ FWS newgroup-flag ]
                News Article Architecture and Protocols    November 2006

   The body of the newgroup "mvgroup" control message contains the following subparts,
   preferably in requests that the order shown:

   1. An "application/news-groupinfo" part (5.3) containing group specified by
   the name and
      <newsgroups-line> (5.3) of the group. This part MUST be present
      and SHOULD first <(old-)newsgroup-name> be used moved to update any copy of that specified by the <newsgroups-line>
      maintained
   second <(new-)newsgroup-name>. Thus it is broadly equivalent to a
   "newgroup" control message for the second group followed by a
   "rmgroup" control message for the serving agent.

   2. Other parts first group.

   The message body contains an "application/news-groupinfo" part (4.3)
   containing useful machine- and human-readable information about the background of
      the newgroup message (typically of type "text/plain").

   3. Parts containing initial articles new
   group, and possibly other subparts as for a "newgroup" control
   message. The information conveyed in the newsgroup. See section
      6.2.1.2 for details.

   In "application/news-groupinfo"
   body part, notably its <newsgroups-line> (4.3), is applied to the event that there new
   group.

   When this message is only received, the single (i.e. application/news-
   groupinfo) subpart present, new group is created (if it will suffice to include does
   not exist already) as for a "Content-
   Type:  application/news-groupinfo" amongst the header fields of the "newgroup" control message.  Otherwise, a "Content-Type: multipart/mixed" header
   field will message, and SHOULD in
   any case be needed, made moderated if a <newgroup-flag> "moderated" is
   present, and each separate part will then need its own
   Content-Type header field.

6.2.1.2.  Initial Articles

   Some subparts of vice versa. At the same time, arrangements SHOULD be
   made to remove the old group (as with a "newgroup" or "mvgroup" "rmgroup" control message MAY
   contain an initial set of articles message),
   but only after a suitable overlap period to be posted allow the network to
   adjust to the affected
   newsgroup as soon as it has been created or modified. These parts are
   identified by having new arrangement.

   At the Media Type "application/news-transmission",
   possibly with the parameter "usage=inject".  The body of each such
   part should be same time as a complete proto-article, ready for posting. This
   feature is intended for storage agent acts upon this message, all
   injecting agents associated with that storage agent SHOULD inhibit
   the posting of charters, initial FAQs and new articles to the
   like old group (preferably with some
   indication to the newly formed group.

   The Newsgroups header field of poster that the proto-article new group should have been used).
   Relaying agents, however, MUST include continue to propagate such articles
   during the
   <newsgroup-name> overlap period.

        NOTE: It is to be expected that different storage agents will
        act on this message at different points of time, users of the newly created or modified group. It MAY
   include other <newsgroup-name>s. If
        old group will have to become accustomed to the proto-article includes a
                News Article Architecture new arrangement,
        and Protocols     January 2006

   Message-ID header field, followups to already established threads will likely
        continue under the message identifier old group. Therefore, there needs to be an
        overlap period during which articles may continue to be accepted
        by relaying and storage agents in either group. This standard
        does not specify any standard period of overlap (though it MUST would
        be
   different from that expected to be expressed in days rather than in months). The
        inhibition of any existing article and from that injection of new articles to the
   control message as a whole.  Alternatively such a message identifier
   MAY be derived by old group may
        seem draconian, but it is the injecting agent when surest way to prevent the proto-article is
   posted. The proto-article SHOULD include the header field
   "Distribution: local".

   The proto-article SHOULD be injected at the serving agent that
   processes
        changeover from dragging on indefinitely.

   Since the "mvgroup" control message AFTER the newsgroup in question has
   been created or modified.  It MUST NOT be injected if the newsgroup is not, newly introduced in fact, created (for whatever reason). It MUST NOT this
   standard and may not be
   submitted to any relaying agent for transmission beyond the serving
   agent(s) upon which the newsgroup creation has just been effected (in
   other words, widely implemented initially, it is to SHOULD be treated as having
   followed shortly afterwards by a "Distribution:  local"
   header field, whether such corresponding "newgroup" control
   message; and again, after a field is actually present or not).

        NOTE: It is not precluded that the proto-article is itself reasonable overlap period, it MUST be
   followed by a "rmgroup" control message or other type of special article, for the old group.

   In order to facilitate a smooth changeover, storage agents MAY
   arrange to service requests for access to the old group by providing
   access to be
        activated only upon creation of the new newsgroup. However,
        except as might arise group, which would then contain, or appear to
   contain, all articles posted to either group (including, ideally, the
   pre-changeover articles from that possibility, any
        "application/news-transmission" within some nested "multipart/*"
        structure within the proto-article old one). Nevertheless, if this
   feature is not implemented, the articles themselves, as supplied to
   reading agents, MUST NOT be activated.

6.2.1.3.  Example

   A "newgroup" with its charter:

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.admin.info,example.admin.announce
      Date: 27 Feb 2002 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: admin@noc.example
      Control: newgroup example.admin.info moderated
      Message-ID: <ng-example.admin.info-20020227@noc.example>
      MIME-Version: 1.0
      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@noc.example>
      Subject: Charter for example.admin.info
      Message-ID: <charter-example.admin.info-20020227@noc.example>
      Distribution: local altered in any way (and, in particular,
                News Article Architecture and Protocols     January    November 2006

      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit

      The group example.admin.info contains regularly posted
      information on

   their Newsgroups header fields MUST contain exactly those newsgroups
   present when they were injected). On the example.* hierarchy.

      --nxtprt--

6.2.2.  The 'rmgroup' Control Message

      control-command     =/ Rmgroup-command
      Rmgroup-command     = "rmgroup" Rmgroup-arguments
      Rmgroup-arguments   = FWS newsgroup-name

   The "rmgroup" control message requests that other hand, the specified Xref header
   field (F-3.2.14) MAY contain entries for either group be
   removed from the list (or even both).

        NOTE: Some storage agents that use an "active" file permit an
        entry of valid groups. The Media Type the form "oldgroup xxx yyy =newgroup", which enables
        any articles arriving for oldgroup to be diverted to newgroup,
        thus providing a simple implementation of this feature. However,
        it is known that not all current storage agents will find
        implementation so easy (especially in the body short term) which is
   unspecified;
        why it MAY contain anything, usually an explanatory text.

        NOTE: It is entirely proper for a serving agent to retain the
        group until not mandated by this standard. Nevertheless, its
        eventual implementation in all storage agents is to be
        considered highly desirable.

        On the articles in other hand, it have expired, provided is recognized that
        it ceases to accept this feature would
        likely not be implementable if the new articles.

6.2.2.1.  Example

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.admin.obsolete, example.admin.announce
      Date: 4 Apr 2002 22:04 -0900 (PST)
      Subject: cmsg rmgroup example.admin.obsolete group was already in
        existence with existing articles in it. This situation should
        not normally arise except when there is already some confusion
        as to which groups are, or are not, supposed to exist in that
        hierarchy. Note that the "mvgroup" control message is not really
        intended to be used for merging two existing groups.

5.2.3.1.  Example

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.oldgroup,example.newgroup,example.admin.announce
      Date: 30 Apr 2006 22:04 -0500 (EST)
      Subject: cmsg mvgroup example.oldgroup example.newgroup moderated
      Message-ID: <rm-example.admin.obsolete-20020404@noc.example> <mvgroup-example.oldgroup-20060430@noc.example>
      Approved: admin@noc.example
      Control: rmgroup example.admin.obsolete mvgroup example.oldgroup example.newgroup moderated
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary=nxt

      --nxt
      Content-Type: application/news-groupinfo

      For your newsgroups file:
      example.newgroup        The new replacement group example.admin.obsolete (Moderated)

      --nxt

      The moderated group example.oldgroup is obsolete. replaced by
      example.newgroup. Please remove it
      from update your system.

6.2.3. configuration, and please,
      if possible, arrange to file articles arriving for
      example.oldgroup as if they were in example.newgroup.

      --nxt
      Content-Type: application/news-transmission

      Newsgroups: example.admin.info
      From: "example.all Administrator" <admin@noc.example>
      Subject: Charter for example.newgroup
      Message-ID: <mvgroup-example.newgroup-20020430@noc.example>
                News Article Architecture and Protocols    November 2006

      Distribution: local
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit

      This group (formerly known as example.oldgroup) is for the
      discussion of examples.

      --nxt--

5.2.4.  The 'mvgroup' 'checkgroups' Control Message

   The "checkgroups" control message contains a list of all the valid
   groups in a complete hierarchy.

      control-command     =/ Mvgroup-command
      Mvgroup-command Checkgroup-command
      Checkgroup-command  = "mvgroup" Mvgroup-arguments
      Mvgroup-arguments "checkgroups" Checkgroup-arguments
      Checkgroup-arguments= [ chkscope ] [ chksernr ]
      chkscope            = 1*( FWS ["!"] newsgroup-name )
      chksernr            = FWS newsgroup-name
                             [ FWS newgroup-flag ]

   The "mvgroup" control "#" 1*DIGIT

   A "checkgroups" message requests that the group specified by
   the first <(old-)newsgroup-name> be moved applies to any (sub-)hierarchy with a prefix
   listed in the <chkscope> argument, provided that specified by the
   second <(new-)newsgroup-name>. Thus it rightmost
   matching <newsgroup-name> in the list is broadly equivalent to not immediately preceded by
   a
   "newgroup" control message "!".  If no <chkscope> argument is given, it applies to all
   hierarchies for the second which group followed by statements appear in the body of the
   message.

        NOTE: Some existing software does not support the <chkscope>
        argument.  Thus a
   "rmgroup" control "checkgroups" message for SHOULD also contain the first group.
        groups of other subhierarchies the sender is not responsible
        for. "New" software MUST ignore groups which do not fall within
        the <chkscope> argument of the "checkgroups" message.

   The message body contains <chksernr> argument is a serial number, which can be any positive
   integer (e.g. just numbered or the date in YYYYMMDD).  It SHOULD
   increase by an "application/news-groupinfo" part (5.3)
   containing machine- and human-readable information about arbitrary value with every change to the new
   group, group list
   and possibly other subparts as for a "newgroup" control
   message. The information conveyed MUST NOT ever decrease.

        NOTE: This was added to circumvent security problems in
        situations where the "application/news-groupinfo"
   body part, notably Date header field cannot be authenticated.

   Example:

      Control: checkgroups de !de.alt #248

   which includes the whole of the 'de.*' hierarchy, with the exception
   of its <newsgroups-line> (5.3), is applied to 'de.alt.*' sub-hierarchy.

   The body of the new
   group. message has the Media Type "application/news-
   checkgroups" (4.4).  It asserts that the <valid-group>s it lists are
   the only newsgroups in the specified hierarchies.

                News Article Architecture and Protocols     January    November 2006

   When this

        NOTE: The "checkgroups" message is received, intended to synchronize the new group is created (if it does
   not exist already) as for
        list of newsgroups stored by a "newgroup" control message, storage agent, and SHOULD in
   any case their
        <newsgroup-description>s, with the lists stored by other storage
        agents throughout the network. However, it might be made moderated if inadvisable
        for the storage agent actually to create or delete any
        newsgroups without first obtaining the approval of its
        administrators for such proposed actions.

        NOTE: The possibility of removing a <newgroup-flag> "moderated" complete hierarchy by means
        of an "invalidation" line beginning with a '!' in the
        checkgroups-body is
   present, and vice versa. At 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 time, arrangements SHOULD effect,
        if required, can now be
   made to remove obtained by the old group (as use of an appropriate
        <chkscope> argument in conjunction with an empty <checkgroups-
        body>.

5.3.  Cancel

   The "cancel" message requests that a "rmgroup" control message),
   but only after a suitable overlap period to allow target article be "canceled",
   i.e. be withdrawn from circulation or access.

      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = FWS msg-id [FWS]

   The argument identifies the network article to
   adjust 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 new arrangement.

   At same newsgroup(s), with the same time distribution(s), as a serving the article
   it is attempting to cancel.

   A storage agent acts upon this message, all
   injecting agents associated with that serving agent elects to honour a "cancel" message SHOULD inhibit make
   the posting article unavailable for relaying or storage (perhaps by deleting
   it completely). If the target article is unavailable, and the
   acceptability of new articles to the old group (preferably with some
   indication to "cancel" message cannot be established without
   it, activation of the poster that "cancel" message SHOULD be delayed until the new group should have
   target article has been used).
   Relaying agents, however, MUST continue to propagate such articles
   during the overlap period. seen.  See also sections 6.3 and 6.4.

        NOTE: It is to be expected that different serving agents the security extension envisaged in
        section 5.1 will
        act on this make more detailed provisions for establishing
        whether honouring a particular "cancel" message at different points of time, users is in order. In
        particular, it is likely that there will be provision for the
        digital signature of 3rd party cancels (i.e. those issued other
        than by the
        old sender, the moderator, or the injector).

        NOTE: A cancel submitted by the poster for an article in a
        moderated group will have to become accustomed be forwarded to the new arrangement, moderator of that
        group, and followups to already established threads will likely
        continue under the old group. Therefore, there needs it is up to be an
        overlap period during which articles may continue that moderator to be accepted
        by relaying and serving agents in either group. This standard
        does not specify any standard period of overlap (though act upon it would
        be expected to be expressed in days rather than in months). (6.8).

        NOTE: The
        inhibition former requirement [RFC 1036] that the From and/or
        Sender header fields of injection the "cancel" message should match those
        of new articles to the old group may
        seem draconian, but original article has been removed from this standard,
                News Article Architecture and Protocols    November 2006

        since it is the surest way only encouraged cancel issuers to prevent the
        changeover from dragging on indefinitely.

   Since the "mvgroup" control message is newly introduced in this
   standard and may not be widely implemented initially, it SHOULD be
   followed shortly afterwards by a corresponding "newgroup" control
   message; conceal their true
        identity, and again, after a reasonable overlap period, it MUST be
   followed was not usually checked or enforced by a "rmgroup" control message for the old group.

   In order to facilitate a smooth changeover, serving agents MAY
   arrange to service requests for access to
        canceling software.  Therefore, both the old group by providing
   access From and/or Sender
        header fields and any Approved header field should now relate to
        the new group, which would then contain, or appear to
   contain, all articles posted to either group (including, ideally, entity responsible for issuing the
   pre-changeover articles from "cancel" message.

5.4.  Ihave, sendme

   The "ihave" and "sendme" control messages implement a crude batched
   predecessor of the old one). Nevertheless, if this
   feature is implemented, NNTP [RFC 3977] protocol. They are largely
   obsolete on the articles themselves, as supplied to
   reading agents, MUST NOT be altered in any way (and, Internet, but still see use in particular,
   their Newsgroups header fields MUST contain exactly those newsgroups
   present conjunction with some
   transport protocols such as UUCP, especially for backup feeds that
   normally are active only when they were injected). On the other hand, the Xref header
   field (F-3.2.11) MAY contain entries a primary feed path has failed. There
   is no requirement for either group (or even both).

        NOTE: Some serving relaying 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 do not support such
   transport protocols to newgroup,
        thus providing 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:

      control-command     =/ Ihave-command
      Ihave-command       = "ihave" Ihave-argument
      Ihave-argument      = relayer-name
      control-command     =/ Sendme-command
      Sendme-command      = "sendme" Sendme-argument
      Sendme-argument     = Ihave-argument
      relayer-name        = path-identity  ; see F-3.1.5
      ihave-body          = *( msg-id CRLF )
      sendme-body         = ihave-body

   The body of the message consists of a simple implementation list of this feature. However,
        it is known that not all current serving agents will find
        implementation so easy (especially <msg-id>s, one per
   line. [RFC 1036] also permitted the list of <msg-id>s to appear in
   the short term) which is
        why it is not mandated by <Ihave-> or <Sendme-argument> with the syntax
      Ihave-argument      = [FWS] *( msg-id FWS ) [relayer-name]
   but this standard. Nevertheless, its
        eventual implementation in all serving agents is to form SHOULD NOT now be
        considered highly desirable.

                News Article Architecture used, though relaying agents MAY
   recognize and Protocols     January 2006

        On the other hand, process it is recognized for backward compatibility.

   The "ihave" message states that this feature would
        likely not be implementable if the new group was already in
        existence with existing named relaying agent has received
   articles in it. This situation should
        not normally arise except when there is already some confusion
        as to with the specified message identifiers, which groups are, or are not, supposed may be of
   interest to exist in that
        hierarchy. Note that the "mvgroup" control relaying agents receiving the ihave message.  The
   "sendme" message is not really
        intended requests that the agent receiving it send the
   articles having the specified message identifiers to be used for merging two existing groups.

6.2.3.1.  Example

      From: "example.all Administrator" <admin@noc.example>
      Newsgroups: example.oldgroup,example.newgroup,example.admin.announce
      Date: 30 Apr 2002 22:04 -0500 (EST)
      Subject: cmsg mvgroup example.oldgroup example.newgroup moderated
      Message-ID: <mvgroup-example.oldgroup-20020430@noc.example>
      Approved: admin@noc.example
      Control: mvgroup example.oldgroup example.newgroup moderated
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary=nxt

      --nxt
      Content-Type: application/news-groupinfo

      For your newsgroups file:
      example.newgroup        The new replacement group (Moderated)

      --nxt

      The moderated group example.oldgroup the named
   relaying agent.

   Upon receipt of the sendme message, the receiving agent sends the
   article(s) requested, often (especially when the transport protocol
   is replaced by
      example.newgroup. Please update your configuration, and please,
      if possible, arrange to file articles arriving for
      example.oldgroup as if they were UUCP) in example.newgroup.

      --nxt
      Content-Type: application/news-transmission

      Newsgroups: example.admin.info
      From: "example.all Administrator" <admin@noc.example>
      Subject: Charter for example.newgroup
      Message-ID: <mvgroup-example.newgroup-20020430@noc.example>
      Distribution: local
      Content-Type: text/plain; charset=us-ascii
      Content-Transfer-Encoding: 7bit

      This group (formerly known as example.oldgroup) is for the
      discussion form of examples.

      --nxt--

6.2.4.  The 'checkgroups' Control Message one or more batches, each containing several
   articles. The "checkgroups" control message contains a list usual form of all a <batch> is defined by the valid
   groups following
   syntax (which is also used in a complete hierarchy. the application/news transmission media
   type (4.1)).

                News Article Architecture and Protocols     January    November 2006

      control-command     =/ Checkgroup-command
      Checkgroup-command  = "checkgroups" Checkgroup-arguments
      Checkgroup-arguments= [ chkscope ] [ chksernr ]
      chkscope

      batch             = 1*( FWS ["!"] newsgroup-name batch-header article )
      chksernr
      batch-header      = "#!" SP rnews SP article-size CRLF
      rnews             = %x72.6E.65.77.73 ; case sensitive "rnews"
      article-size      = FWS "#" 1*DIGIT

   A "checkgroups" message applies to any (sub-)hierarchy with

   Thus a prefix
   listed in the <chkscope> argument, provided that the rightmost
   matching <newsgroup-name> in the list <batch> is not immediately preceded a sequence of articles, each prefixed by a "!".  If no <chkscope> argument header
   line that includes its size. The <article-size> is given, it applies to all
   hierarchies for which group statements appear in the body a decimal count of
   the
   message.

        NOTE: Some existing software does not support the <chkscope>
        argument.  Thus a "checkgroups" message SHOULD also contain octets in the
        groups article, counting each CRLF as one octet regardless
   of other subhierarchies the sender how it is not responsible
        for. "New" software MUST ignore groups which do not fall within actually represented.

        NOTE: Despite the <chkscope> argument similarity of the "checkgroups" message.

   The <chksernr> argument this format to an executable
        UNIX script, it is EXTREMELY unwise to feed such a serial number, which can be any positive
   integer (e.g. just numbered or the date batch into a
        command interpreter in YYYYMMDD).  It SHOULD
   increase by an arbitrary value with every change to anticipation of it running a command
        named "rnews"; the group list
   and MUST NOT ever decrease.

        NOTE: This was added to circumvent security problems implications of so doing would be
        disastrous.

   These control messages are normally sent essentially as point-to-
   point messages, by using <newsgroup-name>s in
        situations where the Date Newsgroups header
   field cannot be authenticated.

   Example:

      Control: checkgroups de !de.alt #248

   which includes the whole of the 'de.*' hierarchy, with form "to."  followed by one (or possibly more)
   <component>s in the exception
   of its 'de.alt.*' sub-hierarchy.

   The body form of a <relayer-name> (see section F-3.1.4
   which forbids "to" as the first <component> of a <newsgroup-name>).
   The control message has SHOULD then be delivered ONLY to the Media Type "application/news-
   checkgroups" (5.4).  It asserts relaying
   agent(s) identified by that the <valid-group>s it lists are
   the only newsgroups in the specified hierarchies.

        NOTE: The "checkgroups" <relayer-name>, and any relaying agent
   receiving such a message is intended to synchronize the
        list which includes its own <relayer-name> MUST
   NOT propagate it further. Each pair of newsgroups stored by a serving agent, relaying agent(s) sending and their
        <newsgroup-description>s,
   receiving these messages MUST be immediate neighbours, exchanging
   news directly with each other. Each relaying agent advertises its new
   arrivals to the lists stored by other serving
        agents throughout using "ihave" messages, and each uses "sendme"
   messages to request the network. However, articles it might lacks.

   To reduce overhead, ihave and sendme messages SHOULD 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.

        NOTE: The possibility sent
   relatively infrequently and SHOULD contain reasonable numbers of removing
   message identifiers. If ihave and sendme are being used to implement
   a complete hierarchy by means backup feed, it may be desirable to insert a delay between
   reception of an "invalidation" line beginning with 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.

5.5.  Obsolete control messages.

   The following control messages (as described in the
        checkgroups-body is no longer provided Appendix A) are
   declared obsolete by this standard. standard:

        sendsys
        version
        whogets
        senduuname

6.  Duties of Various Agents

   The
        intent following section sets out the duties of various agents involved
   in the feature was widely misunderstood creation, relaying and it was
        misused more often than it was used correctly. The same effect,
        if required, can now storage of Netnews articles. Insofar as
   these duties are described as sequences of steps to be obtained by followed, it
   should be understood that it is the use effect of an appropriate
        <chkscope> argument in conjunction with an empty <checkgroups-
        body>. these sequences that is
                News Article Architecture and Protocols     January    November 2006

6.3.  Cancel

   The "cancel" message requests

   important, and implementations may use any method that a target article be "canceled",
   i.e. be withdrawn from circulation or access.

      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = FWS msg-id [FWS]

   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 gives rise to
   the
   that same newsgroup(s), with effect.

   In this section, the same distribution(s), word "verified", as the article
   it is attempting applied to cancel.

   A serving the source of
   some article, means that an agent processing that elects to honour a "cancel" message SHOULD make
   the article unavailable for relaying or serving (perhaps has
   established, by deleting
   it completely). If the target article is unavailable, and some means, the
   acceptability identity of the "cancel" message cannot that source (which may be established without
   it, activation
   another agent or a poster).

        NOTE: In many implementations, a single agent may perform
        various combinations of the "cancel" message SHOULD be delayed until the
   target article has been seen.  See also sections 7.3 injecting, relaying and 7.4.

        NOTE: It is expected that storage
        functions. Its duties are then the security extension envisaged in
        section 6.1 will make more detailed provisions for establishing
        whether honouring a particular "cancel" message is union of the various duties
        concerned.

6.1.  General principles to be followed

   There are two important principles that news implementors (and
   administrators) need to keep in order. In
        particular, it mind. The first is likely that there will be provision for the
        digital signature of 3rd party cancels (i.e. those issued other
        than by well-known
   Internet Robustness Principle:

        Be liberal in what you accept, and conservative in what you
        send.

   However, in the sender, case of news there is an even more important
   principle, derived from a much older code of practice, the moderator, or
   Hippocratic Oath (we may thus call this the injector).

        NOTE: A cancel submitted Hippocratic Principle):

        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 poster for an article in actions of thousands of hosts within a
        moderated group will be forwarded to few minutes.

   In the moderator case of that
        group, gateways, the primary corollary to this is:

        Cause no loops.

6.2.  Duties of an Injecting Agent

   An Injecting Agent is responsible for taking a (proto-)article from a
   posting (or other) agent and either forwarding it is up to that a moderator to act upon or
   injecting it (7.8).

        NOTE: The former requirement [RFC 1036] 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 From and/or
        Sender header fields rules of [USEFOR]. It
   is also expected to bear some responsibility towards the "cancel" message should match those rest 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
   network for the behaviour of its posters.

   In the normal course of events, an article that has already been
   injected into a Netnews network will never pass through another
   injecting agent.  So, if an injecting agent receives an otherwise
   valid article that has already been injected (as evidenced by
        canceling software.  Therefore, both the From and/or Sender
   presence of an Injection-Date header fields and any Approved field, an Injection-Info header field should now relate to
        the entity responsible for issuing the "cancel" message.

6.4.  Ihave, sendme

   The "ihave" and "sendme" control messages implement a crude batched
   predecessor
   field, or more than one occurrence of the NNTP [NNTP] protocol. They are largely obsolete on
   the Internet, but still see use <diag-keyword> "POSTED" in conjunction with some transport
   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 Path header field) it MAY choose to implement them. reject it, but otherwise SHOULD
                News Article Architecture and Protocols     January    November 2006

        NOTE: The ihave and sendme messages defined here have ABSOLUTELY
        NOTHING TO DO WITH NNTP, despite similarities

   cause it to be relayed, as it stands, by a relaying agent (6.3).

   In exceptional circumstances (e.g. as part of terminology.

   The two messages share some complex gatewaying
   process, or where a relaying agent considers it essential for
   fulfilling its responsibility towards the same syntax:

      control-command     =/ Ihave-command
      Ihave-command       = "ihave" Ihave-argument
      Ihave-argument      = relayer-name
      control-command     =/ Sendme-command
      Sendme-command      = "sendme" Sendme-argument
      Sendme-argument     = Ihave-argument
      relayer-name        = path-identity  ; see F-3.1.6
      ihave-body          = *( msg-id CRLF )
      sendme-body         = ihave-body

   The body rest of the message consists of network) an
   already injected article MAY be "reinjected" into the network.  This
   standard does not prescribe any such circumstance; rather this is a list
   matter of <msg-id>s, one per
   line. [RFC 1036] also permitted policy to be determined by the list administrators of <msg-id>s each
   injecting agent, who have the responsibility to appear ensure that no harm
   arises. In all other circumstances, unintented reinjection is to be
   avoided (see 6.9).  Nevertheless, in order to preserve the <Ihave-> or <Sendme-argument> with integrity
   of the syntax
      Ihave-argument      = [FWS] *( msg-id FWS ) [relayer-name]
   but network in these special cases, this form SHOULD NOT now be used, though relaying agents MAY
   recognize standard does set out the
   correct way to reinject (see special provisions in 6.2.2 Steps 3, 7
   and process it 9).

   It is usual for backward compatibility.

   The "ihave" message states that the named relaying an injecting agent has received
   articles with the specified message identifiers, which may to be of
   interest closely associated with a
   storage agent, thus giving it access to the relaying agents receiving list (6.4) showing the ihave message.  The
   "sendme" message requests that
   moderation status of the agent receiving newsgroups it send the
   articles having the specified message identifiers is likely to handle. In the named
   relaying agent.

   Upon receipt of
   event that it does not have such an associated storage agent, it MUST
   maintain that list itself.

6.2.1.  Proto-articles

   A proto-article SHOULD NOT be propagated in that form to other than
   injecting agents.

   A proto-article has the sendme message, the receiving agent sends same format as a normal article except that
   some of the
   article(s) requested, often (especially when following mandatory header fields MAY be omitted:
   Message-Id, Date, Path (and even From if the transport protocol particular injecting
   agent can derive that information from other sources).  However, if
   it is UUCP) in intended to offer the form of one proto-article to two or more batches, each containing several
   articles. The usual form of a <batch> is defined by the following
   syntax (which is also used injecting
   agents in the application/news transmission media
   type (5.1)).

      batch             = 1*( batch-header article )
      batch-header      = "#!" SP rnews SP article-size CRLF
      rnews             = %x72.6E.65.77.73 ; case sensitive "rnews"
      article-size      = 1*DIGIT

   Thus a <batch> parallel, then it is a sequence of articles, each prefixed by a only the Path header
   line field that includes its size. MAY be
   omitted.  The <article-size> header fields that can be omitted MUST NOT contain
   invalid values; they MUST either be correct or not present at all.
[Maybe omit that last sentence.]

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is not therefore to
        be considered as a decimal count of proto-article.  Hence a genuine proto-article
        will not contain any Injection-Date header field nor the octets <diag-
        keyword> "POSTED" anywhere in its Path header field, though that
        header field MAY contain <path-identity>s corresponding to
        machines traversed between the article, counting each CRLF as one octet regardless
   of how it is actually represented.

        NOTE: Despite posting agent and the similarity of this format injecting
        agent proper.

6.2.2.  Procedure to an executable
        UNIX script, it is EXTREMELY unwise be followed by Injecting Agents

   An injecting agent receives (proto-)articles from posting and
   followup agents. It verifies them, adds header fields where required,
   and then either forwards them to feed such a batch into a
        command interpreter in anticipation of it running moderator or injects them by
   passing them to storage or relaying agents.  It MUST NOT forward an
   already injected article to a command
        named "rnews"; the security implications of so doing would be
        disastrous. moderator.

                News Article Architecture and Protocols     January    November 2006

   These control messages are normally sent essentially

   An injecting agent processes articles as point-to-
   point messages, by using <newsgroup-name>s in the Newsgroups follows:

   1. It MUST remove any Injection-Info header field of the form "to."  followed by one (or possibly more)
   <component>s in already present
      (though it might be useful to copy it to a suitable "X-" header
      field). It SHOULD likewise remove any NNTP-Posting-Host, X-Trace,
      or other non-standard tracing header field.

   2. It SHOULD ensure that the form of article is from a <relayer-name> (see section F-3.1.5 verified source, and
      MAY reject articles in which forbids "to" as header fields contain unverified
      email addresses, that is, addresses which are not known to be
      valid for the first <component> of a <newsgroup-name>).
   The control message SHOULD then verified source, though it would be delivered ONLY perverse to
      reject intentionally unverifiable addresses such as those ending
      in ".invalid" (6.5).

   3. It SHOULD reject any article whose Date header field (F-3.1.1) is
      more than 24 hours into the relaying
   agent(s) identified by future (and MAY use a margin less than
      that <relayer-name>, and 24 hours).  It MUST (except when reinjecting) reject any relaying agent
   receiving such a message which includes its own <relayer-name> MUST
   NOT propagate
      article with an Injection-Date header field already present (and
      SHOULD do likewise with any NNTP-Posting-Date header field). When
      reinjecting it further. Each pair MAY, in the absence of relaying agent(s) sending and
   receiving these messages MUST be immediate neighbours, exchanging
   news directly with each other. Each relaying agent advertises its new
   arrivals any Injection-Date header
      field, reject any article whose Date header field appears to be
      stale (e.g. more than 72 hours into the other using "ihave" messages, and each uses "sendme"
   messages to request past).

   4. It MUST reject any article that does not have the articles it lacks.

   To reduce overhead, ihave and sendme messages proper mandatory
      header fields for a proto-article or which contains any header
      field that does not have legal contents.  It SHOULD be sent
   relatively infrequently and reject any
      article which contains any header field deprecated for Netnews
      (e.g. as in [RFC 2298]).  It SHOULD reject any article whose
      Newsgroups header field does not contain reasonable numbers of
   message identifiers. If ihave and sendme are being used to implement
   a backup feed, it may be desirable to insert a delay between
   reception of at least one <newsgroup-
      name> for an ihave existing group (as listed by its associated storage
      agent) and generation it MAY reject any <newsgroup-name> which violates one
      of the restrictions in F-3.1.4 or which, although otherwise
      correct, violates a sendme, so policy restriction established, for some
      (sub-)hierarchy, by an agency with the appropriate authority
      (1.2).  Observe that a slightly
   slow primary feed will not cause large numbers of articles crossposting to be
   requested unnecessarily via sendme.

6.5.  Obsolete control messages.

   The following control messages (as described in Appendix A) are
   declared obsolete by this standard:

        sendsys
        version
        whogets
        senduuname

7.  Duties of Various Agents

   The following section sets out the duties unknown newsgroups is not
      precluded provided at least one of various agents involved those in the creation, relaying and serving of Netnews articles. Insofar as
   these duties are described as sequences Newsgroups header
      field is listed.

        NOTE: This ability to reject <newsgroup-name>s in breach of steps
        established policy does not extend to be followed, relaying agents, though it
   should
        might be understood that it is reasonable for posting agents to do it.

   5. If the effect of these sequences that article is
   important, and implementations may use any method that gives rise to
   that same effect.

   In this section, rejected (for reasons given above, or for other
      formatting errors or matters of site policy) the word "trusted", posting agent
      SHOULD be informed (such as applied to the source of some
   article, means that via an agent processing NNTP 44x response code) that article
      posting has verified, by
   some means, failed and the identity of that source (which may article MUST NOT then be another agent
   or a poster).

        NOTE: In many implementations, a single agent may perform
        various combinations of the injecting, relaying processed
      further.

   6. The Message-ID, Date and serving
        functions. Its duties are then From header fields (with appropriate
      contents) MUST be added when not already present.  A User-Agent
      header field MAY be added (or an already present User-Agent header
      field MAY be augmented) so as to identify the union of software (e.g.
      "INN/1.7.2") used by the various duties
        concerned. injecting agent.

                News Article Architecture and Protocols     January    November 2006

7.1.  General principles to be followed

   There are two important principles

[I think that news implementors (and
   administrators) need last sentence needs to keep go (in which case see consequential
change in mind. The first is the well-known
   Internet Robustness Principle:

        Be liberal 7.3). Did we discuss this when we looked at User-Agent in what you accept,
USEFOR?]

        NOTE: The Message-ID, Date and conservative in what you
        send.

   However, in From fields will already be
        present during reinjection.

   7. The injecting agent MUST NOT alter the case of news there is an even more important
   principle, derived from a much older code body of practice, the
   Hippocratic Oath (we may thus call this the Hippocratic Principle):

        First, do no harm.

   It is VITAL to realize that decisions which might be merely
   suboptimal article in a smaller context can become devastating mistakes any
      way (including any change of Content-Transfer-Encoding). It MAY
      (except when
   amplified reinjecting) add other header fields not already
      provided by the actions of thousands of hosts within a few minutes.

   In poster, but SHOULD NOT alter, delete, or reorder
      any existing header field, with the case specific exception of gateways, the primary corollary to this is:

        Cause no loops.

7.2.  Duties of an Injecting Agent

   An Injecting Agent
      "tracing" header field Injection-Info, which is responsible for taking a (proto-)article from a
   posting (or other) agent and either forwarding it to a moderator be removed as
      already mentioned.

   8. If the Newsgroups header field contains one or
   injecting it into more moderated
      groups and the relaying system for access by readers.

   As such, article does NOT contain an Approved header field,
      the injecting agent is considered responsible for ensuring
   that any article MUST forward it injects conforms with the rules of [USEFOR]. It
   is also expected to bear some responsibility towards the rest of a moderator as specified in
      section 6.2.3 below.

   9. Otherwise, a Path header field with a <tail-entry> (F-3.1.5) MUST
      be correctly added if not already present. During reinjection, the
   network for
      existing Path header field SHOULD be retained.

   10.It MUST then prepend the behaviour <path-identity> of its posters.

   In the normal course of events, an article that has already been
   injected into a Netnews network will never pass through another
   injecting agent.  So, if an injecting agent receives an otherwise
   valid article that has already been injected (as evidenced agent,
      followed by '!.' and the
   presence <diag-keyword> "POSTED", and then a
      further "!", to the content of an Injection-Date the Path header field, an Injection-Info field; this header
   field, or
      field SHOULD then be folded if it would otherwise result in a
      header line of excessive length.

        NOTE: This could result in more than that one "POSTED" <path-keyword>
        in a Path the case of reinjection.

   11.An Injection-Info header field) it MAY
   choose to reject it, but otherwise field (F-3.2.8) SHOULD cause it to be relayed, as
   it stands, by a relaying agent (7.3).

   In exceptional circumstances (e.g. as part of some complex gatewaying
   process, or where a relaying agent considers it essential for
   fulfilling its responsibility towards added,
      identifying the rest verified source of the network) an
   already injected article MAY be "reinjected" into the network.  This
   standard does not prescribe any such circumstance; rather this is and possibly an
      address for mailing complaints to.  Each injecting agent SHOULD
      use a
   matter consistent form of policy to be determined by the administrators of each
   injecting agent, who have the responsibility to ensure that no harm
   arises. In Injection-Info header field for all other circumstances, unintented reinjection
      articles emanating from the same or similar origins.

        NOTE: The step above is the only place in which an Injection-
        Info header field is to be
   avoided (see 7.9).  Nevertheless, created. It follows that this header
        field MUST NOT be created, replaced, changed or deleted by any
        other agent (except during reinjection, in order which case it will
        always relate to preserve the integrity
   of latest injection and is, to that extent,
        regarded as a variant header field).

   12.The injecting agent MUST then add an Injection-Date header field
      (F-3.2.7) if one is not already present, but it MUST NOT alter, or
      delete, an already present Injection-Date header field (and
      likewise SHOULD NOT alter, or delete, an already present NNTP-
      Posting-Date header field).  Finally, it forwards the network in these special cases, this standard does set out article to
      one or more relaying or storage agents, and the
   correct way injection process
      is to reinject (see special provisions in 7.2.2 Steps 3, 7 be considered complete.

                News Article Architecture and Protocols     January    November 2006

   and 9).

   It

        NOTE: The step above is usual for the only place where an Injection-Date
        header field is to be created It follows that it MUST NOT
        subsequently be replaced, changed or deleted by any other agent,
        even during reinjection.

6.2.3.  Procedure for Forwarding to a Moderator

   An injecting agent forwards an article to be closely associated with a
   serving agent, thus giving moderator as follows:

   1. It MUST forward it access to the list (7.4) showing the
   moderation status moderator of the newsgroups it is likely to handle. In first (leftmost)
      moderated group listed in the
   event Newsgroups header field, customarily
      via email, (see 6.8 for how that moderator may forward it does not have such an associated serving agent, it MUST
   maintain that list itself.

7.2.1.  Proto-articles

   A proto-article to
      further moderators). There are two possibilities for doing this:

      (a)  The complete article is encapsulated (header fields and all)
           within the email, preferably using the Content-Type
           "application/news-transmission" (4.1) with any usage
           parameter set to "moderate". Moreover, there SHOULD NOT be propagated in that form to other
           more than
   injecting agents.

   A proto-article one encapsulated article within the one email.
           This method has the same format as a normal article except that
   some advantage of the following mandatory removing any possible
           conflict between Netnews and Email header fields, or of
           changes to those fields MAY be omitted:
   Message-Id, Date, Path (and even From if the particular injecting
   agent can derive that information from other sources).  However, if
   it during transport through email.

      (b)  The article is intended to offer the proto-article to two or more injecting
   agents in parallel, then sent as an email as it is only stands, with the Path
           addition of such extra header field that MAY be
   omitted. fields (e.g. a To header field)
           as are necessary for an email. The existing Message-ID header fields that can
           field SHOULD be omitted MUST retained.

      Although both of these methods have seen use in the past, the
      preponderance of current usage on Usenet has been for method (b)
      and many moderators are ill-prepared to deal with method (a).
      Therefore, method (a) SHOULD NOT contain
   invalid values; they MUST either be correct or not present at all.
[Maybe omit that last sentence.]

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is used until such time as the
      majority of moderators are able to accept it.

   2. This standard does not therefore prescribe how the email address of the
      moderator is to be considered as a proto-article.  Hence a genuine proto-article
        will not contain any Injection-Date header field nor any
        "POSTED" in its Path header field, though determined, that header field MAY
        contain <path-identity>s corresponding being a matter of policy to machines traversed
        between be
      arranged by the posting agent agency responsible for the oversight of each
      hierarchy. Nevertheless, there do exist various agents worldwide
      which provide the service of forwarding to moderators, and the injecting agent proper.

7.2.2.  Procedure
      address to use with them is obtained as follows:

      (a)  Each '.' in the <newsgroup-name> is replaced with a '-'.

      (b)  The result of these operations is used as the <local-part> of
           the <mailbox> of the agent. For example, articles intended
           for "news.announce.important" would be followed by Injecting Agents

   An injecting agent receives (proto-)articles emailed to "news-
           announce-important@forwardingagent.example".

6.3.  Duties of a Relaying Agent

   A Relaying Agent accepts injected articles from posting injecting and
   followup agents. It verifies them, adds header fields where required, other
   relaying agents and then either forwards them to a moderator or injects them by
   passing passes them on to serving or relaying agents.  It MUST NOT forward an
   already injected article or storage agents
   according to a moderator.

   An injecting agent processes mutually agreed policy. Relaying agents SHOULD accept
   articles as follows:

   1. It MUST remove any Injection-Info header field already present
      (though it might be useful to copy it to a suitable "X-" header
      field). It SHOULD likewise remove any NNTP-Posting-Host, X-Trace,
      or other non-standard tracing header field.

   2. It SHOULD verify that the article is ONLY from a trusted source, and
      MAY reject articles in which header fields contain unverified
      email addresses, that is, addresses which are not known to be
      valid for the trusted source, though it would be perverse to
      reject intentionally unverifiable addresses such as those ending
      in ".invalid" (7.5). verified sources.

                News Article Architecture and Protocols     January    November 2006

   3. It SHOULD reject any article whose Date header field (F-3.1.2) is
      more than 24 hours into the future (and MAY use a margin less than
      that 24 hours).  It MUST (except when reinjecting) reject any

   An article with an Injection-Date header field already present (and SHOULD do likewise with any NNTP-Posting-Date header field). When
      reinjecting it MAY, in NOT be relayed unless the absence of any Injection-Date header
      field, reject any article whose Date header field appears sending agent has been
   configured to be
      stale (e.g. more than 72 hours into supply and the past).

   4. It MUST reject any article that does not have receiving agent to receive at least one
   of the proper mandatory
      header fields for a proto-article or which contains any header
      field that does not have legal contents.  It SHOULD reject any
      article which contains any header field deprecated for Netnews
      (e.g. as <newsgroup-name>s in [RFC 2298]).  It SHOULD reject any article whose its Newsgroups header field does not contain and at least
   one <newsgroup-
      name> for an existing group (as listed by of the <dist-name>s in its associated serving
      agent) and it MAY reject any <newsgroup-name> which violates one
      of Distribution header field, if any.
   Exceptionally, ALL relaying agents are deemed willing to supply or
   accept the restrictions in F-3.1.5 <dist-name> "world", and NO relaying agent should supply
   or which, although otherwise
      correct, violates a policy restriction established, for some
      (sub-)hierarchy, by an agency with accept the appropriate authority
      (1.2).  Observe that crossposting to unknown newsgroups is <dist-name> "local".

   However, if the particular implementation does not
      precluded provided at least one of those relay non-existent
   newsgroups, even when included in the Newsgroups header field is listed.

        NOTE: This ability to reject <newsgroup-name>s and
   implied (e.g. by some "wild card" notation) in breach the configuration
   tables, then the agent MUST examine all group control messages (5.2)
   in order to ensure that relaying of
        established policy does not extend those messages proceeds normally.

        NOTE: Although it would seem redundant to filter out unwanted
        distributions at both ends of a relaying agents, though link (and it
        might be reasonable for posting agents is clearly
        more efficient to do it.

   5. If so at the article is rejected (for reasons given above, or for other
      formatting errors or matters of sending end), many sending sites
        have been reluctant, historically speaking, to apply such
        filters (except to ensure that distributions local to their own
        site policy) the posting agent
      SHOULD be informed (such as via or cooperating subnet did not escape); moreover they tended
        to configure their filters on an NNTP 44x response code) "all but those listed" basis,
        so that
      posting has failed new and the article MUST NOT then hitherto unheard of distributions would not be processed
      further.

   6. The Message-ID, Date and From header fields (with appropriate
      contents) MUST be added when not already present.  A User-Agent
      header field MAY be added
        caught. Indeed many "hub" sites actually wanted to receive all
        possible distributions so that they could feed on to their
        clients in all possible geographical (or an already present User-Agent header
      field MAY organizational)
        regions.

        Therefore, it is desirable to provide facilities for rejecting
        unwanted distributions at the receiving end. Indeed, it may be augmented)
        simpler to do so as locally than to identify the software (e.g.
      "INN/1.7.2") used by inform each sending site of
        what is required, especially in the injecting agent.
[That last sentence may case of specialized
        distributions (for example for control messages, such as cancels
        from certain issuers) which might need to be reconsidered (in which case see
consequential change added at short
        notice.  A similar possibility for reading agents to filter
        distributions is also suggested in 7.3).]

        NOTE: The Message-ID, Date and From fields will already be
        present during reinjection.

   7. The injecting agent MUST NOT alter the body of [USEAGE]) for the same
        reason.

   In order to avoid unnecessary relaying, an article in any
      way (including any change of Content-Transfer-Encoding). It MAY
      (except when reinjecting) add other header fields not already
      provided by the poster, but SHOULD NOT alter, delete, or reorder
      any existing header field, with be
   relayed if the specific exception <path-identity> of the
      "tracing" receiving agent (or some known
   alias thereof) appears as a <path-identity> in its Path header field Injection-Info, which field.
   But note that the <tail-entry> (which follows the last "!") is not a
   <path-identity>, although not all current implementations observe
   this distinction.

   For this to be removed as
      already mentioned.

                News Article Architecture and Protocols     January 2006

   8. If work, each relaying agent needs to insert it own <path-
   identity> (chosen according to 2.3) into the Newsgroups Path header field contains one or field. It
   MAY insert more moderated
      groups and than one <path-identity> for itself (in which case
   the leftmost should be the one by which it is known to its immediate
   neighbours), but where an article does passes through several relaying
   agents at the same site it MAY omit the <path-identity>s for some of
   them (but NOT contain an Approved header field, the injecting agent MUST forward one which finally relays it to an outside site).

                News Article Architecture and Protocols    November 2006

   It MAY (and usually SHOULD) also add a moderator as specified in
      section 7.2.3 below.

   9. Otherwise, a Path header field with a <tail-entry> (F-3.1.6) MUST
      be correctly added if not already present. During reinjection, <path-diagnostic> giving
   additional information concerning the
      existing Path header field SHOULD be retained.

   10.It MUST then prepend route taken by the <path-identity> article
   through the network.  A <path-diagnostic> consists of either the injecting agent,
   special <diag-match> "!" (which effectively replaces the standard
   delimiter "!" by "!!"), or it is composed from a <diag-keyword>
   usually followed by a '!', <diag-identity>. The following are the <path-keyword> only
   <diag-keyword>s defined by this standard:
     o "POSTED" and (already introduced in Step 10 of 6.2.2), which is never
       followed by a further "!"
      (or "!!" if appropriate) to <diag-identity>;
     o "SEEN", whose following <diag-identity> indicates the content verified
       identity (see 6) of the Path header field;
      this header field SHOULD then be folded if agent from which the article was received
       (but makes no claim as to whether it would otherwise
      result in a header line of excessive length.
[This may need further changes depending on matched the resolution of ticket
#1047.]

        NOTE: This could result in more that one "POSTED" <path-keyword>
        in the case of reinjection.

   11.An Injection-Info header field (F-3.2.14) SHOULD be added,
      identifying <path-identity)
       inserted by that agent);
     o "MISMATCH", whose following <diag-identity> indicates the trusted source
       verified identity of the article and possibly an
      address for mailing complaints to.  Each injecting agent SHOULD
      use a consistent form of the Injection-Info header field for all
      articles emanating from the same or similar origins.

        NOTE: The step above is the only place in which an Injection-
        Info header field is to be created. It follows the article was
       received and asserts that this header
        field MUST NOT be created, replaced, changed or deleted by any
        other agent (except during reinjection, in which case it will
        always relate to could not be reconciled with the latest injection and is, to
       <path-identity> (supposedly) inserted by that extent,
        regarded as agent.
   Other <diag-keyword>s beginning with "X" MAY be used by a variant header field).

   12.The injecting relaying
   agent MUST then add an Injection-Date header field
      (F-3.2.1) if one is to make some assertion not already present, envisaged here, but it other (non-"X")
   <diag-keyword>s MUST NOT alter, or
      delete, an already present Injection-Date header field (and
      likewise SHOULD NOT alter, or delete, an already present NNTP-
      Posting-Date header field).  Finally, it forwards the article to
      one or more relaying or serving agents, and the injection process
      is to be considered complete. used unless defined by some extension to
   this standard.

        NOTE: The step above is <diag-keyword> "MATCH", which might have indicated the only place where
        verified identity of the source agent with an Injection-Date
        header field is to be created It follows assertion that it MUST NOT
        subsequently be replaced, changed or deleted
        agreed with the <path-identity> inserted by any other that agent,
        even during reinjection.

7.2.3.  Procedure has NOT
        been provided, since the special <diag-match> conveys exactly
        that meaning for Forwarding to a Moderator

   An injecting this commonly occurring case.

        NOTE: Whilst <diag-keywords>s are case insensitive, it is
        intended that they should normally be rendered in uppercase.

   A relaying agent forwards an article to a moderator processes articles as follows:

   1. It MUST forward it to MUST/SHOULD establish the moderator verified identity of the first (leftmost)
      moderated group listed in source of
      the Newsgroups article and compare it with the leftmost <path-identity> of
      the existing Path header field, customarily
      via email, (see 7.8 for how field's content.  Except possibly when
      relaying to other hosts on the same site, It then MUST or SHOULD,
      as indicated, prepend to that moderator may forward it content (from left to right) the
      following:
         o (MUST) its own <path-identity>;
         o (MUST) a "!" delimiter;
         o (MUST/SHOULD) if the verified and existing identities match,
           a <diag-match> (effectively converting the "!" delimiter into
           "!!");
         o (MUST/SHOULD) alternatively, where the identities do not
           match (or have not been determied to match), a ".", the
           <diag-keyword> "MISMATCH" (or "SEEN"), another ".", a <diag-
           identity> indicating the verified identity, and finally a
           further moderators). There are two possibilities for doing this: "!";
         o possibly further <path-identity>s etc. as above, identifying
           itself.
      This header field SHOULD then be folded if it would otherwise
      result in a header line of excessive length.

                News Article Architecture and Protocols     January    November 2006

      (a)  The complete article

[The "MUST/SHOULD"s above were all "MUST" in the previous drafts.
Discussion is encapsulated (header fields and all)
           within needed to resolve this.]

        NOTE: Since each agent at one site can be assumed to be aware of
        the email, preferably using identity of the Content-Type
           "application/news-transmission" (5.1) with any usage
           parameter set others (and of itself), it would be most
        unusual for their <path-identity>s to "moderate". Moreover, there SHOULD NOT be
           more separated other than one encapsulated article within the one email.
           This method has by
        "!!". Thus the advantage of removing any possible
           conflict between Netnews and Email header fields, or of
           changes to those fields during transport through email.

      (b)  The article is sent as an email as it stands, with the
           addition presence of such extra header fields (e.g. a To header field) single "!", unless followed by a
        "." and some <diag-keyword>, can be taken as are necessary for signifying an email. The existing Message-ID header
           field SHOULD be retained.

      Although both of these methods have seen use in the past, the
      preponderance of current usage on Usenet agent
        that has not yet been for method (b)
      and many moderators are ill-prepared upgraded to deal with method (a).
      Therefore, method (a) SHOULD NOT be used until such time as the
      majority of moderators are able conform to accept it.

   2. This standard does not prescribe how this standard.

        NOTE: Whilst the email address presence of a "MISMATCH" would normally
        indicate that the
      moderator is to be determined, existing Path was bogus in some sense, it
        could also indicate that being a matter of policy to be
      arranged by the agency responsible for ralaying agent was improperly
        configured to recognise the oversight identities or aliases used by its
        neighbours. Administators of each
      hierarchy. Nevertheless, there do exist various relaying agents worldwide
      which provide should therefore
        periodically monitor the service of forwarding <path-diagnostic> being inserted so as
        to moderators, and the
      address avoid this.

        NOTE: In order to use with them is obtained prevent overloading, relaying agents should
        not routinely query an external entity (such as follows:

      (a)  Each '.' a DNS-server) in the <newsgroup-name> is replaced with
        order to determine a '-'.

      (b)  The result verified identity (though a local cache of these operations is used as
        the <local-part> of required information might usefully be consulted).

   2. It MUST examine the <mailbox> of Injection-Date header field (or, if that is
      absent, the agent. For example, Date header field) and reject the article as stale
      (F-3.2.7) if that predates the earliest articles intended
           for "news.announce.important" would be emailed to "news-
           announce-important@forwardingagent.example".

7.3.  Duties of a Relaying Agent

   A Relaying Agent accepts injected articles from injecting and other
   relaying agents and passes them on to relaying which it
      normally keeps record, or serving agents
   according to mutually agreed policy. Relaying agents if it is more than 24 hours into the
      future (the margin MAY be less than that 24 hours).

   3. It SHOULD accept
   articles ONLY from trusted agents.

   An reject any article SHOULD NOT be relayed unless that does not include all the sending agent
      mandatory header fields (section F-3.1).

   4. It MAY reject any article whose header fields do not have legal
      contents.

   5. It SHOULD reject any article that has already been
   configured sent to supply it (a
      database of message identifiers of recent messages is usually kept
      and matched against).

        NOTE: Even though commonly derived from the receiving agent to receive at least one domain name of the <newsgroup-name>s
        originating site (and domain names are case-insensitive), a
        <msg-id-core> MUST NOT be altered in its Newsgroups any way during transport,
        or when copied (as when forming a References header field field), and at least
   one
        thus a simple (case-sensitive) comparison of the <dist-name>s in its Distribution header field, if any.
   Exceptionally, ALL relaying agents octets will always
        suffice to recognize that same message identifier wherever it
        subsequently reappears.

        NOTE: These requirements are deemed willing to supply or
   accept the <dist-name> "world", and NO relaying agent should supply
   or accept the <dist-name> "local".

   However, if the particular implementation does not relay non-existent
   newsgroups, even when included in be contrasted with those of the Newsgroups header field and
   implied (e.g.
        un-normalized msg-ids defined by some "wild card" notation) in the configuration
   tables, then the agent MUST examine all group control messages (6.2) [RFC 2822], which may perfectly
        legitimately become normalized (or vice versa) during transport
        or copying in order to ensure that relaying of those messages proceeds normally. email systems.

                News Article Architecture and Protocols     January    November 2006

        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 sending end), many sending sites
        have been reluctant, historically speaking, to apply such
        filters (except to ensure

   6. It SHOULD reject any article that distributions local to their own
        site matches an already received
      cancel message (or an equivalent Supersedes header field) issued
      by its poster or cooperating subnet did not escape); moreover they tended
        to configure their filters on by some other trusted entity.

   7. It MAY reject any article without an "all Approved header field posted
      to newsgroups known to be moderated (this practice is strongly
      recommended, but those listed" basis, the information necessary to do so that new and hitherto unheard of distributions would may not be
        caught. Indeed many "hub" sites actually wanted
      available to receive all
        possible distributions so agents).

   8. It MAY delete any Xref header field that they could feed is present.

   9. Finally, it passes the articles on to their
        clients in all possible geographical (or organizational)
        regions.

        Therefore, it neighbouring relaying and
      storage agents.

   If the article is desirable to provide facilities for rejecting rejected as being invalid, unwanted distributions at the receiving end. Indeed, it may be
        simpler to do so locally than or unacceptable
   due to inform each sending site of
        what is required, especially in policy, the case of specialized
        distributions (for example for control messages, such as cancels
        from certain issuers) which might need to be added at short
        notice.  A similar possibility for reading agents agent that passed the article to filter
        distributions is also suggested in [USEAGE]) for the same
        reason. relaying
   agent SHOULD be informed (such as via an NNTP 43x response code) that
   relaying failed. In order to avoid unnecessary relaying, prevent a large number of error messages
   being sent to one location, relaying agents MUST NOT inform any other
   external entity that an article SHOULD NOT be was not relayed if the <path-identity> UNLESS that external
   entity has explicitly requested that it be informed of the receiving agent (or some known
   alias thereof) appears as a <path-identity> (excluding within the
   <tail-entry>) in its Path header field.

   A relaying agent processes articles as follows:

   1. It such errors.

   Relaying agents MUST establish the trusted identity of the source NOT alter, delete or rearrange any part of the an
   article and compare it with the leftmost <path-identity> of the
      Path except for header field's content. If it matches it fields designated as variant (2.4).  In
   particular

     o they MUST then prepend
      its own <path-identity> and NOT create or augment a '!!' <path-delimiter> User-Agent header field in
       order to that
      content. If it does not match then it prepends instead two entries
      to that content; firstly the true established <path-identity> of
      the source followed by a '!', identify themselves;
     o they MUST NOT rewrite the <path-keyword> "MISMATCH" and a
      further '!', and then, to Newsgroups header field in any way,
       even if some supposedly non-existent newsgroup is included;
     o they MUST NOT refold any header field (i.e. they must pass on the left of that, its own <path-
      identity> followed by a '!!' <path-delimiter>
       folding as usual. This
      prepending of two entries SHOULD received);
     o they MUST NOT be done if alter the provided and
      established identities match. This Date header field SHOULD then be
      folded if it would otherwise result in a or the Injection-Date
       header line of excessive
      length.
[This may need further changes depending on field;
     o they MUST NOT delete any unrecognized header field whose field
       name is syntactically correct (whether or not it is registered
       with IANA [RFC 3864]);
     o they MUST NOT change the resolution Content-Transfer-Encoding of ticket
#1047.]
[It has been suggested that relaying agents should be permitted to
prepend more than the one body or two entries permitted above.]
[something like
       any body part;
     o they MUST transmit lines of arbitrary length and articles of
       arbitrary size.

6.3.1.  Path Header Field Example

      Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example
         !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A
         !dubious.site.example!!old.site.example!barbaz!!baz.isp.example
         !.POSTED!dialup123.baz.isp.example!not-for-mail

        NOTE: That article was injected into the following from Diablo might also be useful:
>>> NOTE <<< you should grep through newly created spool directories
every so often looking for .MISMATCH in news stream by
        baz.isp.example, as indicated by the spool files <diag-keyword> "POSTED"
        (complaints may be addressed to locate
incoming feeds with improperly configured I found abuse@baz.isp.example). The
        injector has chosen to record that four of my 80+
feeds were misconfigured. ] it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
                News Article Architecture and Protocols     January    November 2006

        NOTE: In order

        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to prevent overloading, relaying agents should
        not routinely query an external entity (such the machine known,
        at least to old.site.example, as a DNS-server) in
        order "barbaz".

        Barbaz relayed it to verify an article (though a local cache of old.site.example, which does not yet
        conform to this standard (hence the required
        information might usefully single '!' delimiter). So
        one cannot be consulted).

   2. It MUST examine the Injection-Date header field (or, if that is
      absent, the Date header field) and reject the article as stale
      (F-3.2.1) if sure that predates the earliest articles of which it
      normally keeps record, or if really came from barbaz.

        Old.site.example relayed it is more than 24 hours into the
      future (the margin MAY to a site claiming to be less than that 24 hours).

   3. It SHOULD reject any article that does not include all
        dubious.site.example, and claiming (by using the
      mandatory header fields (section F-3.1).

   4. It MAY reject any article whose header fields do not '!!'
        delimiter) to have legal
      contents.

   5. It SHOULD reject any article verified that has already been sent it came from old.site.example.

        Dubious.site.example relayed it to "foo-server" which, not being
        convinced that it (a
      database of message identifiers of recent messages is usually kept truly came from dubious.site.example, and matched against).

        NOTE: Even though commonly derived
        knowing that it in fact arrived from a host with the domain name of IPv6address
        [2001:DB8:0:0:8:800:200C:417A], inserted the
        originating site (and domain names are case-insensitive), <path-diagnostic>
        "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say
        that [2001:DB8:0:0:8:800:200C:417A] was not a
        message identifier MUST NOT correct IPv6
        address for dubious-site.example, but simply that that
        connection could not be altered in any way during
        transport, or when copied (as when forming substantiated by foo-server).

        "foo-server" is a References header
        field), locally significant name within the complex
        site of many machines run by foo.isp.example, so the latter
        should have no problem recognizing foo-server and thus using a simple (case-sensitive) comparison of octets
        will always suffice '!!'
        delimiter. It was not strictly necessary to recognize that same message identifier
        wherever it subsequently reappears.

        NOTE: These requirements are insert the <path-
        identity> "foo-server" as well as "foo.isp.example" (but maybe
        some site elsewhere had some reason to test for it).
[Please could Richard Clayton provide a more plausible reason why "foo-
server" might be contrasted with those of the
        un-normalized msg-ids defined by [RFC 2822], which may perfectly
        legitimately become normalized (or vice versa) during transport
        or copying in email systems.

   6. a <path-nodot> here?]

        It SHOULD reject any article then went to bar.isp.example which determined (by reverse
        DNS) that matches an already received
      cancel message (or an equivalent Supersedes header field) issued
      by its poster or by some other trusted entity.

   7. It MAY reject any article without an Approved header field posted it had come from news3.foo.isp.example, but had taken
        no steps to newsgroups check whether that was a known alias for
        foo.isp.example (which it probably was). Strictly, it SHOULD
        have made such a check, and then inserted either a "!!" or a
        "!MISMATCH..." according to be moderated (this practice is strongly
      recommended, but the information necessary to do so may not be
      available result.

        Presumably bar.isp.example then delivered the article to all agents).

   8. its
        direct clients.

        It MAY delete any Xref header field appears that is present.

   9. Finally, it passes foo.isp.example, foo-server and baz.isp.example
        decided to fold the articles line, on to neighbouring relaying and
      serving agents.

   If the article is rejected as being invalid, unwanted or unacceptable
   due to site policy, the agent grounds that passed the article it seemed to the relaying
   agent SHOULD be informed (such as via an NNTP 43x response code)
        getting a little too long.  Note that
   relaying failed. In order to prevent folding and whitespace is
        permitted before (but not after) any "!"  (but not within a large number
        "!!"); hence continuation lines will always start with either
        "!" or "!!".

6.4.  Duties of error messages
   being sent to one location, 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 MUST NOT inform any other
   external entity that to access the news database. This database is normally
   indexed by newsgroup with articles in each newsgroup identified by an article was not relayed UNLESS that external
                News Article Architecture and Protocols     January    November 2006

   entity has explicitly requested that it be informed of such errors.

   Relaying agents MUST NOT alter, delete or rearrange any part

   <article-locator> (usually in the form of an
   article except for header fields designated as variant (2.4).  In
   particular

     o they MUST NOT create or augment a User-Agent header field in
       order to identify themselves;
     o they decimal number - see F-
   3.2.14).

   A storage agent MUST NOT rewrite maintain a list of the Newsgroups header field newsgroups it stores in any way,
       even if some supposedly non-existent newsgroup is included;
     o they MUST NOT refold any header field (i.e. they must pass on the
       folding as received);
     o they MUST NOT alter
   its news database showing the Date header field moderation status of each one (see
   5.2.1), and SHOULD include in that list all groups likely to be
   crossposted to from those groups (e.g. all other groups in the same
   hierarchy(ies)).

        NOTE: Since control messages are often of interest, but should
        not be displayed as normal articles in regular newsgroups, it is
        common for storage 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 storage agent MAY decline to accept an article if the Injection-Date
       header field;
     o they MUST NOT delete any unrecognized Path header
   field contains some <path-identity> whose field
       name articles the storage agent
   does not want, as a matter of local policy.

        NOTE: This last facility is syntactically correct (whether or sometimes used to detect and decline
        control messages (notably cancel messages) which have been
        deliberately seeded with a <path-identity> to be "aliased out"
        by sites not wishing to act upon them.
[INN at least does this. It might be argued that it is registered
       with IANA [RFC 3864]);
     o they MUST NOT change not necessary to
mention it here.]

   A storage agent processes articles as follows:

   1. It MUST/SHOULD establish the Content-Transfer-Encoding verified identity of the body or
       any body part;
     o they MUST transmit lines of arbitrary length and articles source of
       arbitrary size.

7.3.1.  Path Header Field Example

      Path: foo.isp.example!!foo-server!!bar.isp.example!MISMATCH!
         2001:DB8:0:0:8:800:200C:417A!!old.site.example!barbaz!!
         baz.isp.example!POSTED!!dialup123.baz.isp.example!not-for-mail

        NOTE: That
      the article was injected into and modify the news stream by
        baz.isp.example, Path header field as indicated by for a relaying
      agent (6.3).

   2. It MUST examine the <path-keyword> "POSTED"
        (complaints may be addressed to abuse@baz.isp.example). The
        injector has chosen to record Injection-Date header field (or, if that it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to the machine known,
        at least to old.site.example, as "barbaz".

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

        Old.site.example relayed it to a site claiming to have
      absent, the IPv6
        address [2001:DB8:0:0:8:800:200C:417A], Date header field) and claiming (by using reject the '!!'  <path-delimiter>) to have verified that it came from
        old.site.example.

        [2001:DB8:0:0:8:800:200C:417A] relayed it to "foo-server" which,
        not being convinced article as stale
      (F-3.2.7) if that it truly came from
        [2001:DB8:0:0:8:800:200C:417A], inserted the <path-keyword>
        "MISMATCH" and then did a reverse lookup on predates the actual source
        and concluded earliest articles of which it
      normally keeps record, or if it was known as bar.isp.example (that is not to
        say more than 24 hours into the
      future (the margin MAY be less than that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6
        address for bar.isp.example, but simply 24 hours).

   3. It MUST reject any article that does not include all the mandatory
      header fields (section F-3.1), or which contains any header field
      that connection
                News Article Architecture and Protocols     January 2006

        could does not be substantiated by foo-server). Observe have legal contents.

   4. It SHOULD reject any article that foo-
        server has now added two entries already been sent to the Path.

        "foo-server" is a locally significant name within the complex
        site it (a
      database of many machines run by foo.isp.example, so the latter
        should have no problem recognizing foo-server and using message identifiers of recent articles is usually kept
      and matched against).

   5. It SHOULD reject any article that matches an already received
      cancel message (or an equivalent Supersedes header field) issued
      by its poster or by some other trusted entity.

      Likewise, a '!!'
        <path-delimiter>.  Presumably foo.isp.example then delivered newly received cancel message (or equivalent
      Supersedes) should cause immediate deletion (or deactivation) of
      the canceled article.

                News Article Architecture and Protocols    November 2006

        NOTE: An article with a Supersedes header field is itself stored
        normally.

   6. It MUST reject any article without an Approved header field posted
      to its direct clients. any newsgroup listed as moderated.

   7. It appears that foo-server and barbaz decided MUST (exept when specially configured to fold preserve the line,
        on
      <article-locator>s set by the grounds that it seemed to be getting a little too long.

7.4.  Duties of a Serving Agent

   A Serving Agent takes an article sending site) remove any Xref header
      field (F-3.2.14) from each article.  It then MAY (and usually
      will) generate a relaying or injecting agent
   and files fresh Xref header field.

   8. Finally, it in a "news database". It also provides an interface for
   reading agents to access stores the article in its news database. This database is normally
   indexed by newsgroup with articles in each newsgroup identified by

   Serving agents MUST NOT create new newsgroups simply because an
   <article-locator> (usually
   unrecognized <newsgroup-name> occurs in a Newsgroups header field
   (see 5.2.1 for the form correct method of a decimal number - see F-
   3.2.11).

   A serving agent newsgroup creation).

   Serving agents MUST maintain a list NOT alter, delete or rearrange any part of the newsgroups it stores an
   article in
   its news database showing the moderation status any other way. The list of each one (see
   6.2.1), particular cases given for
   relaying agents (6.3) applies here also.

6.5.  Duties of a Posting Agent

   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 include in ensure that list all groups likely to be
   crossposted proto-articles they create are
   valid according to from those groups (e.g. all [USEFOR] and other groups applicable policies. In
   particular, they MUST NOT create any Injection-Date or Injection-Info
   header field.

   Contrary to [RFC 2822], which implies that the mailbox(es) in the same
   hierarchy(ies)).

        NOTE: Since control messages are often of interest, but
   From header field should
        not be displayed as normal articles in regular newsgroups, it is
        common that of the poster(s), a poster who does
   not, for serving agents whatever reason, wish 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 use his own mailbox MAY decline use any
   mailbox ending in the top level domain ".invalid" [RFC 2606].

   Posting agents meant for use by ordinary posters SHOULD reject any
   attempt to accept post an article if the Path header
   field contains some <path-identity> whose articles which cancels or Supersedes another
   article of which the serving agent
   does poster is not want, as the author or sender.

6.6.  Duties of a matter Followup Agent

   A Followup Agent is a special case of local policy.

        NOTE: This last facility a posting agent, and as such is sometimes used to detect
   bound by all the posting agent's requirements. Followup agents MUST
   create valid followups and decline
        control messages (notably cancel messages) which have been
        deliberately seeded with a <path-identity> to be "aliased out"
        by sites not wishing to act upon them.
[INN at least does this. It might be argued that it is not necessary are subject to
mention it here.]

   A serving agent processes articles as follows:

   1. It MUST establish the trusted identity of the source of special requirements
   involving the
      article Newsgroups, Subject, Distribution and modify the Path References header field as for a relaying agent
      (7.3).

   2. It MUST examine
   fields.  Wherever in the Injection-Date following it is stated that, "by default", a
   header field (or, if that is
      absent, the Date to be "inherited" from one of those header field) and reject fields in
   the article as stale
      (F-3.2.1) if precursor, it means that predates its initial (semantic) content is to be
   a copy of the earliest articles content of which it
      normally keeps record, or that precursor header field.  However,
   posters MAY then override that default before posting if it is more than 24 hours into the they so
   wish.

                News Article Architecture and Protocols     January    November 2006

      future (the margin MAY be less than that 24 hours).

   3. It MUST reject any article that does

        NOTE: The Keywords header field is not include all the mandatory inheritable, though some
        older user agents treated it as such.

   1. The Newsgroups header fields (section F-3.1), or which contains any field (F-3.1.4) SHOULD by default be
      inherited from the precursor's Followup-To header field if
      present, and otherwise from the precursor's Newsgroups header
      field. However, if the content of that Followup-To header field
      consists of "poster" (and the user 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 articles override it), then the
      followup MUST NOT be posted but, rather, is usually kept
      and matched against).

   5. It to be emailed to the
      precursor's poster.

   2. The Subject header field SHOULD reject any article by default be inherited from that matches an
      of the precursor.  The case sensitive string "Re: " MAY be
      prepended to the content of its Subject header field, unless it
      already received
      cancel message (or an equivalent Supersedes begins with that string.

   3. The Distribution header field) issued
      by its poster or field (F-3.2.4) SHOULD by some other trusted entity.

   6. It default be
      inherited from the precursor's Distribution header field, if any.

   4. The followup MUST reject any article without an Approved (in accordance with the definition of that term
      -  F-1.5) have a References header field posted referring to any newsgroup listed as moderated.

   7. It MUST (exept when specially configured its
      precursor, constructed in accordance with section 6.6.1 below.

        NOTE: That "MUST" is to preserve be contrasted with the
      <article-locator>s set by weaker
        recomendation using "SHOULD" applied, in [RFC 2822], to the sending site) remove
        generation of "replies" in email. Moreover, in Netnews, there is
        no expectation of any Xref In-Reply-To header field (F-3.2.11) from each article.  It then MAY (and usually
      will) generate in a fresh Xref header field.

   8. Finally, it stores followup.

6.6.1.  Construction of the References header field

   The following procedure is to be used whenever some previous article
   (the "parent") is to be referred to in its news database.

   Serving agents MUST NOT create the References header field
   (F-3.2.10) of a new newsgroups simply because an
   unrecognized <newsgroup-name> occurs article, whether in a Newsgroups header field
   (see 6.2.1 for the correct method course of newsgroup creation).

   Serving agents MUST NOT alter, delete generating a
   followup or rearrange any part of an
   article in any other way. The list of particular cases given for
   relaying agents (7.3) applies here also.

7.5.  Duties some other reason (e.g. the later parts of a Posting Agent

   A Posting Agent is used to assist the poster in creating
   multipart posting such as a valid
   proto-article and forwarding it to an injecting agent.

   Postings agents SHOULD ensure that proto-articles they create are
   valid according to [USEFOR] and other applicable policies. In
   particular, they MUST NOT create any Injection-Date FAQ, or Injection-Info
   header field.

   Contrary to [RFC 2822], which implies that the mailbox(es) later parts of a
   message/partial as suggested in [RFC 2046]).

   The (semantic) content (2.1) of the
   From new article's References header
   field should be that consists of the poster(s), a poster who does
   not, for whatever reason, wish to use his own mailbox MAY use any
   mailbox ending in content of the top level domain ".invalid" [RFC 2606].

   Posting agents meant for use by ordinary posters SHOULD reject any
   attempt to post an article which cancels or Supersedes another
   article Message-ID header field of which the poster is not
   parent preceded, if the author or sender.

                News Article Architecture and Protocols     January 2006

7.6.  Duties of a Followup Agent

   A Followup Agent is a special case of parent had a posting agent, and as such is
   bound References header field, by all the posting agent's requirements. Followup agents MUST
   create valid followups
   content of that References header field and are subject a SP (subject to special requirements
   involving trimming
   as described below).

   If the Newsgroups, Subject, Distribution and resulting References header
   fields.  Wherever in the following it is stated that, "by default", a
   header field is to be "inherited" from one of those header fields would, after unfolding,
   exceed 998 characters in
   the precursor, it means that length (including its initial (semantic) content is to be
   a copy of the content of that precursor header field.  However,
   posters MAY then override that default before posting if they so
   wish.

        NOTE: The Keywords header field is name but not inheritable, though some
        older newsreaders treated the
   final CRLF), it as such.

   1. The Newsgroups header field (F-3.1.5) SHOULD by default MUST be
      inherited from the precursor's Followup-To header field if
      present, and trimmed (and otherwise from the precursor's Newsgroups header
      field. However, if the content it MAY be trimmed).
   Trimming involves removing any number of message identifiers from its
   content, except that Followup-To header field
      consists of "poster" (and the user does not override it), then first message identifier and the
      followup last two
   MUST NOT be posted but, rather, removed.

        NOTE: There is no provision in this standard for an article to be emailed to the
      precursor's poster.

   2.
        have more than one parent. The Subject header field SHOULD by default be inherited from that essential property of the precursor.  The case sensitive string "Re: " MAY be
      prepended to the content of its Subject
        References header field, unless it
      already begins with that string.

   3. The Distribution header field (F-3.2.7) SHOULD guaranteed by default be
      inherited from the precursor's Distribution header field, if any.

   4. The followup MUST (in accordance with the definition of that term)
      have a References header field referring to its precursor,
      constructed in accordance with section 7.6.1 below.

        NOTE: That "MUST" is procedure above and
        to be contrasted with the weaker
        recomendation using "SHOULD" applied, in [RFC 2822], to the
        generation of "replies" in email. Moreover, preserved in Netnews, there any future extension, is that no expectation article can
                News Article Architecture and Protocols    November 2006

        ever precede one of any In-Reply-To header field in a followup.

7.6.1.  Construction its own parents.

6.7.  Duties of a Reading Agent

   A reading agent downloads articles from a storage agent, as directed
   by the References header field

   The following procedure is to be used whenever some previous article
   (the "parent") is to be referred reader, and displays them to in the References header field
   (F-3.2.2) of a new article, whether reader (or processes them in the course of generating a
   followup or for
   some other reason (e.g. manner). It SHOULD also have the later parts of a
   multipart posting such as a FAQ, or capability to show the later parts of a
   message/partial
   raw article exactly as suggested in [RFC 2046]).

   The (semantic) content received.

   It MAY present lists of articles available for display, and MAY
   structure those lists so as to show the new article's References header field
   consists of relationships between the content of
   articles, as determined by the Message-ID References, Subject, Date and other
   header field fields (see [USEAGE] for some usual methods of the parent
   preceded, if the parent had a References header field, by the content doing this).
[This whole section may yet get omitted]

6.8.  Duties of that References header field and a SP (subject to trimming as
                News Article Architecture and Protocols     January 2006

   described below).

   If the resulting References header field would, after unfolding,
   exceed 998 characters in length (including its field name but not the
   final CRLF), it MUST be trimmed (and otherwise it MAY be trimmed).
   Trimming involves removing any number of message identifiers from its
   content, except that the first message identifier and the last two
   MUST NOT be removed.

        NOTE: There is no provision in this standard for an article to
        have more than one parent. The essential property of the
        References header field, guaranteed by the procedure above and
        to be preserved in any future extension, is that no article can
        ever precede one of its own parents.

7.7.  Duties of a Reading Agent

   A reading agent downloads articles from a serving agent, as directed
   by the reader, and displays them to the reader (or processes them in
   some other manner). It SHOULD also have the capability to show the
   raw article exactly as received.

   It MAY present lists of articles available for display, and MAY
   structure those lists so as to show the relationships between the
   articles, as determined by the References, Subject, Date and other
   header fields (see [USEAGE] for some usual methods of doing this).
[This whole section may yet get omitted]

7.8.  Duties of a Moderator

   A Moderator receives news articles, customarily by email, decides
   whether Moderator

   A Moderator receives news articles, customarily by email, decides
   whether to approve them and, if so, either injects them into the news
   stream or forwards them to further moderators.

   Articles will be received by the moderator either encapsulated as an
   object of Content-Type application/news-transmission (or possibly
   encapsulated but without an explicit Content-Type header field), or
   else directly as an email already containing all the header fields
   appropriate for a Netnews article (see 7.2.2). 6.2.2).  Moderators SHOULD be
   prepared to accept articles in either format.

   A moderator processes an article, as submitted to any newsgroup that
   he moderates, as follows:

   1. He decides, on the basis of whatever moderation policy applies to
      his group, whether to approve or reject the article. He MAY do
      this manually, or else partially or wholly with the aid of
      appropriate software for whose operation he is then responsible.
      If the article is a cancel nessage (6.3) (5.3) issued by the poster of
      an earlier article, then he is expected to cancel that earlier
      article (in which case there is no more to be done).  He MAY
      modify the article if that is in accordance with the applicable
      moderation policy (and in particular he MAY remove redundant
      header fields and add Comments and other informational header
                News Article Architecture and Protocols     January 2006
      fields).  He also needs to be aware if any change he makes to the
      article will invalidate some authentication check provided by the
      poster or by an earlier moderator.

      If the article is rejected, then it normally fails for all the
      newsgroups for which it was intended. If it is approved, the
      moderator proceeds with the following steps.

   2. If the Newsgroups header field contains further moderated
      newsgroups for which approval has not already been given, he adds
      an indication (identifying both himself and the name of the group)
      that he approves the article, and then forwards it to the
      moderator of the leftmost unapproved group (which, if this
                News Article Architecture and Protocols    November 2006

      standard has been followed correctly, will generally be the next
      moderated group to the right of his own). There are two ways to do
      this:

      (a)  He emails it to the submission address of the next moderator
           (see section 7.2.2 6.2.2 for the proper method of doing this), or

      (b)  he rotates the <newsgroup-name>s in the Newsgroups header
           field to the left so that the targeted group is the leftmost
           moderated group in that field, and injects it again (thus
           causing the injecting agent to forward it to the correct
           moderator). However, he MUST first ensure that the article
           contains no Approved header field.

        NOTE: This standard does not prescribe how a moderator's
        approval is to be indicated (though a future standard may do
        so).  Possible methods include adding an Approved header field
        (or a similar but differently named header field if method (b)
        is being used) listing all the approvals made so far, or adding
        a separate header field for each individual approval (the header
        field X-Auth is sometimes used for this purpose).  The approval
        may also be confirmed with some form of digital signature (6.1). (5.1).

   3. If the Newsgroups header field contains no further unapproved
      moderated groups, he adds an Approved header field (F-3.2.9) (F-3.2.1)
      identifying himself and, insofar as is possible, all the other
      moderators who have approved the article. He thus assumes
      responsibility for having ensured that the article was approved by
      the moderators of all the moderated groups involved.

   4. The Date header field SHOULD be retained. Any Injection-Date
      header field already present (though there should be none) MUST be
      removed. Exceptionally, if it is known that the injecting agent
      does not yet support the Injection-Date header field and the Date
      header field appears to be stale (F-3.2.1) (F-3.2.7) for reasons understood
      by the moderator (e.g. delays in the moderation process) he MAY
      substitute the current date. The Message-ID header field SHOULD
      also be retained unless it is obviously non-compliant with this
      standard.

                News Article Architecture and Protocols     January 2006
      [USEFOR].

        NOTE: A message identifier <msg-id-core> created by a conforming posting or
        injecting agent, or even by a mail user agent conforming to [RFC
        2822], may reasonably be supposed to be conformant (and will, in
        any case, be caught by the injecting agent if it is not).

   5. Any variant header fields (2.4) MUST be removed, except that a
      Path header field MAY be truncated to only those entries following
      its "POSTED" <path-keyword>. <diag-keyword>.  Any Injection-Info header field (F-
      3.2.14)
      3.2.8) SHOULD be removed (and if not, the injecting agent will do
      so, as required in 7.2.2). 6.2.2).

   6. He then causes the article to be injected, having first observed
      all the duties of a posting agent.

                News Article Architecture and Protocols    November 2006

        NOTE: This standard does not prescribe how the moderator or
        moderation policy for each newsgroup is established; rather it
        assumes that whatever agencies are responsible for the relevant
        network or hierarchy (1.1) will have made appropriate
        arrangements in that regard.

7.9.

6.9.  Duties of a Gateway

   A Gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles. Encapsulation of a news article into a message of MIME
   type application/news-transmission, or the subsequent undoing of that
   encapsulation, is not gatewaying, since it involves no transformation
   of the article.

   There are two basic types of gateway, the Outgoing Gateway that
   transforms a news article into a different type of message, and the
   Incoming Gateway that transforms a message from another medium into a
   news article and injects it into a news system. These are handled
   separately below.

   The primary diktat for a gateway is:

        Above all, prevent loops.

   Transformation of an article into another medium stands a very high
   chance of discarding or interfering with the protection inherent in
   the news system against duplicate articles. The most common problem
   caused by gateways is "spews", gateway loops that cause previously
   posted articles to be reinjected repeatedly into Usenet. To prevent
   this, a gateway MUST take precautions against loops, as detailed
   below.

   If bidirectional gatewaying (both an incoming and an outgoing
   gateway) is being set up between Netnews and some other medium, the
   incoming and outgoing gateways SHOULD be coordinated to avoid
   unintended reinjection of gated articles. Circular gatewaying
   (gatewaying a message into another medium and then back into Netnews)
   SHOULD NOT be done; encapsulation of the article SHOULD be used
   instead where this is necessary.

                News Article Architecture and Protocols     January 2006

   A second general principal of gatewaying is that the transformations
   applied to the message SHOULD be as minimal as possible while still
   accomplishing the gatewaying. Every change made by a gateway
   potentially breaks a property of one of the media or loses
   information, and therefore only those transformations made necessary
   by the differences between the media should be applied.

   It is worth noting that safe bidirectional gatewaying between a
   mailing list and a newsgroup is far easier if the newsgroup is
   moderated. Posts to the moderated group and submissions to the
   mailing list can then go through a single point that does the
   necessary gatewaying and then sends the message out to both the
   newsgroup and the mailing list at the same time, eliminating most of
                News Article Architecture and Protocols    November 2006

   the possibility of loops. Bidirectional gatewaying between a mailing
   list and an unmoderated newsgroup, in contrast, is difficult to do
   correctly and is far more fragile.

   Newsgroups intended to be bidirectionally gated to a mailing list
   SHOULD therefore be moderated where possible, even if the moderator
   is a simple gateway and injecting agent that correctly handles
   crossposting to other moderated groups and otherwise passes all
   traffic.

7.9.1.

6.9.1.  Duties of an Outgoing Gateway

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent. The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated. The operation of the outgoing gateway
   is subject to additional constraints due to the possibility of one or
   more corresponding incoming gateways back from that medium to
   Netnews, since this opens the possibility of loops.

   In general, the following practices are recommended for all outgoing
   gateways, regardless of whether there is known to be a related
   incoming gateway, both as a precautionary measure and as a guideline
   to quality of implementation.

   1. The message identifier of the news article should be preserved if
      at all possible, preferably as or within the corresponding unique
      identifier of the other medium, but if not at least as a comment
      in the message. This helps greatly with preventing loops.

   2. The Date and Injection-Date of the news article should also be
      preserved if possible, for similar reasons.

   3. The message should be tagged in some way so as to prevent its
      reinjection into Netnews. This may be impossible to do without
      knowledge of potential incoming gateways, but it is better to try
      to provide some indication even if not successful; at the least, a
      human-readable indication that the article should not be gated
      back to Netnews can help locate a human problem.

                News Article Architecture and Protocols     January 2006

   4. Netnews control messages should not be gated to another medium
      unless they would somehow be meaningful in that medium.

   5. Changes MAY be made to the Content-Transfer-Encoding of some or
      all parts of the body, and even to the charsets specified in
      <encoded-word>s or in Content-Type header fields, but such changes
      SHOULD NOT be made unless absolutely necessary.

7.9.2.

6.9.2.  Duties of an Incoming Gateway

   The incoming gateway has the serious responsibility of ensuring that
   all of the requirements of this standard are met by the articles that
   it forms. In addition to its special duties as a gateway, it bears
   all of the duties and responsibilities of an injecting agent as well,
                News Article Architecture and Protocols    November 2006

   and additionally has the same responsibility of a relaying agent to
   reject articles that it has already gatewayed.

   An incoming gateway MUST NOT gate the same message twice. It may not
   be possible to ensure this in the face of mangling or modification of
   the message, but at the very least a gateway, when given a copy of a
   message it has already gated identical except for trace header fields
   (like Received in Email or Path in Netnews) MUST NOT gate the message
   again.  An incoming gateway SHOULD take precautions against having
   this rule bypassed by modifications of the message that can be
   anticipated.

   News articles prepared by gateways MUST be legal news articles. In
   particular, they MUST include all of the mandatory header fields,
   MUST fully conform to the restrictions on those fields, and SHOULD
   exclude any deprecated header fields (e.g. as in [RFC 2298]).  This
   often requires that a gateway function not only as a relaying agent,
   but also partly as a posting agent, aiding in the synthesis of a
   conforming article from non-conforming input.

   Incoming gateways MUST NOT pass control messages (articles containing
   a Control or Supersedes header field) without removing or renaming
   that header field. Gateways MAY, however, generate their own cancel
   messages, under the general allowance for injecting agents to cancel
   their own messages ([USEAGE]).  If a gateway receives a message that
   it can determine is a valid equivalent of a cancel message in the
   medium it is gatewaying, it SHOULD discard that message without
   gatewaying it, generate a corresponding cancel message of its own,
   and inject that cancel message.

   Incoming gateways MUST NOT inject control messages other than
   cancels.  Encapsulation SHOULD be used instead of gatewaying, when
   direct posting is not possible or desirable.

        NOTE: It is not unheard of for mail-to-news gateways to be used
        to post control messages, but encapsulation should be used for
        these cases instead. Gateways by their very nature are
        particularly prone to loops. Spews of normal articles are bad
        enough; spews of control messages with special significance to
        the news system, possibly resulting in high processing load or
                News Article Architecture and Protocols     January 2006
        even email sent for every message received, are catastrophic. It
        is far preferable to construct a system specifically for posting
        control messages that can do appropriate consistency checks and
        authentication of the originator of the message.

   If there is a message identifier that fills a role similar to that of
   the Message-ID header field in news, it SHOULD be used in the
   formation of the message identifier of the news article, perhaps with
   transformations required to meet the uniqueness requirement of
   Netnews and with the removal of any comments so as to comply with the
   syntax in section F-3.1.3. Such transformations SHOULD be designed so
   that two messages with the same identifier generate the same
   Message-ID header field.

                News Article Architecture and Protocols    November 2006

        NOTE: Message identifiers play a central role in the prevention
        of duplicates, and their correct use by gateways will do much to
        prevent loops. Netnews does, however, require that message
        identifiers be unique, and therefore message identifiers from
        other media may not be suitable for use without modification. A
        balance must be struck by the gateway between preserving
        information used to prevent loops and generating unique message
        identifiers.

   Exceptionally, if there are multiple incoming gateways for a
   particular set of messages, each to a different newsgroup(s), each
   one SHOULD generate a message identifier unique to that gateway. Each
   incoming gateway nonetheless MUST ensure that it does not gate the
   same message twice.

        NOTE: Consider the example of two gateways of a given mailing
        list into the world-wide Usenet newsgroups, both of which
        preserve the email message identifier. Each newsgroup may then
        receive a portion of the messages (different sites seeing
        different portions).  In these cases, where there is no one
        "official" gateway, some other method of generating message
        identifiers has to be used to avoid collisions. It would
        obviously be preferable for there to be only one gateway which
        crossposts, but this may not be possible to coordinate.

   If no date information is available, the gateway MAY supply a Date
   header field with the gateway's current date.  If no injection-date
   information is available, the gateway MUST supply an Injection-Date
   header field with whatever date information is available, and
   otherwise with the gateway's current date.  If only partial
   information is available (e.g.  date but not time), this SHOULD be
   fleshed out to a full Date and/or Injection-Date header field by
   adding default values rather than discarding this information. Only
   in very exceptional circumstances should Date information be
   discarded, as it plays an important role in preventing reinjection of
   old messages.

   An incoming gateway MUST add a Sender header field to the news
   article it forms containing the <mailbox> of the administrator of the
   gateway.  Problems with the gateway may be reported to this
                News Article Architecture and Protocols     January 2006
   <mailbox>. The <display-name> portion of this <mailbox> SHOULD
   indicate that the entity responsible for injection of the message is
   a gateway. If the original message already had a Sender header field,
   it SHOULD be renamed so that its contents can be preserved.

7.9.3.

6.9.3.  Example

   To illustrate the type of precautions that should be taken against
   loops, here is an example of the measures taken by one particular
   combination of mail-to-news and news-to-mail gateways at Stanford
   University designed to handle bidirectional gatewaying between
   mailing lists and unmoderated groups.

                News Article Architecture and Protocols    November 2006

   1. The news-to-mail gateway preserves the message identifier of the
      news article in the generated email message. The mail-to-news
      gateway likewise preserves the email message identifier provided
      that it is syntactically valid for Netnews.  This allows the news
      system's built-in suppression of duplicates to serve as the first
      line of defense against loops.

   2. The news-to-mail gateway adds an X-Gateway header field to all
      messages it generates. The mail-to-news gateway discards any
      incoming messages containing this header field. This is robust
      against mailing list managers that replace the message identifier,
      and against any number of email hops, provided that the other
      message header fields are preserved.

   3. The mail-to-news gateway prepends the host name from which it
      received the email message to the content of the Path header
      field.  The news-to-mail gateway refuses to gateway any message
      that contains the list server name in its Path header field. This
      is robust against any amount of munging of the message header
      fields by the mailing list, provided that the email only goes
      through one hop.

   4. The mail-to-news gateway is designed never to generate bounces to
      the envelope sender. Instead, articles that are rejected by the
      news server (for reasons not warranting silent discarding of the
      message) result in a bounce message sent to an errors address
      known not to forward to any mailing lists, so that they can be
      handled by the news administrators.

   These precautions have proven effective in practice at preventing
   loops for this particular application (bidirectional gatewaying
   between mailing lists and locally distributed newsgroups where both
   gateways can be designed together). General gatewaying to world-wide
   newsgroups poses additional difficulties; one must be very wary of
   strange configurations, such as a newsgroup gated to a mailing list
   which is in turn gated to a different newsgroup.

                News Article Architecture and Protocols     January 2006

8.

7.  Security and Related Considerations

   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.

   See also F-5 for further security considerations related to the
   format of articles.
[And a similar pointer from there to here might be in order.]

8.1.

7.1.  Leakage

   Articles which are intended to have restricted distribution are
   dependent on the goodwill of every site receiving them.  The
   "Archive: no" header field (F-3.2.12) (F-3.2.2) is available as a signal to
   automated archivers not to file an article, but that cannot be
   guaranteed.

                News Article Architecture and Protocols    November 2006

   The Distribution header field makes provision for articles which
   should not be propagated beyond a 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.

   The flooding algorithm is extremely good at finding any path by which
   articles can leave a subnet with supposedly restrictive boundaries,
   and substantial administrative effort is required to avoid this.
   Organizations wishing to control such leakage are strongly advised to
   designate a small number of official gateways to handle all news
   exchange with the outside world (however, making such gateways too
   restrictive can also encourage the setting up of unofficial paths
   which can be exceedingly hard to track down).

   The sendme control message (6.4), (5.4), insofar as it is still used, can be
   used to request articles with a given message identifier, even one
   that is not supposed to be supplied to the requestor.

8.2.

7.2.  Attacks

8.2.1.

7.2.1.  Denial of Service

   The proper functioning of individual newsgroups can be disrupted by
   the massive posting of "noise" articles, by the repeated posting of
   identical or near identical articles, by posting followups unrelated
   to their precursors, or which quote their precursors in full with the
   addition of minimal extra material (especially if this process is
   iterated), and by crossposting to, or setting followups to, totally
   unrelated newsgroups.

   Many have argued that "spam", massively multiposted (and to a lesser
   extent massively crossposted) articles, usually for advertising
   purposes, also constitutes a DoS attack in its own regard.  This may
   be so.

                News Article Architecture and Protocols     January 2006

   Such articles intended to deny service, or other articles of an
   inflammatory nature, may also have their From or Reply-To addresses
   set to valid but incorrect email addresses, thus causing large
   volumes of email to descend on the true owners of those addresses.

   Similar effects could be caused by any email header field which could
   cause every reading agent receiving it to take some externally
   visible action.  For example, the Disposition-Notification-To header
   field defined in [RFC 2298] could cause huge numbers of
   acknowledgements to be emailed to an unsuspecting third party (for
   which reason [RFC 2298] declares that that header field SHOULD NOT be
   used in Netnews).

   It is a violation of this standard for a poster to use as his address
   a <mailbox> which he is not entitled to use.  Even addresses with an
   invalid <local-part> but a valid <domain> can cause disruption to the
   administrators of such domains.  Posters who wish to remain anonymous
   or to prevent automated harvesting of their addresses, but who do not
                News Article Architecture and Protocols    November 2006

   care to take the additional precautions of using more sophisticated
   anonymity measures, should avoid that violation by the use of
   addresses ending in the ".invalid" top-level-domain (see 7.5). 6.5).

   A malicious poster may also prevent his article being seen at a
   particular site by preloading that site into the Path header field
   (F-3.1.6)
   (F-3.1.5) and may thus prevent the true owner of a forged From or
   Reply-To address from ever seeing it.

   A malicious complainer may submit a modified copy of an article (e.g.
   with an altered Injection-Info header field) to the administrator of
   an injecting agent in an attempt to discredit the author of that
   article and even to have his posting privileges removed.
   Administrators should therefore obtain a genuine copy of the article
   from their own serving storage agent before taking such precipitate action.

   Administrative agencies with responsibility for establishing policies
   in particular hierarchies can and should set bounds upon the
   behaviour that is considered acceptable within those hierarchies (for
   example by promulgating charters for individual newsgroups, and other
   codes of conduct).

   Whilst this standard places an onus upon injecting agents to bear
   responsibility for the misdemeanours of their posters (which includes
   non-adherence to established policies of the relevant hierarchies as
   provided in section 7.2), 6.2), and to provide assistance to the rest of
   the network by making proper use of the Injection-Info (F-3.2.14) (F-3.2.8)
   header field, it makes no provision for enforcement, which may in
   consequence be patchy. Nevertheless, injecting sites which
   persistently fail to honour their responsibilities or to comply with
   generally accepted standards of behaviour are likely to find
   themselves blacklisted, with their articles refused propagation and
   even subject to cancellation, and other relaying sites would be well
   advised to withdraw peering arrangements from them.

                News Article Architecture and Protocols     January 2006

8.2.2.

7.2.2.  Compromise of System Integrity

   The posting of unauthorized (as determined by the policies of the
   relevant hierarchy) control messages can cause unwanted newsgroups to
   be created, or wanted ones removed, from serving storage agents.
   Administrators of such agents SHOULD therefore take steps to verify
   the authenticity of such control messages, either by manual
   inspection (particularly of the Approved header field) or by checking
   any digital signatures that may be provided (see 6.1). 5.1).  In addition,
   they SHOULD periodically compare the newsgroups carried against any
   regularly issued checkgroups messages, or against lists maintained by
   trusted servers and accessed by out-of-band protocols such as FTP or
   HTTP.

   Malicious cancel messages (6.3) (5.3) can cause valid articles to be
   removed from serving storage agents. Administrators of such agents SHOULD
   therefore take steps to verify that they originated from the
   (apparent) poster, the injector or the moderator of the article, or
   that in other cases they came from a place that is trusted to work
                News Article Architecture and Protocols    November 2006

   within established policies and customs. Such steps SHOULD include
   the checking of any digital signatures, or other security devices,
   that may be provided (see 6.1). 5.1).  Articles containing Supersedes
   header fields (F-3.2.6) (F-3.2.12) are effectively cancel messages, and SHOULD
   be subject to the same checks.  Currently, many sites choose to
   ignore all cancel messages on account of the difficulty of conducting
   such checks.

   Improperly configured serving injecting and relaying agents can allow
   articles posted to moderated groups onto the net without first being
   approved by the moderator. Injecting agents SHOULD verify that
   moderated articles were received from one of the entities given in
   their Approved header fields and/or check any digital signatures that
   may be provided (see
   6.1). 5.1).

   There may be weaknesses in particular implementations that are
   subject to malicious exploitation. In particular, it has not been
   unknown for complete shell scripts to be included within Control
   header fields. Implementors need to be aware of this.

   Reading agents should be chary of acting automatically upon MIME
   objects with an "application" Content-Type that could change the
   state of that agent, except in contexts where such applications are
   specifically expected (as in 5). 4).  Even the Content-Type "text/html"
   could have unexpected side effects on account of embedded objects,
   especially embedded executable code or URIs that invoke non-news
   protocols such as HTTP [RFC 2616].  It is therefore generally
   recommended that reading agents do not enable the execution of such
   code (since it is extremely unlikely to have a valid application
   within Netnews) and that they only honour URIs referring to other
   parts of the same article.

   Non-printable characters embedded in article bodies may have
   surprising effects on printers or terminals, notably by reconfiguring
   them in undesirable ways which may become apparent only after the
                News Article Architecture and Protocols     January 2006
   reading agent has terminated.

8.3.

7.3.  Liability

[This whole section might be better removed to [USEAGE].]

   There is a presumption that a poster who sends an article to Usenet
   intends it to be stored on a multitude of serving storage agents, and has
   therefore given permission for it to be copied to that extent.
   Nevertheless, Usenet is not exempt from the Copyright laws, and it
   should not be assumed that permission has been given for the article
   to be copied outside of Usenet, nor for its permanent archiving
   contrary to any Archive header field that may be present.

   Posters also need to be aware that they are responsible if they
   breach Copyright, Libel, Harassment or other restrictions relating to
   material that they post, and that they may possibly find themselves
   liable for such breaches in jurisdictions far from their own. Serving
   agents may also be liable in some jurisdictions, especially if the
                News Article Architecture and Protocols    November 2006

   breach has been explicitly drawn to their attention.

   Users who are concerned about such matters should seek advice from
   competent legal authorities.

9.

8.  IANA Considerations

   IANA is requested to register the following media types, described
   elsewhere in this standard, for use with the Content-Type header
   field, in the IETF tree in accordance with the procedures set out in
   [RFC 2048]. 4288].

      application/news-transmission  (5.1)  (4.1)
      application/news-groupinfo     (5.3)     (4.3)
      application/news-checkgroups   (5.4)   (4.4)

   IANA is also requested to change the status of the following media
   type to "OBSOLETE".

      message/news                   (5.2)                   (4.2)

        NOTE: "Application/news-transmission" is an update, with
        clarification and additional optional parameters, to an existing
        registration. "Message/rfc822" should now be used in place of
        the obsoleted "message/news".

10.  nr H1 7

9.  References

10.1.

9.1.  Normative 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.

                News Article Architecture and Protocols     January 2006

   [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 in RFCs to Indicate
        Requirement Levels", RFC 2119, March 1997.

   [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
        RFC 2606, June 1999.

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

   [RFC 3864] G. Klyne, M. Nottingham, and J. Mogul, "Registration
        procedures for message header fields", RFC 3864.

   [USEAGE] draft-ietf-usefor-useage-*.txt.

   [USEFOR] K. Murchison et al, "News Article Format", draft-ietf-
        usefor-usefor-*.txt.
        usefor-usefor-11.txt.

   [USEPRO] This Standard.

10.2.

                News Article Architecture and Protocols    November 2006

9.2.  Informative References

   [NNTP] Clive D.W. Feather, "Network News Transport Protocol", draft-
        ietf-nntpext-base-*.txt.

   [PGPVERIFY] David Lawrence,
        <ftp://ftp.isc.org/pub/pgpcontrol/README.html>.

   [RFC 1036] M. Horton and R. Adams, "Standard for Interchange of
        USENET Messages", RFC 1036, December 1987.

   [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of 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 2142] D. Crocker, "Mailbox Names for Common Services, Roles and
        Functions", RFC 2142, May 1997.

   [RFC 2298] R. Fajman, "An Extensible Message Format for Message
        Disposition Notifications", RFC 2298, March 1998.

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

                News Article Architecture and Protocols     January 2006

   [RFC 2821] John C. Klensin and Dawn P. Mann, "Simple Mail Transfer
        Protocol", RFC 2821, April 2001.

   [RFC 3977] C. Feather, "Network News Transport Protocol (NNTP)", RFC
        3977.

   [RFC 4288] N. Freed and J. Klensin, "Media Type Specifications and
        Registration Procedures", RFC 4288, December 2005.

   [RFC 976] Mark R. Horton, "UUCP mail interchange format standard",
        RFC 976, February 1986.

   [Son-of-1036] Henry Spencer, "News article format and transmission",
        <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.

11.

   [USEAGE] draft-ietf-usefor-useage-*.txt.

10.  Acknowledgements

   As this document is the result result of a ten year effort, the number of
   people that have contributed to its content are too numerous to
   mention individually.  Many thanks go out to all past and present
   members of the USEFOR Working Group of the Internet Engineering Task
   Force (IETF) and the accompanying mailing list.

                News Article Architecture and Protocols    November 2006

11.  Contact Address

Editor

        Charles. H. Lindsey
        5 Clerewood Avenue
        Heald Green
        Cheadle
        Cheshire SK8 3JU
        United Kingdom
        Phone: +44 161 436 6131
        Email: chl@clerew.man.ac.uk

[

Working group chairs

        Alexey Melnikov <alexey.melnikov-usefor@isode.com>
        Harald Tveit Alvestrand <harald@alvestrand.no>
]

   Comments on this draft should preferably be sent to the mailing list
   of the Usenet Format Working Group at

        ietf-usefor@imc.org.

Appendix A - Obsolete Control Messages

   This present standard obsoletes certain control messages defined in
   [RFC 1036] (see 5.5), all of which had the effect of requesting a
   description of a relaying or storage agent's software, or its peering
   arrangements with neighbouring sites, to be emailed to the article's
   reply address. Whilst of some utility when Usenet was much smaller
   than it is now, they had become no more than a tool for the malicious
   sending of mailbombs. Moreover, many organizations now consider
   information about their internal connectivity to be confidential.

      version
      sendsys
      whogets
      senduuname

   "Version" requested details of the transport software in use at a
   site.  "Sendsys" requested the full list of newsgroups taken, and the
   peering arrangements. "Whogets" was similar, but restricted to a
   named newsgroup.  "Senduuname" resembled "sendsys" but restricted to
   the list of peers connected by UUCP.

   Historically, a checkgroups body consisting of one or two lines, the
   first of the form "-n newsgroup", caused check-groups to apply to
   only that single newsgroup.

                News Article Architecture and Protocols    November 2006

   Historically, an article posted to a newsgroup whose name had exactly
   three components of which the third was "ctl" signified that article
   was to be taken as a control message.  The Subject header field
   specified the actions, in the same way the Control header field does
   now.

   These forms are documented for archaeological purposes only; they
   MUST NO LONGER be used.

Appendix B - Differences from the Protocols in RFC 1036 and its
derivatives

   This apendix contains a list of changes that have been made to the
   protocols of the earlier standards, specifically [RFC 1036].  See F-
   Appendix B.  for the related syntax changes.

     o There is a new Control message 'mvgroup' to facilitate moving a
       group to a different place (name) in a hierarchy.
     o Certain Control messages (Appendix A) have been made obsolete,
       and the special significance of "cmsg" when at the start of a
       Subject header field has been removed (section 5).
     o Additional media types are defined for better structuring of
       control messages (4.3 and 4.4).
     o Distributions are expected to be checked at the receiving end, as
       well as the sending end, of a relaying link.
     o There are numerous other small changes, clarifications and
       enhancements.

Appendix C - Transitional Arrangements

   It is the intention that the new features of [USEFOR] and of this
   standard can be assimilated into Usenet as it presently operates
   without major interruption to the service, though some of an eight year effort, the number of
   people that have contributed new
   features may not begin to its content show benefit until they become widely
   implemented.

   An important distinction must be made between news servers, which are too numerous to
   mention individually.  Many thanks go out to all past and present
   members of
   responsible for the USEFOR Working Group distribution and storage of the Internet Engineering Task
   Force (IETF) news articles, and
   user agents, which are responsible for interactions with users. It is
   important that the accompanying mailing list.

12.  Contact Address

Editor

        Charles. H. Lindsey
        5 Clerewood Avenue
        Heald Green
        Cheadle
        Cheshire SK8 3JU
        United Kingdom
        Phone: +44 161 436 6131
        Email: chl@clerew.man.ac.uk

[

Working group chairs

        Alexey Melnikov <alexey.melnikov-usefor@isode.com>
        Harald Tveit Alvestrand <harald@alvestrand.no>
]

   Comments on this draft former should preferably be sent upgraded to conform to this
   standard as soon as possible to provide the mailing list benefit of the Usenet Format Working Group at

        ietf-usefor@imc.org.

Appendix A - Obsolete Control Messages

   This present standard obsoletes certain control messages defined in
   [RFC 1036] (see 6.5), all enhanced
   facilities.  Fortunately, the number of which had distinct implementations of
   such servers is rather small, at least so far as the effect main "backbone"
   of requesting Usenet is concerned, and many of the new features are already
   supported. Contrariwise, there are a
   description great number of implementations
   of user agents, installed on a relaying or serving agent's software, or its peering
   arrangements with neighbouring sites, vastly greater number of small sites.
   Therefore, the new functionality has been designed so that existing
   user agents may continue to be emailed to used, although the article's
   reply address. Whilst of some utility when Usenet was much smaller
   than it is now, they had become no more than full benefits may
   not be realised until a tool for the malicious
   sending substantial proportion of mailbombs. Moreover, many organizations now consider
   information about their internal connectivity them have been
   upgraded.

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

                News Article Architecture and Protocols     January    November 2006

      version
      sendsys
      whogets
      senduuname

   "Version" requested details

     o The introduction of whitespace and folding into the transport software in use Newsgroups
       and related header fields (F-3.1.4, F-3.2.4, F-3.2.6) and of
       <comment>s into the References header field (F-3.2.10) will cause
       problems for existing agents, and [USEFOR] provides that they
       SHOULD NOT be generated at the present time.
     o The requirement in [USEFOR] to support MIME reflects a
   site.  "Sendsys" requested practice
       that is already widespread.  Articles in strict compliance with
       the full list previous standards (using strict US-ASCII) will be
       unaffected.
     o All the header fields newly introduced by [USEFOR] can safely be
       ignored by existing software, albeit with loss of newsgroups taken, and the
   peering arrangements. "Whogets" was similar, but restricted new
       functionality.
     o The new style of Path header field, using a <diag-match> to allow
       "!!"  as a
   named newsgroup.  "Senduuname" resembled "sendsys" but restricted <delimiter> and introducing <path-diagnostic>s (which
       can be distinguished from <path-identity>s by their leading ".")
       is already consistent with the previous standards. However, the
       intention is that relaying agents should eventually reject
       articles in the old style, and so this possibility should be
       offered as a configurable option in relaying agents. User agents
       are unaffected.
     o The new Control: mvgroup command will need to be implemented in
       storage agents. For the list benefit of peers connected older storage agents it is
       therefore RECOMMENDED that it be followed shortly by UUCP.

   Historically, a checkgroups body consisting of one or two lines,
       corresponding newgroup command and it MUST always be followed by
       a rmgroup command for the
   first old group after a reasonable overlap
       period. An implementation of the form "-n newsgroup", caused check-groups to apply to
   only that single newsgroup.

   Historically, mvgroup command as an article posted to a newsgroup whose name had exactly
   three components of which alias for
       the third was "ctl" signified that article
   was to newgroup command would thus be taken as a control message.  The Subject minimally conforming. User
       agents are unaffected.
     o Provision is made for relaying and storage agents to use the Date
       header field
   specified the actions, in the same way the Control case of articles injected through existing
       agents which do not yet provide an Injection-Date header field does
   now.

   These forms are documented for archaeological purposes only; they
   MUST NO LONGER be used. field.

Appendix B D - Notices

Intellectual Property

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

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

                News Article Architecture and Protocols    November 2006

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

                News Article Architecture and Protocols     January 2006

Full Copyright Statement

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

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

Appendix C E - Change Log

[This Appendix is to be removed prior to final publication.]

   For version 01

   1    Numerous texts describing protocol features related to
        particular header fields in parts of [ARTICLE] which were
        destined to become part of [USEFOR] have been moved to
        appropriate locations within section 7 of this document. Such
        revised texts will be found in sections
        7.2.2 Steps 4, 6, 7, 10, 11, 12;
        7.2.3 Step 1(b);
        7.3 introductory paragraphs, Steps 1, 4, 8, 9, and some final
        paragraphs;
        7.4 introductory and final paragraphs;
        7.9.1 Step 5.

   2    A section on "Duties of a Reading Agent" (7.8) has been added.

   3    Some demotions MUST -> SHOULD -> MAY, as noted in pseudo-
        comments, have been made or proposed in sections
        7.3
        7.3 Step 4.

   4    Part of the procedure for examining Path header fields by
        relaying agents has been moved to serving storage agents, as explained
        in pseudo-comments in section 7.4.

   5    Some renumbering of sections and minor textual clarifications.

   For version 02
                News Article Architecture and Protocols    November 2006

   1    2nd para. of a-7 temporarily reinstated in section 6.

   2    Para. in section 6 relating to propagation of control messages
        and local policy removed to [USEAGE].]
                News Article Architecture and Protocols     January 2006

   3    Requirement for some relaying agents to examine control messages
        for non-existent groups
        6
        7.3

   4    Text regarding "aliasing out" brought into line with actual
        practice.
        7.3

   5    More realistic wording regarding the expectations of reading
        agents
        7.7
        7.4

   6    "Precursor" is now defined for all cases in which a References
        header field may be used (even though "followup" is not always
        defined under Alternative-1).
        2.1

   7    Provision is made for a poster to use a mailbox ending in
        ".invalid" in a From header field (formerly in a-5.2).
        7.5

   8    "Inheritable" and "Variant" header fields defined (formerly in
        a-4.2.5).
        2.3

   9    Additional wording regarding function of verb/arguments/body in
        control messages (formerly in a-6.13).
        6

   10   NOTE regarding not altering message indentifiers during
        transport or copying added (formerly in a-5.3).
        7.3

   11   All mention of MIME-style parameters and extension-parameters
        removed.
        3.1
        7.6

   For version 03

   1    The term "inheritable header" is no longer defined. Instead, the
        term "inherited' is used in place of "taken" when defining the
        actions of a followup agent.
        7.6
                News Article Architecture and Protocols    November 2006

   2    Consequent changes to "variant header field", and also mention
        of Injection-Info as sometimes variant.
        2.3

   3    The term "reply address" is no longer defined.

                News Article Architecture and Protocols     January 2006

   4    References now made to sections within USEFOR using "F-..."
        notation.

   5    Cross-references to sections within USEFOR added. Consistent use
        of <...> around all mentions of syntactic objects. All
        occurrences of "Foobar-header" changed to "Foobar header". Many
        other minor textual changes.

   6    <control-message> changed to <control-command>, to avoid
        confusion with "control message", which signifies the complete
        article containing the <control-command>.

   7    <ihave-arguments> has been changed to <ihave-argument> (since
        the earlier practice of multiple arguments is now deprecated).
        Likewise <sendme-argument>.

   For version 04

   1    References divided into Normative and Informational.

   2    All mention of the Mail-Copies-To, Posted-And-Mailed and
        Complaints-To header fields removed.

   3    NOTE added to contrast MUST for References header field with
        SHOULD in RFC 2822.
        7.6

   4    Changes arising from the new syntax of <path-delimiter>s and
        <path-keyword>s.
        7.3

   5    Changes to clarify the construction of the References header
        field.
        7.6.1

   6    Changes due to removal of <comment>s from further header fields.

   7    New section on Identification of news-servers describing
        acceptable forms for <path-identity>s.
        2.3

   8    Definition of "semantic content" of a header field.
        2.1

   9    Systematic replacement of "header" by "header field".

                News Article Architecture and Protocols    November 2006

   10   More stringent rules for checking <newsgroup-name>s in control
        messages for compliance with USEFOR.
        6.2

   For version 05
                News Article Architecture and Protocols     January 2006

   1    Historical Appendices A.1 and A.2 removed, in anticipation of
        republication of Son-of-1036 as an Informational RFC.
        1.3

   2    Definitions of technical terms adopted from USEFOR rather than
        defining them separately.

   3    Discussion of <path-identity> rewritten to reflect recent
        developments (but still awaiting further work in USEFOR).
        2.3

   4    Items now included in Appendix A of USEFOR have been removed
        from section 3, and the "Transitional Arrangements" (which still
        cover the USEFOR changes) have been modified to reflect this.

   For version 06

   1    Procedures for constructing the Path header field updated to
        conform with USEFOR.

   2    s/serving agent/storage agent/ throughout.

   3    s/trusted source/verified source/

   4    Chapter 3 (Changes to the existing protocols) moved to
        Appendices B & C, and subsequent chapters renumbered.