on *13.02.22* at *12:23:17* You wrote in Area *FTSC_PUBLIC* to *Carlos Navarro* about *"MSGID"*.
O> I still don't understand the reasoning and advantages of "string@z:r/n.p". O> Why would one want to use an invalid FTN address in the MSGID, if the O> message is originating in an FTN?
I am also a bit suprised by this discussion because it appears that somebody has the idea of using the address part of the MSGID for an unintended purpose. From my perspective, the *address part is essantially a unique ID that represents the system generating the MSGID number*. This enables the *two together to form a unique identifier for the message* itself w.r.t the system that has created the original FTN message.
I honestly think, *the "valid return address" is only a way of enforcing a sender UID*. Similar practice can be found all across the field (say Java package names). In particular this means, that there should actually be no furhter semantics attached to that address. In particular, no one should actually try to contact the system based on that string.
The hole MSGID/REPLY mechanism however has a generall problem with messages generated outside a FTN network, where the number is generated outside the originating sytem (i.e., a gateway). While such a gateway may indeed rely on the originating network adressing scheme for the adrress part, the number is generated by the gateway without any general mechanism for keeping it unique for that particular sender. While one gateway still could hold a history for each such sender, there may be multiple uncoordinated gateways of the same type producing duplicated numbers for the same origin address. However, in practice I see this only impacting reply linkage in the reade. Dupe checking usually involved information beyond the MSGID and should not fall for it.
Regards, Tim --- WinPoint 399.1 * Origin: Original WinPoint Origin! (2:240/1120.29)
