Document: message-id.txt
Version: 001
Date: 2002-10-28

Message-ID
A new standard for unique message identifiers
October 28, 2002
andrew clarke
3:633/285.4@FidoNet
mail@ozzmosis.com


Status of this document
-----------------------

This document is a FidoNet Standards Proposal (FSP).

This document specifies an optional FidoNet standard protocol for
the FidoNet community, and requests discussion and suggestions for
improvements.

This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.


Rationale
---------

FTS-9 MSGIDs are not unique enough to be accurately relied upon. In
particular you the operator of a system runs the risk of generating
duplicate MSGIDs when using two or more different programs concurrently
that generate one, particularly when those programs use C's time(NULL)
function as a seed value to generate the hex value of the MSGID, which
is quite common. time(NULL) can differ greatly between implementations.
There is also the chance of generating duplicate MSGIDs if the system
time is repeated, eg. switching from daylight saving time to normal
time.

To the author's knowledge the "no two messages from a given system may
have the same serial number within a three years" (sic) clause in FTS-9
has been largely ignored by implementation that perform duplicate
message detection based on the MSGIDs described by FTS-9.


Message-ID
----------

A Message-ID consists of

[\x01Message-ID:][space][YYYY][MM][DD][HH][MM][SS][RR...][space][address][newli
ne]

Where:

[\01Message-ID:] is the ASCII character 1 followed by the string,
"Message-ID:" (where the double-quotes are not part of the string).

[space] is the ASCII character 30.

[YYYY] is the current year.

[MM] is the current month.

[DD] is the current day.

[HH] is the current hour.

[MM] is the current minute.

[SS] is the current second.

[RR]... is a random alphanumeric sequence containing only the characters "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890" and
whose length may be between 2 and 20 characters.

[space] is the ASCII character 30.

[address] is the origination address of the message.

[newline] is the ASCII character 13.

This format is similar to that used in Internet mail.


General
-------

If a Message-ID is to be generated, all the information listed above
must be present. The year must contain the century. The month, day,
hour, minute and second must have a leading zero if their values are
less than 10. The year, month, day, hour, minute and second must be in decimal. The Message-ID control line should be placed before the text
body of the message in which it appears. An existing Message-ID line
should never be stripped from a message passing through an intermediate
system. No system should ever add a Message-ID or modify an existing Message-ID contained in a message not originating on that system.

Implementations that perform dupe-checking must perform their
comparisons on the entire string from the first [space] until the
[newline].

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


Example
-------

An example of a valid Message-ID control line is as follows:

\01Message-ID: 20021028011631AHh7j12h91j1 3:633/285.4@fidonet

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/285.4)

Hi andrew!

28 Oct 30 15:24, andrew clarke wrote to All:

Document: message-id.txt
Version: 001
Date: 2002-10-28

Message-ID
A new standard for unique message identifiers
October 28, 2002
andrew clarke
3:633/285.4@FidoNet
mail@ozzmosis.com

Got here, but I am unsure if and how this echo is connected to the rest of the world. Have to check that now...

Cheers

Ger Vloothuis
ICQ:103-106-035

--- GoldED/W32 3.0.1
* Origin: Teletechnique BBS ttq.darktech.org (3:633/284.5)

arrived here with the following control lines... i am (was?) the main Z2<->Z1 gateway for all the FTSC echos... i also note that my Z1 uplink for this area appears to be running in tiny seenby mode...

in any case, my system has already forwarded this on to 2:201/329 for further distribution...

@MSGID: 3:633/284.5 3dbda568
@REPLY: 3:633/285.4@fidonet 3dbd56c7
@CHRS: IBMPC 2
@SEEN-BY: 10/3 105/360 106/1 2000 123/500 124/5025 140/1
154/15 201/505 396/45
Hi andrew!

28 Oct 30 15:24, andrew clarke wrote to All:

Document: message-id.txt
Version: 001
Date: 2002-10-28

Message-ID
A new standard for unique message identifiers
October 28, 2002
andrew clarke
3:633/285.4@FidoNet
mail@ozzmosis.com

Got here, but I am unsure if and how this echo is connected to
the rest of the world. Have to check that now...

Cheers

Ger Vloothuis
ICQ:103-106-035

--- GoldED/W32 3.0.1
* Origin: Teletechnique BBS ttq.darktech.org (3:633/284.5)
@SEEN-BY: 3634/12
@PATH: 633/284 285 260 774/605 123/500 106/2000

)\/(ark


* Origin: (1:3634/12)

FTS-9 MSGIDs are not unique enough to be accurately relied upon. In particular you the operator of a system runs the risk of generating
duplicate MSGIDs when using two or more different programs concurrently
that generate one, particularly when those programs use C's time(NULL) function as a seed value to generate the hex value of the MSGID, which
is quite common. time(NULL) can differ greatly between implementations.

As a general rule, implementations for specific languages shouldn't be mentioned in documents. I'd avoid this particular comment especially, since it
makes no sense. (time(NULL) must, by definition, be the same in any implementation.)

[\x01Message-ID:][space][YYYY][MM][DD][HH][MM][SS][RR...][space][address][ne
ne]

Really, there's no point in having the time in there at all. You can tell when
the message was written by its timestamp, and as you pointed out above, times are no guarantee of generating a unique ID. It still all comes down to the [RR] field at the end.

For that matter, there's not much point in having the originating address in the spec either. That's specified elsewhere, is open to misinterpretation and abuse, and is, in particular, used for different purposes in different implementations. (FTS-9 specifically does not specify what the originating address format is, and gating software has put this to good use in assigning originating addresses which reflect the internet address of the message rather than the Fido one.)

This format is similar to that used in Internet mail.

IMHO, you're just tampering with a good thing, i.e. the internet style Message-ID line. Simply, make it:
Message-ID: <unique message identifier>
where <unique message identifier> is *ANY* string not containing a newline or a
^A. Provide the time thing as a suggestion for helping to generate unique IDs,
but also point out that time alone is no guarantee. Beyond that, let the implementor choose his/her own method. Another possible note is that IDs which
satisfy the MSGID standard are a strict subset of this one.

---
* Origin: Xanadu: an odd little spot in Edmonton, Alberta (1:342/806)

Hello mark!

30 Oct 30 19:09, mark lewis wrote to Ger Vloothuis:

[........]

in any case, my system has already forwarded this on to 2:201/329 for further distribution...

Beauty.... Now we can get on with DEVeloping the NET :-)

Cheerrs

Ger

--- GoldED/W32 3.0.1
* Origin: Teletechnique BBS - ttq.darktech.org (3:633/284)

Wed 2002-10-30 20:51, Charles Cruden (1:342/806) wrote to Andrew Clarke:

FTS-9 MSGIDs are not unique enough to be accurately relied upon. In
particular you the operator of a system runs the risk of generating
duplicate MSGIDs when using two or more different programs concurrently
that generate one, particularly when those programs use C's time(NULL)
function as a seed value to generate the hex value of the MSGID, which
is quite common. time(NULL) can differ greatly between
implementations.

As a general rule, implementations for specific languages shouldn't be mentioned in documents. I'd avoid this particular comment especially, since it makes no sense. (time(NULL) must, by definition, be the same
in any implementation.)

From the C standard:

"The time function determines the current calendar time. The encoding of the value is unspecified."

Programmers tend to just convert the value returned to an unsigned long and be done with it, unfortunately.

In any case, I will amend the proposal to remove the references to the current system time, and basically make it open-slather as far as how an implementation
can generate their unique numbers. Unless Rob Swindell beats me to it. He's expressed much the same sentiments as you but in FTSC_PUBLIC.

It's probably a wise idea to limit the unique string to only alphanumeric and punctuation characters though, as FidoNet mail isn't entirely 8-bit clean, and some terminals might have problems displaying the Message-ID if there are "unusual" characters in it. And at some point in time people will need to visually identify messages by their Message-ID and this will be made more difficult if the ID contains unusual/extended characters.

Also, a minimum and maximum length for the unique string (eg. 8 and 65) might be a good thing.

For that matter, there's not much point in having the originating
address in the spec either. That's specified elsewhere, is open to misinterpretation and abuse, and is, in particular, used for different purposes in different implementations. (FTS-9 specifically does not specify what the originating address format is, and gating software has
put this to good use in assigning originating addresses which reflect
the internet address of the message rather than the Fido one.)

OK. RFC822 does actually specify a local part and a domain part separated by '@' for the Message-ID but I can see why this might just confuse the issue in FidoNet.

This format is similar to that used in Internet mail.

IMHO, you're just tampering with a good thing, i.e. the internet style Message-ID line. Simply, make it:
Message-ID: <unique message identifier>
where <unique message identifier> is *ANY* string not containing a
newline or a ^A.

OK, with some exceptions (see above).

Provide the time thing as a suggestion for helping to generate
unique IDs, but also point out that time alone is no guarantee.
Beyond that, let the implementor choose his/her own method.

OK.

Another possible note is that IDs which satisfy the MSGID standard
are a strict subset of this one.

True. I'm not sure I want to encourage their use though!

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/285.4)

As a general rule, implementations for specific languages shouldn't be
mentioned in documents. I'd avoid this particular comment especially,
since it makes no sense. (time(NULL) must, by definition, be the same
in any implementation.)

From the C standard:

"The time function determines the current calendar time. The
encoding of the value is unspecified."

Programmers tend to just convert the value returned to an
unsigned long and be done with it, unfortunately.

i believe that charles brought that up because not everyone uses C... i (still)
program in turbo pascal 6 and am just now starting to "play" with delphi 6... other languages include java, php, perl, etc...

one thing that i found exceedingly funny was that the original creator of FTS-0009 was thinking of a simple incrementing counter... that is really all that is necessary... even sendmail uses one... check the code! <<GG>>

)\/(ark


* Origin: (1:3634/12)

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,

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

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

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

Relying or random numbers isn't going to do much good when the randim
numbers are seeded from the clock, and many common random number generators
are only good for a few bits anyway (eg 24bits with ms-basic)

what's the point of repeating the date-time in the message-id anyway?
it's already in the message header.

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.

someone sent me a copy of the pktfix source for a bug-fix (message size
limit removed) maybe I could implement this uniquing scheme, to see how
complex it really is...

Bye <=-

---
* Origin: Death: to stop sinning suddenly. (3:640/531.42)

>> As a general rule, implementations for specific languages
>> shouldn't be mentioned in documents. I'd avoid this particular
>> comment especially, since it makes no sense. (time(NULL) must, by
>> definition, be the same in any implementation.)

From the C standard:

"The time function determines the current calendar time. The
encoding of the value is unspecified.

true, but all C implementations that I'm aware of return "unixtime"
(seconds since 1/1/1970 GMT) either as a long (or posibly as a float
in some cases?)

OK. RFC822 does actually specify a local part and a domain part
separated by '@' for the Message-ID but I can see why this might
just confuse the issue in FidoNet

I can't, explain why.

>> Another possible note is that IDs which satisfy the MSGID standard
>> are a strict subset of this one.

True. I'm not sure I want to encourage their use though!

if you can fix FTS-9 we only need to replace half our software to be compatible. for something new it all needs to be fixed. :)

Bye <=-

---
* Origin: Every solution breeds new problems. (3:640/531.42)

Thu 2002-10-31 20:01, Jasen Betts (3:640/531.42) wrote to andrew clarke:

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,

Good in theory, but not going to work if you don't have the source code to everything unfortunately. I guess the good thing about this is that more and more people are using open source FTN software, if not most of them, so there may be hope yet!

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

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

In any case Charles Cruden's idea of basically allowing any unique string seemed the most logical in hindsight. You could then have a combination of user-supplied-data + random number + MD5 of the 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.

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

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

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

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.

Quite true, but not always practical.

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)

Sat 2002-11-02 07:25, Jasen Betts (3:640/531.42) wrote to andrew clarke:

From the C standard:

"The time function determines the current calendar time. The
encoding of the value is unspecified.

true, but all C implementations that I'm aware of return "unixtime"
(seconds since 1/1/1970 GMT) either as a long (or posibly as a float
in some cases?)

Well, the point was they can return what they like. There is also the issue of
localtime vs UTC/GMT when it comes to using seconds since 1970-01-01 00:00.

OK. RFC822 does actually specify a local part and a domain part
separated by '@' for the Message-ID but I can see why this might
just confuse the issue in FidoNet

I can't, explain why.

In FidoNet it would probably end up translating to "localpart@originationaddress". People will then argue about what the origination address really is in the case of gateways and so on. So I suppose you may as well not bother with that and just have a localpart, which can be anything unique string at all (within reason).

Another possible note is that IDs which satisfy the MSGID standard
are a strict subset of this one.

True. I'm not sure I want to encourage their use though!

if you can fix FTS-9 we only need to replace half our software to be compatible. for something new it all needs to be fixed. :)

Message-ID won't stop people from using MSGID.

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)

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,

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

yeah, but nothing will fix abandoned closed source software.

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

It could be unreliable if the key file goes missing or gets
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

but is probably not such a bad solution if you decide not to generate random numbers. Particularly if the user can decide for themselves
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.

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

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

In any case Charles Cruden's idea of basically allowing any unique
string seemed the most logical in hindsight. You could then have
a combination of user-supplied-data + random number + MD5 of the
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.

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.

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

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

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 <=-

---
* Origin: Iron Law of Distribution: Them that has, gets. (3:640/531.42)

Hi andrew.

>> true, but all C implementations that I'm aware of return
>> "unixtime" (seconds since 1/1/1970 GMT) either as a long (or
>> posibly as a float in some cases?)

Well, the point was they can return what they like. There is also
the issue of localtime vs UTC/GMT when it comes to using seconds
since 1970-01-01 00:00

yeah if the don't have TZ set correcty they'll could get localtime or some other time zone instead.

>> if you can fix FTS-9 we only need to replace half our software to
>> be compatible. for something new it all needs to be fixed. :)

Message-ID won't stop people from using MSGID.

but if their software can't read the REPLY replacemny they loose out...

Bye <=-

---
* Origin: umop apisdn :zO palle> puel ay+ ui ajaymawoS (3:640/531.42)

[ 06 Nov 02 18:52, Jasen Betts wrote to andrew clarke ]

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.

Or a library.

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

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

It's better but still not guaranteed. rand() would have to return the same number twice in the same millisecond for this method to fail.

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

I suppose the message-id could form the domain of the origaddr part of the old msgid, since that will still allow most mail readers to extract Z:N/F as long as they don't barf on the length...


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- FMail/Win32 1.60+
* Origin: Cyberia: All your msgbase are belong to us! (3:712/848)

Wed 2002-11-06 18:52, Jasen Betts (3:640/531.42) wrote to andrew clarke:

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

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.

I'm not suggesting people stop generating MSGID/REPLY.

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

Both may be present if the user wishes. At least until the software stops providing that option (which will probably be never).

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)

Hi Scott.

08-Nov-02 08:04:45, Scott Little wrote to Jasen Betts

[ 06 Nov 02 18:52, Jasen Betts wrote to andrew clarke ]

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.

Or a library.

I had to write it to count the lines... I could turn it into a C library fuunction, and do it in pascal too. I guess even basic too... :)

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

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

It's better but still not guaranteed.

same seed same result that's how RNGs work.

rand() would have to return
the same number twice in the same millisecond for this method to
fail

If you're seeing it once per pkt (or other gropuping of messages)
ithere's no guarantee that it won't give the same number it gave yesterday
or last week some time. or even last year..

the easiest way to ge unique numbers is to use each number once.
the easiest way to do that is just to use them in order.

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

I suppose the message-id could form the domain of the origaddr
part of the old msgid, since that will still allow most mail
readers to extract Z:N/F as long as they don't barf on the
length..

Z:N/F should come from the origin line anyway. (already some msgids don't contain it). if if you can make the numbers unique that's all that's needed
a hint of some sort to indicate that they are unique - a uniqueness certificatte kludge would be sufficient for software that needs a unique message identifier, if it doesn't see the crtificate then the msgid is
possibly non-unique and shouldn't be used asif it was uniue.

@MSGID: 3:640/531.42 819f2b77
@MSGIDUNIQUE

or maybe it could go in the address part of the msgid, not sure how really.

Bye <=-

---
* Origin: How wonderful opera would be if there were no singers (3:640/531.42)

[ 09 Nov 02 07:05, Jasen Betts wrote to Scott Little ]

Or a library.

I had to write it to count the lines... I could turn it into a C
library fuunction, and do it in pascal too. I guess even basic too...
:)

I use a little SQL table.. there are MySQL modules for almost any popular (and not so popular) OS and language.. except DOS but I don't give a fig about DOS anymore :)

If you're seeing it once per pkt (or other gropuping of messages)
ithere's no guarantee that it won't give the same number it gave
yesterday or last week some time. or even last year..

Uh, what did I just say? If the rand() is prefixed with year, month, day, hour, minute, second, millisecon, the rand() would have to return the same number twice in that one millisecond.

The only issue here is if rand() is seeded by the time, in which case multiple processes will generate the same sequence of 'random' numbers (again, this will
have to happen during the same millisecond in both processes). But on any non-shitty OS (ie. not DOS) there will be a system wide source of randomness or
other information that will keep two processes from picking the same number.

the easiest way to ge unique numbers is to use each number once.
the easiest way to do that is just to use them in order.

Which means using a single source.

@MSGIDUNIQUE

Good idea, but rofl!

Fidonet. The amateur Microsoft.

Are you sure this unique ID is really unique? [Y/n] _

or maybe it could go in the address part of the msgid, not sure how really.

Was it decided that three fields in MSGID would break things? If software is currently only generating one field then I can't see it being any worse.


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- FMail/Win32 1.60+
* Origin: Cyberia: All your msgbase are belong to us! (3:712/848)

Hello Scott.

11 Nov 02 14:31, you wrote to Jasen Betts:

Or a library.

I had to write it to count the lines... I could turn it into a C
library fuunction, and do it in pascal too. I guess even basic too...
:)

I use a little SQL table.. there are MySQL modules for almost any
popular (and not so popular) OS and language.. except DOS but I don't
give a fig about DOS anymore :)

Careful.. you'll upset Carol ;-)

Cheers,
Rick

... Peter Norton is the "Betty Crocker" of software!
--- GoldED+/LNX 1.1.5 - Debian/GNU
* Origin: Vampyre's Heaven BBS (3:640/954)

[ 11 Nov 02 16:52, Rick Van Ruth wrote to Scott Little ]

Careful.. you'll upset Carol ;-)

Fortunately the .mil tends to frown on use of their missiles for personal purposes.. she might be able to arrange a real nasty flyby of my office building if they ever drop by Sydney Harbour though...


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- FMail/Win32 1.60+
* Origin: Cyberia: All your msgbase are belong to us! (3:712/848)

Hi andrew.

I'm not suggesting people stop generating MSGID/REPLY.

so why have both?

AFAICT the proposal add nothing that Msgid (etc) doesn't already provide,
or couldn't be fixed to provide except for a "seconds/fractiuons"
timestamp.

Bye <=-

---
* Origin: 16 Km East of TV's "Croc Hunter" (3:640/531.42)

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

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

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,

Good in theory, but not going to work if you don't have the source code
to everything unfortunately. I guess the good thing about this is that more and more people are using open source FTN software, if not most of them, so there may be hope yet!

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

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

In any case Charles Cruden's idea of basically allowing any unique
string seemed the most logical in hindsight. You could then have a combination of user-supplied-data + random number + MD5 of the 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.

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

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

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

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.

Quite true, but not always practical.

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267) SEEN-BY: 10/345 28/1 105/8 106/1 124/5009 143/2 150/220 205/1 229/1000 3000 SEEN-BY: 247/101 250/99 254/6 275/311 278/230 280/5003 282/4066 311/13 SEEN-BY: 322/320 343/41 362/627 379/1 1200 396/45 633/267
751/321 2604/416 @PATH: 633/267 285 260 774/605 123/500 106/2000 140/1 250/501 280/100 28/1 @PATH: 10/345 379/1

========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@p1.f1.n379.z1.fidonet.org

--- Fidolook Lite FTN stub
* Origin: FidoHub Point 1 (1:379/1.1)

Thu 2002-11-21 01:26, Dale Ross (1:379/1.1) wrote to andrew clarke:

@MSGID: 3:633/267@fidonet 3dc76ac0
@PATH: 633/267 285 260 774/605 123/500 106/2000 140/1 250/501
280/100 28/1
@PATH: 10/345 379/1

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

Bizarre. Maybe somebody came back from holiday. Was it just my message, or all the others from Z3 too? Anyway, as of now I've my switched NET_DEV feed to
your system, so at least you'l get my messages fast! ;-)

@PATH: 379/1 396/45 106/2000 123/500 774/605 633/260 285

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
* Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)

Bizarre. Maybe somebody came back from holiday. Was it just my
message, or all the others from Z3 too?

There were a TON of messages that came in yesterday. I do not know where
they were stuck. As to Zone 3, that is about all there is in here! :-)

I have a connection at Mar(c) Lewis at 1:396/45.
He connects to 1:106/2000
Mar(k) Lewis also connects at 1:106/2000
Mar(k) Lewis messages are not coming in through Mar(c) Lewis system.
Perhaps I need to connect to Mar(k) Lewis.

Mark?

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

--- Fidolook Lite FTN stub
* Origin: FidoHub Point 1 (1:379/1.1)

Hi Scott.

the easiest way to ge unique numbers is to use each number once.
the easiest way to do that is just to use them in order.

Which means using a single source.

yeah, that's the only way that i can see of doing FTS-19 in a bulletproof
manner.

or you coulsd make a list of all the used ones and check each one hasn't
been used in the last three years :)

@MSGIDUNIQUE

Good idea, but rofl!

Fidonet. The amateur Microsoft.

Are you sure this unique ID is really unique? [Y/n] _

yeah... you get that.

or maybe it could go in the address part of the msgid, not sure
how really.

Was it decided that three fields in MSGID would break things?

it looks that way from reading fts-19

It says the serial number comes before the end of line so some progs may
juse uset the last 8 hexdigits on the line while others may use the first 8 after the address part and the space....

Bye <=-

---
* Origin: Necessity is a mother. (3:640/531.42)

Bizarre. Maybe somebody came back from holiday. Was
it just my message, or all the others from Z3 too?

There were a TON of messages that came in yesterday. I do not
know where they were stuck. As to Zone 3, that is about all
there is in here! :-)

I have a connection at Mar(c) Lewis at 1:396/45.
He connects to 1:106/2000
Mar(k) Lewis also connects at 1:106/2000
Mar(k) Lewis messages are not coming in through Mar(c) Lewis
system.
Perhaps I need to connect to Mar(k) Lewis.

Mark?

yes? what are we missing?

)\/(ark


* Origin: (1:3634/12)

Hi Dale.

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

It's a pity timestamps aren't part of the path kludge :)
i've piut ount some slow mail but that's 'cause I had no phone for a week.

Bye <=-

---
* Origin: "Hehehehe, 2400 baud sucks!" V.bis and Baudhead (3:640/531.42)

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

It's a pity timestamps aren't part of the path kludge :)
i've piut ount some slow mail but that's 'cause I had no phone for a
week.

I asked for that a LONG time ago. "Special" path kludges, up with the other kludges not messing with the real path info, would be nice.

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

--- Fidolook Lite FTN stub
* Origin: FidoHub Point 1 (1:379/1.1)