CURRENT_MEETING_REPORT_ Reported by Alireza Bahreman/Bellcore Minutes of the Receipt Notifications for Internet Mail Working Group (RECEIPT) RECEIPT met as a BOF at the 33rd IETF on Monday, 17 July. The group has since become a working group. Draft Agenda o Select author for first Internet-Draft o What do we need exactly? o Technical proposal o Usage guidelines o Charter Author The author was identified as Roger Fajman. He will be producing the first draft within a month. What Do We Need? The focus of this group is to specify a standard mechanism to request and transfer read receipts, as well as advising the users on security and privacy issues related to utilizing these mechanisms. The receipt is completely voluntary on the recipient side, meaning they are not obliged to return a receipt. Some suggestions were made by the audience to provide notifications specific to non-receipt, as well as scenarios where a message is passed, deleted, or otherwise ignored. The term `receipt' is overloaded and it may be helpful to either clearly specify the meaning or use other terms such as `disposition'. The term `presentation' was also suggested in place of `receipt' notification. The draft document will clearly define the meaning of the term `receipt'. The security of the receipt notification mechanism was questioned. In particular the ability to repudiate receipts, or otherwise create false receipts. The group decided not to address security based on the lessons learned by other security groups' efforts being delayed as a result of addressing security issues. It was decided that the security concerns will be addressed in a second phase of the working group. Discussion was conducted on applicability of this service for specific communities in which certain policies can be locally enforced to automate the processing or handling of receipts. None the less, it was argued that this mechanism is a `sender' service, in that it is helping the sender decide what happened to the message sent. The service must be least intrusive to the recipient. Technical Proposal On the NOTARY distribution list a first technical solution has been sketched. The read receipt request is transmitted using a new header in the message. In the case where the message has multiple recipients and only for some of them a read receipt is requested, then two messages are created, one for the recipients with a read receipt request in the header and one one without. The confirmation is generated based on the NOTARY work using multipart/report content type. It was deemed important for the mechanism to interoperate with all other mail systems including gateways, etc. Usage Guidelines It was agreed that it is critical to explicitly identify and specify what it entails to receive and return a read receipt notification for all parties involved. This might well be the biggest part of the document. The document will also include documented (with diagrams) scenarios as to what each party can expect at each phase of the protocol, from requesting a receipt to its transfer from the recipient to the sender. The document will specify all phases including MTA delivery, message storage, and UA display of message subject line. The group is in consensus on protecting the privacy of recipients against automated receipt generation. For example, the recipient may wish to respond to a message and acknowledge receipt at a later date. Charter The mailing list will be created and interested people must request to be subscribed. An archive will also be maintained. The details are not available yet but will be announced soon. The charter will be sent to the mailing list. The first draft will be available by 17 August 1995. The draft will be reviewed by the next IETF. The working group is expected to have a lifetime of one year.