MSGID: 2:221/1.58@fidonet ef697c71   
   REPLY: 1:153/7001 tmCYOYVw   
   PID: OpenXP/5.0.49 (Win32)   
   CHRS: ASCII 1   
   TZUTC: -0400   
   Hello Maurice!   
      
   ** On Wednesday 14.04.21 - 15:57, you wrote to me:   
      
    MK> I recall saying that your idea is superior since it doesn't   
    MK> require any changes to existing documentation regarding   
    MK> MSGIDs.   
      
   The existing text could simply change "The serial number may be     
   any eight character hexadecimal number,  as long as it is     
   unique"  to "The serial number may be any eight character     
   hexadecimal number or a randomized alphanumeric number [*] with     
   the character set [a-z][A-Z][0-9], as long as it is unique"   
      
   [*] a suggestion by August Abolins, 2:221/1.58   
      
   The ftsc write-ups could serve as a guidebook for solutions and     
   examples and help remove ambiguity and false interpretations.   
      
      
    MK> If I gave you the wrong impression I will now apologize for   
    MK> my lousy communication skills.  I am obviously a lousy   
    MK> technical writer but in my defence I never claimed to be   
    MK> good at it.   
      
   No worries.  I probably have a greater fog that gets in my way     
   understanding what other people write.   
      
      
    MK> ..Once 2106 rears it's ugly head there is nothing in my   
    MK> routine that will prevent it from adding an extra hex   
    MK> character but then it won't be compliant to the current   
    MK> documented MSGID/REPLY format.   
      
   Even 2038 maybe of little concern for most of here right now. :(   
      
   And, unless a system keeps each and every message beyond 3 years     
   in their respective message bases (even that is possible) there     
   is probably no urgency to maintain rigidly unique msgids   
      
    MK> However the routine based on random 8 character [:alnum:]   
    MK> regex should still be good to go if indeed my attempt at   
    MK> forwards compatibilty fails, which according to everyone is   
    MK> the most likely result.   
      
   Yes.. it is sad that there is not much new or alternative     
   emerging in the "ideas" department for FTN.   
      
    MK> I am on record saying that I am prepared to soldier on if   
    MK> indeed that happens.  That won't stop me from trying again   
    MK> in the future but I cannot guarentee how long I can keep   
    MK> soldiering on.  I am getting old.   
      
   I do hope to see what transpires commencing 2038.   
      
   --   
     ../|ug   
      
   --- OpenXP 5.0.49   
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)   
   SEEN-BY: 1/123 18/200 90/1 105/81 120/340 123/131 124/5016 129/305   
   SEEN-BY: 154/10 203/0 221/1 6 360 226/30 227/114 229/101 424 426 452   
   SEEN-BY: 229/664 700 1016 1017 230/0 240/5832 249/110 206 317 400   
   SEEN-BY: 280/464 5003 282/1038 288/100 292/8125 301/1 310/31 317/3   
   SEEN-BY: 322/757 342/200 396/45 423/81 120 460/58 633/280 770/1   
   PATH: 221/1 280/464 229/101 426