Subject: draft-ietf-usefor-usepro-02

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Dec 2004 19:54:53 GMT

See http://www.ietf-usefor.imc.org/drafts/draft-ietf-usefor-usepro-02.txt
and http://www.ietf-usefor.imc.org/drafts/draft-ietf-usefor-usepro-02.unpaged

Also sent to the drafts editor.

The changes comprise:

A. Various items we discussed earlier, mostly regarding relaying agents
and control messages, and whose revised texts I posted here a couple of
weeks back.

B. Various bits of text formerly in draft 13 which, after discussion with
our Chair, it was decided belonged in USEPRO rather than USEFOR.
Mostly, items in this category do not change anything, although the new
wording regarding the use of the TLD ".invalid" in section 5 is a little
stronger than in the old a-5.2. If you think it is too strong, please
speak up.

All the changes are described briefly in an Appendix at the end. For those
who want to examine the changes word by word, here are the full diffs.

*** landfield/drafts/draft-ietf-usefor-usepro-01.unpaged	Mon Sep 20 17:18:31 2004
--- /tmp/usepro.02	Fri Dec  3 19:24:12 2004
***************
*** 2,9 ****
  INTERNET-DRAFT                               Charles H. Lindsey
  Usenet Format Working Group                  University of Manchester
!                                              September 2004
  
                  News Article Architecture and Protocols
!                    <draft-ietf-usefor-usepro-01.txt>
  
  Status of this Memo
--- 2,9 ----
  INTERNET-DRAFT                               Charles H. Lindsey
  Usenet Format Working Group                  University of Manchester
!                                              December 2004
  
                  News Article Architecture and Protocols
!                    <draft-ietf-usefor-usepro-02.txt>
  
  Status of this Memo
***************
*** 31,35 ****
     http://www.ietf.org/shadow.html.
  
!    This Internet-Draft will expire in March 2005.
  
  Abstract
--- 31,35 ----
     http://www.ietf.org/shadow.html.
  
!    This Internet-Draft will expire in June 2005.
  
  Abstract
***************
*** 83,87 ****
    2.1.  Definitions ...............................................    0
    2.2.  Defining the Architecture .................................    0
!   2.3.  Textual Notations .........................................    0
  3.  Changes to the existing protocols .............................    0
    3.1.  Principal Changes .........................................    0
--- 83,90 ----
    2.1.  Definitions ...............................................    0
    2.2.  Defining the Architecture .................................    0
!   2.3.  Header Properties .........................................    0
!     2.3.1.  Inheritable Headers ...................................    0
!     2.3.2.  Variant Headers .......................................    0
!   2.4.  Textual Notations .........................................    0
  3.  Changes to the existing protocols .............................    0
    3.1.  Principal Changes .........................................    0
***************
*** 252,261 ****
  
     An "article" is the unit of news, synonymous with an [RFC 2822]
!    "message".
  
-    A "proto-article" (7.2.1) is one that has been created by a "posting
-    agent" but has not yet been injected into a Netnews system system by
-    an "injecting agent". It may lack some otherwise mandatory headers.
- 
     A "message identifier" (a-5.3) is a unique identifier for an article,
     usually supplied by the posting agent which posted it or, failing
--- 255,263 ----
  
     An "article" is the unit of news, synonymous with an [RFC 2822]
!    "message".  A "proto-article" (7.2.1) is one that has been created by
!    a "posting agent" but has not yet been injected into a Netnews system
!    system by an "injecting agent". It may lack some otherwise mandatory
!    headers.
  
     A "message identifier" (a-5.3) is a unique identifier for an article,
     usually supplied by the posting agent which posted it or, failing
***************
*** 281,286 ****
     used where several initial components are shared.
  
!    A "poster" is the person or software that composes and submits a
!    possibly compliant article to a posting agent. The poster is
     synonymous with [RFC 2822]'s author.
  
--- 283,288 ----
     used where several initial components are shared.
  
!    A "poster" is the person or software that composes a possibly
!    compliant article for submission to a posting agent. The poster is
     synonymous with [RFC 2822]'s author.
  
***************
*** 287,300 ****
     A "reader" is the person or software reading news articles.
  
!    A "followup" is an article containing a response to the contents of
!    an earlier article (the followup's "precursor").
! [Alternative definition, to bu ised if similar woprding is not added to
! the description of the References-header (a-6.10):]
  
     A "followup" is an article containing a response to the contents of
!    an earlier article (its "precursor"), or which is otherwise intended
!    to be grouped with that article for purposes of display (e.g. as part
!    of a multipart posting such as a FAQ).
  
     An (email) "address" is the mailbox [RFC 2822] (or more particularly
     the addr-spec within that mailbox) which directs the delivery of an
--- 289,310 ----
     A "reader" is the person or software reading news articles.
  
! [Alternative-1.]
  
     A "followup" is an article containing a response to the contents of
!    an earlier article.
  
+    An article is a "precursor" of some later article which is a followup
+    to it, or which is otherwise intended to be grouped with it for
+    purposes of display (e.g. as a part of a multipart posting such as a
+    FAQ).
+ 
+ [Alternative-2.]
+ 
+    A "followup" to an earlier article (its "precursor") is one intended
+    to be grouped with that article for purposes of display (e.g. because
+    it is a response to its contents or is a part of a multipart posting
+    such as a FAQ).
+ [End of alternatives]
+ 
     An (email) "address" is the mailbox [RFC 2822] (or more particularly
     the addr-spec within that mailbox) which directs the delivery of an
***************
*** 309,317 ****
     agent or, which amounts to the same thing, for passing the article to
     the injecting agent.
  
     A "control message" is an article which is marked as containing
!    control information; a "serving agent" receiving such an article may
!    (subject to the policies observed at that site) take actions beyond
!    just filing and passing on the article.
  
  2.2.  Defining the Architecture
--- 319,329 ----
     agent or, which amounts to the same thing, for passing the article to
     the injecting agent.
+ [Is the definition in RFC 2822 sufficient?]
  
     A "control message" is an article which is marked as containing
!    control information; a "serving agent" (and in some cases a "relaying
!    agent") receiving such an article may (subject to the policies
!    observed at that site) take actions beyond just filing and passing on
!    the article.
  
  2.2.  Defining the Architecture
***************
*** 334,345 ****
     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.
- [Alternative definition, to be used if the alternative definition for
- "followup" is used:]
  
     A "followup agent" is a combination of reading agent and posting
!    agent that aids in the preparation and posting of a response intended
!    as a followup to a precursor.
  
     An "injecting agent" takes the finished article from the posting
--- 346,360 ----
     A "reading agent" is software which presents articles to a reader.
  
+ [Alternative-1.]
+ 
     A "followup agent" is a combination of reading agent and posting
     agent that aids in the preparation and posting of a followup.
  
+ [Alternative-2.]
+ 
     A "followup agent" is a combination of reading agent and posting
!    agent that aids in the preparation and posting of an article which is
!    a response to some precursor.
! [End of alternatives]
  
     An "injecting agent" takes the finished article from the posting
***************
*** 377,382 ****
     collectively as "user agents".
  
! 2.3.  Textual Notations
  
     This standard contains explanatory NOTEs using the following format.
     These may be skipped by persons interested solely in the content of
--- 393,447 ----
     collectively as "user agents".
  
! 2.3.  Header Properties
  
+    There are two special properties that may apply to particular
+    headers, namely: "inheritable", and "variant". When a header is
+    defined, in this (or any future) standard, as having one (or possibly
+    more) of these properties, it is subject to special treatment, as
+    indicated below.
+ 
+ 2.3.1.  Inheritable Headers
+ 
+    Subject only to the overriding ability of the poster to determine the
+    contents of the headers in a proto-article, headers with the
+    inheritable property MUST be copied by followup agents (perhaps with
+    some modification) into the followup article, and headers without
+    that property MUST NOT be so copied.
+ 
+    The following headers (see [USEFOR] for their definitions) are
+    classified as "inheritable":
+      o Newsgroups (a-5.5) - copied from the precursor, subject to any
+        Followup-To-header.
+      o Subject (a-5.4) - often modified by prefixing with "Re: ", but
+        otherwise copied from the precursor.
+      o References (a-6.10) - copied from the precursor, with the
+        addition of the precursor's Message-ID.
+      o Distribution (a-6.6) - copied from the precursor.
+ 
+         NOTE: The Keywords-header is not inheritable, though some older
+         newsreaders treated it as such.
+ 
+ 2.3.2.  Variant Headers
+ 
+    Headers 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 headers are modified as articles are propagated, or
+    they reflect the status of the article on a particular serving agent,
+    or cooperating group of such agents. The variant header MAY be placed
+    anywhere within the headers (though placing it first is recommended).
+ 
+ 
+    The following headers (see [USEFOR] for their definitions) are
+    classified as "variant":
+      o Path (a-5.6) - augmented at each relaying agent that an article
+        passes through.
+      o Xref (a-6.16) - used to keep track of the article locators of
+        crossposted articles so that reading agents serviced by a
+        particular serving agent can mark such articles as read.
+ 
+ 2.4.  Textual Notations
+ 
     This standard contains explanatory NOTEs using the following format.
     These may be skipped by persons interested solely in the content of
***************
*** 454,460 ****
         Complaints-To, Injection-Info, Mail-Copies-To, Posted-And-Mailed
         and User-Agent, leading to increased functionality.
-      o Provision has been made for almost all headers to have MIME-style
-        parameters (to be ignored if not recognized), thus facilitating
-        extension of those headers in future standards.
       o Certain headers and Control messages (a-Appendix A.3 and Appendix
         A.3) have been made obsolete.
--- 520,523 ----
***************
*** 728,731 ****
--- 789,829 ----
     otherwise.
  
+    Each control message comprises a verb, which indicates the action to
+    be taken, and argument(s), which supply the details. In some cases
+    the body of the article may also supply details. The following
+    sections contain syntactic definitions for the verb, arguments, and
+    possibly the body, for each type of control message.
+ 
+    The Newsgroups-header of each control message SHOULD include the
+    newsgroup-name(s) for the group(s) affected (i.e. groups to be
+    created, modified or removed, or containing articles to be canceled).
+    This is to ensure that the message propagates to all sites which
+    receive (or would receive) that group(s). It MAY include other
+    newsgroup-names so as to improve propagation (but this practice may
+    cause the control message to propagate also to places where it is
+    unwanted, or even cause it not to propagate where it should, so it
+    should not be used without good reason).
+ 
+         NOTE: Propagation is controlled by relaying agents, and it may
+         be necessary for relaying agents to take special steps to ensure
+         that control messages such as newgroup messages for not-yet-
+         existent newsgroups are propagated correctly (see 7.3).
+ [The first of those paragraphs was originally scheduled to be moved to
+ USEFOR (and it may yet be so moved). It has been reinstated here (at
+ least temporarily) to make sure that it does not get overlooked.]
+ 
+    The presence of a Subject-content starting with the string "cmsg "
+    and followed by a <control-message> was construed under [RFC 1036] as
+    a request to perform that control action (even if no genuine Control
+    header was present). Indeed, some implementations went further and
+    added the implied Control header before injecting. Likewise, the
+    presence of a newsgroup-name ending in ".ctl" in the Newsgroups
+    header caused the Subject header content (not starting with "cmsg" in
+    this case) to be interpreted as a <control-message>.
+ 
+    All these practices are now declared to be Obsolete, and Subject
+    headers MUST NOT now be interpreted as <control-message>s under any
+    circumstances.
+ 
     The descriptions below set out REQUIREMENTS to be followed by sites
     that receive control messages and choose to honour them. However,
***************
*** 736,751 ****
     basis).
  
-    Relaying Agents MUST propagate all control messages regardless of
-    whether or not they are recognized or processed locally.
- 
-    In the following sections, each type of control message is defined
-    syntactically by defining its verb, its arguments, and possibly its
-    body.
- 
  6.1.  Digital Signature of Headers
  
! [Removed to [USEFOR] (unless it remains in this document as the Primary
! document, in which case it would not be placed here.]
  
  6.2.  Group Control Messages
  
--- 834,855 ----
     basis).
  
  6.1.  Digital Signature of Headers
  
!    It is most desirable that group control messages (6.2) in particular
!    be authenticated by incorporating them within some digital signature
!    scheme that encompasses other headers closely associated with them
!    (including at least the Approved-, Message-ID- and Date-headers). At
!    the time of writing, this is usually done by means of a protocol
!    known as "PGPverify" ([PGPVERIFY]), and continued usage of this is
!    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 general purpose digital authentication mechanism with
+    applicability to all situations requiring protection against
+    malicious use of, or interference with, headers.  That extension
+    would also address other Netnews security issues.
+ 
  6.2.  Group Control Messages
  
***************
*** 1120,1129 ****
  
          NOTE: It is expected that the security extension envisaged in
!         section a-7.1 will make more detailed provisions for
!         establishing whether honouring a particular cancel message 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 sender, the moderator, or the
!         injector).
  
          NOTE: A cancel submitted by the poster for an article in a
--- 1221,1229 ----
  
          NOTE: It is expected that the security extension envisaged in
!         section 6.1 will make more detailed provisions for establishing
!         whether honouring a particular cancel message 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 sender, the moderator, or the injector).
  
          NOTE: A cancel submitted by the poster for an article in a
***************
*** 1368,1385 ****
        (e.g. more than 72 hours into the past).
  
!    4. It MUST reject any article that does not have the correct
!       mandatory headers for a proto-article (or, when reinjecting, all
!       the mandatory headers other than Injection-Date), or which
!       contains any header that does not have legal contents.  It SHOULD
!       reject any article which contains any header deprecated for
!       Netnews (a-4.2.1).  It SHOULD reject any article whose
!       Newsgroups-header does not contain at least one newsgroup-name for
!       an existing group (as listed by its associated serving agent) and
!       it MAY reject any newsgroup-name which, although syntactically
!       correct, violates a policy restriction established, for some
!       (sub-)hierarchy, by an agency with the appropriate authority
!       (1.2).  Observe that crossposting to unknown newsgroups is not
!       precluded provided at least one of those in the Newsgroups-header
!       is listed.
  
          NOTE: This ability to reject newsgroup-names in breach of
--- 1466,1482 ----
        (e.g. more than 72 hours into the past).
  
!    4. It MUST reject any article that does not have the proper mandatory
!       headers for a proto-article (or, when reinjecting, all the
!       mandatory headers other than Injection-Date), or which contains
!       any header that does not have legal contents.  It SHOULD reject
!       any article which contains any header deprecated for Netnews (a-
!       4.2.1).  It SHOULD reject any article whose Newsgroups-header does
!       not contain at least one newsgroup-name for an existing group (as
!       listed by its associated serving agent) and it MAY reject any
!       newsgroup-name which, although syntactically correct, violates a
!       policy restriction established, for some (sub-)hierarchy, by an
!       agency with the appropriate authority (1.2).  Observe that
!       crossposting to unknown newsgroups is not precluded provided at
!       least one of those in the Newsgroups-header is listed.
  
          NOTE: This ability to reject newsgroup-names in breach of
***************
*** 1514,1519 ****
     distribution "world", and NO relaying agent should supply or accept
     the distribution "local".
- [That SHOULD has been demoted from a MUST in draft-13. Any objections?]
  
          NOTE: Although it would seem redundant to filter out unwanted
          distributions at both ends of a relaying link (and it is clearly
--- 1610,1620 ----
     distribution "world", and NO relaying agent should supply or accept
     the distribution "local".
  
+    However, if the particular implementation does not relay non-existent
+    newsgroups, even when included in the Newsgroups-header and implied
+    (e.g. by some "wild card" notation) in the configuration tables, then
+    the agent MUST examine all group control messages (6.2) in order to
+    ensure that relaying of those messages proceeds normally.
+ 
          NOTE: Although it would seem redundant to filter out unwanted
          distributions at both ends of a relaying link (and it is clearly
***************
*** 1538,1547 ****
          distributions has been provided (7.7) for the same reason.
  
!    An article SHOULD NOT be relayed if the path-identity of the
!    receiving agent (or some known alias thereof) appears in its Path-
!    header, and the receiving agent MAY detect whether its own path-
!    identity is already present in the Path-content so as to avoid
!    further unnecessary relaying.
! [See related remarks under serving agents.]
  
     A relaying agent processes articles as follows:
--- 1639,1645 ----
          distributions has been provided (7.7) for the same reason.
  
!    In order to avoid unnecessary relaying, an article SHOULD NOT be
!    relayed if the path-identity of the receiving agent (or some known
!    alias thereof) appears in its Path-header.
  
     A relaying agent processes articles as follows:
***************
*** 1572,1583 ****
        less than that 24 hours).
  
!    3. It MUST reject any article that does not have the correct
!       mandatory headers (section a-5) present with legal contents.
  
!    4. It SHOULD reject any article whose optional headers (section a-6)
!       do not have legal contents.
! [Is that too strong? Are relaying agents really expected to check
! headers in that detail? I suggest s/SHOULD/MAY/. Even the MUST in Step 4
! for mandatory headers might be demoted to SHOULD.]
  
     5. It SHOULD reject any article that has already been sent to it (a
--- 1670,1678 ----
        less than that 24 hours).
  
!    3. It SHOULD reject any article that does not include all the
!       mandatory headers (section a-5).
  
!    4. It MAY reject any article whose headers do not have legal
!       contents.
  
     5. It SHOULD reject any article that has already been sent to it (a
***************
*** 1585,1588 ****
--- 1680,1696 ----
        and matched against).
  
+         NOTE: Even though commonly derived from the domain name of the
+         originating site (and domain names are case-insensitive), a
+         message identifier MUST NOT be altered in any way during
+         transport, or when copied (as into a References-header), and
+         thus a simple (case-sensitive) comparison of octets will always
+         suffice to recognize that same message identifier wherever it
+         subsequently reappears.
+ 
+         NOTE: These requirements are to 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. It SHOULD reject any article that matches an already received
        cancel message (or an equivalent Supersedes-header) issued by its
***************
*** 1610,1614 ****
  
     Relaying agents MUST NOT alter, delete or rearrange any part of an
!    article expect for headers designated as variant (a-4.2.5.3).  In
     particular
  
--- 1716,1720 ----
  
     Relaying agents MUST NOT alter, delete or rearrange any part of an
!    article expect for headers designated as variant (2.3.2).  In
     particular
  
***************
*** 1689,1702 ****
          hierarchy under "control." (e.g. "control.cancel").
  
!    A serving agent MAY decline to accept an article if its own path-
!    identity is already present in the Path-content or if the Path-
!    content contains some path-identity whose articles the serving agent
!    does not want, as a matter of local policy.
! [That has been changed from a-5.6.1 in previous drafts, where it said "A
! relaying agent MAY decline...". That seemed plain wrong to me. It is
! fine for a relaying agent to ignore articles which have apparently
! already passed through it (and I still say that), but surely it is for
! serving agents to "reject" for policy reasons, and to which the NOTE
! below would apply.  Comments?]
  
          NOTE: This last facility is sometimes used to detect and decline
--- 1795,1801 ----
          hierarchy under "control." (e.g. "control.cancel").
  
!    A serving agent MAY decline to accept an article if the Path-content
!    contains some path-identity whose articles the serving agent does not
!    want, as a matter of local policy.
  
          NOTE: This last facility is sometimes used to detect and decline
***************
*** 1704,1710 ****
          deliberately seeded with a path-identity to be "aliased out" by
          sites not wishing to act upon them.
! [Again, is this "aliasing out" usually detected by the serving agent, or
! does it more usually work because the previous relaying agent will never
! have sent it in the first place?]
  
     A serving agent processes articles as follows:
--- 1803,1808 ----
          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 to
! mention it here.]
  
     A serving agent processes articles as follows:
***************
*** 1719,1725 ****
        less than that 24 hours).
  
!    3. It MUST reject any article that does not have the correct
!       mandatory headers (section a-5) present, or which contains any
!       header that does not have legal contents.
  
     4. It SHOULD reject any article that has already been sent to it (a
--- 1817,1823 ----
        less than that 24 hours).
  
!    3. It MUST reject any article that does not include all the mandatory
!       headers (section a-5), or which contains any header that does not
!       have legal contents.
  
     4. It SHOULD reject any article that has already been sent to it (a
***************
*** 1757,1768 ****
     or Complaints-To-header.
  
     Posting agents meant for use by ordinary posters SHOULD reject any
     attempt to post an article which cancels or Supersedes another
!    article of which the poster is not the author.
  
  7.6.  Duties of a Followup Agent
  
--- 1856,1868 ----
     or Complaints-To-header.
  
+    Contrary to [RFC 2822], which states that the mailbox(es) in the From
+    header is that of the poster(s), a poster who does not, for whatever
+    reason, wish to use his own mailbox MAY 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 post an article which cancels or Supersedes another
!    article of which the poster is not the author or sender.
  
  7.6.  Duties of a Followup Agent
  
***************
*** 1770,1779 ****
     bound by all the posting agent's requirements. Followup agents MUST
     create valid followups and are subject to special requirements
!    involving certain inheritable (a-4.2.5.2) and other headers.
!    Wherever in the following it is stated that, "by default", a header
!    is to be taken from some header in the precursor, it means that its
!    initial content (plus its extension-parameters, if any) are to be
!    copied from those of that precursor header.  However, posters MAY
!    then override that default before posting if they so wish.
  
          NOTE: There is no provision in this standard for a followup to
--- 1870,1879 ----
     bound by all the posting agent's requirements. Followup agents MUST
     create valid followups and are subject to special requirements
!    involving certain inheritable (2.3.1) and other headers. Wherever in
!    the following it is stated that, "by default", a header is to be
!    taken from some header in the precursor, it means that its initial
!    content is to be copied from the content of that precursor header.
!    However, posters MAY then override that default before posting if
!    they so wish.
  
          NOTE: There is no provision in this standard for a followup to
***************
*** 1796,1805 ****
  
     4. If the precursor did not have a References-header (a-6.10), the
!       followup's References-content MUST be formed by the message
!       identifier of the precursor. A followup to an article which had a
!       References-header MUST have a References-header containing the
!       precursor's References-content (subject to trimming as described
!       below) plus the precursor's message identifier appended to the end
!       of the list (separated from it by CFWS).
  
        Followup agents MAY trim References-headers which have grown to
--- 1896,1905 ----
  
     4. If the precursor did not have a References-header (a-6.10), the
!       followup's References-content MUST be taken from the Message-ID-
!       content of the precursor. A followup to an article which already
!       had a References-header MUST have a References-header comprising
!       the precursor's References-content (subject to trimming as
!       described below) followed by CFWS and the Message-ID-content of
!       the precursor.
  
        Followup agents MAY trim References-headers which have grown to
***************
*** 1825,1829 ****
        a copy-addr
              The followup agent SHOULD likewise email a copy of a posted
!             followup, which MUST then be sent to the copy-addr.
  
        When emailing a copy, the followup agent SHOULD also include a
--- 1925,1929 ----
        a copy-addr
              The followup agent SHOULD likewise email a copy of a posted
!             followup, which SHOULD then be sent to the copy-addr.
  
        When emailing a copy, the followup agent SHOULD also include a
***************
*** 1837,1846 ****
     A reading agent downloads articles from a serving agent, as directed
     by the reader, and displays them (or processes them in some other
!    manner).  The article as displayed MUST be identical to the article
!    as originally posted, subject only to limitations of the display
!    device (such as availability of charsets, etc.). It MUST provide
!    facilities for decoding any Content-Transfer-Encodings, encoded-
!    words, etc., but SHOULD also have the capability to show the article
!    exactly as received.
  
     It MAY present lists of articles available for display, and MAY
--- 1937,1944 ----
     A reading agent downloads articles from a serving agent, as directed
     by the reader, and displays them (or processes them in some other
!    manner), subject to any limitations of the reading agent, such as
!    availability of charsets, and having first decoded any Content-
!    Transfer-Encodings, encoded-words, etc.  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
***************
*** 1847,1855 ****
     structure those lists so as to show the relationships between the
     articles, as determined by the References-, Subject-, Date- and
!    other-headers (see [USEAGE] for some usual methods of doing this). It
!    MAY also be configured so that unwanted distributions (a-6.6) are
!    ignored.
  
- 
  7.8.  Duties of a Moderator
  
--- 1945,1951 ----
     structure those lists so as to show the relationships between the
     articles, as determined by the References-, Subject-, Date- and
!    other-headers (see [USEAGE] for some usual methods of doing this).
! [This whole section may yet get omitted]
  
  7.8.  Duties of a Moderator
  
***************
*** 1934,1939 ****
          any case, be caught by the injecting agent if it is not).
  
!    5. Any variant headers (a-4.2.5.3) MUST be removed, except that a
!       Path-header MAY be truncated to only its pre-injection region (a-
        5.6.3).  Any Injection-Info-header (a-6.19) or Complaints-To-
        header (a-6.20) SHOULD be removed (and if they are not, the
--- 2030,2035 ----
          any case, be caught by the injecting agent if it is not).
  
!    5. Any variant headers (2.3.2) MUST be removed, except that a Path-
!       header MAY be truncated to only its pre-injection region (a-
        5.6.3).  Any Injection-Info-header (a-6.19) or Complaints-To-
        header (a-6.20) SHOULD be removed (and if they are not, the
***************
*** 2265,2269 ****
     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 a-5.2).
  
     A malicious poster may also prevent his article being seen at a
--- 2357,2361 ----
     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).
  
     A malicious poster may also prevent his article being seen at a
***************
*** 2421,2424 ****
--- 2512,2518 ----
          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.
***************
*** 2672,2673 ****
--- 2766,2814 ----
  
     5    Some renumbering of sections and minor textual clarifications.
+ 
+    For version 02
+ 
+    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].]
+ 
+    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 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 (formerly in a-5.2).
+         7.5
+ 
+    8    "Inheritable" and "Variant" headers 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

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5