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 (" 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 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 (" 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} 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" , 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} 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} 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" 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} 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 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 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 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" 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} 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" , 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 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 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 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 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]