Subj : message-id
To   : Charles Cruden
From : andrew clarke
Date : Fri Nov 01 2002 03:21 am

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!

-- [email protected]

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

You are viewing proxied material from cvs.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.