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