CURRENT_MEETING_REPORT_ Reported by Ned Freed/Innosoft International Minutes of the Notifications and Acknowledgements Requirements Working Group (NOTARY) The NOTARY Working Group met on Monday 25 July and again on Tuesday 26 July in Toronto. The meeting began with a presentation by Keith Moore of the new delivery status notification format specification (draft-ietf-notary-mime-delivery-01.txt) that combines elements of both Keith Moore's and Greg Vaudreuil's earlier efforts. In brief, the format consists of a new MIME multipart subtype called multipart/report. This multipart object always contains three parts: 1. An initial part containing human readable text describing the delivery status notification. 2. A second, machine-readable part containing the specifics of the recipients and their respective delivery status values. 3. A third part containing either the entire content of the original message the report applies to or just the headers of that message. After the presentation, discussion focused on various outstanding issues in the new document. o The requirement that the second part be encoded using only 7-bit characters was discussed and found to be acceptable. The use of RFC 1522 encoded words in comment fields was recommended as a means of working around this limitation and the specification will be altered to allow for this. o The text describing the distinction between a final MTA and the remote MTA was thought to be somewhat unclear. Input from the working group to clarify this text was sought. o Currently the message-id of the original message is present in the third part of the status notification. The idea of providing it as a field in in the second part was discussed but there was no consensus to support such a change. o Case sensitivity, whitespace handling, and line continuation issues were discussed and the specification will be clarified accordingly. o The specification makes use of an assortment of abbreviations, and excessive use of abbreviations presents a problem for novice users. The abbreviation ``MTA'' was found to be quite acceptable and a better choice than either their expanded form or a less precise term (e.g. mailer, switch). The abbreviation ``MTS'' was found to be less acceptable but no acceptable alternative was found. Others, such as ``rcpt'' for ``recipient,'' will be expanded in the next draft of the specification. o There is no place for arrival time information in the second part at present. An optional field will be added to store this information. o The scope of a single status notification (multiple messages, multiple recipients, neither, or both) was unclear. Additional prose was crafted to clarify matters so that a single notification can readily be seen to apply to only a single message but possibly multiple recipients. o The list of delivery actions (failed, delayed, delivered, relayed) is not expandable. The idea of making this list expandable was raised but rejected. o The handling of missing or unknown MTS types was discussed. The group agreed that X- values should be allowed as valid MTS types. o Security and confidentiality issues were discussed and Gregory Sheehan provided some additional prose clarifying some of the concerns in this area. o Currently there is no field in a delay report that indicates how long the message can continue to wait before being returned. A field for this information will be added. o The first part can optionally be a multipart/alternative object, allowing for readable status notifications in multiple languages. The idea of allowing the second part to be a multipart structure as well was discussed but rejected. o The handling of status notification requests by mailing list software was discussed and it was agreed that additional prose detailing the various available options is needed. o The insertion of original recipient address information at an intermediate transfer point is not allowed by the present specification. There was some agreement that such insertions should be allowed on the grounds that any earlier address information is better than nothing, but no agreement as to the specifics of this was reached. Discussion of the delivery status notification format specification concluded with a protracted discussion of error codes. The current document uses an extended SMTP error code model. Greg Vaudreuil did some fairly exhaustive cataloguing work to try to come up with a more comprehensive error code scheme. Greg presented a preliminary version of this work at the meeting and it was agreed that a more complete specification would be sent to the list as soon as possible. There was no consensus as to the best way to handle error codes. It is generally recognized that the SMTP error codes are being stretched to, if not past, the breaking point by this work and that some extension scheme will be needed eventually. However, there was also some agreement that defining a completely new error code model would be a major piece of work, possibly beyond the purview of the group, and quite likely taking far longer than the group would be prepared to wait. The group concluded with a discussion of future work items. The notification request SMTP extension was discussed briefly and a new methodology for controlling return of content was outlined. (No new draft of this document was available at the time of this meeting.) The use of this format for read receipts is a definite possibility, and Greg agreed to put together an initial draft of a specification for read receipts. It was agreed that standardizing a way to handle read recipients is a good idea, even though their use in practice is a very inflammatory matter in some circles. The handling of so-called ``vacation'' and ``change of address'' messages were discussed, but not extensively due to lack of time. Some group members saw vacation notices as a subtype of delay notifications, while some did not. John Myers agreed to begin work on a document describing vacation messages.