Commit in docs/usefor (usepro.xml)

[email protected]
Newsgroups gmane.ietf.usenet.format
Message-ID <[email protected]>
    Date: Sunday, September 21, 2008 @ 18:30:34
  Author: eagle
Revision: 5043

Wording changes based on Charles's comprehensive review.  Most of the
changes are minor.  The only substantial changes are to add Path to
the list of headers that have to be removed or renamed during multiple
injection (provisionally, until we decide how to handle POSTED), and
adding a paragraph to Supersedes clarifying that those articles should
not be treated as control messages.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 00:40:25 UTC (rev 5042)
+++ docs/usefor/usepro.xml	2008-09-22 01:30:34 UTC (rev 5043)
@@ -49,7 +49,7 @@
     </author>
 
     <author initials="C.H." surname="Lindsey" fullname="Charles H. Lindsey">
-      <organization>University of Manchester</organization>
+      <organization></organization>
       <address>
         <postal>
           <street>5 Clerewood Avenue</street>
@@ -625,10 +625,10 @@
 
         <section anchor="multi-injection"
                  title="Multiple Injection of Articles">
-          <t>Under some circumstances (posting to multiple disjoint
-          networks, injecting agents with spotty connectivity, or for
-          redundancy, for example), a posting agent may wish to offer the
-          same article to multiple injecting agents.  In this unusual
+          <t>Under some circumstances (posting to multiple supposedly
+          disjoint networks, injecting agents with spotty connectivity, or
+          for redundancy, for example), a posting agent may wish to offer
+          the same article to multiple injecting agents.  In this unusual
           case, the goal is to not create multiple independent articles
           but rather to inject the same article at multiple points and let
           the normal duplicate suppression facility of Netnews (see <xref
@@ -644,18 +644,18 @@
 
           <t>In some cases, offering the same proto-article to all
           injecting agents may not be possible (such as when gatewaying,
-          after the fact, articles found on one Netnews network to
+          after injection, articles found on one Netnews network to
           another, supposedly unconnected one).  In this case, the posting
-          agent MUST convert the article back into a proto-article before
-          passing it to another injecting agent, but it MUST retain
-          unmodified the Message-ID, Date, and Injection-Date header
-          fields.  It MUST NOT add an Injection-Date header field if it is
-          missing from the existing article.  It MUST remove any Xref
-          header field and either rename or remove any Injection-Info
-          header field and other trace fields.
+          agent MUST remove any Xref header field and rename or remove any
+          Injection-Info, Path, and other trace header field before
+          passing it to another injecting agent.  (This converts the
+          article back into a proto-article.)  It MUST retain unmodified
+          the Message-ID, Date, and Injection-Date header fields.  It MUST
+          NOT add an Injection-Date header field if it is missing from the
+          existing article.
             <list style="empty">
               <t>NOTE: Multiple injection inherently risks duplicating
-              articles.  Multiple injection after the fact, by converting
+              articles.  Multiple injection after injection, by converting
               an article back to a proto-article and injecting it again,
               additionally risks loops, loss of trace information,
               unintended repeat injection into the same network, and other
@@ -746,10 +746,10 @@
 
           <t>The content of the new article's References header field MUST
           be formed from the content of the parent's References header
-          field if present and the content of the Message-ID header field
-          of the parent.  If the parent had a References header, FWS as
-          defined in <xref target="USEFOR" /> MUST be added between its
-          content and the Message-ID header field content.</t>
+          field if present, followed by the content of the Message-ID
+          header field of the parent.  If the parent had a References
+          header, FWS as defined in <xref target="USEFOR" /> MUST be added
+          between its content and the Message-ID header field content.</t>
 
           <t>If the resulting References header field would, after
           unfolding, exceed 998 characters in length (including its field
@@ -988,9 +988,9 @@
             <t>It SHOULD reject any article that matches an
             already-received cancel control message or the contents of the
             Supersedes header field of an accepted article, provided that
-            the relaying agent chose (on the basis of local site policy)
-            to honor that cancel control message or Supersedes header
-            field.</t>
+            the relaying agent has chosen (on the basis of local site
+            policy) to honor that cancel control message or Supersedes
+            header field.</t>
 
             <t>It MAY reject any article without an Approved header field
             posted to a newsgroup known to be moderated.  This practice is
@@ -1989,6 +1989,11 @@
         messages.  If the Supersedes header field is honored, the news
         server SHOULD take the same actions as it would take when honoring
         a cancel control message for the given target article.</t>
+
+        <t>The article containing the Supersedes header field, whether or
+        not the Supersedes header field is honored, SHOULD be handled as a
+        normal article and SHOULD NOT receive the special treatment of
+        control messages described in <xref target="serving" />.</t>
       </section>
 
       <section anchor="sendme" title="The ihave and sendme Control Messages">
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.