CURRENT_MEETING_REPORT_ Reported by Greg Vaudreuil/CNRI AGENDA o Introduction o Why Are We Here? o Should We Be Here? o Goals For The Group o Mail Extensions Architecture o Message Format Architecture SMTPEXT Minutes The IETF Internet Mail Extensions Working Group met for two days at the 20th IETF meeting in St. Louis. The meeting began with an overview of the motivations for forming the Working group, and a discussion of the role the group should play in the context of the current Internet mail environment and the emergence of X.400 based mail systems. There was little debate about the necessity to engineer a short-term solution to the need for greater mail functionality, especially for international character set support. There was a feeling that the work of this group could potentially speed the X.400 deployment into the current Internet. By increasing the functionality of X.400 gateways and stimulating the development of multi-media mail facilities, the work may facilitate the smooth transition to X.400. No one expressed an opinion that this work should not continue. The Working Group spent the remainder of the morning enumerating possible goals for the mail extensions effort. The group proceeded to narrow the list of goals to a manageable subset for the first phase of the effort. Possible Goals Goals chosen for the initial effort marked with an X. x Include support for most international multi-character sets in message body 1 x Support multi-part messages x Support multi-media messages x Increase interworkability with X.400 x Remain backward compatible with RFC 822, 821 x Support enhanced functionality over current 7 bit transport ? Use 8 bit transport paths if available ? Enhance multi-character set support in message headers x Resolve line length, end of message, and format effector issues - Resolve message length issues (Message Fragmentation) - Include external references for long messages - Define standard error message reporting formats (Internet Mail Control Message Protocol) - Define a standard UA configuration file format (.mailcap) - Mail Gateway requirements document - Receiver initiated file transfer - POP-IMAP-PCMAIL standardization issues - Subsume X.400 Functionality (Return Receipt, Privacy Enhanced Mail, Accounting) - Listservice Specification ? Mail Transport MIB ? Enhanced addressing (i.e., Phone Number, Postal Address) - Mailbox Management - Message Storage Architecture x Establish Liaison with X.400 After enumerating the goals for the mail extensions effort, the group proceeded to categorize the goals as either RFC 822 Message Format Extensions or RFC 821 SMTP Extensions. The group briefly discussed the differences between RFC 821 and RFC 822, resulting in greater understanding of the current mail environment. One crucial distinction was the point in the specifications where ASCII-7 is defined to be the character set. It was found that SMTP does indeed specify ASCII as the character set, rather than the set of allowed bit codes. 2 Architecture The Working Group proceeded to spend the second full afternoon sessions discussing the transport architecture to be used in enhancing the current Mail system. The architecture discussion was crucial to understand the context of the changes needed to the message format, and SMTP RFC's. Initially there were two competing ideas for this architecture, and later, a transition solution was proposed. The 7 Bit Solution The first proposal, based on the existing 7 bit infrastructure, specified no changes to the SMTP protocol, and made all mail functionality enhancements in the RFC 822 message format. In the special case of 8 bit text, the conversion to a 7 bit encoding occurs in the sending and receiving user agents. +----------+------+ +------+----------+ | 8 Bit UA | 8to7 | | 7to8 | 8 Bit UA | +----------+------+ +------+----------+ | | | +------------+ +-----------+ | +---| 7 Bit MTA |------| 7 Bit MTA |--+ +------------+ +-----------+ The 8 Bit Solution The second proposal, based on current practice among those currently using extended character sets in Europe, consisted of lifting the 7 bit restriction in SMTP, and using existing 8 bit friendly user agents to pass 8 bit character codes to capable terminals. This proposal has been referred to as the ``declare 7 bit to be broken''. It was asserted that most SMTP MTA's currently pass 8 bit mail unmodified. This proposal requires no special encoding of 8 bit text. +----------+ +------------+ +-----------+ +----------+ | 8 Bit UA |----| 8 Bit MTA |----| 8 Bit MTA |----| 8 Bit UA | +----------+ +------------+ +-----------+ +----------+ These two proposals are not interoperable. The first, the 7 bit solution, interoperates with current SMTP agents, but not with existing 8 bit users or their agents. The second works with existing 8 bit user agents but not fully conformant SMTP implementations. 3 The 8/7 Bit Transition Solution After some discussion, a transition solution was proposed by the Chair, soon to be dubbed the ``Wretched'' solution. This proposal required 8-bit capable SMTP agents to convert from 8 bit to 7 bit message formats. This proposal was based on the principle that a conversion from 8 bits to 7 bits can be specified such that the same conversion can be made either by a user agent, or by a mail forwarder on a per-message demand basis. This transition proposal has two distinguishing features. In the existing world of 7 bit SMTP MTA agents, it is identical to the 7 bit proposal, requiring all UA's to either encode or decode 8 bit text. In the ideal world where all SMTP MTA's are 8 bit capable, it is identical to the 8 bit solution. It does however require implementing the conversion process in both the MTA's and UA's. A third feature, one that turned out to cause problems, is the requirement that the entire message be convertible from 8 bit to 7 bit without regard to the contents. It was felt that if a suitable encoding was chosen, it could be indicated by prepending a new header line ``Message encoded in 7 bits'' by any MTA that modified the message. +------------+ +-----------+ +--------->-| 8 Bit MTA |--------| 8 Bit MTA | ------------+ | +------------+ +-----------+ | | | | +------------+------+ +-----------+ | | +-| 8 Bit MTA | 8to7 |-------| 7 Bit MTA |---+ | | | +------------+------+ +-----------+ | | | | | | +----------+------+ +------+----------+ | 8 Bit UA | 8to7 | | 7to8 | 8 Bit UA | +----------+------+ +------+----------+ | | | +------------+ +-----------+ | +---| 7 Bit MTA |------| 7 Bit MTA |--+ +------------+ +-----------+ At the conclusion of the first day, the group tentatively adopted the transition solution. 4 Day 2 The second day was scheduled to begin work on the specifics of the Message Format Extensions required to achieve the goals previously defined. The work was intended to be essentially independent of the RFC 821 SMTP efforts to be discussed later in the day. However, within minutes, it became clear that the group had not realized many of the implications of the transition proposal. Specifically, there is an implication that non-text messages originating from a 8 bit User Agent may, with certain encodings, be re-encoded by the MTA, resulting in double-encoding. For a worst case example, consider a binary message encoded to utilize a full 8 bit path. If it encounters a 7 bit MTA later in the journey, it will be converted again. While judicious choice of encodings will make this double encoding a non-issue, the perceived additional complexity, and the restrictions this implied in the multi-part, multi-media extensions to be proposed caused many in the group to re-evaluate their positions with regard to the transition proposal. For the purpose of making progress the Working Group adopted the 7 bit proposal to begin work on the 822 message body extensions. There remains significant constituency for the transition proposal, but after hours of hallway discussions, the group reached a consensus that changes to SMTP merely to facilitate the 8 to 7 conversion were not sufficient to justify upgrading the MTA infrastructure. However, many hold hope that enhancements including binary transmission will result in a system that can fully and efficiently utilize 8 bit transport. Message Format Extensions After the contentious issues of mail transport were put behind the group, work began on defining an extension to the RFC 822 message format to facilitate multi-part, multi-media applications, including international character sets. The group began by considering a specific proposal by Borenstein, Freed, Vance, and Carosso (BFVC). As this proposal was put forth, a debate ensued over the relative merits of line counts vs message boundary delimiters. The group felt that in general, message delimiters were superior to line counts for reliability and readability, but that line counts were useful ``hints'' which allowed fast parsing of long multi-part messages. A proposal to combine both message delimiters and line counts was made, but not pursued. The group moved forward and choose to use the BFVC proposal as a strawman. Several issues were raised. The message boundary delimiter is chosen at random for each message. This eliminates the need to reserve a specific begin and end sequence for messages. It was not clear how difficult it would be to implement this scheme. 5 The content-encoding and content-type are independent fields which are included for each of the message body parts. Advocates asserted that these independent axis make the overall implementation easier than defining a standard encoding for each body part. This proposal allows a sender to encode a message in whatever encoding type is optimal for the message sent. The receiver must then be able to decode each of the several standard encoding types. With several standard encoding types defined, a sender could pick the ideal encoding for the particular message type. This many-types, limited encodings approach reduces the complexity for a full featured user agent. This proposal has the disadvantage of increasing complexity in a single function station, such as a fax server, or text only user agent. The implication that a user agent must implement several decoding and encoding mechanisms to simply receive and send 8 bit text was of some concern. This was discussed but not resolved. One proposal was to make 8 bit text a special case with a single encoding type. A strawman poll was taken with the following options. 1. Body part ``a'' must be sent with encoding type ``y'' 2. Body part ``a'' should be sent with encoding type ``y'', but may be sent with any encoding x,y,z 3. Body part ``a'' can be sent with any encoding x,y,z 4. Body parts a, b, c can be sent in any encoding x,y,z except for body part ``d'' which must be sent in ``x'' There was no majority, with most expressing preference for (2), and and equal number expressing either (3) or (4). Future Meetings The Chair of the Working Group strongly advocated an interim meeting. He proposed a choice between a face to face meeting or a teleconference. The group preferred a Video Teleconference. The Chair took an action to find open dates and if possible, schedule a teleconference. Interest was expressed by some of the international participants in holding a Working Group meeting in Europe in the near future. Attendees Nathaniel Borenstein nsb@thumper.bellcore.com Cyrus Chow cchow@orion.arc.nasa.gov Alan Clegg abc@concert.net Mark Crispin mrc@cac.washington.edu 6 David Crocker dcrocker@pa.dec.c Johnny Eriksson bygg@sunet.se Ned Freed net@ymir.claremont.edu Shari Galitzer shari@gateway.mitre.org Tony Genovese Olafur Gudmundsson ogud@cs.umd.edu Russ Hobby rdhobby@ucdavis.edu Neil Katin katin@eng.sun.com Tom Kessler kessler@sun.com Darren Kinley kinley@crim.ca Anders Klemets klemets@cs.cmu.edu Jim Knowles jknowles@trident.arc.nasa.gov Ruth Lang rlang@nisc.sri.com Vincent Lau vlau@sun.com David Lippke lippke@utdallas.edu E. Paul Love loveep@sdsc.edu Leo McLaughlin ljm@ftp.com David Miller dtm@ulana.mitre.org Mark Moody ccmarkm@umcvmb.missouri.edu Keith Moore moore@cs.utk.edu Robert Morgan morgan@jessica.stanford.edu Michael Patton map@lcs.mit.edu Joel Replogle replogle@ncsa.uiuc.edu Jan Michael Rynning jmr@nada.kth.se George Sanderson sanderson@mdc.com Ursula Sinkewicz sinkewic@decvax.dec.com Lawrence Snodgrass snodgras@educom.edu Bernhard Stockman bygg@sunet.se Dean Throop throop@dg-rtp.dg.com Robert Ullmann ariel@relay.prime.com Gregory Vaudreuil gvaudre@nri.reston.va.us John Veizades veizades@apple.com Chris Weider clw@merit.edu John Wobus jmwobus@suvm.acs.syr.edu Russ Wright wright@lbl.gov Wengyik Yeong yeongw@psi.com 7