home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / fido / ftsc_all.z43 / FSC-0041.001 < prev    next >
Text File  |  1990-03-12  |  6KB  |  143 lines
  1. Document: FSC-0041
  2. Version:  001
  3. Date:     03/13/90
  4.  
  5.  
  6.  
  7.  
  8.                               MSGID / REPLY
  9.                 A proposal for unique message identifiers
  10.                         and reply chain linkage
  11.  
  12.                                jim nutt
  13.                            1:114/30@fidonet
  14.  
  15.      
  16.  
  17.      Information:
  18.  
  19.          This FSC suggests a proposed protocol for the FidoNet
  20.          community, and requests discussion and suggestions for
  21.          improvements.  Distribution of this document is
  22.          unlimited.
  23.  
  24.  
  25.  
  26. From a message originally posted in the NET_DEV conference:
  27.  
  28. The following is a brief description of the proposed standard for
  29. generating msgid/reply 'kludge' lines in a message. Msgids have a number
  30. of uses besides simply being a unique message identifier. They can be
  31. used for dupe killing and reply linkage as well.
  32.  
  33.  
  34. MSGID
  35.  
  36.     A MSGID line consists of the string ^AMSGID: followed by a space,
  37. the address of the originating system and a serial number unique to that
  38. message on the originating system.  i.e:
  39.  
  40.         ^MSGID: zone:net/node.point@domain serialno
  41.  
  42. It is not the intent to limit the address field of the msgid to fidonet
  43. style addresses,  they are used here simply for illustration;  messages
  44. originating from other types of systems should use an address appropriate
  45. to the originating system.  The serial number may be anything the
  46. developer's little heart desires,  AS LONG AS IT IS UNIQUE - NO TWO
  47. MESSAGES ON A SYSTEM MAY SHARE A SERIAL NUMBER!!  The serial number is
  48. formatted as an 8 character hexadecimal integer,  i.e.  a 32 bit word.
  49. Since this yields in the neighborhood of 4 billion unique numbers,  I
  50. don't think it will be a limit for most systems.  A common choice for
  51. the serial number is the number of seconds since 1 jan 1970 00:00:00
  52. gmt;  this is unique on a single user system and relatively easy to
  53. generate.  A more elaborate system will doubtless be necessary in the
  54. case of a multi-user system.
  55.  
  56.  
  57. REPLY
  58.  
  59.     A REPLY line looks similiar to a MSGID line, and is in fact,  very
  60. close.  REPLY lines are generated using the MSGID line of the message
  61. being replied to.  The ^AMSGID: string in the MSGID line is replaced with
  62. ^AREPLY: and then written to the text of the new message.  i.e.:
  63.  
  64.         ^AREPLY: msgid of original message
  65.  
  66. Again, this is very simple and as non-compute intense as possible
  67.  
  68.  
  69. GENERAL
  70.  
  71.     For best results, MSGID and REPLY lines should be the first two lines
  72. of the message after extended addressing lines (FMPT, TOPT, INTL,
  73. DOMAIN), with MSGID appearing above REPLY.  This makes it unlikely that a
  74. MSGID will be damaged by something that doesn't destroy the binary
  75. message header as well.  As mentioned above,  it doesn't really matter
  76. what method is used in generating the serial number,  as long as it
  77. produces an eight digit hexadecimal number UNIQUE TO THE ORIGINATING
  78. SYSTEM.  Finally,  a MSGID SHOULD BE GENERATED ONLY AT MESSAGE CREATION.
  79. IT SHOULD NEVER,  EVER BE STRIPPED FROM A MESSAGE NOR SHOULD ONE BE ADDED
  80. TO A MESSAGE PASSING THROUGH A SYSTEM (whew,  all those caps wore me
  81. out!).  This is essential for a msgid to be useful,  without this
  82. restriction,  msgids are useless or worse.
  83.  
  84.  
  85. RATIONALE
  86.  
  87.     Finally, what you've all been waiting for (I'm entering this in sixty
  88. line mode and the top has scrolled off) ... WHY you should use msgid and
  89. reply kludge lines.  Good question and one that has several answers,
  90. which I will cover one by one...
  91.  
  92.    1) They eliminate the need for origin lines.  A msgid contains all the
  93.       information an origin line is technically there for.  It is in a
  94.       safer place than an origin line and much less likely to be
  95.       truncated or destroyed while leaving the rest of the message
  96.       intact.
  97.  
  98.    2) Is related to 1) above, a msgid makes private replies to echomail
  99.       via netmail a trivial process, you know exactly what system
  100.       originated the message without worrying about parsing out the
  101.       origin line (and we all know how much fun THAT is).
  102.  
  103.    3) True reply linkage is possible in echomail because you know exactly
  104.       which message the reply is to.  You just look for a message whose
  105.       msgid matches the reply in the current message.  And you already
  106.       have a database of msgids for dupe killing (more later).  This also
  107.       lets you track replies ACROSS echomail conferences ... some
  108.       fascinating possibilities there,  eh?
  109.  
  110.    4) Annoying messages can be tracked more accurately.  Because msgids
  111.       are a 'hidden' line and therefore not normally visible or creatable
  112.       by your average user, they are considerably more difficult to forge
  113.       than an origin line (forging which is a trivial task).  Admittedly
  114.       this isn't going to stop a twit sysop,  but that 8 digit serial
  115.       number is going to be a problem for him ... if he copies one that
  116.       already exists,  the message will be killed as a dupe,  if he makes
  117.       one up,  chances are fairly good that that will be a dupe as well,
  118.       so it does make forgery a bit more difficult.
  119.  
  120.    5) Accurate dupe killing is possible.  By maintaining a database of
  121.       msgids one can easily check to see if a message is a duplicate of
  122.       one already entered.  If it is stipulated that msgids must be
  123.       sequential, it becomes, once again,  trivial ... simply store the
  124.       highest serial number that has come from a particular address,
  125.       any messages that come in with a serial number lower than that can
  126.       be assumed dupes and killed.
  127.  
  128.    6) Tracking of dupe generators is possible.  Since msgids are never
  129.       stripped and never added, the only msgid on a message should be the
  130.       one of the originating system.
  131.  
  132.    7) Simplicity.  MSGID and REPLY kludgelines are very simple to
  133.       generate, they require no complex calculations and are easy to
  134.       parse.  And they give you all the benefits above.  So why NOT use
  135.       them?
  136.  
  137.  
  138. FINALLY
  139.  
  140.     Your questions and comments are welcome and will be responded to as
  141. time permits. This is only the initial draft, there are a number of
  142. proposed extensions to this specification already.
  143.