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 8 December at the 31st IETF. Agenda o Agenda approval o Document bashing, multipart/report document: ``The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages'' o Document bashing, MIME-delivery document: ``An Extensible Message Format for Delivery Status Notifications'' o Document bashing, SMTP-DRPT document: ``SMTP Service Extension for Delivery Status Notifications'' o All other business In this case, document bashing means exactly what it sounds like: o The group will go through the document page by page. o Comments on ambiguous language, unclear figures and spelling misteaks are in order. o Suggestions for grand redesigns are out of order. o A copy will be marked up with what time each page should be started in order to finish on time. If the document review is finished ahead of time, the group can discuss other fun things like receipt reports (no activity since last time), vacation notices (same comment) and so on. Multipart/Report Document Greg Vaudreuil presented a brief description of the multipart/report format. Harald Alvestrand pointed out that the third part of such objects, which is used for returned content, is not constrained in any way in terms of what it can be. The group decided that this is appropriate in this specification, but that other specifications using this format should be able to restrict what is allowed in this part. The group then agreed that this document should be submitted for consideration as a Proposed Standard by the IESG after this change is made. MIME-Delivery Document Discussion turned to the delivery report format specification. Keith began the discussion by presenting some issues reported by Eric Allman that have turned up in the context of implementation of this format in sendmail. The first issue was that of MTS type. This concept has proved to be difficult to understand. Keith proposed removing the concept of MTS type and replacing it with separate type indicators for the status code and address fields, and the working group concurred. A suggestion was made to replace the use of the term ``final MTA'' with ``reporting MTA.'' The working group agreed that this change is a good idea. Jim Conklin noted that various terms defined in RFC 822 were used without referring to their definition in RFC 822. Keith agreed to add the proper references to RFC 822 to the specification. The definition and use of xtext was then discussed. It was pointed out that the sharp sign used as a quoting character is a national variant character, which could be problematic in some environments. A prolonged discussion ensued, where various alternatives, e.g., use of quoted-printable across the entire notification body, use of quoted-printable on a per-field basis, and so on. Various problems were found with the alternatives, e.g., that the cross-body encoding does not allow for pure binary material, use of local quoted-printable breaks the comment usage now specified in the draft, and so on. The issue was eventually tabled for later discussion as time permits. The ``received-from'' field name will be changed to ``received-from-MTA.'' A suggestion was made to change the name to ``previous-MTA,'' but this was seen as actually being less clear. Discussion then turned to the issue of final versus remote fields. It was generally agreed that the two sets of fields are useful for both MTAs and status codes. The distinction between a final recipient and a remote recipient, however, seems less clear. A complex debate then ensued, where all of the various recipient fields (original, RFC 822 format, final, remote) were bandied about. The conclusion was to specify a typed earliest recipient field as the basic field that is returned, with Greg raising an objection that the field should be required to be in RFC 822 format. The action field was then discussed. There was some sentiment that the set of values should be extensible, but no decision was made to make them extensible. Keith then presented the latest status code proposal. In brief, the idea is to currently define a single digit status code based on the first digit of SMTP codes (2, 4, or 5), and subsequently to develop a standards track specification that provides more detailed status codes. This proposal was approved by the working group. The name of the ``date'' field was changed to ``last-attempt-date.'' It was observed that with the ``final-log-id'' field, implementations use all sorts of identifiers and that there is no single clear identifier to put here. The working group decided to remove this field in favor of implementations using whatever ``X-'' fields they find appropriate. The group then moved on to consider remote status codes. Various people argued against these codes. Ned Freed pointed out that such codes give the appearance of precision when in fact they may not be. John Myers countered by pointing out that such information is very useful for trouble ticket applications, and proposed modifying this field to make it ``write only'' remote-MTA-specific information. Harald Alvestrand then pointed out that this proposal will be much easier to accept if SMTP codes that people already understand could be included. After prolonged discussion, Harald recommended tabling this issue and discussing it further on the list. Keith Moore will take the discussion as input and try to clarify the text, which will then be discussed on the mailing list. Harald Alvestrand pointed out that the security section needs to be enhanced to point out that various fields may be dropped due to security concerns. Certain fields need to be required, e.g., action and status, but practically everything else may be a candidate for removal by security firewalls. SMTP-DRPT Document The group considered the DRPT SMTP extension document. The first issue raised was an old one -- that of concern about the possible liability ramifications of delivery receipts. One possible approach is to use the ``relayed'' option in a receipt indicating that the message was successfully transferred but may or may not have undergone successful final delivery. It was proposed that the MTS type be carried in the same field as the address. There were no objections to this change. It was generally agreed that the delay notification mechanism needs some work. In particular, the times when such notices can or should be generated should be clarified. The idea of using this SMTP extension with other types of report requests was raised. It was generally agreed that other types of requests will require a separate and different extension. The meeting concluded with a long discussion of the quoting mechanism used in the SMTP extension parameters. The current draft calls for percent signs to be used, which given their use in addresses may be confusing. Various schemes were proposed and rejected. It was finally agreed that plus signs will be used as the quoting character.