home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / fido / ftsc_all.z43 / FSC-0030.TXT < prev    next >
Text File  |  1989-04-21  |  9KB  |  163 lines
  1. FSC-0030
  2.  
  3.         MESSAGE IDENTIFICATION AND REPLY FOR FIDONET
  4.         *DRAFT* FIDONET TECHNICAL COMMENT
  5.  
  6.         Author:  John Cowan
  7.         Fido:    1:107/711 (formerly 1:107/111)
  8.         Arpa:    cowan@magpie.masa.com
  9.         Uucp:    {backbones}!rutgers!hombre!magpie!cowan
  10.         Vox:    +1-212-236-9153
  11.  
  12. ABSTRACT
  13.  
  14. The following document proposes a standard for message identification and
  15. message reply identification for Fidonet and Fidonet-based electronic mail
  16. system.  It is based on the Usenet standard, RFC 850 and successors.
  17. The proposed standard will assist in duplicate-message detection and will
  18. permit the support of true reply threading across the network.  The standard
  19. consists of mandatory and suggested portions; however the term "mandatory"
  20. does not mean that any Fidonet product must implement this standard -- it
  21. simply means that those that do claim to implement this standard must do
  22. so in the way described.
  23.  
  24. BACKGROUND
  25.  
  26. Currently, Fidonet messages are not uniquely identified.  A variety of schemes
  27. are in place to determine whether a message received by a Fidonet node has
  28. been previously processed by the node, but all of them involve a probabilistic
  29. component which may allow duplicates to slip through.  This can happen with
  30. particular ease where non-Fidonet gateways are involved which may reformat
  31. a message.
  32.  
  33. In addition, Fidonet provides no clear and definite indication of whether
  34. a message is a reply to some other message, and if so, which message.  This
  35. is a consequence of the previous problem -- there is no way to refer to a
  36. message that is valid across all nodes.  Programs like TBBS, therefore,
  37. which do support the notion of detailed reply threading (each reply refers
  38. to some definite "parent" message) have to use a semi-guesswork algorithm
  39. which frequently leads to the wrong answer -- the latest message with a
  40. common Subject header is taken to be the parent, even when examination of the
  41. context by a human being indicates that the message is in reply to some
  42. earlier message.
  43.  
  44. The Usenet network, which shares much of its problem domain with Fidonet,
  45. solves these problems by tagging every outgoing message with a unique
  46. Message ID string.  Other messages can then refer to this Message ID and
  47. provide an unambiguous indication of which message, or messages, they are
  48. in reply to.
  49.  
  50. IFNA KLUDGE LINES "MESSAGE-ID" AND "IN-REPLY-TO"
  51.  
  52. Fidonet supports a general method for sending additional information embedded
  53. in a message known as the "IFNA kludge line".  This is a line of text beginning
  54. with the ASCII SOH character.  The characters following SOH are a word
  55. indicating the type of kludge line, and the remainder of the line contains
  56. information specific to that type.
  57.  
  58. This standard introduces two new types of kludge lines, the MESSAGE-ID line
  59. and the IN-REPLY-TO line.  These names, and the kludge line formats, are
  60. taken directly from Usenet.  MESSAGE-ID is used to tag an outgoing message
  61. with a unique string, different from any other message on the network.
  62. IN-REPLY-TO is used by threading message processors to specify the Message ID
  63. of the "parent" of a reply message.  These kludge lines are generated and
  64. interpreted by message editors; tosser/scanner and mailer products need only
  65. leave them undisturbed.  They are applicable to both regular network mail
  66. and Echomail.
  67.  
  68. FORMAT OF A MESSAGE ID -- MANDATORY
  69.  
  70. This format is drawn directly from Usenet; it may seem a little arcane, but
  71. is flexible enough to handle a large variety of needs.  Generally, a Message ID
  72. looks like this:
  73.     <unique-part@domain-name>
  74. The <, @, and > characters are fixed, and are used to help in parsing the
  75. Message ID.  The "unique-part" may consist of any characters -- the only
  76. requirement is that it be different for every message generated on a given
  77. node or point.  Possible implementations of "unique-part"s include a simple
  78. serial number, a date+time, or something completely different.
  79.  
  80. The "domain-name" must be a valid Internet domain name.  Luckily, every
  81. Fidonet system has a valid domain name now!  The format here is as follows:
  82.     The domain name of the node a:bbb/ccc is
  83.         Fccc.Nbbb.Za.FIDONET.ORG
  84.     and the domain name of the point a:bbb/ccc.ddd is
  85.         Pddd.Fccc.Nbbb.Za.FIDONET.ORG
  86. The periods, magic letters, and the magic name "FIDONET.ORG" make the
  87. domain name unique in the world.  Of course, Fidonet systems that already
  88. have a different domain name (e.g. circle.UUCP) are free to use that name
  89. instead.
  90.  
  91. A system which generates Message IDs must guarantee that no Message ID will
  92. be reused for at least two years.  This implies that if multiple message
  93. editors exist on a system they must cooperate at least to the extent of not
  94. using the same Message IDs for different messages.  In particular, a message
  95. editor that uses a simple serial number should make provision for the user
  96. to set the starting serial number to a value other than zero, so that different
  97. starting values can be used by different products.  Note that the numeric
  98. name of a .MSG file is >not< suitable as a unique-part, because it is neither
  99. unique nor permanent.
  100.  
  101. FORMAT OF A MESSAGE ID -- SUGGESTED
  102.  
  103. It is suggested, though not required, that the unique-part of all Message IDs
  104. consist only of decimal digits, and not more than 9 of these, so that the
  105. unique-part can be stored as a 32-bit signed integer.  A serial number
  106. scheme meets this standard, as does a Unix-style timestamp (seconds since
  107. midnight Jan 1 1970, Universal Time).  There many other possible schemes.
  108.  
  109.  
  110. CREATION OF THE IN-REPLY-TO LINE -- MANDATORY
  111.  
  112. The most important thing about the IN-REPLY-TO line is that the Message ID
  113. specified by it should be the actual Message ID of the message being replied
  114. to, and not a Message ID invented by the sender of the reply.  This implies
  115. that message editors which generate IN-REPLY-TO lines should be able to
  116. store the Message IDs of all incoming and locally generated messages for
  117. as long as the messages themselves remain on-line.  It is worth repeating,
  118. however, that there is nothing mandatory about generating the IN-REPLY-TO
  119. line at all.  A message editor may generate both MESSAGE-ID and IN-REPLY-TO
  120. lines, only MESSAGE-ID lines, or neither.
  121.  
  122. Due to problems with existing software, message editors should be prepared
  123. to receive (and either discard or display uninterpreted) IN-REPLY-TO lines
  124. which are >not< in standard format.  Standard format lines will have a <
  125. character just after the keyword and a > character at the end of the line.
  126.  
  127. DUPLICATE MESSAGE ELIMINATION
  128.  
  129. Usenet makes use of a "history file" which maintains the Message IDs of
  130. messages received in the last 15 days (this number is configurable by the
  131. sysop).  Fidonet has a similar scheme, but this is inherently less reliable,
  132. depending as it does on the exact layout of each message.  With MESSAGE-ID
  133. kludge lines, dupe eliminators can take advantage of them to help kill
  134. dupes once and for all, using existing mechanisms as a backup when needed.
  135.  
  136. IMPLICATIONS FOR USENET GATEWAYS
  137.  
  138. Currently, Fidonet<->Usenet gateways generate Message IDs for messages
  139. passing from Fidonet to Usenet, and discard them for messages passing the
  140. other way.  With this standard in place, such gateways should be modified
  141. to watch for MESSAGE-ID and IN-REPLY-TO kludge lines and translate them
  142. to Usenet "Message-ID:" and "In-Reply-To:" header lines, and vice versa.
  143. This will improve the behavior of threading systems like TBBS on the Fidonet
  144. side and 'notes' on the Usenet side.  Fidonet messages which don't have a
  145. MESSAGE-ID line will, of course, need to have one generated when passing over
  146. to Usenet, as is now the case.
  147.  
  148. IMPLEMENTATIONS
  149.  
  150. The Magpie tree-structured BBS is now being enhanced to provide Fidonet
  151. access to its users.  Magpie depends heavily on the notion of parent
  152. messages; every message on a Magpie system (except one) has a parent.
  153. Magpie/Fidonet systems will use the above technique to pass the parent
  154. information they need transparently through the Fidonet, so that incoming
  155. Fidonet messages can be connected at the correct place in the Magpie tree.
  156. (A backup algorithm similar to TBBS's will be used for Fidonet messages
  157. without parent information.)
  158.  
  159. We are publishing this information as a Fidonet technical comment in hopes
  160. that other Fidonet products will eventually incorporate all or part of this
  161. standard as well, and that it will eventually form part of a Fidonet
  162. Technical Standard.
  163.