Editor's Note: Minutes received 12/7/92 CURRENT_MEETING_REPORT_ Reported by John Klensin/MIT Minutes of the SMTP Extensions Working Group (SMTPEXT) Summary The Working Group has once again finished its work and is ready to submit rewritten documents to IESG for Proposed Standard status. Documents reviewed and completed this week include revised versions of: o ``SMTP Service Extensions'' model o ``SMTP Service Extension for Message Size Declaration'' and o ``SMTP Service Extension for 8bit-MIMEtransport''. From a protocol standpoint, these documents are substantially equivalent to the one that emerged from the Boston IETF except for the changed keyword model of the ``EHLO'' command response. The following documents will follow these three in short order: o A contribution to the MIME effort specifying the logic and conventions for 8bit to 7bit (transport) conversion, o An informational document describing transitional strategies for existing ``8 bit clean'' implementations; and o An informational document that contains additional clarification and guidance material needed to support the protocol extensions (most of this material is from the earlier (consolidated) Working Group draft. The Working Group met twice during this IETF. At the beginning of the first session, the Working Group reviewed new versions of the modular documents developed after the previous last call. These versions, edited by Ned Freed, contained a re-editing to incorporate materials that were still important from the earlier Working Group draft. Significant, and other outstanding, technical issues were then reviewed and decided upon. o Document format: Three+1 (Service extensions, Size, 8bit + informational) or three+2 (... plus informational and folklore (e.g., using Julian's document as a basis). Decision: Multidocument model, not one document, but with the expectation of advancing the three together, i.e., ``three documents, one standard''. 1 o Service extensions/EHLO: The key remaining differences between the new proposal and the earlier Working Group one are in the use of keywords, rather than specific verbs, in EHLO and in the use of parameters (where feasible) to existing commands rather than alternate command forms. Decision: The keyword form is clearly preferable. Given the desire to avoid additional round trips, the increase in complexity of command parsing associated with the parameters is a desirable tradeoff. o An outstanding question is whether possible future extensions that would be associated with commands that don't accept arguments should be implemented with new commands or with parameters on the old ones. Decision: The present Working Group inclination, reflected in the document, is that extensions to parameter-less commands (e.g., DATA should be performed by making new commands. This strategy should be slightly more robust against sloppy implementations. However, this decision can be reviewed when the first such extension is actually proposed. o If an extended command is issued with more than one set of extension parameters, and the server wishes to indicate that the request was not satisfied (i.e., that there is an error condition), there could be an ambiguity about which of the parameters (or the base command) was at fault. Several possible solutions have been proposed, including using the explanatory text in special ways, creating a series of per-extension error codes (possibly in the current-unused 6yz or 7yz range), or ignoring the issue on the assumption that more detail would encourage attempts to negotiate options. Decision: Consistent with tradition and the spirit of RFC1123, things either succeed or fail and we do not provide for tricky negotiation or alternative-seeking. A minimum number of reply codes will be used, implementors may provide textual explanation, but clients should not attempt to take specific action on these. o SIZE: Change from kilo-octets to bytes, with supporting language. Decision: Agreed without dissent. o Use of a single number versus several numbers (e.g., the old LIMIT). Decision: Agreed. These two issues were the only apparently-outstanding ones with SIZE and the only substantive differences between the Moore proposal and the original committee draft not covered elsewhere in this notes. SIZE is therefore closed out and ready for forwarding. o 8bit clean: There was an extended discussion about the existing ``8bit clean'' vendors and the supporting facilities they needed. 2 It was concluded that the CONVERT/NOCONVERT facilities did them no good and that, if the investment was made to send EHLO, then it was plausible to make the further investment to send MIME. Decision: The Working Group agreed, following the pre-July draft, that ``8bit'' implies MIME and that the keywords chosen should reflect this. This change removes the NOCONVERT/ CONVERT/ and MIME keywords from the EHLO response, and eliminates the need for conversion to application/octet-stream and character set ``unknown'' in the protocol document. A separate, non-standards-track, document will be developed to suggest transition strategies. o Relaying: RFC1123 attempted to discourage relaying in the Internet. Sending clients in quest of relays who could perform a conversion after receiving a rejection from a target host probably represents bad policy (although there is neither need nor desire to prohibit static determination of conversion gateways). Leaving the ``go find a relay'' alternative in the text as a means of coping with rejections implies error message complexities that are not worth the trouble. Decision: Remove the text that appears to encourage finding a relay if mail cannot be delivered as originally specified. o MIME-MIME conversions: As things now stand, the text contains several statements about MIME processing that effectively create two-way crossreferences with the MIME document. The earlier Working Group draft resolved this problem by simply insisting that any conversions produce valid MIME, believing that the definitions of ``valid MIME'' belonged in MIME documents, not in SMTP extensions ones. Decision: These text should be removed and replaced by a ``convert to valid MIME'' statement. Any additional statements about MIME and how to handle it should be made in modifications to the MIME RFC or, if necessary, in non-standards-trace transition document. o Trace/received syntax: As of the start of IETF, the document overloaded the RFC821/822 Received phrase ``with'' (specified in those RFCs as a transport protocol) to include conversion statements, e.g., ``with 8bit-to-base64''. This changed the semantics of the 821/822 definition, however subtly. It also produced a significant potential for misunderstanding, as evidenced by the example in the text, e.g., Received: from baiji.dbc.mtview.ca.us by dbc.mtview.ca.us with 8bit-to-base64. It is not clear what this means, since the translation/conversion would normally occur intra-host. Decision: A new phrase keyword will be added, ``convert'', followed by a keyword that will specify the conversion performed in the process of receiving mail and sending it on. This solution also reduces the potential for generating many extra Received lines, which could be problematic for (probably non-conforming) implementations that use the number of Received headers as a trap 3 for mail loops. o The conversion issue: With the proposed documents, the Working Group appeared to have come full circle to a variation on the so-called ``wretched solution'' of 18 or so months ago. That approach called for expecting that any MTA that was willing to accept 8bit traffic must be prepared to convert to 7bit [MIME] if needed. This implied the ability to parse MIME and make per-body-part decisions, raising the threshold of effort that must go into such an MTA and forcing inclusion of a facility that would be unneeded if the transition to an entirely 8bit world ever completed. The Working Group agreed to this in San Diego and did not raise it again in Boston, nor was the issue raised during the Last Call discussion /cries of agony. It was, however, suggested that there never was real consensus, just exhaustion, and that the requirement was ultimately spurious, that the only thing accomplished by such a requirement was to insist that an implementation that was unwilling to convert lie about the reason for rejecting the message. Decision: The document will be revised to indicate a preference for conversion, but to provide for message rejection when conversion was not possible for some reason. o MXE: Some months ago, the Working Group proposed a DNS extension, MXE, which could be used to identify enhanced SMTP servers prior to opening SMTP connections. This suggestion was forwarded to the DNS Working Group, which has not taken an action on it. Decision: the proposal should be withdrawn. Given changes in the extension model, if anything is needed, it might be based on a cross between the EHLO response and the WKS record. Anyone who is convinced that this is important should write a proposal. The Working Group appears to have reached consensus on the above issues and the form and content of revised documents. After the documents are revised to reflect the decisions outline above and a brief review on the mailing list, the documents will once again be recommended to the IESG for processing as a Proposed Standard. Attendees Randall Atkinson atkinson@itd.nrl.navy.mil Bryan Beecher bryan@umich.edu Fred Bohle fab@interlink.com Kay Chang chang@chang.austin.ibm.com James Conklin jbc@bitnic.educom.edu Chuck Cranor chuck@maria.wustl.edu Erik Fair fair@apple.com Roger Fajman raf@cu.nih.gov Ned Freed ned@innosoft.com Olafur Gudmundsson ogud@cs.umd.edu 4 Marco Hernandez marco@mh-slip.educom.edu Russ Hobby rdhobby@ucdavis.edu Tim Howes tim@umich.edu. Frank Kastenholz kasten@ftp.com Neil Katin neil.katin@eng.sun.com John Klensin klensin@infoods.unu.edu Jim Knowles jknowles@binky.arc.nasa.gov Eliot Lear lear@sgi.com Edward Levinson levinson@pica.army.mil Chris Newman chrisn+@cmu.edu Michael Patton map@bbn.com Marshall Rose mrose@dbc.mtview.ca.us Tim Seaver tas@concert.net Mark Smith mcs@umich.edu Larry Snodgrass snodgras@bitnic.educom.edu Einar Stefferud stef@nma.com Stuart Vance vance@tgv.com Gregory Vaudreuil gvaudre@cnri.reston.va.us 5