CURRENT_MEETING_REPORT_
Reported by Greg Vaudreuil/CNRI
822EXT Minutes
Agenda
o Review of Implementations.
o Review of the Message Format Document.
o Type/ Subtype Clarifications.
o Resolution of the Encapsulated Message Format.
o State and Status of the Mnemonic Encoding and Character Set
Document.
The meeting began with a review of the work of implementors on the
Message format documents. Four attendees had implemented from the
document, with at least two others not in attendance. Three of the
known implementations were mail readers and two were gateway products.
A review of the Message format document was begun. Due to the limited
time the Working Group had in face to face session, it was agreed to
only discuss those points which were substantive and potentially
controversial.
Issue 1: Character set designation in a new header line. There was
dissatisfaction with indicating the character set only as a subtype of
text. One implementor found it useful to have a character set is
non-text objects. A review of the reasons for putting character sets in
a sub-type resulted in no objections to moving this information into a
new header.
Issue 2: The character designation discussion opened up a issue
regarding the syntax of optional and required fields in the type
designation. An objection, with request for explanation, was made to
the split between the type and the subtype field. The original rational
for this hierarchy, to aid gateways and mail readers in ``doing the
right thing'' with unrecognized content-types is less compelling in
light of the realization that the content-type is little more than a
hint as to which transfer encoding should be used, and there are many
cases where selection of a transfer-encoding will result in a less
efficient choice than could be made. Other participants argued that the
type field offers a valuable help to mail readers which try to do
something with unrecognized subtypes. Resolution was reached with the
observation that the type/subtype notation could be interpreted by a
mail reader as a single level content-type. The proposed standard
version will use the two level hierarchy.
Issue 3: The syntax of type/subtype is not clean. Some subtypes have
mandatory fields, such as text, and others have an attribute pair
notation for options. Much of this notation is a holdover from the RFC
934 multi-part specification. The Working Group re-affirmed the
1
preference for simplicity and elegance over compatibility with that
previous specification. After discussion the following was proposed and
accepted overwhelmingly: required parameters for a type or subtype
should be included as part of that content-type header line, and
optional parameters should be put in a new header line per option. It
was noted that several options may be used by many body-types and so
there is a reduction of complexity. Among the new optional parameters
suggested were content-filename and content-conversion. Other fields
were left up to the document editors to define as needed to clean up the
type/subtype syntax.
After this warmup the Working Group moved on to the issue of nested
transfer encodings. After some initial implementation experience, it
has become clear that allowing arbitrary nested body parts each with a
transfer encoding, causes a significant increase in the complexity of
mail readers. No one disagreed that nested encodings are possible on
almost all know platforms. People realized that some of this complexity
could be pushed off onto gateways, but after exchanging sendmail horror
stories for 30 minutes, it became clear that having gateways mung
messages was really ``sickening'' to many in attendance.
In return for this complexity, two key advantages are realized. The
first is the ability to allow 8 bit text in the headers of messages,
provided the message is encoded as a whole a transfer encoding. Without
the ability to nest the encodings, including headers in this fashion
would only be possible for simple messages with no encoded body parts.
The second advantage is the ability to specify a simple encapsulation
for gateways between diverse transport environments as well as non-smtp
based environments. By allowing the encapsulation of a binary or 8bit
message without requiring part by part examination and conversion, the
need for a gateway to parse complex multi-part messages and understand
the content-types is significantly reduced.
After two hours of talking, a strawman poll was taken in which the group
was fairly evenly split between those interested in preserving the
nested encodings and those who did not. In the interest of making
progress with an issue that has defied consensus, the Chair proposed a
compromise position. Because the group could agreed that it is far
easier to drop the nested encodings in a future version than to add it
the following was stated.
POSITION: The Proposed Standard version of the message format document
will allow nested encodings. If in implementing this specification, it
is determined by the group that it is either technologically unfeasible
or excessively cumbersome, it will be dropped at the Draft Standard
stage.
Beginning the second session, the Working Group discussed the two
documents by Keld Simonson. The first of these documents describes many
character sets, both ISO standards and others that are of interest to
the Internet Community. Furthermore, this document defines naming
conventions for both the characters and character sets. This naming
functionality is not duplicated in any other registry, although it is
expected that a similar ISO registry will be set up at some time. This
2
document uniquely names the character sets intended to be used in the
Message Format document and other IETF work. With the addition of a
provision that future character sets will be registered with the IANA,
the Working Group endorsed it's publication as an informational
document.
The second of Simonsen's documents, the mnemonic encoding document was
discussed in terms of the message format document. This document uses
the character names in the character set document to define a readable
escape sequence for characters which cannot be represented in ASCII.
This has been proposed as an alternative to the use of a native
character set and transport encoding. The Working Group thought this
was a wonderful idea, and endorsed it's publication as an experimental
protocol. The Message Format document will reference this as a
mechanism for sending 8 bit text where it is known the receiver is only
capable of reading text on an ASCII or invariant 646 display.
The Working Group discussed the need to resolve the problem with the
growing anarchy in email error message, both in terms of the
interpretation of RFC822 headers for the designation of error
recipients, and the format of those messages. It was felt that this
work should be begun in two areas, a revision to RFC 822, to clarify
ambiguous sections, and defining a standard machine-parsable error
message using the message format standard. This effort began with a
call for ideas and strawman proposals on the Working Group. Due to lack
of time, this was not discussed further in this meeting.
Attendees
Philip Budne phil@shiva.com
Johnny Eriksson bygg@sunet.se
Erik Fair fair@apple.com
Ned Freed ned@innosoft.com
Karen Frisa karen.frisa@andrew.cmu.edu
Russ Hobby rdhobby@ucdavis.edu
P. Allen Jensen allen@audfax.audiofax.com
Neil Katin katin@eng.sun.com
Douglas Kerr dougk@mtxinu.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
Louis Mamakos louie@ni.umd.edu
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
Harri Salminen hks@funet.fi
Keld Simonsen keld.simonsen@dkuug.dk
Gregory Vaudreuil gvaudre@nri.reston.va.us
John Wobus jmwobus@suvm.acs.syr.edu
3