Re: #1416

[Russ Allbery <rra@xxxxxxxxxxxx>]

stanley@xxxxxxxx writes:

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

I really think the confusion here is just my unfortunate summary; there is
probably no simple way to talk about this.  From the rest of your message,
you understand what's going on, so we're not really disagreeing.  I think
the best thing to do at this point is to just ignore anything I write in
e-mail that's confusing in favor of paying attention to the language in
the current I-D, since that's all that really matters anyway.

If the language in the current I-D is still confusing, please someone
write something better and I'll incorporate it.  Or, for that matter, pick
up as editor; I'm happy to step down in favor of someone else who has more
time and energy to try to explain all of this.  I'm pretty burned out.

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

Becuase of the added Injection-Date header with a newer Date, which
overrides the article's Date header for this purpose.

> If it does, it's just going to expire it again.

Most servers expire based on arrival time, not based on the Date header.
There are various internal data structure reasons why this is often
easier, plus it's arguably a more correct user experience.  See the third
bullet point in the history section in the current draft for the technical
details.

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

Correct.  That's the intended benefit of Injection-Date.

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

Right.  But it only does so in a context of not accepting articles that
were already accepted, not in a broader sense of rejecting articles with
old dates only because they have old dates.

I agree that in practice with most servers using the typical history
mechanism, the distinction is purely academic.

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

Exactly.  I don't think we're disagreeing here.

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

Right, that's why I worded it that way.  The header serves other purposes
outside of the USEPRO context.

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

Okay.

You, Harald, and Charles feel that way by my current count, with Forrest,
myself, and Dan on the other side.  I'm not sure which way Frank is
leaning.

Given that the people who want Injection-Date to always be added feel
strongly about it and given that the circumstances when this fails are
obscure, maybe the best approach is to just go forward with always adding
Injection-Date.  As discussed in other threads, I'd really like to
finalize this and get it out the door before we all burn out completely
and never publish anything, and either is a significant improvement over
RFC 1036.

-- 
Russ Allbery (rra@xxxxxxxxxxxx)             <http://www.eyrie.org/~eagle/>