RFC 2376

XML Media Types

📅 published July 1998, from ietf

RFC 2376: XML Media Types 🎀

Okay bestie, so this is RFC 2376, called XML Media Types 💖 It was written by E. Whitehead from UC Irvine and M. Murata from Fuji Xerox Info. Systems, and it came out in July 1998. It's Informational, so it's giving "here's some good info for the Internet community" and not "this is an official Internet standard" ✨ The title block doesn't list anything it obsoletes or updates, so there's no drama there 🧚

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 🦋

Okay, the big idea is that this document proposes two brand new media subtypes, text/xml and application/xml, so people can swap around network entities that are valid Extensible Markup Language (XML) 💜 XML entities are already being passed around over HyperText Transfer Protocol on the World Wide Web, they're a core part of the WebDAV protocol for remote web authoring, and they're expected to be useful in lots of domains 🫶

Table of Contents 🧚

   1 INTRODUCTION ....................................................2
   2 NOTATIONAL CONVENTIONS ..........................................3
   3 XML MEDIA TYPES .................................................3
   3.1  Text/xml Registration ........................................3
   3.2  Application/xml Registration .................................6
   4 SECURITY CONSIDERATIONS .........................................8
   5 THE BYTE ORDER MARK (BOM) AND CONVERSIONS TO/FROM UTF-16 ........9
   6 EXAMPLES ........................................................9
   6.1  text/xml with UTF-8 Charset .................................10
   6.2  text/xml with UTF-16 Charset ................................10
   6.3  text/xml with ISO-2022-KR Charset ...........................10
   6.4  text/xml with Omitted Charset ...............................11
   6.5  application/xml with UTF-16 Charset .........................11
   6.6  application/xml with ISO-2022-KR Charset ....................11
   6.7  application/xml with Omitted Charset and UTF-16 XML Entity ..12
   6.8  application/xml with Omitted Charset and UTF-8 Entity .......12
   6.9  application/xml with Omitted Charset and Internal Encoding
   Declaration.......................................................12
   7 REFERENCES .....................................................13
   8 ACKNOWLEDGEMENTS ...............................................14
   9 ADDRESSES OF AUTHORS ...........................................14
   10 FULL COPYRIGHT STATEMENT ......................................15

1. Introduction 🌸

So the World Wide Web Consortium (W3C) put out a Recommendation [REC-XML] that defines the Extensible Markup Language (XML), version 1. To make it possible to exchange XML network entities, this document proposes two new media types, text/xml and application/xml 💖

XML entities are already being 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. So we need a media type that labels the exchange of XML network entities properly 🎀 (Quick side note, because this happens between communities sometimes: both MIME and XML use the word entity, but they mean different things 🙈)

XML is a subset of the Standard Generalized Markup Language (SGML) [ISO-8897], and right now it's assigned the media types text/sgml and application/sgml. But using those to label XML is not it, and there are three reasons why 💅 First, there are lots of applications that can process XML but can't process SGML, because SGML has a bigger feature set. Second, SGML applications can't always process XML entities, because XML uses features from 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). XML doesn't use these parameters, so it would be ambiguous if they were given for an XML entity 😭 So the best approach for labeling XML network entities is to make new media types just for XML 🦋

XML is an integral part of the WebDAV Distributed Authoring Protocol. W3C Recommendations have usually been assigned IETF tree media types, and similar media types (HTML, SGML) have been assigned IETF tree media types too. So the XML media types belong in the IETF media types tree as well 👑

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

3. XML Media Types 🧚

This document introduces two new media types for XML entities, text/xml and application/xml. The registration info for these media types is described in the sections below 🌈

Every XML entity is suitable for use with the application/xml media type without modification. But that doesn't take advantage of the fact that XML can be treated as plain text in many cases. MIME user agents (and web user agents) that don't have explicit support for application/xml will treat it as application/octet-stream, for example by offering to save it to a file 💾

To say that an XML entity should be treated as plain text by default, use the text/xml media type. This limits the encoding used in the XML entity to the ones that work with the requirements for text media types described in [RFC-2045] and [RFC-2046], like UTF-8, but not UTF-16 (except for HTTP) 🍓

XML gives you a general framework for defining sequences of structured data. Sometimes it makes sense to define new media types that use XML but cover one specific application of XML, maybe because of domain-specific security considerations or runtime information 🔥 This document doesn't prohibit future media types dedicated to those XML applications. However, developers of such media types are recommended to use this document as a basis. Especially, the charset parameter should be used in the same manner 🫶

Inside the XML specification, XML entities fall into four types. In XML terminology they're 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 any of these four types 💖

3.1. Text/xml Registration 🎀

  • MIME media type name: text
  • MIME subtype name: xml
  • Mandatory parameters: none
  • Optional parameters: charset

Even though charset is listed as an optional parameter, using it is STRONGLY RECOMMENDED 🙈 That's because XML processors can use it to figure out the character encoding of the XML entity authoritatively. The charset parameter can also be used for protocol-specific operations, like 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 entity is sent over HTTP, which uses a MIME-like mechanism that's 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]. Here's the tea: most MIME applications handle CR, LF and NUL for text types in ways that would mess up individual octets in UTF-16 multi-octet characters, so gateways from HTTP to these MIME applications MUST transform the XML entity from text/xml; charset="utf-16" to application/xml; charset="utf-16" 😭

Following [RFC-2046], if a text/xml entity is received with the charset parameter left out, MIME processors and XML processors MUST use the default charset value of "us-ascii". When the XML entity is sent over HTTP, the default charset value is still "us-ascii" 🌸

Since the charset parameter is authoritative, the charset isn't always declared inside an XML encoding declaration. So be careful when the recipient strips the MIME header and provides persistent storage for the received XML entity (for example, in a file system) 🧚 Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also persistently store information about the charset, maybe by putting a correct XML encoding declaration inside the XML 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 (for example, ESMTP, 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 encoded. For binary clean transports (for example, 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 it's supported by a wide range of Web user agents, WebDAV clients and servers, as well as XML authoring tools 🌈

Additional information:

  • Magic number(s): none
  • Although no byte sequences can be counted on to always be present, XML entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more information, see Appendix F of [REC-XML] 🧚
  • File extension(s): .xml, .dtd
  • Macintosh File Type Code(s): "TEXT"

Person & email address for further information:

  • Dan Connolly <connolly@w3.org>
  • Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>

Intended usage: COMMON 💖

3.2. Application/xml Registration ✨

okay bestie, this one is the application/xml registration, and it's giving a little more freedom than text/xml 💅

MIME media type name: application

MIME subtype name: xml

Mandatory parameters: none

Optional parameters: charset

Even though charset is listed as optional, using it is STRONGLY RECOMMENDED 🫶 XML processors can use it to figure out the charset of the XML entity with total authority, and it can also power protocol-specific stuff like 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, for the UTF-8 and UTF-16 charsets. They're the faves because every conforming XML processor supports them [REC-XML] 🌸

Now, if an application/xml entity shows up with no charset parameter, the Content-Type header tells you nothing about the charset 🙈 Conforming XML processors MUST follow section 4.3.3 of [REC-XML], which covers exactly this situation. Non-XML MIME processors, though, should not assume a default charset when charset is missing from an application/xml entity.

Here's a plot twist 🌀 Because the charset parameter is the authoritative one, the charset isn't always declared in the XML encoding declaration. So if the recipient strips the MIME header and saves the XML entity somewhere persistent (like a file system), it needs to be careful. Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also store the charset info persistently, maybe by embedding a correct XML encoding declaration inside the XML entity ✨

Encoding considerations:

This media type MAY be encoded however makes sense for the charset and what the MIME transport can handle 🦋 Over 7-bit transports, both UTF-8 and UTF-16 data gets encoded in quoted-printable or base64. Over 8-bit clean transports (like ESMTP, 8BITMIME, or NNTP), UTF-8 stays unencoded but UTF-16 gets base64 encoded. Over binary clean transports (like HTTP), no content-transfer-encoding is needed at all 💖

Security considerations: See section 4 below.

Interoperability considerations: XML has proven itself to be interoperable when importing and exporting between lots of different XML authoring tools 🎀

Published specification: see [REC-XML]

Applications which use this media type: XML is device-, platform-, and vendor-neutral, and it's supported by a huge range of Web user agents and XML authoring tools. Iconic behavior 👑

Additional information:

Magic number(s): none

No byte sequences are guaranteed to show up, but XML entities in ASCII-compatible charsets (including UTF-8) often start with the hexadecimal bytes 3C 3F 78 6D 6C (<?xml). UTF-16 ones often start with FE FF 00 3C 00 3F 00 78 00 6D or FF FE 3C 00 3F 00 78 00 6D 00, which is the Byte Order Mark (BOM) followed by <?xml. For more, check Annex F of [REC-XML] 🔍

File extension(s): .xml, .dtd

Macintosh File Type Code(s): "TEXT"

Person & email address for further information:

Dan Connolly <connolly@w3.org>

Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>

Intended usage: COMMON

Author/Change controller:

The XML specification is a work product of the World Wide Web Consortium's XML Working Group, and it was edited by:

Tim Bray <tbray@textuality.com>

Jean Paoli <jeanpa@microsoft.com>

C. M. Sperberg-McQueen <cmsmcq@uic.edu>

The W3C, and its XML working group, has change control over the XML specification 👑

4. Security Considerations 🔐

XML is a subset of SGML, so it has the same security considerations as [RFC-1874] lays out 💀

To paraphrase section 3 of [RFC-1874]: XML entities carry information that the recipient's XML system parses and processes. Those entities may contain, and such systems may permit, explicit system-level commands to run while the data is processed. To the extent that an XML system will execute arbitrary command strings, recipients of XML entities may be at risk. Generally speaking, it may be possible to specify commands that do unauthorized file operations or change the display processor's environment in ways that mess with later operations 😱

XML use is expected to be varied and widespread 🌈 It's being looked at by a wide range of communities 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 started looking at XML for medical information. Other groups see XML as a way to marshal parameters for remote procedure calls. More uses will undoubtedly pop up 🧚

Security considerations depend on the domain of use. For instance, XML medical records need way more stringent privacy and security considerations than XML library metadata. Likewise, using XML as a parameter marshalling syntax calls for a case-by-case security review 🔒

XML may also have some of the same concerns as plain text 📝 Just like plain text, XML can contain escape sequences which, when displayed, could change the display processor's environment in ways that hurt later operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so that later displayed text is unreadable, or even changing display parameters to deliberately obscure or distort later displayed material so its meaning is lost or altered. Display processors should either filter such material out of displayed text or make sure to reset all important settings once a given display operation is done.

Some terminal devices have keys whose output can be changed by sending the display processor a character sequence. If that's possible, displaying a text object containing such sequences could reprogram keys to do something illicit or dangerous when the user later presses them. In some cases keys can not only be programmed but also triggered remotely, so a text display operation could directly cause some unwanted action. Because of this, the ability to program keys should be blocked, either by filtering or by disabling key programming entirely. 🚨

Also, it's possible to build XML documents that use what XML calls "entity references" (using the XML meaning of "entity", which differs from the MIME definition of that term) to build up repeated expansions of text. Recursive expansions are prohibited [REC-XML], and XML processors are required to detect them. However, even non-recursive expansions can strain a computer's finite computing resources if they're performed many times 🥴

5. The Byte Order Mark (BOM) and Conversions to/from UTF-16 🌟

The XML Recommendation, in section 4.3.3, says that UTF-16 XML entities must begin with a byte order mark (BOM). The BOM is the ZERO WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or 0xFFFE, depending on endianness). The XML Recommendation also says that the BOM is an encoding signature and is not part of the markup or character data of the XML document 🧠

Because of the BOM, applications that convert XML from the UTF-16 encoding to another encoding SHOULD strip the BOM before converting. Similarly, when converting from another encoding into UTF-16, the BOM SHOULD be added once the conversion is complete ✨

6. Examples 📚

The examples below show the value of the Content-type MIME header and the XML declaration (which includes the encoding declaration) inside the XML entity. For UTF-16 examples, the Byte Order Mark character is written as {BOM}, and the XML declaration is assumed to come at the very beginning of the XML entity, right after the BOM. Other MIME headers may be present, and the XML entity may contain other data besides the XML declaration. The examples focus on the Content-type header and the encoding declaration, for clarity 🎀

6.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 text/xml 💖 Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as UTF-8 encoded.

If it's sent over a 7-bit transport (e.g., SMTP), the XML entity must use a content-transfer-encoding of either quoted-printable or base64. Over an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a binary clean transport (e.g., HTTP), no content-transfer-encoding is needed.

6.2. text/xml with UTF-16 Charset 🌊

Content-type: text/xml; charset="utf-16"

{BOM}<?xml version='1.0' encoding='utf-16'?>

This is only possible when the XML entity is sent via HTTP. HTTP uses a MIME-like mechanism and is a binary clean protocol, so it doesn't do CR and LF transformations and it allows NUL octets. That's different 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.

6.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]. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as encoded per [RFC-1557].

ISO-2022-KR is defined to use only 7 bits of data, so no content-transfer-encoding is needed over any transport 🦋

6.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 left out. In this case, MIME and XML processors must assume the charset is "us-ascii", which is the default charset value for text media types specified in [RFC-2046]. That "us-ascii" default still holds even if the text/xml entity is transported using HTTP.

Leaving out the charset parameter is NOT RECOMMENDED for text/xml 🚫 For example, even if the XML entity's contents are UTF-16 or UTF-8, or the entity has an explicit encoding declaration, XML and MIME processors must still assume the charset is "us-ascii" 😭

6.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 application/xml 👑 Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as UTF-16 encoded.

If it's sent over a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), the XML entity must be encoded in quoted-printable or base64. Over a binary clean transport (e.g., HTTP), no content-transfer-encoding is needed.

6.6. application/xml with ISO-2022-KR Charset

Content-type: application/xml; charset="iso-2022-kr"

<?xml version="1.0" encoding="iso-2022-kr"?>

okay so this one is giving Korean 🌸 with a Korean charset (think Hangul) encoded following [RFC-1557]. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as encoded per [RFC-1557], no matter whether the XML entity has an internal encoding declaration. This example does have one, and it agrees with the charset parameter, so everyone's on the same page 💅

ISO-2022-KR has been defined to use only 7 bits of data, so no content-transfer-encoding is necessary with any transport ✨

6.7. application/xml with Omitted Charset and UTF-16 XML Entity

Content-type: application/xml

{BOM}<?xml version='1.0'?>

bestie, the XML entity begins with a BOM 🫶 and the charset has been omitted. That means a conforming XML processor follows the requirements of [REC-XML], section 4.3.3. It reads the BOM, so it knows deterministically that the charset encoding is UTF-16. no guessing needed, it's giving main character energy 👑

An XML-unaware MIME processor should make no assumptions about the charset of the XML entity 🙈

6.8. application/xml with Omitted Charset and UTF-8 Entity

Content-type: application/xml

<?xml version='1.0'?>

in this one the charset parameter is 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 doesn't contain an encoding declaration, but since the encoding is UTF-8, it's still a conforming XML entity. iconic, honestly 💜

An XML-unaware MIME processor should make no assumptions about the charset of the XML entity 🙈

6.9. application/xml with Omitted Charset and Internal Encoding Declaration

Content-type: application/xml

<?xml version='1.0' encoding="ISO-10646-UCS-4"?>

ngl this one is my favourite 🦋 The charset parameter is omitted and there is no BOM, BUT the XML entity does have an encoding declaration inside it that specifies its charset. So 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 entity. In this example, that's UCS-4.

An XML-unaware MIME processor should make no assumptions about the charset of the XML entity 🙈

7. References 📚

  • [ISO-10646] ISO/IEC, Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, May 1993.
  • [ISO-8897] ISO (International Organization for Standardization) ISO 8879:1986(E) Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986- 10-15.
  • [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC- xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
  • [RFC-1557] Choi, U., Chon, K., and H. Park. "Korean Character Encoding for Internet Messages", RFC 1557. December, 1993.
  • [RFC-1874] Levinson, E., "SGML Media Types", RFC 1874. December 1995.
  • [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
  • [RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  • [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.

8. Acknowledgements 💖

okay the thank-you list is so sweet 🥹 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, and 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, and Gavin Nicol for their many thoughtful comments 🫶🌈

9. Addresses of Authors 📬

E. James Whitehead, Jr.
Dept. of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425

EMail: ejw@ics.uci.edu


Murata Makoto (Family Given)
Fuji Xerox Information Systems,
KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku,
Kawasaki-shi, Kanagawa-ken,
213 Japan

EMail: murata@fxis.fujixerox.co.jp

the legal bit, but it's still important, so here it is in full 🎀

Copyright (C) The Internet Society (1998). 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. 🌸

📦 where this page comes from