Network Working Group M. Murata
Internet-Draft Fuji Xerox Information Systems
Expires: May 8, 2000 S. St.Laurent
November 8, 1999
XML Media Types
draft-murata-xml-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 8, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document proposes three new media subtypes, text/xml,
application/xml, and application/xml-dtd, for use in exchanging
network entities which are conforming Extensible Markup Language
(XML). This document also proposes a convention for naming media
subtypes outside of these three subtypes when those subtypes
represent XML entities. XML MIME entities are currently exchanged
via the HyperText Transfer Protocol on the World Wide Web, are an
integral part of the WebDAV protocol for remote web authoring, and
are expected to have utility in many domains.
Murata & St.Laurent Expires May 8, 2000 [Page 1]
Internet-Draft XML Media Types November 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7
3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9
3.3 Application/xml-dtd Registration . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . 13
5. The Byte Order Mark (BOM) and Conversions to/from UTF-16 . . 15
6. A naming convention for XML-based media types . . . . . . . 16
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 18
7.2 text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 18
7.3 text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 18
7.4 text/xml with Omitted Charset . . . . . . . . . . . . . . . 19
7.5 application/xml with UTF-16 Charset . . . . . . . . . . . . 19
7.6 application/xml with ISO-2022-KR Charset . . . . . . . . . . 19
7.7 application/xml with Omitted Charset and UTF-16 XML MIME
entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8 application/xml with Omitted Charset and UTF-8 Entity . . . 20
7.9 application/xml with Omitted Charset and Internal Encoding
Declaration . . . . . . . . . . . . . . . . . . . . . . . . 20
7.10 application/xml-dtd . . . . . . . . . . . . . . . . . . . . 21
7.11 application/mathml-xml . . . . . . . . . . . . . . . . . . . 21
7.12 application/xsl-xml . . . . . . . . . . . . . . . . . . . . 21
7.13 application/rdf-xml . . . . . . . . . . . . . . . . . . . . 21
7.14 image/svg-xml . . . . . . . . . . . . . . . . . . . . . . . 22
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
A. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . 27
Murata & St.Laurent Expires May 8, 2000 [Page 2]
Internet-Draft XML Media Types November 1999
1. Introduction
The World Wide Web Consortium (W3C)[16]has issued Extensible Markup
Language (XML), version 1[3]. To enable the exchange of XML network
entities, this document proposes three new media types, text/xml,
application/xml, and application/xml-dtd as well as a naming
convention for identifying XML-based MIME media types.
XML entities are currently exchanged on the World Wide Web, and XML
is also used for property values and parameter marshalling by the
WebDAV protocol for remote web authoring. Thus, there is a need for
a media type to properly label the exchange of XML network entities.
(Note that, as sometimes happens between two communities, both MIME
and XML have defined the term entity, with different meanings.)
Although XML is a subset of the Standard Generalized Markup Language
(SGML) [ISO-8897], and currently is assigned the media types
text/sgml and application/sgml, there are several reasons why use of
text/sgml or application/sgml to label XML is inappropriate. First,
there exist many applications which can process XML, but which
cannot process SGML, due to SGML's larger feature set. Second, SGML
applications cannot always process XML entities, because XML uses
features of recent technical corrigenda to SGML. Third, the
definition of text/sgml and application/sgml [RFC-1874] includes
parameters for SGML bit combination transformation format (SGML-
bctf), and SGML boot attribute (SGML-boot). Since XML does not use
these parameters, it would be ambiguous if such parameters were
given for an XML MIME entity. For these reasons, the best approach
for labeling XML network entities is to provide new media types for
XML.
Since XML is an integral part of the WebDAV Distributed Authoring
Protocol, and since World Wide Web Consortium Recommendations have
conventionally been assigned IETF tree media types, and since
similar media types (HTML, SGML) have been assigned IETF tree media
types, the XML media types also belong in the IETF media types tree.
Similarly, XML will be used as a foundation for other media types,
including types in every branch of the IETF media types tree. To
facilitate the processing of such types, media types based on XML,
but which are not identified using text/xml or application/xml,
should be named using a suffix of -xml. This will allow XML-based
tools - browsers, editors, search engines, and other processors - to
work with all XML-based media types.
1.1 Editor's Notes
This section will be removed by the final draft of this document.
It provides a listing of all the Editor's Notes appearing in this
Murata & St.Laurent Expires May 8, 2000 [Page 3]
Internet-Draft XML Media Types November 1999
document. Notes still appear in the document in the section noted.
3.1 - [Editor's note: should we say anything about dispatching
based on namespace URIs in this document?]
3.2 - [Editor's note: should we say anything about dispatching
based on namespace URIs in this document?]
4. - [Editor's note: some applications of XML may open up new
security considerations. This issue needs further consideration.]
6. - [Editor's note: the use of non-XPointer fragment identifiers
by XML vocabularies like SVG and SMIL requires further
discussion.]
Murata & St.Laurent Expires May 8, 2000 [Page 4]
Internet-Draft XML Media Types November 1999
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119][6].
Murata & St.Laurent Expires May 8, 2000 [Page 5]
Internet-Draft XML Media Types November 1999
3. XML Media Types
This document introduces three new media types for XML MIME
entities, text/xml, application/xml, and application/xml-dtd.
Registration information for these media types are described in the
sections below.
Within the XML specification, XML MIME entities can be classified
into four types. In the XML terminology, they are called "document
entities", "external DTD subsets", "external parsed entities", and
"external parameter entities". The media types text/xml and
application/xml can be used for "document entities" or "external
parsed entities". For backward compatibility, they can also be used
for "external DTD subsets" or "external parameter entities". The
media type application/xml-dtd can be used for "external DTD
subsets" or "external parameter entities". XML also has unparsed
entities, internal parsed entities, and internal parameter entities,
but they are not XML MIME entities.
If an XML document or external parsed entity is readable by casual
users, text/xml is preferable to application/xml. MIME user agents
(and web user agents) that do not have explicit support for text/xml
will treat it as text/plain, for example, by displaying the XML
entity as plain text. Application/xml is preferable when the XML
MIME entity is unreadable by casual users.
The top-level media type "text" has some restrictions on MIME
entities and they are described in [RFC-2045] and [RFC-2046]. In
particular, UTF-16, UCS-4, and UTF-32 are not allowed (except for
HTTP, which uses a MIME-like mechanism). Thus, if an XML document
or external parsed entity is encoded in such character encoding
schemes, it cannot be labled as text/xml (except for HTTP).
Text/xml and application/xml behave differently when the charset
parameter is not explicitly specified. If the default charset
(i.e., US-ASCII) for text/xml is inconvenient for some reason (e.g.,
bad WWW servers), application/xml provides an alternative (see
"Optional parameters" of "3.2 Application/xml Registration").
XML provides a general framework for defining sequences of
structured data. In some cases, it may be desirable to define new
media types which use XML but define a specific application of XML,
perhaps due to domain-specific security considerations or runtime
information. This document does not prohibit future media types
dedicated to such XML applications. However, developers of such
media types are recommended to use this document as a basis. In
particular, the charset parameter should be used in the same manner.
Murata & St.Laurent Expires May 8, 2000 [Page 6]
Internet-Draft XML Media Types November 1999
3.1 Text/xml Registration
MIME media type name: text
MIME subtype name: xml
Mandatory parameters: none
Optional parameters: charset
Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since this information can be
used by XML processors to determine authoritatively the character
encoding of the XML MIME entity. The charset parameter can also be
used to provide protocol-specific operations, such as charset-based
content negotiation in HTTP. "UTF-8" [RFC-2279] is the recommended
value, representing the UTF-8 charset. UTF-8 is supported by all
conforming XML processors [REC-XML].
If the XML MIME entity is transmitted via HTTP, which uses a
MIME-like mechanism that is exempt from the restrictions on the text
top- level type (see section 19.4.1 of HTTP 1.1 [RFC-2068]),
"UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646])
is also recommended. UTF-16 is supported by all conforming XML
processors [REC-XML]. Since the handling of CR, LF and NUL for text
types in most MIME applications would cause undesired
transformations of individual octets in UTF-16 multi-octet
characters, gateways from HTTP to these MIME applications MUST
transform the XML MIME entity from a text/xml; charset="utf-16" to
application/xml; charset="utf-16".
Conformant with [RFC-2046], if a text/xml entity is received with
the charset parameter omitted, MIME processors and XML processors
MUST use the default charset value of "us-ascii". In cases where
the XML MIME entity is transmitted via HTTP, the default charset
value is still "us-ascii".
Since the charset parameter is authoritative, the charset is not
always declared within an XML encoding declaration. Thus, special
care is needed when the recipient strips the MIME header and
provides persistent storage of the received XML MIME entity (e.g.,
in a file system). Unless the charset is UTF-8 or UTF-16, the
recipient SHOULD also persistently store information about the
charset, perhaps by embedding a correct XML encoding declaration
within the XML MIME entity.
Encoding considerations:
This media type MAY be encoded as appropriate for the charset and
Murata & St.Laurent Expires May 8, 2000 [Page 7]
Internet-Draft XML Media Types November 1999
the capabilities of the underlying MIME transport. For 7-bit
transports, data in both UTF-8 and UTF-16 is encoded in quoted-
printable or base64. For 8-bit clean transport (e.g., ESMTP,
8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
encoded. For binary clean transports (e.g., HTTP), no content-
transfer-encoding is necessary.
Security considerations:
See section 4 below.
Interoperability considerations:
XML has proven to be interoperable across WebDAV clients and
servers, and for import and export from multiple XML authoring tools.
Published specification:
see [REC-XML]
Applications which use this media type:
XML is device-, platform-, and vendor-neutral and is supported by a
wide range of Web user agents, WebDAV clients and servers, as well
as XML authoring tools.
[Editor's note: should we say anything about dispatching based on
namespace URIs in this document?]
Additional information:
Magic number(s): none
Although no byte sequences can be counted on to always be present,
XML MIME entities in ASCII-compatible charsets (including UTF-8)
often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more
information, see Appendix F of [REC-XML].
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
Murata Makoto (Family Given) <murata.makoto@fujixerox.co.jp>
Simon St.Laurent <simonstl@simonstl.com>
Intended usage: COMMON
Murata & St.Laurent Expires May 8, 2000 [Page 8]
Internet-Draft XML Media Types November 1999
Author/Change controller:
The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
The W3C, and the W3C XML Core Working Group, have change control
over the XML specification.
3.2 Application/xml Registration
MIME media type name: application
MIME subtype name: xml
Mandatory parameters: none
Optional parameters: charset
Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since this information can be
used by XML processors to determine authoritatively the charset of
the XML MIME entity. The charset parameter can also be used to
provide protocol-specific operations, such as charset-based content
negotiation in HTTP.
"UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and
Amendment 1 of [ISO-10646]) are the recommended values, representing
the UTF-8 and UTF-16 charsets, respectively. These charsets are
preferred since they are supported by all conforming XML processors
[REC-XML].
If an application/xml entity is received where the charset parameter
is omitted, no information is being provided about the charset by
the MIME Content-Type header. Conforming XML processors MUST follow
the requirements in section 4.3.3 of [REC-XML] which directly
address this contingency. However, MIME processors which are not XML
processors should not assume a default charset if the charset
parameter is omitted from an application/xml entity.
Since the charset parameter is authoritative, the charset is not
always declared within an XML encoding declaration. Thus, special
care is needed when the recipient strips the MIME header and
provides persistent storage of the received XML MIME entity (e.g.,
Murata & St.Laurent Expires May 8, 2000 [Page 9]
Internet-Draft XML Media Types November 1999
in a file system). Unless the charset is UTF-8 or UTF-16, the
recipient SHOULD also persistently store information about the
charset, perhaps by embedding a correct XML encoding declaration
within the XML MIME entity.
Encoding considerations:
This media type MAY be encoded as appropriate for the charset and
the capabilities of the underlying MIME transport. For 7-bit
transports, data in both UTF-8 and UTF-16 is encoded in quoted-
printable or base64. For 8-bit clean transport (e.g., ESMTP,
8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
encoded. For binary clean transport (e.g., HTTP), no content-
transfer-encoding is necessary.
Security considerations:
See section 4 below.
Interoperability considerations:
XML has proven to be interoperable for import and export from
multiple XML authoring tools.
Published specification:
see [REC-XML]
Applications which use this media type:
XML is device-, platform-, and vendor-neutral and is supported by a
wide range of Web user agents and XML authoring tools.
[Editor's note: should we say anything about dispatching based on
namespace URIs in this document?]
Additional information:
Magic number(s): none
Although no byte sequences can be counted on to always be present,
XML MIME entities in ASCII-compatible charsets (including UTF-8)
often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in
UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D or
FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM) followed by
"<?xml"). For more information, see Annex F of [REC- XML].
File extension(s): .xml
Murata & St.Laurent Expires May 8, 2000 [Page 10]
Internet-Draft XML Media Types November 1999
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
Murata Makoto (Family Given) <murata.makoto@fujixerox.co.jp>
Simon St.Laurent <simonstl@simonstl.com>
Intended usage: COMMON
Author/Change controller:
The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
The W3C, and the W3C XML working group, has change control over the
XML specification.
3.3 Application/xml-dtd Registration
MIME media type name: application
MIME subtype name: xml-dtd
Mandatory parameters: none
Optional parameters: charset
The charset parameter of application/xml-dtd is handled exactly the
same as that of application/xml.
Encoding considerations:
The encoding considerations of application/xml apply.
Security considerations:
See section 4 below.
Interoperability considerations:
XML DTDs has proven to be interoperable by DTD authoring tools and
XML WWW browsers among others.
Murata & St.Laurent Expires May 8, 2000 [Page 11]
Internet-Draft XML Media Types November 1999
Published specification: see [REC-XML]
Applications which use this media type:
DTD authoring tools handle external DTD subsets as well as external
parameter entities. XML browsers may also access external DTD
subests and external parameter entities.
Additional information:
Magic number(s): none
Although no byte sequences can be counted on to always be present,
external DTD subsets and external parameter entities in
ASCII-compatible charsets (including UTF-8) often begin with
hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in UTF-16 often
begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D or FF FE 3C 00
3F 00 78 00 6D 00 (the Byte Order Mark (BOM) followed by "<?xml").
For more information, see Annex F of [REC-XML].
File extension(s): .dtd
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
Murata Makoto (Family Given) <murata.makoto@fujixerox.co.jp>
Simon St.Laurent <simonstl@simonstl.com>
Intended usage: COMMON
Author/Change controller:
The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
The W3C, and the W3C XML working group, has change control over the
XML specification.
Murata & St.Laurent Expires May 8, 2000 [Page 12]
Internet-Draft XML Media Types November 1999
4. Security Considerations
XML, as a subset of SGML, has the same security considerations as
specified in [RFC-1874]. [Editor's note: some applications of XML
may open up new security considerations. This issue needs further
consideration.]
To paraphrase section 3 of [RFC-1874], XML MIME entities contain
information to be parsed and processed by the recipient's XML
system. These entities may contain and such systems may permit
explicit system level commands to be executed while processing the
data. To the extent that an XML system will execute arbitrary
command strings, recipients of XML MIME entities may be at risk. In
general, it may be possible to specify commands that perform
unauthorized file operations or make changes to the display
processor's environment that affect subsequent operations.
Use of XML is expected to be varied, and widespread. XML is under
scrutiny by a wide range of communities for use as a common syntax
for community-specific metadata. For example, the Dublin Core group
is using XML for document metadata, and a new effort has begun which
is considering use of XML for medical information. Other groups
view XML as a mechanism for marshalling parameters for remote
procedure calls. More uses of XML will undoubtedly arise.
Security considerations will vary by domain of use. For example,
XML medical records will have much more stringent privacy and
security considerations than XML library metadata. Similarly, use of
XML as a parameter marshalling syntax necessitates a case by case
security review.
XML may also have some of the same security concerns as plain text.
Like plain text, XML can contain escape sequences which, when
displayed, have the potential to change the display processor
environment in ways that adversely affect subsequent operations.
Possible effects include, but are not limited to, locking the
keyboard, changing display parameters so subsequent displayed text
is unreadable, or even changing display parameters to deliberately
obscure or distort subsequent displayed material so that its meaning
is lost or altered. Display processors should either filter such
material from displayed text or else make sure to reset all
important settings after a given display operation is complete.
Some terminal devices have keys whose output, when pressed, can be
changed by sending the display processor a character sequence. If
this is possible the display of a text object containing such
character sequences could reprogram keys to perform some illicit or
dangerous action when the key is subsequently pressed by the user.
In some cases not only can keys be programmed, they can be triggered
Murata & St.Laurent Expires May 8, 2000 [Page 13]
Internet-Draft XML Media Types November 1999
remotely, making it possible for a text display operation to
directly perform some unwanted action. As such, the ability to
program keys should be blocked either by filtering or by disabling
the ability to program keys entirely.
Note that it is also possible to construct XML documents which make
use of what XML terms "entity references" (using the XML meaning of
the term "entity", which differs from the MIME definition of this
term), to construct repeated expansions of text. Recursive
expansions are prohibited [REC-XML] and XML processors are required
to detect them. However, even non-recursive expansions may cause
problems with the finite computing resources of computers, if they
are performed many times.
Murata & St.Laurent Expires May 8, 2000 [Page 14]
Internet-Draft XML Media Types November 1999
5. The Byte Order Mark (BOM) and Conversions to/from UTF-16
The XML Recommendation, in section 4.3.3, specifies that UTF-16 XML
MIME entities must begin with a byte order mark (BOM), which is the
ZERO WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or
0xFFFE, depending on endian). The XML Recommendation further states
that the BOM is an encoding signature, and is not part of either the
markup or the character data of the XML document.
Due to the BOM, applications which convert XML from the UTF-16
encoding to another encoding SHOULD strip the BOM before conversion.
Similarly, when converting from another encoding into UTF-16, the
BOM SHOULD be added after conversion is complete.
Murata & St.Laurent Expires May 8, 2000 [Page 15]
Internet-Draft XML Media Types November 1999
6. A naming convention for XML-based media types
This document proposes the use of a naming convention (a suffix of
'-xml') for identifying XML-based MIME media types, whatever their
particular contents may represent. This allows the use of generic
XML processors and technologies on a wide variety of different XML
document types at a minimum cost, using existing frameworks for
media type registration. The use of a suffix convention is intended
to avoid interference with the existing MIME type structures.
As XML development continues to develop, new XML document types are
appearing rapidly. Many of these XML document types would benefit
from the identification possibilities of a more specific MIME media
type than text/xml or application/xml can provide, and it is likely
that many new media types for XML-based document types will be
registered in the near and ongoing future.
While the benefits of specific MIME types for particular types of
XML documents are significant, all XML documents share common
structures and syntax that make possible common processing.
Some areas where 'generic' processing is useful include:
o Browsing - An XML browser can display any XML document with a
provided CSS [CSS] or XSL [XSL] style sheet, whatever the
vocabulary of that document.
o Editing - Any XML editor can read, modify, and save any XML
document.
o Fragment identification - XPointers [XPtr] can work with any XML
document, whatever vocabulary it uses and whether or not it uses
XPointer for its own fragment identification. [Editor's note: the
use of non-XPointer fragment identifiers by XML vocabularies like
SVG and SMIL requires further discussion.]
o Hypertext Linking - XLink [XLink] hypertext linking is designed
to connect any XML documents, regardless of vocabulary.
o Searching - Search engines, agents, and XML-oriented query tools
should be able to read XML documents and extract the content and
names of elements and attributes even if they are ignorant of the
particular vocabulary used for elements and attributes.
o Storage - XML-oriented storage systems, which keep XML documents
internally in a parsed form, should similarly be able to process,
store, and recreate any XML document.
When a new media type is introduced for an XML-based format, the
Murata & St.Laurent Expires May 8, 2000 [Page 16]
Internet-Draft XML Media Types November 1999
name of the media type should end with "-xml". This convention will
allow applications that can process XML generically to detect that
the MIME entity is supposed to be an XML document, verify this
assumption by invoking some XML processor, and then process the XML
document accordingly. Applications may match for types that
represent XML entities by comparing the subtype to the pattern
*/*-xml.
XML-generic processing is not always appropriate for XML-based media
types. For example, some such media types may require fragment
identifiers different from XPointer. By *not* following the naming
convention */*-xml, such media types can avoid XML-generic
processing.
The registration process for these media types is described in
[RFC-2048]. The registrar for the IETF tree will enforce this rule
for all XML-based media types created in the IETF tree. Registrars
for other trees should follow this convention in order to ensure
maximum interoperability of their XML-based documents. Similarly,
media subtypes that do not represent XML MIME entities should not be
allowed to register with a -xml suffix.
The suffix approach allows XML document types to be identified
within any subtree. The vendor subtree, for example, is likely to
include a large number of XML-based document types. By using a
suffix, rather than setting up a separate subtree, those types may
remain in the same location in the tree of MIME types that they
would have occupied had they not been based on XML.
The optional charset parameter may be used with media types
following these conventions as described in this document for
text/xml and application/xml. If an XML-based media type is under
the text top-level type, the charset parameter is authoritative and
the default value is "US-ASCII". If an XML-based media type is
under other top-level types, the charset parameter is authoritative
and there are no default values. MIME processors which are not XML
processors should not assume a default charset, while conforming XML
processors MUST follow the requirements in section 4.3.3 of [3].
The use of the charset parameter is STRONGLY RECOMMENDED, since this
information can be used by XML processors to determine
authoritatively the charset of the XML MIME entity.
Murata & St.Laurent Expires May 8, 2000 [Page 17]
Internet-Draft XML Media Types November 1999
7. Examples
The examples below give the value of the Content-type MIME header
and the XML declaration (which includes the encoding declaration)
inside the XML MIME entity. For UTF-16 examples, the Byte Order
Mark character is denoted as "{BOM}", and the XML declaration is
assumed to come at the beginning of the XML MIME entity, immediately
following the BOM. Note that other MIME headers may be present, and
the XML MIME entity may contain other data in addition to the XML
declaration; the examples focus on the Content-type header and the
encoding declaration for clarity.
7.1 text/xml with UTF-8 Charset
Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
This is the recommended charset value for use with text/xml. Since
the charset parameter is provided, MIME and XML processors must
treat the enclosed entity as UTF-8 encoded.
If sent using a 7-bit transport (e.g. SMTP), the XML entity must use
a content-transfer-encoding of either quoted-printable or base64.
For an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a
binary clean transport (e.g., HTTP) no content-transfer-encoding is
necessary.
7.2 text/xml with UTF-16 Charset
Content-type: text/xml; charset="utf-16"
{BOM}<?xml version='1.0' encoding='utf-16'?>
This is possible only when the XML MIME entity is transmitted via
HTTP, which uses a MIME-like mechanism and is a binary-clean
protocol, hence does not perform CR and LF transformations and
allows NUL octets. This differs from typical text MIME type
processing (see section 19.4.1 of HTTP 1.1 [RFC-2068] for details).
Since HTTP is binary clean, no content-transfer-encoding is
necessary.
7.3 text/xml with ISO-2022-KR Charset
Content-type: text/xml; charset="iso-2022-kr"
<?xml version="1.0" encoding='iso-2022-kr'?>
Murata & St.Laurent Expires May 8, 2000 [Page 18]
Internet-Draft XML Media Types November 1999
This example shows text/xml with a Korean charset (e.g., Hangul)
encoded following the specification in [RFC-1557]. Since the
charset parameter is provided, MIME and XML processors must treat
the enclosed entity as encoded per [RFC-1557].
Since ISO-2022-KR has been defined to use only 7 bits of data, no
content-transfer-encoding is necessary with any transport.
7.4 text/xml with Omitted Charset
Content-type: text/xml
{BOM}<?xml version="1.0" encoding="utf-16"?>
This example shows text/xml with the charset parameter omitted. In
this case, MIME and XML processors must assume the charset is "us-
ascii", the default charset value for text media types specified in
[RFC-2046]. The default of "us-ascii" holds even if the text/xml
entity is transported using HTTP.
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For
example, even if the contents of the XML MIME entity are UTF-16 or
UTF-8, or the XML MIME entity has an explicit encoding declaration,
XML and MIME processors must assume the charset is "us-ascii".
7.5 application/xml with UTF-16 Charset
Content-type: application/xml; charset="utf-16"
{BOM}<?xml version="1.0"?>
This is a recommended charset value for use with application/xml.
Since the charset parameter is provided, MIME and XML processors
must treat the enclosed entity as UTF-16 encoded.
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean
transport (e.g., ESMTP, 8BITMIME, or NNTP), the XML MIME entity must
be encoded in quoted-printable or base64. For a binary clean
transport (e.g., HTTP), no content-transfer-encoding is necessary.
7.6 application/xml with ISO-2022-KR Charset
Content-type: application/xml; charset="iso-2022-kr"
<?xml version="1.0" encoding="iso-2022-kr"?>
This example shows application/xml with a Korean charset (e.g.,
Hangul) encoded following the specification in [RFC-1557]. Since the
charset parameter is provided, MIME and XML processors must treat
Murata & St.Laurent Expires May 8, 2000 [Page 19]
Internet-Draft XML Media Types November 1999
the enclosed entity as encoded per [RFC-1557], independent of
whether the XML MIME entity has an internal encoding declaration
(this example does show such a declaration, which agrees with the
charset parameter).
Since ISO-2022-KR has been defined to use only 7 bits of data, no
content-transfer-encoding is necessary with any transport.
7.7 application/xml with Omitted Charset and UTF-16 XML MIME entity
Content-type: application/xml
{BOM}<?xml version='1.0'?>
For this example, the XML MIME entity begins with a BOM. Since the
charset has been omitted, a conforming XML processor follows the
requirements of [REC-XML], section 4.3.3. Specifically, the XML
processor reads the BOM, and thus knows deterministically that the
charset encoding is UTF-16.
An XML-unaware MIME processor should make no assumptions about the
charset of the XML MIME entity.
7.8 application/xml with Omitted Charset and UTF-8 Entity
Content-type: application/xml
<?xml version='1.0'?>
In this example, the charset parameter has been omitted, and there
is no BOM. Since there is no BOM, the XML processor follows the
requirements in section 4.3.3, and optionally applies the mechanism
described in appendix F (which is non-normative) of [REC-XML] to
determine the charset encoding of UTF-8. The XML entity does not
contain an encoding declaration, but since the encoding is UTF-8,
this is still a conforming XML MIME entity.
An XML-unaware MIME processor should make no assumptions about the
charset of the XML MIME entity.
7.9 application/xml with Omitted Charset and Internal Encoding
Declaration
Content-type: application/xml
<?xml version='1.0' encoding="ISO-10646-UCS-4"?>
In this example, the charset parameter has been omitted, and there
is no BOM. However, the XML MIME entity does have an encoding
Murata & St.Laurent Expires May 8, 2000 [Page 20]
Internet-Draft XML Media Types November 1999
declaration inside the XML MIME entity which specifies the entity's
charset. Following the requirements in section 4.3.3, and optionally
applying the mechanism described in appendix F (non-normative) of
[REC-XML], the </section> XML processor determines the charset
encoding of the XML MIME entity (in this example, UCS-4).
An XML-unaware MIME processor should make no assumptions about the
charset of the XML MIME entity.
7.10 application/xml-dtd
Content-type: application/xml-dtd; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
Charset "utf-8" is a recommended charset value for use with
application/xml-dtd. Since the charset parameter is provided, MIME
and XML processors must treat the enclosed entity as UTF-8 encoded.
7.11 application/mathml-xml
Content-type: application/mathml-xml
<?xml version="1.0" ?>
MathML documents are XML documents whose content describes
mathematical information, as described by the MathML recommendation
[MathML]. As a format based on XML, MathML documents should use the
-xml suffix convention in their MIME content-type identifier.
7.12 application/xsl-xml
Content-type: application/xsl-xml
<?xml version="1.0" ?>
Extensible Stylesheet Language (XSL) documents are XML documents
whose content describes stylesheets for other XML documents, as
described by the XSL recommendation [XSL]. As a format based on XML,
XSL documents should use the -xml suffix convention in their MIME
content-type identifier.
7.13 application/rdf-xml
Content-type: application/rdf-xml
<?xml version="1.0" ?>
RDF documents identified using this MIME type are XML documents
Murata & St.Laurent Expires May 8, 2000 [Page 21]
Internet-Draft XML Media Types November 1999
whose content describes mathematical information, as described by
the RDF recommendation [RDF]. RDF documents that use a format based
on XML should use the -xml suffix convention in their MIME
content-type identifier.
7.14 image/svg-xml
Content-type: image/svg-xml
<?xml version="1.0" ?>
Scalable Vector Graphics (SVG) documents are XML documents whose
content describes graphical information, as described by the SVG
recommendation [SVG]. As a format based on XML, SVG documents should
use the -xml suffix convention in their MIME content-type identifier.
Murata & St.Laurent Expires May 8, 2000 [Page 22]
Internet-Draft XML Media Types November 1999
8. Revision History
draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
and examples (application/mathml-xml, application/xsl-xml,
application/rdf-xml, and image/svg-xml) are added.
draft-murata-01: When text/xml is more appropriate than
application/xml and vice versa.
Murata & St.Laurent Expires May 8, 2000 [Page 23]
Internet-Draft XML Media Types November 1999
References
[1] International Standard Organization/International
Electrotechnical Commission, "Information Technology -
Universal Multiple- Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane", ISO/IEC 10646, May
1993.
[2] International Standard Organization, "Information Processing --
Text and Office Systems -- Standard Generalized Markup Language
(SGML).", ISO 8879, October 1986.
[3] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998.
[4] Choi, U., Chon, K. and H. Park, "Korean Character Encoding for
Internet Messages", RFC 1557, December 1993.
[5] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[9] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[11] The Unicode Consortium, "The Unicode Standard, Version 2.0",
July 1996.
[12] World Wide Web Consortium, "Mathematical Markup Language (XML)
1.01", W3C MathML, July 1999.
[13] World Wide Web Consortium, "Extensible Stylesheet Language
(XSL) 1.0", W3C XSL, April 1999.
[14] World Wide Web Consortium, "Resource Description Framework
Model and Syntax Specification", W3C RDF, February 1999.
Murata & St.Laurent Expires May 8, 2000 [Page 24]
Internet-Draft XML Media Types November 1999
[15] World Wide Web Consortium, "Scalable Vector Graphics (SVG)",
W3C SVG, August 1999.
[16] http://www.w3.org/
Authors' Addresses
MURATA Makoto (FAMILY Given)
Fuji Xerox Information Systems
KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku
Kawasaki-shi, Kanagawa-ken 213-0012
Japan
Phone: +81-44-812-7230
Fax: +81-44-812-7231
EMail: murata.makoto@fujixerox.co.jp
URI: http://www.fxis.co.jp/DMS/sgml/
Simon St.Laurent
126 Birchwood Drive #2
Ithaca, New York 14850
US
EMail: simonstl@simonstl.com
URI: http://www.simonstl.com/
Murata & St.Laurent Expires May 8, 2000 [Page 25]
Internet-Draft XML Media Types November 1999
Appendix A. Acknowledgement
Chris Newman and Yaron Y. Goland both contributed content to the
security considerations section of this document. In particular,
some text in the security considerations section is copied verbatim
from work in progress, draft-newman-mime-textpara-00, by permission
of the author. Chris Newman additionally contributed content to the
encoding considerations sections. Dan Connolly contributed content
discussing when to use text/xml. Discussions with Ned Freed and Dan
Connolly helped refine the author's understanding of the text media
type; feedback from Larry Masinter was also very helpful in
understanding media type registration issues.
Members of the W3C XML Working Group and XML Special Interest group
have made significant contributions to this document, and the
authors would like to specially recognize James Clark, Martin
Duerst, Rick Jelliffe, Gavin Nicol for their many thoughtful
comments.
Murata & St.Laurent Expires May 8, 2000 [Page 26]
Internet-Draft XML Media Types November 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Murata & St.Laurent Expires May 8, 2000 [Page 27]