CURRENT_MEETING_REPORT_ Reported by Greg Vaudreuil/CNRI Minutes of the Internet Message Extensions Working Group (822ext) Agenda o Discuss and resolve outstanding issues in Quad-x o Discuss and complete the header character set proposal. Minutes 1. Resolve outstanding issues in Quad-X A list of outstanding issues was reviewed and amended. Note, the term Quad-x was coined for RFCXXXX at this meeting, and is used throughout these minutes. (a) Audio format The Working Group was presented with two proposals for the format of audio/basic. Both proposals were based on the NeXT audio formats, one had attributes in the content-type headers and the other had the attributes in the file header in the body. After discussion, the Working Group concluded that it had no basis for choosing a standard #extensible# audio format and left the work for a future group. The NeXT format was seen by many to be too machine dependent, and had too many options, even as profiled by Marshall Rose. A simple format was agreed to for audio/basic which has no options and is not extensible. This definition for audio basic was defined as u- law, 1-channel, 8 khz. The data in the bodypart is straight u-law. (b) Message integrity check The Working Group expressed a strong need to define a message integrity check for message bodies. This was felt to be more general than would be available be adding a checksum to the base 64 encoding. No clear specification was available at this meeting. In the interests of making forward progress, the Working Group agreed that not having a MIC was not a show stopper, and if a solid proposal is ready, and can be approved by the list by December 16th, it would be included in the document. ACTION: Ned Freed and Jim Galvin -- Write a MIC proposal to 1 include the preferred MIC as suggested by the SAAG. (c) Multipart/Alternative Multipart alternative was enthusiastically endorsed as a transition mechanism to encourage the sending richer formats than may otherwise be used. By allowing a sender to send both a richly formatted document and include in a systematic way a simpler version, one which may be ``cat'ed'' to the screen, concern for the lowest common denominator will not have to be a restriction on the use of new features. (d) Character set issues The Working Group specified the definition of a character set for the purposes of quad-x to be a unique mapping of a byte stream to glyphs, a mapping which does not require external profiling information. i. ISO 2022-jp ISO 2022 is not strictly speaking a character set. It is a switching mechanism which requires an external profile to be useful, The Japanese have defined such a profile, and that profile will be documented and considered a character set for the purposes of Quad-x. ii. Mnemonic Keld Simonsen's mnemonic proposal as currently written requires the external specification of a character set and an escape character. As such, it does not fit the general requirements of a character set. A lunch sub-group defined a profile for mnemonic, with a lead in character of ``&'' (ascii 38) and ascii as the default character set. With the profile, the Working Group accepted mnemonic as a acceptable character set for Quad-x. (e) Application specifications The Working Group agreed upon several criterion for the specification of new application subtypes to be defined in the quad-x proposal. A new application must include in attribute-value pairs the profile, macro packages used, and any external pre-processors needed to use the included data. The security implications of using the particular applications data without authentication must also be discussed. i. PostScript Adobe has defined Postscript in such a way that it does not 2 require profiling information. A security considerations section was written by Ned Freed, essentially pointing out the nature of the risk associated with file operations, and recommending that they be disabled. Macintosh postscript files, which require laserprep header, as well as other postscript files generated by programs such as FrameMaker which call external libraries, must be sent with all such libraries prepended the mailed postscript to avoid the need to externally specify profiling information. ii. .nroff and TeX No person in the Working Group felt comfortable writing a complete profile for the use of either TeX or .nroff. The specification of these popular applications was left as a future effort. (f) Alphabet for boundary markers The current alphabet for boundary markers makes it difficult to construct markers which are compatible with RFC934 and existing digesting software. The addition of space as a valid character would satisfy this need. Further discussion resulted in the adoption of a more general alphabet, to include the invariant set of characters defined for the use of Base-64 to be used in boundary markers. Trailing spaces are not permitted. When spaces are used in a marker, the entire marker will have to be quoted in the header. (g) Binary type definition An unscheduled discussion on the need for the Binary type was held. With the clarification of the Applications type, and the difficulty of specifying exactly what initial content-types Binary should have, the Working Group without objection decided to drop it in favor of Application/Raw. This was a natural progression from the realignment of content-types in terms of system resources begun before the Atlanta meeting. Application and Binary both require the ability to handle arbitrary Binary data, and require external programs to use the information. (h) Application/External-Reference External Reference was seen by the Working Group to be a very useful feature, but as inadequately defined in Quad-x. The current syntax provides no mechanism for multiple simultaneous retrieval mechanisms, the specification of syntax for mail-servers, or prioritizing the retrieval order. The use of specific application/ftp and application/NFS when used with multi-part/alternative seems to be a reasonable approach, and 3 was to be written up Borenstein. As with the MIC, this absence of this feature was not seen to be a show-stopper. A new proposal will be submitted to the mailing list and if acceptable will be included in the document. ACTION: Nathaniel Borenstine -- Write up and submit to the mailing list a new proposal for application/external reference. (i) Use of defaults The current quad-x document specifies defaults for only selected content-types. In the case where defaults are not specified, and when the specified default may cease to be useful, possible ambiguity results. A strong view expressed before this meeting by Dave Crocker was supported by most attendees that defaults should be prohibited and that the subtype should always be specified. For broken mail which is send with incomplete content-types, behavior of the reader is left up to the implementor and user. It was felt that because the message was already ``broken'' any uniform assumption could not be reliable. (j) Portable End-Of-Line markers in base 64 The Working Group deleted end of line markers in Base 64, leaving it to the specific content-type to define the semantics of end of record. This decision has the advantage of restoring symmetry and transport independence between Base 64 and Quoted-Printable (k) Compression Compression was raised in the context of the Binary content type. Participants have expressed a desire, and the pragmatic realization that the use of ``compressed, uuencoded, tar'' files will continue to be sent and need to be indicated in the message. The Working Group previously stated it's preferences and rational for not supporting uuencode, but has never clearly expressed it's position on compress. The issue was tabled pending a proposal to be sent to the mailing list. Again, if the proposal is acceptable it will be included, and it's absence was not a show-stopper. ACTION: Neil Katkin -- Draft a proposal for the use of the compress algorithm in the Quad-X proposal. i. Internal reference in richtext 4 A proposal was made at this meeting to expand the richtext definition by including an internal-reference token. It was envisioned that this token would allow the insertion of objects in other parts of the message into the richtext stream. While many people supported this idea, no concrete proposal was submitted. If a proposal is approved by the mailing list, it will be included in the document. ACTION: Harri Salminen -- Draft a proposal for Internal reference in the richtext content subtype. Timetable for completion With the conclusion of the meeting, five issues were left open. A new version of Quad-x, along with the proposals for the open issues are due on December 6th. A new Internet Draft is expected at that time. The final comment period will end with the posting of a final version of Quad-x in the first week of January when the Working Group will submit the document to the IESG for Proposed Standard Status. 2. Header character set proposal The Working Group began a review of the proposal submitted by Keith Moore to include character set identification and encoding information in the headers of a document. The discussion was unstructured resulted in a productive stream of consiousness review. The Working Group approved of the general approach and with the changes discussed, approved the proposal. Below are the main issues discussed and their resolution. ED NOTE: Please help me reconstruct this discussion and submit text for these minutes! (a) Multiple encoded words The Working Group felt that it should be acceptable to use multiple encoded words. Furthermore, the Working Group agreed that the length of encoded words should not be limited by this document, but rather by implementors of software in consideration of the pragmatic guidelines in the Quad-x document. (b) Character set names The Working Group committed to alligning the character set names between the header document, Quad-x and Simonsen's charset document. The use of the numeric identify was dropped, both as a result of allowing longer lines by specifying multiple encoded words, and out of consideration in making the encoded word more user-readable with old software. 5 (c) Use of Spaces in encoded words Keith? Megan, If I do not send you text for this section, just delete it. Timetable for completion This document will be alligned with Quad-x, and a new version will be submitted to the Internet Drafts directory by December 6th. At that time, the Working Group may decide to combine the two documents, or progress them jointly as a single standard. In any event, the Working Group committed to the submission of the header document and Quad-x as a bound set. Attendees Harald Alvestrand herald.alvestrand@delab.sintef.no Mary Artibee artibee@sgi.com Nathaniel Borenstein nsb@thumper.bellcore.com Ronald Broersma ron@nosc.mil Cyrus Chow cchow@ames.arc.nasa.gov James Conklin conklin@bitnic.educom.edu Robert Cooney cooney@wnyose.nctsw.navy.mil Mark Crispin mrc@cac.washington.edu Erik Fair fair@apple.com Ned Freed ned@innosoft.com James Galvin galvin@tis.com Jisoo Geiter geiter@gateway.mitre.org Russ Hobby rdhobby@ucdavis.edu William Jackson jackson@manta.nosc.mil Borka Jerman-Blazic jerman-blazic@ijs.ac.mail.yu William Jolitz william@okeeffe.cs.berkeley.edu Neil Katin katin@eng.sun.com Tom Kessler kessler@sun.com Jim Knowles jknowles@trident.arc.nasa.gov Vincent Lau vincent.lau@eng.sun.com Eliot Lear lear@sgi.com Gordon Lee gordon@ftp.com Jack Liu liu@koala.enet.dec.com Paul Milazzo milazzo@bbn.com Keith Moore moore@cs.utk.edu Mark Needleman mhn@stubbs.ucop.edu Daniel Newman dan@innosoft.com Michael Patton map@lcs.mit.edu Harri Salminen hks@funet.fi Keld Simonsen keld@dkuug.dk Gregory Vaudreuil gvaudre@nri.reston.va.us 6