"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:
Sure, but in practice if you want to check whether a message is the sameas 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?