Re: SBBS/W32 Kermit SABOTAGE
  By: Paul Westell to Rob Swindell on Sun Oct 17 2004 03:25 am

 >  >> You have stated that the third field in the message ID is necessary
 >  >> to overcome some deficiencies in the accepted FTN format. Please
 >  >> detail these and how this third field avoids them. Although I am not
 >  >> a programmer I have some grasp of the concepts, and I know there are
 >  >> some as yet unheard from programmers following this.
 > 
 >  RS> It's been discussed to death in FTSC_PUBLIC and other echoes. To
 >  RS> summarize, a
 >  RS> 32-bit number, alone, is not enough data to insure message uniqueness
 >  RS> without
 >  RS> jumping through great hoops to insure that number is not re-used by
 >  RS> any 2
 >  RS> messages from the same system.
 > 
 > That is a problem most seem to regard as rather minor and by itself
 > hardly justifies modifying current standards.

Non-unique MSGIDs defeat the whole purpose of MSGIDs and are basically useless.
I consider that problem much more than minor.  

 > You stated deficiencies in the plural. Are the remainder so
 > insignificant that they are not worth explaining? If so then they
 > hardly require fixing. Please be more forthcoming.

Actually, I used the word "inadequacies". The inadequacies I'm
referring to are
specifically, that the MSGID is made up of specified "fields" with limited 
specific content. MSGIDs should (and in most cases *are*) stored and used as
simple text strings that uniquely identify a message. To summarize, you could
say there is just one inadequacy of FTS-9, that being that it dictates the
exact content of a MSGID, and limits the "unique" portion to just 32-bits.

                                                  digital man

Snapple "Real Fact" #138:
Hawaii is the only U.S. state that grows coffee. 
--- SBBSecho 2.10-Win32