Subject: Count of senders to this mailing list, April 30

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Apr 2007 16:12:59 +0200

Thought I might just as well sum for the month...

  1   21  32.31 "Charles Lindsey" <[email-masked]>
  2   19  61.54 Russ Allbery <[email-masked]>
  3   11  78.46 Frank Ellermann <[email-masked]>
  4    9  92.31 Harald Alvestrand <[email-masked]>
  5    2  95.38 "Forrest J. Cavalier III" <[email-masked]>
  6    1  96.92 Dan Schlitt <[email-masked]>
  7    1  98.46 Richard Clayton <[email-masked]>
  8    1 100.00 [email-masked] (Ralph Babel from the peanut 
gallery)

Total: 65 messages

Date: Mon, 30 Apr 2007 16:12:59 +0200
From: Harald Alvestrand <[email-masked]>
To: Usenet <[email-masked]>
Subject: Count of senders to this mailing list, April 30
Sender: [email-masked]

Thought I might just as well sum for the month...

  1   21  32.31 "Charles Lindsey" <[email-masked]>
  2   19  61.54 Russ Allbery <[email-masked]>
  3   11  78.46 Frank Ellermann <[email-masked]>
  4    9  92.31 Harald Alvestrand <[email-masked]>
  5    2  95.38 "Forrest J. Cavalier III" <[email-masked]>
  6    1  96.92 Dan Schlitt <[email-masked]>
  7    1  98.46 Richard Clayton <[email-masked]>
  8    1 100.00 [email-masked] (Ralph Babel from the peanut 
gallery)

Total: 65 messages

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fwd: draft-resnick-2822upd-01 posted
Date:  Sun, 29 Apr 2007 23:53:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Pete Resnick wrote:
 
> Please follow the discussion on [email-masked].
[...] 
> <http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>

My attempt to post a rationale why NO-WS-CTL is bad and "canonical"
Message-IDs are good on the rfc822 list was rather clumsy.  Please
help to improve this if you think that RFC.ietf-usefor-usefor-12 got
this right (modulo "magic SP" and other Netnews peculiarities):

<http://permalink.gmane.org/gmane.ietf.rfc822/11834>

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: #1416 Injection-Date: current wording proposal (corrected)
Organization: The Eyrie
Date: Sat, 28 Apr 2007 19:32:33 -0700
Sender: [email-masked]

Gr.  Ignore the previous version of this message.  Saving the file before
regenerating the diff is useful.  Please ignore the previous version and
use this one instead.

Here's the updated wording proposal taking Frank's review into account.
This time I'll try XML diff, which I think is a little more readable (and
way easier to prepare) than trying to extract meaning from the text diff
with all the section numbering and pagination changes.

I think it may be worthwhile to reach consensus on several parts of this
separately.  For example, if we decide that the whole current history
section is fine, I can incorporate that into the draft and then stop
including it in further diffs for discussion.

--- usepro.xml	2007-02-19 22:20:06.000000000 -0800
+++ usepro-1416.xml	2007-04-28 19:30:11.000000000 -0700
@@ -165,8 +165,9 @@
 
         <t>"Injecting" an article is the processing of a proto-article by
         an injecting agent.  Normally this action is done once and only
-        once for a given article.  "Reinjecting" an article is passing an
-        already-injected article to an injection agent.</t>
+        once for a given article.  "Multiple injection" is passing the
+        same article to multiple injecting agents, either serially or in
+        parallel.</t>
 
         <t>A "gateway" is software which receives news articles and
         converts them to messages of some other kind (such as <xref
@@ -446,6 +447,68 @@
         </section>
       </section>
 
+      <section anchor="history"
+               title="Article History and Duplicate Suppression">
+        <t>Netnews normally uses a flood-fill algorithm for propagation of
+        articles in which each news server offers articles it accepts to
+        multiple peers and each news server may be offered the same
+        article from multiple other news servers.  Accordingly, duplicate
+        suppression is key; if a news server accepted every article it was
+        offered, it may needlessly accept (and then potentially
+        retransmit) dozens of copies of every article.</t>
+
+        <t>Relaying and serving agents therefore MUST keep a record of
+        articles they have already seen and use that record to reject
+        additional offers of the same article.  This record is called the
+        history file or database.</t>
+
+        <t>Each article is uniquely identified by its message identifier,
+        so a relaying or serving agent could satisfy this requirement by
+        storing a record of every message identifier that agent has ever
+        seen.  Such a history database would grow without bound, however,
+        so it is common and permitted to optimize based on the
+        Injection-Date or Date header field of an article as follows.  (In
+        the following discussion, the "date" of an article is defined to
+        be the date represented by its Injection-Date header field if
+        present, otherwise its Date header field.)
+          <list style="symbols">
+            <t>Agents MAY select a cutoff interval and reject any article
+            with a date farther in the past than that cutoff interval.  If
+            this interval is shorter than the time it takes for an article
+            to propagate through the network, the agent may reject an
+            article it had not yet seen, so it ought not be aggressively
+            short.  For Usenet, for example, a cutoff interval of no less
+            than seven days is conventional.</t>
+
+            <t>Agents that enforce such a cutoff MAY then drop records of
+            articles that had dates older than the cutoff from their
+            history databases.  If such an article were offered to the
+            agent again, it would be rejected due to the cutoff date, so
+            the history record is no longer required to suppress the
+            duplicate.</t>
+
+            <t>As an optimization for easier history database
+            manipulation, agents MAY instead drop history records written
+            longer ago than the cutoff interval plus one day.  If this
+            retention mechanism is used, the history retention period MUST
+            be longer than the cutoff interval to allow for articles dated
+            in the future unless the agent rejects all articles dated in
+            the future.  One day is the maximum allowed error into the
+            future for article dates, so it is a convenient and safe
+            extension for the retention interval.</t>
+          </list>
+        </t>
+
+        <t>This is just one implementation strategy for article history,
+        albeit the most common one.  Relaying and serving agents are not
+        required to use this strategy, only to meet the requirement of not
+        accepting an article more than once.  However, implementors of
+        general-purpose Netnews relaying and serving agents who do not
+        have extensive experience with Netnews and the subtle effects of
+        its flood-fill algorithm are encouraged to use the above algorithm
+        by default.</t>
+      </section>
+
       <section anchor="posting" title="Duties of a Posting Agent">
         <t>A posting agent is the component of a user agent that assists a
         poster in creating a valid proto-article and forwarding it to an
@@ -453,9 +516,33 @@
 
         <t>Posting agents SHOULD ensure that proto-articles they create
         are valid according to <xref target="USEFOR" /> and any other
-        applicable policies.  They MUST NOT create any Injection-Date or
-        Injection-Info header fields; these headers will be added by the
-        injecting agent.</t>
+        applicable policies.  They MUST NOT create an Injection-Info
+        header field; this header field will be added by the injecting
+        agent.</t>
+
+        <t>If a proto-article contains both Message-ID and Date header
+        fields, posting agents MAY add an Injection-Date header field to
+        that proto-article immediately before passing that proto-article
+        to an injection agent.  They SHOULD do so if the Date header field
+        (representing the composition time of the proto-article) is more
+        than a day in the past at the time of injection.  If the
+        proto-article is being sent to more than one injecting agent, see
+        <xref target="multi-injection" />.</t>
+
+        <t>The Injection-Date header field is new in this revision of the
+        Netnews protocol and is designed to permit the Date header field
+        to hold the composition date (as defined in section 3.6.1 of <xref
+        target="RFC2822" />), even if the proto-article is not injected
+        for some time after its composition.  However, note that all
+        implementations predating this specification ignore the
+        Injection-Date header field and use the Date header field in its
+        stead for rejecting articles older than their cutoff (see <xref
+        target="history" />), and injecting agents predating this
+        specification do not add an Injection-Date header.  Articles with
+        a Date header field substantially in the past will still be
+        rejected by implementations predating this specification,
+        regardless of the Injection-Date header field, and may suffer poor
+        propagation.</t>
 
         <t>Contrary to <xref target="RFC2822" />, which implies that the
         mailbox or mailboxes in the From header field should be that of
@@ -478,48 +565,70 @@
           agent.</t>
 
           <t>A proto-article has the same format as a normal article
-          except that the Injection-Date, Injection-Info, and Xref header
-          fields MUST NOT be present; the Path header field MUST NOT
-          contain a "POSTED" &lt;diag-keyword>; and any of the following
-          mandatory header fields MAY be omitted: Message-ID, Date, and
-          Path.  In all other respects, a proto-article MUST be a valid
-          Netnews article.  In particular, the header fields which may be
-          omitted MUST NOT be present with invalid content.</t>
+          except that the Injection-Info and Xref header fields MUST NOT
+          be present; the Path header field MUST NOT contain a "POSTED"
+          &lt;diag-keyword>; and any of the following mandatory header
+          fields MAY be omitted: Message-ID, Date, and Path.  In all other
+          respects, a proto-article MUST be a valid Netnews article.  In
+          particular, the header fields which may be omitted MUST NOT be
+          present with invalid content.</t>
 
           <t>If a posting agent intends to offer the same proto-article to
-          multiple injecting agents, the header fields Message-ID and Date
-          MUST be present and identical in all copies of the
-          proto-article.</t>
+          multiple injecting agents, the header fields Message-ID, Date,
+          and Injection-Date MUST be present and identical in all copies
+          of the proto-article.  See <xref target="multi-injection" />.</t>
         </section>
 
-        <section anchor="reinjection" title="Reinjection of Articles">
-          <t>A given article SHOULD be processed by an injecting agent
-          once and only once.  The Injection-Date or Injection-Info
-          header fields are added by an injecting agent and are not
-          permitted in a proto-article.  Their presence (or the presence
-          of other unstandardized or obsolete trace headers such as
-          NNTP-Posting-Host, NNTP-Posting-Date, or X-Trace) indicates
-          that the proto-article is instead an article and has already
-          been processed by an injecting agent.  A posting agent SHOULD
-          normally reject such articles.</t>
-
-          <t>In the exceptional case that an article needs to be
-          reinjected for some reason (such as transferring an article from
-          one Netnews to another where those networks have no relaying
-          agreement), the posting agent doing the reinjection MUST convert
-          the article back into a proto-article before passing it to an
-          injecting agent (such as by renaming the Injection-Info and
-          Injection-Date header fields and removing any Xref header field)
-          and MUST perform the date checks on the existing Injection-Date
-          or Date header fields that would otherwise be done by the
-          injecting agent.</t>
-
-          <t>Reinjecting articles may cause loops, loss of trace
-          information, and other problems and should only be done with
-          care and when there is no available alternative.  A posting
-          agent that does reinjection is a limited type of gateway and as
-          such is subject to all of the requirements of an incoming
-          gateway in addition to the requirements of a posting agent.</t>
+        <section anchor="multi-injection"
+                 title="Multiple Injection of Articles">
+          <t>Under some circumstances (posting to multiple disjoint
+          networks, injecting agents with spotty connectivity, or
+          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 target="history" />) ensure that any given agent only
+          accepts the article once.</t>
+
+          <t>Whenever possible, multiple injection SHOULD be done by
+          offering the same proto-article to multiple injecting agents.
+          The posting agent MUST supply the Message-ID, Date, and
+          Injection-Date header fields, and the proto-article offered to
+          each injecting agent MUST be identical.</t>
+
+          <t>In some cases, offering the same proto-article to all
+          injecting agents may not be possible (such as when transferring,
+          after the fact, articles found on one Netnews network to
+          another, 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.</t>
+
+          <t>Multiple injection inherently risks duplicating articles.
+          Multiple injection after the fact, by converting an article back
+          to a proto-article and injecting it again, additionally risks
+          loops, loss of trace information, and other problems and should
+          be done with care and only when there is no alternative.  The
+          requirement to retain Message-ID, Date, and Injection-Date
+          header fields minimizes the possibility of a loop and ensures
+          that the newly injected article is not treated as a new,
+          separate article.</t>
+
+          <t>Multiple injection of an article listing one or more
+          moderated newsgroups in its Newsgroups header field SHOULD only
+          be done by a moderator and MUST only be done after the
+          proto-article is approved for all moderated groups to which it
+          is posted and has an Approved header field.  Multiple injection
+          of an unapproved article intended for moderated newsgroups will
+          normally only result in the moderator receiving multiple copies,
+          and if the newsgroup status is not consistent across all
+          injecting agents, may result in duplication of the article or
+          other problems.</t>
         </section>
 
         <section anchor="followups" title="Followups">
@@ -644,23 +753,24 @@
 
             <t>It MUST reject any proto-article that does not have the
             proper mandatory header fields for a proto-article; that has
-            Injection-Date, Injection-Info, or Xref header fields; that
-            has a Path header field containing the "POSTED"
-            &lt;diag-keyword>; or that is not syntactically valid as
-            defined by <xref target="USEFOR" />.  It SHOULD reject any
-            proto-article which contains a header field deprecated for
-            Netnews.  It MAY reject any proto-article that contains trace
-            header fields indicating that it was already injected by an
-            injecting agent that did not add Injection-Info or
-            Injection-Date.</t>
+            Injection-Info or Xref header fields; that has a Path header
+            field containing the "POSTED" &lt;diag-keyword>; or that is
+            not syntactically valid as defined by <xref target="USEFOR"
+            />.  It SHOULD reject any proto-article which contains a
+            header field deprecated for Netnews.  It MAY reject any
+            proto-article that contains trace header fields indicating
+            that it was already injected by an injecting agent that did
+            not add Injection-Info or Injection-Date.</t>
 
             <t>It SHOULD reject any article whose Date header field is
             more than 24 hours into the future (and MAY use a margin less
             than 24 hours).  It SHOULD reject any article whose Date
-            header appears to be stale (more than 72 hours into the past,
-            for example, or too old to still be recorded in the database
-            of a relaying agent the injecting agent will be using) since
-            not all news servers support Injection-Date.</t>
+            header is too far into the past (older than the cutoff
+            interval of a relaying agent the injecting agent is using, for
+            example), since not all news servers support Injection-Date
+            and only the injecting agent can provide a useful error
+            message to the posting agent.  This interval SHOULD NOT be any
+            shorter than 72 hours into the past.</t>
 
             <t>It SHOULD reject any proto-article whose Newsgroups header
             field does not contain at least one &lt;newsgroup-name> for a
@@ -704,8 +814,14 @@
             the source of the article and possibly other trace information
             as described in Section 3.2.8 of <xref target="USEFOR" />.</t>
 
-            <t>The injecting agent MUST then add an Injection-Date header
-            field containing the current date and time.</t>
+            <t>If the proto-article already had an Injection-Date header
+            field, it MUST NOT be modified or replaced.  If the
+            proto-article had both a Message-ID header field and a Date
+            header field, an Injection-Date header field MUST NOT be
+            added, since the proto-article may have been multiply injected
+            by a posting agent that predates this standard.  Otherwise,
+            the injecting agent MUST add an Injection-Date header field
+            containing the current date and time.</t>
 
             <t>Finally, the injecting agent forwards the article to one or
             more relaying agents, and the injection process is
@@ -801,18 +917,15 @@
             field or Message-ID header field, or without either an
             Injection-Date or Date header field.</t>
 
-            <t>It MUST reject any article that has already been
-            successfully sent to it, based on the Message-ID header field
-            of the article.  To satisfy this requirement, a relaying agent
-            normally keeps a database of message identifiers it has
-            already accepted.</t>
-
             <t>It MUST examine the Injection-Date header field or, if
             absent, the Date header field, and reject the article if that
-            date predates the earliest articles of which it keeps record
-            or if that date is more than 24 hours into the future.  It MAY
-            reject articles with dates in the future with a smaller margin
-            than 24 hours.</t>
+            date is more than 24 hours into the future.  It MAY reject
+            articles with dates in the future with a smaller margin than
+            24 hours.</t>
+
+            <t>It MUST reject any article that has already been
+            successfully sent to it or that is dated older than its cutoff
+            date, as described in <xref target="history" />.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -886,16 +999,13 @@
 
             <t>It MUST examine the Injection-Date header field or, if
             absent, the Date header field, and reject the article if that
-            date predates the earliest articles of which it keeps record
-            or if that date is more than 24 hours into the future.  It MAY
-            reject articles with dates in the future with a smaller margin
-            than 24 hours.</t>
+            date is more than 24 hours into the future.  It MAY reject
+            articles with dates in the future with a smaller margin than
+            24 hours.</t>
 
             <t>It MUST reject any article that has already been
-            successfully sent to it, based on the Message-ID header field
-            of the article.  To satisfy this requirement, a relaying agent
-            normally keeps a database of message identifiers it has
-            already accepted.</t>
+            successfully sent to it or that is dated older than its cutoff
+            date, as described in <xref target="history" />.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1003,8 +1113,7 @@
             for reasons understood by the moderator (such as delays in the
             moderation process) in which case they MAY substitute the
             current date.  Any Injection-Date, Injection-Info, or Xref
-            header fields already present (though there should be none)
-            MUST be removed.</t>
+            header fields already present MUST be removed.</t>
 
             <t>Any Path header field MUST either be removed or truncated
             to only those entries following its "POSTED"

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: #1416 Injection-Date: current wording proposal
Organization: The Eyrie
Date: Sat, 28 Apr 2007 19:28:06 -0700
Sender: [email-masked]

Here's the updated wording proposal taking Frank's review into account.
This time I'll try XML diff, which I think is a little more readable (and
way easier to prepare) than trying to extract meaning from the text diff
with all the section numbering and pagination changes.

I think it may be worthwhile to reach consensus on several parts of this
separately.  For example, if we decide that the whole current history
section is fine, I can incorporate that into the draft and then stop
including it in further diffs for discussion.

--- usepro.xml	2007-02-19 22:20:06.000000000 -0800
+++ usepro-1416.xml	2007-04-28 19:04:17.000000000 -0700
@@ -165,8 +165,9 @@
 
         <t>"Injecting" an article is the processing of a proto-article by
         an injecting agent.  Normally this action is done once and only
-        once for a given article.  "Reinjecting" an article is passing an
-        already-injected article to an injection agent.</t>
+        once for a given article.  "Multiple injection" is passing the
+        same article to multiple injecting agents, either serially or in
+        parallel.</t>
 
         <t>A "gateway" is software which receives news articles and
         converts them to messages of some other kind (such as <xref
@@ -446,6 +447,68 @@
         </section>
       </section>
 
+      <section anchor="history"
+               title="Article History and Duplicate Suppression">
+        <t>Netnews normally uses a flood-fill algorithm for propagation of
+        articles in which each news server offers articles it accepts to
+        multiple peers and each news server may be offered the same
+        article from multiple other news servers.  Accordingly, duplicate
+        suppression is key; if a news server accepted every article it was
+        offered, it may needlessly accept (and then potentially
+        retransmit) dozens of copies of every article.</t>
+
+        <t>Relaying and serving agents therefore MUST keep a record of
+        articles they have already seen and use that record to reject
+        additional offers of the same article.  This record is called the
+        history file or database.</t>
+
+        <t>Each article is uniquely identified by its message identifier,
+        so a relaying or serving agent could satisfy this requirement by
+        storing a record of every message identifier that agent has ever
+        seen.  Such a history database would grow without bound, however,
+        so it is common and permitted to optimize based on the
+        Injection-Date or Date header field of an article as follows.  (In
+        the following discussion, the "date" of an article is defined to
+        be the date represented by its Injection-Date header field if
+        present, otherwise its Date header field.)
+          <list style="symbols">
+            <t>Agents MAY select a cutoff interval and reject any article
+            with a date farther in the past than that cutoff interval.  If
+            this interval is shorter than the time it takes for an article
+            to propagate through the network, the agent may reject an
+            article it had not yet seen, so it ought not be aggressively
+            short.  For Usenet, for example, a cutoff interval of no less
+            than seven days is conventional.</t>
+
+            <t>Agents that enforce such a cutoff MAY then drop records of
+            articles that had dates older than the cutoff from their
+            history databases.  If such an article were offered to the
+            agent again, it would be rejected due to the cutoff date, so
+            the history record is no longer required to suppress the
+            duplicate.</t>
+
+            <t>As an optimization for easier history database
+            manipulation, agents MAY instead drop history records written
+            longer ago than the cutoff interval plus one day.  If this
+            retention mechanism is used, the history retention period MUST
+            be longer than the cutoff interval to allow for articles dated
+            in the future unless the agent rejects all articles dated in
+            the future.  One day is the maximum allowed error into the
+            future for article dates, so it is a convenient and safe
+            extension for the retention interval.</t>
+          </list>
+        </t>
+
+        <t>This is just one implementation strategy for article history,
+        albeit the most common one.  Relaying and serving agents are not
+        required to use this strategy, only to meet the requirement of not
+        accepting an article more than once.  However, implementors of
+        general-purpose Netnews relaying and serving agents who do not
+        have extensive experience with Netnews and the subtle effects of
+        its flood-fill algorithm are encouraged to use the above algorithm
+        by default.</t>
+      </section>
+
       <section anchor="posting" title="Duties of a Posting Agent">
         <t>A posting agent is the component of a user agent that assists a
         poster in creating a valid proto-article and forwarding it to an
@@ -453,9 +516,33 @@
 
         <t>Posting agents SHOULD ensure that proto-articles they create
         are valid according to <xref target="USEFOR" /> and any other
-        applicable policies.  They MUST NOT create any Injection-Date or
-        Injection-Info header fields; these headers will be added by the
-        injecting agent.</t>
+        applicable policies.  They MUST NOT create an Injection-Info
+        header field; this header field will be added by the injecting
+        agent.</t>
+
+        <t>If a proto-article contains both Message-ID and Date header
+        fields, posting agents MAY add an Injection-Date header field to
+        that proto-article immediately before passing that proto-article
+        to an injection agent.  They SHOULD do so if the Date header field
+        (representing the composition time of the proto-article) is more
+        than a day in the past at the time of injection.  If the
+        proto-article is being sent to more than one injecting agent, see
+        <xref target="multi-injection" />.</t>
+
+        <t>The Injection-Date header field is new in this revision of the
+        Netnews protocol and is designed to permit the Date header field
+        to hold the composition date (as defined in section 3.6.1 of <xref
+        target="RFC2822" />), even if the proto-article is not injected
+        for some time after its composition.  However, note that all
+        implementations predating this specification ignore the
+        Injection-Date header field and use the Date header field in its
+        stead for rejecting articles older than their cutoff (see <xref
+        target="history" />), and injecting agents predating this
+        specification do not add an Injection-Date header.  Articles with
+        a Date header field substantially in the past will still be
+        rejected by implementations predating this specification,
+        regardless of the Injection-Date header field, and may suffer poor
+        propagation.</t>
 
         <t>Contrary to <xref target="RFC2822" />, which implies that the
         mailbox or mailboxes in the From header field should be that of
@@ -478,48 +565,70 @@
           agent.</t>
 
           <t>A proto-article has the same format as a normal article
-          except that the Injection-Date, Injection-Info, and Xref header
-          fields MUST NOT be present; the Path header field MUST NOT
-          contain a "POSTED" &lt;diag-keyword>; and any of the following
-          mandatory header fields MAY be omitted: Message-ID, Date, and
-          Path.  In all other respects, a proto-article MUST be a valid
-          Netnews article.  In particular, the header fields which may be
-          omitted MUST NOT be present with invalid content.</t>
+          except that the Injection-Info and Xref header fields MUST NOT
+          be present; the Path header field MUST NOT contain a "POSTED"
+          &lt;diag-keyword>; and any of the following mandatory header
+          fields MAY be omitted: Message-ID, Date, and Path.  In all other
+          respects, a proto-article MUST be a valid Netnews article.  In
+          particular, the header fields which may be omitted MUST NOT be
+          present with invalid content.</t>
 
           <t>If a posting agent intends to offer the same proto-article to
-          multiple injecting agents, the header fields Message-ID and Date
-          MUST be present and identical in all copies of the
-          proto-article.</t>
+          multiple injecting agents, the header fields Message-ID, Date,
+          and Injection-Date MUST be present and identical in all copies
+          of the proto-article.  See <xref target="multi-injection" />.</t>
         </section>
 
-        <section anchor="reinjection" title="Reinjection of Articles">
-          <t>A given article SHOULD be processed by an injecting agent
-          once and only once.  The Injection-Date or Injection-Info
-          header fields are added by an injecting agent and are not
-          permitted in a proto-article.  Their presence (or the presence
-          of other unstandardized or obsolete trace headers such as
-          NNTP-Posting-Host, NNTP-Posting-Date, or X-Trace) indicates
-          that the proto-article is instead an article and has already
-          been processed by an injecting agent.  A posting agent SHOULD
-          normally reject such articles.</t>
-
-          <t>In the exceptional case that an article needs to be
-          reinjected for some reason (such as transferring an article from
-          one Netnews to another where those networks have no relaying
-          agreement), the posting agent doing the reinjection MUST convert
-          the article back into a proto-article before passing it to an
-          injecting agent (such as by renaming the Injection-Info and
-          Injection-Date header fields and removing any Xref header field)
-          and MUST perform the date checks on the existing Injection-Date
-          or Date header fields that would otherwise be done by the
-          injecting agent.</t>
-
-          <t>Reinjecting articles may cause loops, loss of trace
-          information, and other problems and should only be done with
-          care and when there is no available alternative.  A posting
-          agent that does reinjection is a limited type of gateway and as
-          such is subject to all of the requirements of an incoming
-          gateway in addition to the requirements of a posting agent.</t>
+        <section anchor="multi-injection"
+                 title="Multiple Injection of Articles">
+          <t>Under some circumstances (posting to multiple disjoint
+          networks, injecting agents with spotty connectivity, or
+          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 target="history" />) ensure that any given agent only
+          accepts the article once.</t>
+
+          <t>Whenever possible, multiple injection SHOULD be done by
+          offering the same proto-article to multiple injecting agents.
+          The posting agent MUST supply the Message-ID, Date, and
+          Injection-Date header fields, and the proto-article offered to
+          each injecting agent MUST be identical.</t>
+
+          <t>In some cases, offering the same proto-article to all
+          injecting agents may not be possible (such as when transferring,
+          after the fact, articles found on one Netnews network to
+          another, 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.</t>
+
+          <t>Multiple injection inherently risks duplicating articles.
+          Multiple injection after the fact, by converting an article back
+          to a proto-article and injecting it again, additionally risks
+          loops, loss of trace information, and other problems and should
+          be done with care and only when there is no alternative.  The
+          requirement to retain Message-ID, Date, and Injection-Date
+          header fields minimizes the possibility of a loop and ensures
+          that the newly injected article is not treated as a new,
+          separate article.</t>
+
+          <t>Multiple injection of an article listing one or more
+          moderated newsgroups in its Newsgroups header field SHOULD only
+          be done by a moderator and SHOULD only be done after the
+          proto-article is approved for all moderated groups to which it
+          is posted and has an Approved header field.  Multiple injection
+          of an unapproved article intended for moderated newsgroups will
+          normally only result in the moderator receiving multiple copies,
+          and if the newsgroup status is not consistent across all
+          injecting agents, may result in duplication of the article or
+          other problems.</t>
         </section>
 
         <section anchor="followups" title="Followups">
@@ -644,23 +753,24 @@
 
             <t>It MUST reject any proto-article that does not have the
             proper mandatory header fields for a proto-article; that has
-            Injection-Date, Injection-Info, or Xref header fields; that
-            has a Path header field containing the "POSTED"
-            &lt;diag-keyword>; or that is not syntactically valid as
-            defined by <xref target="USEFOR" />.  It SHOULD reject any
-            proto-article which contains a header field deprecated for
-            Netnews.  It MAY reject any proto-article that contains trace
-            header fields indicating that it was already injected by an
-            injecting agent that did not add Injection-Info or
-            Injection-Date.</t>
+            Injection-Info or Xref header fields; that has a Path header
+            field containing the "POSTED" &lt;diag-keyword>; or that is
+            not syntactically valid as defined by <xref target="USEFOR"
+            />.  It SHOULD reject any proto-article which contains a
+            header field deprecated for Netnews.  It MAY reject any
+            proto-article that contains trace header fields indicating
+            that it was already injected by an injecting agent that did
+            not add Injection-Info or Injection-Date.</t>
 
             <t>It SHOULD reject any article whose Date header field is
             more than 24 hours into the future (and MAY use a margin less
             than 24 hours).  It SHOULD reject any article whose Date
-            header appears to be stale (more than 72 hours into the past,
-            for example, or too old to still be recorded in the database
-            of a relaying agent the injecting agent will be using) since
-            not all news servers support Injection-Date.</t>
+            header is too far into the past (older than the cutoff
+            interval of a relaying agent the injecting agent is using, for
+            example), since not all news servers support Injection-Date
+            and only the injecting agent can provide a useful error
+            message to the posting agent.  This interval SHOULD NOT be any
+            shorter than 72 hours into the past.</t>
 
             <t>It SHOULD reject any proto-article whose Newsgroups header
             field does not contain at least one &lt;newsgroup-name> for a
@@ -704,8 +814,14 @@
             the source of the article and possibly other trace information
             as described in Section 3.2.8 of <xref target="USEFOR" />.</t>
 
-            <t>The injecting agent MUST then add an Injection-Date header
-            field containing the current date and time.</t>
+            <t>If the proto-article already had an Injection-Date header
+            field, it MUST NOT be modified or replaced.  If the
+            proto-article had both a Message-ID header field and a Date
+            header field, an Injection-Date header field MUST NOT be
+            added, since the proto-article may have been multiply injected
+            by a posting agent that predates this standard.  Otherwise,
+            the injecting agent MUST add an Injection-Date header field
+            containing the current date and time.</t>
 
             <t>Finally, the injecting agent forwards the article to one or
             more relaying agents, and the injection process is
@@ -801,18 +917,15 @@
             field or Message-ID header field, or without either an
             Injection-Date or Date header field.</t>
 
-            <t>It MUST reject any article that has already been
-            successfully sent to it, based on the Message-ID header field
-            of the article.  To satisfy this requirement, a relaying agent
-            normally keeps a database of message identifiers it has
-            already accepted.</t>
-
             <t>It MUST examine the Injection-Date header field or, if
             absent, the Date header field, and reject the article if that
-            date predates the earliest articles of which it keeps record
-            or if that date is more than 24 hours into the future.  It MAY
-            reject articles with dates in the future with a smaller margin
-            than 24 hours.</t>
+            date is more than 24 hours into the future.  It MAY reject
+            articles with dates in the future with a smaller margin than
+            24 hours.</t>
+
+            <t>It MUST reject any article that has already been
+            successfully sent to it or that is dated older than its cutoff
+            date, as described in <xref target="history" />.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -886,16 +999,13 @@
 
             <t>It MUST examine the Injection-Date header field or, if
             absent, the Date header field, and reject the article if that
-            date predates the earliest articles of which it keeps record
-            or if that date is more than 24 hours into the future.  It MAY
-            reject articles with dates in the future with a smaller margin
-            than 24 hours.</t>
+            date is more than 24 hours into the future.  It MAY reject
+            articles with dates in the future with a smaller margin than
+            24 hours.</t>
 
             <t>It MUST reject any article that has already been
-            successfully sent to it, based on the Message-ID header field
-            of the article.  To satisfy this requirement, a relaying agent
-            normally keeps a database of message identifiers it has
-            already accepted.</t>
+            successfully sent to it or that is dated older than its cutoff
+            date, as described in <xref target="history" />.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1003,8 +1113,7 @@
             for reasons understood by the moderator (such as delays in the
             moderation process) in which case they MAY substitute the
             current date.  Any Injection-Date, Injection-Info, or Xref
-            header fields already present (though there should be none)
-            MUST be removed.</t>
+            header fields already present MUST be removed.</t>
 
             <t>Any Path header field MUST either be removed or truncated
             to only those entries following its "POSTED"

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416: Reinjection and Injection-Date proposed text
Organization: The Eyrie
Date: Sat, 28 Apr 2007 19:24:41 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:
> Russ Allbery wrote:

>> + it ought not be aggressively short.  For For Usenet, for example,
>> + a cutoff interval of no less than seven days is conventional.

> Yes, no MUSTard needed here, the consequences are clear.  Commercial
> servers with shorter cutoff intervals for "binary" newsgroups may
> need the support staff to answer complaints by their angry customers.

Just for clarity in the discussion (I don't think a wording change is
needed), note that the cutoff date for history retention is independent of
the period of article retention in the spool.  Usually the latter is
longer than the former, but it may also be shorter.  They don't need to be
related.

Normally, the cutoff date is set uniformly across the server regardless of
the group, but the article retention period may be set much shorter for
binary groups.  The requirement is then that the server keep a record of
those received and expired binary articles in the history file even after
deleting the article off disk until they meet the cutoff requirements.

>> - MUST NOT create any Injection-Date or Injection-Info header
>> - fields; these headers will be added by the injecting agent.
>> + MUST NOT create an Injection-Info header field; this headers will
>> + be added by the injecting agent.

> Nit: s/headers/header field/

Thanks, fixed.

>> + The Injection-Date header field is new in this revision of the
>> + Netnews protocol and is designed to permit the Date header field to
>> + hold the composition date, even if the proto-article is not injected
>> + for some time after its composition.

> Please add a reference to RFC 2822 here, it's likely not only you who
> hates this, it needs a compelling justification.

Yes, good idea.  Done.

>> + Posting agents MAY add an Injection-Date header field and SHOULD do
>> + so if the Date header field (representing the composition time of
>> + the proto-article) is more than a day in the past in case the
>> + injecting agent predates this specification.

> I think you're mixing unrelated concepts here.  The SHOULD is clear,
> it doesn't need the qualifier starting with "in case...".  The SHOULD
> addresses the "stale 2822 date" issue among other problems.

Yes, I think you're right.

> The MAY is something more subtle, and from the text it's not clear if
> this is limited to "more than a day ago".  I _guess_ that the MAY is
> about multiple injections, and you want to allow that posting agents
> create their own unique Message-ID + Injection-Date combination.  And
> with some reading between the lines such smart posting agents might even
> decide to ignore RFC 2822 and force a corresponding unique Date.

The intention was to allow posting agents to add an Injection-Date header
field any time they feel like it.  The other point that's missing here is
that the Injection-Date header shouldn't be added at the same point the
Date header is.  I now have:

   If a proto-article contains both Message-ID and Date header fields,
   posting agents MAY add an Injection-Date header field to that proto-
   article immediately before passing that proto-article to an injection
   agent.  They SHOULD do so if the Date header field (representing the
   composition time of the proto-article) is more than a day in the past
   at the time of injection.  If the proto-article is being sent to more
   than one injecting agent, see Section 3.4.2.

   The Injection-Date header field is new in this revision of the
   Netnews protocol and is designed to permit the Date header field to
   hold the composition date (as defined in section 3.6.1 of [RFC2822]),
   even if the proto-article is not injected for some time after its
   composition.  However, note that all implementations predating this
   specification ignore the Injection-Date header field and use the Date
   header field in its stead for rejecting articles older than their
   cutoff (see Section 3.3), and injecting agents predating this
   specification do not add an Injection-Date header.  Articles with a
   Date header field substantially in the past will still be rejected by
   implementations predating this specification, regardless of the
   Injection-Date header field, and may suffer poor propagation.

on the grounds of putting the requirement first and then the explanation.

>> + the header field Injection-Date SHOULD be present and identical in
>> + all copies of the proto-article.  See Section 3.4.2.

> Yes, and the MAY mentioned above might be also related to 3.4.2, If
> that's the case you've just overwritten it here by a SHOULD, or is the
> MAY about a 3rd case ?  Like a posting agent always creating its own
> Injection-Date even if it's not one of the two SHOULDs, that could be a
> 3rd case.  In that case I hope that it gets "identical" right under all
> foreseeable circumstances wrt the "multi-SHOULD".

This was a bit of a mess.  In my current draft, I've simplified this whole
situation by saying that posting agents doing multiple injection MUST add
the Injection-Date header field.  This makes all existing multiple
injection posting agents non-compliant, but we also did the same thing
with injecting agents and their Injection-Date requirement, so this seems
symmetric.

I would prefer that the whole Injection-Date feature be either a SHOULD or
a MUST, rather than using differing levels of requirement for different
agents.  Thoughts?  And does anyone want to argue that the whole feature
should be a SHOULD?

>> + the goal is to not create multiple independent articles but
>> + rather to inject the same article at multiple points and use the
>> + normal duplicate suppression facility of Netnews (see Section 3.3)
>> + ensure that any given agent only accepts the article once.

> Nit: s/use/let/

Fixed.

> The move from "reinjection" to "multiple injection" resulted in a
> far better readable story.

Yes, I was rather happy with that.  Thanks to Harald for the suggestion.
I think that casting of the idea makes everything much simpler.

>> -  A posting agent SHOULD normally reject such articles.

> Odd, was that really a "posting agent" rejecting articles ?

Yeah.  Dumb idea on my part, in retrospect.  It was discussed in some of
the side-threads of this overall discussion, and I decided to drop it as
part of these changes since the bits that it was referring to have now
substantially changed anyway.

>> + The posting agent MUST supply the Message-ID, Date, and
>> + Injection-Date header fields, and the proto-article offered to
>> + each injecting agent MUST be identical.

> Some lines above it was a "multi-SHOULD", now you have a "multi-MUST"
> for the Injection-Date.  How about this:

> | The posting agent MUST supply the Message-ID and the Date, it
> | SHOULD also supply an Injection-Date, and the proto-article
> | offered to each injecting agent MUST be identical.

> Arguably you can also use MUST here as you have it, and replace
> the "multi-SHOULD" at the end of 3.4.1 by MUST.  But that would
> render all existing posting agents with no idea about the new
> Injection-Date as "non-conforming" when they try multi-Injection.

As mentioned above, I went the MUST route, but I think it's a debatable
point and I'd love to hear other comments.

>> + It MUST remove any Xref header field and either rename or remove
>> + any Injection-Info header field and other trace fields.

> I see why they MUST remove Injection-Info, an old injecting agent would
> let it pass causing havoc.  But why MUST a posting agent remove Xref,
> this job could be handled by the injecting agent ?

> Is it "a simple MUST is better than more convoluted statements",
> or do I miss a serious Xref-problem here ?

It's more the former, plus backwards compatibility.  Existing injecting
agents will reject articles with Xref rather than remove the header.  It
seems simple enough given the other context to have posting agents remove
it, and existing posting agents remove it, so I just said MUST instead of
adding the explanation that existing injecting agents will reject and then
go through and try to change the language to allow injecting agents to
cope with it.

>> + SHOULD only be done after the proto-article is approved for
>> + all moderated groups to which it is posted and has an Approved
>> + header field.

> What's a good excuse to violate this SHOULD ?  Is it a moderator
> removing moderated and unapproved newsgroups, and injecting the article
> at least for the approved or unmoderated newsgroups ?  If there's no
> good excuse I prefer a MUST.

If the moderator changed anything about the Newsgroups header field, it
would no longer be multiple injection as defined in this document.  I
can't think of any reason to ever violate that SHOULD, so I've
provisionally changed it to MUST.  (Well, I suppose there's the case where
one has access to several injecting agents, each of which are unreliable,
and therefore one is using multiple injection to try to increase the
chances that at least one copy of the article gets to the moderator, but
this is enough of a special case that I don't think we need to call that
multiple injection as opposed to the poster intentionally posting several
articles.)

>> + This interval SHOULD NOT be any shorter than 72 hours into the
>> + past.

> That's a rather short minimum, barely enough for a normal weekend.
> For this radical approach, how about a MUST NOT ?  Disclaimer, I've
> no idea about what's usual for "binary" newsgroups.  But I doubt
> that they have any use for the 2822-Date concept like "text" groups
> or, more important, mail2news gateways.

On Usenet, I think a MUST NOT would probably be warranted, but I wasn't
comfortable enough saying that there would be no reason to ever use a
shorter interval in any Netnews implementation.  I don't really feel
strongly about this, but I mildly lean towards SHOULD NOT here just on the
grounds of permitting an out for some reason that we didn't anticipate.

Of course, the presence of this provision for injecting agents in the
draft at all is still being debated.  I know Charles would prefer that it
be removed, and I would like to get more feedback on that.

>> + If the proto-article had both a Message-ID header field and a
>> + Date header field, an Injection-Date header field MUST NOT be
>> + added, since the proto-article may have been multiply injected
>> + by a posting agent that predates this standard.  Otherwise, the
>> + injecting agent MUST add an Injection-Date header field
>> + containing the current date and time.

> We really need to check that you use MUST and SHOULD consistently.

> How about a 2 * 2 table, two for legacy vs. new posting agent, and two
> for legacy vs. new injecting agent, stating that all new agents MUST get
> it right, resulting in an overall SHOULD for "any" agent.

> Your MUST NOT + MUST above talks about new injecting agents.  For the
> MUST NOT it's obvious, a legacy agent doesn't know what the
> Injection-Date is and has no problem with not adding it.  But the MUST
> is only for new agents.  Overall it's a SHOULD, and legacy agents have a
> good excuse to violate the overall SHOULD.

Here's what it looked like before I started writing this section of my
reply:

Legacy posting agent, legacy injecting agent:
    No one will add Injection-Date since neither agent knows about it,
    although as a generic unknown header, either agent is permitted to
    do so.

Legacy posting agent, compliant injecting agent:
    Posting agent won't add Injection-Date.  Injecting agent MUST add
    Injection-Date if one or both of Date and Message-ID are not
    specified, otherwise MUST NOT (since multiple injection may be
    happening).

Compliant posting agent, legacy injecting agent:
    Posting agent MAY add Injection-Date any time, SHOULD if the Date
    is more than a day in the past at the time of injection, MUST if
    doing multiple injection.  The injecting agent doesn't know about
    the header and therefore will do nothing with it.

Compliant posting agent, compliant injecting agent:
    Posting agent MAY add Injection-Date any time, SHOULD if the Date
    is more than a day in the past at the time of injection, MUST if
    doing multiple injection.  Injecting agent generally MUST add the
    header if the posting agent doesn't.  The one exception is if the
    posting agent provides both Message-ID and Date but not
    Injection-Date, which it is always allowed to do and which doesn't
    even violate a SHOULD if the Date is fresh.  In this case, the
    injecting agent MUST NOT add it either.

Looking at that table, and given that we have spelled out elsewhere how to
handle articles with no Injection-Date, I think I agree with your point
and don't see a reason for the injection agent requirement to be MUST.  We
already have a scenario in which a post only handled by compliant agents
gets no Injection-Date and it doesn't break anything, so it seems like
addition of Injection-Date by an injecting agent need only be a SHOULD.

Opinions?

This situation might change if we went with Charles's approach where
injecting agents are permitted to add Injection-Date to posts that already
have both Message-ID and Date.  In that case, there is no gap.

>> + It MAY reject articles with dates in the future with a smaller
>> + margin than 24 hours.

> Does that really help ?

It's there to make it clear that some agents do not give you 24 hours of
leeway and this is permitted in the protocol.  It's redundant with the
general rule that anyone can reject any article for any reason they
please, but I felt like it was worth drawing special attention to this so
that people don't think they can rely on having 24 hours of slop in the
date checking.

>> + the Date header field, and reject the article if that date is
>> + more than 24 hours into the future.  It MAY reject articles with
>> + dates in the future with a smaller margin than 24 hours.

> Same here, let's stick to one day, and get rid of less than one day.

This wording should be identical to the wording called out above, so I'll
change both if we decide to change it.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Organization: The Eyrie
Date: Sat, 28 Apr 2007 18:44:31 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> I agree that that's the explanation, but it's a big wad of parenthetical
>> in the middle of the point.  Hm.

>> How about:

>>    "... Using "!!", and thereby adding <diag-match> since the
>                                         ^
>                                         a
>>    <path-identity> is verified, is RECOMMENDED."
>                        ^
>                   clearly/obviously

> Yes, something like that would be fine.

Here is the modified text proposal (as an XML diff):

--- usepro.xml	2007-02-19 22:20:06.000000000 -0800
+++ usepro-1414.xml	2007-04-28 18:43:12.000000000 -0700
@@ -373,16 +373,22 @@
               specification will add only single "!" characters between
               &lt;path-identity> strings.</t>
 
-              <t>The agent MUST then prepend its own &lt;path-identity> to
-              the Path header field content.</t>
-
-              <t>The agent MAY then prepend additional &lt;path-identity>s
-              for itself to the Path header field content, following each
-              &lt;path-identity> so added with either "!!" or "!".  This
-              is permitted for agents that have multiple
-              &lt;path-identity>s (such as during a transition from one to
-              another).  Each of these &lt;path-identity>s MUST meet the
-              requirements set out in <xref target="path" />.</t>
+              <t>The agent MAY then prepend to the Path header field
+              content "!" or "!!" followed by an additional
+              &lt;path-identity> for itself other than its primary one.
+              Using "!!", and thereby adding a &lt;diag-match> since the
+              &lt;path-identity clearly is verified, is RECOMMENDED.  This
+              step may be repeated any number of times.  This is permitted
+              for agents that have multiple &lt;path-identity>s (such as
+              during a transition from one to another).  Each of these
+              &lt;path-identity>s MUST meet the requirements set out in
+              <xref target="path" />.</t>
+
+              <t>Finally, the agent MUST prepend its primary
+              &lt;path-identity> to the Path header field content.  The
+              primary &lt;path-identity> is the &lt;path-identity> it
+              normally advertises to its peers for their use in generating
+              &lt;path-diagnostic>s as described above.</t>
             </list>
           </t>

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 28 Apr 2007 00:02:21 -0500
To: USEFOR:;
From: Pete Resnick <[email-masked]>
Subject: Fwd: draft-resnick-2822upd-01 posted
Sender: [email-masked]

Please follow the discussion on [email-masked].

--- begin forwarded text

Date: Thu, 26 Apr 2007 16:55:06 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: draft-resnick-2822upd-01 posted

You may have noticed that 2822upd-01 was posted.

<http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>
Also:
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt>

To make rfcdiff work, I've put a copy of RFC 2822 on my web site with 
some of the later sections rearranged so that they're in the same 
order as the current draft. You can see the diffs between the two 
here:

<http://tools.ietf.org/rfcdiff?url1=http://www.qualcomm.com/~presnick/rfc2822-fixed.txt&url2=http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>

Though overall very few, there are real changes from 2822 in this 
document that need review. See the changes section at the bottom. I 
did *not* go whole hog and switch to Bruce's syntax, simply because I 
wanted to limit the number of changes and see if we can't get this 
thing to Draft along with 2821bis. But I did incorporate (hopefully 
all of) the corrections that you all have pointed out over the last 
couple of years.

Please review with a fine toothed comb. If there are more than just a 
few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who 
have at assorted time offered assistance) to start an issues list.

Thanks in advance for your assistance.

pr

--- end forwarded text

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Organization: The Eyrie
Date: Fri, 27 Apr 2007 21:19:40 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> Point 1 says "use the actual name of your system in the Path."  I think
>> that's pretty clearly the best option and the one that provides the
>> maximum amount of useful trace information.  Does anyone really
>> disagree with that?

> I think the WG previously took the view that the actual name of the
> system and an MX to reach its admins were equally suitable. But if the
> WG now wants to say that the actual address is Point 1 and an MX is
> Point 2, then I would not argue too hard against it. Actually, the
> really REALLY best practice is to provide both an A/AAAA _and_ an MX,
> and that might be worth pointing out

It's a minor point, and somewhat off-topic, but I feel obligated to point
out whenever it seems appropriate that hosts running SMTP daemons with A
records do not need MX records.  A remarkable number of people (which I
expect does *not* include you -- this was just a rant trigger) seem to be
confused about this these days and write stupid spam filtering software
under the assumption that A records are not sufficient for delivering
e-mail.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.usefor:24627
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Fri, 27 Apr 2007 20:16:36 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> However, I am a bit dubious about mentioning exact figures like "72
>> hours", especially as you now speak elsewhere of "1 week" as a normal
>> cutoff time (I had always understood that a 3-day cutoff was common
>> amongst the large relay-only sites). That "72" may be justified here,
>> but there was another "72" elsewhere in your draft that is much more
>> doubtful.

>I'm trying to find a balance between being conservative in what one sends
>and liberal in what one accepts, and three days and seven days are the
>most common lower cutoff numbers that I've seen.  It's not clear to me the
>best way to handle this.

I would be inclined to mention in in the Moderators bit (as indeed was
done in Usepro-06), but not in the duties of an injecting agent.
Essentially, if a guy is slow at injecting an article he wrote some days
earlier, then it is his problem if it gets lost. But you can hardly blame
that guy in the case where it was the Moderator who mucked it up.

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

To: [email-masked]
Xref: clerew local.usefor:24626
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Date: Fri, 27 Apr 2007 20:08:17 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:
>> Russ Allbery <[email-masked]> writes:

>> OK, so what about #1415? I seem to remember suggesting a revised wording
>> for the introductory paragraph of 3.2.1 of the form:

>>    Except possibly when relaying to other hosts on the same site, every
>>    injecting, relaying, or serving agent that accepts an article MUST
>>    update the Path header field ....

>This part of #1415 I still don't agree with, and I didn't get the feeling
>there was a consensus in favor of (see also Richard's comments).  I'm not
>horribly *upset* by your proposal either, but so far it seemed like
>discussion was running 2 to 1 against.

OK, it is down as an Issue, so in due course the WG will have to decide it
one way or the other. The Sky will not Fall In either way. I raised it
because I had understood that is what the WG had originally agreed.

>>> Here's the new text rendered:

>> Yes that is much better. I would suggest, however

>>     "... Using "!!" is RECOMMENDED (where the second "!" is intended to
>>     be interpreted as a <diag-match>, such as might have been added in
>>     Step 3 if that additional <path-identity> has been placed there by a
>>     separate agent).

>I agree that that's the explanation, but it's a big wad of parenthetical
>in the middle of the point.  Hm.

>How about:

>    "... Using "!!", and thereby adding <diag-match> since the
                                        ^
                                        a
>    <path-identity> is verified, is RECOMMENDED."
                       ^
                  clearly/obviously

Yes, something like that would be fine.

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

To: [email-masked]
Xref: clerew local.usefor:24628
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Fri, 27 Apr 2007 20:23:28 GMT
Lines: 63
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:
>> Russ Allbery <[email-masked]> writes:

>>> I believe that an injecting agent MUST reject an article that already
>>> has an Injection-Info header and MAY reject an article that contains
>>> other trace headers that it happens to recognize.  Removing headers or
>>> renaming headers provided by a posting agent I believe is a SHOULD NOT.

>>> So some disagreement here.

>> I could almost be persuaded of this. My only doubt arises from the case
>> where an article prepared on a small private (one-node) network is then
>> (for redundancy or other reasons) is to be forwarded to two places, one
>> of which accepts relaying and the other insists it is injecting...

>> In that case, different versions of the article have to be sent to the
>> two sites.

>Correct.  The existing software for doing these sorts of things does
>handle this.  In INN, for instance, you would use a conventional nntpsend
>feed for the relaying site and an rpost feed for the injecting site.

>> That is not impossible, but it is a nuisance, especially if the site
>> actually believes (though misunderstanding) that it is relaying in both
>> cases (in which case you would then argue, I suppose, that it needs to
>> be "educated").

>Well, yes, because the site that requires injection is *not* relaying, by
>definition.  But the point of rpost is to convert a relaying attempt into
>an injecting attempt.

OK, I think you have persuaded me on that one.

>> However, even if Injection-Info is removed by a reinjector, I would
>> still prefer any original Path to be retained (even if that results in
>> two "POSTED"s within it). A Path is meant to record an article's
>> history, and destroying a part of that history may hinder subsequent
>> troubleshooting.

>I can be convinced that injecting agents shouldn't reject a Path
>containing two POSTEDs.  Anyone else have an opinion on that?  Is there
>any drawback to not allowing that?

AFAIR, the WG always accepted that could happen. In cases where things
have gone wrong, or malpractice is suspected, not throwing away what might
be useful evidence is never a good idea. Some sites copy original Paths
into an X-header, but I see no gain in doing that as opposed to just
leaving the Path as received and prepending new stuff in the usual way.

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

To: [email-masked]
Xref: clerew local.usefor:24625
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 27 Apr 2007 19:45:15 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>Charles,

>which part of RESOLVED didn't you understand?

We may have resolved what we are going to say, but not necessarily how we
are going to say it.

For example, I find the text that you yourself wrote when you first
proposed the idea that names which did not immediately resolve in the DNS
should be allowed (and which can still be found as '2nd alternative' in
Usepro-06) is superior to the present text.

>Charles Lindsey wrote:

>> bogus.bogus.com                                        - score  0 marks
>>   
>This is where you get confused.
>bogus.bogus.com WILL yield a SOA - the SOA of .com.

Indeed, which is why simply looking for SOA is not enough. For sure we do
not want to allow bogus.bogus.com.

Interestingly, the DKIM WG has been looking at this, and to do it properly
you really need some widely publicised and maintained list of TLDs/zones.

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

To: [email-masked]
Xref: clerew local.usefor:24623
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 27 Apr 2007 19:26:00 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> And if you say that Point 2 allows "any DNS record or none at all", then
>> what is the purpose of Point 1? Remember that we are trying to give some
>> rough "decreasing order of preference".

>Point 1 says "use the actual name of your system in the Path."  I think
>that's pretty clearly the best option and the one that provides the
>maximum amount of useful trace information.  Does anyone really disagree
>with that?

I think the WG previously took the view that the actual name of the system
and an MX to reach its admins were equally suitable. But if the WG now
wants to say that the actual address is Point 1 and an MX is Point 2, then
I would not argue too hard against it. Actually, the really REALLY best
practice is to provide both an A/AAAA _and_ an MX, and that might be worth
pointing out

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

To: [email-masked]
Xref: clerew local.usefor:24629
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Fri, 27 Apr 2007 20:26:48 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Harald Alvestrand <[email-masked]> writes:

>> I still think that having the posting agent specify injection-date is a
>> Bad Idea, but I could be willing to be part of the "rough" in "rough
>> consensus".

>After writing the text, I think it's weird, but it's not quite as bad as I
>thought it was going to be.  It does have the merit of closely mirroring
>how Date works today, and if we're going to change something in this area,
>sticking as close to what we know works as possible seems like a good idea
>to me.

+1

It may well be that most 'normal' posting agents leave it to the injecting
agent, but for the guy who is doing something slightly out of the ordinary
(multiple injection, delayed injection, etc) it does have some advantages,
and I can't see any disadvantage.

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

To: [email-masked]
Xref: clerew local.usefor:24624
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 27 Apr 2007 19:35:14 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> bogus.example.com where example.com yields just an SOA - score 10 marks
>> bogus.bogus.com                                        - score  0 marks
>> bogus.bogus                                            - score  0 marks
>> a <path-nodot>                                         - score 15 marks

>s/15/5/

:-)

>We can't have a DNS tutorial in the NetNews protocol spec.

Sure. We can use wording which indicates how the <path-identity> is to be
interpreted without going into DNS technicalities. "The domain in the
<path-identity> MUST/SHOULD/MAY be chosen so that it is possible to
identify the host-concerned/the admine-concerned/whatever-else ...".

>  And I hope they don't find 2142 as it is today,
>for cases when they're interested in something that's not abuse@.

I think we have made a deliberate choice not to _endorse_ 2142, but that
is not to say that it is wrong to follow it (though not at the level of
detail that it tries to insist on). USEAGE could try to pick up the
pieces.

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

Date: Thu, 26 Apr 2007 07:13:24 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: OT: nslookup -q=soa bogus.bogus.com
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>
>   
>> bogus.bogus.com WILL yield a SOA - the SOA of .com.
>>     
>
> `nslookup -q=soa bogus.bogus.com` results in an error
> with my version of nslookup, it gives up for NXDOMAIN.
>   
I was talking about Charles' tree-climbing exercise; if you cut off 
labels until you find something, you will eventually look up ".com".

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Tue, 24 Apr 2007 10:14:11 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> I still think that having the posting agent specify injection-date is a
> Bad Idea, but I could be willing to be part of the "rough" in "rough
> consensus".

After writing the text, I think it's weird, but it's not quite as bad as I
thought it was going to be.  It does have the merit of closely mirroring
how Date works today, and if we're going to change something in this area,
sticking as close to what we know works as possible seems like a good idea
to me.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 24 Apr 2007 14:49:40 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Russ Allbery <[email-masked]> writes:
>
>   
>> Charles Lindsey <[email-masked]> writes:
>>     
>
>   
>>> I think we have now said everything that is to be said on this, so I
>>> have produced a summary of where I think we have got to.
>>>       
>
>   
>> Thank you very much for writing this up.
>>     
>
> OK, so it seems my summary is largely accepted, modulo any additions
> arising from my more recent message regarding moderators. So it should now
> be just a straight question of choosing IC or IR.
>
>   
Don't bet on it. I haven't bothered commenting on your text in detail, 
since I find it more constructive to comment on Russ' proposed texts.

I still think that having the posting agent specify injection-date is a 
Bad Idea, but I could be willing to be part of the "rough" in "rough 
consensus".

Date: Tue, 24 Apr 2007 14:47:32 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: Reject vs. fix
Sender: [email-masked]

My technical opinion:

I think it's reasonable for a posting agent (under the control of the 
poster) to "fix" articles.
I think it's unreasonable for an injecting agent (under the control of 
the news admin) to do so.

Frank Ellermann wrote:
> Russ Allbery wrote:
>
>   
>> I believe that an injecting agent MUST reject an article that
>> already has an Injection-Info header and MAY reject an article
>> that contains other trace headers that it happens to recognize.
>> Removing headers or renaming headers provided by a posting 
>> agent I believe is a SHOULD NOT.
>>     
>  
>   
>> So some disagreement here.
>>     
>
> The idea is important, rejecting is clearer than most attempts
> to automatically "fix" articles.  It needs human intervention.
>
> Frank
>
>
>
>   

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Date:  Tue, 24 Apr 2007 13:47:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 9
Sender: [email-masked]

Russ Allbery wrote:
 
> How about:
>     "... Using "!!", and thereby adding <diag-match> since the
>     <path-identity> is verified, is RECOMMENDED."

Sure.  I thought the rationale is obvious, but explicitly stating
it in one short sentence is better.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  OT: nslookup -q=soa bogus.bogus.com (was: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity)
Date:  Tue, 24 Apr 2007 13:42:05 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Harald Alvestrand wrote:

> bogus.bogus.com WILL yield a SOA - the SOA of .com.

`nslookup -q=soa bogus.bogus.com` results in an error
with my version of nslookup, it gives up for NXDOMAIN.

> NEW TECHNICAL ARGUMENTS

Just an off topic technical observation, the question
of "zone cuts" is quite interesting, but admittedlly
not here.

Frank

Date: Tue, 24 Apr 2007 13:26:36 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

Charles,

which part of RESOLVED didn't you understand?

Charles Lindsey wrote:
> In <[email-masked]> Russ Allbery <[email-masked]> writes:
>   
> In the following, "bogus" means a component that fails to resolve,
> "example" means a component that resolves to an IP or MX, or even an SOA,
> possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" etc.
>
> example.example.com yields the IP of the relaying host - score 60 marks.
> example.example.com yields a useful MX                 - score 40 marks
>    (i.e. it works with some suitable RFC 2142 identity
>    such as news@/postmaster@/whatever)
> bogus.example.com where example.com yields a useful MX - score 20 marks
> bogus.example.com where example.com yields just an SOA - score 10 marks
> bogus.bogus.com                                        - score  0 marks
>   
This is where you get confused.
bogus.bogus.com WILL yield a SOA - the SOA of .com.

So you cannot programmatically tell the difference between 
"bogus.bogus.com" and "bogus.example.com" without giving special 
treatment to ".com".

One example of such a situation is where "bogus.com" is registered with 
Verisign, but no DNS service has been established yet. (Verisign allows 
that; others, such as .no, don't).

The current text covers that situation.
There has been no support for changing it.

Unless you have NEW TECHNICAL ARGUMENTS - which means something 
DIFFERENT from "I like" or "I think the group should like", your harping 
on the issue is OUT OF ORDER.

                      Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date:  Tue, 24 Apr 2007 12:13:56 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Charles Lindsey wrote:

> bogus.example.com where example.com yields just an SOA - score 10 marks
> bogus.bogus.com                                        - score  0 marks
> bogus.bogus                                            - score  0 marks
> a <path-nodot>                                         - score 15 marks

s/15/5/

>> I think the current wording is fine and already excludes bogus TLDs.
> Only in a very half-hearted sort of way.

We can't have a DNS tutorial in the NetNews protocol spec.  Folks
interested in the merits of MX or DDDS or RP and so on need to
look elsewhere.  And I hope they don't find 2142 as it is today,
for cases when they're interested in something that's not abuse@.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Organization: The Eyrie
Date: Mon, 23 Apr 2007 10:51:43 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> Sure it does.  Point 2 allows any DNS record or none at all.

> We seem to have reached the point now where it is agreed by the WG that
> we want to allow various things (including MX records and also things
> that do not resolve at all in the DNS, even though a 'stub' does
> resolve, but excluding things that are totally unrelated to the DNS,
> such as bogus TLDs). The question now is whether the present wording is
> the best way to describe what we want to allow.

> And if you say that Point 2 allows "any DNS record or none at all", then
> what is the purpose of Point 1? Remember that we are trying to give some
> rough "decreasing order of preference".

Point 1 says "use the actual name of your system in the Path."  I think
that's pretty clearly the best option and the one that provides the
maximum amount of useful trace information.  Does anyone really disagree
with that?

> In the following, "bogus" means a component that fails to resolve,
> "example" means a component that resolves to an IP or MX, or even an
> SOA, possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk"
> etc.

> example.example.com yields the IP of the relaying host - score 60 marks.
> example.example.com yields a useful MX                 - score 40 marks
>    (i.e. it works with some suitable RFC 2142 identity
>    such as news@/postmaster@/whatever)

I think the main place we disagree is over the usefulness of an MX record.
If I have the FQDN of the host, I can figure out somewhere reasonable to
mail.  An MX may save me a small amount of time, but usually it's pretty
obvious.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Mon, 23 Apr 2007 10:48:11 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:
>> Charles Lindsey <[email-masked]> writes:

>>> I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*,
>>> X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject
>>> (reinjected) articles already containing those headers.

>> I believe that an injecting agent MUST reject an article that already
>> has an Injection-Info header and MAY reject an article that contains
>> other trace headers that it happens to recognize.  Removing headers or
>> renaming headers provided by a posting agent I believe is a SHOULD NOT.

>> So some disagreement here.

> This arises when an article has been "reinjected" for some strange
> reason.  Essentially, you are saying that it is the responsibility of
> the reinjector to remove any existing Injection-Info, otherwise the
> injecting agent will throw it back at him.

Correct.

> I could almost be persuaded of this. My only doubt arises from the case
> where an article prepared on a small private (one-node) network is then
> (for redundancy or other reasons) is to be forwarded to two places, one
> of which accepts relaying and the other insists it is injecting (even
> though IHAVE has been used, as now permitted by INN).

INN doesn't permit IHAVE in a default configuration, to note.

> In that case, different versions of the article have to be sent to the
> two sites.

Correct.  The existing software for doing these sorts of things does
handle this.  In INN, for instance, you would use a conventional nntpsend
feed for the relaying site and an rpost feed for the injecting site.

> That is not impossible, but it is a nuisance, especially if the site
> actually believes (though misunderstanding) that it is relaying in both
> cases (in which case you would then argue, I suppose, that it needs to
> be "educated").

Well, yes, because the site that requires injection is *not* relaying, by
definition.  But the point of rpost is to convert a relaying attempt into
an injecting attempt.

> However, even if Injection-Info is removed by a reinjector, I would
> still prefer any original Path to be retained (even if that results in
> two "POSTED"s within it). A Path is meant to record an article's
> history, and destroying a part of that history may hinder subsequent
> troubleshooting.

I can be convinced that injecting agents shouldn't reject a Path
containing two POSTEDs.  Anyone else have an opinion on that?  Is there
any drawback to not allowing that?

>> However, I think the best solution to this is, rather than tackling the
>> gateways section, to write a separate section about multiple injection
>> to replace the section about reinjection.

> However, reinjection is not always associated with multiple injection,
> so it still needs some mention.

It is if you define multiple injection that way.  :)  See my proposed new
section and see what you think.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Mon, 23 Apr 2007 10:43:31 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> However, I am a bit dubious about mentioning exact figures like "72
> hours", especially as you now speak elsewhere of "1 week" as a normal
> cutoff time (I had always understood that a 3-day cutoff was common
> amongst the large relay-only sites). That "72" may be justified here,
> but there was another "72" elsewhere in your draft that is much more
> doubtful.

I'm trying to find a balance between being conservative in what one sends
and liberal in what one accepts, and three days and seven days are the
most common lower cutoff numbers that I've seen.  It's not clear to me the
best way to handle this.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Organization: The Eyrie
Date: Mon, 23 Apr 2007 10:42:01 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> Easy one first.  Here is my proposed text for #1414, which also
>> addresses part of Charles's concerns in #1415.  There hasn't been any
>> subsequent discussion of my original response to #1414, so I'm going to
>> go with my preferred option of MUST/SHOULD for "!" vs. "!!".

> OK, so what about #1415? I seem to remember suggesting a revised wording
> for the introductory paragraph of 3.2.1 of the form:

>    Except possibly when relaying to other hosts on the same site, every
>    injecting, relaying, or serving agent that accepts an article MUST
>    update the Path header field ....

> So if the point is accepted, that wording should still work. See issue
> tracker #1415 for full discussion.

This part of #1415 I still don't agree with, and I didn't get the feeling
there was a consensus in favor of (see also Richard's comments).  I'm not
horribly *upset* by your proposal either, but so far it seemed like
discussion was running 2 to 1 against.

>> Here's the new text rendered:

>>   4.  The agent MAY then prepend to the Path header field content "!"
>>       or "!!" followed by an additional <path-identity> for itself
>>       other than its primary one.  Using "!!" is RECOMMENDED.  This
>>       step may be repeated any number of times.  This is permitted for
>>       agents that have multiple <path-identity>s (such as during a
>>       transition from one to another).  Each of these <path-identity>s
>>       MUST meet the requirements set out in Section 3.2.

>>   5.  Finally, the agent MUST prepend its primary <path-identity> to
>>       the Path header field content.  The primary <path-identity> is
>>       the <path-identity> it normally advertises to its peers for their
>>       use in generating <path-diagnostic>s as described above.

> Yes that is much better. I would suggest, however

>     "... Using "!!" is RECOMMENDED (where the second "!" is intended to
>     be interpreted as a <diag-match>, such as might have been added in
>     Step 3 if that additional <path-identity> has been placed there by a
>     separate agent).

I agree that that's the explanation, but it's a big wad of parenthetical
in the middle of the point.  Hm.

How about:

    "... Using "!!", and thereby adding <diag-match> since the
    <path-identity> is verified, is RECOMMENDED."

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.usefor:24608
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Date: Mon, 23 Apr 2007 14:02:45 GMT
Lines: 60
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Harald Tveit Alvestrand <[email-masked]> writes:

>> #1414: USEPRO 3.2.1: delimiter for multiple Path identities
>>  No discussion
>> #1415: USEPRO 3.2.1: Number of path entries per site
>>  Discussion, but no proposed text.

>Easy one first.  Here is my proposed text for #1414, which also addresses
>part of Charles's concerns in #1415.  There hasn't been any subsequent
>discussion of my original response to #1414, so I'm going to go with my
>preferred option of MUST/SHOULD for "!" vs. "!!".

OK, so what about #1415? I seem to remember suggesting a revised wording
for the introductory paragraph of 3.2.1 of the form:

   Except possibly when relaying to other hosts on the same site, every
   injecting, relaying, or serving agent that accepts an article MUST
   update the Path header field ....

So if the point is accepted, that wording should still work. See issue
tracker #1415 for full discussion.

>Here's the new text rendered:

>   4.  The agent MAY then prepend to the Path header field content "!"
>       or "!!" followed by an additional <path-identity> for itself
>       other than its primary one.  Using "!!" is RECOMMENDED.  This
>       step may be repeated any number of times.  This is permitted for
>       agents that have multiple <path-identity>s (such as during a
>       transition from one to another).  Each of these <path-identity>s
>       MUST meet the requirements set out in Section 3.2.

>   5.  Finally, the agent MUST prepend its primary <path-identity> to
>       the Path header field content.  The primary <path-identity> is
>       the <path-identity> it normally advertises to its peers for their
>       use in generating <path-diagnostic>s as described above.

Yes that is much better. I would suggest, however

    "... Using "!!" is RECOMMENDED (where the second "!" is intended to be
    interpreted as a <diag-match>, such as might have been added in Step 3
    if that additional <path-identity> has been placed there by a separate
    agent).

IOW, software/humans reading the Path do not need to be aware whether
successive <path-identity>s were added by the same of by different agents.

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

To: [email-masked]
Xref: clerew local.usefor:24610
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Mon, 23 Apr 2007 14:52:26 GMT
Lines: 44
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>   4.  Moderators are encouraged to retain the Message-ID header field
>       if it is valid, and also retain the Date header field unless it
>       appears to be stale (72 hours or more in the past) for reasons
>       understood by the moderator (such as delays in the moderation
>       process) in which case they MAY substitute the current date.  Any
>       Injection-Date, Injection-Info, or Xref header fields already
>       present (though there should be none) MUST be removed.

>I'm dropping the "(though there should be none)" when proposing wording
>for this change, since it's now more likely.

OK.

>>> There is a separate but related question of whether, for the benefit of
>>> legacy injecting and relaying agents, he might need to do something
>>> about a Date header that had been rendered unusually stale because of
>>> hiw own delay. Usepro-06 made some special provision for this, and I
>>> think Usepro-07 does also. Normally, of course, Date should be left
>>> strictly alone as being a matter to be determined by the Poster, but
>>> one can hardly blame the Poster for subsequent delays caused by the
>>> moderator.

>> Yup.

>And the current provision is also quoted above.

However, I am a bit dubious about mentioning exact figures like "72
hours", especially as you now speak elsewhere of "1 week" as a normal
cutoff time (I had always understood that a 3-day cutoff was common
amongst the large relay-only sites). That "72" may be justified here, but
there was another "72" elsewhere in your draft that is much more doubtful.

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

To: [email-masked]
Xref: clerew local.usefor:24607
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Mon, 23 Apr 2007 12:21:27 GMT
Lines: 68
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> On the contrary, Russ has agreed, more or less, with the list of
>> existing practices thst we need to accomodate, but clearly the present
>> wording does not allow all of them (in particular, it seems not to allow
>> MX records in any shape or form).

>Sure it does.  Point 2 allows any DNS record or none at all.

We seem to have reached the point now where it is agreed by the WG that we
want to allow various things (including MX records and also things that do
not resolve at all in the DNS, even though a 'stub' does resolve, but
excluding things that are totally unrelated to the DNS, such as bogus
TLDs). The question now is whether the present wording is the best way to
describe what we want to allow.

And if you say that Point 2 allows "any DNS record or none at all", then
what is the purpose of Point 1? Remember that we are trying to give some
rough "decreasing order of preference".

Essentially, we want the <path-identity>s that are used to be "helpful" to
both software and humans that have occasion to use them. Suppose we award
marks for "helpfulness" (note, I am not suggesting we write the document
in these terms).

In the following, "bogus" means a component that fails to resolve,
"example" means a component that resolves to an IP or MX, or even an SOA,
possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" etc.

example.example.com yields the IP of the relaying host - score 60 marks.
example.example.com yields a useful MX                 - score 40 marks
   (i.e. it works with some suitable RFC 2142 identity
   such as news@/postmaster@/whatever)
bogus.example.com where example.com yields a useful MX - score 20 marks
bogus.example.com where example.com yields just an SOA - score 10 marks
bogus.bogus.com                                        - score  0 marks
bogus.bogus                                            - score  0 marks
a <path-nodot>                                         - score 15 marks

So an ideal site could score 100 marks;
60 marks and even 40 marks could be normal and acceptable;
But below 40 is getting a bit dodgy, though allowable;
And zero is quite unacceptable.

So it those marks reflect our gut feeling of what we want to see, then the
question is what wording would best convey that gut feeling (though not
with such a fine-grained level of detail)?

My concern is that the present wording gets no way near it. We should be
able to do much better.

>I think the current wording is fine and already excludes bogus TLDs.

Only in a very half-hearted sort of way.

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

To: [email-masked]
Xref: clerew local.usefor:24609
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Mon, 23 Apr 2007 14:45:13 GMT
Lines: 122
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> I think we have now said everything that is to be said on this, so I
>> have produced a summary of where I think we have got to.

>Thank you very much for writing this up.

OK, so it seems my summary is largely accepted, modulo any additions
arising from my more recent message regarding moderators. So it should now
be just a straight question of choosing IC or IR.

>> I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*,
>> X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject
>> (reinjected) articles already containing those headers.

>I believe that an injecting agent MUST reject an article that already has
>an Injection-Info header and MAY reject an article that contains other
>trace headers that it happens to recognize.  Removing headers or renaming
>headers provided by a posting agent I believe is a SHOULD NOT.

>So some disagreement here.

This arises when an article has been "reinjected" for some strange reason.
Essentially, you are saying that it is the responsibility of the
reinjector to remove any existing Injection-Info, otherwise the injecting
agent will throw it back at him.

I could almost be persuaded of this. My only doubt arises from the case
where an article prepared on a small private (one-node) network is
then (for redundancy or other reasons) is to be forwarded to two places,
one of which accepts relaying and the other insists it is injecting (even
though IHAVE has been used, as now permitted by INN). In that case,
different versions of the article have to be sent to the two sites.

That is not impossible, but it is a nuisance, especially if the site
actually believes (though misunderstanding) that it is relaying in both
cases (in which case you would then argue, I suppose, that it needs to be
"educated").

However, even if Injection-Info is removed by a reinjector, I would still
prefer any original Path to be retained (even if that results in two
"POSTED"s within it). A Path is meant to record an article's history, and
destroying a part of that history may hinder subsequent troubleshooting.
Better the evidence of reinjection should be there for all to see.
Moreover, if by some complicated means the article ever propagates back
towards one of the "pre-historic" sites, it would still be in order not to
send it there on the grounds that is had already been there once.

>> We disagree on the following two possibilities:
> 
>> IC. Injecting agents MUST insert Injection-Date when it is absent
>> (unless it is apparent that this is a reinjection).

>>    Good News IC: This provides immediate beneffit to the posting agent
>>    which has delayed injection, even if P5 is not implemented.

>>    Bad News IC: Until multi-injecting sites can be assumed to have
>>    implemented P6 this can cause re-acceptance of articles at later
>>    relaying agents if one of the multi-injected versions suffers
>>    substantial delay en route. So the existing behaviour is changed to
>>    that extent.
> 
>> IR. Injecting agents MUST NOT insert Injection-Date if both (Date AND
>>    Message-ID are already present).

>>    Good News IR: Inverse of the Bad News IC.

>>    Bad News IR: Posting agents with delayed injection see no benefit
>>    unless/until they implement P5.

>I think that's a fair summary of the options.

OK, so are we ready to count heads on that?

Essentially, it is a choice between accepting an occasional duplicate
article at un-upgraded sites, versus not getting the full benefit of
Injection-Date with current posting agents as soon as injecting/relaying
agents start to recognize it.

>> Gateways:
>> ---------

>> And especially Gateways from one Netnews system A to another one B, in
>> particular from small private one-node networks into Usenet:

>> G1. MUST retain all headers as received (including in particular Date
>> and Injection-Date), unless some EXCEPTION applies, as listed below.

>> G2. MUST hand article to an injecting agent, or else perform all the
>> duties on an injecting agent (except perhaps insertion of
>> Injection-Date) themselves and then relay.

>However, I think the best solution to this is, rather than tackling the
>gateways section, to write a separate section about multiple injection to
>replace the section about reinjection.

However, reinjection is not always associated with multiple injection, so
it still needs some mention. For sure, Gateways have to do the right thing
in the ways I have outlined, whether we use the word "reinjection" or not.
The problem is that such reinjectors may not think to regard themselves as
gatweways unless we point it out to them.

I have read your revised wordings to implement all these things, but I
need to examine them more carefully before responding. I notice that Frank
has made some comments, not all of which I agree with.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Organization: The Eyrie
Date: Sun, 22 Apr 2007 12:51:21 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:
> Russ Allbery wrote:

>> + The primary &lt;path-identity> is the &lt;path-identity>
>> + it normally advertises to its peers for their use in
>> + generating &lt;path-diagnostic>s as described above.</t>

> Good.  An XML-editor keeping ">" as is only because it's
> allowed would make me nervous, but that's off topic... :-)

XML editor?  What's that?  :)  (I'm too anal about indentation and
whitespace and all the XML editors I've used do things subtlely wrong for
me.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Date:  Sun, 22 Apr 2007 19:50:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Russ Allbery wrote:

>+ <t>The agent MAY then prepend to the Path header field
>+ content "!" or "!!" followed by an additional
>+ &lt;path-identity> for itself other than its primary one.
>+ Using "!!" is RECOMMENDED.
[...]

Is that new ?  I thought that's already accepted text.

>+ The primary &lt;path-identity> is the &lt;path-identity>
>+ it normally advertises to its peers for their use in
>+ generating &lt;path-diagnostic>s as described above.</t>

Good.  An XML-editor keeping ">" as is only because it's
allowed would make me nervous, but that's off topic... :-)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Reject vs. fix (was: #1416 Injection-Date - Summary of options)
Date:  Sun, 22 Apr 2007 19:40:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Russ Allbery wrote:

> I believe that an injecting agent MUST reject an article that
> already has an Injection-Info header and MAY reject an article
> that contains other trace headers that it happens to recognize.
> Removing headers or renaming headers provided by a posting 
> agent I believe is a SHOULD NOT.
 
> So some disagreement here.

The idea is important, rejecting is clearer than most attempts
to automatically "fix" articles.  It needs human intervention.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1416 Injection-Date - Summary of options
Date:  Sun, 22 Apr 2007 19:26:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Russ Allbery wrote:

> Look good?

Yes, I read and answered in reverse chronological order, see
my longer reply to your long diff with a question about the
second moderator multi-SHOULD.  I tried to figure out why
it's no MUSTard.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1416: Reinjection and Injection-Date proposed text
Date:  Sun, 22 Apr 2007 19:12:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 157
Sender: [email-masked]

Russ Allbery wrote:

> +3.3.  Article History and Duplicate Suppression
[...]

Very clear, thanks.

>+ it ought not be aggressively short.  For For Usenet, for example,
>+ a cutoff interval of no less than seven days is conventional.

Yes, no MUSTard needed here, the consequences are clear.  Commercial
servers with shorter cutoff intervals for "binary" newsgroups may
need the support staff to answer complaints by their angry customers.

>- MUST NOT create any Injection-Date or Injection-Info header
>- fields; these headers will be added by the injecting agent.
>+ MUST NOT create an Injection-Info header field; this headers will
>+ be added by the injecting agent.

Nit: s/headers/header field/

>+ The Injection-Date header field is new in this revision of the
>+ Netnews protocol and is designed to permit the Date header field to
>+ hold the composition date, even if the proto-article is not injected
>+ for some time after its composition.

Please add a reference to RFC 2822 here, it's likely not only you who
hates this, it needs a compelling justification.

>+ Posting agents MAY add an Injection-Date header field and SHOULD do
>+ so if the Date header field (representing the composition time of
>+ the proto-article) is more than a day in the past in case the
>+ injecting agent predates this specification.

I think you're mixing unrelated concepts here.  The SHOULD is clear,
it doesn't need the qualifier starting with "in case...".  The SHOULD
addresses the "stale 2822 date" issue among other problems.

The MAY is something more subtle, and from the text it's not clear if
this is limited to "more than a day ago".  I _guess_ that the MAY is
about multiple injections, and you want to allow that posting agents
create their own unique Message-ID + Injection-Date combination.  And
with some reading between the lines such smart posting agents might
even decide to ignore RFC 2822 and force a corresponding unique Date.

>+ Note, though, that articles with a Date header field substantially
>+ in the past will still be rejected by implementations predating
>+ this specification, regardless of the Injection-Date header field,
>+ and may suffer poor propagation.

Okay, it's not only "between the lines", and I like that, too.

>+ the header field Injection-Date SHOULD be present and identical in
>+ all copies of the proto-article.  See Section 3.4.2.

Yes, and the MAY mentioned above might be also related to 3.4.2,  If
that's the case you've just overwritten it here by a SHOULD, or is
the MAY about a 3rd case ?  Like a posting agent always creating its
own Injection-Date even if it's not one of the two SHOULDs, that
could be a 3rd case.  In that case I hope that it gets "identical"
right under all foreseeable circumstances wrt the "multi-SHOULD".

>+ the goal is to not create multiple independent articles but
>+ rather to inject the same article at multiple points and use the
>+ normal duplicate suppression facility of Netnews (see Section 3.3)
>+ ensure that any given agent only accepts the article once.

Nit: s/use/let/

The move from "reinjection" to "multiple injection" resulted in a
far better readable story.

>-  A posting agent SHOULD normally reject such articles.

Odd, was that really a "posting agent" rejecting articles ?

>+ The posting agent MUST supply the Message-ID, Date, and
>+ Injection-Date header fields, and the proto-article offered to
>+ each injecting agent MUST be identical.

Some lines above it was a "multi-SHOULD", now you have a "multi-MUST"
for the Injection-Date.  How about this:

| The posting agent MUST supply the Message-ID and the Date, it
| SHOULD also supply an Injection-Date, and the proto-article
| offered to each injecting agent MUST be identical.

Arguably you can also use MUST here as you have it, and replace
the "multi-SHOULD" at the end of 3.4.1 by MUST.  But that would
render all existing posting agents with no idea about the new
Injection-Date as "non-conforming" when they try multi-Injection.

>+ It MUST remove any Xref header field and either rename or remove
>+ any Injection-Info header field and other trace fields.

I see why they MUST remove Injection-Info, an old injecting agent
would let it pass causing havoc.  But why MUST a posting agent
remove Xref, this job could be handled by the injecting agent ?

Is it "a simple MUST is better than more convoluted statements",
or do I miss a serious Xref-problem here ?

>+ SHOULD only be done after the proto-article is approved for
>+ all moderated groups to which it is posted and has an Approved
>+ header field.

What's a good excuse to violate this SHOULD ?  Is it a moderator
removing moderated and unapproved newsgroups, and injecting the
article at least for the approved or unmoderated newsgroups ?
If there's no good excuse I prefer a MUST.

>+ This interval SHOULD NOT be any shorter than 72 hours into the
>+ past.

That's a rather short minimum, barely enough for a normal weekend.
For this radical approach, how about a MUST NOT ?  Disclaimer, I've
no idea about what's usual for "binary" newsgroups.  But I doubt
that they have any use for the 2822-Date concept like "text" groups
or, more important, mail2news gateways.

>+ If the proto-article had both a Message-ID header field and a
>+ Date header field, an Injection-Date header field MUST NOT be
>+ added, since the proto-article may have been multiply injected
>+ by a posting agent that predates this standard.  Otherwise, the
>+ injecting agent MUST add an Injection-Date header field
>+ containing the current date and time.

We really need to check that you use MUST and SHOULD consistently.

How about a 2 * 2 table, two for legacy vs. new posting agent, and
two for legacy vs. new injecting agent, stating that all new agents
MUST get it right, resulting in an overall SHOULD for "any" agent.

Your MUST NOT + MUST above talks about new injecting agents.  For
the MUST NOT it's obvious, a legacy agent doesn't know what the
Injection-Date is and has no problem with not adding it.  But the
MUST is only for new agents.  Overall it's a SHOULD, and legacy
agents have a good excuse to violate the overall SHOULD.

>+ It MAY reject articles with dates in the future with a smaller
>+ margin than 24 hours.

Does that really help ?  Otherwise strike it, we have a precision
of "days" elsewhere, not "hours", and "days" allow us to ignore
all plausible timezone issues.

>+ the Date header field, and reject the article if that date is
>+ more than 24 hours into the future.  It MAY reject articles with
>+ dates in the future with a smaller margin than 24 hours.

Same here, let's stick to one day, and get rid of less than one day.

Impression without checking the details:  the quoted parts are now
clearer than in I-D.ietf-usefor-usepro-06.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: #1416: Reinjection and Injection-Date proposed text
Organization: The Eyrie
Date: Sat, 21 Apr 2007 22:13:38 -0700
Sender: [email-masked]

Okay, here we go.  Some time away from this, while unfortunate for
progress in the working group, definitely cleared my head and gave me a
new perspective.

Here's a concrete wording proposal.  This implements the IR proposal
rather than the IC proposal in Charles's writeup.  If we decide to go with
IC, the modifications should be slight.  This will hopefully give us
something more concrete to discuss, and I think we'll be able to quickly
reach consensus on some parts of it.

After some time away and reconsidering this, I favor Harold's (and, I
think, Charles's) proposal of simply not worrying about the case that was
giving me so much heartburn and simply ruling out serial multiple
injection in cases where you have to drop the Injection-Date header field
in the main language of the standard.  If someone wants to handle that
separately as a gateway, I think the out is there, and we don't need to
draw a bright arrow to it.

Please pay special attention to the new Article History and Duplicate
Suppression section and the Multiple Injection of Articles section that
replaces the whole Reinjection section in the current draft.  The former
should hopefully be uncontroversial and address many of Frank's concerns.

Hopefully a unified diff is reasonably readable.  If folks would like me
to send out the complete revised text, let me know.  I've omitted the
obvious diffs to section numbers and the like, so this diff probably won't
apply entirely cleanly.

--- draft-ietf-usefor-usepro-07.txt	2007-02-19 22:20:36.000000000 -0800
+++ usepro-1416.txt	2007-04-21 22:08:45.000000000 -0700
@@ -309,8 +309,8 @@
 
    "Injecting" an article is the processing of a proto-article by an
    injecting agent.  Normally this action is done once and only once for
-   a given article.  "Reinjecting" an article is passing an already-
-   injected article to an injection agent.
+   a given article.  "Multiple injection" is passing the same article to
+   multiple injecting agents, either serially or in parallel.
 
    A "gateway" is software which receives news articles and converts
    them to messages of some other kind (such as [RFC2822] mail
@@ -631,7 +631,72 @@
    baz.isp.example, bar.isp.example, and foo-news folded the Path header
    field.
 
-3.3.  Duties of a Posting Agent
+3.3.  Article History and Duplicate Suppression
+
+   Netnews normally uses a flood-fill algorithm for propagation of
+   articles in which each news server offers articles it accepts to
+   multiple peers and each news server may be offered the same article
+   from multiple other news servers.  Accordingly, duplicate suppression
+   is key; if a news server accepted every article it was offered, it
+   may needlessly accept (and then potentially retransmit) dozens of
+   copies of every article.
+
+   Relaying and serving agents therefore MUST keep a record of articles
+   they have already seen and use that record to reject additional
+   offers of the same article.  This record is called the history file
+   or database.
+
+   Each article is uniquely identified by its message identifier, so a
+   relaying or serving agent could satisfy this requirement by storing a
+   record of every message identifier that agent has ever seen.  Such a
+   history database would grow without bound, however, so it is common
+   and permitted to optimize based on the Injection-Date or Date header
+   field of an article as follows.  (In the following discussion, the
+   "date" of an article is defined to be the date represented by its
+   Injection-Date header field if present, otherwise its Date header
+   field.)
+
+   o  Agents MAY select a cutoff interval and reject any article with a
+      date farther in the past than that cutoff interval.  If this
+      interval is shorter than the time it takes for an article to
+      propagate through the network, the agent may reject an article it
+      had not yet seen, so it ought not be aggressively short.  For
+      Usenet, for example, a cutoff interval of no less than seven days
+      is conventional.
+
+
+
+
+
+Allbery & Lindsey         Expires July 5, 2007                 [Page 12]
+
+Internet-Draft     Netnews Architecture and Protocols       January 2007
+
+
+   o  Agents that enforce such a cutoff MAY then drop records of
+      articles that had dates older than the cutoff from their history
+      databases.  If such an article were offered to the agent again, it
+      would be rejected due to the cutoff date, so the history record is
+      no longer required to suppress the duplicate.
+
+   o  As an optimization for easier history database manipulation,
+      agents MAY instead drop history records written longer ago than
+      the cutoff interval plus one day.  If this retention mechanism is
+      used, the history retention period MUST be longer than the cutoff
+      interval to allow for articles dated in the future unless the
+      agent rejects all articles dated in the future.  One day is the
+      maximum allowed error into the future for article dates, so it is
+      a convenient and safe extension for the retention interval.
+
+   This is just one implementation strategy for article history, albeit
+   the most common one.  Relaying and serving agents are not required to
+   use this strategy, only to meet the requirement of not accepting an
+   article more than once.  However, implementors of general-purpose
+   Netnews relaying and serving agents who do not have extensive
+   experience with Netnews and the subtle effects of its flood-fill
+   algorithm are encouraged to use the above algorithm by default.
+
+3.4.  Duties of a Posting Agent
 
    A posting agent is the component of a user agent that assists a
    poster in creating a valid proto-article and forwarding it to an
@@ -639,8 +704,33 @@
 
    Posting agents SHOULD ensure that proto-articles they create are
    valid according to [USEFOR] and any other applicable policies.  They
-   MUST NOT create any Injection-Date or Injection-Info header fields;
-   these headers will be added by the injecting agent.
+   MUST NOT create an Injection-Info header field; this headers will be
+   added by the injecting agent.
+
+   The Injection-Date header field is new in this revision of the
+   Netnews protocol and is designed to permit the Date header field to
+   hold the composition date, even if the proto-article is not injected
+   for some time after its composition.  However, note that all
+   implementations predating this specification ignore the Injection-
+   Date header field and use the Date header field in its stead for
+   rejecting articles older than their cutoff (see Section 3.3), and
+   injecting agents predating this specification do not add an
+   Injection-Date header.  Posting agents MAY add an Injection-Date
+   header field and SHOULD do so if the Date header field (representing
+   the composition time of the proto-article) is more than a day in the
+   past in case the injecting agent predates this specification.  Note,
+   though, that articles with a Date header field substantially in the
+   past will still be rejected by implementations predating this
+
+
+
+Allbery & Lindsey         Expires July 5, 2007                 [Page 13]
+
+Internet-Draft     Netnews Architecture and Protocols       January 2007
+
+
+   specification, regardless of the Injection-Date header field, and may
+   suffer poor propagation.
 
    Contrary to [RFC2822], which implies that the mailbox or mailboxes in
    the From header field should be that of the poster or posters, a
@@ -652,7 +742,7 @@
    attempt to post an article which cancels or Supersedes another
    article of which the poster is not the author or sender.
 
-3.3.1.  Proto-articles
+3.4.1.  Proto-articles
 
    A proto-article is an article in the format used by a posting agent
    for offering to an injecting agent.  It may omit certain header
@@ -662,54 +752,75 @@
    SHOULD NOT be transmitted to any other agent.
 
    A proto-article has the same format as a normal article except that
-   the Injection-Date, Injection-Info, and Xref header fields MUST NOT
-   be present; the Path header field MUST NOT contain a "POSTED" <diag-
-   keyword>; and any of the following mandatory header fields MAY be
-
+   the Injection-Info and Xref header fields MUST NOT be present; the
+   Path header field MUST NOT contain a "POSTED" <diag-keyword>; and any
+   of the following mandatory header fields MAY be omitted: Message-ID,
+   Date, and Path.  In all other respects, a proto-article MUST be a
+   valid Netnews article.  In particular, the header fields which may be
+   omitted MUST NOT be present with invalid content.
 
+   If a posting agent intends to offer the same proto-article to
+   multiple injecting agents, the header fields Message-ID and Date MUST
+   be present and identical in all copies of the proto-article, and the
+   header field Injection-Date SHOULD be present and identical in all
+   copies of the proto-article.  See Section 3.4.2.
+
+3.4.2.  Multiple Injection of Articles
+
+   Under some circumstances (posting to multiple disjoint networks,
+   injecting agents with spotty connectivity, or 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 use the normal duplicate suppression
+   facility of Netnews (see Section 3.3) ensure that any given agent
+   only accepts the article once.
 
-Allbery & Lindsey         Expires July 5, 2007                 [Page 12]
-
-Internet-Draft     Netnews Architecture and Protocols       January 2007
+   Whenever possible, multiple injection SHOULD be done by offering the

-   omitted: Message-ID, Date, and Path.  In all other respects, a proto-
-   article MUST be a valid Netnews article.  In particular, the header
-   fields which may be omitted MUST NOT be present with invalid content.
 
-   If a posting agent intends to offer the same proto-article to
-   multiple injecting agents, the header fields Message-ID and Date MUST
-   be present and identical in all copies of the proto-article.
+Allbery & Lindsey         Expires July 5, 2007                 [Page 14]
+
+Internet-Draft     Netnews Architecture and Protocols       January 2007
 
-3.3.2.  Reinjection of Articles
 
-   A given article SHOULD be processed by an injecting agent once and
-   only once.  The Injection-Date or Injection-Info header fields are
-   added by an injecting agent and are not permitted in a proto-article.
-   Their presence (or the presence of other unstandardized or obsolete
-   trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or
-   X-Trace) indicates that the proto-article is instead an article and
-   has already been processed by an injecting agent.  A posting agent
-   SHOULD normally reject such articles.
-
-   In the exceptional case that an article needs to be reinjected for
-   some reason (such as transferring an article from one Netnews to
-   another where those networks have no relaying agreement), the posting
-   agent doing the reinjection MUST convert the article back into a
-   proto-article before passing it to an injecting agent (such as by
-   renaming the Injection-Info and Injection-Date header fields and
-   removing any Xref header field) and MUST perform the date checks on
-   the existing Injection-Date or Date header fields that would
-   otherwise be done by the injecting agent.
-
-   Reinjecting articles may cause loops, loss of trace information, and
-   other problems and should only be done with care and when there is no
-   available alternative.  A posting agent that does reinjection is a
-   limited type of gateway and as such is subject to all of the
-   requirements of an incoming gateway in addition to the requirements
-   of a posting agent.
+   same proto-article to multiple injecting agents.  The posting agent
+   MUST supply the Message-ID, Date, and Injection-Date header fields,
+   and the proto-article offered to each injecting agent MUST be
+   identical.
+
+   In some cases, offering the same proto-article to all injecting
+   agents may not be possible (such as when transferring, after the
+   fact, articles found on one Netnews network to another, 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.
+
+   Multiple injection inherently risks duplicating articles.  Multiple
+   injection after the fact, by converting an article back to a proto-
+   article and injecting it again, additionally risks loops, loss of
+   trace information, and other problems and should be done with care
+   and only when there is no alternative.  The requirement to retain
+   Message-ID, Date, and Injection-Date header fields minimizes the
+   possibility of a loop and ensures that the newly injected article is
+   not treated as a new, separate article.
+
+   Multiple injection of an article listing one or more moderated
+   newsgroups in its Newsgroups header field SHOULD only be done by a
+   moderator and SHOULD only be done after the proto-article is approved
+   for all moderated groups to which it is posted and has an Approved
+   header field.  Multiple injection of an unapproved article intended
+   for moderated newsgroups will normally only result in the moderator
+   receiving multiple copies, and if the newsgroup status is not
+   consistent across all injecting agents, may result in duplication of
+   the article or other problems.
 
-3.3.3.  Followups
+3.4.3.  Followups
 
    A followup is an article that contains a response to the contents of
    an earlier article, its precursor.  In addition to its normal duties,
@@ -831,30 +942,31 @@
 
    2.   It MUST reject any proto-article that does not have the proper
         mandatory header fields for a proto-article; that has Injection-
-        Date, Injection-Info, or Xref header fields; that has a Path
-        header field containing the "POSTED" <diag-keyword>; or that is
+        Info or Xref header fields; that has a Path header field
+        containing the "POSTED" <diag-keyword>; or that is not
+        syntactically valid as defined by [USEFOR].  It SHOULD reject

-Allbery & Lindsey         Expires July 5, 2007                 [Page 15]
+Allbery & Lindsey         Expires July 5, 2007                 [Page 17]
 
 Internet-Draft     Netnews Architecture and Protocols       January 2007

-        not syntactically valid as defined by [USEFOR].  It SHOULD
-        reject any proto-article which contains a header field
-        deprecated for Netnews.  It MAY reject any proto-article that
-        contains trace header fields indicating that it was already
-        injected by an injecting agent that did not add Injection-Info
-        or Injection-Date.
+        any proto-article which contains a header field deprecated for
+        Netnews.  It MAY reject any proto-article that contains trace
+        header fields indicating that it was already injected by an
+        injecting agent that did not add Injection-Info or Injection-
+        Date.
 
    3.   It SHOULD reject any article whose Date header field is more
         than 24 hours into the future (and MAY use a margin less than 24
-        hours).  It SHOULD reject any article whose Date header appears
-        to be stale (more than 72 hours into the past, for example, or
-        too old to still be recorded in the database of a relaying agent
-        the injecting agent will be using) since not all news servers
-        support Injection-Date.
+        hours).  It SHOULD reject any article whose Date header is too
+        far into the past (older than the cutoff interval of a relaying
+        agent the injecting agent is using, for example), since not all
+        news servers support Injection-Date and only the injecting agent
+        can provide a useful error message to the posting agent.  This
+        interval SHOULD NOT be any shorter than 72 hours into the past.
 
    4.   It SHOULD reject any proto-article whose Newsgroups header field
         does not contain at least one <newsgroup-name> for a valid
@@ -904,13 +1016,19 @@
         source of the article and possibly other trace information as
         described in Section 3.2.8 of [USEFOR].
 
-   11.  The injecting agent MUST then add an Injection-Date header field
-        containing the current date and time.
+   11.  If the proto-article already had an Injection-Date header field,
+        it MUST NOT be modified or replaced.  If the proto-article had
+        both a Message-ID header field and a Date header field, an
+        Injection-Date header field MUST NOT be added, since the proto-
+        article may have been multiply injected by a posting agent that
+        predates this standard.  Otherwise, the injecting agent MUST add
+        an Injection-Date header field containing the current date and
+        time.
 
    12.  Finally, the injecting agent forwards the article to one or more
         relaying agents, and the injection process is complete.
 
-3.4.1.  Forwarding Messages to a Moderator
+3.5.1.  Forwarding Messages to a Moderator
 
    An injecting agent MUST forward the proto-article to the moderator of
    the leftmost moderated group listed in the Newsgroups header field,
@@ -964,7 +1084,7 @@
    that database.  Such methods may be more appropriate for smaller
    Netnews networks.
 
-3.5.  Duties of a Relaying Agent
+3.6.  Duties of a Relaying Agent
 
    A relaying agent accepts injected articles from injecting and other
    relaying agents and passes them on to relaying or serving agents.  To
@@ -993,28 +1113,24 @@
 
    1.  It MUST reject any article without a Newsgroups header field or
        Message-ID header field, or without either an Injection-Date or
-       Date header field.
-
-   2.  It MUST reject any article that has already been successfully
-       sent to it, based on the Message-ID header field of the article.
-       To satisfy this requirement, a relaying agent normally keeps a
-       database of message identifiers it has already accepted.

-
-
-Allbery & Lindsey         Expires July 5, 2007                 [Page 18]
+Allbery & Lindsey         Expires July 5, 2007                 [Page 20]
 
 Internet-Draft     Netnews Architecture and Protocols       January 2007

-   3.  It MUST examine the Injection-Date header field or, if absent,
-       the Date header field, and reject the article if that date
-       predates the earliest articles of which it keeps record or if
-       that date is more than 24 hours into the future.  It MAY reject
-       articles with dates in the future with a smaller margin than 24
-       hours.
+       Date header field.
+
+   2.  It MUST examine the Injection-Date header field or, if absent,
+       the Date header field, and reject the article if that date is
+       more than 24 hours into the future.  It MAY reject articles with
+       dates in the future with a smaller margin than 24 hours.
+
+   3.  It MUST reject any article that has already been successfully
+       sent to it or that is dated older than its cutoff date, as
+       described in Section 3.3.
 
    4.  It SHOULD reject any article that does not include all the
        mandatory header fields.  It MAY reject any article that contains
@@ -1052,19 +1168,20 @@
    modify the body of articles in any way.  If an article is not
    acceptable as-is, the article MUST be rejected rather than modified.
 
-3.6.  Duties of a Serving Agent
 
-   A serving agent accepts articles from a relaying agent or injecting
-   agent, stores it, and makes it available to reading agents.  Articles
-   are normally indexed by newsgroup and <article-locator> (Section

-Allbery & Lindsey         Expires July 5, 2007                 [Page 19]
+Allbery & Lindsey         Expires July 5, 2007                 [Page 21]
 
 Internet-Draft     Netnews Architecture and Protocols       January 2007

+3.7.  Duties of a Serving Agent
+
+   A serving agent accepts articles from a relaying agent or injecting
+   agent, stores it, and makes it available to reading agents.  Articles
+   are normally indexed by newsgroup and <article-locator> (Section
    3.2.14 of [USEFOR]), usually in the form of a decimal number.
 
    If the serving agent stores articles by newsgroup, control messages
@@ -1088,20 +1205,17 @@
        fields that do not have valid contents.
 
    2.  It MUST examine the Injection-Date header field or, if absent,
-       the Date header field, and reject the article if that date
-       predates the earliest articles of which it keeps record or if
-       that date is more than 24 hours into the future.  It MAY reject
-       articles with dates in the future with a smaller margin than 24
-       hours.
+       the Date header field, and reject the article if that date is
+       more than 24 hours into the future.  It MAY reject articles with
+       dates in the future with a smaller margin than 24 hours.
 
    3.  It MUST reject any article that has already been successfully
-       sent to it, based on the Message-ID header field of the article.
-       To satisfy this requirement, a relaying agent normally keeps a
-       database of message identifiers it has already accepted.
+       sent to it or that is dated older than its cutoff date, as
+       described in Section 3.3.
 
    4.  It SHOULD reject any article that matches an already-received and
        honored cancel message or Supersedes header field following the
-       same rules as a relaying agent (Section 3.5).
+       same rules as a relaying agent (Section 3.6).
 
    5.  It MUST reject any article without an Approved header field
        posted to any newsgroup listed as moderated.
@@ -1212,7 +1327,7 @@
        understood by the moderator (such as delays in the moderation
        process) in which case they MAY substitute the current date.  Any
        Injection-Date, Injection-Info, or Xref header fields already
-       present (though there should be none) MUST be removed.
+       present MUST be removed.
 
    5.  Any Path header field MUST either be removed or truncated to only
        those entries following its "POSTED" <diag-keyword>, if any.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Sat, 21 Apr 2007 21:41:03 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:
> Russ Allbery wrote:

>> I think it's reasonable to let the article possibly end up duplicated
>> in the bizarre case where the poster is multiply injecting and some
>> sites have the group marked moderated and some marked unmoderated.

> If that case is considered as "bizarre" please say so in the draft.
> Maybe not literally, but the tendency should be clear for readers.

   Multiple injection of an article listing one or more moderated
   newsgroups in its Newsgroups header field SHOULD only be done by a
   moderator and SHOULD only be done after the proto-article is approved
   for all moderated groups to which it is posted and has an Approved
   header field.  Multiple injection of an unapproved article intended
   for moderated newsgroups will normally only result in the moderator
   receiving multiple copies, and if the newsgroup status is not
   consistent across all injecting agents, may result in duplication of
   the article or other problems.

Look good?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Sat, 21 Apr 2007 21:39:04 -0700
Sender: [email-masked]

Russ Allbery <[email-masked]> writes:
> Charles Lindsey <[email-masked]> writes:

>> So I think, in this case, the moderator MUST now discard any
>> Injection-Date already provided, and then proceed to inject the
>> Approved article in the normal manner, at which point he MAY then add
>> an Injection-Date, and MUST add one if he is injecting at multiple
>> sites.

> Yup, that sounds right to me.  Good catch.

Turns out we already had this:

   4.  Moderators are encouraged to retain the Message-ID header field
       if it is valid, and also retain the Date header field unless it
       appears to be stale (72 hours or more in the past) for reasons
       understood by the moderator (such as delays in the moderation
       process) in which case they MAY substitute the current date.  Any
       Injection-Date, Injection-Info, or Xref header fields already
       present (though there should be none) MUST be removed.

I'm dropping the "(though there should be none)" when proposing wording
for this change, since it's now more likely.

>> There is a separate but related question of whether, for the benefit of
>> legacy injecting and relaying agents, he might need to do something
>> about a Date header that had been rendered unusually stale because of
>> hiw own delay. Usepro-06 made some special provision for this, and I
>> think Usepro-07 does also. Normally, of course, Date should be left
>> strictly alone as being a matter to be determined by the Poster, but
>> one can hardly blame the Poster for subsequent delays caused by the
>> moderator.

> Yup.

And the current provision is also quoted above.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Sat, 21 Apr 2007 19:44:46 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I think we have now said everything that is to be said on this, so I
> have produced a summary of where I think we have got to.

Thank you very much for writing this up.

It's been a long time since the last message, so I'm going to quote
extensively to save people from having to refer back to the mailing list
archives.

> The following rules are mostly agreed (and indeed some are already in
> the present USEPRO). They are all included to give a complete
> picture. Note that these are indications of what is supposed to happen,
> and not wordings ready for use in the document.

> The chief issue is to choose between Rules IC and IR, for which the
> several "Good/Bad News" paragraphs need to be studied. Neither Rule is
> perfect. It is a question of whether a little pain should be endured for
> the benefit of an ultimate gain. In either case, the Sky will not Fall
> In - the worst is that an occasional article might be seen twice at some
> server.

> Posting agents:
> ---------------

> P1. MAY omit various headers from proto-articles (specifically Message-ID,
> Date, Path).

> P2. But should (with a small 's') not omit Date (because we are following
> the RFC 2822 idea that Date reflects time of composition).

>    NOTE P2: This practice is already widespread, and growing, but it works
>    against the man whose injections are significantly delayed after
>    composition time; hence P5 below.

> P3. MUST include Message-ID and Date if article is to be injected at
> multiple injecting agents (and the same at each injecting agent, of course).

> P4. MAY include Injection-Date indicating time of actual injection (as
> opposed to composition).

> P5. SHOULD/should include Injection-Date if injection time is significantly
> later than composition time.

>    Good News P5: A certain cure for the man with delayed injection problems;

>    Bad News P5: Posting agents tend not to get upgraded with such
>    new-fangled ideas until long after servers have adopted them. But at
>    least this man has a strong incentive to upgrade (once he is aware of the
>    possibility).

> P6. When injecting at multiple injecting agents, MUST include Injection-Date
> which MUST then indicate time of earliest injection at any such agent.

I agree with all of those statements.

> Injecting Agents:
> -----------------

> I1. MUST insert Date and Message-ID when absent and insert/extend PATH.

Agreed.

> I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*,
> X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject
> (reinjected) articles already containing those headers.

I believe that an injecting agent MUST reject an article that already has
an Injection-Info header and MAY reject an article that contains other
trace headers that it happens to recognize.  Removing headers or renaming
headers provided by a posting agent I believe is a SHOULD NOT.

So some disagreement here.

> I3. MUST/SHOULD insert Injection-Date when Injection-Date is absent AND
> (either Date OR Message-ID is absent).

>    NOTE I3: But see IC and IR below for further details.

> I4. MUST NOT insert (or alter or delete) Injection-Date if it is already
> present.

>    NOTE I4: That is to prevent re-acceptance problems arising from
>    unanticipated (and unpreventable) "leaks" between small private
>    networks and major networks such as Usenet. But see E1 for how a
>    gateway might do such tricks.

Agreed on these.

> We disagree on the following two possibilities:
 
> IC. Injecting agents MUST insert Injection-Date when it is absent
> (unless it is apparent that this is a reinjection).

>    Good News IC: This provides immediate beneffit to the posting agent
>    which has delayed injection, even if P5 is not implemented.

>    Bad News IC: Until multi-injecting sites can be assumed to have
>    implemented P6 this can cause re-acceptance of articles at later
>    relaying agents if one of the multi-injected versions suffers
>    substantial delay en route. So the existing behaviour is changed to
>    that extent.
 
> IR. Injecting agents MUST NOT insert Injection-Date if both (Date AND
>    Message-ID are already present).

>    Good News IR: Inverse of the Bad News IC.

>    Bad News IR: Posting agents with delayed injection see no benefit
>    unless/until they implement P5.

I think that's a fair summary of the options.

> Relaying and Serving Agents:
> ----------------------------

> R1. MUST discard incoming articles whose Injection-Date (or Date if
> Injection-Date is absent) predates the earliest articles of which it
> keeps record (or if more than 24 hours into the future, etc.).

> That "earliest articles of which it keeps record" might be reworded (see
> my reply to Frank on March 1st). The essential question is "if this
> article had arrived X days ago, would I still be recording that fact?" 
> (which allows for different retentions for different groups, etc). And
> maybe it records the time of arrival, or the original Date header, or
> whatever (about which I don't think we care).

Right.  I'm going to propose a new section that discusses how the history
file works and which should make all of this much clearer and more
straightforward.  There are a couple of standard ways of handling history
file entries, and we should probably just spell them out.

> Gateways:
> ---------

> And especially Gateways from one Netnews system A to another one B, in
> particular from small private one-node networks into Usenet:

> G1. MUST retain all headers as received (including in particular Date
> and Injection-Date), unless some EXCEPTION applies, as listed below.

> G2. MUST hand article to an injecting agent, or else perform all the
> duties on an injecting agent (except perhaps insertion of
> Injection-Date) themselves and then relay.

I would just say that they hand the article to an injecting agent, since
the second option there is just a special case of the first where the
injecting agent they use is built in to the gateway.

However, I think the best solution to this is, rather than tackling the
gateways section, to write a separate section about multiple injection to
replace the section about reinjection.  I'm going to take a crack at that
and see if I can come up with something that's fairly clear.

> EXCEPTIONs:
> -----------

> These are the tricky bits

> E1. An existing Injection-Date MAY be removed, but ONLY IF

> a) There is no possibility that another Gateway (direct or indirect)
> between those networks exists (which includes all manner of "leaks" by
> other nodes in A over which the gatewayer has no control).

> b) The article had not been previously gatewayed from B into A (i.e. it
> had been originally posted by a user of A).

>    NOTE: That covers the man who carries his private server around on a
>    laptop, and other users of suck/rpost, but if covers very little else.

>    NOTE: It is safer to allow gateways (which hopefully understand the
>    circumstances of the particular article) to do any tinkering with
>    Injection-Date than for injecting agents to do it; Hence Rule I4.

Yup, this seems right.

> E2. Other evidence of injection within network A (e.g. Injection-Info,
> NNTP-Posting-*, etc) MAY be removed, but ONLY IF

> a) The gatewaying is to use an injecting agent which would not otherwise
> allow reinjection.

>    NOTE: That screams of "cheating", "horrible hacking", etc. So be it.
>    Perhaps it is better not mentioned.

I don't believe injecting agents should ever allow reinjection, so I would
remove the conditional.  Otherwise, I agree.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: #1414: USEPRO 3.2.1: delimiter for multiple Path identities
Organization: The Eyrie
Date: Sat, 21 Apr 2007 19:33:15 -0700
Sender: [email-masked]

Harald Tveit Alvestrand <[email-masked]> writes:

> #1414: USEPRO 3.2.1: delimiter for multiple Path identities
>  No discussion
> #1415: USEPRO 3.2.1: Number of path entries per site
>  Discussion, but no proposed text.

Easy one first.  Here is my proposed text for #1414, which also addresses
part of Charles's concerns in #1415.  There hasn't been any subsequent
discussion of my original response to #1414, so I'm going to go with my
preferred option of MUST/SHOULD for "!" vs. "!!".

--- usepro.xml	2007-02-19 22:20:06.000000000 -0800
+++ usepro-1414.xml	2007-04-21 19:31:58.000000000 -0700
@@ -373,16 +373,21 @@
               specification will add only single "!" characters between
               &lt;path-identity> strings.</t>
 
-              <t>The agent MUST then prepend its own &lt;path-identity> to
-              the Path header field content.</t>
-
-              <t>The agent MAY then prepend additional &lt;path-identity>s
-              for itself to the Path header field content, following each
-              &lt;path-identity> so added with either "!!" or "!".  This
-              is permitted for agents that have multiple
-              &lt;path-identity>s (such as during a transition from one to
-              another).  Each of these &lt;path-identity>s MUST meet the
-              requirements set out in <xref target="path" />.</t>
+              <t>The agent MAY then prepend to the Path header field
+              content "!" or "!!" followed by an additional
+              &lt;path-identity> for itself other than its primary one.
+              Using "!!" is RECOMMENDED.  This step may be repeated any
+              number of times.  This is permitted for agents that have
+              multiple &lt;path-identity>s (such as during a transition
+              from one to another).  Each of these &lt;path-identity>s
+              MUST meet the requirements set out in
+              <xref target="path" />.</t>
+
+              <t>Finally, the agent MUST prepend its primary
+              &lt;path-identity> to the Path header field content.  The
+              primary &lt;path-identity> is the &lt;path-identity> it
+              normally advertises to its peers for their use in generating
+              &lt;path-diagnostic>s as described above.</t>
             </list>
           </t>
 
Here's the new text rendered:

   4.  The agent MAY then prepend to the Path header field content "!"
       or "!!" followed by an additional <path-identity> for itself
       other than its primary one.  Using "!!" is RECOMMENDED.  This
       step may be repeated any number of times.  This is permitted for
       agents that have multiple <path-identity>s (such as during a
       transition from one to another).  Each of these <path-identity>s
       MUST meet the requirements set out in Section 3.2.

   5.  Finally, the agent MUST prepend its primary <path-identity> to
       the Path header field content.  The primary <path-identity> is
       the <path-identity> it normally advertises to its peers for their
       use in generating <path-diagnostic>s as described above.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Organization: The Eyrie
Date: Fri, 20 Apr 2007 10:09:09 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> On the contrary, Russ has agreed, more or less, with the list of
> existing practices thst we need to accomodate, but clearly the present
> wording does not allow all of them (in particular, it seems not to allow
> MX records in any shape or form).

Sure it does.  Point 2 allows any DNS record or none at all.

> Moreover, Russ also agrees that mention needs to be made that will
> exclude bogus TLDs.

> I suggest we give Russ tiem to come back on some of these points.

I think the current wording is fine and already excludes bogus TLDs.  No
change required is my preferred resolution.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.usefor:24595
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 20 Apr 2007 13:09:50 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>I'm closing this item as "no change needed".

>Apart from Charles, there seems to be nobody asking for a change, and 
>several people have said that they are OK with the current wording.

On the contrary, Russ has agreed, more or less, with the list of existing
practices thst we need to accomodate, but clearly the present wording does
not allow all of them (in particular, it seems not to allow MX records in
any shape or form).

Moreover, Russ also agrees that mention needs to be made that will exclude
bogus TLDs.

I suggest we give Russ tiem to come back on some of these points.

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

Date: Wed, 18 Apr 2007 11:54:38 +0200
From: Harald Alvestrand <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
Cc: Usefor Mailing List <[email-masked]>
Subject: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

I'm closing this item as "no change needed".

Apart from Charles, there seems to be nobody asking for a change, and 
several people have said that they are OK with the current wording.

                 Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1416 Injection-Date - Summary of options
Date:  Tue, 17 Apr 2007 23:22:56 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Russ Allbery wrote:

> It's clear to me from the discussion that we need a couple new sections
> to the document that provide clearer guidance and descriptions of how
> the history mechanism works.

That's good news from my POV as somebody who wants to know "how
stuff works" without cheating like "get hold of a s-o-1036 copy".

> I think it's reasonable to let the article possibly end up duplicated
> in the bizarre case where the poster is multiply injecting and some
> sites have the group marked moderated and some marked unmoderated.

If that case is considered as "bizarre" please say so in the draft.
Maybe not literally, but the tendency should be clear for readers.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date - Summary of options
Organization: The Eyrie
Date: Tue, 17 Apr 2007 11:17:39 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I understand that Ruus has been tied up on other matters since then, but
> that he hopes to return to active participation shortly.

Yes, sorry.  That's still my plan, and responding to that message is near
the top of my priorities when I can find a bit of time again.

It's clear to me from the discussion that we need a couple new sections to
the document that provide clearer guidance and descriptions of how the
history mechanism works.

> So I think, in this case, the moderator MUST now discard any
> Injection-Date already provided, and then proceed to inject the Approved
> article in the normal manner, at which point he MAY then add an
> Injection-Date, and MUST add one if he is injecting at multiple sites.

Yup, that sounds right to me.  Good catch.  I think it's reasonable to let
the article possibly end up duplicated in the bizarre case where the
poster is multiply injecting and some sites have the group marked
moderated and some marked unmoderated.  Articles are occasionally
duplicated in similar cirumstances today.

> That will give the best chance of the article propagating normally, even
> if the moderator delayed before Approving it.

> There is a separate but related question of whether, for the benefit of
> legacy injecting and relaying agents, he might need to do something about
> a Date header that had been rendered unusually stale because of hiw own
> delay. Usepro-06 made some special provision for this, and I think
> Usepro-07 does also. Normally, of course, Date should be left strictly
> alone as being a matter to be determined by the Poster, but one can hardly
> blame the Poster for subsequent delays caused by the moderator.

Yup.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.usefor:24591
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date - Summary of options
Date: Tue, 17 Apr 2007 16:09:26 GMT
Lines: 92
Sender: [email-masked]

In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:

>I think we have now said everything that is to be said on this, so I have
>produced a summary of where I think we have got to.

>It lists rules for what various agents are supposed to do with
>Injection-Date in various situations. Most of these are, I think, agreed
>(and they differ quite a bit from our starting point in the two versions
>of USEPRO and in assumptions made at the start of this thread, so that at
>least indicates some progress).

I had hoped for some response to this, especially from Russ, particularly
as to whether the points I claimed to be "agreed" were in fact agreed.
That would then enable us to proceed to the main issue of disagreement:

>There still remains the two conflicting possibilities (labelled IC and IR
>in this summary) that we have to choose between, though I think we
>understand the consequences of each better than we did.

I understand that Ruus has been tied up on other matters since then, but
that he hopes to return to active participation shortly.

In the meantime, however, I have encountered one feature that we need to
look at further. In addition to delays caused by a poster who prepares his
article offline and then delays for some days before injecting it, there
is also the case where the poster injects his article promptly but,
because it is posted to a moderated group, the moderator may then delay
for several days before approving it.

>Posting agents:
>---------------

.....

>P4. MAY include Injection-Date indicating time of actual injection (as
>opposed to composition).

...........

>P6. When injecting at multiple injecting agents, MUST include Injection-Date
>which MUST then indicate time of earliest injection at any such agent.

But of course all those multiple injections will now end up being sent to
the same moderator, and the Injection-Date provided by the posting agent
(which usually would not be aware whether a particular group was moderated
or not) is largely meaningless.

I am assuming, of course, that if the 'moderator' is actually a team of
moderators with some bot to distribute articles amongst them, they will
have set up arrangements to ensure that a given article only gets approved
once.

>Injecting Agents:
>-----------------

......

>I4. MUST NOT insert (or alter or delete) Injection-Date if it is already
>present.

So I think, in this case, the moderator MUST now discard any
Injection-Date already provided, and then proceed to inject the Approved
article in the normal manner, at which point he MAY then add an
Injection-Date, and MUST add one if he is injecting at multiple sites.

That will give the best chance of the article propagating normally, even
if the moderator delayed before Approving it.

There is a separate but related question of whether, for the benefit of
legacy injecting and relaying agents, he might need to do something about
a Date header that had been rendered unusually stale because of hiw own
delay. Usepro-06 made some special provision for this, and I think
Usepro-07 does also. Normally, of course, Date should be left strictly
alone as being a matter to be determined by the Poster, but one can hardly
blame the Poster for subsequent delays caused by the moderator.

Apart from this one case, I think all the other rules listed in my
original message are unaffected.

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

To: [email-masked]
Xref: clerew local.usefor:24590
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Tue, 17 Apr 2007 11:14:00 GMT
Lines: 75
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Sorry to reply to this issue when I know that it's more important that I
>reply to other open issues, but I'm doing the bit of work I had a moment
>to do.  I'm hoping to find time to do the more extensive work needed on
>other fronts fairly soon, since I'm almost done with post-etch Debian
>work.

>My continued objection to being more explicit in various directions about
>the path hosts (either the proposal to be more specific about what FQDN
>means or to be more restrictive or explicit about how to set up DNS
>records) is three-fold:

> * It doesn't match existing practice.  In existing practice, it is common
>   for the Path header to be the FQDN of the news server (which is why
>   that's explicitly stated to be the preferred option in the current
>   draft), but failing that, there are a wide variety of practices.

Yes, though we might want tp prioritize them in some way (as indeed the
present wording does to a small extent).

> * Being more specific requires diving into DNS RRs to a degree that
>   quickly makes me uncomfortable.... All the proposed wording I've seen
>   so far doesn't deal directly with the question of CNAMEs.

I tend to assume that you just follow CNAMEs and then deal with whatever
they lead you to. Some past USEPRO drafts have said that explicitly, and
it could be put back in if wanted.

> * ...I don't believe that it is frequently necessary to try to construct
>   contact addresses from Path headers to reach intermediate sites, or
>   that when it is necessary it's particularly difficult under existing
>   practice (which doesn't require anything, really).

I think it needs to be done often enough that the facility needs to be
there. I agree that people familiar with the way things work can usually
figure out how to make contact with a given domain-name (and if you are
not familiar enough to do that, then you probably ought not to be trying
in the first place). RFC 2142 tried to provide a mechanism (and even has
pretensions to being a standard), but the trouble from a News POV is that
it was a bit TOO prescriptive of how Paths should look, which is why we
decided not to mention it normatively.

>I would prefer to stick with the simple language in the current draft,
>which represents existing practice except for stating that you can't just
>make up any random name you want, and you can't use an invalid TLD.

I think the problem with the present draft is that it is too specific
about some things, and too vague about others (though I am happy with the
clear distinction between FQDNs and <path-nodots> as covered with the
wording of #3). The more you say about what IS allowed, the more you
imply that possibilities not mentioned are NOT allowed.

So either the wording needs to be tightened up (the FQDNs MUST/SHOULD/MAY
resolve, in defined ways, to various desirable entities - hosts, servers,
administrators, responsible persons, whatever);

or else it needs to be loosened (it must be possible, by some means not
specified in detail, to derive pointers to various desirable entities -
hosts, servers, administrators, responsible persons, whatever).

I think we are agreed that what we do NOT want is some jumbled collection
of stuff that just happens for fit the syntax of a domain-name (like those
15 bogus tlds, for example).

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date:  Sat, 14 Apr 2007 12:54:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:

> What is an RP record?

"Responsible Person", RFC 1183 (2.2).  I'm puzzled by another
article in this thread about newsAexample.B.example, where
an A.example server uses for historic reasons a path identity
newsAexample.B.example

If it's not 100% clear (99.99% would be far too less) that 
A.example MUST immediately cease and desist to abuse names
below B.example as soon as B.example wishes that, and I mean
immediately, not tommorrow, then I second to add MUSTard to
the USEPRO or any other draft stating this as normative fact.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Organization: The Eyrie
Date: Fri, 13 Apr 2007 21:39:17 -0700
Sender: [email-masked]

Sorry to reply to this issue when I know that it's more important that I
reply to other open issues, but I'm doing the bit of work I had a moment
to do.  I'm hoping to find time to do the more extensive work needed on
other fronts fairly soon, since I'm almost done with post-etch Debian
work.

My continued objection to being more explicit in various directions about
the path hosts (either the proposal to be more specific about what FQDN
means or to be more restrictive or explicit about how to set up DNS
records) is three-fold:

 * It doesn't match existing practice.  In existing practice, it is common
   for the Path header to be the FQDN of the news server (which is why
   that's explicitly stated to be the preferred option in the current
   draft), but failing that, there are a wide variety of practices.  I
   think Charles's analysis supports that as well.  Discounting the bogus
   TLDs (which would not be acceptable under the new draft and I think
   rightfully so), over 11% of the <path-identity>s analyzed do not
   resolve.  I think that makes it fairly clear that requiring the Path
   identity to be a resolvable DNS entry is not existing practice.

 * Being more specific requires diving into DNS RRs to a degree that
   quickly makes me uncomfortable.  We get into A records vs. AAAA records
   vs. whatever someone comes up with later, discussion of the content of
   SOA records (I'd be hard-pressed to name any other protocol that cares
   about the contents of an SOA record outside of DNS itself), questions
   over whether MX records are okay (thereby potentially leading into
   questions about SRV records), etc.  All the proposed wording I've seen
   so far doesn't deal directly with the question of CNAMEs.  I think this
   is both complex and picky to specify and far outside the scope of the
   target audience of this specification, particularly given the third
   objection...

 * ...which is that, as pointed out by others, I'm hard-pressed to see how
   this matters enough to spend complexity and detailed specification on.
   I don't believe that it is frequently necessary to try to construct
   contact addresses from Path headers to reach intermediate sites, or
   that when it is necessary it's particularly difficult under existing
   practice (which doesn't require anything, really).  Mapping a news
   server to an organization is generally more than sufficient, and we're
   indicating a preference for putting the FQDN of the news server in the
   Path header.

I would prefer to stick with the simple language in the current draft,
which represents existing practice except for stating that you can't just
make up any random name you want, and you can't use an invalid TLD.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.usefor:24586
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 13 Apr 2007 16:22:06 GMT
Lines: 45
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>>>    2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
>>>        some SOA record) with the administrators of the agent (who could
>>>        then guarantee its uniqueness). For example, "server.example.org",
>>>        even if it had no DNS record of its own, would be covered by the
>>>        SOA record for "example.org".
>> 
>> I don't see an improvement. If A runs a news server, and for some reason 
>> has an unlisted name in the B.com domain, by agreement with the B.com 
>> administrators, there is absolutely no reason why our standards should 
>> specify that he can't, even though the SOA records for B.com mention 
>> nothing about A.
>> 

>Charles, we already understand your points.  Did you really think rewording 
>would help?

No, it is evident you do not understand them.

>If you want a real life case to show your wording is not an improvement, 
>consider what happens in a corporate merger.  The administrators of A could now 
>be responsible for keeping news.B.com running, but have no control over the DNS, 
>nor should they have to force all the peers to change to recognize a
>renamed news.B.com.

In that case (I am assuming A.com is the new name of the company, but it
is too much hassle to tell all their peers to recognize news.A.com), then
the proper course of action is for A to retain ownership of the domain
B.com (with at least an SOA record in place, even if nothing else).

Otherwise, some other body could now register the name B.com, and would
then expect to be able to use news.B.com for any purpose they saw fit. My
wording would disallow that.

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

To: [email-masked]
Xref: clerew local.usefor:24585
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 13 Apr 2007 16:13:52 GMT
Lines: 100
Sender: [email-masked]

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>As far as I can see, there is no support for your contention that we 
>need to do extra work to make a path-identity mailable.

>That means no support for extra text for recognizing the MX case either.

The conclusion of Issue "1093 was:

The USEPRO document will not say MUST or SHOULD about any of the addresses
"abuse@identity", "usefor@identity" or "news@identity".

That is a long way from saying "The USEPRO Document will actively prevent,
or hinder, the use of addresses such as "news@identity" etc." If you
list, as allowed <path-identity>s, only those domain names which resolve to
the IP address of a host, or do not resolve to anything but might be
"affiliated" to some higher domain (i.e. the present cases #1 and #2),
then you have outlawed the possibility of using a domain name that
resolves to just an MX, and which might then have been used to try to send
email to news@identity.

I have just examined some 1571 articles in which I found 565 distinct
<path-identity>s. Of these:

73 were <path-nodot>s (though that includes some <tail-entry>s)
492 were distinct domain-names (after following all CNAME pointers)

Of these 492 domain-names

   258 resolved to an A record only
   23  resolved to an MX record only
   135 resolved to both an A and an MX
   4   resolved just to an NS (not very useful)
   57  failed to resolve, but looked like an SOA record could be found (I
       didn't check)
   15  had apparently bogus TLDs

So it seems that MX records are in fairly widespread current use within
<path-identity>s and hence it would not be proper to exclude them, which
is what the present wording does. I am not asking for "extra work to make
a path-identity mailable" - I am just asking for existing practice to be
recognized.

>I am certainly against it.
> 
>>>  2.  A fully-qualified domain name (FQDN) within a domain affiliated
>>>       with the administrators of the agent and guaranteed to be unique
>>>       by the administrators of that domain.  For example, the
>>>       uniqueness of server.example.org could be guaranteed by the
>>>       administrator of example.org even if there is no DNS record for
>>>       server.example.org itself.
>>>     
>>
>> Well, you know I am not happy about that. But would it not be clearer (and
>> more accurate) to say that the FQDN must be within a zone whose SOA record
>> clearly identifies, or belongs to, the administrators of that domain (who
>> are then responsible for ensuring its uniqueness). I.e., if you start with
>> the FQDN and chop off components from the left, then you must assuredly
>> arrive eventually at an FQDN with an SOA record (and presumably also some
>> NS records and quite likely others records as well). For example:
>>
>>     2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
>>         some SOA record) with the administrators of the agent (who could
>>         then guarantee its uniqueness). For example, "server.example.org",
>>         even if it had no DNS record of its own, would be covered by the
>>         SOA record for "example.org".
>I don't see an improvement. If A runs a news server, and for some reason 
>has an unlisted name in the B.com domain, by agreement with the B.com 
>administrators, there is absolutely no reason why our standards should 
>specify that he can't, even though the SOA records for B.com mention 
>nothing about A.

But my wording does not "specify that he can't"; it merely requires that
the adminitrators of B.com take some responsibility for allowing A to use
their namespace.

>It's reasonable to ask that if you ask the administrators of B.com about 
>the name "AsNewsServer.B.com", they recognize the name as something 
>they've allowed to be used. (I'm not sure "affiliated" means exactly 
>that, but it can be stretched to that meaning, I think). But I don't see 
>a reason to ask them to put that in the SOA record.

Nobody is asking them to put anything different in the SOA record (in
fact, there is no mechanism whereby that could be done). In fact, my
wording does exactly what you suggest, but it also makes it absolutely
clear that those 15 bogus TLDs are out of order.

And s/affiliated/associated/ might be clearer in cases such as the one you
mentioned.

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

To: [email-masked]
Xref: clerew local.usefor:24587
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Fri, 13 Apr 2007 16:37:50 GMT
Lines: 51
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Alvestrand wrote:

>>> A fully-qualified domain name (FQDN) within a zone affiliated (by
>>> some SOA record) with the administrators of the agent (who could
>>> then guarantee its uniqueness). For example, "server.example.org",
>>> even if it had no DNS record of its own, would be covered by the
>>>  SOA record for "example.org".

>> I don't see an improvement. If A runs a news server, and for some
>> reason has an unlisted name in the B.com domain, by agreement with
>> the B.com administrators, there is absolutely no reason why our
>> standards should specify that he can't, even though the SOA records
>> for B.com mention nothing about A.

>Maybe that's not what Charles is talking about, and he simply wants
>"unique within the relevant zone".  Or "below the relevant SoA", if
>that's clearer.

Exactly. In particular, I want some assured method whereby, if a domain
name is used in a <path-identity>, you can use the DNS to identify someone
with responsibility for it. An SOA record is probably the last resort
(usually, by chopping off components from the left, you will probably find
something more convenient before you get that far).

>  As an example, I can't use news.xyzzy.claranet.de
>just because I think it's cute.  In theory there could be a real
>user "news.xyzzy" different from user "xyzzy", and in practice the
>A and MX for news.xyzzy.claranet.de have nothing to do with me, it's
>a wildcard. 

In theory yes, but I think you would be entitled to take a very dim view
if Claranet tried to create an A record for news.xyzzy.claranet.de without
some request from you beforehand.

>And it's an example why Charles' A, AAAA, or MX proposal would not 
>always do what he hopes.  It would also miss RP records.

What is an RP record?

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date:  Thu, 12 Apr 2007 16:26:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Sender: [email-masked]

Harald Alvestrand wrote:

>> A fully-qualified domain name (FQDN) within a zone affiliated (by
>> some SOA record) with the administrators of the agent (who could
>> then guarantee its uniqueness). For example, "server.example.org",
>> even if it had no DNS record of its own, would be covered by the
>>  SOA record for "example.org".

> I don't see an improvement. If A runs a news server, and for some
> reason has an unlisted name in the B.com domain, by agreement with
> the B.com administrators, there is absolutely no reason why our
> standards should specify that he can't, even though the SOA records
> for B.com mention nothing about A.

Maybe that's not what Charles is talking about, and he simply wants
"unique within the relevant zone".  Or "below the relevant SoA", if
that's clearer.  As an example, I can't use news.xyzzy.claranet.de
just because I think it's cute.  In theory there could be a real
user "news.xyzzy" different from user "xyzzy", and in practice the
A and MX for news.xyzzy.claranet.de have nothing to do with me, it's
a wildcard.  

And it's an example why Charles' A, AAAA, or MX proposal would not 
always do what he hopes.  It would also miss RP records.

Frank

Date: Thu, 12 Apr 2007 08:31:53 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

>>    2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
>>        some SOA record) with the administrators of the agent (who could
>>        then guarantee its uniqueness). For example, "server.example.org",
>>        even if it had no DNS record of its own, would be covered by the
>>        SOA record for "example.org".
> 
> I don't see an improvement. If A runs a news server, and for some reason 
> has an unlisted name in the B.com domain, by agreement with the B.com 
> administrators, there is absolutely no reason why our standards should 
> specify that he can't, even though the SOA records for B.com mention 
> nothing about A.
> 

Charles, we already understand your points.  Did you really think rewording 
would help?

If you want a real life case to show your wording is not an improvement, 
consider what happens in a corporate merger.  The administrators of A could now 
be responsible for keeping news.B.com running, but have no control over the DNS, 
nor should they have to force all the peers to change to recognize a
renamed news.B.com.  (If you still can't see the problem, know that in the real 
word there is a difference between "administrators of the agent" and 
"administrators of that domain.")

And, (not that it matters) "who could then guarantee its uniqueness" is a 
particularly bad wording, Charles.  It doesn't mean what you intended.
"could" is a statement of possibility, not a requirement in a standard.

But don't bother correcting it.

Date: Thu, 12 Apr 2007 09:39:31 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

As far as I can see, there is no support for your contention that we 
need to do extra work to make a path-identity mailable.

That means no support for extra text for recognizing the MX case either.

I am certainly against it.
 
>>  2.  A fully-qualified domain name (FQDN) within a domain affiliated
>>       with the administrators of the agent and guaranteed to be unique
>>       by the administrators of that domain.  For example, the
>>       uniqueness of server.example.org could be guaranteed by the
>>       administrator of example.org even if there is no DNS record for
>>       server.example.org itself.
>>     
>
> Well, you know I am not happy about that. But would it not be clearer (and
> more accurate) to say that the FQDN must be within a zone whose SOA record
> clearly identifies, or belongs to, the administrators of that domain (who
> are then responsible for ensuring its uniqueness). I.e., if you start with
> the FQDN and chop off components from the left, then you must assuredly
> arrive eventually at an FQDN with an SOA record (and presumably also some
> NS records and quite likely others records as well). For example:
>
>     2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
>         some SOA record) with the administrators of the agent (who could
>         then guarantee its uniqueness). For example, "server.example.org",
>         even if it had no DNS record of its own, would be covered by the
>         SOA record for "example.org".
I don't see an improvement. If A runs a news server, and for some reason 
has an unlisted name in the B.com domain, by agreement with the B.com 
administrators, there is absolutely no reason why our standards should 
specify that he can't, even though the SOA records for B.com mention 
nothing about A.

It's reasonable to ask that if you ask the administrators of B.com about 
the name "AsNewsServer.B.com", they recognize the name as something 
they've allowed to be used. (I'm not sure "affiliated" means exactly 
that, but it can be stretched to that meaning, I think). But I don't see 
a reason to ask them to put that in the SOA record.

                   Harald

To: [email-masked]
Xref: clerew local.usefor:24581
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Wed, 11 Apr 2007 17:24:05 GMT
Lines: 84
Sender: [email-masked]

In <08DBF8F69193F92ACDF00313@[192.168.1.108]> Harald Tveit Alvestrand <[email-masked]> writes:

>After having read 5 mails from Frank on the issue, I still am not sure 
>whether Frank supports adding it as a tracked issue or not.
>But we might as well get on with it.

>The issue concerns the following text in USEPRO-07:

I have had some further thoughts on this.

>   The <path-identity> used by an agent may be chosen via one of the
>   following methods (in decreasing order of preference):

Maybe s/may/SHOULD/

>   1.  The fully-qualified domain name (FQDN) of the system on which the
>       agent is running.

That seems to be only half the story. AIUI, normal current practice is to
provide either

a. An FQDN with an A or AAAA record that identifies the system like you
say, or

b. An FQDN with an MX record enabling email contact, but not identifying
the system, or even

c. An FQDN with both an A (or AAAA) -and- and MX (best of both worlds).

I don't think we want to express any preference between these, but
currently we don't seem to recognize case b at all. May I therefore
suggest:

    1.  A fully-qualified domain name (FQDN) resolving to either (or both)
        of
	   . an A or AAAA record identifying the system on which the agent
             is running;
           . an MX record enabling email contact with the administrators
             of that agent (e.g. using one of the role names suggested in
             [RFC 2142]).

{where "suggested" is about the weakest or various possible terms that
might be used there, and the reference to RFC 2142 is clearly just
informational}

>   2.  A fully-qualified domain name (FQDN) within a domain affiliated
>       with the administrators of the agent and guaranteed to be unique
>       by the administrators of that domain.  For example, the
>       uniqueness of server.example.org could be guaranteed by the
>       administrator of example.org even if there is no DNS record for
>       server.example.org itself.

Well, you know I am not happy about that. But would it not be clearer (and
more accurate) to say that the FQDN must be within a zone whose SOA record
clearly identifies, or belongs to, the administrators of that domain (who
are then responsible for ensuring its uniqueness). I.e., if you start with
the FQDN and chop off components from the left, then you must assuredly
arrive eventually at an FQDN with an SOA record (and presumably also some
NS records and quite likely others records as well). For example:

    2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
        some SOA record) with the administrators of the agent (who could
        then guarantee its uniqueness). For example, "server.example.org",
        even if it had no DNS record of its own, would be covered by the
        SOA record for "example.org".

>   3.  Some other (arbitrary) name in the form <path-nodot> believed to
>       be unique and registered at least with all the other news servers
>       to which that relaying agent or injecting agent sends articles.
>       This option SHOULD NOT be used unless the earlier options are
>       unavailable or unless the name is of longstanding usage.

And the wording of case #3 is fine as it stands.

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

To: [email-masked]
Xref: clerew local.usefor:24579
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Thu, 5 Apr 2007 11:32:56 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>I reread 2142, and see that it expects either #1 or the top level FQDN
>for the organisation (which #2 covers)

I don't think #2 covers 2142, because if it is neither an MX nor an A
record, then there is no way to send email to
abuse/news/postmaster/whatever @ it.

My main objection to #2 is that I regard it as a sloppy practice which I
don't want to legitimize (thus a guy who wants to do it has to bear the
stigma of breaking a SHOULD NOT - that does not mean the sky will fall
in).

>only the desperate look at the path ... everyone else looks at the
>injection info to find out who to talk to

Sure. You only want to mail someone in the middle of the Path is you want
to draw his attention to some technical problem at his site

>bottom line: I don't see a need for the SHOULD NOT, and I'm not deeply
>in favour of giving 2142 a plug.

I would only give it the mildest of plugs. For sure it would be
informative and not normative.

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

From: [email-masked] (Ralph Babel from the peanut gallery)
To: [email-masked]
Subject: Re: Count of senders to this mailing list
Date: Thu,  5 Apr 2007 10:14:37 +0200 (CEST)
Sender: [email-masked]

Harald Alvestrand wrote:

> It seems it's quiet here...

Usefor ain't dead; it just smells funny.

Date: Wed, 4 Apr 2007 11:48:22 -0400
From: Dan Schlitt <[email-masked]>
To: Harald Alvestrand <[email-masked]>
cc: Usefor Mailing List <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

I agree with Harald. In my experience running a news server only the
uniqueness of the names on the path was useful.

/dan

-- 

Dan Schlitt
[email-masked]

Date: Wed, 4 Apr 2007 13:46:20 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>>   The <path-identity> used by an agent may be chosen via one of the
>>   following methods (in decreasing order of preference):
>
>>   1.  The fully-qualified domain name (FQDN) of the system on which the
>>       agent is running.
>
>>   2.  A fully-qualified domain name (FQDN) within a domain affiliated
>>       with the administrators of the agent and guaranteed to be unique
>>       by the administrators of that domain.  For example, the
>>       uniqueness of server.example.org could be guaranteed by the
>>       administrator of example.org even if there is no DNS record for
>>       server.example.org itself.
>
>>   3.  Some other (arbitrary) name in the form <path-nodot> believed to
>>       be unique and registered at least with all the other news servers
>>       to which that relaying agent or injecting agent sends articles.
>>       This option SHOULD NOT be used unless the earlier options are
>>       unavailable or unless the name is of longstanding usage.
>
>>As far as I can tell, Charles is proposing that the second option should 
>>have a "SHOULD NOT be used" attached to it, just like the third.
>>As far as I can tell, Frank does not see a benefit to such a change.
>>No other people have contributed to this thread.

I reread 2142, and see that it expects either #1 or the top level FQDN
for the organisation (which #2 covers)

>More or less. I think I would rather combine #1 and #2 by saying that it
>SHOULD be a fully-qualified domain name (FQDN) resolvable, to
>MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing.

only the desperate look at the path ... everyone else looks at the
injection info to find out who to talk to

        X-Complaints-To: [email-masked]

because what people complain about is the injection of an article not
the fact that it has propagated.

Although there seems to be some feeling that people regularly want to
write to news servers in the middle of propagation paths in order to
discuss the mangling of articles (or some other wickedness), that
doesn't sound like the real world to me.  Those who chase down such
obscure things are probably capable of driving search engines,
corresponding with other Usenet administrators, and finding out who to
talk to by out-of-band techniques [which probably eschew role addresses
because getting things done means getting another specific sysadmin to
own the problem for you]

As Harald say, it's only uniqueness that matters to the protocol, and
being non-unique only damages you and your clone -- except in corner
cases where servers are downstream of a single major server...

>I accept that we are not going to make any normative statement regarding
>mail addresses to reach sites, but I would still like to see a NOTE
>pointing out the existence of RFC 2142, which implementors than then decide
>for themselves whether to follow. Something like:
>
>   NOTE: According to [RFC 2142], the forms "usenet@<path-identity>" and
>   "news@<path-identity>" are common addresses for a news server
>   administrator.

X-Trace and X-Complaints-To  arrived in INN pretty much the same time as
2142 came out...   which will be why 2142 documented the only method
widely available at that time...

bottom line: I don't see a need for the SHOULD NOT, and I'm not deeply
in favour of giving 2142 a plug.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

Date: Wed, 04 Apr 2007 08:06:04 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

I support no change required.

Date: Wed, 04 Apr 2007 13:45:08 +0200
From: Harald Alvestrand <[email-masked]>
To: Usenet <[email-masked]>
Subject: Count of senders to this mailing list
Sender: [email-masked]

I did a count of the senders to this mailing list today, over the last 
14 days.
It seems it's quiet here...

msgs since 21-Mar-2007
  1    9  40.91 "Charles Lindsey" <[email-masked]>
  2    8  77.27 Harald Tveit Alvestrand <[email-masked]>
  3    3  90.91 Frank Ellermann <[email-masked]>
  4    2 100.00 Harald Alvestrand <[email-masked]>

To: [email-masked]
Xref: clerew local.usefor:24573
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Date: Wed, 4 Apr 2007 10:34:49 GMT
Lines: 61
Sender: [email-masked]

In <08DBF8F69193F92ACDF00313@[192.168.1.108]> Harald Tveit Alvestrand <[email-masked]> writes:

>After having read 5 mails from Frank on the issue, I still am not sure 
>whether Frank supports adding it as a tracked issue or not.
>But we might as well get on with it.

>The issue concerns the following text in USEPRO-07:

>   The <path-identity> used by an agent may be chosen via one of the
>   following methods (in decreasing order of preference):

>   1.  The fully-qualified domain name (FQDN) of the system on which the
>       agent is running.

>   2.  A fully-qualified domain name (FQDN) within a domain affiliated
>       with the administrators of the agent and guaranteed to be unique
>       by the administrators of that domain.  For example, the
>       uniqueness of server.example.org could be guaranteed by the
>       administrator of example.org even if there is no DNS record for
>       server.example.org itself.

>   3.  Some other (arbitrary) name in the form <path-nodot> believed to
>       be unique and registered at least with all the other news servers
>       to which that relaying agent or injecting agent sends articles.
>       This option SHOULD NOT be used unless the earlier options are
>       unavailable or unless the name is of longstanding usage.

>As far as I can tell, Charles is proposing that the second option should 
>have a "SHOULD NOT be used" attached to it, just like the third.
>As far as I can tell, Frank does not see a benefit to such a change.
>No other people have contributed to this thread.

More or less. I think I would rather combine #1 and #2 by saying that it
SHOULD be a fully-qualified domain name (FQDN) resolvable, to
MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing.

That still leaves a chink for someone who convinces himself that his case
is extra special to violate that SHOULD.

>The discussion of mail addresses to reach sites remains #1093, and is not 
>part of this issue#.

I accept that we are not going to make any normative statement regarding
mail addresses to reach sites, but I would still like to see a NOTE
pointing out the existence of RFC 2142, which implementors than then decide
for themselves whether to follow. Something like:

   NOTE: According to [RFC 2142], the forms "usenet@<path-identity>" and
   "news@<path-identity>" are common addresses for a news server
   administrator.

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

Date: Wed, 04 Apr 2007 08:21:35 +0200
From: Harald Alvestrand <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
Cc: Usefor Mailing List <[email-masked]>
Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

My technical opinion (chair hat OFF):

The requirement on a path-identity is uniqueness only. Option 2 
guarantees uniqueness as well as option 1 does. Resolvability gives no 
extra value for the uniqueness requirement.

I support "no change required" as the resolution of this issue.

Harald

Harald Tveit Alvestrand wrote:
>
> After having read 5 mails from Frank on the issue, I still am not sure 
> whether Frank supports adding it as a tracked issue or not.
> But we might as well get on with it.
>
> The issue concerns the following text in USEPRO-07:
>
> The <path-identity> used by an agent may be chosen via one of the
> following methods (in decreasing order of preference):
>
> 1. The fully-qualified domain name (FQDN) of the system on which the
> agent is running.
>
> 2. A fully-qualified domain name (FQDN) within a domain affiliated
> with the administrators of the agent and guaranteed to be unique
> by the administrators of that domain. For example, the
> uniqueness of server.example.org could be guaranteed by the
> administrator of example.org even if there is no DNS record for
> server.example.org itself.
>
> 3. Some other (arbitrary) name in the form <path-nodot> believed to
> be unique and registered at least with all the other news servers
> to which that relaying agent or injecting agent sends articles.
> This option SHOULD NOT be used unless the earlier options are
> unavailable or unless the name is of longstanding usage.
>
> As far as I can tell, Charles is proposing that the second option 
> should have a "SHOULD NOT be used" attached to it, just like the third.
> As far as I can tell, Frank does not see a benefit to such a change.
> No other people have contributed to this thread.
>
> The discussion of mail addresses to reach sites remains #1093, and is 
> not part of this issue#.
>
> Harald (in role as issue tracker)
>
>

Date: Wed, 04 Apr 2007 06:31:00 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity
Sender: [email-masked]

After having read 5 mails from Frank on the issue, I still am not sure 
whether Frank supports adding it as a tracked issue or not.
But we might as well get on with it.

The issue concerns the following text in USEPRO-07:

   The <path-identity> used by an agent may be chosen via one of the
   following methods (in decreasing order of preference):

   1.  The fully-qualified domain name (FQDN) of the system on which the
       agent is running.

   2.  A fully-qualified domain name (FQDN) within a domain affiliated
       with the administrators of the agent and guaranteed to be unique
       by the administrators of that domain.  For example, the
       uniqueness of server.example.org could be guaranteed by the
       administrator of example.org even if there is no DNS record for
       server.example.org itself.

   3.  Some other (arbitrary) name in the form <path-nodot> believed to
       be unique and registered at least with all the other news servers
       to which that relaying agent or injecting agent sends articles.
       This option SHOULD NOT be used unless the earlier options are
       unavailable or unless the name is of longstanding usage.

As far as I can tell, Charles is proposing that the second option should 
have a "SHOULD NOT be used" attached to it, just like the third.
As far as I can tell, Frank does not see a benefit to such a change.
No other people have contributed to this thread.

The discussion of mail addresses to reach sites remains #1093, and is not 
part of this issue#.

                 Harald (in role as issue tracker)

To: [email-masked]
Xref: clerew local.usefor:24571
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: Possibility to use non-resolvable domain name as path-identity
Date: Mon, 2 Apr 2007 13:19:09 GMT
Lines: 40
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> And all I am asking is that it SHOULD resolve.

>For which query types (apart from soa and ns) ?  A type 99 record
>"v=spf1 -all" won't help for the purposes of news (in fact it would
>be very near to pointless without a corresponding SMTP server, MTAs
>can reject MAIL FROM:<[email-masked]> if
>there's no IP and no MX, without wasting time for SPF checks).

Even NS would be interesting, if there is nothing else.

>SRV or similar records could be interesting, if the "news-servers"
>at example.com wish to enumerate their hosts news17, etc.  That's
>only a future possibility mentioned in the "URI" I-D so far, and
>it's unrelated to any "SHOULD resolve (some query types TBD)".

>> Then if it doesn't, it immediately draws attention to itself as a
>> cause for suspicion.

>I don't recall a single case where I tried `nslookup -q=any` for a
>path identity, and I looked into the peering database a few times
>while trying to figure out path header fields.  Admittedly I'm more
>interested in mail abuse today.

Actually, I quite often use ANY (with 'dig' rather than 'nslookuop') when
I am not quite sure what I am looking for.

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