Subject: #1416 Injection-Date: proposed diff

From: Russ Allbery <[email-masked]>
Date: Mon, 16 Jul 2007 13:45:35 -0700

It's been a while since we discussed this, so here again is my current
proposed diff.  If there are parts of this we can agree on independently,
I can start merging it into the main draft.

--- usepro.xml	2007-07-01 19:38:06.000000000 -0700
+++ usepro-1416.xml	2007-07-16 13:43:23.000000000 -0700
@@ -18,6 +18,8 @@
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
   <!ENTITY rfc3629 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
+  <!ENTITY rfc3798 PUBLIC '' 
+    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3798.xml'>
   <!ENTITY rfc3977 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3977.xml'>
   <!ENTITY rfc4234 PUBLIC '' 
@@ -165,8 +167,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
@@ -452,6 +455,66 @@
         </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>Alternatively, agents MAY drop history records according to
+            the date when the article was first seen by that agent rather
+            than the date of the article.  In this case, the history
+            retention interval MUST be at least 24 hours longer than the
+            cutoff interval to allow for articles dated in the future.
+            This interval matches the allowable error in the date of the
+            article (see <xref target="injecting" />).</t>
+          </list>
+        </t>
+
+        <t>These are just two implementation strategies for article
+        history, albeit the most common ones.  Relaying and serving agents
+        are not required to use these strategies, only to meet the
+        requirement of not accepting an article more than once.  However,
+        these strategies are safe and widely deployed and implementors are
+        encouraged to use one of them, especially if they not have
+        extensive experience with Netnews and the subtle effects of its
+        flood-fill algorithm.</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
@@ -459,9 +522,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 any Injection-Info
+        header field; this header field will be added by the injecting
+        agent.</t>
+
+        <t>If the proto-article already 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 submitted 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 allow the Date header field to
+        hold the composition date (as recommended 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 hence may
+        suffer poorer propagation.</t>
 
         <t>Contrary to <xref target="RFC2822" />, which implies that the
         mailbox or mailboxes in the From header field should be that of
@@ -484,48 +571,73 @@
           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 for
+          redundancy, for example), a posting agent may wish to offer the
+          same article to multiple injecting agents.  In this unusual
+          case, the goal is to not create multiple independent articles
+          but rather to inject the same article at multiple points and let
+          the normal duplicate suppression facility of Netnews (see <xref
+          target="history" />) ensure that any given agent accepts the
+          article only 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 as 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 gatewaying,
+          after the fact, articles found on one Netnews network to
+          another, supposedly unconnected one).  In this case, the posting
+          agent MUST convert the article back into a proto-article before
+          passing it to another injecting agent, but it MUST retain
+          unmodified the Message-ID, Date, and Injection-Date header
+          fields.  It MUST NOT add an Injection-Date header field if it is
+          missing from the existing article.  It MUST remove any Xref
+          header field and either rename or remove any Injection-Info
+          header field and other trace fields.
+            <list style="empty">
+              <t>NOTE: 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,
+              unintended repeat injection into the same network, and other
+              problems.  It 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>
+            </list>
+          </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 to be posted and has an Approved header field (see <xref
+          target="moderator" />).  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">
@@ -650,23 +762,27 @@
 
             <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>
-
-            <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>
+            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 (see, for example, <xref
+            target="RFC3798" />).  It MAY reject any proto-article that
+            contains trace header fields (e.g., NNTP-Posting-Host)
+            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 Injection-Date or 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 Injection-Date header field is too far in the
+            past (older than the cutoff interval of a relaying agent the
+            injecting agent is using, for example).  It SHOULD similarly
+            reject any article whose Date header field is too far in the
+            past, since not all news servers support Injection-Date and
+            only the injecting agent can provide a useful error message to
+            the posting agent.  In either case, 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
@@ -710,8 +826,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
@@ -806,18 +928,18 @@
             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 accepted.
+            If it implements the mechanism described in <xref
+            target="history" />, this means that it MUST reject any
+            article whose date falls outside the cutoff interval since it
+            won't know whether such articles had been accepted previously
+            or not.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -891,16 +1013,16 @@
 
             <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>
-
-            <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>
+            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 accepted.
+            If it implements the mechanism described in <xref
+            target="history" />, this means that it MUST reject any
+            article whose date falls outside the cutoff interval since it
+            won't know whether such articles had been accepted previously
+            or not.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1008,8 +1130,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"
@@ -2042,6 +2163,7 @@
       &rfc1036;
       &rfc2045;
       &rfc2606;
+      &rfc3798;
       &rfc3977;
       <reference anchor="USEAGE">
         <front>

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Jul 2007 10:14:59 +0200

I'll take this by section, since I'm not in a position to comment on the 
whole block in one go...

Speaking as a contributor:
I like the text of the history section, and think that we should just 
declare it "text accepted".

> +++ usepro-1416.xml	2007-07-16 13:43:23.000000000 -0700
Nit: this doesn't seem to take a position on whether it's the same 
posting agent doing the multiple injection or different posting agents; 
I suggest adding ", by one or several posting agents" if this is what we 
think is intended.
>          converts them to messages of some other kind (such as <xref
nit: "not have" - > "do not have".

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 18 Jul 2007 15:04:18 GMT

>I can start merging it into the main draft.

Yes, large chunks of this are fine, though I have a few nits (see later).

The main outstanding matter is Issue #1416, which I shall now try to
summarize as I see it.

Essentially, we have to choose between two options, which we have in the
past named "IR" and "IC". The current text reflects IR. The differences
relate to when an Injection-Date header MUST/MUST NOT/Whatever be added by
Posting and Injection agants.

Option IR
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
Message-ID _and_ Date present						YES
Message-ID or Date or both absent					???

[Where I believe "???" should be "YES", but text doesn't actually say so]

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
Message-ID _and_ Date present				YES
Message-ID or Date or both absent		YES

Option IC
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
All other cases (Message-ID or Date or neither)				YES

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
All other cases (Message-ID or Date or neither)	YES

Discussion of IR
----------------

The essential difference is the rule that Injecting agents MUST NOT add
Injection-Date if _both_ Message-ID and Date are already present, and MUST
add it otherwise. This rule is counter-intuitive and confusing.

A consequence of the rule is that it will forever remain the case that
some articles will never acquire an Injection-Date (those where the
Posting agent provides both of Message-ID and Date).

Russ counters this by claiming that, in time, Posting agents will learn to
add the Injection-Date themselves, but this is only a "MAY" as specified,
and I remain unconvinced that implementors will take the hint.

So if we decide to remain with Option IR, I would want to see a much
stronger wording in place of that "MAY" (not necessarily a "SHOULD", but
some indication that it was intended to become standard practice).

Moreover, there is a danger that Posting agent implementors will do it
wrongly, adding the Injection-Date _before_ they are sure they have a
working connection to an Injecting agent. Yes, multiple injectors have to
get this right, but people doing multiple injection can be expected to
have a higher level of "clue".

Discussion of IC
----------------

We distinguish between "OLD" agents which are unaware of our new standard,
and "NEW" agents which implement it as written.

The following scenario, which I understand to be the case Russ is worried
about, illustrates the problem with IC. If anyone knows of a different, or
a simpler, scenario that exhibits the same problem, then please speak up.

Day 0	OLD Posting agent P composes an article (with Date: Day0) and some
	Message-ID. P is in the habit of multi-injecting.
Day 1	P injects the message to (OLD or NEW) Injecting agent A (the ACopy).
Day 2	P injects the message to NEW Injecting agent B (the BCopy); B adds
	Injection-Date: Day2.
meanwhile:
Day 1	The ACopy propagates rapidly and arrives at NEW Serving agent C,
	which stores it and puts it in its history file (which it
	normally retains for 7 days).
Day 2	The BCopy arrives at Relaying agent D, which promptly breaks and goes
	offline for 7 days (or otherwise causes that propagation delay).
Day 8	C removes the ACopy from its history file.
Day 9	D wakes up, embarks on a massive catchup, and releases the BCopy.
Day 9	The BCopy arrives at C, which observes that it is (just) within 7
	days of its Injection-Date, and so accepts and stores it again.

	Which is, of course, a Bad Thing. C's users will say "Didn't I
	already see that article last week?" But it is no worse than that;
	in particular, I cannot see any way that looping could arise.

Observe that this Bad Thing would not have happened if:
	. B had been an OLD agent
	. C had been an OLD agent
	. P had been a NEW agent
	. The delay at D had been 1 day less
	. The delay at D had been 1 day more

So yes, the Bad Thing would not have happened on the current network, and
it will not happen when the whole network is NEW - so it is a transitional
problem whilst OLD and NEW agents are still around. Moreover, you might
think the whole scenario is somewhat artificial (hence the invitation to
propose more realistic scenarios).

So the choice you people have to make is between this possible, but rare,
Bad Thing, and the counter-intuitive properties of option IR.

The following are the paragraphs relating to this issue, and which would
need changing if we move to Opion IC. ALso a few nit-fixes in some of
them.

>+        header fields, posting agents MAY add an Injection-Date header
                                           ^
                       , as part of the injection process,
>+        proto-article to an injection agent.

That is where I don't see why they MAY add it only if both Message-ID and
Date are present (see "???" above). What harm arises, even in IR, if they
are allowed to add it anyway?

>+        ...... They SHOULD do so if the
                      ^^
              They MUST do so if
>+        one injecting agent, see <xref target="multi-injection" />.</t>

Yes, that last MUST is redundant, but the point is important and
you have a similar redundancy when discussing proto-articles further on.

>+          Injection-Date header fields, and the proto-article as offered
                                                        ^^^^^^^
                                                        articles

>+          header field and other trace fields.

Technically, that is what we used to call "reinjection". Now it is called
"Gatewaying after the fact", which is a bit of a mouthfull. Neither term
really indicates that the person/entity doing it may be completely unaware
that either multiple- or re-injection is taking place. Also, I am not sure
that "converting it back into a proto-article" is quite what is happening.
What is important is that any Message-ID, Date and Injection-Date MUST
stay, and any Xref and Injection-Info MUST go.

Also, it is not clear what is to happen to any Path. My preference would
be to leave it (see discussion of this further down), or otherwise to
rename it.

>+            won't know whether such articles had been accepted previously

Those are the texts relevant to the IR/IC issue. Here now are my remaining
nits - mostly typos or minor wording suggestions, although there is a
smallish issue related to POSTED in the Path header.

                                                   ^
                                                  the
>+        article from multiple other news servers....
>+
>+          <list style="symbols">
                                                          ^^^
                                                         might
>+            article it had not yet seen, so it ought not be aggressively
                                                          ^
                                                          to
>+            short....

>+        encouraged to use one of them, especially if they not have
                                                           ^
                                                           do
>+        extensive experience with Netnews and the subtle effects of its
                                                ^^^
                                            with the more

                                          ^^^^^^^
                                       is only to be
>+        <xref target="RFC2822" />), even if the proto-article is not
                                                                      ^
                                                                    to be
>+        injected for some time after its composition....

I would prefer a "SHOULD NOT contain a "POSTED" &lt;diag-keyword>". No
interoperability arises if a "POSTED" appears twice in a Path, though it
may well be a cause for suspicion, and even for over-zealous agents to
reject it.

It can arise in the following circumstances:

1. As a result of "reinjecting " (aka "gatewaying after the fact").
2. In some forms of multiple injection, notably when one of the
"injections" is technically a relaying, using IHAVE. Such multiple
injection would indeed violate one of your SHOULDs, but SHOULD violations
are going to happen from time to time (and sometimes for good reason).
3. When some s[pc]ammer has preloaded the Path in order to disguise the
true origin of the article (indeed, this was one of the original purposes
for inventing POSTED). A pretty stupid s[pc]ammer, or course (competent
ones will just post from alt.net :-) ).

Generally, I prefer to preserve all evidence from earlier Paths, for the
netkops to interpret as they will (whether or not this results in multiple
POSTEDs). Alternatively, I might be persuaded that we should recommend
renaming earlier Paths, as we do for pre-existing Injection-Infos.

>+          of the proto-article.  See <xref target="multi-injection" />.</t>

That is the place I mentioned earlier where you already have a redundant
MUST for Injection-Date. Fine, it helps make things clearer.

>+          <t>Under some circumstances (posting to multiple disjoint
                                                            ^
                                                        supposedly
>+          same article to multiple injecting agents. ....

>+          moderated newsgroups in its Newsgroups header field SHOULD only
                                                                ^^^^^^^^^^^
                                                                SHOULD ONLY
>+          be done by a moderator and MUST only be done after the
                                       ^^^^^^^^^
                                       MUST ONLY
>+          proto-article is approved for all moderated groups to which it
                          ^^
                      has been
>+          target="moderator" />)....

I would prefer POSTED to be in the "SHOULD reject"s, for reasons already
stated above.
>+
>+            ...  It SHOULD similarly

That SHOULD is better than the MUST that was present in earlier drafts. I
would still be happier with a MAY.

>+            If it implements the mechanism described in <xref
                               ^^^^^^^^^^^^^
                          one of the mechanisms

-- 
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]>
Date: Wed, 25 Jul 2007 14:38:13 -0700

> declare it "text accepted".

That would make my life much easier.  I'd like us to just do that as
well.

> I suggest adding ", by one or several posting agents" if this is what we

That's the intention here.  I've changed my text accordingly.

> nit: "not have" - > "do not have".

Fixed in my draft.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 25 Jul 2007 15:01:47 -0700

Trying to fix tab damage here.  Please don't use tabs for column alignment
because quoting throws off the alignment and changes the meaning of the
original message.

>                                               MUST    MUSTNOT SHOULD  MAY
> Multiple injection (also requires Msgid & Date)YES

> [Where I believe "???" should be "YES", but text doesn't actually say so]

The text was intended to only permit adding an Injection-Date header if
Message-ID and Date are both present.  The posting agent can either add
all three or omit Injection-Date; anything else would be rather bizarre.

The *ideal* case when no multiple injection is involved is for the posting
agent to not provide any of those headers and let the injecting agent take
care of it, since the headers added by the injecting agent are likely to
be of higher quality.  But that feels like USEAGE material to me.

Does this need to be further clarified in the proposed text?  I guess
nothing explicitly says to not add Injection-Date unless you're also
adding Message-ID and Date, even though the MAY phrasing strongly implies
it.  This is fallout from changing things around so that posting agents
can add it at all.

> Message-ID or Date or both absent             YES

Correct.

Snipping the rest of this discussion since I think we're just repeating
the same arguments in different words.  The other nits I'll get in the
next post.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 25 Jul 2007 15:32:13 -0700

> are allowed to add it anyway?

The language is written as it is because it's written from the perspective
of establishing a unique identity for the article and that can't be done
without the Message-ID header anyway.  Thinking of an article with
Injection-Date and not Message-ID is rather weird to me, but I can't think
of any specific *problems* it would cause.  It's similar to an article
with Date but no Message-ID today.

Adding Injection-Date when there's no Date header is just bizarre and
strange, since it means that one is not trying to use the "time of
composition" semantics of Date and it baffles me why they wouldn't just
let the injecting agent add the headers.  Here I similarly can't put my
finger on any harm, but even more so than the Message-ID case, it's a
remarkably strange thing to do and I can't figure out why anyone would
want to do that or what meaningful semantics it would express.

I guess I'm not sure the right thing to say here.

> you have a similar redundancy when discussing proto-articles further on.

Agreed.  Changed in my draft.

>>+          to each injecting agent MUST be identical.</t>

Intentionally not plural because they're identical and hence there is only
one proto-article.

> that either multiple- or re-injection is taking place.

How could you not be aware that multiple injection is taking place?  Some
agent involved in the process clearly *does* know this unless the multiple
injection is being done manually by a human, in which case the *human*
knows this.  You're starting with an existing news article rather than
with a blank screen and an editor; that's a pretty obvious difference.

Whatever agent that is that knows this is going on is responsible for
doing the right thing in conjunction with the posting agent doing the
work.

> Also, I am not sure that "converting it back into a proto-article" is
> quite what is happening.  What is important is that any Message-ID, Date
> and Injection-Date MUST stay, and any Xref and Injection-Info MUST go.

Which makes it a proto-article.  I phrase it that way because I want to be
very clear that any constraints expressed in the Proto-articles section
apply to the resulting article.

> be to leave it (see discussion of this further down), or otherwise to

I agree that this isn't clear.  I think I'm convinced that we can drop the
restriction on POSTED keywords in Path in proto-articles, but I'd like
other members of the working group to weigh in on that.

>>+        articles in which each news server offers articles it accepts to

Changed.

>>+            to propagate through the network, the agent may reject an

Changed.

>>+            article it had not yet seen, so it ought not be aggressively

I think this is an English style difference.  I believe the current text
is correct, and adding "to" seems less correct to me.

The wording is a little awkward, though, but the rephrasings occuring to
me are even more cumbersome.

>>+        encouraged to use one of them, especially if they not have

Changed (I think someone else had already caught that).

>>+        flood-fill algorithm.</t>

I don't see how that's an improvement.  The nouns joined with that
conjunction seem brief enough to me to not warrant repeating the
preposition.

>>+        header field; this header field will be added by the injecting

As much as I prefer to avoid using lowercase may, "may only" seems way
clearer here to me than either "will be" or "is only to be".  Changed
accordingly.

>>+        injected for some time after its composition....

Changed.

> may well be a cause for suspicion, and even for over-zealous agents to

I think SHOULD NOT is the worst thing we could say here; I think it should
either be MUST NOT so that parsers can rely on one and only one POSTED
diag, or we should remain quiet on it entirely and allow multiple POSTED
diags and expect people to do the right thing.  SHOULD NOT leaves the
matter ambiguous for everyone and seems like a breeding point for later
arguments.

I'm leaning towards the latter, since otherwise we have to tell people to
throw out trace information that could help catch loops.

> POSTEDs).

Yup.

>>+          <t>Under some circumstances (posting to multiple disjoint

Well, no, if the networks weren't disjoint, the posting agent wouldn't
need to offer the same article to multiple injecting agents.  This
parenthetical is talking about the motivations, not the problems.

Instead, I added this to the end sentence of that paragraph and now have:

          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 accepts the article only once, even if
          supposedly disjoint networks have unexpected links.</t>

>>+          moderated newsgroups in its Newsgroups header field SHOULD only

SHOULD ONLY and MUST ONLY are not RFC 2119 keywords, and hence I don't
capitalize the only.

>>+          target="moderator" />)....

Changed.

>>+            If it implements the mechanism described in <xref

Changed in both places.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 25 Jul 2007 19:07:12 -0500

--On 25. juli 2007 15:32 -0700 Russ Allbery <[email-masked]> wrote:

>> really indicates that the person/entity doing it may be completely
>> unaware that either multiple- or re-injection is taking place.
>

In the "gatewaying" case, the guy that does the second injection knows that 
multiple injection is taking place. The guy (process, human or exotic) 
doing the first injection may or may not know.

                    Harald

---

From: Russ Allbery <[email-masked]>
Date: Wed, 25 Jul 2007 17:10:56 -0700

> In the "gatewaying" case, the guy that does the second injection knows
> that multiple injection is taking place. The guy (process, human or
> exotic) doing the first injection may or may not know.

Oh.  Yes.  That I agree with.  That's why there shouldn't be any special
requirements placed on the first injector for this case.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 26 Jul 2007 12:12:16 GMT

>the same arguments in different words.  The other nits I'll get in the

Yes, the main point of my message was to set out the differences between
options IR and IC, and the arguments in favour of each.

If we can agree that I have stated the issues correctly, then Harald can
proceed to a head count.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 26 Jul 2007 12:09:14 GMT

>with Date but no Message-ID today.

Which is actually quite common. The injection agent creates the Message-ID
(which is can probably do more reliably than poorly configured user
agents, which have been known to create message-ids with "@localhost" in
them).

>want to do that or what meaningful semantics it would express.

Yes, I agree that Injection-Date without Date would be totally bizarre,
but if it does no harm then there is no point in wording to forbid it,
which means people just start wondering why you did so. So it is better to
say

   "Posting agents MAY, as part of the injection process (i.e. immediately
   before passing that proto-article to an injection agent), add an
   Injection-Date header field to that proto-article (though it would be
   unusual to do so if Date and Message-ID fields were not also being
   provided)."

Generally speaking (especially if we say with option IR) we should be
encouraging posting agents to take advantage of this new "MAY" feature,
and unnecessary "small print" will just put them off.

Of course we all agree that it MUST be done in the case of multiple
injection.

>Intentionally not plural because they're identical and hence there is only

But two "offerings".

Hmmm! It just seems an odd piece of English to say "a single-object ...
MUST be identical".

>with a blank screen and an editor; that's a pretty obvious difference.

Small local networks with more than one site tend to be run in an
amateurish fashion. So the second guy, who caused the extra "leak", may
have been badly configured, or ignorant, or both. One of the benefits of
encouraging the first guy to include an Injection-Date and forbidding
anyone anywhere ever to remove it is that such leaks will do less harm.

So the wording you have written in entirely correct, but I am not sure it
is enforceable.

>apply to the resulting article.

Yes, but are there any particular constraints you have in mind here,
bearing in mind that your wording has already overridden the usual
proto-article constraints of all (well nearly all) of the headers which
are mentioned in the Proto-articles section?

>matter ambiguous for everyone and seems like a breeding point for later

OK, I am happy with a weaker wording than "SHOULD", all the way down to no
wording at all.

>Yup.

Then maybe a NOTE somewhere to the effect that multiple POSTEDs may
sometimes be seen and that they cause no harm but may serve as an
indication of some unusual behaviour or malpractice.

>          supposedly disjoint networks have unexpected links.</t>

OK.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 26 Jul 2007 09:26:09 -0700

> If we can agree that I have stated the issues correctly, then Harald can

Other than the minor notes that I posted, it seemed correct to me.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 26 Jul 2007 12:35:19 -0400

> Hmmm! It just seems an odd piece of English to say "a single-object ...

I think it should be reworded to avoid the clumsiness.

In the first it reads "SHOULD" be offering the same proto article.
The second sentence says "proto-article as offered MUST be identical."

So which is it?  SHOULD or MUST?

I personally, say MUST.  If you can't offer the same proto-article,
then you are reposting, not multi-injecting.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 26 Jul 2007 09:48:28 -0700

> So which is it?  SHOULD or MUST?

It's talking about two different things.  The structure of the section
goes like:  You SHOULD use simultaneous injection of the same article
rather than transforming an already-injected article back to a
proto-article and injecting it again.  If you do use simultaneous
injection, here's how you MUST do it.  If you instead do the latter,
here's how you MUST do it.

Alternative wording suggestions welcome.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 27 Jul 2007 13:34:46 GMT

>The second sentence says "proto-article as offered MUST be identical."

Yes, as Russ has said, that SHOULD is to discourage some more preculiar
ways of doing multiple injection.

For example, all my own articles are first injected to my own private news
server. Then they are relayed (using IHAVE) to a site that has agreed to
peer with me (but which is shambolically managed). Then, after a short
interval to allow it to propagate, I inject it again to a site with which
I do not have a peering arrangement using POST (well, I actually use IHAVE
because that site implements the INN option of allowing IHAVE to be used
for injection, but it is still an injection).

So I would technically be breaking that first SHOULD, and at some stage I
will have to consider whether to continue doing that, and what to do with
any Injection-Date header that I create.

There are also various other weird and wonderful ways that SHOULD might be
ignored - some of them quite sensible and some of them not.

>then you are reposting, not multi-injecting.

Yes, that is rather the point I was making. Russ has removed the term
"reinjection" from the draft and left us with the mouthful "multiple
injection after the fact". His wording is technically correct (with MUST
in all the right places), but maybe it could be reviewed.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 27 Jul 2007 09:20:22 -0700

> in all the right places), but maybe it could be reviewed.

I'm okay with reintroducing the term.  I mostly took it out as part of
incorporating Harald's way of viewing the situation, which I found
clearer, but I may have gone too far that direction.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 29 Jul 2007 18:52:33 -0700

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

>> The language is written as it is because it's written from the
>> perspective of establishing a unique identity for the article and that
>> can't be done without the Message-ID header anyway.  Thinking of an
>> article with Injection-Date and not Message-ID is rather weird to me,
>> but I can't think of any specific *problems* it would cause.  It's
>> similar to an article with Date but no Message-ID today.

> Which is actually quite common. The injection agent creates the
> Message-ID (which is can probably do more reliably than poorly
> configured user agents, which have been known to create message-ids with
> "@localhost" in them).

Yeah, and the agent may want to allow for an injecting agent that doesn't
create Injection-Date.  Okay, that makes sense.

> which means people just start wondering why you did so. So it is better
> to say

>    "Posting agents MAY, as part of the injection process
>    (i.e. immediately before passing that proto-article to an injection
>    agent), add an Injection-Date header field to that proto-article
>    (though it would be unusual to do so if Date and Message-ID fields
>    were not also being provided)."

> and unnecessary "small print" will just put them off.

That sounds fine to me.  I now have:

        <t>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 a Date header field
        (representing the composition time of the proto-article) is
        present in the proto-article and is more than a day in the past at
        the time of injection.  They MUST do so if the proto-article is
        being submitted to more than one injecting agent; see <xref
        target="multi-injection" />.</t>

I don't think we need to say that it's unusual, but I can add that if need
be.

>> How could you not be aware that multiple injection is taking place?
>> Some agent involved in the process clearly *does* know this unless the
>> multiple injection is being done manually by a human, in which case the
>> *human* knows this.  You're starting with an existing news article
>> rather than with a blank screen and an editor; that's a pretty obvious
>> difference.

> have been badly configured, or ignorant, or both.

Right, but either it's a normal relaying agent to relaying agent
connection that leaks, or he knew he was reinjecting.  He may not know how
to configure it properly.

> One of the benefits of encouraging the first guy to include an
> Injection-Date and forbidding anyone anywhere ever to remove it is that
> such leaks will do less harm.

This I do agree with.

> So the wording you have written in entirely correct, but I am not sure
> it is enforceable.

The person who takes an existing news message and reposts it is the person
who needs to take the necessary precautions, because they're the person
doing something outside of the regular Usenet protocol.  However, I do
agree that it makes sense to make the whole system more robust against
people who do that without knowing what they're doing.

>> Which makes it a proto-article.  I phrase it that way because I want to
>> be very clear that any constraints expressed in the Proto-articles
>> section apply to the resulting article.

> are mentioned in the Proto-articles section?

I don't override them, just restate them (I think).  No, I don't have any
others in mind.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 30 Jul 2007 11:56:03 GMT

>clearer, but I may have gone too far that direction.

OK, let me encourage you to have a close look at that section with a view
to clarifying it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 30 Jul 2007 11:54:31 GMT

>to configure it properly.

Suppose the local network has some local.* groups which all participants
are instructed not to let leak to the outside Usenet.

So our amateurish guy implements this by configuring that all bona-fide
Usenet groups are to be relayed/injected as the case may be, but carefully
omits the local.* groups from his list. And for months and months that
works fine, so the guy believe he is configured just fine.

Then, one day, someone elsewhere on the local network writes an article
crossposted to local.misc and comp.misc - well you can see what happens
then, and two versions of the article running around Usenet is one
possible outcome.

{Just as an aside, there are actually two top level hierarchies on Usenet
known as "man.*. One is the University of Manchester, and the other is the
University of Manitoba. Both hierarchies have groups called
man.cs.general, and occasionally we used to see articles from the "wrong"
hierarchy for just that reason. I had some discussion with the Newsmaster
at Manitoba, and we agreed there was nothing much to be done about it, and
that such occasional insights into the "other" culture might even be
beneficial.}

---

From: Russ Allbery <[email-masked]>
Date: Mon, 30 Jul 2007 09:32:56 -0700

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

> Usenet groups are to be relayed/injected as the case may be, but
> carefully omits the local.* groups from his list. And for months and
> months that works fine, so the guy believe he is configured just fine.

> then, and two versions of the article running around Usenet is one

So he still knows he's reinjecting (or not) and therefore his software
still handles Injection-Date properly unless his software has been broken
all along for comp.* as well.

I'm still not seeing your point.  He still always knows when he's
reinjecting and therefore has an opportunity to do the right thing by the
protocol.  I'm not arguing that things never leak; I know that they do.
Only that anyone who is doing reinjection *knows* they're doing
reinjection, even if they're confused over which articles they're
reinjecting.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 31 Jul 2007 11:38:40 GMT

>all along for comp.* as well.

No, he thinks he is just relaying an article to comp.misc.

Yes, if his software knows that a pre-existing Injection-Date is NEVER to
be removed or altered, then no harm will arise. And since that is a matter
for the software implementor rather than a matter locally configurable,
he is unlikely to make that mistake (unless he starts hacking the source
code).

Moreover, no existing implementation is going to remove that
Injection-Date, because no existing implementation is even aware that
header exists. So I think the rules as you have written cover all the
possibilities fine.

I have just checked my own 'sys' file, and indeed the problem cannot arise
with, for example, the man.* groups I mentioned, some of which I keep on
my machine. But I can also see how a 'sys' file could easily be
misconfigured so that it happened.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 31 Jul 2007 11:00:06 -0700

>> still handles Injection-Date properly unless his software has been
>> broken all along for comp.* as well.

> No, he thinks he is just relaying an article to comp.misc.

Not if he's using POST he doesn't, and if he's not using POST, he's not
reinjecting.  (Barring configurations that use IHAVE for injection in
intentional violation of a SHOULD NOT in RFC3977, at which point they're
on their own in getting the details right because that's why the standard
says you shouldn't do that.  And at that point, the server accepting the
IHAVE has to take responsibility for ensuring the right thing happens
because the client can no longer indicate the difference between relaying
and the injection of an article.)

If he's using POST with an article that he didn't just prepare from
scratch with a posting agent, he's reinjecting.  It's unambiguous as to
whether you're reinjecting or relaying, and I don't see how one could
possibly create a situation where one is accidentally reinjecting without
being aware it's happening (only scenarios where the articles being
reinjected are other than was intended).

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Tue, 31 Jul 2007 11:00:06 -0700
Sender: [email-masked]

>> still handles Injection-Date properly unless his software has been
>> broken all along for comp.* as well.

> No, he thinks he is just relaying an article to comp.misc.

Not if he's using POST he doesn't, and if he's not using POST, he's not
reinjecting.  (Barring configurations that use IHAVE for injection in
intentional violation of a SHOULD NOT in RFC3977, at which point they're
on their own in getting the details right because that's why the standard
says you shouldn't do that.  And at that point, the server accepting the
IHAVE has to take responsibility for ensuring the right thing happens
because the client can no longer indicate the difference between relaying
and the injection of an article.)

If he's using POST with an article that he didn't just prepare from
scratch with a posting agent, he's reinjecting.  It's unambiguous as to
whether you're reinjecting or relaying, and I don't see how one could
possibly create a situation where one is accidentally reinjecting without
being aware it's happening (only scenarios where the articles being
reinjected are other than was intended).

To: [email-masked]
Xref: clerew local.usefor:24729
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Tue, 31 Jul 2007 11:38:40 GMT
Lines: 46
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Mon, 30 Jul 2007 09:32:56 -0700
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:24727
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Mon, 30 Jul 2007 11:56:03 GMT
Lines: 26
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:24726
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Mon, 30 Jul 2007 11:54:31 GMT
Lines: 51
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Sun, 29 Jul 2007 18:52:33 -0700
Sender: [email-masked]

This I do agree with.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Fri, 27 Jul 2007 09:20:22 -0700
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:24723
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Fri, 27 Jul 2007 13:34:46 GMT
Lines: 53
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Thu, 26 Jul 2007 09:48:28 -0700
Sender: [email-masked]

Date: Thu, 26 Jul 2007 12:35:19 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Thu, 26 Jul 2007 09:26:09 -0700
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:24719
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Thu, 26 Jul 2007 12:12:16 GMT
Lines: 22
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:24718
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Thu, 26 Jul 2007 12:09:14 GMT
Lines: 194
Sender: [email-masked]

But two "offerings".

OK.

Date: Thu, 26 Jul 2007 00:22:28 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, LEMONADE WG <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>, SIMPLE WG <[email-masked]>
Subject: Mailing List Last Call for 2822 update internet-draft
Sender: [email-masked]

There have been some comments on draft-resnick-2822upd-* but they have
dwindled down to none.

This is a "formal" Mailing List Last Call on
draft-resnick-2822upd-02.txt. The last call will last for two weeks
time, ending on August 10, 2007.

The document will be discussed on the 822 mailing list,
<[email-masked]>. Please send your comments there.

For a copy of the current draft, you can find it at

	http://www.ietf.org/internet-drafts/draft-resnick-2822upd-02.txt
or
	http://tools.ietf.org/html/draft-resnick-2822upd

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	[email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Wed, 25 Jul 2007 17:10:56 -0700
Sender: [email-masked]

Date: Wed, 25 Jul 2007 19:07:12 -0500
From: Harald Tveit Alvestrand <[email-masked]>
To: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Sender: [email-masked]

                    Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Wed, 25 Jul 2007 15:32:13 -0700
Sender: [email-masked]

Changed.

Changed.

Changed.

Yup.

Changed.

Changed in both places.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Wed, 25 Jul 2007 15:01:47 -0700
Sender: [email-masked]

Correct.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: History section (Re: #1416 Injection-Date: proposed diff)
Organization: The Eyrie
Date: Wed, 25 Jul 2007 14:38:13 -0700
Sender: [email-masked]

Fixed in my draft.

To: [email-masked]
Xref: clerew local.usefor:24711
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1416 Injection-Date: proposed diff
Date: Wed, 18 Jul 2007 15:04:18 GMT
Lines: 399
Sender: [email-masked]

Option IR
---------

						MUST	MUSTNOT	SHOULD	MAY

						MUST	MUSTNOT	SHOULD	MAY

Option IC
---------

						MUST	MUSTNOT	SHOULD	MAY

						MUST	MUSTNOT	SHOULD	MAY

Discussion of IR
----------------

Discussion of IC
----------------

                                           ^

                      ^^
              They MUST do so if

                                                        ^^^^^^^
                                                        articles

                                                   ^
                                                  the
                                                          ^^^
                                                         might
                                                          ^
                                                          to

                                                           ^
                                                           do
                                                ^^^
                                            with the more

                                          ^^^^^^^
                                       is only to be
                                                                      ^
                                                                    to be

                                                            ^
                                                        supposedly

                                                                ^^^^^^^^^^^
                                                                SHOULD ONLY
                                       ^^^^^^^^^
                                       MUST ONLY
                          ^^
                      has been

 

                               ^^^^^^^^^^^^^
                          one of the mechanisms

Date: Tue, 17 Jul 2007 10:14:59 +0200
From: Harald Alvestrand <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: History section (Re: #1416 Injection-Date: proposed diff)
Sender: [email-masked]

>          poster in creating a valid proto-article and forwarding it to an

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Mon, 16 Jul 2007 13:45:35 -0700
Sender: [email-masked]

 

 

 

 

 

 

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1416 Injection-Date: current wording proposal (corrected)
Organization: The Eyrie
Date: Mon, 16 Jul 2007 13:41:57 -0700
Sender: [email-masked]

>>I now have:

>>            <t>It MUST reject any article that has already been accepted.
>>            If it implements the mechanism described in <xref
>>            target="history" />, this means that it MUST reject any
>>            article whose date falls outside a cutoff interval since it
>                                               ^
>                                              the
>>            won't know whether such articles had been accepted or not.</t>
>                                                                ^
>                                                          earlier/previously

Change made in my version.

Date: Mon, 16 Jul 2007 22:28:07 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-ietf-usefor-usepro-08.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090503090101070906090609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This draft has been published.

Barring further debate, I'm closing all issues where text was proposed 
in -08.
I'll send out an updated issues list later.

             Harald

--------------090503090101070906090609
Content-Type: message/rfc822;
 name="I-D ACTION:draft-ietf-usefor-usepro-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-ietf-usefor-usepro-08.txt"

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usepro-08.txt 
Date: Tue, 03 Jul 2007 19:15:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Architecture and Protocols
	Author(s)	: R. Allbery, C. Lindsey
	Filename	: draft-ietf-usefor-usepro-08.txt
	Pages		: 49
	Date		: 2007-7-3
	
This document defines the architecture of Netnews systems and
   specifies the correct manipulation and interpretation of Netnews
   articles by software which originates, distributes, stores, and
   displays them.  It also specifies the requirements that must be met
   by any protocol used to transport and serve Netnews articles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-usefor-usepro-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--------------090503090101070906090609--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usepro-08.txt 
Date: Tue, 03 Jul 2007 19:15:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Architecture and Protocols
	Author(s)	: R. Allbery, C. Lindsey
	Filename	: draft-ietf-usefor-usepro-08.txt
	Pages		: 49
	Date		: 2007-7-3
	
This document defines the architecture of Netnews systems and
   specifies the correct manipulation and interpretation of Netnews
   articles by software which originates, distributes, stores, and
   displays them.  It also specifies the requirements that must be met
   by any protocol used to transport and serve Netnews articles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-usefor-usepro-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun,  1 Jul 2007 19:38:15 -0700 (PDT)
Sender: [email-masked]

    Date: Sunday, July 1, 2007 @ 19:38:14
  Author: eagle
Revision: 3041

Update date of the draft.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2007-07-02 02:36:42 UTC (rev 3040)
+++ docs/usefor/usepro.xml	2007-07-02 02:38:14 UTC (rev 3041)
@@ -62,7 +62,7 @@
       </address>
     </author>
 
-    <date month="January" year="2007" />
+    <date month="July" year="2007" />
 
     <area>Applications</area>
     <workgroup>Usenet Format Working Group</workgroup>

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun,  1 Jul 2007 19:35:37 -0700 (PDT)
Sender: [email-masked]

    Date: Sunday, July 1, 2007 @ 19:35:34
  Author: eagle
Revision: 3038

Update I-D file name.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2007-07-01 19:27:55 UTC (rev 3037)
+++ docs/usefor/usepro.xml	2007-07-02 02:35:34 UTC (rev 3038)
@@ -26,7 +26,7 @@
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
 ]>
 
-<rfc ipr="full3978" docName="draft-ietf-usefor-usepro-07" obsoletes="1036"
+<rfc ipr="full3978" docName="draft-ietf-usefor-usepro-08" obsoletes="1036"
      category="std">
   <front>
     <title>Netnews Architecture and Protocols</title>