Hi andrew.

  >> At it simplest This means about 15 lines of C. (or pascal, bssic
  >> etc) in each program where they generate the message-ids, and a
  >> key file somewhere where all the mail processors can reach it,

 ac> Good in theory, but not going to work if you don't have the source
 ac> code to everything unfortunately.

yeah, but nothing will fix abandoned closed source software.

 ac> I guess the good thing about this is that more and more people are
 ac> using open source FTN software, if not most of them, so there may be
 ac> hope yet

 ac> It could be unreliable if the key file goes missing or gets
 ac> corrupted (eg. two programs trying to write to it at once)

yeah, but two programs can't open the file at the same time, that's how
file locking works, in effect the key file is its own semaphone, (unless
there's a network or OS comnfoiguration problem)

in the unlikely event of loss or corruption of the file a simple formula
((unixtime*42) mod 2^32)  will give a good starting point since it only
visits the spame part of the serial number range once every three years

 ac> but is probably not such a bad solution if you decide not to generate
 ac> random numbers. Particularly if the user can decide for themselves
 ac> which method to use

That was another idea I toyed with, making the serial number engine
pluggable... where the editor (etc) rouns an external prog to generate the
serial number.

 ac> Although I still think a random number generator seeded with the
 ac> year + month + day + hour + minute + second + subsecond would do a
 ac> pretty reasonable job if the string to be generated was long
 ac> enough.  I guess I should do some tests

yeah, but no better than just using the year + month + day + hour + minute
+ second + subsecond

 ac> In any case Charles Cruden's idea of basically allowing any unique
 ac> string seemed the most logical in hindsight.  You could then have
 ac> a combination of user-supplied-data + random number + MD5 of the
 ac> message text, or any other combination you wanted to use..

  >> Maybe another kludge could be added to indicate the the msgid so
  >> generated is guaranteed to be unique.

 ac> May as well invent a new kludge that does both.  ;-)

a new kludge won't be compatible with existing software.
^AMSGID is nice on it's own, but ^AREPLY is really useful.

 ac>>> Implementations that generate a Message-ID may also optionally
 ac>>> generate a MSGID conforming to the FTS-9 standard for systems
 ac>>> that do not recognise the Message-ID.

  >> is there going to be a replacemnt to the REPLY kludge too ?

 ac> Yep.

So converters will be needed for people with old software who want to see
threads, or will both MSGID always be present in messages with with a
message-id



 -=> Bye <=-

---