PE> To "detect" it, I use Squish's "Duplicates"
keyword.  In any conference
PE> that I have defined that has a low number of messages (e.g. 1 per day),
PE> and I happen to be keeping 1000 duplicates per area (the Squish
PE> default), then I will indeed keep 3 years worth of this information,
PE> and if you attempt to send me a duplicate MSGID, your message will be
PE> lost without warning when it passes through this system.

RS> Yes, but as he says, the chance of that happening, someone keeping that

It is very easy to keep 3 years worth of duplicates.  A lot of
people keep a fixed area size, e.g. 500 messages.  They do that
on Lotus, or Z3_NETDEV, not sure about BLAKES_7, then they will
indeed get 3 years worth of duplicates.

RS> period, and you accidentally reusing the SAME MSGID in the SAME very low
RS> volume area, is indeed utterly microscopic. And if that risk does actually
RS> worry you, the answer is to improve the dupe delete mech so it only does
RS> an unconfirmed delete when the other fields match TOO, and say asks for
RS> confirmation if they dont also match. Far better than just ditching MSGID
RS> for such a microscopic risk.

When you get:

1. Squish changed so that it does this
2. The *masses* of Squish to use the new version

then let me know.  Until then, it's just baying at the moon.

PE> Certainly it's of absolutely no use for getting an address from.

RS> Thats wrong for starters, its more rigorously defined than the other 
RS> source.

WRONG!  The MSGID address is defined to be the address in the
ORIGINATING NETWORK.  Quite often, this is an internet address,
but it could also be an Adultnet address, Zyxelnet address, or
any other net, with numbers that are shared by another net, or
maybe even a fakenet.  Since there is NO WAY of knowing what net 
it was that created the message, you HAVE to treat that as a
character string that is not to be interpreted, anything else is
irresponsible.

On the other hand, the address in the origin line is defined in
FTS-4, and will be a fidonet address (or more to the point, an
address in the CURRENT network).  The INTL line is similarly
robust.

PE> It's only use is for duplicate detection,

RS> Nope, there are a variety of other benefits, particularly when
RS> its turned into a valid REPLYID when replied to. You have a quite
RS> unambiguous specification of what its a reply to. And thats not
RS> just useful for threading either.

Yeah, that's one small benefit, when someone goes and changes
the subject line.

PE> and that's the problem I'm most worried about.

RS> For microscopic risk which can be readily
RS> fixed if if really does worry you.

Nope, can't be fixed unless you can change all the software in
existence that dupe detects quite validly based on the FTS-9
spec.  It is YOUR duty to make sure that no two messages you
generate have duplicate MSGIDs, NOT the author of Squish.  You
can bay at the moon all you like, and run around in ever 
decreasing circles, but it doesn't change a damn thing - it is
YOUR responsibility, don't ask others to change their software
because YOU haven't bothered to read the specs.

PE> For unimportant thinks like reply-threading on the
PE> local BBS, you may as well just use the subject line.

RS> Nope, doesnt handle a subject line change, which happens often.

Ok, this is the only situation where MSGID is useful.  

ac> FTS-9 was designed to be used, not ignored.  Don't ignore
ac> (ok, half of) it because you're afraid of it breaking

PE> That's not my attitude towards specs.

RS> You have an attitude problem |-)

I don't think so.  Make up your own spec if you are planning on
not following the current one.  BFN.  Paul.
@EOT:

---