home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / NOTARY / 94MAR.MIN < prev    next >
Encoding:
Text File  |  1994-06-06  |  5.8 KB  |  132 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Harald Alvestrand/UNINETT
  5.  
  6. Minutes of the Notifications and Acknowledgements Requirements Working
  7. Group (NOTARY)
  8.  
  9. Keith Moore began the meeting by presenting an overview of his draft
  10. document defining a Delivery Status Report SMTP extension.  The draft
  11. was then reviewed and the following points were discussed:
  12.  
  13.  
  14.    o RFC 1425 defines an esmtp-value as a sequence of ASCII characters
  15.      excluding CTLs, spaces, and equal signs.  Since addresses often
  16.      contain spaces and equal signs, quoting is needed to pass address
  17.      information in these values.  The current quoting scheme was found
  18.      to be acceptable.
  19.  
  20.    o The ORCPT parameter is used to carry original address information.
  21.      The idea of allowing the addition of this information by
  22.      intermediate SMTP hosts was discussed and rejected.
  23.  
  24.    o The RET parameter is used to request return of message content in
  25.      Delivery Status Reports.  This parameter is currently advisory
  26.      rather than mandatory, and this approach was found to be
  27.      acceptable.
  28.  
  29.    o A proposal was submitted to the mailing list to add an SMTP MAIL
  30.      FROM parameter to indicate when a Delivery Status Report is being
  31.      transferred.  The group saw no reason to have such an SMTP
  32.      parameter.
  33.  
  34.    o The handling of ``message delayed in transit'' Delivery Status
  35.      Reports was discussed at some length.  Various approaches were
  36.      considered, including:
  37.  
  38.      (a) Treat delay reports as just another form of negative Delivery
  39.          Status report and bind their behavior to the current NOTIFY
  40.          parameter.
  41.  
  42.      (b) Bind the handling of delay reports to some more complex
  43.          combination of existing parameter values.
  44.  
  45.      (c) Add an additional parameter to control delay reports
  46.          specifically.
  47.  
  48.      (d) Ignore delay reports as an issue.
  49.  
  50.      After discussion the group was obviously overwhemingly in favor of
  51.      (c).
  52.  
  53.    o John Myers raised an objection to the current draft's requirement
  54.      that any SMTP server providing this extension must provide support
  55.      for positive acknowledgments.  The specific issue is a legal one,
  56.      in that some agencies do not wish to be obligated to provide any
  57.      guarantee that a message has in fact been delivered to a given
  58.      recipient.  It was pointed out that RFC 821 states that any agent
  59.      that accepts a message in turn accepts responsibility for that
  60.      message, and given that the current draft document permits a
  61.      response of ``message relayed; expect no additional
  62.      notifications,'' this proposal does not add anything that SMTP does
  63.      not require already.  Keith and John agreed to work on wording to
  64.      clarify this matter.
  65.  
  66.  
  67. Greg Vaudreuil then presented a comparison of his draft and Keith
  68. Moore's draft describing their respective approaches to Status Report
  69. formats.  The group initially discussed the scope of such formats and
  70. came to the conclusion that any format of this type should be general
  71. and extensible and that the initial document should define both the
  72. basic format and how it should be used for positive and negative
  73. Delivery Status Reports.  Message Transfer Agents will be primarily
  74. responsible for the generation of such reports, although other agents
  75. like gateways may generate such reports as well.  Use of the format for
  76. other purposes (e.g.  by user agents for Read Receipts) will be deferred
  77. to future documents that may or may not be within the scope of this
  78. group.
  79.  
  80. The discussion then turned to the differences in how the two documents
  81. handle error codes.  The group decided that a set of error codes based
  82. on SMTP codes was appropriate, and that error codes from other
  83. environments needed to ``tunneled'' through rather than being coerced
  84. exclusively into SMTP errors, even with finer granularity than SMTP
  85. presently provides.
  86.  
  87. The last issue concerned return of message content.  Keith's draft
  88. defines a message/sample type that is used to return possibly incomplete
  89. message content.  The group found this approach to be too restrictive
  90. and decided that the choice of an appropriate format for return of
  91. content should be left to the agent generating the Status Report.  In
  92. particular, a choice of message/rfc822 might be appropriate for
  93. returning RFC 822 messages, text/plain for returning message headers,
  94. and application/octet-stream for return binary message objects.
  95.  
  96.  
  97. Attendees
  98.  
  99. Nashwa Abdel-Baki        nashwa@frcu.eun.eg
  100. Claudio Allocchio        Claudio.Allocchio@elettra.trieste.it
  101. John Beck                jbeck@cup.hp.com
  102. Dick Brooks              d.brooks@ieee.org
  103. Rong Chang               rong@watson.ibm.com
  104. Charles Combs            0003647213@mcimail.com
  105. Jim Conklin              jbc@bitnic.educom.edu
  106. Shane Davis              shane@delphi.com
  107. Peter DiCamillo          Peter_DiCamillo@brown.edu
  108. Cheri Dowell             cdowell@atlas.arc.nasa.gov
  109. Urs Eppenberger          eppenberger@switch.ch
  110. Roger Fajman             raf@cu.nih.gov
  111. Ned Freed                ned@innosoft.com
  112. Terry Gray               gray@cac.washington.edu
  113. Alex Hopmann             alex.hopmann@resnova.com
  114. Steven Hubert            hubert@cac.washington.edu
  115. Ryu Inada                ryu@fujixerox.co.jp
  116. Marko Kaittola           Marko.Kaittola@dante.org.uk
  117. Neil Katin               katin@eng.sun.com
  118. John Klensin             Klensin@infoods.unu.edu
  119. Michael Knezevich        knezevich@pmel.noaa.gov
  120. Jim Knowles              jknowles@binky.arc.nasa.gov
  121. Sylvain Langlois         Sylvain.Langlois@der.edf.fr
  122. Edward Levinson          levinson@pica.army.mil
  123. Keith Moore              moore@cs.utk.edu
  124. John Myers               jgm+@cmu.edu
  125. Paul-Andre Pays          pays@faugeres.inria.fr
  126. Karen Petraska-Veum      karen.veum@gsfc.nasa.gov
  127. Tim Seaver               tas@concert.net
  128. Michael Seibel           mikes@cac.washington.edu
  129. Einar Stefferud          stef@nma.com
  130. Peter Sylvester          peter.sylvester@inria.fr
  131.  
  132.