ietf-xml-mime
[Top] [All Lists]

Re: Starting the ietf-xml-mime mailing list

1999-04-04 20:33:27
Paul Hoffman / IMC wrote:
OK, we've got about 30 people who signed up for the list. I think the first 
order of business is for someone to say what is incorrect and/or lacking in 
RFC 2376.

Here it is.  I will also post my summary of the discussion at the xml-dev 
mailing list very soon.

Makoto
-------------------------------------------------------------
Needs more information in the MIME header! (DRAFT)

MURATA Makoto, Paul Hoffman, Frank Dawson, Jim Whitehead

1. Problem statement

We would like the MIME parser to be able to dispatch different sorts
of XML documents to different applications, such as specialized
programs that handle just one type of XML document.  Because MIME
parsers do not look inside the MIME parts, identifiying the sort of
documents must be done in the MIME headers.  However, neither text/xml
nor application/xml allow such information.

2. Possible solutions

Three approaches have been proposed.  They are (1) specialized media
types such as text/calendar, (2) a top-level media type xml and its
subtypes such as xml/calendar, and (3) a new parameter "externalid" of
text/xml and applcation/xml.

(1) Specialized mime types

For each specialized applications of XML, we introduce a new subtype.
It may introduce more parameters and might even have some added
security consideration.  This is the approach that has been assumed by
the authors of RFC2376.

Pros:

Each application will be documented by some RFC.

Cons: 

When the MIME parser does not know of such a subtype, the only
available fallback is text/plain or application/octet-stream.  That
is, the MIME parser cannot invoke generic XML parsers/viewers, but has
to display the document as a plain text file or save the document in a
file.

Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.

(2) New top-level media type xml and its subtypes

Pros:

Fallback to "xml/plain" allows the use of generic XML parsers/viewers.

We can also lift the line termination rule of the top-level media type
"text".

Cons:

It is extremely difficult to register a new top-level media type and
therefore can have long delays (practically, who wants to do this?).
The default behavior is probably not a good enough reason.

Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.

(3) A new parameter "externalid" for text/xml and application/xml

This parameter specifies the externalID from the DOCTYPE of the XML
document (if the DOCTYPE is present).  Examples would be:

Content-type: text/xml;
   externalid="http://www.foo.com/whizzy.dtd";
or
Content-type: application/xml; charset="utf-16be";
   externalid="-//IETF//DTD vCard v3.0//EN"

Pros:

This is probably the easiest solution which also provides XML-specific
fallback.

Requires no registration with a central authority.

Other parameters can be added in the future when we have new schemata
or when we find new usage patterns for DTDs. The definitions for those
parameters can define which sets of parameters can appear together.

Cons:

DTD's do not necessarily exist.  For example, RFD metadata do not have
DTD's.

The use of DTD's to choose applications might be an abuse of DTD's.
Moreover, some DTD's might be handled by many different programs on a
system, such as by a specialized processor and one or more XML
browsers.  On the other hand, some applications (such as XML browsers)
handle a variety of DTD's.

There will be new schemata that will probably overshadow DTD's, and
these schemata may not use externalIDs the same way they are used in
today's DTDs.

(4) Yet another parameter "optinfo" or "ADD-PARAM"

On top of (3), provide yet another parameter "optinfo" (list of name-value 
pairs) 
or "ADD-PARAM" (plain text) for additional information.

Pros:

Some applications of XML require even more appliction-specfic information so 
as to launch appropriate software tools.  For example, if iCalendar information 
is captured by an XML DTD, the text/xml or application/xml MIME header has 
to mimick "method", "component", and "optinfo" of text/icalendar.  (The 
latest internet draft for text/icalendar is available at:  
ftp://ftp.isi.edu/internet-drafts/draft-ietf-calsch-ical-12.txt)

If this parameter is not available, people will abuse the parameter 
"externalid" 
by providing different names for the same DTD so as to express more 
information.  
This parameter stops such abuse.

Cons:

The "optinfo" parameter makes it difficult for a simple MIME parser to know 
what to expect in the parameter.   The "ADD-PARAM" parameter does not have 
this problem, but does not have enough expressiveness.


Note: None of the above proposals handle non-monolithic XML documents very 
well, 
since different islands of non-monolithic XML documents belong to different 
namespaces and thus different schemata.  For example, the MIME parser cannot 
invoke vCard applications if the vCard is embeded by the namespace mechanism.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: murata(_at_)apsdc(_dot_)ksp(_dot_)fujixerox(_dot_)co(_dot_)jp