home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / NOTARY / 94DEC.MIN next >
Encoding:
Text File  |  1995-06-26  |  7.1 KB  |  174 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Ned Freed/Innosoft International
  5.  
  6. Minutes of the Notifications and Acknowledgements Requirements
  7. Working Group (NOTARY)
  8.  
  9. The NOTARY Working Group met on 8 December at the 31st IETF.
  10.  
  11.  
  12. Agenda
  13.  
  14.    o Agenda approval
  15.  
  16.    o Document bashing, multipart/report document:  ``The
  17.      Multipart/Report Content Type for the Reporting of Mail System
  18.      Administrative Messages''
  19.  
  20.    o Document bashing, MIME-delivery document:  ``An Extensible Message
  21.      Format for Delivery Status Notifications''
  22.  
  23.    o Document bashing, SMTP-DRPT document:  ``SMTP Service Extension for
  24.      Delivery Status Notifications''
  25.  
  26.    o All other business
  27.  
  28.  
  29. In this case, document bashing means exactly what it sounds like:
  30.  
  31.  
  32.    o The group will go through the document page by page.
  33.  
  34.    o Comments on ambiguous language, unclear figures and spelling
  35.      misteaks are in order.
  36.  
  37.    o Suggestions for grand redesigns are out of order.
  38.  
  39.    o A copy will be marked up with what time each page should be started
  40.      in order to finish on time.
  41.  
  42.  
  43. If the document review is finished ahead of time, the group can discuss
  44. other fun things like receipt reports (no activity since last time),
  45. vacation notices (same comment) and so on.
  46.  
  47.  
  48. Multipart/Report Document
  49.  
  50. Greg Vaudreuil presented a brief description of the multipart/report
  51. format.  Harald Alvestrand pointed out that the third part of such
  52. objects, which is used for returned content, is not constrained in any
  53. way in terms of what it can be.  The group decided that this is
  54. appropriate in this specification, but that other specifications using
  55. this format should be able to restrict what is allowed in this part.
  56.  
  57. The group then agreed that this document should be submitted for
  58. consideration as a Proposed Standard by the IESG after this change is
  59. made.
  60.  
  61.  
  62.  
  63. MIME-Delivery Document
  64.  
  65. Discussion turned to the delivery report format specification.  Keith
  66. began the discussion by presenting some issues reported by Eric Allman
  67. that have turned up in the context of implementation of this format in
  68. sendmail.
  69.  
  70. The first issue was that of MTS type.  This concept has proved to be
  71. difficult to understand.  Keith proposed removing the concept of MTS
  72. type and replacing it with separate type indicators for the status code
  73. and address fields, and the working group concurred.
  74.  
  75. A suggestion was made to replace the use of the term ``final MTA'' with
  76. ``reporting MTA.'' The working group agreed that this change is a good
  77. idea.
  78.  
  79. Jim Conklin noted that various terms defined in RFC 822 were used
  80. without referring to their definition in RFC 822.  Keith agreed to add
  81. the proper references to RFC 822 to the specification.
  82.  
  83. The definition and use of xtext was then discussed.  It was pointed out
  84. that the sharp sign used as a quoting character is a national variant
  85. character, which could be problematic in some environments.  A prolonged
  86. discussion ensued, where various alternatives, e.g., use of
  87. quoted-printable across the entire notification body, use of
  88. quoted-printable on a per-field basis, and so on.  Various problems were
  89. found with the alternatives, e.g., that the cross-body encoding does not
  90. allow for pure binary material, use of local quoted-printable breaks the
  91. comment usage now specified in the draft, and so on.  The issue was
  92. eventually tabled for later discussion as time permits.
  93.  
  94. The ``received-from'' field name will be changed to
  95. ``received-from-MTA.'' A suggestion was made to change the name to
  96. ``previous-MTA,'' but this was seen as actually being less clear.
  97.  
  98. Discussion then turned to the issue of final versus remote fields.  It
  99. was generally agreed that the two sets of fields are useful for both
  100. MTAs and status codes.  The distinction between a final recipient and a
  101. remote recipient, however, seems less clear.
  102.  
  103. A complex debate then ensued, where all of the various recipient fields
  104. (original, RFC 822 format, final, remote) were bandied about.  The
  105. conclusion was to specify a typed earliest recipient field as the basic
  106. field that is returned, with Greg raising an objection that the field
  107. should be required to be in RFC 822 format.
  108.  
  109. The action field was then discussed.  There was some sentiment that the
  110. set of values should be extensible, but no decision was made to make
  111. them extensible.
  112.  
  113. Keith then presented the latest status code proposal.  In brief, the
  114. idea is to currently define a single digit status code based on the
  115. first digit of SMTP codes (2, 4, or 5), and subsequently to develop a
  116. standards track specification that provides more detailed status codes.
  117. This proposal was approved by the working group.
  118.  
  119. The name of the ``date'' field was changed to ``last-attempt-date.''
  120.  
  121. It was observed that with the ``final-log-id'' field, implementations
  122. use all sorts of identifiers and that there is no single clear
  123. identifier to put here.  The working group decided to remove this field
  124. in favor of implementations using whatever ``X-'' fields they find
  125. appropriate.
  126.  
  127. The group then moved on to consider remote status codes.  Various people
  128. argued against these codes.  Ned Freed pointed out that such codes give
  129. the appearance of precision when in fact they may not be.  John Myers
  130. countered by pointing out that such information is very useful for
  131. trouble ticket applications, and proposed modifying this field to make
  132. it ``write only'' remote-MTA-specific information.  Harald Alvestrand
  133. then pointed out that this proposal will be much easier to accept if
  134. SMTP codes that people already understand could be included.
  135.  
  136. After prolonged discussion, Harald recommended tabling this issue and
  137. discussing it further on the list.  Keith Moore will take the discussion
  138. as input and try to clarify the text, which will then be discussed on
  139. the mailing list.
  140.  
  141. Harald Alvestrand pointed out that the security section needs to be
  142. enhanced to point out that various fields may be dropped due to security
  143. concerns.  Certain fields need to be required, e.g., action and status,
  144. but practically everything else may be a candidate for removal by
  145. security firewalls.
  146.  
  147.  
  148. SMTP-DRPT Document
  149.  
  150. The group considered the DRPT SMTP extension document.  The first issue
  151. raised was an old one -- that of concern about the possible liability
  152. ramifications of delivery receipts.  One possible approach is to use the
  153. ``relayed'' option in a receipt indicating that the message was
  154. successfully transferred but may or may not have undergone successful
  155. final delivery.
  156.  
  157. It was proposed that the MTS type be carried in the same field as the
  158. address.  There were no objections to this change.
  159.  
  160. It was generally agreed that the delay notification mechanism needs some
  161. work.  In particular, the times when such notices can or should be
  162. generated should be clarified.
  163.  
  164. The idea of using this SMTP extension with other types of report
  165. requests was raised.  It was generally agreed that other types of
  166. requests will require a separate and different extension.
  167.  
  168. The meeting concluded with a long discussion of the quoting mechanism
  169. used in the SMTP extension parameters.  The current draft calls for
  170. percent signs to be used, which given their use in addresses may be
  171. confusing.  Various schemes were proposed and rejected.  It was finally
  172. agreed that plus signs will be used as the quoting character.
  173.  
  174.