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