CURRENT_MEETING_REPORT_ Reported by James Conklin/National Science Foundation Minutes of the Mail Extensions Working Group (MAILEXT) Working Group Charter John Klensin noted that the Applications Area Directorate's intent is to use this working group for review, not for writing, of standards---it will only deal with relatively complete proposals (not the generation of new proposals) to provide relatively fast review of those that are believed to be nearly done. Its responses to proposals should generally be to: o recommend for promotion to Draft Standard; o refer it to another (perhaps new) working group for action and/or development; o further refine and review it within the working group; or o recommend that it be discarded. Consideration of Proposals ``SMTP Service Extension for Command Pipelining'' Pathname: draft-ietf-smtpext-pipeline-02.txt Ned Freed Review: o Pipelining goal is increased efficiency by removing SMTP turnaround states where possible; design to reduce state transitions (reduction from 6 to 3 in practice) doubles throughput in Freed's experiments. o Issue: Why do you need to standardize this -- why cannot implementors ``just do it''? It is not prohibited by SMTP. Pragmatic considerations require documentation, standardization as an extension. o The document has been out for about a year (goes back about 2.5 years in discussions). Freed has had small-group interaction and feedback from about 20 people -- not new, Rose and Vaudreuil have written documents that predate. o Implementation is easy. Discussion: o What needs to be fixed? ``Just run more sendmail daemons. Equipment and bandwidth getting more and cheaper.'' Answer: Some people have limited resources. Case reported of 70% of sendmail time awaiting SMTP transactions, 30% actual processing. Several reported experiences backed up this issue and the need for improvement. Basically, is this the best way to improve performance? It helps people with limited bandwidth, with limited cpu cycles, people who must pay for packets. o How useful does it have to be to be necessary? Why not? It is between ``consenting pairs,'' does not hurt others. Or is it our business to determine if it is ``necessary,'' or to provide it to be used if desired, if it is basically useful and not harmful? o Implementations noted by participants: Freed, Vaudreuil, Houser (in MUMPS). o Sendmail problem -- forks between certain commands and uses STDIO, which causes data pipes to break. Requires modification to sendmail for proposal as stated. Or modification to proposal to cause it to work with sendmail. Better to modify sendmail if possible; talk with Eric Allman to explore this possibility before modifying the proposal. Other implementations also will not support the proposal (no details as to which and what changes might be needed). However, it is a 90% solution. Importance of keeping the specification in mind, not justifying deviations by implementations. Working Group Recommendation: o The working group recommends that the document be republished as a MAILEXT Working Group Internet-Draft. It will be submitted as a Proposed Standard, in approximately two weeks, once Ned Freed consults with Rob Ullmann and resolves the sendmail issue. ``MIME and File Transfer Body Parts'' Pathname: draft-freed-ftbp-00.txt Ned Freed Review: o The X.400 File Transfer (binary) body-part in the 1994 specification is sufficiently parallel to MIME to allow gatewaying because of separation between structure information and content-type OID. The EMA is actively profiling the file-transfer body part and defining object identifiers. Freed's proposal specifies an approach to gatewaying the file-transfer body-part between X.400 and MIME, and provides the necessary ASN.1 documentation for understanding relevant parts of the X.400 specification. The proposed Mapping takes Structure information and Content-Type OID, and maps them into specific MIME content-type headers. Optional EMA stuff is mapped into other ``content-'' headers or ignored. It may be possible to work with Microsoft and EMA in this effort. o Mapping from SMTP into X.400: No X.400 place exists for MIME body-part header info, except in the case of the file-transfer body part. Discussion: o May have defined too many headers for X.400 stuff of questionable value. Presence in the specification may lead people to believe that this ``stuff'' is important, whereas it is likely to be ignored on the X.400 side. Alternative might be to push it all into a single header into which all such stuff is pushed (hidden) through ASN.1. This may be significant philosophical issue. o Any approach should take into account the dynamic nature of the standards, rather than trying to be too specific to their present form. o Issue of other OSI standards with inconsistent definitions of objects leads to the desirability of labeling the OSI object being mapped into MIME (provide the source of the semantics being mapped), to provide flexibility and interpretability. o Needs case-by-case evaluation of the objects and what to do with each. Issue of mapping back as well as forward. Issue of whether this working group/IETF should delete info or take the stand that info generated by other standards is useless -- if not, how to map sensibly into Internet and MIME standards. What is useful enough to standardize on? o More work needed before the proposal moves forward? Where? -- on this working group list, based on show of those interested. Working Group Recommendation: o The working group recommends that the document be republished as a MAILEXT Working Group Internet-Draft. Ned will post it to the working group mailing list for further development. ``SMTP Service Extensions for Transmission of Large and Binary MIME Messages'' Pathname: draft-vaudreuil-smtp-binary-04.txt (Ed: The document pathname has since been changed to draft-ietf-mailext-smtp-binary.) Greg Vaudreuil Review: o Intent: to meet the needs of people who send around binary objects for which the base-64 encoding is too expensive o Requires new EHLO keywords: binary, chunking o Alternative to DATA command; chunking o Chunking -- BDAT command sends one variable-length block at a time. Works for 7-bit and for 8-bit text. End of data indicated by parameter ``last'' (BDAT 0 LAST). Works with streaming. o Content must be MIME with appropriate CTE; requires chunking extension. o History: dates back to early MIME work; current specification has been available for a couple of months and has gotten feedback Discussion: o Is not this a transport-level implementation of ftp? Allows posting without opening second channel, can be used across firewalls, ``is easier,'' chunking desirable anyway for mail, second-channel implementation for mail would, according to some, be handled differently than ftp anyway. o Why chunking? Allows implementation to canonicalize in memory in one pass -- very desirable for efficiency and if exact size not known. o What is happened to earlier proponents that this type of extension (mixing binary with MIME data) is dangerous to mail in general, ``evil'' in general? Proposal allows implementors who have this concern to not implement. o SMTP and MIME use of CRLFs in headers makes essential extreme care in both the specification and the implementation of any proposal to send binary data using SMTP. o Implementations that do not count accurately will have problems with this proposal. o Only 2 folks feel that they really understand the proposal well enough to make a recommendation. o More interoperability testing would be desirable, because this is a major extension that could cause problems, though it is very desirable. Working Group Recommendation: o The working group recommends that the document be republished as a MAILEXT Working Group Internet-Draft. A one-month working group review is expected to be followed by an IESG Last Call. If that is successful, then the document will be moved to Proposed Standard status prior to the next IETF. ``SMTP 521 reply code'' Pathname: draft-durand-smtp-521-reply-code-00.txt (Ed: The document pathname has since been changed to draft-ietf-mailext-smtp-521.) John Myers Review: o To add an SMTP 521 reply code that host never accepts SMTP mail. Allows sender to know that re-send should not be attempted. Allows immediate bounce, rather than delay that would be associated with no response from host. Also eliminates repeated retries to the host. o Is intent to use only for host that never intends to accept mail from ANY host, or whether it intends only to never accept mail from the PARTICULAR host sending the message? Should it be handled at the ICMP level? (The latter ties one to IP rather than just SMTP; also has implementation and practice difficulties raised in discussion.) o Should the sender remember that it received a 521 (and not even attempt to connect again)? Both caching and mailing-list issues are raised by the question of ``never'' versus ``some specified length of time.'' Working Group Recommendation: o The working group recommends that the document be posted to the working group mailing list for refinement and development. ``Language tags for MIME content portions'' Pathname: draft-alvestrand-language-tag-00.txt (Ed: The document pathname has since been changed to draft-ietf-mailext-lang-tag.) Harald Alvestrand Review: o To meet the need to specify the language used in a MIME message o Allows MUA to present to the user the language alternatives included in a message, for presentation. Also allows standardized labeling of languages. And for systems that convert text mail to voice. o Intentionally does not include the facility to handle embedded changes of language within the content of a message. Working Group Recommendation: o The working group recommends that the document be sent to the working group mailing list for review and to attempt to reach consensus for recommending the document for Proposed Standard status. Miscellaneous o A-bombs and c-bombs may be presented on the mailing list for discussion. o The MAILEXT Working Group charter needs to be updated based on this meeting. Allan Cargille will revise the document and post it to the list for approval. o Session participants (and others) must subscribe themselves in order to be on the mailing list, as they will NOT be automatically subscribed. There was a request that a mailext-request@cs.wisc.edu address be implemented for those who want special handling possibly not provided by the automated software. For the moment, such requests may be sent to the working group chair. Mailing list information from the working group charter is appended below. o Ed Levinson announced that work is going on concerning SGML and MIME-encapsulation of SGML. A BOF will be held at the next IETF. Mailing-list is mime-sgml@infoods.unu.edu, subscription requests should be sent to mime- sgml-request@infoods.unu.edu. o Einar Stefferud announced a proposal to set up ``simple core, with gateways at the extremities'' and encapsulation of messages for transport through the ``simple core'' using MIME for encapsulation. This will be discussed further on the mailing list.