Re: #1083: USEPRO 5.3: Rules for generating message-ID

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Russ Allbery wrote:
 
> I propose closing this ticket with no further changes.

I disagree.  Not talking about spam cancel conventions is okay.
Not talking about Message-IDs is not.  For UAs it can be okay
if they only try to get it right based on the text in RFC 2822.

But if an injecting agent creates Message-IDs it can't afford
to create collisions.  It has to work if it generates more than
one Message-ID per second, and it has to work if its local time
sometimes jumps backwards into the "past".  It has to work at
the end of daylight savings time, and after a reboot.

Your concept "Message-ID + Injection-Date = id" is IMO wrong. 
The id of an article is the Message-ID, as the name suggests.

The Injection-Date is a kludge dealing with incomplete history
files.  It's impossible and/or undesirable to keep a complete
list of all seen Message-IDs in practice, but it's the ideal
for worldwide unique Message-IDs forever.  

This is a core feature of s-o-1036, worldwide unique forever.

It took me very long to get this, from my Fidonet POV, where
the path is everything, and the Message-ID only optional.  I
tried weird compromises like "if two years isn't enough, then
maybe five years, or ten years".  But of course the s-o-1036
evangelists finally convinced me that "unique forever" is not
two, five, or ten years, but much longer.  And that this idea
of the Message-ID is the essence of NetNews (taking groups as
given, that was similar in FTN echomail).

Any text intending to obsolete s-o-1036 has to get this idea
to all readers (or at least to the implementors reading it).
For outsiders with a 2822-POV (Message-ID not mandatory) or
my former FTN POV it's not obvious.  It's also not obvious
why there is a history in addition to the path.  

Not talking about it (as a trick to avoid the question of a 
reasonable minimum) is no option.  S-o-1036 has this right,
and if USEPRO refuses to outline the principles of operation
it is pointless to continue with it.  Readers need to know
*_why_* something is a MUST NOT or SHOULD or MAY.  For that
they need to know how stuff works beyond their own server or
implementation.

Frank