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