| Newsgroups |
gmane.ietf.usenet.format |
| Message-ID |
<[email protected]> |
"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?