Re: #1416: USEPRO 3.9: Reinjection and Injection-Date

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Russ Allbery wrote:

> if we want to use the normal arrival-based expiration, we need to
> require it somewhere.

Or allow it somewhere.  I don't get the difference if articles older
than "X" determined by a header field are anyway rejected as too old.

> For example, we're theoretically breaking our uniqueness model with
> multiple injection a minute apart.  This opens the door to duplicates.
> However, to get a duplicate in practice, the later copy of the article
> would have to arrive less than a minute after the earlier copy had
> expired, something that in practice is hideously unlikely.

Hitting one critical minute of 4321 for 4320=3*24*60 isn't impossible,
but finding a route to this server needing 3 days might be difficult.

> If we disallow late injection in general, both injection and reinjection,
> then we don't need Injection-Date.

Yes, but that's not realistic.  Users can poll their server, and then go
offline for some time creating articles with different days, waiting in
their outbound for better times.  Then they go online again and try to
post their articles.  That's one scenario where Injection-Date could be
better than Date.

Another scenario is a xyz2news gateway where the xyz comes with a Date,
but may take some time (fido2news, mail2news).  It's then desirable to 
preserve the original Date.  Unless there's another xyz2news gateway
injecting the same article with a very different earlier Injection-Date.

Either I'm too clumsy to get this right, or both USEPRO drafts don't
discuss the function of a history file yet.  S-o-1036 9.2 explains how
that's supposed to work, proposing a minimum of N = 7 days for "seen",
with a Date older than now - N considered as "stale".

If it's really not yet there USEPRO needs a similar section with the
same RECOMMENDED N = 7 days minimum.

> I think Injection-Date introduces more problems than it solves and
> the complexity isn't worth it.

The reinjection part was somewhat odd, I never got it.  Based on your
explanation I finally begin to understand the USEPRO-06 idea.  Your
proposal to treat reinjection as special case of gatewaying offered a
way to ignore these oddities.

But the underlying concepts (history + dupes + late injection) have
to be clear.  Going back to no Injection-Date doesn't help for late
injections, and that's no irrelevant corner case like reinjection.

>> How many posters per day on Usenet will be posting days later than
>> authoring?  

Poll Friday, write Saturday, and inject Monday could be a plausible
scenario.  The USEFOR decision to stick to RFC 2822 where that's at
all possible was intentional.  2822 defines:

 The origination date specifies the date and time at which the creator
 of the message indicated that the message was complete and ready to
 enter the mail delivery system.  For instance, this might be the time
 that a user pushes the "send" or "submit" button in an application
 program.  In any case, it is specifically not intended to convey the
 time that the message is actually transported, but rather the time at
 which the human or other creator of the message has put the message
 into its final form, ready for transport.  (For example, a portable
 computer user who is not connected to a network might queue a message
 for delivery.  The origination date is intended to contain the date
 and time that the user queued the message, not the time when the user
 connected to the network to send the message.)

However s-o-1036 states:

 The Date header contains the date and time when the article was 
 submitted for transmission

That's obviously incompatible, and the reason why USEFOR adds the new
beast Injection-Date for the function related to history files.  Just
removing Injection-Date would also cause havoc for combined UAs (mail
or news), implementors can't get incompatible Date semantics right...
or maybe they could, but they won't bother, and that's the problem.
 
> I think that if we're introducing Injection-Date, we need to provide
> a transition during which it's clear that Injection-Date still isn't
> going to be a panacea, and in that transition period, I don't think
> we're doing posters any favors accepting articles that most people
> will keep ignoring.

If injecting agents behave like relaying agents, and use the Date as
surrogate for the missing Injection-Date, then they'll reject a Date
older than N = 7 days.  That should work to some degree.  Or there's
a smaller window, less than N days, for this purpose.  Declaring when
the transition period is finished is the job for another draft in the
late 40s of this century.  Maybe 2048+, then it's in sync with BCP 18.

Frank