This is only a rough draft - Megan 04/15/92 IETF SMTP Extensions WG Minutes: San Diego IETF -------------------------- Summary ------- During the San Diego meeting, the WG reviewed several issues that had been settled earlier, but for which it appeared that new technical issues had been identified. The WG concluded that there were, in fact, no significant new technical issues being raised, and no significant changes to the working document were made. The WG did succeed in tying up the remaining loose ends in the document, including identifying locations where additional explanatory text was needed and providing exact keywords, syntax, and definition for concepts agreed upon some time ago. The present draft provides an extension model and compatible extensions to SMTP for mail transport of 8-bit characters. Using the same extension model, it provides some additional extensions to supplement SMTP and improve its efficiency, especially when very large files are being transmitted. It is expected that a new Internet Draft, reflecting agreements made in San Diego, will be produced shortly after IETF, reviewed quickly on the mailing list, and then submitted for processing as a proposed standard. The meeting contained an extended discussion of the issues raised the previous day, including a review of whether the WG's work and the RFC-ZZZZ model fit well into a "transition plan"/"final target" model. Several other issues were revisited, including the question of whether we might be better off with a new protocol on a new port. The assertion was made that the present model either constituted two separate services over the same port (in which case it was muddled and wrong) or some attempt at hidden gateways (in which case there was fear of other problems). It was pointed out that the two port model made it very difficult to distinguish between no service on the "new" port and temporary unavailability. The advocates of the two-port model felt that this was a non-problem unless one wanted to mix services or have implied gateways. It was pointed out that no gateway was implied if the originating system was prepared to send a message in either 8-bit or 7-bit form, but preferred 8 if that was available. There was a brief religious argument as to whether or not this case was interesting. The WG concluded that it did not want to revisit the "new port" issue. A second heated discussion over the CPBL command with a contention that the command would increase the number of round trips pitted against a contention that it would give intelligent clients the ability to reduce the actual number of round trips. The WG decided to retain CPBL. The issue of "SIZE" was reviewed, both with regard to the information to be returned by CPBL (redesignated as "LIMIT" after the meeting to reduce possible confusion) and with regard to the estimation and treatment of the value to be sent with the SIZE verb. The WG concluded that the capability limit should be reported in terms of two administrative values, the size that the implementation would try to provide in all cases and the size that would probably always be rejected. The editor was directed to provide some guidance in the document for estimating, in hosts with single-character newline conventions internally, the size to be transmitted. See the new version of the draft document for the results of these discussions. Details of Discussions and Decisions ------- -- ----------- --- --------- As discussed in the summary above, much of the two WG sessions at this meeting was devoted to a review of previously-settled issues, sometimes from a new point of view. Issues and proposals raised included: * Syntax and semantics for the response to the CBPL command/inquiry. The WG decided that this should list all capabilities of the server, on a one-verb-per-line basis, using the existing syntax for multiline responses. This is one of the options considered in Santa Fe and tentatively approved. The handling of the "message size" portion of the response was as agreed on in Santa Fe, i.e., providing the administrative limits. * Syntax and semantics of the SIZE command. The decisions made in Santa Fe were affirmed and refined. See the forthcoming version of the Internet Draft for additional details on the two features above. * Possible separation of a "transition model" from the "protocol" as it would exist in deployed form, e.g., creating two clearly separated documents. The WG concluded that this was neither necessary nor appropriate. * Possible replacement of the notion of capabilities inquiries with a clear "version" model with no optional features. The theory behind this was that the Internet has succeeded because of the small number of options (Telnet negotiation notwithstanding) and that few clients have really be designed to take advantage of optional features in any event. This discussion led to the insight that some confusion has been created by describing EMAL and related features in "negotiation" terms. They are really verification that particular expected capabilities are present. The next version of the Internet-Draft will been modified to reflect the "verification" terminology and to remove "negotiation". This does not affect the operation of the proposed protocol. After some discussion, the WG concluded that a "version" model was inappropriate. Different members saw different problems, but the most serious included the fact that SMTP already contains optional features (e.g., the interactive mail commands SEND FROM, SOML FROM, and SAML FROM) and that introducing strict "all or nothing at this level" versioning would require either requiring support for those verbs and concepts or deprecating them. The WG was unwilling to consider doing either; some members considered such tampering with the requirement level for existing features to be outside the WG's scope. There were also concerns about excessively raising the level of effort required for a minimal implementation of the new features, thereby defeating the WG's goal of providing as smooth and easy a transition path to existing (nonconforming) 8bit-sending implementations as possible. * There was interest expressed in "address streaming" and, in particular, return of sequence numbers in replies to RCPT TO commands. The WG concluded that this was not an extension it was willing to make to SMTP during the current round, especially since no concrete or specific proposal was on the table. John C. Klensin Chair IETF SMTP Extensions WG