home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mailext / mailext-minutes-94jul.txt < prev    next >
Text File  |  1994-11-01  |  12KB  |  325 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by James Conklin/National Science Foundation
  5.  
  6. Minutes of the Mail Extensions Working Group (MAILEXT)
  7.  
  8.  
  9. Working Group Charter
  10.  
  11. John Klensin noted that the Applications Area Directorate's intent is to
  12. use this working group for review, not for writing, of standards---it
  13. will only deal with relatively complete proposals (not the generation of
  14. new proposals) to provide relatively fast review of those that are
  15. believed to be nearly done.  Its responses to proposals should generally
  16. be to:
  17.  
  18.  
  19.    o recommend for promotion to Draft Standard;
  20.  
  21.    o refer it to another (perhaps new) working group for action and/or
  22.      development;
  23.  
  24.    o further refine and review it within the working group; or
  25.  
  26.    o recommend that it be discarded.
  27.  
  28.  
  29. Consideration of Proposals
  30.  
  31. ``SMTP Service Extension for Command Pipelining''
  32.  
  33. Pathname:  draft-ietf-smtpext-pipeline-02.txt
  34.  
  35. Ned Freed Review:
  36.  
  37.  
  38.    o Pipelining goal is increased efficiency by removing SMTP turnaround
  39.      states where possible; design to reduce state transitions
  40.      (reduction from 6 to 3 in practice) doubles throughput in Freed's
  41.      experiments.
  42.  
  43.    o Issue:  Why do you need to standardize this -- why cannot
  44.      implementors ``just do it''?  It is not prohibited by SMTP.
  45.      Pragmatic considerations require documentation, standardization as
  46.      an extension.
  47.  
  48.    o The document has been out for about a year (goes back about 2.5
  49.      years in discussions).  Freed has had small-group interaction and
  50.      feedback from about 20 people -- not new, Rose and Vaudreuil have
  51.      written documents that predate.
  52.  
  53.    o Implementation is easy.
  54.  
  55.  
  56. Discussion:
  57.  
  58.  
  59.    o What needs to be fixed?  ``Just run more sendmail daemons.
  60.      Equipment and bandwidth getting more and cheaper.''  Answer:  Some
  61.      people have limited resources.  Case reported of 70% of sendmail
  62.      time awaiting SMTP transactions, 30% actual processing.  Several
  63.      reported experiences backed up this issue and the need for
  64.      improvement.  Basically, is this the best way to improve
  65.      performance?  It helps people with limited bandwidth, with limited
  66.      cpu cycles, people who must pay for packets.
  67.  
  68.    o How useful does it have to be to be necessary?  Why not?  It is
  69.      between ``consenting pairs,'' does not hurt others.  Or is it our
  70.      business to determine if it is ``necessary,'' or to provide it to
  71.      be used if desired, if it is basically useful and not harmful?
  72.  
  73.    o Implementations noted by participants:  Freed, Vaudreuil, Houser
  74.      (in MUMPS).
  75.  
  76.    o Sendmail problem -- forks between certain commands and uses STDIO,
  77.      which causes data pipes to break.  Requires modification to
  78.      sendmail for proposal as stated.  Or modification to proposal to
  79.      cause it to work with sendmail.  Better to modify sendmail if
  80.      possible; talk with Eric Allman to explore this possibility before
  81.      modifying the proposal.  Other implementations also will not
  82.      support the proposal (no details as to which and what changes might
  83.      be needed).  However, it is a 90% solution.  Importance of keeping
  84.      the specification in mind, not justifying deviations by
  85.      implementations.
  86.  
  87.  
  88. Working Group Recommendation:
  89.  
  90.  
  91.    o The working group recommends that the document be republished as a
  92.      MAILEXT Working Group Internet-Draft.  It will be submitted as a
  93.      Proposed Standard, in approximately two weeks, once Ned Freed
  94.      consults with Rob Ullmann and resolves the sendmail issue.
  95.  
  96.  
  97. ``MIME and File Transfer Body Parts''
  98.  
  99. Pathname:  draft-freed-ftbp-00.txt
  100.  
  101. Ned Freed Review:
  102.  
  103.  
  104.    o The X.400 File Transfer (binary) body-part in the 1994
  105.      specification is sufficiently parallel to MIME to allow gatewaying
  106.      because of separation between structure information and
  107.      content-type OID. The EMA is actively profiling the file-transfer
  108.      body part and defining object identifiers.  Freed's proposal
  109.      specifies an approach to gatewaying the file-transfer body-part
  110.      between X.400 and MIME, and provides the necessary ASN.1
  111.      documentation for understanding relevant parts of the X.400
  112.      specification.  The proposed Mapping takes Structure information
  113.      and Content-Type OID, and maps them into specific MIME content-type
  114.      headers.  Optional EMA stuff is mapped into other ``content-''
  115.      headers or ignored.  It may be possible to work with Microsoft and
  116.      EMA in this effort.
  117.  
  118.    o Mapping from SMTP into X.400:  No X.400 place exists for MIME
  119.      body-part header info, except in the case of the file-transfer body
  120.      part.
  121.  
  122.  
  123. Discussion:
  124.  
  125.  
  126.    o May have defined too many headers for X.400 stuff of questionable
  127.      value.  Presence in the specification may lead people to believe
  128.      that this ``stuff'' is important, whereas it is likely to be
  129.      ignored on the X.400 side.  Alternative might be to push it all
  130.      into a single header into which all such stuff is pushed (hidden)
  131.      through ASN.1.  This may be significant philosophical issue.
  132.  
  133.    o Any approach should take into account the dynamic nature of the
  134.      standards, rather than trying to be too specific to their present
  135.      form.
  136.  
  137.    o Issue of other OSI standards with inconsistent definitions of
  138.      objects leads to the desirability of labeling the OSI object being
  139.      mapped into MIME (provide the source of the semantics being
  140.      mapped), to provide flexibility and interpretability.
  141.  
  142.    o Needs case-by-case evaluation of the objects and what to do with
  143.      each.  Issue of mapping back as well as forward.  Issue of whether
  144.      this working group/IETF should delete info or take the stand that
  145.      info generated by other standards is useless -- if not, how to map
  146.      sensibly into Internet and MIME standards.  What is useful enough
  147.      to standardize on?
  148.  
  149.    o More work needed before the proposal moves forward?  Where?  -- on
  150.      this working group list, based on show of those interested.
  151.  
  152.  
  153. Working Group Recommendation:
  154.  
  155.  
  156.    o The working group recommends that the document be republished as a
  157.      MAILEXT Working Group Internet-Draft.  Ned will post it to the
  158.      working group mailing list for further development.
  159.  
  160.  
  161.  
  162. ``SMTP Service Extensions for Transmission of Large and Binary MIME
  163. Messages''
  164.  
  165. Pathname:  draft-vaudreuil-smtp-binary-04.txt (Ed: The document pathname has
  166. since been changed to draft-ietf-mailext-smtp-binary.)
  167.  
  168. Greg Vaudreuil Review:
  169.  
  170.  
  171.    o Intent:  to meet the needs of people who send around binary objects
  172.      for which the base-64 encoding is too expensive
  173.  
  174.    o Requires new EHLO keywords:  binary, chunking
  175.  
  176.    o Alternative to DATA command; chunking
  177.  
  178.    o Chunking -- BDAT command sends one variable-length block at a time.
  179.      Works for 7-bit and for 8-bit text.  End of data indicated by
  180.      parameter ``last'' (BDAT 0 LAST). Works with streaming.
  181.  
  182.    o Content must be MIME with appropriate CTE; requires chunking
  183.      extension.
  184.  
  185.    o History:  dates back to early MIME work; current specification has
  186.      been available for a couple of months and has gotten feedback
  187.  
  188.  
  189. Discussion:
  190.  
  191.  
  192.    o Is not this a transport-level implementation of ftp?  Allows
  193.      posting without opening second channel, can be used across
  194.      firewalls, ``is easier,'' chunking desirable anyway for mail,
  195.      second-channel implementation for mail would, according to some, be
  196.      handled differently than ftp anyway.
  197.  
  198.    o Why chunking?  Allows implementation to canonicalize in memory in
  199.      one pass -- very desirable for efficiency and if exact size not
  200.      known.
  201.  
  202.    o What is happened to earlier proponents that this type of extension
  203.      (mixing binary with MIME data) is dangerous to mail in general,
  204.      ``evil'' in general?  Proposal allows implementors who have this
  205.      concern to not implement.
  206.  
  207.    o SMTP and MIME use of CRLFs in headers makes essential extreme care
  208.      in both the specification and the implementation of any proposal to
  209.      send binary data using SMTP.
  210.  
  211.    o Implementations that do not count accurately will have problems
  212.      with this proposal.
  213.  
  214.    o Only 2 folks feel that they really understand the proposal well
  215.      enough to make a recommendation.
  216.  
  217.    o More interoperability testing would be desirable, because this is a
  218.      major extension that could cause problems, though it is very
  219.      desirable.
  220.  
  221.  
  222. Working Group Recommendation:
  223.  
  224.  
  225.    o The working group recommends that the document be republished as a
  226.      MAILEXT Working Group Internet-Draft.  A one-month working group
  227.      review is expected to be followed by an IESG Last Call.  If that is
  228.      successful, then the document will be moved to Proposed Standard
  229.      status prior to the next IETF.
  230.  
  231.  
  232.  
  233. ``SMTP 521 reply code''
  234.  
  235. Pathname:  draft-durand-smtp-521-reply-code-00.txt (Ed: The document
  236. pathname has since been changed to draft-ietf-mailext-smtp-521.)
  237.  
  238. John Myers Review:
  239.  
  240.  
  241.    o To add an SMTP 521 reply code that host never accepts SMTP mail.
  242.      Allows sender to know that re-send should not be attempted.  Allows
  243.      immediate bounce, rather than delay that would be associated with
  244.      no response from host.  Also eliminates repeated retries to the
  245.      host.
  246.  
  247.    o Is intent to use only for host that never intends to accept mail
  248.      from ANY host, or whether it intends only to never accept mail from
  249.      the PARTICULAR host sending the message?  Should it be handled at
  250.      the ICMP level?  (The latter ties one to IP rather than just SMTP;
  251.      also has implementation and practice difficulties raised in
  252.      discussion.)
  253.  
  254.    o Should the sender remember that it received a 521 (and not even
  255.      attempt to connect again)?  Both caching and mailing-list issues
  256.      are raised by the question of ``never'' versus ``some specified
  257.      length of time.''
  258.  
  259.  
  260. Working Group Recommendation:
  261.  
  262.  
  263.    o The working group recommends that the document be posted to the
  264.      working group mailing list for refinement and development.
  265.  
  266.  
  267.  
  268. ``Language tags for MIME content portions''
  269.  
  270. Pathname:  draft-alvestrand-language-tag-00.txt (Ed: The document pathname
  271. has since been changed to draft-ietf-mailext-lang-tag.)
  272.  
  273. Harald Alvestrand Review:
  274.  
  275.  
  276.    o To meet the need to specify the language used in a MIME message
  277.  
  278.    o Allows MUA to present to the user the language alternatives
  279.      included in a message, for presentation.  Also allows standardized
  280.      labeling of languages.  And for systems that convert text mail to
  281.      voice.
  282.  
  283.    o Intentionally does not include the facility to handle embedded
  284.      changes of language within the content of a message.
  285.  
  286.  
  287. Working Group Recommendation:
  288.  
  289.  
  290.    o The working group recommends that the document be sent to the
  291.      working group mailing list for review and to attempt to reach
  292.      consensus for recommending the document for Proposed Standard
  293.      status.
  294.  
  295.  
  296. Miscellaneous
  297.  
  298.    o A-bombs and c-bombs may be presented on the mailing list for
  299.      discussion.
  300.  
  301.    o The MAILEXT Working Group charter needs to be updated based on this
  302.      meeting.  Allan Cargille will revise the document and post it to
  303.      the list for approval.
  304.  
  305.    o Session participants (and others) must subscribe themselves in
  306.      order to be on the mailing list, as they will NOT be automatically
  307.      subscribed.  There was a request that a mailext-request@cs.wisc.edu
  308.      address be implemented for those who want special handling possibly
  309.      not provided by the automated software.  For the moment, such
  310.      requests may be sent to the working group chair.  Mailing list
  311.      information from the working group charter is appended below.
  312.  
  313.    o Ed Levinson announced that work is going on concerning SGML and
  314.      MIME-encapsulation of SGML. A BOF will be held at the next IETF.
  315.      Mailing-list is mime-sgml@infoods.unu.edu, subscription requests
  316.      should be sent to mime-
  317.      sgml-request@infoods.unu.edu.
  318.  
  319.    o Einar Stefferud announced a proposal to set up ``simple core, with
  320.  
  321. gateways at the extremities'' and encapsulation of messages for
  322. transport through the ``simple core'' using MIME for encapsulation.
  323. This will be discussed further on the mailing list.
  324.  
  325.