CURRENT_MEETING_REPORT_ Reported by Harald Alvestrand/UNINETT Minutes of the Notifications and Acknowledgements Requirements Working Group (NOTARY) Keith Moore began the meeting by presenting an overview of his draft document defining a Delivery Status Report SMTP extension. The draft was then reviewed and the following points were discussed: o RFC 1425 defines an esmtp-value as a sequence of ASCII characters excluding CTLs, spaces, and equal signs. Since addresses often contain spaces and equal signs, quoting is needed to pass address information in these values. The current quoting scheme was found to be acceptable. o The ORCPT parameter is used to carry original address information. The idea of allowing the addition of this information by intermediate SMTP hosts was discussed and rejected. o The RET parameter is used to request return of message content in Delivery Status Reports. This parameter is currently advisory rather than mandatory, and this approach was found to be acceptable. o A proposal was submitted to the mailing list to add an SMTP MAIL FROM parameter to indicate when a Delivery Status Report is being transferred. The group saw no reason to have such an SMTP parameter. o The handling of ``message delayed in transit'' Delivery Status Reports was discussed at some length. Various approaches were considered, including: (a) Treat delay reports as just another form of negative Delivery Status report and bind their behavior to the current NOTIFY parameter. (b) Bind the handling of delay reports to some more complex combination of existing parameter values. (c) Add an additional parameter to control delay reports specifically. (d) Ignore delay reports as an issue. After discussion the group was obviously overwhemingly in favor of (c). o John Myers raised an objection to the current draft's requirement that any SMTP server providing this extension must provide support for positive acknowledgments. The specific issue is a legal one, in that some agencies do not wish to be obligated to provide any guarantee that a message has in fact been delivered to a given recipient. It was pointed out that RFC 821 states that any agent that accepts a message in turn accepts responsibility for that message, and given that the current draft document permits a response of ``message relayed; expect no additional notifications,'' this proposal does not add anything that SMTP does not require already. Keith and John agreed to work on wording to clarify this matter. Greg Vaudreuil then presented a comparison of his draft and Keith Moore's draft describing their respective approaches to Status Report formats. The group initially discussed the scope of such formats and came to the conclusion that any format of this type should be general and extensible and that the initial document should define both the basic format and how it should be used for positive and negative Delivery Status Reports. Message Transfer Agents will be primarily responsible for the generation of such reports, although other agents like gateways may generate such reports as well. Use of the format for other purposes (e.g. by user agents for Read Receipts) will be deferred to future documents that may or may not be within the scope of this group. The discussion then turned to the differences in how the two documents handle error codes. The group decided that a set of error codes based on SMTP codes was appropriate, and that error codes from other environments needed to ``tunneled'' through rather than being coerced exclusively into SMTP errors, even with finer granularity than SMTP presently provides. The last issue concerned return of message content. Keith's draft defines a message/sample type that is used to return possibly incomplete message content. The group found this approach to be too restrictive and decided that the choice of an appropriate format for return of content should be left to the agent generating the Status Report. In particular, a choice of message/rfc822 might be appropriate for returning RFC 822 messages, text/plain for returning message headers, and application/octet-stream for return binary message objects. Attendees Nashwa Abdel-Baki nashwa@frcu.eun.eg Claudio Allocchio Claudio.Allocchio@elettra.trieste.it John Beck jbeck@cup.hp.com Dick Brooks d.brooks@ieee.org Rong Chang rong@watson.ibm.com Charles Combs 0003647213@mcimail.com Jim Conklin jbc@bitnic.educom.edu Shane Davis shane@delphi.com Peter DiCamillo Peter_DiCamillo@brown.edu Cheri Dowell cdowell@atlas.arc.nasa.gov Urs Eppenberger eppenberger@switch.ch Roger Fajman raf@cu.nih.gov Ned Freed ned@innosoft.com Terry Gray gray@cac.washington.edu Alex Hopmann alex.hopmann@resnova.com Steven Hubert hubert@cac.washington.edu Ryu Inada ryu@fujixerox.co.jp Marko Kaittola Marko.Kaittola@dante.org.uk Neil Katin katin@eng.sun.com John Klensin Klensin@infoods.unu.edu Michael Knezevich knezevich@pmel.noaa.gov Jim Knowles jknowles@binky.arc.nasa.gov Sylvain Langlois Sylvain.Langlois@der.edf.fr Edward Levinson levinson@pica.army.mil Keith Moore moore@cs.utk.edu John Myers jgm+@cmu.edu Paul-Andre Pays pays@faugeres.inria.fr Karen Petraska-Veum karen.veum@gsfc.nasa.gov Tim Seaver tas@concert.net Michael Seibel mikes@cac.washington.edu Einar Stefferud stef@nma.com Peter Sylvester peter.sylvester@inria.fr