Subject: Commit in docs/usefor (usepro.xml)

From: [email-masked]
Date: Mon, 25 May 2009 16:52:25 -0700 (PDT)

Date: Monday, May 25, 2009 @ 16:52:24
  Author: eagle
Revision: 5921

The results of my editing pass following the RFC Editor editing pass.
Restore the correct link for the pgpverify format (not the README for
the software package).  Add some minor tweaks and clarifications.  Add
RFC 1036 as a specification for application/news-transmission and allow
our superseding status to disambiguate.  Minimally wrap long lines so
that the XML is still readable.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-25 23:49:56 UTC (rev 5920)
+++ docs/usefor/usepro.xml	2009-05-25 23:52:24 UTC (rev 5921)
@@ -173,19 +173,6 @@
       mailbox             = <see [RFC5322] Section 3.4>
       utext               = <see [RFC2822] Section 3.2.6>
 ]]></artwork>
-
-<!--[rfced] Since RFC 5322 obsoleted RFC 2822, we have updated this
-   document accordingly. 
-
-   However, if RFC 2822 should be referred to throughout the document,
-   then please add a sentence to mention the existence of RFC 5322 and
-   explain to the reader why it is not being used in this document.
-
-   Regarding "utext": It does not appear in RFC 5322, so this has not 
-   been changed.  Please let us know how this particular reference 
-   should be updated.  We note that RFC 5335 extends the 2822 "utext".
--->
-
         </figure>
       </section>
 
@@ -234,7 +221,8 @@
       <t>The exact means used to transmit articles from one agent to
       another is not specified.  NNTP <xref target="RFC3977" /> is the
       most common transport mechanism for Netnews networks.  Other
-      methods in use include the Unix-to-Unix Copy Protocol (UUCP) <xref target="RFC0976" />
+      methods in use include the Unix-to-Unix Copy Protocol (UUCP)
+      <xref target="RFC0976" />
       (extensively used in the early days of Usenet) and physically
       delivered magnetic and optical media.  Any mechanism may be used
       in conjunction with this protocol provided that it can meet the
@@ -273,10 +261,9 @@
       agent, transferred through one or more relaying agents, accepted by
       a serving agent, and finally retrieved by a reading agent.  Articles
       submitted to moderated groups go through an additional process,
-      which is described separately (see <xref target="moderate" /> and Step 7
-      of <xref target="injecting" />.  
-     Finally, the additional duties and
-      requirements of a gateway are discussed.</t>
+      which is described separately (see <xref target="moderate" /> and
+      Step 7 of <xref target="injecting" />).  Finally, the additional
+      duties and requirements of a gateway are discussed.</t>
 
       <t>At each step, each agent has a set of checks and transformations
       of the article that it is required to perform.  These are described
@@ -617,19 +604,20 @@
 
         <t>Contrary to <xref target="RFC5322" />, which implies that the
         mailbox or mailboxes in the From header field should be that of
-        the poster or posters, 
-        a poster who does not, for whatever
+        the poster or posters, 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" <xref target="RFC2606"
         />.</t>
 
         <t>Posting agents meant for use by ordinary posters SHOULD reject
-        any attempt to post an article that cancels or supersedes another
+        any attempt to post an article that cancels or supersedes (via the
+        Supersedes header field) another
         article of which the poster is not the author or sender.</t>
 
         <section anchor="proto-article" title="Proto-Articles">
           <t>A proto-article is an article in the format used by a posting
-          agent when offering that article to an injecting agent.  It may omit certain
+          agent when offering that article to an injecting agent.  It may
+          omit certain
           header fields that can be better supplied by the injecting
           agent and will not contain header fields that are added by the
           injecting agent.  A proto-article is only for transmission to an
@@ -673,7 +661,7 @@
 
           <t>In some cases, offering the same proto-article to all
           injecting agents may not be possible (such as when
-          gatewaying -- after injection -- articles found on one Netnews network to
+          gatewaying, after injection, articles found on one Netnews network to
           another supposedly unconnected one).  In this case, the posting
           agent MUST remove any Xref header field and rename or remove any
           Injection-Info, Path, and other trace header fields before
@@ -700,7 +688,8 @@
           moderated newsgroups in its Newsgroups header field SHOULD only
           be done by a moderator and MUST only be done after the
           proto-article has been approved for all moderated groups to
-          which it is to be posted and after it has an Approved header field (see
+          which it is to be posted and after an Approved header
+          field has been added (see
           <xref target="moderator" />).  Multiple injection of an
           unapproved article intended for moderated newsgroups will
           normally only result in the moderator receiving multiple copies,
@@ -739,8 +728,8 @@
 
               <t>The Newsgroups header field SHOULD, by default, be
               inherited from the precursor's Followup-To header field if
-              present; otherwise, it is inherited from the precursor's Newsgroups
-              header field.</t>
+              present; otherwise, it is inherited from the precursor's
+              Newsgroups header field.</t>
 
               <t>The Subject header field SHOULD, by default, be inherited
               from that of the precursor.  The case-sensitive string
@@ -981,8 +970,7 @@
         field and at least one of the &lt;dist-name>s in its Distribution
         header field (if present).  Exceptionally, control messages
         creating or removing newsgroups (newgroup or rmgroup control
-        messages, for example) 
-        SHOULD be relayed if the affected group
+        messages, for example) SHOULD be relayed if the affected group
         appears in its Newsgroups header field and both the sending and
         receiving relaying agents are configured to relay a newsgroup of
         that name (whether or not such a newsgroup exists).</t>
@@ -1010,7 +998,8 @@
             If it implements one of the mechanisms described in <xref
             target="history" />, this means that it MUST reject any
             article whose date falls outside the cutoff interval since it
-            won't know whether or not such articles had been accepted previously.</t>
+            won't know whether or not such articles had been accepted
+            previously.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -1092,7 +1081,8 @@
             If it implements one of the mechanisms described in <xref
             target="history" />, this means that it MUST reject any
             article whose date falls outside the cutoff interval since it
-            won't know whether or not such articles had been accepted previously.</t>
+            won't know whether or not such articles had been accepted
+            previously.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1286,12 +1276,10 @@
               <t>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. However, if it is not preserved in this way,
-              then at least it should be preserved 
-              as a comment in the message.  This helps greatly with
-              preventing loops.</t>
+              medium. However, if it is not preserved in this way, then at
+              least it should be preserved as a comment in the message.
+              This helps greatly with preventing loops.</t>
 
-
               <t>The Date and Injection-Date of the news article should
               also be preserved if possible, for similar reasons.</t>
 
@@ -1353,7 +1341,8 @@
               articles are bad enough; spews of control messages with
               special significance to the news system, possibly resulting
               in high processing load or even in emails being sent for
-              every message received, are catastrophic.  It is far preferable to
+              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.</t>
@@ -1600,7 +1589,7 @@
                              the recipient host's system beyond just
                              storage of the article.
 
-   Published specification:  RFC 5537
+   Published specification:  RFC 1036, RFC 5537
 
    Body part:                A complete proto-article ready for
                              injection into Netnews or an article
@@ -1615,13 +1604,6 @@
           </artwork>
         </figure>
 
-<!--[rfced] 2 questions about the registration above (first was 
-addressed in email from Lindsey on 4/16)
-
-For "Published specification", should RFC 1036 be added? Both this
-   document and 1036 are listed for news-transmission on
-   http://www.iana.org/assignments/media-types/application/
--->
         <t>usage=moderate indicates the article is intended for a
         moderator, usage=inject for an injecting agent, and usage=relay
         for a relaying agent.  The entity receiving the article may only
@@ -1786,7 +1768,6 @@
       checkgroups-body    = *( valid-group CRLF )
       valid-group         = newsgroups-line ; see Section 4.2
           </artwork>
-
         </figure>
 
         <t>The same restrictions on charset, &lt;newsgroup-name>, and
@@ -1843,7 +1824,8 @@
       header field starting with the string "cmsg&nbsp;" MUST NOT cause an
       article to be interpreted as a control message.  Agents MAY reject an
       article that has such a Subject header field and no Control
-      header field as ambiguous.  Likewise, the presence of a &lt;newsgroup-name>
+      header field as ambiguous.  Likewise, the presence of a
+      &lt;newsgroup-name>
       ending in ".ctl" in the Newsgroups header field or the presence of
       an Also-Control header field MUST NOT cause the article to be
       interpreted as a control message.</t>
@@ -2402,13 +2384,11 @@
             <organization>FlyDash, Inc.</organization>
           </author>
         </front>
-        <seriesInfo name="RFC"
-          value="5536" />
+        <seriesInfo name="RFC" value="5536" />
       </reference>
     </references>
 
     <references title="Informative References">
-
       <reference anchor="PGPMOOSE" 
        target="http://seer-grog.net/README">
         <front>
@@ -2422,7 +2402,7 @@
       </reference>
 
       <reference anchor="PGPVERIFY"
-        target="ftp://ftp.isc.org/pub/pgpcontrol/README.html">
+        target="ftp://ftp.isc.org/pub/pgpcontrol/FORMAT">
         <front>
           <title>Signing Control Messages</title>
           <author initials="D." surname="Lawrence"
@@ -2460,8 +2440,7 @@
           </author>
           <date month="March" year="2005" />
         </front>
-        <seriesInfo name="Work in"
-          value="Progress" />
+        <seriesInfo name="Work in" value="Progress" />
       </reference>
     </references>