Editor's Note: These minutes have not been edited. Here are the draft minutes of the RECEIPT working group. Comments are welcome and I'll produce updated minutes if required. Deadline for comments is July 5th, for the minutes July 12th. Many thanks to all who attended the meeting. It was fun working with you. And it's good to see concrete and useful results coming out. Keep up the good work, Urs. ----------------------------------------------------------------------------- Draft Minutes for Receipt IETF Working Group Co-Chairs: Urs Eppenberger <eppenberger@switch.ch>, Ned Freed <ned@innosoft.com> Minutes: Chris Newman <chris.newman@innosoft.com> 1. Open issues -------------- 1) Type for reporting user agent removed. Other types left in. (See Sec 3.1.2) Discussed at last IETF. 2) Question about the comparison between the address & Return-Path for disposition notification. What if no Return-Path header? Counts as a failure of the comparison. Strip source routes for comparison. What if multiple Return-Path headers? Could pick the first one. Is a protocol error, so can failure the comparison. Document editor will work out wording. There was also a suggestion on the list that multiple addresses be allowed in Disposition-Notification-To. Add text explaining why multiple addresses is a bad idea. Don't want to disallow it. Add more discussion about why automatic replies are dangerous in these cases. Document editor will work out wording. 3) List of dispositions. Added automatic dispositions. Distinction between generated by UA, and generated by user. Proposal: acknowledged (user-acknowledge) disposition which means the user has taken action to acknowledge the receipt of this message. The problem is that "displayed" could be automatically generated by UI. Alternative: a separate "manual-user-acknowledged" attribute and drop the "auto-*" dispositions. What if secretary responds for boss? Add a comment about using Sender/From distinction for human agents? No. Let drums document make the distinction. Just reference 822 for details on generating from/sender. (Section 3.2.6) Eliminate "denied"? "denied" is a way to say "you shouldn't have sent me this". This is useful, so we'll keep it. 4) Discussion about mailing list support and list recipients (3.2.7). There is a requirement by some U.S. government agencies to get a list of all recipients of a message -- is this a good mechanism? Don't try to solve this now. Is this mechanism proper for this draft? Defer for further study? Yes, this is a rat hole. 2. Work left for the I-D ------------------------ Jim Galvin (?) will produce more text for the security section Keith Moore will work on the Mailing list section and either approve the current text or provide better wording. All new text and additional comments have to be sent to the mailing list by July 15th. Roger Fajman will update the I-D by end of July. 3. Usage of RECEIPT work for EDI -------------------------------- It has been discussed how the prposed receipts can be used by the EDIINT working group. Their requirements are signed receipts. It has been accepted to extend the I-D if needed by EDIINT. (Later discussions after the meeting showed, that they will most probably define a new notification type signed-receipt and therefore will use the NOTARY framework but be independent of NOTARY.) 4. Other extensions ------------------- Perhaps we should add parameters to disposition-notification? Concensus that we need parameters. One header or two headers? A sub- group will make a solid proposal by July 15th. Ned Freed will work on it. 5. Other work related to RECEIPT -------------------------------- Vacation- / Change of address - notifications The group decided, that these are not receipts. A data format might be needed to support automated handling. The tasks are not close enough to the current charter of the working group to justify inclusion. If someone wants it bad enough, he can come up with a proposal and publish it as an I-D and get a working group started on it.