RFC 7303

XML Media Types

📅 published July 2014, from ietf

RFC 7303: XML Media Types 💖

Part 1 of 8

Okay bestie, this is RFC 7303, called XML Media Types 🎀. The authors are H. Thompson from the University of Edinburgh and C. Lilley from W3C. It's a Standards Track document dated July 2014, with ISSN 2070-1721 ✨. It obsoletes RFC 3023 and updates RFC 6839, so it's the new official version that replaces the old XML media type spec 🫶.

Abstract ✨

This spec standardizes three media types: application/xml, application/xml-external-parsed-entity, and application/xml-dtd 💅. They're for sending network entities related to the Extensible Markup Language (XML). It also defines text/xml and text/xml-external-parsed-entity as aliases for the matching application/ types. Lastly, it standardizes the +xml suffix for naming media types outside these five types when those types represent XML MIME entities 🦋.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF) 🌸. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7303 🍓.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
  2.2.  Characters, Encodings, Charsets . . . . . . . . . . . . .   4
  2.3.  MIME Entities, XML Entities . . . . . . . . . . . . . . .   5
3.  Encoding Considerations . . . . . . . . . . . . . . . . . . .   6
  3.1.  XML MIME Producers  . . . . . . . . . . . . . . . . . . .   6
  3.2.  XML MIME Consumers  . . . . . . . . . . . . . . . . . . .   7
  3.3.  The BOM and Encoding Conversions  . . . . . . . . . . . .   8
4.  XML Media Types . . . . . . . . . . . . . . . . . . . . . . .   9
  4.1.  XML MIME Entities . . . . . . . . . . . . . . . . . . . .   9
  4.2.  Using '+xml' when Registering XML-Based Media Types . . .  11
  4.3.  Registration Guidelines for XML-Based Media Types Not
        Using   '+xml'  . . . . . . . . . . . . . . . . . . . . .  12
5.  Fragment Identifiers  . . . . . . . . . . . . . . . . . . . .  13
6.  The Base URI  . . . . . . . . . . . . . . . . . . . . . . . .  14
7.  XML Versions  . . . . . . . . . . . . . . . . . . . . . . . .  14
8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
  8.1.  UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . .  15
  8.2.  UTF-16 Charset  . . . . . . . . . . . . . . . . . . . . .  16
  8.3.  Omitted Charset and 8-Bit MIME Entity . . . . . . . . . .  16
  8.4.  Omitted Charset and 16-Bit MIME Entity  . . . . . . . . .  16
  8.5.  Omitted Charset, No Internal Encoding Declaration . . . .  17
  8.6.  UTF-16BE Charset  . . . . . . . . . . . . . . . . . . . .  17
  8.7.  Non-UTF Charset . . . . . . . . . . . . . . . . . . . . .  18
  8.8.  INCONSISTENT EXAMPLE: Conflicting Charset and Internal
        Encoding Declaration  . . . . . . . . . . . . . . . . . .  18
  8.9.  INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . .  18
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
  9.1.  application/xml Registration  . . . . . . . . . . . . . .  19
  9.2.  text/xml Registration . . . . . . . . . . . . . . . . . .  21
  9.3.  application/xml-external-parsed-entity Registration . . .  21
  9.4.  text/xml-external-parsed-entity Registration  . . . . . .  22
  9.5.  application/xml-dtd Registration  . . . . . . . . . . . .  22
  9.6.  The '+xml' Naming Convention for XML-Based Media Types  .  23
    9.6.1.  The '+xml' Structured Syntax Suffix Registration  . .  23
10. Security Considerations . . . . . . . . . . . . . . . . . . .  25
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  27
  11.2.  Informative References . . . . . . . . . . . . . . . . .  29
Appendix A.  Why Use the '+xml' Suffix for XML-Based MIME Types?   32
Appendix B.  Core XML Specifications  . . . . . . . . . . . . . .  32
Appendix C.  Operational Considerations . . . . . . . . . . . . .  32
  C.1.  General Considerations  . . . . . . . . . . . . . . . . .  33
  C.2.  Considerations for Producers  . . . . . . . . . . . . . .  33
  C.3.  Considerations for Consumers  . . . . . . . . . . . . . .  34
Appendix D.  Changes from RFC 3023  . . . . . . . . . . . . . . .  34
Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  35

1. Introduction ✨

The World Wide Web Consortium has put out the Extensible Markup Language (XML) 1.0 [XML] and Extensible Markup Language (XML) 1.1 [XML1.1] specs 🌸. So that XML network entities can be exchanged, this spec standardizes three media types (application/xml, application/xml-external-parsed-entity, and application/xml-dtd), two aliases (text/xml and text/xml-external-parsed-entity), and a naming convention for XML-based MIME media types that uses +xml 💖.

XML has been the foundation for lots of other media types, in every branch of the IETF media types tree 🦋. To make those easier to process, and following what [RFC6838] says about structured syntax name suffixes, the +xml suffix is registered in Section 9.6. That means generic XML tools (browsers, editors, search engines, and other processors) can work with all XML-based media types 🧚.

This spec replaces [RFC3023] 💅. The big changes are: text/xml and text/xml-external-parsed-entity now line up with application/xml and application/xml-external-parsed-entity respectively; XPointer and XML Base are added as fragment identifiers and base URIs; the XPointer Registry is integrated; and lots of references got updated 👑.

2. Notational Conventions 📚

2.1. Requirements Language 🔑

Here's the key words list. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this spec are to be read as described in [RFC2119] 🫶.

2.2. Characters, Encodings, Charsets 🔤

Both XML (in an XML or Text declaration, using the encoding pseudo-attribute) and MIME (in a Content-Type header field, using the charset parameter) use one shared set of labels [IANA-CHARSETS] to name the MIME charset, which is the mapping from byte stream to character sequence [RFC2978] 🌈.

Here we say "charset parameter" and "encoding declaration" to mean whichever MIME charset is set by a MIME charset parameter or an XML encoding declaration, respectively 💜. The phrase "character encoding" (or just "encoding", when context makes it clear) is reserved for the MIME charset actually used in a given XML MIME entity ✨.

[UNICODE] defines three "encoding forms": UTF-8, UTF-16, and UTF-32 🍓. Since UTF-8 can only be serialized one way, the only possible label for UTF-8-encoded documents serialized into MIME entities is utf-8. UTF-16 XML documents, though, can be serialized into MIME entities in one of two ways: big-endian, labelled (optionally) utf-16 or utf-16be, or little-endian, labelled (optionally) utf-16 or utf-16le 🌸. When the utf-16 serialization is used, a Byte Order Mark (BOM) is required, as explained in Section 3.3 below 🔥.

UTF-32 has four possible serializations, but [UNICODE] only gives names to two of them (UTF-32BE and UTF-32LE) 🙈. Support for the various serializations varies a lot, and security concerns about using them have been raised (for example, see [Sivonen]). The use of UTF-32 is NOT RECOMMENDED for XML MIME entities 🚫.

2.3. MIME Entities, XML Entities 🧩

Sometimes two communities collide, and that's what happened here: MIME and XML both define the term "entity", but with different meanings 💀. Section 2.4 of [RFC2045] says:

The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity.

Section 4 of [XML] says:

An XML document may consist of one or many storage units. These are called entities; they all have content and are all (except for the document entity and the external DTD subset) identified by entity name.

In this spec, "XML MIME entity" means the second kind (an XML entity) wrapped inside the first kind (a MIME entity) 🦋.

XML also lets you name and reference entities for inclusion or substitution. To avoid mixing things up, this spec uses "XML-entity declaration/reference/..." when talking about those cases 💅.

3. Encoding Considerations ✨

okay so this one is about character encoding, and it's giving "everyone needs to be on the same page or it all goes sideways" 💅 The registrations below all handle encoding the same way, by pointing back to this section 🫶

Here's the tea: an XML MIME entity can have up to three different sources of info about its character encoding 👀 There's the charset parameter, a BOM (see Section 3.3 below), and an XML encoding declaration (see Section 4.3.3 of [XML]). Keeping those three in sync takes real teamwork between entity authors and MIME agents, meaning the processes that package, transfer, deliver, and/or receive MIME entities 🎀

The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME entities 🌸 bestie, this is the main one to remember 🍓

Some MIME agents are "XML-aware" 🧚 which means they can actually process XML MIME entities as XML and detect the XML encoding declaration (or notice that it's missing). They can see all three sources of encoding info, and they're expected to know about this spec 🔥

Other MIME agents are not XML-aware 💀 so they have zero clue what the XML encoding declaration says. They're missing one of the three sources, and they're also less likely to know about or follow this spec 🙈

Then there are agents like proxies and transcoders, which both consume and produce MIME entities 🦋

Having two kinds of agents handling XML MIME entities makes the coordination way more complicated 😭 So the recommendations below are built to maximise interoperability. On one hand, they require consistent production and encourage production that's as robust as possible. On the other hand, they spell out recovery strategies so consumers can still interoperate when the production rules get broken 💜

3.1. XML MIME Producers

XML-aware MIME producers SHOULD supply a charset parameter and/or an appropriate BOM with non-UTF-8-encoded XML MIME entities that lack an encoding declaration. Such producers SHOULD remove or correct an encoding declaration that is known to be incorrect (for example, as a result of transcoding). 🧹

XML-aware MIME producers MUST supply an XML text declaration at the beginning of non-UNICODE XML external parsed entities that would otherwise begin with the hexadecimal octet sequences 0xFE 0xFF, 0xFF 0xFE or 0xEF 0xBB 0xBF, in order to avoid the mistaken detection of a BOM. This one is a MUST, no cap, because otherwise a BOM could get detected by accident 🙅‍♀️✨

XML-unaware MIME producers MUST NOT supply a charset parameter with an XML MIME entity unless the entity's character encoding is reliably known. This is especially important for central configuration of web servers, where setting a default for the charset parameter will almost certainly break this rule 💀 Don't do it, friend 🫠

XML MIME producers are RECOMMENDED to provide ways for users to control what value, if any, is given to charset parameters for XML MIME entities. One example is letting users control the configuration of Web server filename-to-Content-Type-header mappings on a file-by-file or suffix basis 🌈 giving people the choice is so iconic 👑

3.2. XML MIME Consumers

For XML MIME consumers, things get messy when the available character encoding info doesn't agree with itself 😵‍💫 Again, we have to split things up into XML-aware and XML-unaware agents 🎀

When a charset parameter is specified for an XML MIME entity, the normative part of the [XML] specification leaves open how to figure out which encoding to use when processing the entity 🤷‍♀️ That's true whether or not the entity has in-band encoding info, meaning a BOM (Section 3.3), an XML encoding declaration, both, or neither. The tricky case is when there's in-band info and it conflicts with the charset parameter, because [XML] doesn't say which one wins. Its (non-normative) Appendix F actually points over to this spec:

   [T]he preferred method of handling conflict should be specified as
   part of the higher-level protocol used to deliver XML.  In
   particular, please refer to [IETF RFC 3023] or its successor...

So to match what deployed processors and content already do, and to avoid clashing with this or other normative specs, this spec sets the priority like this 🧠

  • A BOM (Section 3.3) is authoritative if it is present in an XML MIME entity.
  • In the absence of a BOM (Section 3.3), the charset parameter is authoritative if it is present.

Whenever one of those determines the authoritative source of encoding info, consumers SHOULD process XML MIME entities based on that info 🔥

When MIME producers follow the requirements above (Section 3.1, Section 3), inconsistencies won't pop up 🙌 The priority rules only really matter for non-conforming XML MIME entities. When things are inconsistent, no single strategy gets the 'right' answer every single time 🤓 The whole point of picking one here is to help everyone slowly converge, first on the consumer side and then on the producer side 🌱

For XML-aware consumers, note that Section 4.3.3 of [XML] does _not_ make it an error for the charset parameter and the XML encoding declaration (or the UTF-8 default when there's no encoding declaration and no BOM) to be inconsistent. Such consumers might still choose to issue a warning in this case ⚠️

If an XML MIME entity shows up with the charset parameter left out, the MIME Content-Type header isn't giving any info about the character encoding at all 🫥 XML-aware consumers MUST follow the requirements in section 4.3.3 of [XML] that directly address this case. XML-unaware MIME consumers SHOULD NOT assume a default encoding in this case 🙅‍♀️

3.3. The BOM and Encoding Conversions

Section 4.3.3 of [XML] says that UTF-16 XML MIME entities not labelled as "utf-16le" or "utf-16be" MUST begin with a BOM, U+FEFF. That shows up as the hexadecimal octet sequence 0xFE 0xFF (big-endian) or 0xFF 0xFE (little-endian). [XML] also says the BOM is an encoding signature, which means it isn't part of the markup or the character data of the XML document 🧚

Because of the BOM, applications that convert XML from UTF-16 to an encoding other than UTF-8 MUST strip the BOM before converting. Going the other way, when converting from another encoding into UTF-16, either with no charset parameter or labelled "utf-16", the BOM MUST be added. The exception is when the original encoding was UTF-8 and a BOM was already there, because then it MUST be transcoded into the right UTF-16 BOM 🔄

Section 4.3.3 of [XML] also lets UTF-8 XML MIME entities start with a BOM, which shows up as the hexadecimal octet sequence 0xEF 0xBB 0xBF. That's also defined as an encoding signature, not part of the markup or character data 🫶

Applications that convert XML from UTF-8 to an encoding other than UTF-16 MUST strip the BOM, if one is present, before converting. Applications that convert XML into UTF-8 MAY add a BOM 🌸

Besides the MIME charset "utf-16", [RFC2781] introduces "utf-16le" (little-endian) and "utf-16be" (big-endian). When an XML MIME entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM, but it SHOULD contain an in-band XML encoding declaration 💖 Converting from UTF-8 or from UTF-16 (unlabelled, or labelled "utf-16") to "utf-16be" or "utf-16le" MUST strip a BOM if one is present. Converting from UTF-16 labelled "utf-16le" or "utf-16be" to UTF-16 with no label or labelled "utf-16" MUST add the appropriate BOM. Converting from UTF-16 labelled "utf-16le" or "utf-16be" to UTF-8 MAY add a UTF-8 BOM, but this is NOT RECOMMENDED 🙈

Appendix F of [XML] also suggests that a UTF-32 BOM might be used with UTF-32-encoded documents. As mentioned above, this specification recommends against using UTF-32 🚫 If you do use it, the same considerations as UTF-16 apply: the BOM is a signature and not part of the document, there's transcoding into and out of it, and there's transcoding into and out of the MIME charsets "utf-32le" and "utf-32be". Consumers that don't support UTF-32 SHOULD still recognise UTF-32 signatures so they can give helpful error messages, instead of treating them as invalid UTF-16 🧚‍♀️✨

4. XML Media Types

4.1. XML MIME Entities ✨

Okay so within the XML spec, XML MIME entities come in four flavours 💅 In XML-speak they're called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". Here's how the registered types should be used for each one 🎀

  • document entities: The media types application/xml or text/xml, or a more specific media type (see Section 9.6), SHOULD be used.
  • external DTD subsets: The media type application/xml-dtd SHOULD be used. The media types application/xml and text/xml MUST NOT be used.
  • external parsed entities: The media types application/xml-external-parsed-entity or text/xml-external-parsed-entity SHOULD be used. The media types application/xml and text/xml MUST NOT be used unless the parsed entities are also well-formed "document entities".
  • external parameter entities: The media type application/xml-dtd SHOULD be used. The media types application/xml and text/xml MUST NOT be used.

Now the tea 🍓 [RFC3023] (which this specification obsoletes) recommended text/xml and text/xml-external-parsed-entity for document entities and external parsed entities, respectively. Buuut it described character encoding handling that didn't match what everyone actually did in the wild 🙈 Those types are still super common, so this spec lines up the character encoding handling with industry practice.

Also, [RFC2376] (which is obsolete) let application/xml and text/xml be used for any of the four types. In practice though, it was probably rare 🤷‍♀️

Neither external DTD subsets nor external parameter entities parse as XML documents. Some XML document entities can be used as external parsed entities and vice versa, but there are lots of cases where the two aren't interchangeable 🦋 XML also has unparsed entities, internal parsed entities, and internal parameter entities, but those are not XML MIME entities, so they're out of scope here.

Compared to [RFC2376] or [RFC3023], this spec changes how text/xml and text/xml-external-parsed-entity handle character encoding. They're now treated exactly like the matching application/ types. Still, application/xml and application/xml-external-parsed-entity are RECOMMENDED, to avoid confusion from the old distinction ✨ The earlier confusion about default character sets for the two text/ types is gone, because:

  • [RFC7231] changes [RFC2616] by removing the ISO-8859-1 default and not defining any default at all;
  • [RFC6657] updates [RFC2046] to remove the US-ASCII [ASCII] default.

See Section 3 for the now-unified approach to the charset parameter that comes out of this 💜

XML gives you a general framework for defining sequences of structured data 🧚 It's often a good idea to define new media types that use XML but cover one specific application of it, because of domain-specific display, editing, security considerations, or runtime information 👑 Those media types might also only allow UTF-8 and/or UTF-16 and prohibit other character sets. This spec doesn't prohibit them. In fact, they're expected to multiply 🌈

That said, developers of those media types are RECOMMENDED to use this spec as the basis for their registration. See Section 4.2 for more detailed guidance on using the '+xml' suffix when registering such types.

An XML document labelled application/xml or text/xml, or with a '+xml' media type, might contain namespace declarations, stylesheet-linking processing instructions (PIs), schema information, or other declarations that suggest how the document should be processed 👀 For example, a document might have the XHTML namespace and a reference to a Cascading Style Sheets (CSS) stylesheet. Applications could use that info to send the document off for the right processing. Appendix B lists the core XML specifications that, together with [XML] itself, show how to figure out an XML document's language-level semantics and suggest how to locate information about its application-level semantics 🔥

4.2. Using '+xml' when Registering XML-Based Media Types 💖

In Section 9.6, this spec updates the registration in [RFC6839] for XML-based MIME types (the '+xml' types).

When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml', unless generic XML processing is somehow inappropriate for documents of the new type. This convention lets applications that can process XML generically detect that the MIME entity is supposed to be an XML document, verify that by invoking an XML processor, and then process it accordingly 🫶 Applications can check for types that represent XML MIME entities by comparing the last four characters of the subtype to the string '+xml'. (Heads up though: four of the five media types defined in this spec, namely text/xml, application/xml, text/xml-external-parsed-entity, and application/xml-external-parsed-entity, also represent XML MIME entities while not ending in '+xml' 🙃)

NOTE: Section 5.3.2 of [RFC7231] does not support any form of Accept header that will match only '+xml' types. In particular, Accept headers of the form Accept: */*+xml are not allowed, and will not work for this purpose. 💀

Media types following the '+xml' naming convention SHOULD define the charset parameter, for consistency, since XML-generic processing by definition treats all XML MIME entities the same way when it comes to character encoding information. Still, there are some cases where the charset parameter doesn't need to be defined. For example:

  • When an XML-based media type is restricted to UTF-8, it is not necessary to define the charset parameter. UTF-8 is the default for XML.
  • When an XML-based media type is restricted to UTF-8 and UTF-16, it might not be unreasonable to omit the charset parameter. Neither UTF-8 nor UTF-16 require XML encoding declarations.

XML generic processing isn't always appropriate for XML-based media types. For example, some authors may want their types to stay totally opaque, except to applications built specifically for that media type 🔒 By NOT following the '+xml' naming convention, such media types can avoid XML-generic processing. Generic processing is still going to be useful in lots of cases, though, including situations that are hard to predict ahead of time, so the '+xml' convention is to be preferred unless there's a particularly compelling reason not to use it ✨

The registration process for specific '+xml' media types is described in [RFC6838]. New XML-based media type registrations in the IETF MUST follow these guidelines. When other organisations register XML-based media types via the "Specification Required" IANA registration policy [RFC5226], the relevant Media Reviewer SHOULD make sure they use the '+xml' convention, to maximise interoperability of their XML-based documents 🌸 Only media subtypes that represent XML MIME entities are allowed to register with a '+xml' suffix.

Besides the changes described above, the change controller has been changed to be the World Wide Web Consortium (W3C) 🎉

4.3. Registration Guidelines for XML-Based Media Types Not Using '+xml' 🧁

Registrations for new XML-based media types that do not use the '+xml' suffix SHOULD, when specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of application/xml as specified in RFC 7303".

Defining the charset parameter is RECOMMENDED, since XML processors can use this info to determine authoritatively the character encoding of the XML MIME entity when there's no BOM. If there are reasons not to follow this advice, they SHOULD be included as part of the registration. As shown above, two such reasons are "UTF-8 only" or "UTF-8 or UTF-16 only" 💜

These registrations SHOULD specify that the XML-based media type being registered has all of the security considerations described in this spec, plus any additional considerations specific to that media type. 🔐

These registrations SHOULD also reference this spec when specifying magic numbers, base URIs, and use of the BOM.

These registrations MAY reference the application/xml registration in this document when specifying interoperability and fragment identifier considerations, if those considerations aren't overridden by issues specific to that media type 🦋

5. Fragment Identifiers 🧚

Uniform Resource Identifiers (URIs) can contain fragment identifiers (see Section 3.5 of [RFC3986]). Specifying the syntax and semantics of fragment identifiers is handed off by [RFC3986] to the appropriate media type registration 💅

The syntax and semantics of fragment identifiers for the XML media types defined in this spec are based on the [XPointerFramework] W3C Recommendation. It allows simple names and more complex constructions based on named schemes ✨ When the syntax of a fragment identifier part of any URI or Internationalized Resource Identifier (IRI) ([RFC3987]) with a retrieved media type governed by this spec conforms to the syntax specified in [XPointerFramework], conforming applications MUST interpret such fragment identifiers as designating whatever is specified by [XPointerFramework], together with any other specifications governing the XPointer schemes used in those identifiers that the applications support. Conforming applications MUST support the 'element' scheme as defined in [XPointerElement], but they don't need to support other schemes 🎀

If an XPointer error is reported while trying to process the part, this spec doesn't define an interpretation for that part 🙈

A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Generic processors of XML MIME entities SHOULD NOT implement unregistered XPointer schemes ([XPtrRegPolicy] describes the requirements and procedures for registering schemes) 🚫

See Section 4.2 for additional requirements that apply when an XML-based media type follows the '+xml' naming convention.

If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, that type SHOULD NOT follow the '+xml' naming convention 🫠

When a URI has a fragment identifier, it is encoded using a limited subset of the repertoire of US-ASCII characters. See [XPointerFramework] for details 🌈

6. The Base URI 🍓

An XML MIME entity of type application/xml, text/xml, application/xml-external-parsed-entity, or text/xml-external-parsed-entity MAY use the xml:base attribute, as described in [XMLBase], to embed a base URI in that entity for use in resolving relative URI references (see Section 5.1 of [RFC3986]) 🔗

Note that the base URI itself might be embedded in a different MIME entity, since the default value for the xml:base attribute can be specified in an external DTD subset or external parameter entity. Since conforming XML processors don't always need to read and process external entities, the effect of such an external default is uncertain. Therefore, its use is NOT RECOMMENDED 🙅‍♀️

7. XML Versions ✨

okay so application/xml, application/xml-external-parsed-entity, application/xml-dtd, text/xml, and text/xml-external-parsed-entity are all meant to be used with [XML] 💅. In every example where version="1.0" shows up, version="1.1" might show up too 🦋, as long as the content actually conforms to [XML1.1] 🫶.

The normative requirement for XML documents and processors is to follow the requirements of [XML], Section 4.3.3 📜.

Except for minor clarifications, that section is basically the same from the first edition to the current (5th) edition of XML 1.0, and from XML 1.1 first or second edition [XML1.1] 🌸. So references here to [XML] can be read as any existing version or edition of XML, or any later edition or version that makes no incompatible changes to that section ✨.

Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions or editions of XML to be used 🎀.

8. Examples ✨

This section is non-normative 🙈. Heads up though: all the [RFC2119] language in here just repeats or sums up the consequences of normative statements already made above 💅. It has no independent normative force, so it doesn't show up in uppercase 🍓.

The examples below show the MIME Content-Type header, including the charset parameter if there is one, plus the XML declaration or Text declaration (which includes the encoding declaration) inside the XML MIME entity 🧚. For UTF-16 examples, the Byte Order Mark character, properly UTF-16 encoded, is written as "{BOM}", and the XML or Text declaration is assumed to be at the very start of the XML MIME entity, right after the encoded BOM 🔥. Other MIME headers can be there too, and the XML MIME entity will normally hold other data besides the XML declaration. The examples just focus on the Content-Type header and the encoding declaration so it's easier to see 👑.

Even though they show a content type of 'application/xml', all the examples below apply to all five media types declared below in Section 9, plus any media types declared with the '+xml' convention. The exception is the examples involving the charset parameter for any of those media types that don't enable its use 💖. See the XML MIME entities table (Section 4.1, Paragraph 1) for which types fit which kinds of XML MIME entity 🌈.

8.1. UTF-8 Charset

Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>

or

<?xml version="1.0"?>

UTF-8 is the recommended encoding for all the media types defined in this specification 🫶. Since the charset parameter is there and there's no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-8 encoded 💜.

If it's sent over a 7-bit transport (like SMTP [RFC5321]), a UTF-8 XML MIME entity generally must use a content-transfer-encoding of either quoted-printable or base64 😭. Over an 8-bit clean transport (like 8BITMIME ESMTP or NNTP), or a binary clean transport (like BINARY ESMTP or HTTP), no content-transfer-encoding is necessary. With HTTP it's not even possible 💅.

8.2. UTF-16 Charset

Content-Type: application/xml; charset=utf-16

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

or

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

For the three application/media types defined above, if they're sent over a 7-bit transport (like SMTP) or an 8-bit clean transport (like 8BITMIME ESMTP or NNTP), the XML MIME entity must be encoded in quoted-printable or base64 🍓. For a binary clean transport (like BINARY ESMTP or HTTP), no content-transfer-encoding is necessary, and with HTTP it isn't even possible 🦋.

As described in [RFC2781], the UTF-16 family must not be used with media types under the top-level type "text" except over HTTP or HTTPS (see Section A.2 of HTTP [RFC7231] for details) 🙅‍♀️. So one of the two text/media types defined above can only be used with this example when the XML MIME entity goes over HTTP or HTTPS 🌸. Those use a MIME-like mechanism, are binary-clean, don't do CR and LF transformations, and allow NUL octets ✨. Since HTTP is binary clean, no content-transfer-encoding is necessary (or even possible) 💖.

8.3. Omitted Charset and 8-Bit MIME Entity

Content-Type: application/xml

<?xml version="1.0" encoding="iso-8859-1"?>

Since there's no charset parameter in the Content-Type header and no overriding BOM, conformant XML processors must treat "iso-8859-1" as the authoritative encoding 👑. Conformant XML-unaware MIME processors should make no assumptions about the character encoding of the XML MIME entity 🧚.

8.4. Omitted Charset and 16-Bit MIME Entity

Content-Type: application/xml

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

or

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

This example shows a 16-bit MIME entity with no charset parameter 🌈. But since there's a BOM, conformant processors must treat the entity as UTF-16 encoded 🔥.

Leaving out the charset parameter is not recommended with media types under the top-level type "application" when they're used over transports other than HTTP or HTTPS 💀. Media types under the top-level type "text" should not be used for 16-bit MIME over transports other than HTTP or HTTPS (see the discussion above in Section 8.2, Paragraph 7) 🙈.

8.5. Omitted Charset, No Internal Encoding Declaration

Content-Type: application/xml

<?xml version='1.0'?>

In this one, the charset parameter is left out, there's no internal encoding declaration, and there's no BOM 🫶. Since there's no BOM or charset parameter, the XML processor follows the requirements in Section 4.3.3, and can optionally apply the mechanism described in Appendix F (which is non-normative) of [XML] to work out an encoding of UTF-8 ✨. Even though the XML MIME entity has no encoding declaration, as long as the encoding actually is UTF-8, it's a conforming XML MIME entity 💅.

A conformant XML-unaware MIME processor should make no assumptions about the character encoding of the XML MIME entity 🌸.

For transport-related issues with UTF-8 XML MIME entities, see Section 8.1 🦋.

8.6. UTF-16BE Charset

Content-Type: application/xml; charset=utf-16be

<?xml version='1.0' encoding='utf-16be'?>

Notice that there's no BOM, because this encoding doesn't use one 👀. Since the charset parameter is provided and there's no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-16BE encoded 💜.

See also the additional considerations in the UTF-16 example in Section 8.2 🍓.

8.7. Non-UTF Charset

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

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

This one shows a non-UTF character encoding (Hangul in this case, but it's meant to cover all non-UTF-family character encodings) 🇰🇷. Since the charset parameter is provided and there's no overriding BOM, conformant processors must treat the enclosed entity as encoded per RFC 1557 🧚.

ISO-2022-KR [RFC1557] was defined to use only 7 bits of data, so no content-transfer-encoding is necessary with any transport 🫶. For character sets that need 8 or more bits, the considerations discussed above (Sections 8.1 and 8.2) would apply 🔥.

8.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding Declaration

Content-Type: application/xml; charset=iso-8859-1

<?xml version="1.0" encoding="utf-8"?>
Okay, this one is the "wait, which is it?" example 🙈. The charset parameter is in the Content-Type header, there's no BOM, and the charset parameter doesn't match the XML encoding declaration. Even so, conformant MIME and XML processors will still interoperate 💅. Since the charset parameter is authoritative when there's no BOM, conformant processors will treat the enclosed entity as iso-8859-1 encoded. So the "UTF-8" encoding declaration gets ignored 💀.

Conformant processors that generate XML MIME entities must not label conflicting character encoding information between the MIME Content-Type and the XML declaration, unless they have definitive information about the actual encoding (for example, from systematic transcoding) 🌈. Honestly, the addition by servers of an explicit, site-wide charset parameter default has frequently led to interoperability problems for XML documents 😭.

8.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM

Content-Type: application/xml; charset=iso-8859-1

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

Here the charset parameter is in the Content-Type header, but there's also a BOM, so MIME and XML processors may not interoperate 🥺. Since the BOM is authoritative for conformant XML processors, they'll treat the enclosed entity as UTF-16 encoded, and the "iso-8859-1" charset parameter gets ignored 👑. XML-unaware MIME processors, on the other hand, might not know about the BOM and so could treat the entity as iso-8859-1 encoded 🌸.

Conformant processors that generate XML MIME entities must not label conflicting character encoding information between the MIME Content-Type and an entity-initial BOM 🔥.

9. IANA Considerations ✨

9.1. application/xml Registration

Type name: application 🎀

Subtype name: xml

Required parameters: none

Optional parameters: charset, see Section 3 💅

Encoding considerations: okay this one is a lot, so bear with me 🫶 Depending on which character encoding you use, XML MIME entities can be 7bit, 8bit, or binary data [RFC6838]. On 7-bit transports, 7bit data (think US-ASCII) doesn't need a content-transfer-encoding, but 8bit or binary data (like UTF-8 or UTF-16) MUST be content-transfer-encoded in quoted-printable or base64. On 8-bit clean transports (like 8BITMIME ESMTP [RFC6152] or NNTP [RFC3977]), 7bit or 8bit data (like US-ASCII or UTF-8) doesn't need the encoding, but binary data, like a UTF-16 encoding, MUST be content-transfer-encoded in base64. On binary clean transports (like BINARY ESMTP [RFC3030] or HTTP [RFC7230]), no content-transfer-encoding is needed for 7bit, 8bit, or binary data, and for HTTP it's not even possible 🙈

Security considerations: see Section 10 🔒

Interoperability considerations: XML has been proven to be interoperable across both generic and task-specific apps, and for importing and exporting between lots of XML authoring and editing tools ✨ Validating processors give you the most interoperability, because they have to handle every single aspect of XML. A non-validating processor may be more efficient, but it might not handle all aspects. For more info, check out Section 2.9 "Standalone Document Declaration" and Section 5 "Conformance" of [XML].

Honestly, character set issues have been the biggest source of interoperability problems 😭 Using UTF-8, and paying careful attention to the guidelines in Section 3, are the best ways to dodge that drama.

Published specification: Extensible Markup Language (XML) 1.0 (Fifth Edition) [XML] or subsequent editions or versions thereof 📚

Applications that use this media type: XML is device, platform, and vendor neutral, and it's supported by generic and task-specific apps and a wide range of generic XML tools (editors, parsers, Web agents, ...). It's giving main character energy 👑

Additional information:

  • Magic number(s): None. Nothing can be counted on to always be there, but XML MIME entities in ASCII-compatible character sets (including UTF-8) often begin with the hexadecimal bytes 3C 3F 78 6D 6C ("<?xml"). Entities in UTF-16 often begin with either FE FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00, which is the BOM followed by "<?xml". For more info, see Appendix F of [XML] 🧚
  • File extension(s): .xml
  • Macintosh File Type Code(s): "TEXT"
  • Base URI: see Section 6

Person and email address for further information: see Authors' Addresses section

Intended usage: COMMON

Author: see Authors' Addresses section

Change controller: the XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303 🌸

9.2. text/xml Registration

The registration info for text/xml is basically the same as the application/xml one above (Section 9.1), except the "Type name" is "text" 💖

9.3. application/xml-external-parsed-entity Registration

Type name: application

Subtype name: xml-external-parsed-entity

Required parameters: none

Optional parameters: charset, see Section 3

Encoding considerations: same as for application/xml (Section 9.1) 🫶

Security considerations: see Section 10 🔒

Interoperability considerations: XML external parsed entities are just as interoperable as XML documents ✨ They have a less tightly constrained structure, though, so XML documents need to reference them for XML processors to handle them properly. Similarly, XML documents can't be reliably used as external parsed entities, because external parsed entities are prohibited from having standalone document declarations or DTDs 🙅‍♀️ Giving XML external parsed entities their own content type makes interoperability better for both XML documents and XML external parsed entities.

Published specification: same as for application/xml (Section 9.1)

Applications which use this media type: same as for application/xml (Section 9.1)

Additional information:

  • Magic number(s): same as for application/xml (Section 9.1)
  • File extension(s): .xml or .ent
  • Macintosh File Type Code(s): "TEXT"
  • Base URI: see Section 6

Person and email address for further information: see Authors' Addresses section.

Intended usage: COMMON

Author: see Authors' Addresses section.

Change controller: the XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303 🌈

9.4. text/xml-external-parsed-entity Registration

The registration info for text/xml-external-parsed-entity is basically the same as the application/xml-external-parsed-entity one above (Section 9.3), except the "Type name" is "text" 🦋

9.5. application/xml-dtd Registration

Type name: application

Subtype name: xml-dtd

Required parameters: none

Optional parameters: charset, see Section 3

Encoding considerations: same as for application/xml (Section 9.1) 💜

Security considerations: see Section 10 🔒

Interoperability considerations: XML DTDs have been proven to be interoperable by DTD authoring tools and XML validators, among others 🍓

Published specification: same as for application/xml (Section 9.1)

Applications which use this media type: DTD authoring tools handle external DTD subsets as well as external parameter entities. XML validators may also access external DTD subsets and external parameter entities 🧠

Additional information:

  • Magic number(s): same as for application/xml (Section 9.1)
  • File extension(s): .dtd or .mod
  • Macintosh File Type Code(s): "TEXT"

Person and email address for further information: see Authors' Addresses section.

Intended usage: COMMON

Author: see Authors' Addresses section.

Change controller: the XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303 💅

9.6. The '+xml' Naming Convention for XML-Based Media Types

This section supersedes the earlier registration of the '+xml' suffix [RFC6839] 👑

This specification recommends using the '+xml' naming convention for identifying XML-based media types ✨ That fits the recognition of structured syntax name suffixes in [RFC6838]. It lets generic XML processors and technologies work on a wide variety of XML document types at minimal cost, using the existing frameworks for media type registration. Iconic 🫶

For guidance on when and how to register a '+xml'-based media subtype, see Section 4.2. For registering a media subtype for XML but not using '+xml', see Section 4.3.

9.6.1. The '+xml' Structured Syntax Suffix Registration 🎀

Name: Extensible Markup Language (XML)

+suffix: +xml

Reference: RFC 7303

Encoding considerations: same as Section 9.1

Fragment identifier considerations: okay, the rules for fragment identifiers are the spicy part 🌶️ Registrations that use this '+xml' convention MUST also reference this document, specifically Section 5, when specifying fragment identifier syntax and semantics. They MAY restrict the syntax to a specified subset of schemes, except that they MUST NOT disallow barenames or 'element' scheme pointers. They MAY further require support for other registered schemes. They also MAY add extra syntax (which MUST NOT overlap with [XPointerFramework] syntax) along with associated semantics, and they MAY add extra semantics for barename XPointers. Those extra semantics only apply when this document doesn't define an interpretation, as provided for in Section 5.

In practice, these constraints mean that for a fragment identifier addressed to an instance of a specific xxx/yyy+xml type, there are three cases 💖
  • For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier resolves per the rules specified there, process it as specified there.
  • For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier does not resolve per the rules specified there, process it as specified in xxx/yyy+xml.
  • For fragment identifiers not matching the syntax defined in [XPointerFramework], process it as specified in xxx/yyy+xml. A fragment identifier like xywh=160,120,320,240, defined in [MediaFrags], which might be used in a URI for an XML-encoded image, would fall into this category 🖼️

Interoperability considerations: same as Section 9.1. See above, and also Section 3, for guidelines on using the charset parameter 🧚

Security considerations: see Section 10 🔒

Contact: see Authors' Addresses section

Author: see Authors' Addresses section

Change controller: the XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303 🌈

10. Security Considerations 🛡️

Okay bestie, this section is seriously important, so grab a snack and pay attention 🍓. XML MIME entities carry information that the recipient may parse and process further. These entities may contain explicit system-level commands, and recipients may let them run while processing the data. If a recipient application executes arbitrary command strings from inside XML MIME entities, it may be at risk 😭.

Lowkey the scariest part: running arbitrary commands from inside a document is a whole vibe you do NOT want. 💀

Anything stored outside the user's direct control can be a source of insecurity, and that includes CSS style sheets, XSL transformations, XML-entity declarations, and DTDs. The danger can be obvious or super sneaky 🙈. For example, a tiny "whiteout attack" change to a "master" style sheet could make words in critical spots vanish from user documents. The user document and the style sheet it references wouldn't even be touched directly. So the security of any XML document depends heavily on every document it references, all the way down the chain 🔗✨.

The XML-entity lists and DTDs for XHTML 1.0 [XHTML] are likely to be a widely exploited set of resources. Tons of developers will use and trust them, and most of them won't know much about the security of the W3C's servers or any similarly trusted repository 🫣.

The simplest attack is adding declarations that break validation. Extra declarations in a list of character XML-entities can totally "break the contract" that documents rely on 📜💅. A tiny change that causes a fatal error in a DTD could halt XML processing on a huge scale. Extra declarations are fairly obvious, but sneakier tricks, like changing attributes from optional to required, can be really hard to track down 🕵️‍♀️. Perhaps the most dangerous option for attackers is redefining default values for attributes, especially when external DTD subsets, external parameter entities, or other externally specified defaulting are involved. For example, if developers have relied on defaulted attributes for security, a relatively small change might expose a massive amount of information 😱🔥.

Beyond structural stuff, there's also "XML-entity spoofing," which can insert text into documents. That can vandalize content or send an unintended message 🎭. Because XML permits multiple XML-entity declarations and the first declaration takes precedence, malicious content can be inserted wherever an XML-entity reference is used. One example is inserting the full text of Winnie the Pooh in place of every occurrence of &mdash; 🍯🧸.

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

XML may also share some security concerns with plain text. Like plain text, XML can contain escape sequences that, when displayed, could change the display processor environment in ways that hurt later operations 😵. The possible effects include, but aren't limited to, locking the keyboard, changing display parameters so later text is unreadable, or even changing display parameters to deliberately obscure or distort later material so its meaning is lost or altered. Display processors SHOULD either filter such material from displayed text or make sure to reset all important settings after a display operation is complete 🧹✨.

With some terminal devices, sending particular character sequences to the display processor can change the output of later key presses 😳. If that's possible, displaying a text object containing such sequences could reprogram keys to do something illicit or dangerous when the user 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 💀. That's why the ability to program keys SHOULD be blocked, either by filtering or by disabling the ability to program keys entirely 🔒.

Also, XML documents can use what XML calls "[XML-]entity references" to build repeated expansions of text. Recursive expansions are prohibited by [XML], and XML processors are required to detect them 🔁. But even non-recursive expansions can strain the finite computing resources of machines if they're performed many times. For example, imagine XML-entity A consists of 100 copies of XML-entity B, which consists of 100 copies of XML-entity C, and so on. Yikes, that adds up fast 📈🫠.

11. References 📚

11.1. Normative References

Here's the full reference list, copied exactly as the original spells it out 👇

[IANA-CHARSETS]
           IANA, "Character Sets Registry", 2013,
           <http://www.iana.org/assignments/character-sets/>.

[RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part One: Format of Internet Message
           Bodies", RFC 2045, November 1996.

[RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046,
           November 1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
           10646", RFC 2781, February 2000.

[RFC2978]  Freed, N. and J. Postel, "IANA Charset Registration
           Procedures", BCP 19, RFC 2978, October 2000.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66, RFC
           3986, January 2005.

[RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
           Identifiers (IRIs)", RFC 3987, January 2005.

[RFC6657]  Melnikov, A. and J. Reschke, "Update to MIME regarding
           "charset" Parameter Handling in Textual Media Types", RFC
           6657, July 2012.

[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
           Specifications and Registration Procedures", BCP 13, RFC
           6838, January 2013.

[RFC6839]  Hansen, T. and A. Melnikov, "Additional Media Type
           Structured Syntax Suffixes", RFC 6839, January 2013.

[RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
           (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
           2014.

[RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
           (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

[UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
           7.0.0", (Mountain View, CA: The Unicode Consortium, 2014
           ISBN 978-1-936213-09-2),
           <http://www.unicode.org/versions/Unicode7.0.0/>.

[XML]      Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
           F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
           Edition)", W3C Recommendation REC-xml, November 2008,
           <http://www.w3.org/TR/2008/REC-xml-20081126/>.

           Latest version available at <http://www.w3.org/TR/xml>.

[XML1.1]   Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
           Yergeau, F., and J. Cowan, "Extensible Markup Language
           (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml,
           September 2006,
           <http://www.w3.org/TR/2006/REC-xml11-20060816/>.

           Latest version available at <http://www.w3.org/TR/xml11>.

[XMLBase]  Marsh, J. and R. Tobin, "XML Base (Second Edition)", W3C
           Recommendation REC-xmlbase-20090128, January 2009,
           <http://www.w3.org/TR/2009/REC-xmlbase-20090128/>.

           Latest version available at
           <http://www.w3.org/TR/xmlbase>.

[XPointerElement]
           Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
           element() Scheme", W3C Recommendation REC-XPointer-
           Element, March 2003,
           <http://www.w3.org/TR/2003/REC-xptr-element-20030325/>.

           Latest version available at
           <http://www.w3.org/TR/xptr-element>.

[XPointerFramework]
           Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
           Framework", W3C Recommendation REC-XPointer-Framework,
           March 2003,
           <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.

           Latest version available at
           <http://www.w3.org/TR/xptr-framework>.

[XPtrReg]  Hazael-Massieux, D., "XPointer Registry", 2005,
           <http://www.w3.org/2005/04/xpointer-schemes/>.

[XPtrRegPolicy]
           Hazael-Massieux, D., "XPointer Scheme Name Registry
           Policy", 2005,
           <http://www.w3.org/2005/04/xpointer-policy.html>.

11.2. Informative References 🦋

[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

[AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", W3C Recommendation REC-webarch-20041215, December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/.

Latest version available at http://www.w3.org/TR/webarch.

[FYN] Mendelsohn, N., "The Self-Describing Web", W3C TAG Finding selfDescribingDocuments-2009-02-07, February 2009, http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2009-02-07.html.

Latest version available at http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

[Infoset] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C Recommendation REC-xml-infoset-20040204, Febuary 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.

Latest version available at http://www.w3.org/TR/xml-infoset/.

[MediaFrags] Troncy, R., Mannens, E., Pfeiffer, S., and D. Van Deursen, "Media Fragments URI 1.0 (basic)", W3C Recommendation media-frags, September 2012, http://www.w3.org/TR/2012/REC-media-frags-20120925/.

Latest version available at http://www.w3.org/TR/media-frags.

[RFC1557] Choi, U., Chon, K., and H. Park, "Korean Character Encoding for Internet Messages", RFC 1557, December 1993.

[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

[Sivonen] Sivonen, H. and others, "Mozilla bug: Remove support for UTF-32 per HTML5 spec", October 2011, https://bugzilla.mozilla.org/show_bug.cgi?id=604317#c6.

[TAGMIME] Bray, T., Ed., "Internet Media Type registration, consistency of use", April 2004, http://www.w3.org/2001/tag/2004/0430-mime.

[XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", W3C Recommendation xhtml1, December 1999, http://www.w3.org/TR/2000/REC-xhtml1-20000126/.

Latest version available at http://www.w3.org/TR/xhtml1.

[XMLModel] Grosso, P. and J. Kosek, "Associating Schemas with XML documents 1.0 (Third Edition)", W3C Working Group Note NOTE-xml-model-20121009, October 2012, http://www.w3.org/TR/2012/NOTE-xml-model-20121009/.

Latest version available at http://www.w3.org/TR/xml-model.

[XMLNS10] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation REC-xml-names-20091208, December 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/.

Latest version available at http://www.w3.org/TR/xml-names.

[XMLNS11] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.1 (Second Edition)", W3C Recommendation REC-xml-names11-20060816, August 2006, http://www.w3.org/TR/2006/REC-xml-names11-20060816/.

Latest version available at http://www.w3.org/TR/xml-names11.

[XMLSS] Clark, J., Pieters, S., and H. Thompson, "Associating Style Sheets with XML documents 1.0 (Second Edition)", W3C Recommendation REC-xml-stylesheet-20101028, October 2010, http://www.w3.org/TR/2010/REC-xml-stylesheet-20101028/.

Latest version available at http://www.w3.org/TR/xml-stylesheet.

[XMLid] Marsh, J., Veillard, D., and N. Walsh, "xml:id Version 1.0", W3C Recommendation REC-xml-id-20050909, September 2005, http://www.w3.org/TR/2005/REC-xml-id-20050909/.

Latest version available at http://www.w3.org/TR/xml-id.

Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 🌸

[RFC3023] has a detailed discussion of the (at the time) novel use of a suffix, a practice that has since become widespread 💅. If you're curious about the history, go check [RFC3023], Appendix A. ✨

The registration process for new '+xml' media types is described in [RFC6838]. 🧚

Appendix B. Core XML Specifications 💜

Okay, so these specifications each explain key parts of XML document semantics 🤓:

  • Namespaces in XML 1.0 [XMLNS10]/Namespaces in XML 1.1 [XMLNS11]
  • XML Information Set [Infoset]
  • xml:id [XMLid]
  • XML Base [XMLBase]
  • Associating Style Sheets with XML documents [XMLSS]
  • Associating Schemas with XML documents [XMLModel]

The W3C Technical Architecture group also made two documents that are super relevant 🔥:

  • The Self-Describing Web [FYN] discusses the overall principles of how document semantics are determined on the Web.
  • Architecture of the World Wide Web, Volume One [AWWW], Section 4.5.4, discusses the specific role of XML Namespace documents in this process.

Appendix C. Operational Considerations 🍓

This section gives an informal summary of the major operational considerations that come up when you exchange XML MIME entities over a network 🌐.

C.1. General Considerations

The mix of XML-aware and XML-unaware agents handling XML MIME entities can compromise interoperability 😬. Generic transcoding proxies are a particular risk here. Detailed advice about handling BOMs when transcoding is in Section 3.3.

This specification requires XML consumers to treat BOMs as authoritative. In principle, that's a backwards-incompatibility. In practice, though, serious interoperability issues already exist when BOMs are used 💀. Making BOMs authoritative, together with deprecating the UTF-32 encoding form and requiring an XML encoding declaration in certain cases (Section 3.1), is meant to improve in-practice interoperability as much as possible over time ✨.

This specification establishes Section 5 as the basis for interpreting URIs for XML MIME entities that include fragment identifiers. It mandates support only for shorthand ("simple name") and 'element'-scheme fragments, and it deprecates support for unregistered XPointer schemes by XML MIME entity processors. So URIs will interoperate best if they use only simple names and 'element'-scheme fragment identifiers 🎀. Registered schemes vary widely in how much support you'll find in generic tools, so XPointer scheme authors can only expect generic tool support if they register their schemes 🦋.

C.2. Considerations for Producers

Interoperability for all XML MIME entities is maximized by using UTF-8, without a BOM 👑. When UTF-8 is _not_ used, a charset parameter and/or a BOM improves interoperability, especially when XML-unaware consumers may be involved 🫶.

In the very rare case where the substantive content of a non-UNICODE XML external parsed entity begins with the hexadecimal octet sequences 0xFE 0xFF, 0xFF 0xFE or 0xEF 0xBB 0xBF, including an XML text declaration will forestall the mistaken detection of a BOM 🙈.

Using UTF-32 for XML MIME entities puts interoperability at very high risk 😭.

Web-server configurations that supply default charset parameters risk misrepresenting XML MIME entities. Allowing users to control the value of charset parameters improves interoperability 💖.

Supplying a mistaken charset parameter is worse than supplying none at all. Generic processors such as transcoders, when processing based on a mistaken charset parameter, are likely to produce arbitrarily bogus results if they don't fail altogether, and the original can't be recovered from those results 💀.

C.3. Considerations for Consumers

Consumers of XML MIME entities can maximize interoperability by:

  1. Taking a BOM as authoritative if it is present in an XML MIME entity;
  2. In the absence of a BOM, taking a charset parameter as authoritative if it is present.

Assuming a default character encoding in the absence of a charset parameter harms interoperability 🥲.

Although support for UTF-32 is not required by [XML] itself, and this specification deprecates its use, consumers that check for UTF-32 BOMs can avoid mistakenly processing UTF-32 entities as (invalid) UTF-16 entities 🧠.

Appendix D. Changes from RFC 3023 🌈

There are numerous and significant differences between this specification and [RFC3023], which it obsoletes 😤. This appendix covers only the major differences, so here they are:

  • XPointer ([XPointerFramework] and [XPointerElement]) has been added as fragment identifier syntax for all the XML media types, and the XPointer Registry ([XPtrReg]) mentioned
  • [XMLBase] has been added as a mechanism for specifying base URIs
  • The language regarding character sets was updated to correspond to the W3C TAG finding Internet Media Type registration, consistency of use [TAGMIME]
  • Priority is now given to a BOM if present
  • Many references are updated, and the existence of XML 1.1 and relevance of this specification to it acknowledged
  • A number of justifications and contextualizations that were appropriate when XML was new have been removed, including the whole of the original Appendix A

Appendix E. Acknowledgements 🫶

MURATA Makoto (FAMILY Given) and Alexey Melnikov made early and important contributions to the effort to revise [RFC3023] 👑.

This specification reflects the input of numerous participants to the ietf-xml-mime@imc.org, xml-mime@ietf.org, and apps-discuss@ietf.org mailing lists. Any errors are the responsibility of the authors. Special thanks to:

Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed, Yaron Goland, Bjoern Hoehrmann, Rick Jelliffe, Murray S. Kucherawy, Larry Masinter, David Megginson, S. Moonesamy, Keith Moore, Chris Newman, Gavin Nicol, Julian Reschke, Marshall Rose, Jim Whitehead, Erik Wilde, and participants of the XML activity and the TAG at the W3C 🌟.

Jim Whitehead and Simon St. Laurent were editors of [RFC2376] and [RFC3023], respectively 💖.

Authors' Addresses 🎀

okay bestie, this is the end of the doc!! 🦋 here's where you can find the two people who wrote it 💅 Henry is at the University of Edinburgh, and Chris is at the World Wide Web Consortium in Sophia Antipolis 🌸

Henry S. Thompson
University of Edinburgh

EMail: ht@inf.ed.ac.uk
URI:   http://www.ltg.ed.ac.uk/~ht/


Chris Lilley
World Wide Web Consortium
2004, Route des Lucioles - B.P. 93 06902
Sophia Antipolis Cedex
France

EMail: chris@w3.org
URI:   http://www.w3.org/People/chris/

and that's the whole RFC, periodt 🫶✨

📦 where this page comes from