home *** CD-ROM | disk | FTP | other *** search
-
- 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
-
-