home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-palme-newfields-info-00.txt < prev    next >
Text File  |  1997-07-07  |  7KB  |  183 lines
  1. Network Working Group                                       Jacob Palme
  2. Internet Draft                                 Stockholm University/KTH
  3. draft-palme-newfields-info-00.doc
  4. IETF status: To become an informational RFC
  5. Expires: January 1998                                         July 1997
  6.  
  7.  
  8.  
  9.  
  10. Advise on the implementation of In-Reply-To, References and Supersedes
  11. e-mail and netnews headers
  12.  
  13.  
  14.  
  15. Status of this Document
  16.  
  17.  
  18. This document is an Internet-Draft. Internet-Drafts are working
  19. documents of the Internet Engineering Task Force (IETF), its areas, and
  20. its working groups. Note that other groups may also distribute working
  21. documents as Internet-Drafts.
  22.  
  23. Internet-Drafts are draft documents valid for a maximum of six months
  24. and may be updated, replaced, or obsoleted by other documents at any
  25. time. It is inappropriate to use Internet-Drafts as reference material
  26. or to cite them other than as ``work in progress.''
  27.  
  28. To learn the current status of any Internet-Draft, please check the
  29. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  30. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32. ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Abstract
  36.  
  37. Separate Internets standards documents define the e-mail headers
  38. In-Reply-To, References, Supersedes and Expires. This document,
  39. which is an informational RFC, gives some advise on the
  40. implementation of these features.
  41.  
  42.  
  43. Table of Contents
  44.  
  45. 1. User interface
  46. 2. Hard and soft Supersedes
  47. 3. Data base
  48. 4. References
  49. 5. Author's Address
  50.  
  51.  
  52. 1.    User interface
  53.  
  54. The fields "In-Reply-To", "References" and "Supersedes" are all used to
  55. convey information about references between different e-mail messages
  56. or netnews articles.
  57.  
  58. The best way to implement these fields is to tell the recipient that
  59. two messages reference each other, and to make it easy for readers to
  60. traverse threads (series of linked messages) up and down.
  61.  
  62. In the particular case of "Supersedes", a user who has not yet read
  63. either the old or the new version, may be shown only the new version as
  64. a new message, but with methods to easily find the old version.
  65.  
  66. A good way to show this information to users is to show the "In-Reply-To",
  67. "Supersedes" and "References" fields and allow the user to click
  68. on the parameters of these fields to get to the referred-to messages.
  69. Additionally, it is useful to add reverse fields to message headers,
  70. i.e. "Replied-By", "Referenced-By" and "Superseded-By". This allows a
  71. user, when reading a message, to see if someone else has already
  72. replied, and it allows users to traverse threads downwards and not only
  73. upwards. Such reverse fields should not be sent in e-mail, they are
  74. just for local handling in user mailbox databases.
  75.  
  76.  
  77. 2.    Hard and soft Supersedes
  78.  
  79. By a hard supersedes is meant a Supersedes which causes deletion of the
  80. supersedes message. By a soft supersedes is meant a Supersedes which
  81. still keeps both messages, and allows a user to see and use the
  82. reference between them, similarly to In-Reply-To and References.
  83.  
  84. Supersedes should be implemented as soft supersedes. Some
  85. implementations, especially in Usenet News, do however implement it as
  86. hard supersedes.
  87.  
  88. Hard supersedes has the same security problem as the Cancel command of
  89. Usenet News. They can be used to malicuosly deleting other people's
  90. messages. Use of strong authentication of the author can reduce this
  91. risk.
  92.  
  93.  
  94. 3.    Data base
  95.  
  96. In order to implement this, a data base is needed which, given a
  97. Message-ID, can find the message which this Message-ID refers to. This
  98. data base has a very simple structure, just a single value mapped to
  99. one or more messages. Note, however, that the same message can be
  100. stored in more than one mailbox, so the data base should not be
  101. restricted to only one location for each Message-ID.
  102.  
  103. Every time a message is added, moved, copied, deleted or purged, this
  104. data base need to be updated.
  105.  
  106. The main problem with these kinds of Message-ID data bases is that they
  107. tend to become very large with time, and they easily collect garbage
  108. (Message-ID-s of messages not any more available in the mailbox data
  109. base).
  110.  
  111. The two most common methods to implement such data bases are:
  112.  
  113. (a) Implement a large data base, but with some method of garbage
  114.     collection to avoid unlimited growth of the data base.
  115.  
  116. (b) Implement a smaller data base, where all objects are deleted
  117.     after a certain time, for example a few months.
  118.  
  119. With implementation method (b), information about the references in the
  120. form of "In-Reply-To", "References", "Supersedes", "Replied-By",
  121. "Referenced-By" and "Superseded-By" should also be stored in the
  122. message headers themselves. The reason method (b) works is that it is
  123. very uncommon that a message has a reference to other than very recent
  124. messages. Thus, the lack of "Replied-By", "Referenced-By" and
  125. "Superseded-By" headers in these very uncommon cases is acceptable.
  126.  
  127. The advantage with method (b) is that a complex garbage collection
  128. method, as for method (a), is not needed. A much simpler garbage
  129. collection method, just removing records after a certain expiration
  130. time, can be used instead.
  131.  
  132.  
  133. 4.    References
  134.  
  135. Ref.            Author, title
  136. ---------       --------------------------------------------------------
  137.  
  138. [AUTOLOOP]      J. Palme: "Loop control for the Auto-Submitted e-mail
  139.                 header", draft-palme-autosub-03.txt, July 1997.
  140.  
  141. [MIME1]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
  142.                 Extensions (MIME) Part One: Format of Internet Message
  143.                 Bodies", RFC 2045, December 1996.
  144.                 .
  145. [MIME2]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
  146.                 Extensions (MIME) Part Two:  Media Types", RFC 2046,
  147.                 December 1996.
  148.  
  149. [MIME3]         K. Moore, "MIME (Multipurpose Internet Mail Extensions)
  150.                 Part Three:  Message Header Extensions for Non-ASCII
  151.                 Text", RFC 2047, December 1996.
  152.  
  153. [MIME4]          N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
  154.                 Mail Extensions (MIME) Part Four:  Registration
  155.                 Procedures", RFC 2048, January 1997.
  156.  
  157. [MIME5]         "Multipurpose Internet Mail Extensions (MIME) Part Five:
  158.                 Conformance Criteria and Examples", RFC 2049, December
  159.                 1996.
  160.  
  161. [NEWFIELDS]     J. Palme: "The Auto-Submitted, Supersedes and Expires
  162.                 E-mail Headers", draft-ietf-mailext-new-fields-08.txt,
  163.                 July 1997.
  164.  
  165. [NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
  166.                 USENET messages", RFC 1036, December 1987.
  167.  
  168. [RFC822]        D. Crocker: "Standard for the format of ARPA Internet
  169.                 text messages." STD 11, RFC 822, August 1982.
  170.  
  171. [SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
  172.                 821, August 1982.
  173.  
  174.  
  175.  
  176. 5.    Author's Address
  177.  
  178. Jacob Palme                          Phone: +46-8-16 16 67
  179. Stockholm University and KTH         Fax: +46-8-783 08 29
  180. Electrum 230                         E-mail: jpalme@dsv.su.se
  181. S-164 40 Kista, Sweden
  182.  
  183.