home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / receipt-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  4KB  |  101 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Alireza Bahreman/Bellcore
  5.  
  6. Minutes of the Receipt Notifications for Internet Mail Working Group
  7. (RECEIPT)
  8.  
  9. RECEIPT met as a BOF at the 33rd IETF on Monday, 17 July.  The group has
  10. since become a working group.
  11.  
  12.  
  13. Draft Agenda
  14.  
  15.    o Select author for first Internet-Draft
  16.    o What do we need exactly?
  17.    o Technical proposal
  18.    o Usage guidelines
  19.    o Charter
  20.  
  21.  
  22. Author
  23.  
  24. The author was identified as Roger Fajman.  He will be producing the
  25. first draft within a month.
  26.  
  27.  
  28. What Do We Need?
  29.  
  30. The focus of this group is to specify a standard mechanism to request
  31. and transfer read receipts, as well as advising the users on security
  32. and privacy issues related to utilizing these mechanisms.  The receipt
  33. is completely voluntary on the recipient side, meaning they are not
  34. obliged to return a receipt.
  35.  
  36. Some suggestions were made by the audience to provide notifications
  37. specific to non-receipt, as well as scenarios where a message is passed,
  38. deleted, or otherwise ignored.  The term `receipt' is overloaded and it
  39. may be helpful to either clearly specify the meaning or use other terms
  40. such as `disposition'.  The term `presentation' was also suggested in
  41. place of `receipt' notification.  The draft document will clearly define
  42. the meaning of the term `receipt'.
  43.  
  44. The security of the receipt notification mechanism was questioned.  In
  45. particular the ability to repudiate receipts, or otherwise create false
  46. receipts.  The group decided not to address security based on the
  47. lessons learned by other security groups' efforts being delayed as a
  48. result of addressing security issues.  It was decided that the security
  49. concerns will be addressed in a second phase of the working group.
  50.  
  51. Discussion was conducted on applicability of this service for specific
  52. communities in which certain policies can be locally enforced to
  53. automate the processing or handling of receipts.  None the less, it was
  54. argued that this mechanism is a `sender' service, in that it is helping
  55. the sender decide what happened to the message sent.  The service must
  56. be least intrusive to the recipient.
  57.  
  58.  
  59. Technical Proposal
  60.  
  61. On the NOTARY distribution list a first technical solution has been
  62. sketched.  The read receipt request is transmitted using a new header in
  63. the message.  In the case where the message has multiple recipients and
  64. only for some of them a read receipt is requested, then two messages are
  65. created, one for the recipients with a read receipt request in the
  66. header and one one without.  The confirmation is generated based on the
  67. NOTARY work using multipart/report content type.
  68.  
  69. It was deemed important for the mechanism to interoperate with all other
  70. mail systems including gateways, etc.
  71.  
  72.  
  73. Usage Guidelines
  74.  
  75. It was agreed that it is critical to explicitly identify and specify
  76. what it entails to receive and return a read receipt notification for
  77. all parties involved.  This might well be the biggest part of the
  78. document.
  79.  
  80. The document will also include documented (with diagrams) scenarios as
  81. to what each party can expect at each phase of the protocol, from
  82. requesting a receipt to its transfer from the recipient to the sender.
  83. The document will specify all phases including MTA delivery, message
  84. storage, and UA display of message subject line.
  85.  
  86. The group is in consensus on protecting the privacy of recipients
  87. against automated receipt generation.  For example, the recipient may
  88. wish to respond to a message and acknowledge receipt at a later date.
  89.  
  90.  
  91. Charter
  92.  
  93. The mailing list will be created and interested people must request to
  94. be subscribed.  An archive will also be maintained.  The details are not
  95. available yet but will be announced soon.
  96.  
  97. The charter will be sent to the mailing list.  The first draft will be
  98. available by 17 August 1995.  The draft will be reviewed by the next
  99. IETF. The working group is expected to have a lifetime of one year.
  100.  
  101.