Subject: Re: #1416

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

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Sure, but in practice if you want to check whether a message is the same
>as some other ancient message, it is much simpler to have a "date" as 
>well,
>so you can just say "this is so stale that I shall assume it is a
>duplicate and ignore it anyway".

Yes, just like I already said, you reject it because it is too old, with 
the ASSUMPTION that "too old" means you've already seen it.

The only information you can get from the Date is the age of the article. 
You cannot get anything about whether it is a duplicate or not.

Our working group defined the message id and the message id alone as the 
globally, forever unique identifier for a message.

Perhaps we truly do need a statement to that effect somewhere in the 
draft, if even Charles is confused by the difference between "date prior 
to earliest history entry" and "duplicate". The assumption results in 
treating the article as if the two were the same, but they really are 
different cases.

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

>If you now have both Date and Injection-Date headers, then which is the
>true "date" for the purposes of the test above?

If a server yesterday looks at the Date header and deletes the message 
(expiration), and today it gets the same message with the same Date header 
and accepts it, it is broken. It is ridiculous to accept articles that are
just going to be deleted in the next expiration pass. I don't know if 
server authors actually considered that when they wrote their code, but it 
seems like a useful optimization. "Don't accept things older than I'm 
already expiring..."

That server is looking at the Date header, not the Injection Date. That's 
why I wrote "If a message is expired based on the Date header...". It 
doesn't matter what you think the "true" date is. Hint: how do you have a 
"modified Injection Date" if there was no Injection Date to start with?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Aug 2008 11:12:38 GMT

>seems like a useful optimization. "Don't accept things older than I'm 

Yes, but the whole point of Injection-Date is that NEW servers use it when
deciding whether to consider it stale. That way an article that was
injected 24 hours after it was composed has an extra 24 hours before it
gets considered stale, thus improving its chances of propagation.

The (slight) downside of that is that NEW servers can be hoodwinked in
some highly peculiar scenarios such as the one I showed (but it wouldn't
happen anymore once all the OLD servers had been pensioned off).

-- 
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: "Frank Ellermann" <[email-masked]>
Date: Sat, 16 Aug 2008 00:15:22 +0200

Charles Lindsey wrote:

> it wouldn't happen anymore once all the OLD servers had been
> pensioned off

I'd agree with anybody claiming that our chances that this ever
happens are somewhere between limited and lousy.  But I think
we should stick to the vision that it *could* happen, because
changing the Injection-Date course midway between usefor-usefor
and usefor-usepro is messy.

There was a reason why Russ proposed this header field, we had
a conflict with the RFC 2822 Date semantics, and we decided to 
emulate the slightly different Netnews semantics with the new
Injection-Date.

If folks want to revert that decision let them do it later in
the successors of usefor-usefor and usefor-usepro.  But *that*
would be a discussion which I'd try to avoid, WG or elsewhere.

 Frank