CURRENT_MEETING_REPORT_ Reported by John Klensin/United Nations University Minutes of the Mime Content BOF (MIMECONT) Because the following reviews are informal, there are not, in general, topic-specific mailing lists. However, the ``822ext'' list, available for MIME implementation issues, is the generic location for discussions of these types until topic-specific lists are spun off. General discussion: ietf-822@dimacs.rutgers.edu To subscribe: ietf-822-request@dimacs.rutgers.edu Background The MIME RFC (RFC 1521) specifies that anyone can register a content subtype under one of the major types simply by supplying a name and specification to IANA. However, there are cases where something is important enough to justify special review or when there appears to be an opportunity to draw competing proposals together and avoid the interoperability problems that would otherwise arise from differently profiled MIME applications. Rather than charter a working group for each topic, or create a standing working group that would review all such proposals (but probably have expertise specific to few of them), the Applications Area Directors have established an ad hoc review mechanism by which interested people can discuss the proposals and recommend to the area directors what, if any, further action should be taken. Six of these reviews occurred during this IETF. In several cases, the fact of scheduling the reviews and asking people to be prepared to present and discuss their proposals produced significant convergence, and the reviews were devoted to overviews and discussion of the new proposals that were emerging from that process. While the reviews appeared together in the agenda, and are consolidated in these minutes, it is important to understand that they are independent events and activities. Full SGML Over MIME and SGML Introduction Current document: o draft-levinson-sgml-00.txt Supplemental tutorial on SGML: o SGML Tutorial that appears as Part 1 of `Guidelines for Electronic Text Encoding and Interchange,' draft version 2 of document TEI P2 from the Text Encoding Initiative (TEI), edited by C. M. Sperberg-McQueen and Lou Burnard This review dealt with moving general SGML document files over MIME as distinguished from specially-profiled files that use SGML syntax and concepts (see the review on ``Structured Information and Personal Contact Information''). SGML was defined and its important characteristics identified. The group discussed the relationship between SGML external references and various existing, and proposed, Internet mechanisms including MIME external bodies and Content-IDs and the various URIs. Another issue was the SGML, like Postscript permits embedding executable structures (normally used to interpret graphics) and raw device commands that could create significant security risks. Since these are implementation- and site-dependent, the group concluded that it would be sensible to significantly restrict their use. There was also some consensus that the present document should be modified to utilize more general mechanisms for aggregating files within a MIME message, rather than inventing its own. This would leverage existing mechanisms for cross-references, external documents, and so on. Conclusion: No new working group is needed, at least at present. Discussion will continue on the 822 list. Ed Levinson will reissue the document with changes suggested in this session and additional discussions. MIME Multipart Structuring: Header-Sets and References Current documents: o draft-crocker-headerset-00.txt, .ps o draft-moore-mime-reference-00.txt Major consolidation and revision pending, see below. Many people have observed that many different multipart types -- beyond the ``mixed,'' ``alternative,'' ``digest,'' and ``parallel'' constructions specified in RFC 1521 -- are being specified for MIME. Many of these have most of their features in common, and a generic strategy would ease implementations, simplify design of future ones, and possibly reduce burdens on the registration process. Preparation for this review resulted in the combination of several alternatives into a new proposal, which has not yet been written up. A new proposal for multipart ``families'' is being prepared to define multipart as a general facility and provide guidance for handling aggregate objects. One important aspect of this work will be to specify how gateways to non-MIME environments should behave when these types are encountered. Conclusion: The headerset proposal is to be dropped. The multipart/alternative one will be dropped until and unless applications appear that actually require that level of generality and complexity. The new ``families'' proposal will be written up and discussed, then we will review what to do with it, since it is likely to be rather more a set of guidelines than an actual protocol specification. Structured Information and Personal Contact Information Current documents: o draft-crocker-stif-00.txt, .ps o draft-crocker-pci-00.txt, .ps o draft-adie-shave-00.txt, .ps o draft-adie-spci-00.txt, .ps o draft-vaudreuil-mime-sig-00.txt Many situations need structured attribute (or name)/value pairs within MIME messages and in other applications. Personal contact information, such as one might find on business cards or in a Rolodex are among the often-cited examples. Several people have independently tried to develop standard ways to represent this type of information. The two major proposals to do this are based on an extension of the RFC 822 header field model to accommodate nested structures (STIF) and a profile and set of definitions for using SGML to accomplish the same purpose (SHAVE). The 822-like format (at least without the extensions) is very familiar in the Internet community and feels quite natural. The SGML one feels natural to communities that have been using SGML and provides solutions to problems that still must be worked out with STIF, but SGML is not familiar to most of the IETF community and looks foreign and complex to a major subset of it. STIF is certainly easier to read for simple cases; but SHAVE might be easier in very complex ones. The familiarity with STIF-like arrangements, the installed base of data embedded in SGML formats, and the availability of a formal, executable definition against which validity can be determined, are all important considerations. It is important to note that SHAVE, unlike the general SGML model of the ``Full SGML Over MIME and SGML Introduction'' review, does not contemplate sending SGML Document Type Definitions (DTDs) around: at most one DTD would be defined per application, and processing the application would just imply applying it. This is similar to having a definition of a set of fields for use with STIF. STIF will not be registered as a content subtype. It is really a framework for constructing such subtypes. SHAVE could go either way, either as such a framework, or in a model that might use, e.g., content-type: text/SHAVE; dtd=SPCI Conclusion: Discussions will continue using the 822ext mailing list. It is not clear whether a separate signature subtype is needed or desirable, or whether signatures should just be handled as a special case of personal contact information under either the STIF or SHAVE models. Formation of a working group in this area is likely. Mail Delivery Reports and Notifications Current documents: o draft-moore-mime-delivery-00.txt o draft-moore-smtp-drpt-00.txt o draft-vaudreuil-mime-delivery-00.txt There have been several proposals for specific formats for automatically-generated reports about mail delivery or non-delivery. Getting such notices require a model for requesting them that probably must be handled as an SMTP extension, but a standardized format for sending them would greatly facilitate automated processing and building of intelligent user agents. The two report format proposals differ in level of generality and the problems addressed. All of the problems appear to be important, and a new proposal is needed that would address them. Conclusion: These reports, and the request mechanism, must be on the standards track to be useful. A working group is needed that will focus on both the report formats and the needed SMTP extensions, probably in that order. Keith Moore and Greg Vaudreuil will start a mailing list, announce it to the 822ext list, and begin to develop a working group charter. Specification of Presentation Direction for Text/Plain and Languages Whose Natural Order is Not Left-to-Right Current document: o draft-nussbacher-mime-direction-01.txt The group reviewed a proposal for specifying the relationship between presentation order (e.g., on a screen) and characters in the data stream for languages whose characters were written other than left-to-right. The proposal was to handle this by adding an extra parameter to Content-type: text/plain; charset=xxx that would specify the ``directionality'' of the characters with keywords drawn from applicable ECMA and ISO standards. While there was some sense that this would have been the right thing to do had it be thought of earlier in MIME's development, the consensus of those present was that it was not possible to add a parameter to text/plain at this time: some implementations might ignore it, others might actually get into trouble. Two alternate suggestions were made: 1. Extend the character set names to include the directionality, e.g., Content-type: text/plain; charset=iso-8859-8-visual 2. Use a completely different text subtype, e.g., either: Content-type: text/directional; charset=iso-8859-9; direction=implicit or Content-type: text/plain-explicit; charset=iso-8859-9 Macintosh File Transmission With MIME Current documents: o draft-faltstrom-macmime1-00.txt o draft-faltstrom-macmime2-00.txt There have been discussions in various forums for a year or more about how to best send Macintosh files over MIME. The Internet-Drafts listed above represent consensus among most of the contenders. The group reviewed them and concluded that, while some tuning is still needed, the concepts are basically sound. The importance of these formats is such that they should be placed on the standards track. A new draft will be produced and reviewed via an extended Last Call. Attendees George Chang gkc@ctt.bellcore.com James Conklin jbc@bitnic.educom.edu David Crocker dcrocker@mordor.stanford.edu James Davin davin@thumper.bellcore.com Donald Eastlake dee@skidrow.lkg.dec.com Ed Ellesson ellesson@vnet.ibm.com Urs Eppenberger eppenberger@switch.ch Patrik Faltstrom paf@nada.kth.se Qin Fang qin_fang@unc.edu James Fielding jamesf@arl.army.mil Ned Freed ned@innosoft.com Tony Genovese genovese@es.net Shawn Gillam shawn@timonware.com Erik Huizer Erik.Huizer@SURFnet.nl Neil Katin katin@eng.sun.com John Klensin Klensin@infoods.unu.edu Edward Levinson elevinson@accurate.com Lars-Johan Liman liman@ebone.net Wayne McDilda wayne@dir.texas.gov Keith Moore moore@cs.utk.edu Robert Moskowitz 3858921@mcimail.com John Myers jgm+@cmu.edu Chris Newman chrisn+@cmu.edu Masataka Ohta mohta@cc.titech.ac.jp Henry Sinnreich hsinnreich@mcimail.com Simon Spero ses@unc.edu Rick Troth troth@rice.edu Gregory Vaudreuil gvaudre@cnri.reston.va.us