Please review and comment on these minutes of the two working session
in Atlanta. Attendees, please check the list at the end of the
minutes for accuracy, and send specific corrections to the minutes to
me.
I invite all non-attendees to comment on the decisions reached at the
working group. It is difficult to make progress and reach consensus
on a mailing list, so I would like to consider the agreements worked
out during these meeting to be the consensus of the working group. I'm
willing to re-consider the decisions reached if there are significant
technical arguments not raised in the working group session.
Greg Vaudreuil
Chairman, Internet Message Format Extensions Working Group.
---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ----
Minutes of the 822 Message Format Extensions Working Group
July 29th, July 30th
Agenda
-------
1) Review of Implementations
2) Review of the Message format document
3) Type/ Subtype clarifications
4) Resolution of the Encapsulated Message format
5) State and Status of the Mnemonic encoding and character set document.
MINUTES
--------
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 has 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
dis-satisfaction 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 with
regard 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 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 a 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
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. This complexity included the need to write re-entrant
decoding routines and the need to store multiple copies of a message
in various stages of un-encoding.
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.
A strawman poll was taken, and the group was fairly evenly split
between those interested in preserving the nested encodings and those
who did not. A compromise position was advanced and generally
accepted. The Proposed Standard will retain the use of nested
transport encodings. If this proves to be unworkable or unduly
burdensome, it will be dropped as the protocol advances to Draft
Standard. The group agreed that it is far easier to drop the nested
encodings in a future version than to add it.
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
a naming conventions for both the characters and character sets. This
naming functionality is not duplicated in any other registry, although
it is expected that an similar ISO registry will be set up at some
time. This 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 know the receiver is only
capable of reading text on a ASCII or invariant 646 display. This
document will have the content-type of TEXT/MNEMONIC.
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 header for the designation of error
recipients, and the format of those message. It was felt that this
work should be begun in two areas, a revision to RFC 822, to clarify
ambiguous sections, and to define 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(_at_)shiva(_dot_)com
Johnny Eriksson bygg(_at_)sunet(_dot_)se
Erik Fair fair(_at_)apple(_dot_)com
Ned Freed ned(_at_)innosoft(_dot_)com
Karen Frisa karen(_dot_)frisa(_at_)andrew(_dot_)cmu(_dot_)edu
Russ Hobby rdhobby(_at_)ucdavis(_dot_)edu
P. Allen Jensen allen(_at_)audfax(_dot_)audiofax(_dot_)com
Neil Katin katin(_at_)eng(_dot_)sun(_dot_)com
Douglas Kerr dougk(_at_)mtxinu(_dot_)com
Darren Kinley kinley(_at_)crim(_dot_)ca
Jim Knowles jknowles(_at_)trident(_dot_)arc(_dot_)nasa(_dot_)gov
Vincent Lau vincent(_dot_)lau(_at_)eng(_dot_)sun(_dot_)com
Eliot Lear lear(_at_)net(_dot_)bio(_dot_)net
Jack Liu liu(_at_)koala(_dot_)enet(_dot_)dec(_dot_)com
Joseph Malcom dhylton(_at_)umd5(_dot_)umd(_dot_)edu
Louis Mamakos louie(_at_)ni(_dot_)umd(_dot_)edu
Leo McLaughlin ljm(_at_)wco(_dot_)ftp(_dot_)com
Keith Moore moore(_at_)cs(_dot_)utk(_dot_)edu
Michael Patton map(_at_)lcs(_dot_)mit(_dot_)edu
Jan Michael Rynning jmr(_at_)nada(_dot_)kth(_dot_)se
Harri Salminen hks(_at_)funet(_dot_)fi
Keld Simonsen keld(_dot_)simonsen(_at_)dkuug(_dot_)dk
Gregory Vaudreuil gvaudre(_at_)nri(_dot_)reston(_dot_)va(_dot_)us
John Wobus jmwobus(_at_)suvm(_dot_)acs(_dot_)syr(_dot_)edu