home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mailext-new-fields-07.txt < prev    next >
Text File  |  1997-05-27  |  13KB  |  307 lines
  1. Network Working Group                                     Jacob Palme
  2. Internet Draft                               Stockholm University/KTH
  3. <draft-ietf-mailext-new-fields-07.txt>                         Sweden
  4. Category-to-be: Proposed standard                            May 1997
  5. Expires October 1997
  6.  
  7.  
  8.              The Supersedes and Expires e-mail headers
  9.  
  10.  
  11. Status of this Memo
  12.  
  13. This document is an Internet-Draft.  Internet-Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its
  15. areas, and its working groups.  Note that other groups may also
  16. distribute working documents as Internet-Drafts.
  17.  
  18. Internet-Drafts are draft documents valid for a maximum of six
  19. months and may be updated, replaced, or obsoleted by other
  20. documents at any time.  It is inappropriate to use Internet-
  21. Drafts as reference material or to cite them other than as
  22. ``work in progress.''
  23.  
  24. To learn the current status of any Internet-Draft, please check
  25. the ``1id-abstracts.txt'' listing contained in the Internet-
  26. Drafts Shadow Directories on ftp.is.co.za (Africa),
  27. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  28. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  29.  
  30. This memo provides information for the Internet community. This
  31. memo does not specify an Internet standard of any kind, since
  32. this document is mainly a compilation of information taken from
  33. other RFC-s.. Distribution of this memo is unlimited.
  34.  
  35.  
  36. Abstract
  37.  
  38. This memo introduces two new e-mail (RFC 822) headers,
  39. Supersedes, and Expires. The postscript version of this IETF draft 
  40. shows the differences from its previous version.
  41.  
  42.  
  43. Differences from previous version
  44.  
  45. Differences between version 04 and version 05
  46.  
  47. The syntax of the Supersedes header has been changed from 1#msg-id to 
  48. 1*msg-id, i.e. LWSP instead of comma between multiple values.
  49.  
  50. Difference between version 05 and version 06
  51.  
  52. The main change here is that the standard now specifies the same 
  53. recommended practice in both e-mail and netnews. The current 
  54. difference in practice in netnews is described and allowed but not 
  55. recommended.
  56.  
  57. The text about the Supersedes header has thus been modified so that 
  58. recommended practice is now to allow more than one parameter to this 
  59. header in both e-mail and netnews. This means that many netnews 
  60. servers as clients may for some time not handle Supersedes with more 
  61. than one parameter correctly, but after discussion with some leading 
  62. Usenet News software developers, this has been found to be better 
  63. than to specify different behavior in the standard for news and e-
  64. mail. Usenet News software developers can be expected to modify their 
  65. software.
  66.  
  67. The other major difference between netnews and e-mail, that 
  68. supersedes causes a hard delete in netnews but a soft delete in 
  69. netnews, is handled by recommending soft supersedes but allowing hard 
  70. supersede.
  71.  
  72. Difference between version 06 and version 07
  73.  
  74. Added the sentence "There is no requirement that a user agent must 
  75. suppress expired messages or make them inaccessible to their owners."
  76.  
  77. Added the following clause: "Note: The Message-ID of a superseding 
  78. message MUST be different from the Message-ID of the superseded 
  79. message. The Message-ID of the superseded message is used as value in 
  80. the "Supersedes:" header, not in the Message-ID of the superseding 
  81. message."
  82.  
  83. Also some trivial editorial changes.
  84.  
  85.  
  86. 1. Introduction
  87.  
  88. This memo introduces two new headers for Internet e-mail (RFC 822) 
  89. headers which will enhance the e-mail service in various ways. The 
  90. names of the new headers are: Supersedes and Expires.
  91.  
  92.  
  93. 2. Supersedes
  94.  
  95. Syntax: supersedes-field = "Supersedes" ":" 1*msg-id
  96.  
  97. The message identifiers (msg-id) use the msg-id format, as defined in 
  98. RFC 822 [1].
  99.  
  100. The Supersedes header identifies previous correspondence, which this 
  101. message supersedes. A user agent is expected to handle this field in 
  102. much the same way as the In-Reply-To and References header.
  103.  
  104. (a) Thus, this header does not imply any mandatory deletion of the 
  105. previous correspondence.
  106.  
  107. (b) User agents which provide user commands for getting from a reply 
  108. to the replied-to message (or for getting from a replied-to 
  109. message to its replies), MAY provide similar commands for getting 
  110. from a superseding message to the superseded message (or for 
  111. getting from a superseded message to its superseding version).
  112.  
  113. (c) User agents MAY normally show the recipient both the previous and 
  114. the superseding message. If, however, both the previous and the 
  115. superseding message have arrived, both having the same author, 
  116. but the user has not yet seen either of them, a user agent MAY 
  117. show only the superseding message, but also show the supersedes-
  118. field to inform the recipient that this message supersedes a 
  119. previous message.
  120.  
  121. (d) User agents might issue a warning if a superseding message 
  122. arrives with a different author than the author of the superseded 
  123. message. This can be done by checking the "From:" header, or, if 
  124. PEM [6], PGP [7] or MOSS [8] signatures are available, by 
  125. checking the digital signature.
  126.  
  127. The above procedure is called a "soft supersedes".
  128.  
  129. Some user agents or servers may delete the old version of a message 
  130. when a new version arrives, which is called a "hard supersedes". Hard 
  131. supersedes is NOT RECOMMENDED practice, but common, especially in 
  132. netnews where servers want to save disk space.
  133.  
  134. When this is written (1997) some netnews agents (servers and clients) 
  135. cannot handle Supersedes with more than one previous articles listed 
  136. as parameters. They usually ignore the Supersedes header in this 
  137. case, and treats the new article as a separate article, not related 
  138. to the superseded article. Implementors of netnews agents SHOULD 
  139. modify their software to be able to handle Supersedes with more than 
  140. one previous article as parameter, but for some time, many agents may 
  141. not be able to handle Supersedes with more than one parameter. A 
  142. gateway from e-mail to news MAY because of this delete all but the 
  143. first parameter of this attribute when conveying messages from e-mail 
  144. to news, BUT such a practice should be temporary only for one or two 
  145. years until news agents have been modified.
  146.  
  147. Warning: This header MUST be spelled "Supersedes" and not 
  148. "Supercedes". Mailers MUST never generate "Supercedes" but MAY accept 
  149. "Supercedes" in input.
  150.  
  151. Note: The Message-ID of a superseding message MUST be different from 
  152. the Message-ID of the superseded message. The Message-ID of the 
  153. superseded message is used as value in the "Supersedes:" header, not 
  154. in the Message-ID of the superseding message.
  155.  
  156.  
  157. 3. Expires:
  158.  
  159. Syntax: Expires-field = "Expires" ":" date-time
  160.  
  161. The Expires header indicates a date-time, at which this message 
  162. expires. The field can be used both to limit and to extend the life 
  163. of a message. User agents and servers which employ automatic purging 
  164. of old messages MAY let this field influence the purging process. 
  165. There is no requirement that a user agent must suppress expired 
  166. messages or make them inaccessible to their owners.
  167.  
  168. Note: This header is also defined, with similar meaning, in netnews 
  169. [5] and in X.420 [4].
  170.  
  171.  
  172. 4. Relation to X.400 gateways versus Netnews
  173.  
  174. Similar headers to those defined in this document are also defined in 
  175. recommendations for gatewaying [2] between X.400 [4] and Internet 
  176. mail. However, those recommendations are only valid for gateways. By 
  177. defining the fields here, the fields are made available for general 
  178. Internet e-mail usage. This document also gives fuller descriptions 
  179. of the fields than is given by the X.400 gatewaying recommendations 
  180. [2].
  181.  
  182. Unfortunately, the two new headers specified here have different 
  183. names in  Internet-X.400 gatewaying standards [2] and in netnews.
  184.  
  185. RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is 
  186. usually called "Supersedes:" (not specified in RFC 1036 [5] but in 
  187. common usage).
  188.  
  189. RFC 1327 gives the name "Expiry-Date:" for what in netnews is called 
  190. "Expires:" (as specified in RFC 1036).
  191.  
  192. Because compatibility with netnews is more important than with X.400, 
  193. the netnews names of the fields are proposed here.
  194.  
  195. Future versions of RFC 1327 (the MIXER document) may choose to 
  196. specify the use of "Supersedes" and "Expires" also in gatewayed 
  197. messages from X.400.
  198.  
  199.  
  200. 5. Security considerations
  201.  
  202. 5.1 "Supersedes" security considerations
  203.  
  204. If a mail or news server or receiving user agent suppresses showing 
  205. of superseded messages, the "Supersedes:" feature might be used 
  206. maliciously to suppress messages written by other people. To reduce 
  207. the risk for this, it is RECOMMENDED that user agents give a warning 
  208. to the recipient when a superseding message has a different "From:" 
  209. name than the superseded message.
  210.  
  211. A moderately clever forger can of course circumvent this by sending 
  212. messages with falsified "From:" field and even falsified SMTP 
  213. senders. User agents supporting PEM [6] or PGP [7] can require and 
  214. check digital signatures to reduce also this risk.
  215.  
  216. Another possible risk with "Supersedes:" is that it allows people to 
  217. "change their minds", possibly changing the meaning of replies to 
  218. them. Example: A message with the text "Do you like your mother" gets 
  219. the reply "Yes, very much", and then the original message might be 
  220. changed to "Do you like Hitler", changing the meaning of the reply. 
  221. Note, however, that the "In-Reply-To" or "References" headers in the 
  222. reply refers to the Message-ID of the original message, not of the 
  223. superseding message. Thus, a user agent can avoid this problem by 
  224. designing the user interface so that replies are not shown as 
  225. referring to the superseding message, when they use the Message-ID of 
  226. the superseded message.
  227.  
  228. Also, since "Supersedes:" in e-mail does not actually cause deletion 
  229. of the superseded message, recipients can look up the superseded 
  230. message to see if the author has changed his mind. In general, it is 
  231. not illegal or unethical to change your mind, rather, it shows your 
  232. openness to new ideas and willingness to listen to the arguments of 
  233. other people.
  234.  
  235. The fact that Supersedes in e-mail does not enforce deletion of the 
  236. supersedes message, but that Supersedes in many existing netnews 
  237. implementations does enforce such deletion, may in some circumstances 
  238. cause security problems.
  239.  
  240. 5.2 "Expires" security considerations
  241.  
  242. One intention of "Expires" is to help recipients avoid seeing 
  243. messages with information which is not any longer valid. There may of 
  244. course be cases where a user might want to see an expired message 
  245. (e.g. a user might sometimes want to be informed of a meeting, even 
  246. after the time of the meeting). This could possibly be solved by 
  247. having different kinds of "Expires" for different expiration causes, 
  248. however, this complexity is not felt needed at present. A user agent 
  249. can of course be designed to inform the recipient also of expired 
  250. messages, and allow the recipient the choice of reading them or not. 
  251. This standard does, therefore, not require user agents to make 
  252. expired messages inaccessible.
  253.  
  254.  
  255. 6. Acknowledgements
  256.  
  257. Many people have helped with the production of this document. Of 
  258. special value have been H. T. Alvestrand, S. Kille, K.Moore, P. 
  259. Overell and K. Weide.
  260.  
  261. 7. References
  262.  
  263.   [1]  D. Crocker: "Standard for the format of ARPA Internet text
  264.        messages." STD 11, RFC 822, August 1982.
  265.  
  266.   [2]  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021
  267.        and RFC 822",  RFC 1327 May 1992.
  268.  
  269.   [3]  ISO/ITU: "Message Handling Systems", ISO international standard
  270.        10021, ITU  recommendation X.400.
  271.  
  272.   [4]  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
  273.        Messaging System, ISO international standard 10021-7, ITU
  274.        recommendation X.420.
  275.  
  276.   [5]  M.R. Horton, R. Adams: "Standard for interchange of USENET
  277.        messages", RFC 1036, December 1987.
  278.  
  279.   [6]  S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy
  280.        Enhancement for Internet Electronic Mail: Part I-IV, 
  281.        RFC 1421-1424, February 1993.
  282.  
  283.   [7]  Gary B. Edstrom: Frequently Asked Questions; alt.security.pgp.
  284.        Available from faq servers, such as URL: gopher:
  285.        //nutmeg.ukc.ac.uk.:70/11/.archive/uunet/usenet/news.answers/
  286.        pgp-faq.
  287.  
  288.   [8]  S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
  289.        Services", RFC 1848, March 1995.
  290.  
  291.  
  292. 7. Author's address
  293.  
  294.   Jacob Palme                          Phone: +46-8-16 16 67
  295.   Stockholm University/KTH             Fax: +46-8-703 90 25 (not fast)
  296.   Electrum 230                         E-mail: jpalme@dsv.su.se
  297.   S-164 40 Kista, Sweden
  298.  
  299.  
  300.  
  301.  
  302. 4
  303.  
  304.  
  305.  
  306.  
  307.