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