ac> ========FTN PACKET HEADER (PKT_MSG20):========
 ac> type          2
 ac> origNode      1
 ac> destNode      1
 ac> origNet       379
 ac> destNet       379
 ac> AttributeWord 0
 ac> cost          0
 ac> DateTime[20]  05 Nov 02  11:22:08
 ac> toUserName    Jasen Betts
 ac> fromUserName  andrew clarke
 ac> subject       message-id

 ac> ========FTN MESSAGE SOURCE:========
 ac> AREA:NET_DEV
 ac> {at}MSGID: 3:633/267{at}fidonet 3dc76ac0
 ac> {at}TZUTC: 1100
 ac> {at}REPLY: 3:640/531.42 1eb6d8b9
 ac> {at}TID: hpt 0.9.7d-stable/w32 02-01-01
 ac> Thu 2002-10-31 20:01, Jasen Betts (3:640/531.42) wrote to andrew
 ac> clarke:

 ac>>> FTS-9 MSGIDs are not unique enough to be accurately relied upon.

 >> sure they are, FTS-9 says they don't reapeat for three years,

 >> of course many implementations don't ensure that.

 >> IMO what's needed is a proper implementation of FTS-9

 >> eg using sequential numbers from a single source for all the messagids
 >> on the system.

 >> 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 code
 ac> to everything unfortunately.  I guess the good thing about this is that
 ac> more and more people are using open source FTN software, if not most of
 ac> them, so there may be hope yet!

 ac> It could be unreliable if the key file goes missing or gets corrupted
 ac> (eg. two programs trying to write to it at once) but is probably not
 ac> such a bad solution if you decide not to generate random numbers.
 ac> Particularly if the user can decide for themselves which method to use.

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

 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 a
 ac> combination of user-supplied-data + random number + MD5 of the message
 ac> 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.  ;-)

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

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

 ac> Yep.

 >> one solution to different applications generating matching msgids is to
 >> give the different appications diffrerent addresses - eg give the news
 >> autoposter a point address so it can't clash with the message editor.

 ac> Quite true, but not always practical.

 ac> -- mail{at}ozzmosis.com

 ac> --- Msged/NT 6.1.1
 ac> SEEN-BY: 10/345 28/1 105/8 106/1 124/5009 143/2 150/220 205/1 229/1000
 ac> 3000 SEEN-BY: 247/101 250/99 254/6 275/311 278/230 280/5003 282/4066
 ac> 311/13 SEEN-BY: 322/320 343/41 362/627 379/1 1200 396/45 633/267
 ac> 751/321 2604/416 {at}PATH: 633/267 285 260 774/605 123/500 106/2000 140/1
 ac> 250/501 280/100 28/1 {at}PATH: 10/345 379/1

 ac> ========FTN MESSAGE END============


Sorry for the long quote and no reply. This message took TWO WEEKS to arrive
here.

With best regards, Dale Ross.  E-mail: Dale.Ross{at}p1.f1.n379.z1.fidonet.org

--- Fidolook Lite FTN stub