From: http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt Date: November 17, 1999 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 (" Simon St.Laurent 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 Jean Paoli C. M. Sperberg-McQueen 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 (" Simon St.Laurent 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 Jean Paoli C. M. Sperberg-McQueen 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 (" Simon St.Laurent 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 Jean Paoli C. M. Sperberg-McQueen 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" 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} 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" 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} 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} 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" 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} 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 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 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 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" 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 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 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 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 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]