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

["Forrest J. Cavalier III" <mibsoft@xxxxxxxxxxxxxxx>]

Russ Allbery wrote:
>   I think it's the specific use cases that are mixing
> things up.

I think that indicates that no matter what we do, someone is going
to screw it up sometime, somewhere.

Russ, I think your lengthy analysis is accurate, except for two points.

1. The article identity (for preventing duplicates) is not actually a 2-tuple
of Message-ID, Date.  It is Message-ID + fuzzy arrival date.  Every date within
the past 3 days is probably as good as any other date in that range.  The
header fields do not always set the roll-off from message-id history.  It is 
arrival order.  That changes your conclusions a bit too, I think.

Overconstraining the solutions to guaranteeing (Message, Date) is not
strictly necessary, and I think you throw out some potentially rewarding
arrangements.

2. I think you present all branches of your fault tree as if they were all
equally likely in practice.  I disagree with that approach when we
admit we don't have a solution for all cases for all people.

I prefer to take the most likely of situations, standardize something that 
works, and then ignore the least likely branches.  They fall outside our
standard, or they can go look at Duties of a Gateway and figure out something.

If we disallow "late (re)injection", don't most of the problems go away?

Sure, I'd like late reinjection to work too, but it doesn't happen enough to 
work to standardize.  Let some future standard tackle it.

So, after all this time, no one seems to have proposed something that we have 
consensus that works.  Too bad.  It isn't our problem that the people who 
proposed Injection-Date as a solution to this problem didn't get it right.  If 
they want it, they can propose something that gets consensus.  I don't care to
fix it for them.

My opinion: Standardize reinjection from private leaf nodes (it's common).
Standardize multi-point injection.

Drop late injection.  It almost requires a flag day, not because we get
duplicates (we would), but because the contents of a newsgroup is going to be 
different at different sites, depending on whether they implemented 
expiry/incoming relay on Injection Date, or Date.  And isn't that is the problem 
that it was intending to prevent?  If an article is re-injected late, we have
the amusing situation of an article appearing, not appearing, and appearing
as a duplicate on various servers.

And all this complexity about late injections for what?  A handful of posters 
per day on Usenet?  Hours later is not going to matter.    How many posters per 
day on Usenet will be posting days later than authoring?  Does anyone have an 
estimate?

Aren't we knocking ourselves out over mere annoyance?  Just tell those posters 
that their message had better have a current Date: header if they want it to 
propagate, (that's reality, and telling them different is not helpful) and if a 
late Date header seems like deception, they can note it in the body of their 
message. If they want a sooner expiry, add a header field.  Voila!  Backwards
compatible too.