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