home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mailext / mailext-minutes-94dec.txt < prev    next >
Encoding:
Text File  |  1995-02-28  |  7.9 KB  |  190 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by C. Allan Cargille/MCI
  5.  
  6. Minutes of the Mail Extensions Working Group (MAILEXT)
  7.  
  8.  
  9. Agenda
  10.  
  11.    o Introduction, participants, approval of minutes, revise charter,
  12.      revise agenda.
  13.  
  14.    o Individual work items:
  15.       -  521 status codes proposal (John Myers).
  16.       -  Language tag proposal (Harald Alvestrand).
  17.       -  File transfer body part MIME mapping (Ned Freed).
  18.       -  Pipelining SMTP extension (Ned Freed).
  19.       -  Checkpointing SMTP extension (Dave Crocker and Ned Freed).
  20.       -  Binary and chunking SMTP extensions (Greg Vaudreuil).
  21.       -  A-BoMBS and C-BoMBS (Jerome Houttein).
  22.       -  Text/html proposal from the HTML working group (Eric Huizer
  23.          presenting).
  24.  
  25.  
  26. Jacob Palme asked if this group is an appropriate forum for discussion
  27. of work being done in the X.400/OSI community on incorporation of
  28. Internet addressing.  John Klensin responded that this is not an
  29. appropriate forum for such discussion, but that it can be discussed if
  30. time permits.
  31.  
  32.  
  33. 521 Status Codes Proposal
  34.  
  35. John Myers presented an overview of the 521 status code proposal.  In
  36. brief, this proposal is something that network entities that do not
  37. support e-mail would support.  It causes mail to immediately bounce when
  38. an attempt is made to send it to such an entity.  Currently such mail
  39. tends to sit in some queue somewhere until it times out and is returned.
  40.  
  41. Keith Moore raised the issue of how MX records pointing at such entities
  42. should work.  The current specification says that the message should
  43. bounce.  Keith argued that it would be preferable to try other MX
  44. records instead.
  45.  
  46. John Myers then pointed out that he had recently realized that this
  47. proposal is not necessary.  It is almost as easy to implement a simple
  48. SMTP parser that returns a 5xx code to any RCPT TO command.  This
  49. approach has the advantage it works with existing broken implementations
  50. that effectively ignore the initial banner status.
  51.  
  52. Harald Alvestrand and others countered by saying that standarding the
  53. meaning of 521 in this context is useful in its own right.  In addition,
  54. John's proposal is problematic in that it could be construed that the
  55. postmaster address should always work.
  56.  
  57. Harald also suggested that this proposal needs to be tried to be
  58. assessed.  If it is deployed and is useful it could be moved to
  59. standards track.  If not, it should be dropped.  This in turn argues
  60. that the document should be issued as Experimental.  Allan concluded by
  61. suggesting that the document authors should attempt to reach consensus
  62. on the list for the documents moving forward as Experimental.
  63.  
  64.  
  65. Language Tag Proposal
  66.  
  67. The group considered the language header proposal.  Harald summarized
  68. this proposal as one that allows labelling the content of a message or
  69. part of a message as being in a particular language.
  70.  
  71. Jacob asked if the language concept extends to computer languages.
  72. Harald said it does not, but it could be extended to cover this.
  73. Nathaniel Borenstein asked about how multi-lingual text is handled -- it
  74. is done by specifying multiple language values.
  75.  
  76. Ned Freed noted that this work may be part of future efforts in
  77. extending MIME to uses in non-messaging environments.  This should not
  78. preclude moving the document along the standards track now, however.
  79.  
  80. John Klensin pointed out that the syntactic use of dash differs from
  81. previous usage in RFC 822.  Harald responded that this is by design, in
  82. that while the dash is a syntactic element he wants to capitalize on the
  83. effect it has of making it look like a single token.  Dave Crocker added
  84. that this needed to be made explicit in the text.
  85.  
  86. Dave Crocker also raised the issue of why this does not make sense as a
  87. content-type parameter.  Ned countered by pointing out that global
  88. content type parameters are not allowed in MIME, and that this
  89. information spans multiple content types.
  90.  
  91. The group concluded that this document should be submitted for
  92. consideration by the IESG as a Proposed Standard.
  93.  
  94.  
  95. File Transfer Body Part MIME Mapping
  96.  
  97. Ned presented his file transfer body part, SMTP pipelining, and SMTP
  98. checkpointing extension.  Ned prefaced his remarks by stating that only
  99. the pipelining extension is a candidate for advancement at this time.
  100.  
  101. The file transfer body part work is a result of work undertaken by the
  102. EMA Message Attachment Working Group (MAWG). The specification seeks to
  103. map X.400 file transfer body parts into appropriate MIME objects and
  104. vice versa.
  105.  
  106. Discussion focused on the need for a general file transfer mechanism in
  107. MIME and whether or not this mechanism should be extended to provide
  108. this facility.  Ned pointed out that since the EMA's use of file
  109. transfer body part is to provide a MIME-like mechanism for object
  110. encapsulation, not to use the mechanism for the (obvious) purpose to
  111. transfer files per se, and as such the mapping specification seeks to
  112. provide an object mapping rather than a file transfer mechanism.
  113.  
  114. Eric Fair noted that in the best of all worlds it would be possible to
  115. specify generic formats for generic object types.  Dave Crocker and
  116. others noted that while this would be desirable it is not present-day
  117. reality, and is not likely to become reality in the foreseeable future.
  118.  
  119. The discussion concluded with Ned stating that he wants to consider the
  120. various issues brought up by the group and see how the document needs to
  121. be changed (or not changed) to accommodate them.
  122.  
  123.  
  124.  
  125. Pipelining SMTP Extension
  126.  
  127. Ned reported that, as tasked by the working group, he had communicated
  128. with Eric Allman about the issues of implementing the pipelining
  129. extension in sendmail.  Eric had responded that the problems with
  130. implementing pipelining in sendmail (e.g., the use of a fork system
  131. calls in the middle of the SMTP dialogue) would probably be addressed in
  132. the long term by other planned modifications.  As such, Ned recommended
  133. moving the document forward for consideration as a Proposed Standard
  134. without any sendmail-specific changes, and the working group agreed.
  135.  
  136.  
  137.  
  138. Checkpointing SMTP Extension
  139.  
  140. The checkpointing proposal was discussed.  One of the coauthors (Ned)
  141. had thought of this proposal as something of an academic exercise.
  142. However, the other author (Dave Crocker) disagreed and so did a
  143. considerable fraction of the group.  It was accordingly decided that
  144. implementation of this proposal is needed, and if it proves to be useful
  145. the working group should consider moving this work forward on a
  146. standards track.
  147.  
  148.  
  149.  
  150. Binary and Chunking SMTP Extensions
  151.  
  152. Greg Vaudreuil presented his chunking and binary SMTP extension
  153. specification.  Discussion centered on interoperability testing and
  154. issues surrounding binary MIME. The latter were ruled out of scope for
  155. the present discussion, but the former are of such concern that the
  156. working group decided to ask for some indication of interoperability
  157. before advancing the document to Proposed Standard.
  158.  
  159.  
  160. A-BoMBS and C-BoMBS
  161.  
  162. The BoMBS documents were reviewed.  A large number of substantive
  163. comments were made about both documents.  Dave Crocker stated that this
  164. work is extremely important and long overdue, and that the best approach
  165. would be to charter a separate working group to deal with these
  166. documents in detail.  This suggestion was favorably received by the
  167. working group.
  168.  
  169.  
  170. Text/html Proposal from the HTML Working Group
  171.  
  172. Eric Huizer presented a proposal for the handling of text/html, which
  173. was worked out by the HTML Working Group (which met in parallel with
  174. Mail Extensions Working Group).  In brief, the HTML group has decided on
  175. a canonical form that agrees with MIME text/plain (i.e CRLF line
  176. terminator sequence).  Clients are supposed to support a wider variety
  177. of terminators, but text/html is supposed to be in this form.  This
  178. proposal was very favorably received by the Mail Extensions Working
  179. Group.
  180.  
  181. Eric Huizer also presented a proposal for a MIME testing service.  A
  182. document will be posted to the list describing this service.
  183.  
  184.  
  185. Conclusion
  186.  
  187. Allan Cargille concluded the meeting by thanking the various document
  188. authors for the work they have done on these proposals.
  189.  
  190.