Minutes of the June 21 SMTP extensions working group. Attendees --------- Phill Gross pgross@nis.ans.net Peter Svanberg psu@nada.kth.se Byungnam Chung bnchung.sokri.etra.re.kr Bob Kummerfeld bob@ca.pn.oz.au Jonny Eriksson bygg@sunet.se Jan Michael Rynning jmr@nada.kth.se Keld Simonsen keld.simonsen@dkuug.dk Greg Vaudreuil gvaudre@nri.reston.va.us Agenda ------ 1) 8 Bit Transport - Overview of current status - Review of current proposals o Negotiated 8 bit support o Unnegotiated 8 bit support o Use of 7 bit transport with encoding - Discussion: Which is the preferred proposal? 2) Mail Enclave Issues - Local use of non-standard practices: Real problem or not? o Non-standard or non-support of transfer encodings o Local use of non-standard character sets - Define Enclaves o Administratively limited? o Universal mesh of capabilities? Minutes ------- 1) 8 Bit Transport Issues Much discussion has occured both on the mailing list and in private with the chairman calling into queston the conclusions the smtpext working group reached during the St. Louis IETF in March 91. This issue was raised at this Copenhagen meeting to reconsider or reaffirm the conclusions the working group at that earlier meeting. There continue to be two credible proposals for transition to 8 bit transport. Th first is a proposal to redefine the SMTP protocol to standardize the existing practice sending 8 bit mail over standard SMTP channels. The second is a proposal send 8 bit textual data after negotiating that capability. The working group review the two proposals and came to the following understandings about the proposals. A third "proposal", do nothing, was evaluated as well. a) Redefine SMTP to pass 8 bit data. The proposal stems from the existing practice of sending 8 bit data between SMTP implementations without negotiation or confirmation of the capabilities of the receiver. Benefits -------- - It works (Mostly) - Easy modification to existing code to gain functionality - Currently deployed by several vendors, and tested extensively in current mail environments. Costs ----- - There is no assurance that the message was delivered as intended. - Use of C1 codespace may be compromised. - Not functionally compatible with many current SMTP implementations. Discussion ---------- - The extensions have been extensively tested in a "friendly"environment where character sets sent have not used C1 codespace for graphic characters, nor have multi-byte characters been sent. - Some unpredictable behavior has been noted. - The costs are continuing, they never go away. b) Negotiate the sending of 8 bit data Benefits -------- - Backwards compatible with current conforment implementations. - Failure is detectable, and recovery by encoding and resending is possible Costs ----- - Not compatible with some (much?) current deployed software - Failure recovery after negative negotiation potentially complex - Code changes are more complex Discussion ---------- - The costs of the transition are one time, and will fade away with time. c) Send no 8 bit data Benefits -------- - The hassle of upgrading current transport is unneeded - All functionality is supported through encoding Costs ----- - Encoding required additional resources including computer time as well as communications bandwidth - Local users may use 8 bit transport anyway. Discussion ---------- - The technical analysis of this issue is but a small part in the problem. There is a strong feeling, almost religion,among site administrators and many "users" that encoding data that is easily transportable of the network infrastructure is wasteful, inelegant, and just plain wrong. d) Conclusions The attendees of this meeting reaffirmed the working group consensus that standard for the transmission of 8 bit characters without negotiation has costs which were too in terms of expected mail performance to be acceptable. The main points underscoring this conclusion was the inability to "know" the transaction was successful, and the effective loss of the ability to use C1 codespace in future character sets intended to be transportable over SMTP. While it was noted that much experience has been gathered with current implementations using un-negotiated 8 bit mail, it was understood that this experience was gathered in a relatively homogeneous environment with friendly character sets. Problems were expected by the working groups in general application in the Internet and in sending characters sets like IBM PC codepages which use C1 codespace. 2) Enclave Issues The working group felt that the concept of enclaves was not something that had to be defined. Specifically, the idea that enhanced capabilities should be confined to a administrative or geographical region was seen as being too restrictive. The attendees preferred to maintain the end to end model of electronic mail, rather than formalize the concept of autonomous mail domains.