Subject: Re: #1416

From: [email-masked]
Date: Thu, 7 Aug 2008 16:14:26 -0700 (PDT)

I don't think I understand the issue, because I don't see the reason for 
the exemption of "has date and message id" from insertion of Injection 
Date.

Russ writes:

* The Injection-Date feature will not realistically be able to be used to
   allow for articles with very old Date headers for the forseeable future,
   possibly ever.  It will require upgrading all servers to use
   Injection-Date rather than Date, which I think is very unlikely to
   happen.

Isn't the benefit of the Injection-Date header available to any server 
that is updated to read it, regardless of any other transport server? 
Those that do not read it will do nothing different; those that do can use 
it. It would be nice if all servers updated, but the benefits don't 
require it.

Also Russ:

* Given the very slow development pace of netnews software, I think
   backward compatibility should be our highest goal.

I don't see a backward compatibility issue. It appears that the issue 
involves "injection of an article with message id and date header", and 
the assumption that such an article is part of a multiple-injection set. 
What harm is there if an Injection-Date is added to such an article?

The comment about servers detecting duplicates by Injection-Date is 
confusing. Injection-Date isn't how duplicates are supposed to be 
detected. Yes, I see section 3.3 in the draft, but that section is 
incorrectly combining duplicate suppression and old-article prevention. An 
injection date of 20 days ago doesn't mean the article is a duplicate; it 
means the article is simply old. The assumption is that "older than 
history" means "appeared in history", which is not a bad assumption, but 
mixes two different issues.

An article with a Date header 20 days in the past and a current Injection 
Date is just as old, and 3.3 allows either or both to be used in rejecting
"duplicates". Un-updated servers will use Date. Updated servers should be 
using both. Problem solved.

Now, if a posting agent is handing an injection agent an article with a 
CURRENT date header and message id and is truly a delayed (by twenty 
days?) multiple injection attempt, the problem is a broken posting agent, 
and leaving out the Injection Date header is not going to assist anyone in 
rejecting the article. If it has an old date header, then that date can be 
used under 3.3 just as the Injection Date can. A current date and current 
injection-date would still require a history of the message id to be 
branded a duplicate.

As a side note, I'm a bit dissappointed that IETF will grab an unfinished 
work and publish it as the product of this group, as if it were the 
completed, consensus product. If a group cannot reach consensus on a 
draft, and simply stops working on it (as this group appears to have), 
then the product is not ready for publication.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 07 Aug 2008 18:31:05 -0700

> the exemption of "has date and message id" from insertion of Injection

Briefly: the Message-ID plus the Date is the unique identifier for the
message.  If you allow an injecting agent to change one or the other (and
adding an Injection-Date is effectively changing the Date), you break
uniqueness.  This creates the possibility of duplicates.

In this case, the scenario under which duplicates arise is possible but
unlikely.  It requires, if I remember correctly, badly-timed multiple
injection of the message such that it expires on the basis of its original
Date and is then reaccepted on the basis of the modified Injection-Date.

> that is updated to read it, regardless of any other transport server?

Assuming that the message ever gets to you, yes.  However, unless enough
other servers implement Injection-Date to allow flood-fill to reach you, a
message that benefits from this feature won't get to you for you to be
able to benefit.

> incorrectly combining duplicate suppression and old-article prevention.
> An injection date of 20 days ago doesn't mean the article is a
> duplicate; it means the article is simply old. The assumption is that
> "older than history" means "appeared in history", which is not a bad
> assumption, but mixes two different issues.

Our protocol, as currently documented in -10, contains nothing about old
article prevention except at the injecting agent point (see below).  There
are no requirements that relaying agents or serving agents reject old
articles, only a requirement that servers reject articles that they've
already seen.

Date or Injection-Date is a way to avoid having to keep perpetual history
to satisfy this requirement.

Individual sites can of course reject old articles, as well as anything
else they don't want to carry, but it's not a protocol requirement.  The
only protocol function (from a USEPRO, not a USEFOR, perspective) of the
Date and Injection-Date header is to enable the normal history mechanism
to function.

> An article with a Date header 20 days in the past and a current
> Injection Date is just as old, and 3.3 allows either or both to be used
> in rejecting "duplicates". Un-updated servers will use Date. Updated
> servers should be using both. Problem solved.

If updated relaying or serving agents use both when both are present, it
completely defeats the point of having Injection-Date and we should just
remove it.  If that's the implication that you got from 3.3, the wording
is buggy.  That was supposed to be covered by this:

   (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.)

implying that if Injection-Date is present, Date is ignored.

Injection agents are encouraged to check for stale Dates due to the
problem of silent discards of those messages from un-updated agents, but
the threshold they use is expected to be long enough that articles with
less stale Dates may still potentially benefit from Injection-Date at
later points in their propagation.

> days?) multiple injection attempt, the problem is a broken posting
> agent, and leaving out the Injection Date header is not going to assist
> anyone in rejecting the article.

Yes.  This isn't the scenario.

> As a side note, I'm a bit dissappointed that IETF will grab an
> unfinished work and publish it as the product of this group, as if it
> were the completed, consensus product. If a group cannot reach consensus
> on a draft, and simply stops working on it (as this group appears to
> have), then the product is not ready for publication.

I generally agree with this.  I'm not willing to see -10 published; the
current text is not a particularly useful direction to go, and I think we
reached a consensus on that a long time ago.

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

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 7 Aug 2008 18:53:32 -0700

On Aug 7, 2008, at 4:14 PM, [email-masked] wrote:

> unfinished work and publish it as the product of this group, as if  
> it were the completed, consensus product. If a group cannot reach  
> consensus on a draft, and simply stops working on it (as this group  
> appears to have), then the product is not ready for publication.

I would be happy to hear arguments that the current draft is worse  
than the RFC it would replace.  If there is consensus around that  
point then I'd retract my promise to process the document by the end  
of the month.  However, I'd still close the WG as there has been no  
progress for so long.

The WG came to consensus around most of the latest I-D with the  
exception of issue #1416, and partial consensus is not the same as no  
consensus when we look at the whole document.  Recall that even if an  
incomplete revision is made RFC, it can itself be replaced by another  
RFC.  Perfection is never attainable, mere improvement is often  
helpful, and the process is iterative.

Lisa

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Aug 2008 12:25:24 GMT

>uniqueness.  This creates the possibility of duplicates.

Which is, of course, why we REQUIRE people doing multiple injections to
insert all these things themselves before injecting any of them.

>Date and is then reaccepted on the basis of the modified Injection-Date.

It requires the badly timed events to cause arrival at some site within the
critical 24 hours mentioned in the text, having failed to flood around the
site that introduced the delay. Moreover, the duplicate copies that a user
at that site sees will only differ in the presence of an Injection-Date in
the one, but not in the other. The full scenario is explained in
http://www.imc.org/ietf-usefor/drafts/issue-1416.

>message that benefits from this feature won't get to you for you to be

The benefit of Injection-Date is that a badly delayed article is more
likely to reach you, assuming you and your upstreams have taken advantage
of it, of course. I think you are more likely to get that benefit if the
disputed sentence is omitted.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Aug 2008 11:52:09 GMT

>helpful, and the process is iterative.

I think you need the various changes that Russ has recently put before us,
including the resolution to #1416. I.e., it is better with that text in
whether the sentence that I want removed is removed or not, though
obviously I prefer it with the sentence removed.

---

From: Ralph Babel <[email-masked]>
Date: Sat, 9 Aug 2008 23:08:53 +0200 (CEST)

Lisa Dusseault wrote:

> I would be happy to hear arguments that the current
> draft is worse than the RFC it would replace.

*sigh* ... not _again_.

> If there is consensus around that point
> then I'd retract my promise to process
> the document by the end of the month.

I thought consensus was required to _publish_ an RFC, not
to keep a half-baked document from being advanced to RFC
status more or less by accident or general lack of interest.

Let the mailing-list archives and the drafts serve
as a memorial of what happens when you don't keep
idiots with a political agenda out of a technical WG.

> However, I'd still close the WG as there
> has been no progress for so long.

About time.

| Goals and Milestones:
|
| Apr 97      Identify areas where updates required and write
|             draft standards for inclusion in the main document.
|
| May 97      Produce a revised internet-draft
|             of the Usenet Article Standard.
|
| May-Sep 97  Produce further drafts as needed.
|
| Oct 97      Submit the revised Usenet Article Standard
|             to the IESG for Proposed Standard status

<[email-masked]>