Larry, I find the first paragraph confusing in respect to certain XML
datatypes, such as application/beep+xml. This kind of content is almost
always expected to be found within a BEEP transaction. However, it does
have meaning in other contexts. If found in the wild, the MIME label
would at least let you know that you're looking at part of a beep
transaction, and may be useful for analysis, archiving, or evaluating
profiles. In particular (as specified in Section 6.4 of RFC 3080) there
are two additional restrictions made on this kind of content beyond
regular XML rules.
You seem to favor that there should only be MIME types for discrete
content that is regularly handled over multiple transports, such as
image/svg+xml or application/calendar+xml. However, a MIME type that is
registered but not used does no harm that I can see. So, I would place
the bias in the other direction, that new datatypes (including protocol
fragments) SHOULD be assigned a MIME type unless they have no meaning
outside their original context.
In particular, I think the emphasis of this sentence is backwards: "In
cases where the choice of encoding of data may be limited to using a
specific XML structure, the use of MIME labeling itself should be
avoided if possible." It also repeats the sentiment of the previous
paragraph. Finally, "never be recommended" at the end is much more
clear as "should not be used", since this document is the one doing the
recommending.
CURRENT DRAFT (section 4.11 of
<http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guideline
s-03.txt>) says:
o XML media types. Some protocols have protocol elements that are
MIME bodies, and allow MIME labeling. In cases where a MIME label
is used to identify a protocol element the MIME labeling policies
defined in RFC 3023 [5] should be followed and an XML declaration
should be present.
Consistent with RFC 3023, protocol elements should be exchanged
using the "application/xml" media type instead of the "text/xml"
media type. However, as discussed in RFC 3023, "application/xml"
may not be appropriate in all cases, and a new media type may be
needed; if so, the new media type should be registered with the
IANA.
LARRY'S SUGGESTION:
Using MIME to label XML content applies where XML entities are expected
to be stand-alone, largely interpreted without reference to the context
in which they appear. By contrast a piece of XML in a protocol element
is often intimately bound to the protocol context in which it appears,
and in particular might be directly derived from/input to protocol
state-machine implementations, with consequently limited scope for
interpretation.
This document makes the following recommendations:
In cases where the choice of encoding of data may be limited to using a
specific XML structure, the use of MIME labeling itself should be
avoided if possible. If MIME labeling is needed, then the advice of RFC
3023 applies. In particular, if the XML represents a new language or
document type, a new MIME media type should be registered, for the
reasons in RFC 3023 sections 7 and A.1. In situations where XML is used
to encode generic structured data (e.g., a document-oriented application
that involves combining XML with a stylesheet), "application/xml" may be
used. Because of issues involving display behavior and default charsets,
"text/xml" should never be recommended.
DAN'S SUGGESTION:
XML media types. A piece of XML in a protocol element is sometimes
intrinsically bound to the protocol context in which it appears, and in
particular might be directly derived from and/or input to protocol
state-machine implementations. In cases where the XML content has no
relevant meaning outside it's original protocol context, there is no
reason to register a MIME type. When it is possible that XML content
can be interpreted outside of its original context (such as when that
XML content is being stored in a filesystem or tunneled over another
protocol), then a MIME type should be registered to specify the specific
format for the data and to provide a hint as to how it might be
processed.
If MIME labeling is needed, then the advice of RFC 3023 applies. In
particular, if the XML represents a new language or document type, a new
MIME media type should be registered, for the reasons in RFC 3023
sections 7 and A.1. In situations where XML is used to encode generic
structured data (e.g., a document-oriented application that involves
combining XML with a stylesheet), "application/xml" may be used. Because
of issues involving display behavior and default charsets, "text/xml"
should not be used.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>
Essays announced on <mailto:dankohn-subscribe(_at_)yahoogroups(_dot_)com>
-----Original Message-----
From: Larry Masinter [mailto:LMM(_at_)acm(_dot_)org]
Sent: Thursday, May 30, 2002 20:20
To: ietf-xml-use(_at_)imc(_dot_)org
Subject: dangers of application/xml
Here's an attempted rewrite
Using MIME to label XML content applies where XML entities are
expected
to be stand-alone, largely interpreted without reference to the
context
in which they appear. By contrast a piece
of XML in a protocol element is often intimately bound to the protocol
context in which it appears, and in particular might be directly
derived
from/input to protocol state-machine implementations, with
consequently
limited scope for interpretation.
This document makes the following recommendations:
In cases where the choice of encoding of data may be limited to
using a specific XML structure, the use of MIME labeling itself
should be avoided if possible. If MIME labeling is needed, then
the advice of RFC 3023 applies. In particular, if the XML represents
a new language or document type, a new MIME media type should be
registered,
for the reasons in RFC 3023 sections 7 and A.1. In situations where
XML is used to encode generic structured data (e.g., a
document-oriented
application that involves combining XML with a stylesheet),
"application/xml"
may be used. Because of issues involving display behavior and
default charsets, "text/xml" should never be recommended.