Re: #1416

[Russ Allbery <[e-mail]>]

[e-mail] writes:

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

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.

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

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.

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

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.

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

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 ([e-mail])             <http://www.eyrie.org/~eagle/>