CURRENT_MEETING_REPORT_
Reported by Greg Vaudreuil/CNRI
SMTPEXT Minutes
Agenda
o Where are we, and where are we going?
- Just send 8 bits
- Negotiate 8 bits
- Do nothing
o If negotiated, how to do transport conversion?
- Encapsulation
- Message Munging
o Defining the ``New'' SMTP
Where are We, and Where are We Going?
The Chair began this meeting by reviewing the history of this Working
Group and the goals as they have evolved. This meeting was called in
part to affirm the progress on the mailing list in a room where true
give-and-take could be had. In a nutshell, the SMTP extensions were
first motivated by those who want to be able to send 8 bit textual data
via SMTP. This is already being done in practice. The group discussed
the goals and in light of current deployment of non-standard systems,
refined the goals to include a more general extension to the SMTP
protocol.
There was a general feeling among many participants that a simple
extension to support only 8 bit textual data was not worth the
transition costs involved in upgrading the system. There are however
many reasons to update the mail transport protocol. Among these needs
are arbitrary options negotiation, binary transport, maximum message
length restrictions, and ``real'' authentication. A sampling of
opinions from the meeting:
o The Europeans REALLY REALLY want to send their stuff without
encoding it. They REALLY REALLY want to do this via a negotiated
option so they could have an assurance that the mail was delivered
as intended.
o Existing software vendors, Prime, Sun, and others not so visible,
do not feel that 8 bit textual data transmission is worth the costs
of modification. This was strongly asserted at the St. Louis
IETF, while the mailing list (led in part by the Chair) went off
and wrote an SMTP extensions specification for 8 bit mail anyway.
1
o Even the multi-part multi-media mail people could agree with the
assertion that the world would be a better place if binary data
could be sent.
After a bit of soul searching, the group agreed to work on a complete
change to SMTP which would allow future new features to be added via
negotiation, and would allow binary and 8 bit transport.
Interworking of 7 bit, 8 bit and Binary Transport.
Now that the Working Group decided to move ahead on new functionality,
the next question to be solved was the definition of an interworking
strategy. Fortunately for this group, the Message Format Extensions
group decided to keep nested transport encodings in their proposed
standard document. While this feature is tentative and subject to the
results of implementation experience, it provides a mechanism for
initial implementations. After a short amount of discussion, the group
decided to write a specific, well defined conversion algorithm which
specifies that messages which need to be converted between transport
environments, MUST be encapsulated into a new message of the form
defined in the message format extensions document. This encapsulation
will result in a message with a single body part MESSAGE with an
appropriate transport encoding. If the message format document is
changed to make illegal nested transport encodings, this issue will have
to be revisited.
The strict definition of the transport encoding to be used was
discussed, and the consensus of the group was that a strict
specification of which transport encoding to use could not easily be
made to work. The best approach for an implementor is to scan the
document and determine statistically whether it would be better to
encode the entire message in a Base 64 encoding or escape the few
offending characters via a quoted printable encoding.
Defining the ``New'' SMTP
The Working Group began work on the new SMTP version. It was argued
that the greatest change necessary is to define a negotiation mechanism
for new capabilities. Some of these capabilities are:
o 8 bit Text
o Binary Transport
o Authentication
o Delivery Notification
o Message Size Negotiation
o Explicit Batch Mode
Several modifications to the protocol were suggested that were
feature-independent. Among the suggestions were:
A Second TCP Connection for Data
2
A second data connection would make it possible to do data
checkpointing, and would reduce the cost of sending binary data.
Drawbacks include the overhead of opening and tearing down a second
channel, and running SMTP over non-tcp single-channel protocols such as
X.25. The Working Group decided not to pursue this approach. The cost
of sending binary data over the existing channel either by escaping or
byte counting was found to be preferable over the cost of opening a new
TCP connection. Checkpointing in FTP is still not widely used, and is
considered by this group to be of dubious value.
Asynchronous Operation
Currently SMTP commands are batched by several implementations and sent
in a single packet to save round-trips. This has been demonstrated to
work with known SMTP implementations. An extension to tag the data and
the commands to allow full asynchronous operation was proposed. This
offers very significant improvements in throughput by reducing packet
per verb to control packet per session in the best case. The Working
Group debated this point and concluded that full asynchronous operation
would push SMTP into a not-so-simple MTP.
A Negotiation Infrastructure
The group agreed that a mechanism needs to be defined to allow the
extension of SMTP. The current approach of this Working Group has been
to add functionality via the addition of new verbs. While this approach
is seen by some to be the strait forward answer, using new verbs can
cost significant time in round-trip delay while playing a network
version of the old card game ``go-fish''. Other suggestions included a
telnet like negotiation.
The Working Group began exploring features of a new negotiation
mechanism for the SMTP protocol. Among the possible goals are:
o Symmetry -- should the receiver and the sender both request an
option?
o Batchable -- should more than one option be negotiated at a time?
o Duration -- per-session, per message, or per-recipient?
o Default behavior - should the default be better than current SMTP
service?
Symmetry: Symmetry was suggested as a means to allow authentication of
the sender by the receiver. At this time there is no formal
authentication mechanism, and the negotiated use of CAT or Kerberos was
seen as a good thing. After lengthy debate, the group decided that
authentication of the sending SMTP in a store and forward network was of
dubious value and was not worth the added complexity a symmetric
negotiation entails.
Batchable: Batching negotiated parameters offers great savings in
round-trip times. It is not clear how this would work in practice, but
the group felt that this was a good goal.
3
Duration: This was a tricky subject. Currently SMTP does not provide
any information about the users environment. Any use of per-recipient
or per-message requires the keeping of more knowledge about the end-user
than the system has now. It was not clear to the group that any
per-recipient options exist that could not be duplicated by a local
delivery agent.
Default: This turned into a no-brainer. The group unanimously felt
that the new SMTP needed to be backward compatible, and in the case of
complete failure of any negotiation, the mail would continue to go
through as specified in RFC 821 and HR.
The meeting concluded with the discussion of several specific
negotiation strategies. Several attendees volunteered to write up
proposals for negotiation mechanisms. This discussion will be continued
on the mailing list.
Attendees
Peter Boos peterb@bnr.ca
James Conklin conklin@bitnic.educom.edu
Johnny Eriksson bygg@sunet.se
Erik Fair fair@apple.com
Ned Freed ned@innosoft.com
Olafur Gudmundsson ogud@cs.umd.edu
Russ Hobby rdhobby@ucdavis.edu
Neil Katin katin@eng.sun.com
Darren Kinley kinley@crim.ca
Jim Knowles jknowles@trident.arc.nasa.gov
Vincent Lau vincent.lau@eng.sun.com
Eliot Lear lear@turbo.bio.net
Jack Liu liu@koala.enet.dec.com
Joseph Malcom jmalcom@sura.net
Leo McLaughlin ljm@wco.ftp.com
Keith Moore moore@cs.utk.edu
Michael Patton map@lcs.mit.edu
Jan Michael Rynning jmr@nada.kth.se
Mark Saake saake@llnl.gov
Harri Salminen hks@funet.fi
Keld Simonsen keld.simonsen@dkuug.dk
Gregory Vaudreuil gvaudre@nri.reston.va.us
4