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