Editor's note:  These minutes have not been edited.

Minutes for the
RECEIPT Working Group
LA IETF

Most of the meeting was devoted to reviewing the current receipts draft and reaching closure on the various open issues left over from the last meeting. 

The most important issue considered by the group was that of where receipts should be sent. The obvious choices are to return the receipt to either the envelope originator address appearing in the Return-Path or to the address appearing in the Disposition-Notification-To (DNT) heading field. 

The group hit upon the clever solution of defining the receipt recipient in the DNT header. However, if the Return-Path is specified and different from DNT field, the MUA should *not* send a receipt without user confirmation. This protects users from receipt requests sent to a list in order to get a roster, because the list exploder will change the envelope originator address but not the DNT field.

A question was raised regarding section 3.3.5 in the draft, which states that if a Message-ID is present in the original, it SHOULD be returned in the receipt. The group decided to change the SHOULD to MUST. 

Section 3.2.1 in the draft states that the Reporting-UA field is required. The group decided that the Reporting-UA field should be optional. 

The group decided to get rid of all of the various -type subfields. 

The various disposition types to include in the base document were considered. The group decided on three positive ones (user manually confirmed, user automatically confirmed, robot confirmed) and four negative ones (terminated, expired, denied, obsoleted). The document editor (Roger Fajman) was tasked with coming up with good names for the positive ones. 

The group considered the question of recommended behavior for list servers. There are several valid scenarios: 

- - Listserver sends a receipt to the sender, and strips the receipt request 
when sending to list members.

- - Listserver sends nothing, passes the request, and recipients send receipts 
directly to the sender.

- - Listserver passes the request to list members, recipients send receipts 
back to the list, and it correlates and sends a single receipt to the sender.

Keith Moore agreed to come up with language for the Security Considerations section that outlines the possibilities and their implications. 

The question was raised of what to say about signed receipts. This is already covered in RFC1892.

Finally, the group agreed to the following timeline: 

- - New draft by 4/10
- - Another revised draft by end of April for a 2-week last call - - Jim will write a privacy consideration paragraph. 

- ------- =_aaaaaaaaaa0--

------- End of Forwarded Message