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