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