Re: #1416

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.