XML Media Types
 TOC 
Network Working Group 
Internet-DraftM. Murata
Expires: May 31, 2000Fuji Xerox Information Systems
 S. St.Laurent
 December 1999

XML Media Types
draft-murata-xml-02

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."

To view the entire list of Internet-Drafts Shadow Directories, see 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.



 TOC 

Table of Contents




 TOC 

1. Introduction

The World Wide Web Consortium (W3C) 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.

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.]



 TOC 

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].



 TOC 

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 "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 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 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

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.

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.

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.

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.

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:

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.



 TOC 

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 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.



 TOC 

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.



 TOC 

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:

When a new media type is introduced for an XML-based format, the 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.



 TOC 

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'?>

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 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 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"?>

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.



 TOC 

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.



 TOC 

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 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.


 TOC 

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:  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/


 TOC 

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.



 TOC 

Full Copyright Statement

Acknowledgement