Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/93nov/mimecont-minutes-93nov.txt

Text File | 1994-02-16 | 12KB | 296 lines

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: [e-mail]
 To subscribe:       [e-mail]


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             [e-mail]
James Conklin            [e-mail]
David Crocker            [e-mail]
James Davin              [e-mail]
Donald Eastlake          [e-mail]
Ed Ellesson              [e-mail]
Urs Eppenberger          [e-mail]
Patrik Faltstrom         [e-mail]
Qin Fang                 [e-mail]
James Fielding           [e-mail]
Ned Freed                [e-mail]
Tony Genovese            [e-mail]
Shawn Gillam             [e-mail]
Erik Huizer              [e-mail]
Neil Katin               [e-mail]
John Klensin             [e-mail]
Edward Levinson          [e-mail]
Lars-Johan Liman         [e-mail]
Wayne McDilda            [e-mail]
Keith Moore              [e-mail]
Robert Moskowitz         [e-mail]
John Myers               [e-mail]
Chris Newman             [e-mail]
Masataka Ohta            [e-mail]
Henry Sinnreich          [e-mail]
Simon Spero              [e-mail]
Rick Troth               [e-mail]
Gregory Vaudreuil        [e-mail]