draft-ietf-usefor-usepro-05

["Charles Lindsey" <[e-mail]>]

See www.imc.org/ietf/usefor/drafts/draft-ietf-usefor-usepro-05.txt
and www.imc.org/ietf/usefor/drafts/draft-ietf-usefor-usepro-05.unpaged
and also on its way to the drafts editor.

The main changes are the rmeoval of all texts that were duplicated in
USEFOR, with other consequential changes to bring into line with
USEFOR-06. Also removed the historical appendices and replaced with
wording referring to Henry's about-to-be-published Son-of-1036. Also
assorted niggles and boilerplate fixes. No changes to the protocols
(though there will be work to be done when #1047 is resolved).

For those who want to check, here are the full diffs.

*** draft-ietf-usefor-usepro-04.unpaged	Fri Jul 15 18:20:42 2005
--- draft-ietf-usefor-usepro-05.unpaged	Thu Jan  5 22:44:15 2006
***************
*** 3,5 ****
  Usenet Format Working Group                  University of Manchester
!                                              July 2005
  
--- 3,5 ----
  Usenet Format Working Group                  University of Manchester
!                                              January 2006
  
***************
*** 6,8 ****
                  News Article Architecture and Protocols
!                    <draft-ietf-usefor-usepro-04.txt>
  
--- 6,8 ----
                  News Article Architecture and Protocols
!                    <draft-ietf-usefor-usepro-05.txt>
  
***************
*** 31,33 ****
  
!    This Internet-Draft will expire in January 2006.
  
--- 31,33 ----
  
!    This Internet-Draft will expire in July 2006.
  
***************
*** 43,48 ****
  
-    Since the 1980s, Usenet has grown explosively, and many Internet and
-    non-Internet sites now participate. In addition, the Netnews
-    technology is now in widespread use for other purposes.
- 
     Backward compatibility has been a major goal of this endeavour, but
--- 43,44 ----
***************
*** 52,54 ****
  
!    A companion Current Best Practice document [USEAGE], addressing
     requirements which are present for Social rather than Normative
--- 48,50 ----
  
!    A companion Best Current Practice document [USEAGE], addressing
     requirements which are present for Social rather than Normative
***************
*** 81,83 ****
    2.2.  Defining the Architecture .................................    0
!   2.3.  Identification of news-servers ............................    0
    2.4.  Variant Header Fields .....................................    0
--- 78,80 ----
    2.2.  Defining the Architecture .................................    0
!   2.3.  Identification of news servers ............................    0
    2.4.  Variant Header Fields .....................................    0
***************
*** 85,87 ****
  3.  Changes to the existing protocols .............................    0
!   3.1.  Principal Changes .........................................    0
    3.2.  Transitional Arrangements .................................    0
--- 82,84 ----
  3.  Changes to the existing protocols .............................    0
!   3.1.  Protocol Changes ..........................................    0
    3.2.  Transitional Arrangements .................................    0
***************
*** 138,142 ****
  12.  Contact Address ..............................................    0
! Appendix A.1 - A-News Article Format ..............................    0
! Appendix A.2 - Early B-News Article Format ........................    0
! Appendix A.3 - Obsolete Control Messages ..........................    0
  Appendix B - Notices ..............................................    0
--- 135,137 ----
  12.  Contact Address ..............................................    0
! Appendix A - Obsolete Control Messages ............................    0
  Appendix B - Notices ..............................................    0
***************
*** 145,159 ****
  
- [This draft [USEPRO] and its partner [USEFOR] are an interim stage in
- the splitting into two parts of the earlier draft [ARTICLE].  There is a
- certain amount of material - basic concepts, definitions, etc - which
- ultimately need occur in only one of the documents, and further such
- material which may not be needed at all (e.g. terms currently defined
- which in the event may not get used). For the moment, all such material
- has been retained in the present draft (it being, in any case, easier to
- take unwanted stuff out than to put new stuff in). It has also to be
- decided, for such material which is needed by both documents, which one
- (the "Primary") should contain it and which one should incorporate it by
- reference (essentially, this draft is written so that it could be the
- Primary).]
- 
  1.  Introduction
--- 140,141 ----
***************
*** 173,181 ****
  
-    An important characteristic of Netnews is the lack of any requirement
-    for a central administration or for the establishment of any
-    controlling host to manage the network. 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".
- 
     "Usenet" is a particular worldwide publicly accessible network based
--- 155,156 ----
***************
*** 186,187 ****
--- 161,168 ----
  
+    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
***************
*** 194,195 ****
--- 175,177 ----
     their recipients.
+ [Could omit that last sentence.]
  
***************
*** 203,207 ****
     between the various agents comprising that architecture. In this
!    standard, references to sections in the companion [USEFOR] are
!    prefixed with "F-".
  
     It is NOT the purpose of this standard to settle matters of policy,
--- 185,194 ----
     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.]
+ 
     It is NOT the purpose of this standard to settle matters of policy,
***************
*** 226,246 ****
  
!    The earliest news interchange used the so-called "A News" article
!    format.  Shortly thereafter, an article format vaguely resembling
!    Internet Mail was devised and used briefly.  Both of those formats
!    are completely obsolete; they are documented in Appendix A.1 and
!    Appendix A.2 for historical reasons only.  With publication of [RFC
!    850] in 1983, news articles came to closely resemble Internet Mail
!    messages, with some restrictions and some additional header fields.
!    [RFC 1036] in 1987 updated [RFC 850] without making major changes.
  
!    A Draft popularly referred to as "Son of 1036" [Son-of-1036] was
!    written in 1994 by Henry Spencer.  Much is taken directly from Son of
!    1036, and it is hoped that we have followed its spirit and
!    intentions.
  
- [It is anticipated that [Son-of-1036] will shortly be published as an
- informational RFC (for purposes of historical documentation only), in
- which case most historical information can be removed from this draft,
- including the whole of Appendix A.1 and Appendix A.2.]
- 
  2.  Definitions, Notations and Conventions
--- 213,225 ----
  
!    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.
  
  2.  Definitions, Notations and Conventions
***************
*** 249,305 ****
  
!    An "article" is the unit of news, synonymous with an [RFC 2822]
!    "message".  A "proto-article" is one that has not yet been injected
!    into the news system.  In constrast to an article, a proto- article
!    may lack some mandatory header fields
  
-    A "message identifier" (F-3.1.3) is a unique identifier for an
-    article, usually supplied by the posting agent which posted it or,
-    failing that, by the injecting agent. It distinguishes the article
-    from every other article ever posted anywhere. Articles with the same
-    message identifier are treated as if they are the same article
-    regardless of any differences in the body or header fields.
- 
-    A "newsgroup" is a single news forum, a logical bulletin board,
-    having a name and nominally intended for articles on a specific
-    topic. An article is "posted to" a single newsgroup or several
-    newsgroups. When an article is posted to more than one newsgroup, it
-    is said to be "crossposted"; note that this differs from posting the
-    same text as part of each of several articles, one per newsgroup.
- 
-    A newsgroup may be "moderated", in which case submissions are not
-    posted directly, but mailed to a "moderator" for consideration and
-    possible posting.  Moderators are typically human but may be
-    implemented partially or entirely in software.
- 
     A "hierarchy" is the set of all newsgroups whose names share a first
!    component (as defined in F-3.1.5).  The term "sub-hierarchy" is also
!    used where several initial components are shared.
  
-    A "poster" is the person or software that composes and submits a
-    possibly compliant article for submission to a posting agent. The
-    poster is analogous to [RFC 2822]'s author.
- 
-    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, its "precursor". Every followup includes a
-    References header field identifying that precursor (but note that
-    non-followup articles may also use a References header field).
- 
-    An (email) "address" is the mailbox [RFC 2822] (or more particularly
-    the addr-spec within that mailbox) which directs the delivery of an
-    email to its intended recipient, who is said to "own" that address.
- 
-    A "sender" is the person or software (usually, but not always, the
-    same as the poster) responsible for the operation of the posting
-    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.
- 
     The "semantic content" (often abbreviated to just "content" when the
--- 228,237 ----
  
!    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).  The term "sub-hierarchy" is
!    also used where several initial components are shared.
  
     The "semantic content" (often abbreviated to just "content" when the
***************
*** 314,316 ****
  
!    A Netnews system is a distributed database composed of "agents" of
     various types which, acting together according to the protocols
--- 246,248 ----
  
!    A Netnews system is a distributed database composed of agents of
     various types which, acting together according to the protocols
***************
*** 320,323 ****
     wherever stored, are identical apart from those header fields defined
!    as variant (2.4).
  
     A "posting agent" is the software that assists posters to prepare
--- 252,257 ----
     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:
  
     A "posting agent" is the software that assists posters to prepare
***************
*** 346,347 ****
--- 280,283 ----
     agents to access the news database.
+ [There is a suggestion that "serving agent" should be changed to
+ "storage agent" throughout.]
  
***************
*** 361,405 ****
     Posting, reading and followup agents (which are usually just
!    different services provided by the same piece of software) are known
!    collectively as "user agents".
  
!    Injecting, relaying and serving agents (which are often just
!    different services provided by the same piece of software) are known
!    collectively as "news-servers".
  
! 2.3.  Identification of news-servers
  
!    News-servers need to identify themselves by inserting their public
!    name, in the form of a <path-identity> (F-3.1.6), into Path,
!    Injection-Info and Xref header fields. An injecting agent MUST
!    identify itself with the same <path-identity> in both Path and
!    Injection-Info header fields, and a serving agent SHOULD use the same
!    <path-identity> in both Path and Xref header fields.
  
!    The following possibilities are available when choosing a <path-
!    identity>, but some of them are less suited to providing a unique
!    identity for the news-server concerned and are NOT RECOMMENDED, as
!    shown:
  
!    1. A fully qualified domain name (FQDN) associated with an "A" or
!       "AAAA" record (or an equivalent "CNAME"), which SHOULD identify
!       the actual host inserting this <path-identity> and, ideally,
!       should also be "mailable" (see below).
  
!    2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
!       3986] - which SHOULD be a publicly recognized address [RFC 1918]
!       for the actual host, as above. This option SHOULD NOT be used if
!       an FQDN for that host is available.
  
!    3. A fully qualified domain name (FQDN) associated with an "MX"
!       record, which MUST be "mailable".
  
!    4. Some other (arbitrary) name believed to be unique and registered
        at least with all other news-servers sending articles directly to
!       the given one. The news-server administrator is responsible for
!       choosing an appropriate name (and will bear the consequences of an
!       inappropriate choice). This option SHOULD NOT be used unless the
!       earlier options are unavailable (e.g. because the host in question
!       is not connected to the Internet), or unless it is of longstanding
!       usage and cessation would be unduly disruptive.
  
          NOTE: The syntax permits the colon character (which, prior to
--- 297,373 ----
     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.
  
!    Likewise, injecting, relaying and serving 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 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), which can appear in Path, Injection-Info and Xref header
!    fields. Whatever <path-identity> is used in the Path header field
!    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 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.
! 
!    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 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.
  
+    According to [RFC 2142]], the forms "usenet@server" and "news@server"
+    are common addresses for a news server administrator.
+ [end of alternatives]
+ 
+         NOTE: A news server administrator who chooses a name which turns
+         out not to be unique will have to bear the consequences.
+ 
          NOTE: The syntax permits the colon character (which, prior to
***************
*** 407,409 ****
          identity> which is in the form of an <IPv6address>.  It would
!         therefor be unwise to choose, as such a name, anything composed
          solely from four (or less) hexadecimal digits.
--- 375,377 ----
          identity> which is in the form of an <IPv6address>.  It would
!         therefore be unwise to choose, as such a name, anything composed
          solely from four (or less) hexadecimal digits.
***************
*** 410,422 ****
  
-    The FQDN of a news-server is "mailable" if its administrators can be
-    reached by email using both of the forms "usenet@" that FQDN and
-    "news@" that FQDN, in conformity with [RFC 2142].
- 
-    For an injecting agent prepending to a Path header field (7.2.2), the
-    <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
-    and if the agent offers its services to the general public the form
-    "abuse@" that FQDN MUST also be available, unless a more specific
-    complaints address has been provided in a <complainto-param> of an
-    Injection-Info header field (F-3.2.14).
- 
  2.4.  Variant Header Fields
--- 378,379 ----
***************
*** 471,476 ****
  
-         NOTE: The use of "MUST" or "SHOULD" implies a requirement that
-         would or could lead to interoperability problems if not
-         followed.
- 
          NOTE: A requirement imposed on a relaying or serving agent
--- 426,427 ----
***************
*** 498,519 ****
     1036].  It is the intention that they can be assimilated into Usenet
!    as it presently operates without major interruption to the service,
!    though some of the new features may not begin to show benefit until
!    they become widely implemented. This section summarizes the main
!    changes, and comments on some features of the transition.
  
! 3.1.  Principal Changes
  
-      o The [RFC 2822] conventions for parenthesis-enclosed <comment>s in
-        header fields are supported in all newly defined header fields
-        and in header fields inherited from [RFC 2822].  They are,
-        however, still disallowed for performance and/or compatibility
-        reasons in the Message-ID, Newsgroups, Path, Followup-To,
-        Control, Supersedes, Distribution, Xref and Lines header fields.
-      o Whitespace is permitted in Newsgroups header fields, permitting
-        folding of such header fields. Indeed, all header fields can now
-        be folded.
-      o An enhanced syntax for the Path header field enables the
-        injection point of and the route taken by an article to be
-        determined with certainty.
-      o MIME is recognized as an integral part of Netnews.
       o There is a new Control message 'mvgroup' to facilitate moving a
--- 449,458 ----
     1036].  It is the intention that they can be assimilated into Usenet
!    as it presently operates without major interruption to the service
!    (3.2), though some of the new features may not begin to show benefit
!    until they become widely implemented.  Changes in the syntax and
!    format are documented in F-Appendix B and changes to control messages
!    and the protocols are documented below.
  
! 3.1.  Protocol Changes
  
       o There is a new Control message 'mvgroup' to facilitate moving a
***************
*** 520,528 ****
         group to a different place (name) in a hierarchy.
!      o There is a new mandatory Injection-Date header field to
!        facilitate the rejection of stale articles.
!      o There are new optional header fields defined, Archive,
!        Injection-Info and User-Agent, leading to increased
!        functionality.
!      o Certain header fields and Control messages (F-3.3 and Appendix
!        A.3) have been made obsolete.
       o Distributions are expected to be checked at the receiving end, as
--- 459,465 ----
         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 6).
!      o Additional media types are defined for better structuring of
!        control messages (5.3 and 5.4).
       o Distributions are expected to be checked at the receiving end, as
***************
*** 534,549 ****
  
!    An important distinction must be made between serving and relaying
!    agents, which are responsible for the distribution and storage of
!    news articles, and user agents, which are responsible for
!    interactions with users. It is important that the former should be
!    upgraded to conform to this standard as soon as possible to provide
!    the benefit of the enhanced facilities.  Fortunately, the number of
!    distinct implementations of such agents is rather small, at least so
!    far as the main "backbone" of Usenet is concerned, and many of the
!    new features are already supported. Contrariwise, there are a great
!    number of implementations of user agents, installed on a vastly
!    greater number of small sites. Therefore, the new functionality has
!    been designed so that existing user agents may continue to be used,
!    although the full benefits may not be realised until a substantial
!    proportion of them have been upgraded.
  
--- 471,486 ----
  
!    An important distinction must be made between news servers, which are
!    responsible for the distribution and storage of news articles, and
!    user agents, which are responsible for interactions with users. It is
!    important that the former should be upgraded to conform to this
!    standard as soon as possible to provide the benefit of the enhanced
!    facilities.  Fortunately, the number of distinct implementations of
!    such servers is rather small, at least so far as the main "backbone"
!    of Usenet is concerned, and many of the new features are already
!    supported. Contrariwise, there are a great number of implementations
!    of user agents, installed on a vastly greater number of small sites.
!    Therefore, the new functionality has been designed so that existing
!    user agents may continue to be used, although the full benefits may
!    not be realised until a substantial proportion of them have been
!    upgraded.
  
***************
*** 554,566 ****
  
!      o [RFC 2822] style <comment>s in header fields do not affect
!        serving and relaying agents.  They are unlikely to hinder their
!        proper display in existing reading agents except in the case of
!        the References header field in agents which thread articles.
!        Therefore, it is provided that they SHOULD NOT be generated in
!        that case.
!      o Because of its importance to all serving agents, the newly
!        permitted whitespace and folding in Newsgroups header fields
!        SHOULD NOT be generated (though it MUST be accepted); this
!        restriction may well be removed in a future version of this
         standard.
       o The new style of Path header field, using "!!" as a <path-
--- 491,505 ----
  
!      o [RFC 2822] style <comment>s 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 the case of the References header field in
!        agents which thread articles. [USEFOR] therefore provides that
!        they SHOULD NOT be generated in that case.
!      o Because of its importance to all serving agents, the whitespace
!        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 in a future version of this
         standard.
+ [That last bit needs discussion. It should probably be moved to USEFOR
+ if it is to be retained.]
       o The new style of Path header field, using "!!" as a <path-
***************
*** 571,581 ****
         agents are unaffected.
!      o The introduction of MIME reflects a practice that is already
!        widespread.  Articles in strict compliance with 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, in general, that any single user
!        agent will be able to display every charset known to IANA, but
!        all such agents MUST support US-ASCII. Serving and relaying
         agents are not affected.
--- 510,520 ----
         agents are unaffected.
!      o The introduction by [USEFOR] of MIME reflects a practice that is
!        already widespread.  Articles in strict compliance with 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, in general, that any single
!        user agent will be able to display every charset known to IANA,
!        but all such agents MUST support US-ASCII. Serving and relaying
         agents are not affected.
***************
*** 592,596 ****
         agents which do not yet provide an Injection-Date header field.
!      o All the header fields newly introduced by this standard can
!        safely be ignored by existing software, albeit with loss of the
!        new functionality.
  
--- 531,535 ----
         agents which do not yet provide an Injection-Date header field.
!      o All the header fields newly introduced by [USEFOR] can safely be
!        ignored by existing software, albeit with loss of the new
!        functionality.
  
***************
*** 1296,1298 ****
     line. [RFC 1036] also permitted the list of <msg-id>s to appear in
!    the Ihave- or Sendme-argument with the syntax
        Ihave-argument      = [FWS] *( msg-id FWS ) [relayer-name]
--- 1239,1243 ----
     line. [RFC 1036] also permitted the list of <msg-id>s to appear in
!    the <Ihave-> or <Sendme-argument> with the syntax
! 
! 
        Ihave-argument      = [FWS] *( msg-id FWS ) [relayer-name]
***************
*** 1355,1357 ****
  
!    The following control messages (as described in Appendix A.3) are
     declared obsolete by this standard:
--- 1302,1304 ----
  
!    The following control messages (as described in Appendix A) are
     declared obsolete by this standard:
***************
*** 1414,1417 ****
     is also expected to bear some responsibility towards the rest of the
!    network for the behaviour of its posters (and provision is therefore
!    made for it to be easily contactable by email).
  
--- 1361,1363 ----
     is also expected to bear some responsibility towards the rest of the
!    network for the behaviour of its posters.
  
***************
*** 1436,1439 ****
     of the network in these special cases, this standard does set out the
!    correct way to reinject (see special provisions in 7.2.2 Steps 3, 4,
!    7 and 9).
  
--- 1382,1385 ----
     of the network in these special cases, this standard does set out the
!    correct way to reinject (see special provisions in 7.2.2 Steps 3, 7
!    and 9).
  
***************
*** 1501,1504 ****
     4. It MUST reject any article that does not have the proper mandatory
!       header fields for a proto-article (except, when reinjecting, for
!       the Injection-Date header field), or which contains any header
        field that does not have legal contents.  It SHOULD reject any
--- 1448,1450 ----
     4. It MUST reject any article that does not have 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
***************
*** 1531,1532 ****
--- 1479,1482 ----
        "INN/1.7.2") used by the injecting agent.
+ [That last sentence may need to be reconsidered (in which case see
+ consequential change in 7.3).]
  
***************
*** 1558,1561 ****
        this header field SHOULD then be folded if it would otherwise
!       result in a header line of excessive length.  The prepended
!       <path-identity> MUST be an FQDN mailable address (2.3).
  
--- 1506,1510 ----
        this header field SHOULD then be folded if it would otherwise
!       result in a header line of excessive length.
! [This may need further changes depending on the resolution of ticket
! #1047.]
  
***************
*** 1698,1699 ****
--- 1647,1651 ----
        length.
+ [This may need further changes depending on the resolution of ticket
+ #1047.]
  [It has been suggested that relaying agents should be permitted to
***************
*** 1700,1701 ****
--- 1652,1658 ----
  prepend more than the one or two entries permitted above.]
+ [something like the following from Diablo might also be useful:
+ >>> NOTE <<< you should grep through newly created spool directories
+ every so often looking for .MISMATCH in the spool files to locate
+ incoming feeds with improperly configured I found that four of my 80+
+ feeds were misconfigured. ]
  
***************
*** 2350,2351 ****
--- 2309,2314 ----
  
+    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.  Leakage
***************
*** 2497,2503 ****
     parts of the same article.
- [Frank wants
- MIME security considerations are discussed in [RFC2046].  Note that
- applying some [RFC2231] extensions for parameters like multi-line
- paramters on a boundary parameter as defined in [RFC2046] might be
- abused to bypass simple algorithms trying to analyze MIME parts.]
  
--- 2465,2466 ----
***************
*** 2556,2558 ****
          Coded Character Sets - 7-Bit American National Standard Code for
!         1996.
  
--- 2523,2525 ----
          Coded Character Sets - 7-Bit American National Standard Code for
!         Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
  
***************
*** 2563,2565 ****
     [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
!         Disposition Notifications", RFC 2298, March 1998.
  
--- 2530,2532 ----
     [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
!         Requirement Levels", RFC 2119, March 1997.
  
***************
*** 2566,2568 ****
     [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
!         HTTP/1.1", RFC 2616, June 1999.
  
--- 2533,2535 ----
     [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
!         RFC 2606, June 1999.
  
***************
*** 2572,2574 ****
     [RFC 3864] G. Klyne, M. Nottingham, and J. Mogul, "Registration
!         <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.
  
--- 2539,2541 ----
     [RFC 3864] G. Klyne, M. Nottingham, and J. Mogul, "Registration
!         procedures for message header fields", RFC 3864.
  
***************
*** 2583,2589 ****
  10.2.  Informative References
-         Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
  
-    [ARTICLE] Charles H. Lindsey, "News Article Format and Transmission",
-         draft-ietf-usefor-article-format-*.txt.
- 
     [NNTP] Clive D.W. Feather, "Network News Transport Protocol", draft-
--- 2550,2552 ----
***************
*** 2597,2602 ****
  
-    [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot,
-         and E. Lear, "Address Allocation for Private Internets", RFC
-         1918, February 1996.
- 
     [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
--- 2560,2561 ----
***************
*** 2607,2609 ****
          Extensions (MIME) Part Two: Media Types", RFC 2046, November
!         Requirement Levels", RFC 2119, March 1997.
  
--- 2566,2568 ----
          Extensions (MIME) Part Two: Media Types", RFC 2046, November
!         1996.
  
***************
*** 2613,2615 ****
     [RFC 2298] R. Fajman, "An Extensible Message Format for Message
!         RFC 2606, June 1999.
  
--- 2572,2574 ----
     [RFC 2298] R. Fajman, "An Extensible Message Format for Message
!         Disposition Notifications", RFC 2298, March 1998.
  
***************
*** 2617,2627 ****
          P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol --
!         procedures for message header fields", RFC 3864.
  
!    [RFC 3986] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform
!         Resource Identifier (URI): Generic Syntax", STD 66, January
!         2005.
  
-    [RFC 850] Mark R. Horton, "Standard for interchange of Usenet
-         messages", RFC 850, June 1983.
- 
     [RFC 976] Mark R. Horton, "UUCP mail interchange format standard",
--- 2576,2582 ----
          P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol --
!         HTTP/1.1", RFC 2616, June 1999.
  
!    [RFC 2821] John C. Klensin and Dawn P. Mann, "Simple Mail Transfer
!         Protocol", RFC 2821, April 2001.
  
     [RFC 976] Mark R. Horton, "UUCP mail interchange format standard",
***************
*** 2630,2631 ****
--- 2585,2587 ----
     [Son-of-1036] Henry Spencer, "News article format and transmission",
+         <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.
  
***************
*** 2633,2640 ****
  
!    TBD
  
  12.  Contact Address
--- 2589,2596 ----
  
!    As this document is the result of an eight 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.
  
  12.  Contact Address
***************
*** 2650,2652 ****
          Phone: [phone]
!         Email: [e-mail]
  
--- 2606,2608 ----
          Phone: [phone]
!         Email: [e-mail]
  
***************
*** 2665,2727 ****
  
! Appendix A.1 - A-News Article Format
  
-    The obsolete "A News" article format consisted of exactly five lines
-    of header field information, followed by the body. For example:
- 
-       Aeagle.642
-       news.misc
-       cbosgd!mhuxj!mhuxt!eagle!jerry
-       Fri Nov 19 16:14:55 1982
-       Usenet Etiquette - Please Read
-       body
-       body
-       body
- 
-    The first line consisted of an "A" followed by an article ID
-    (analogous to a message identifier and used for similar purposes).
-    The second line was the list of newsgroups. The third line was the
-    path. The fourth was the date, in the format above (all fields fixed
-    width), resembling an Internet date but not quite the same. The fifth
-    was the subject.
- 
-    This format is documented for archaeological purposes only.  Articles
-    MUST NOT be generated in this format.
- 
- Appendix A.2 - Early B-News Article Format
- 
-    The obsolete pseudo-Internet article format, used briefly during the
-    transition between the A News format and the modern format, followed
-    the general outline of a MAIL message but with some non-standard
-    header fields. For example:
- 
-       From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
-       Newsgroups: news.misc
-       Title: Usenet Etiquette -- Please Read
-       Article-I.D.: eagle.642
-       Posted: Fri Nov 19 16:14:55 1982
-       Received: Fri Nov 19 16:59:30 1982
-       Expires: Mon Jan 1 00:00:00 1990
- 
-       body
-       body
-       body
- 
-    The From header field contained the information now found in the Path
-    header field, plus possibly the full name now typically found in the
-    From header field. The Title header field contained what is now the
-    content of the Subject header field. The Posted header field
-    contained what is now the content of the Date header field. The
-    Article-I.D. header field contained an article ID, analogous to a
-    message identifier and used for similar purposes. The Newsgroups and
-    Expires header fields were approximately as now. The Received header
-    field contained the date when the latest relaying agent to process
-    the article first saw it. All dates were in the above format, with
-    all fields fixed width, resembling an Internet date but not quite the
-    same.
- 
-    This format is documented for archaeological purposes only.  Articles
-    MUST NOT be generated in this format.
- 
- Appendix A.3 - Obsolete Control Messages
- 
     This present standard obsoletes certain control messages defined in
--- 2621,2624 ----
  
! Appendix A - Obsolete Control Messages
  
     This present standard obsoletes certain control messages defined in
***************
*** 2787,2789 ****
  
!    Copyright (C) The Internet Society (2005).  This document is subject
     to the rights, licenses and restrictions contained in BCP 78, and
--- 2684,2686 ----
  
!    Copyright (C) The Internet Society (2006).  This document is subject
     to the rights, licenses and restrictions contained in BCP 78, and
***************
*** 2941 ****
--- 2839,2856 ----
          6.2
+ 
+    For version 05
+ 
+    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.


-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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