Hi Tobias! :-)

 TE> Indeed. Must be at least 1 year since I last logged into my fido 
 TE> node. I've been surprised that it was still up and running, but hey, 
 TE> that's NetBSD :-).
Heh. I had that running for a while, too, but it didn't work with all my hardware.

 TE> Sure. But the default assumption is that nothing is permitted, unless 
 TE> the standard explicitly permits it.
I'm not sure, but it makes sense for technical standards. :)

 TE> Msged parsses the MSGID to retrieve the zone number, which is not 
 TE> necessarily available anywhere else in the message. Both the INTL 
 TE> kludge and the 4D origin line are sort of optional. Sure, MSGID is 
 TE> also optional, that's why Msged parses all three of them in an 
 TE> attempt to get some information.
Eh? Shouldn't that be in the message base somewhere? It is part of the
binary pkt/message header, at least in v2+ packets, which should be almost
all of them by now (yeah, sure). Or is the info from the pkt stripped
before messages get stored into the message base?

 TE> But with the dupe checker, you might run into string length issues. 
 TE> And a dupe checker is often not a standalone program, but part of the 
 TE> tosser, and the tosser might want to knwo the zone number (at least 
 TE> for netmail), so if both functions are not well separated within the 
 TE> tosser, you might end up having a dupe checker working with the 
 TE> parsed MSGID, not with the unparsed one. Theoretically ;-).
Yeah, but the tosser must have the zone number from the pkt, so that's no
issue. I know it's hard to get right, though. Different variants of the pkt
header format have the info in different places. So when the header has
inconsistent info, which can happen, maybe a fallback to MSGID is tried in
some programs.

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

pharao90:~ $ cat /home/fido/seq
932223318

No idea whether anything besides hpt uses it, though.

Ciao
Pascal

--- Msged/LNX 6.1.1