Re: #1416

[stanley@xxxxxxxx]

Russ Allbery <rra@xxxxxxxxxxxx>:

> Briefly: the Message-ID plus the Date is the unique identifier for the
> message.

I'm with Frank in being confused by this statement. According to USEFOR:

   A "message identifier" (Section 3.1.3) is a unique identifier for an
   article, usually supplied by the "user agent" that posted it or,
   failing that, by the "news server".  It distinguishes the article
   from every other article ever posted anywhere.  Articles with the
   same message identifier are treated as if they are the same article
   regardless of any differences in the body or header fields.

This clearly states that two articles with the same message id, even with 
different dates, are the same article. "Every article ... ever". If you 
say that "message id plus date" is the unique identifier, then you are 
saying that two messages with different dates but identical message ids 
are two different messages -- a violation of the definition of message id.

> If you allow an injecting agent to change one or the other (and
> adding an Injection-Date is effectively changing the Date),

It does not change the Date header.

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

If a message is expired based on the Date header, why would the server 
then accept the same article with the same Date header later? If it does,
it's just going to expire it again. This just doesn't make sense. It 
sounds too much like a bug and not a feature.

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

So the benefit you see is that articles with really old dates will still 
be propogated, even though the date indicates that the message predates 
the start of a local history file and thus the article is assumed to have 
been seen already?

> Our protocol, as currently documented in -10, contains nothing about old
> article prevention except at the injecting agent point (see below).

By assuming "old date" (defined as "prior to oldest local history file 
entry") means "has already been seen", section 3.3 does implicitly deal
with old article rejection. Not an important point, but still true.

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

Yes, by assuming that "old" means "already seen". Only then can you say 
that not finding a message id in the history means that you've already 
seen the article, when normally not finding the message id means you 
haven't seen it yet.

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

Some headers, sometimes, serve more than just a "protocol function from a 
USEPRO perspective". I see value in Injection-Date as a record of when the 
article was injected versus when it was written.

For that reason, I think I have to object to the exclusion statement and 
require injecting agents to put in an Injection-Date header unless that 
header is already there, without regard to existing message id or date 
headers.