CURRENT_MEETING_REPORT_ Reported by John Klensin/MIT Minutes of the Internet Mail Extensions Working Group (SMTPEXT) The meeting on the 19th was long, and very intense. The result was a narrowing of the focus on the transport extensions. The meeting began with Greg Vaudreuil introducing John Klensin and handing over the chair. Klensin then announced that the Meta-Agenda for the day was to either focus sufficiently that a clean plan and schedule could emerge or to be able to report that the Working Group was going nowhere and should be abandoned. Klensin then introduced a decision model for the major options facing the Working Group. That model was refined somewhat in group discussion and appeared as follows: Negotiate _____________________________________________________ | | | | Yes No Can't decide Decide not to | ____|___________ _____| | __|____ ?* Prime | | | | | ___|__ | | ? | RFCZZZZ ?* Prime | | |<-----------------| bis bis | |______| | | | | | v v Let 1k flowers v @ @ bloom New protocol ?* @ Notation: ?* -> Need to make a plan @ -> Need to consider--or abdicate--damage control for ``old'' systems, especially wrt blowups and information loss. ``Prime'' refers both to the specific proposal from them and to the class of proposals who share the concept that existing ``8 bit clean/8 bit transmitting'' implementations are acceptable, should be encouraged, and should be joined by others. 1 Considerable discussion ensued. There was no sympathy expressed for the sending of unnegotiated 8bit data as a long term strategy, but a general understanding that it was undesirable to leave existing implementations that do that without plausible transition paths. The Working Group concluded that the receipt of data with the 8th bit set but without negotiation was an error, and proceeded to analyse the error states. The conclusion was that an originating SMTP client was non-conforming if it transmitted any data with the 8th bit set without prior negotiation and agreement. A destination server receiving such a message could respond in one of three ways and be conforming: i. Reject the message as an invalid transport case, presumably using a 520 error code. ii. Deliver the message in 8bit form. This option requires that the MTA ``know'' that such delivery can be accomplished accurately (i.e., without loss of information). This would normally be the case when both delivery MTA and UA were in a ``8bit clean'' environment. iii.If sufficient information is available, downgrade the message to 7bit RFC-XXXX. Since the Working Group did not consider it acceptable to ``guess'' at what the character set might be, or to make an assumption based on, e.g., the sending or receiving country, the ``sufficient information'' condition will in general be met only if the incoming message is already in valid RFC-XXXX format. If a message with leading bits set arrives at a relay host without prior negotiation, the relay has the additional option of transparently forwarding that message. The destination host is no worse off in this case than it would be had the message been sent without the relay. In other words, the Working Group agreed that there was no significant benefit in imposing additional requirements on relays for policing protocol conformance. Relays would, of course, retain the options of rejecting or downgrading, as provided in (i) and (iii) above. There was then general agreement that ``doing nothing'' was undesirable. For some people, the above analysis was acceptable only if the Working Group proceeded to define and agree upon a negotiation model; others were convinced that the analysis and agreement was useful in itself. The various large scale options of RFC-ZZZZ (6 Nov draft) were then reviewed, with backward references to the pre-St. Louis version of that document. The options of ``new protocol'' and ``move more rapidly toward X.400'' were raised as alternatives, but quickly dismissed in the 2 context of the current charge of the Working Group, since they do not address the very real issues of existing 8bit transport over existing ports and protocols. The session on 21 November began with a review of an intermediate draft of RFC-ZZZZ which Klensin had prepared to incorporate the changes agreed to on the 19th. The meeting then went through an interim ``outstanding issues'' list (see Appendix A), eliminating many of the issues and deferring others. As one might expect, some issues were controversial, others were not. A review of the interactions between SIZE and the capabilities concept introduced on Tuesday led to the partial restoration of the former while retaining the latter. The morning's greatest controversy was about exactly what requirement to impose for the capability for conversion from 8bit to 7bit transport forms in mail relays. The issue is complex because it is seen by some as an issue of keeping mail relays simple and, in particular, not requiring that each one have gateway capability, and by others as an issue of increased mail interoperability (or of avoiding decreased interoperabiliy). After lengthy and sometimes heated discussion, it was agreed to adopt a rule designed to reduce as much as possible the chance of deferred rejection of 8bit mail as a result of encountering an 8->7 boundary. A host accepting 8bit mail is not permitted to have the mail later rejected as a result of a conversion requirement. This means, in essence, that any host accepting 8bit mail must either be able to guarantee (through out-of-band information) that it can make final 8bit delivery to the addresses in the message, or must be prepared to arrange for conversion to seven-bit form. The Working Group understands that the conditions for guaranteeing an unobstructed 8bit path can rarely be met in practice and that this requirement means that a mechanism for conversion to 7bit forms is therefore essentially a requirement of a host that is implementing server support for EMAL. Probably the only exception that does not depend on considerable out of band information and very early verification of addresses would be for a server that supported only local delivery, with no capability for relaying, automatic forwarding, or providing mail exchanger services for other hosts. There was then a discussion of newly-written ``packetized data stream'' and ``binary'' proposals by Neil Katin. The discussion of the former was carried far enough to reach general agreement on a model: sending and acknowledgement (in a request-and-wait mode, paralleling DATA) of a ``packet mode'' command. If that command is accepted, the sender can send packetized streams of data using an introducing ``packet N'' command followed by N octet of data without regard to line lengths or delimiters. Each packet would be acknowledged by the server, but the model is designed so that these acknowledgements can be handled asynchronously by the client (permitting batching). After each such packet, the server would expect to receive either another ``packet N'' command; the ``packet 0'' command, indicating end-of-data; or RSET or 3 QUIT. Lengths of packets would be as chosen by the sender. The question of need for a receiver-imposed maximum packet length was discussed. It was finally concluded that such sizes were not an issue given TCP buffering capability; the issue will be revisited if anyone can identify a case in which server-imposed restrictions are actually needed. Agreement was reached in principle on incorporating packetized data stream (as described above) and binary mail. Joint work with the 822-extensions group to provide additional specifications for the handling of error messages that must be mailed back to the sender (rather than reported as part of the SMTP transaction). These efforts will be incorporated into RFC-ZZZZ if they converge rapidly enough and are appropriate; otherwise they will be handled as separate documents. Specific conclusions about RFC-ZZZZ were: 1. There is, at present, no real demand for transport forms wider than 8 bits or for addressing the issues such transport would cause. The question will be revisited when and if there is a requirement for such transport. 2. It is important to clarify and establish an extension model for RFC821 now, even if no substantive changes were incorporated into that extension model. 3. There is no demand for 8-bit versions of SOML and SAML, since it is unlikely that anyone would really want RFC-XXXX messages delivered directly to their screens. An 8-bit version of SEND FROM is problematic, since such messages are typically transported without headers, leaving ambiguitites about the character set in use as soon as the characters are not clearly ASCII. If and when there is demand and a definition for an enhanced SEND, an extension can be proposed and considered. 4. As a result of (1) and (3), the marginal ``cost'' of a new transport variation (e.g., binary or ESND) becomes one verb, not four verbs. And, since there is willingness to defer extended-width (past 8) entirely and predict that it will not be needed, the complexities and additional states associated with the TYPE verb can be eliminated by getting rid of that verb. This, of course, implies that EMAL limits the message being transported to being one in which ASCII (with a leading zero bit) can be successfully used in trace fields. That does not appear to be a severe restriction in practice, regardless of the theoretical possibilities. 5. While the concept of a SIZE inquiry is desirable, it was felt that several other inquiries may be useful also and that it was not 4 desirable to worsen the query-and-wait transaction model. Consequently SIZE (as an inquiry) is to be removed and replaced by a capability inquiry to which a server would return such information as what size messages were normally acceptable and what other options were supported in a canonical way. The format of the canonical response awaits further definition, although there was sympathy for something of the attribute=value character. There was also discussion about the implications of denial of the availability of a service without general agreement other than a client should not ``try anyway'' if some capability were explicitly denied. There was also a discussion of the fact that some hosts might wish to avoid giving out `capability information as a security measure in order to avoid disclosing operating system or similar information. This may imply that hosts should be able to respond to a capability request by explicitly asserting certain services, by explicitly denying them, or by providing no information (in which case the client would normally behave as if the inquiry had not been made). 6. The SIZE verb, used to alert the server of the approximate size of a file that is about to be transmitted, is retained. This verb serves two main purposes: early rejection of large messages, rather than having to transmit them first and providing receivers some ability to prepare for large messages. The latter may actually permit larger messages to be delivered. 7. Additional text should be put into the document that explicitly identifies the results of experiments with existing servers relative to handling of unknown verbs and recommending behavior if commands are refused with syntax errors. 8. The explanatory/discussion sections should be retained, although we may wish to start identifying those that are intended for a final document separately from those which are to be retained only during discussion. 9. Support of EVFY is required of any server that supports EMAL and support of CPBL is required of any server that supports any enhanced capability (beyond those of SMTP). For the latter, ``support'' is defined as the ability to return useful information on which the client is expected to take action. Mechanisms for CPBL responses that do not reveal information will be considered only if an explicit request or requirement is received from the security area. 10. While enhanced trace field capabilities and requirements are needed if enhanced mail features are not going to make it appreciably harder to identify and fix problems (it is already bad enough), that material will be removed to a separate document if agreement cannot be reached quickly enough. The Working Group identified one specific concern, which is the need to bind conversion-tracing fields to RFC-XXXX body parts, not whole messages, since some conversions will be performed one body part at a time. The 5 requirement for this body part header has been brought to the attention of the RFC-XXXX authors. 11. The material on RSET and defining new FROM verbs is useful and should be retained. Some textual improvements are needed. 12. CPBL does not accept an argument; the use of one is a syntax error. The following issue is considered resolved unless new issues and alternatives are raised. It differs from the above because, rather than being discussed at length, there has apparently been no interest in taking issue with it since the first version appeared in the first Internet Draft version of RFC-ZZZZ. 13. The model for which error/response codes are used in various situations. The placeholder for this has been changed to a ``tentative agreement'' paragraph. Summary, Schedule, and Plan. After discussion with the Applications Area Director and the IETF Chair, we should plan on requesting that RFC-ZZZZ be promoted to proposed standard status not later than the end of the March IETF meeting. It appears after the November 1991 Working Group meetings that there are no show stopper issues remaining (if this is not the case, people should identify them as soon as possible). There are several issues for which options, details, or explicit text still need to be worked out. Any of those that cannot be worked out and agreed upon by March will be removed from RFC-ZZZZ and handled separately. A new version of RFC-ZZZZ has been prepared and is being submitted for publication as an internet draft. Note that this version supercedes the one announced on the list and circulated to the 21 November Working Group meeting. John C. Klensin Chair, SMTP Extensions Working Group Klensin@INFOODS.MIT.EDU APPENDIX A Outstanding issues, RFC-ZZZZ-02. 20 November 1991 The list that follows was used as the Agenda for the 21 November Working Group session. 6 Note: Most of the issues below have been resolved. The resolutions are discussed in the main body of the Minutes. Those that have not been resolved appear, in one form or another, as ``open issues'' in the working draft document and/or in the ``action item list'' that appears as Appendix B. The list below is included with the Minutes because it documents the progress, direction, and process of the Working Group during the Santa Fe meeting. 1. Should the remaining discussion paragraphs be retained somewhat longer or removed at this time? (general) 2. Fixing error codes (end of section 1A, 11.2). 3. Should EVFY be required of systems that support this protocol? Is it adequately specified? (3ii and 6) 4. Should support for CPBL be required of servers that support this protocol? Is that a reasonable name? Is refusal to supply information an error or just a special case of a ``1yz'' message? (3iii and 7). 5. Should the material on trace fields be retained? Is it ok? In particular, is it desirable to identify the gateway or other processor that is making changes but to explicitly try to avoid specifying the nature of the transformation? Are special considerations introduced when multiple body parts are converted separately? (3iv, 3v, and 9). 6. Is the material on RSET necessary and/or useful? (3vi, 10). 7. Mechanism for defining and registering new FROM verbs (5.2). 8. Is there any possible reason to prohibit any possible ``conversion prohibited always'' cases? Should this be called out? (5.2). 9. BINARY (5.1) 10. CPBL/SIZE (7). Eliminating SIZE as an inquiry prevents a server from setting up special buffers, allocation sizes, or space to receive a message of a particular large-ish size. That forecloses the ``I can accept larger messages if I know they are coming'' cases. Is this what we intend? 11. CPBL (7). Prohibited argument? 12. CPBL (7.1) Format of reply. 13. CPBL - client behavior (7.2). Is this what we want? In 7 particular, is the model of behavior when the server indicates that a particular option is not available the one intended? 14. Trace fields: Needs to be checked against and updated to current RFC-XXXX (9). 15. ``With smtp''. Use for both 7 and 8 bit forms? (end of 9). 16. Is the restriction rule on servers accepting EMAL FROM and then rejecting an address correctly stated (11.1)? 17. Return of error messages over irreversible path. Do we need a ``Content-type: bogus'' in RFC-XXXX, or is returning without the original message text acceptable? (11.1) 18. Is the requirement for support of downgrading in relays correctly stated (11.4.2)? I think we do not want to discourage people from implementating relays on small machines or constrained environments. APPENDIX B Remaining outstanding issues and action items as of 22 November 1991. Note that some additional issues are flagged in the draft as ``tentative decision'' or ``open issue''. The difference between these two categories is that the former will be considered resolved unless someone objects prior to the third Internet-Draft version of RFC-ZZZZ. Some issues below are labelled ``default decision''. This identifies the approach that will be taken if timely agreement cannot be reached. 1. Syntax for CPBL responses, especially for size information (section 7, volunteer sought) 2. Extensions to RFC-XXXX to support per-body-part trace/conversion information (Freed). 3. Text and description for ``packet mode'' (Katin) Default decision: Defer 4. Text and description for ``binary'' (Katin) Default decision: Defer 8 5. Mechanism and model for IANA registrations of things that must meet complex definitional criteria as a prerequisite for registration. Procedure for getting approval for IANA to assume this role. (IESG problem: Vaudreuil) 6. Open Issue: The CPBL functionality gives us a way to explicitly specify how further extensions beyond those of this document (including ``private'' ones) might be tested. In addition to possibly the usual words about ``X''s, we could *require* that the attempted use of any verb not specified in a standard or near-standard RFC must be preceeded by the use of CPBL to verify that the server supports it. My bias that being explicit reduces later problems makes a small argument for including some text to this effect. Anyone who feels strongly one way or the other should speak up. Default decision: Defer (punt) 7. Extensions/Mechanisms for formatted error messages when such messages are mailed back. There are really two separate problems here: an encapsulation model (RFC-XXXX extension) for returning the content of 8bit messages over 7bit channels and a canonical representation and taxonomy for mailed error responses. Note that these are primarily RFC-XXXX problems; RFC-ZZZZ mostly just needs to point to the solution. (Freed, Klensin, others sought). Also note that not solving the encapsulation problem implies non-return of content in some cases. Default decision: If agreement cannot be reached, the language in RFC-ZZZZ that permits non-return of content in some cases will be strengthened. The canonical mesage form problem is one we have been living with since before RFC 821 and is not on the critical path for RFC-ZZZZ. 8. Tentative decision: People should review the new SIZE, rewritten to reflect the presence of CPBL, and complain if they don't like it and want to propose specific changes. Attendees Mary Artibee artibee@sgi.com Nathaniel Borenstein nsb@thumper.bellcore.com James Conklin conklin@bitnic.educom.edu Mark Crispin mrc@cac.washington.edu Peter DiCamillo cmsmaint@brownvm.brown.edu Erik Fair fair@apple.com Ned Freed ned@innosoft.com Olafur Gudmundsson ogud@cs.umd.edu Russ Hobby rdhobby@ucdavis.edu Christian Huitema christian.huitema@sophia.inria.fr Neil Katin katin@eng.sun.com John Klensin klensin@infoods.mit.edu Jim Knowles jknowles@trident.arc.nasa.gov Vincent Lau vincent.lau@eng.sun.com Eliot Lear lear@sgi.com 9 Gordon Lee gordon@ftp.com Jack Liu liu@koala.enet.dec.com Paul Milazzo milazzo@bbn.com Keith Moore moore@cs.utk.edu Robert Morgan morgan@jessica.stanford.edu Chris Myers chris@wugate.wustl.edu Mark Needleman mhn@stubbs.ucop.edu Michael Newell mnewell@nhqvax.hg.nasa.gov Daniel Newman dan@innosoft.com Michael Patton map@lcs.mit.edu Robert Purvy bpurvy@us.oracle.com Robert Shirey shirey@mitre.org Keld Simonsen keld@dkuug.dk Ursula Sinkewicz sinkewic@decvax.dec.com Gregory Vaudreuil gvaudre@nri.reston.va.us 10