Network Working Group
Internet-Draft M. Murata
Expires: May 31, 2000 Fuji Xerox Information Systems
S. St.Laurent
December 1999
XML Media Types
draft-murata-xml-02.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 31, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document proposes five new media types, text/xml,
application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, 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 five 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.
, et. al. Expires May 31, 2000 [Page 1]
Internet-Draft XML Media Types December 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7
3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9
3.3 text/xml-external-parsed-entity Registration . . . . . . . . 11
3.4 application/xml-external-parsed-entity Registration . . . . 13
3.5 Application/xml-dtd Registration . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 16
5. The Byte Order Mark (BOM) and Conversions to/from UTF-16 . . 18
6. A naming convention for XML-based media types . . . . . . . 19
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1 text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 21
7.2 text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 21
7.3 text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 21
7.4 text/xml with Omitted Charset . . . . . . . . . . . . . . . 22
7.5 application/xml with UTF-16 Charset . . . . . . . . . . . . 22
7.6 application/xml with ISO-2022-KR Charset . . . . . . . . . . 22
7.7 application/xml with Omitted Charset and UTF-16 XML MIME
entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.8 application/xml with Omitted Charset and UTF-8 Entity . . . 23
7.9 application/xml with Omitted Charset and Internal Encoding
Declaration . . . . . . . . . . . . . . . . . . . . . . . . 23
7.10 text/xml-external-parsed-entity with UTF-8 Charset . . . . . 24
7.11 application/xml-external-parsed-entity with UTF-16 Charset . 24
7.12 application/xml-dtd . . . . . . . . . . . . . . . . . . . . 24
7.13 application/mathml-xml . . . . . . . . . . . . . . . . . . . 25
7.14 application/XSLT-xml . . . . . . . . . . . . . . . . . . . . 25
7.15 application/rdf-xml . . . . . . . . . . . . . . . . . . . . 25
7.16 image/svg-xml . . . . . . . . . . . . . . . . . . . . . . . 25
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 26
References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
A. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
, et. al. Expires May 31, 2000 [Page 2]
Internet-Draft XML Media Types December 1999
1. Introduction
The World Wide Web Consortium (W3C)[20] has issued Extensible
Markup Language (XML), version 1[10]. To enable the exchange of XML
network entities, this document proposes five new media types,
text/xml, application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, 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 8879[1], 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 in RFC 1874[4] 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.
, et. al. Expires May 31, 2000 [Page 3]
Internet-Draft XML Media Types December 1999
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
document. Notes still appear in the document in the section noted.
General - [Editor's note: should we replace
'external-parsed-entity' with 'epse'?]
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.]
, et. al. Expires May 31, 2000 [Page 4]
Internet-Draft XML Media Types December 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 RFC 2119[8].
, et. al. Expires May 31, 2000 [Page 5]
Internet-Draft XML Media Types December 1999
3. XML Media Types
This document introduces five new media types for XML MIME entities,
text/xml, application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, 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", while "external
parsed entities" require text/xml-external-parsed-entity or
application/xml-external-parsed-entity. For backward compatibility,
application/xml and text/xml can also be used for "external parsed
entities", "external DTD subsets", and "external parameter
entities". The media type application/xml-dtd can be used for
"external DTD subsets" or "external parameter entities". Neither
external DTD subsets nor external parameter entities parse as XML
documents, and while some XML document entities may be used as
external parsed entities and vice versa, there are many cases where
the two are not interchangeable. XML also has unparsed entities,
internal parsed entities, and internal parameter entities, but they
are not XML MIME entities.
If an XML document 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. Similarly,
text/xml-external-parsed-entity is preferable when an external
parsed entity is readable by casual users, but
application/xml-external-parsed-entity is preferable when a plain
text display is inappropriate.
The top-level media type "text" has some restrictions on MIME
entities and they are described in RFC 2045[5] and RFC 2046[6]. 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 or
text/xml-external-parsed-entity (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
, et. al. Expires May 31, 2000 [Page 6]
Internet-Draft XML Media Types December 1999
"Optional parameters" of "3.2 Application/xml Registration"). The
same rules apply to the distinction between
text/xml-external-parsed-entity and
application/xml-external-parsed-entity.
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.
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" (see RFC 2279[9]) is the
recommended value, representing the UTF-8 charset. UTF-8 is
supported by all conforming processors of XML 1.0[10].
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 RFC 2616[13])), "UTF-16"
(Appendix C.3 of Unicode 3.0[14] and Amendment 1 of ISO/IEC
10646[2]) is also recommended. UTF-16 is supported by all
conforming processors of XML 1.0[10] . 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[6], 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
, et. al. Expires May 31, 2000 [Page 7]
Internet-Draft XML Media Types December 1999
value is still "us-ascii". (Note: There is an inconsistency
between this specification and HTTP/1.1, which uses "ISO-8859-1" as
the default for a historical reason. Since XML is a new format, a
new default should be chosen for better I18N. "US-ASCII" was chosen
as the intersection of "UTF-8" and "ISO-8859-1".)
One reason that the charset parameter is authoritative is that some
MIME processing engines do transcoding of MIME bodies of the
top-level media type "text" without reference to any of the internal
content. Thus, it is possible that some agent might change a
text/xml;charset=iso-2022-jp to text/xml;charset=UTF-8 without
modifying the encoding declaration of an XML document.
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
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., 8BITMIME
ESMTP 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 XML 1.0[10]
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
, et. al. Expires May 31, 2000 [Page 8]
Internet-Draft XML Media Types December 1999
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 XML 1.0[10].
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
Murata Makoto (Family Given) <mura034@attglobal.net>
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 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
, et. al. Expires May 31, 2000 [Page 9]
Internet-Draft XML Media Types December 1999
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" (see RFC 2279[9]) and "UTF-16" (Appendix C.3 of Unicode
3.0[14] and Amendment 1 of ISO/IEC 10646[2]) are the recommended
values, representing the UTF-8 and UTF-16 charsets, respectively.
These charsets are preferred since they are supported by all
conforming processors of XML 1.0[10].
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 XML 1.0[10] 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.,
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., 8BITMIME
ESMTP 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.
, et. al. Expires May 31, 2000 [Page 10]
Internet-Draft XML Media Types December 1999
Published specification:
see XML 1.0[10]
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 XML 1.0[10].
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
See the registration of text/xml.
Intended usage: COMMON
Author/Change controller:
The same as the author/change controller of text/xml.
3.3 text/xml-external-parsed-entity Registration
MIME media type name: text
MIME subtype name: xml-external-parsed-entity
Mandatory parameters: none
Optional parameters: charset
The charset parameter of text/xml-external-parsed-entity is handled
exactly the same as that of text/xml.
, et. al. Expires May 31, 2000 [Page 11]
Internet-Draft XML Media Types December 1999
Encoding considerations:
The encoding considerations of text/xml apply.
Security considerations:
See section 4 below.
Interoperability considerations:
XML external parsed entities are as interoperable as XML documents,
though they have a less tightly constrained structure and must
therefore be referenced by XML documents for proper handling by XML
processors. Similarly, XML documents cannot be reliably used as
external parsed entities because external parsed entities are
prohibited from using the standalone declaration in the XML
declaration. Identifying XML external parsed entities with their own
content type should enhance interoperability of both XML documents
and XML external parsed entities.
Since non-validating processors of XML 1.0 do not always read
external parsed entities, interoperability is not guaranteed.
Published specification:
see XML 1.0[10]
Applications which use this media type:
Applications of text/xml or application/xml may use external parsed
entities.
[Editor's note: should we say anything about dispatching based on
namespace URIs in this document?]
Additional information:
Magic number(s): none
The same as magic numbers for text/xml.
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
See the registration of text/xml.
, et. al. Expires May 31, 2000 [Page 12]
Internet-Draft XML Media Types December 1999
Intended usage: COMMON
Author/Change controller:
The same as the author/change controller of text/xml.
3.4 application/xml-external-parsed-entity Registration
MIME media type name: application
MIME subtype name: xml-external-parsed-entity
Mandatory parameters: none
Optional parameters: charset
The charset parameter of application/xml-external-parsed-entity 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:
The interoperability considerations of
text/xml-external-parsed-entity apply.
Published specification:
see XML 1.0[10]
Applications which use this media type:
Applications of text/xml or application/xml may use external parsed
entities.
[Editor's note: should we say anything about dispatching based on
namespace URIs in this document?]
Additional information:
Magic number(s): none
The same as magic numbers for text/xml.
, et. al. Expires May 31, 2000 [Page 13]
Internet-Draft XML Media Types December 1999
File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
See the registration of text/xml.
Intended usage: COMMON
Author/Change controller:
The same as the author/change controller of text/xml.
3.5 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.
Published specification: see XML 1.0[10]
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:
, et. al. Expires May 31, 2000 [Page 14]
Internet-Draft XML Media Types December 1999
Magic number(s): none
The same as magic numbers for application/xml.
File extension(s): .dtd
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
See the registration of text/xml.
Intended usage: COMMON
Author/Change controller:
The same as the author/change controller of text/xml.
, et. al. Expires May 31, 2000 [Page 15]
Internet-Draft XML Media Types December 1999
4. Security Considerations
XML, as a subset of SGML, has the same security considerations as
specified in RFC 1874[4]. [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[4], 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
, et. al. Expires May 31, 2000 [Page 16]
Internet-Draft XML Media Types December 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 by XML 1.0[10] 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.
, et. al. Expires May 31, 2000 [Page 17]
Internet-Draft XML Media Types December 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.
, et. al. Expires May 31, 2000 [Page 18]
Internet-Draft XML Media Types December 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[12] or XSLT[19] 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[16] 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[17] 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
, et. al. Expires May 31, 2000 [Page 19]
Internet-Draft XML Media Types December 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[7]. 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 XML
1.0[10]. 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.
, et. al. Expires May 31, 2000 [Page 20]
Internet-Draft XML Media Types December 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., 8BITMIME ESMTP 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 RFC 2616[13]) 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'?>
, et. al. Expires May 31, 2000 [Page 21]
Internet-Draft XML Media Types December 1999
This example shows text/xml with a Korean charset (e.g., Hangul)
encoded following the specification in RFC 1557[3]. Since the
charset parameter is provided, MIME and XML processors must treat
the enclosed entity as encoded per RFC 1557[3].
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[6]. 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), the XML MIME entity
must be encoded in quoted-printable or base64. For a binary clean
transport (e.g., HTTP) or an 8-bit clean transport (e.g., 8BITMIME
ESMTP or NNTP), 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[3]. Since
the charset parameter is provided, MIME and XML processors must
, et. al. Expires May 31, 2000 [Page 22]
Internet-Draft XML Media Types December 1999
treat the enclosed entity as encoded per RFC 1557[3], 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 XML 1.0[10], 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 XML 1.0[10] 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
, et. al. Expires May 31, 2000 [Page 23]
Internet-Draft XML Media Types December 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
XML 1.0[10], 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 text/xml-external-parsed-entity with UTF-8 Charset
Content-type: text/xml-external-parsed-entity; charset="utf-8"
<?xml encoding="utf-8"?>
This is the recommended charset value for use with
text/xml-external-parsed-entity. 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., 8BITMIME ESMTP or NNTP), or a
binary clean transport (e.g., HTTP) no content-transfer-encoding is
necessary.
7.11 application/xml-external-parsed-entity with UTF-16 Charset
Content-type: application/xml-external-parsed-entity;
charset="utf-16"
{BOM}<?xml?>
This is a recommended charset value for use with
application/xml-external-parsed-entity. 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., 8BITMIME ESMTP 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.12 application/xml-dtd
Content-type: application/xml-dtd; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
, et. al. Expires May 31, 2000 [Page 24]
Internet-Draft XML Media Types December 1999
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.13 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 MathML 1.01[15]. As a
format based on XML, MathML documents should use the -xml suffix
convention in their MIME content-type identifier.
7.14 application/XSLT-xml
Content-type: application/XSLT-xml
<?xml version="1.0" ?>
Extensible Stylesheet Language (XSLT) documents are XML documents
whose content describes stylesheets for other XML documents, as
described by XSLT[19]. As a format based on XML, XSLT documents
should use the -xml suffix convention in their MIME content-type
identifier.
7.15 application/rdf-xml
Content-type: application/rdf-xml
<?xml version="1.0" ?>
RDF documents identified using this MIME type are XML documents
whose content describes mathematical information, as described by
RDF[11]. RDF documents that use a format based on XML should use the
-xml suffix convention in their MIME content-type identifier.
7.16 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 SVG[18]. As
a format based on XML, SVG documents should use the -xml suffix
convention in their MIME content-type identifier.
, et. al. Expires May 31, 2000 [Page 25]
Internet-Draft XML Media Types December 1999
8. Revision History
draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
and examples (application/mathml-xml, application/XSLT-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.
draft-murata-02: Replaced "(e.g., ESMTP, 8BITMIME, or NNTP)" with
"(e.g., 8BITMIME ESMTP or NNTP)"; transcoding without revising
encoding declarations is mentioned; the choice of "US-ascii" as the
default is explained. text/xml-external-parsed-entity and
application/xml-external-parsed-entity are added. Examples of these
two media types are added (7.10 and 7.11). References are updated.
, et. al. Expires May 31, 2000 [Page 26]
Internet-Draft XML Media Types December 1999
References
[1] International Standard Organization, "Information Processing --
Text and Office Systems -- Standard Generalized Markup Language
(SGML).", ISO 8879, October 1986.
[2] International Standard Organization/International
Electrotechnical Commission, "Information Technology -
Universal Multiple- Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane. Several amendments
and technical corrigenda have been published up to now. Other
amendments are currently at various stages of
standardization.", ISO/IEC 10646, May 1993.
[3] Choi, U., Chon, K. and H. Park, "Korean Character Encoding for
Internet Messages", RFC 1557, December 1993.
[4] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[7] Freed, N., Klensin, J. and J Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC
2048, November 1996.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[10] Bray, T, Paoli, J and C.M. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0", World Wide Web Consortium
Recommendation REC-xml-19980210.
http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
[11] Lassila, O. and R.R. Swick, "Resource Description Framework
(RDF) Model and Syntax Specification", World Wide Web
Consortium Recommendation REC-rdf-syntax-19990222.
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222, February
1999.
[12] Bos, B., Lie, H.W., Lilley, C. and I. Jacobs, "Cascading Style
, et. al. Expires May 31, 2000 [Page 27]
Internet-Draft XML Media Types December 1999
Sheets, level 2 (CSS2) Specification", World Wide Web
Consortium Recommendation REC-CSS2-19980512
http://www.w3.org/TR/1998/REC-CSS2-19980512, May 1998.
[13] 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.
[14] The Unicode Consortium, "The Unicode Standard, Version 3.0
(ISBN 0-201-61633-5)", September 1999.
[15] Ion, P. and R. Miner, "Mathematical Markup Language (MathML)
1.01", World Wide Web Consortium Recommendation
REC-MathML-19980407; revised 19990707.
http://www.w3.org/1999/07/REC-MathML-19990707, July 1999.
[16] DeRose, S. and R. Daniel Jr., "XML Pointer Language
(XPointer)", World Wide Web Consortium Working Draft.
http://www.w3.org/1999/07/WD-xptr-19990709, July 1999.
[17] DeRose, S., Orchard, D. and B. Trafford, "XML Linking Language
(XLink)", World Wide Web Consortium Working Draft
WD-xlink-19990726 http://www.w3.org/1999/07/WD-xlink-19990726,
July 1999.
[18] Ferraiolo, J, "Scalable Vector Graphics (SVG)", World Wide Web
Consortium Working Draft.
http://www.w3.org/1999/08/WD-SVG-19990812/, August 1999.
[19] Clark , J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116.
http://www.w3.org/TR/1999/REC-xslt-19991116, November 1999.
[20] http://www.w3.org/
Authors' Addresses
, et. al. Expires May 31, 2000 [Page 28]
Internet-Draft XML Media Types December 1999
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: mura034@attglobal.net
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/
, et. al. Expires May 31, 2000 [Page 29]
Internet-Draft XML Media Types December 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.
, et. al. Expires May 31, 2000 [Page 30]
Internet-Draft XML Media Types December 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 implementation 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.
, et. al. Expires May 31, 2000 [Page 31]