Hallo Pascal!

 > Hi Tobias! :-)

 > Long time no see.

Indeed. Must be at least 1 year since I last logged into my fido node. I've
been surprised that it was still up and running, but hey, that's NetBSD
:-).

Well, my wife and baby have just left for a three weeks stay with my
parents, so I've suddenly got some free time ;-)

 > Well, true, but the language between "master and servant" is special 
 > anyway, and normally "you may do this" means "you are
permitted to do 
 > this", not "do this now".

Sure. But the default assumption is that nothing is permitted, unless the
standard explicitly permits it.

 > have damn good reasons if you do not use the recommended approach. Then 
 > there is "shall" or "must be", which means
"do it or die". At least 
 > that's how the Internet RFCs use these words. I know, this *may not* be 
 > what the FTS writers use.

I agree that the standard should  be clarified by either using the
word "shall" or by adding "may be ..., but software is
allowed to do otherwise", or similar.

 > There is already software that puts other stuff there. However, what I 
 > don't understand is why any software would even want to look at an 
 > MSGID in a more structured way than "it's just a unique string for the 
 > message". I don't see the need to decompose it into several parts. Just 
 > use the complete string.

Msged parsses the MSGID to retrieve the zone number, which is not
necessarily available anywhere else in the message. Both the INTL kludge
and the 4D origin line are sort of optional. Sure, MSGID is also optional,
that's why Msged parses all three of them in an attempt to get some
information.

Again, I agree that a dupe checker has no reason to treat the MSGID as
anything else than a standard string, and a well-designed program such as
Msged should not crash when it can't parse the MSGID, and should be fine as
long as the zone information can be obtained from INTL or origin.

But with the dupe checker, you might run into string length issues. And a
dupe checker is often not a standalone program, but part of the tosser, and
the tosser might want to knwo the zone number (at least for netmail), so if
both functions are not well separated within the tosser, you might end up
having a dupe checker working with the parsed MSGID, not with the unparsed
one. Theoretically ;-).

I still don't fully understand the need for this anyway. Proposals for
writing a separate tool that generates unique numbers (by storing in a file
the last number issued and then just increasing the counter or using any
other suitable algorithm when generating the next number), and that is
interrogated by all other fidonet software on the system whenever any such
software wants to generate a Msgid,  have been around since before I got
married (which seems like ages ago), so why has nobody ventured to
implement one yet? Seems to me to be a more clean option than extending the
standard to its limits.

Regards,
Tobias

--- Msged/BSD 6.1.1 (NetBSD/1.4 (alpha))