BOM takes priority over the charset parameter because BOMs are in-band signals that survive transcoding less ambiguously than out-of-band MIME headers. Making BOMs authoritative, together with deprecating UTF-32 and requiring XML encoding declarations in certain cases, is intended to improve practical interoperability over time.

The '+xml' suffix convention is preferred over leaving XML-based types opaque because generic XML processing—by browsers, editors, and search engines—is useful in many situations that are difficult to predict ahead of time. Types wishing to remain opaque may deliberately omit the '+xml' suffix.

Consumers that do not support UTF-32 SHOULD nonetheless recognize UTF-32 signatures in order to give helpful error messages rather than treating them as invalid UTF-16.

The UTF-16 family MUST NOT be used with media types under the top-level type 'text' except over HTTP or HTTPS, since HTTP is binary-clean and does not perform CR/LF transformations or disallow NUL octets.

This specification aligns text/xml and text/xml-external-parsed-entity with their application/ counterparts for character encoding handling, eliminating the former distinction. The application/ variants remain preferred to avoid confusion based on the earlier distinction.

Applications converting XML from UTF-16 to another encoding MUST strip the BOM before conversion. When converting into UTF-16 (unlabelled or labelled 'utf-16'), the BOM MUST be added unless the original was UTF-8 with an existing BOM, which MUST be transcoded to the appropriate UTF-16 BOM.

Conforming applications MUST interpret XPointerFramework-conformant fragment identifiers for XML media types as specified by XPointerFramework and MUST support the 'element' scheme as defined in XPointerElement.

Generic processors of XML MIME entities SHOULD NOT implement unregistered XPointer schemes.

The media types application/xml and text/xml MUST NOT be used for external DTD subsets or external parameter entities; application/xml-dtd SHOULD be used instead.

The use of UTF-32 is NOT RECOMMENDED for XML MIME entities due to varying support and security concerns around its multiple potential serializations.

The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME entities to maximize interoperability across both XML-aware and XML-unaware agents.

UTF-16 XML MIME entities not labelled as 'utf-16le' or 'utf-16be' MUST begin with a BOM (U+FEFF). When encoded as utf-16le or utf-16be, the entity MUST NOT begin with a BOM but SHOULD contain an in-band XML encoding declaration.

When a charset parameter is omitted from an XML MIME entity, XML-aware consumers MUST follow XML Section 4.3.3; XML-unaware MIME consumers SHOULD NOT assume a default encoding.

When a new media type is introduced for an XML-based format, the name SHOULD end with '+xml' unless generic XML processing is in some way inappropriate. Only media subtypes that represent XML MIME entities are allowed to register with a '+xml' suffix.

registry

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 0xFE 0xFF, 0xFF 0xFE, or 0xEF 0xBB 0xBF, to avoid mistaken BOM detection.

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, and SHOULD remove or correct an incorrect encoding declaration.

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 particularly relevant for web server default charset configurations.

Five XML media types are defined: application/xml and text/xml for document entities, application/xml-external-parsed-entity and text/xml-external-parsed-entity for external parsed entities, and application/xml-dtd for external DTD subsets and external parameter entities. The application/ variants are preferred.

Fragment identifiers for XML media types are based on the XPointerFramework W3C Recommendation, supporting simple names and scheme-based constructions. The 'element' scheme is mandatory; other registered schemes are optional.

The '+xml' suffix is a naming convention for XML-based media types allowing generic XML tools (browsers, editors, search engines) to detect and process XML MIME entities. Applications may check for '+xml' by comparing the last four characters of the subtype.

registry

XML MIME entities of type application/xml, text/xml, application/xml-external-parsed-entity, or text/xml-external-parsed-entity MAY use the xml:base attribute to embed a base URI for resolving relative URI references.

Registers application/xml-dtd for XML external DTD subsets and external parameter entities, with file extensions .dtd or .mod.

registry

Registers application/xml-external-parsed-entity for XML external parsed entities, with file extensions .xml or .ent. This type must not be used for document entities with standalone declarations or DTDs.

registry

Registers text/xml as an alias for application/xml with identical registration information except for the top-level type name. text/xml is retained for compatibility but application/xml is preferred.

registry

Registers text/xml-external-parsed-entity as an alias for application/xml-external-parsed-entity with identical registration information except the top-level type name.

registry

Registers the media type application/xml with optional charset parameter, encoding considerations covering 7bit/8bit/binary transports, and W3C as change controller. This is the primary media type for XML document entities.

registry, json

Registers the '+xml' structured syntax suffix (superseding RFC 6839), with W3C as change controller. Registrations using '+xml' MUST reference Section 5 for fragment identifier syntax and MUST NOT disallow barenames or 'element' scheme pointers.

registry

Any information outside direct user control—including CSS stylesheets, XSL transformations, XML-entity declarations, and DTDs—can be an attack vector. A 'whiteout attack' on a shared stylesheet could silently alter the rendering of many documents without modifying them directly. Security of any XML document depends on all documents it recursively references.

security

Non-recursive XML entity expansion can exhaust computing resources even though recursive expansions are prohibited by XML. For example, entity A consisting of 100 copies of entity B, which consists of 100 copies of entity C, creates exponential expansion (the 'billion laughs' class of attack).

security

XML entity spoofing allows insertion of malicious content by exploiting that the first entity declaration takes precedence when multiple declarations exist. Attackers can substitute arbitrary text wherever an entity reference is used.

security

XML, like plain text, can contain escape sequences that adversely change display processor environments—locking keyboards, altering display parameters to obscure content, or programming terminal keys to perform illicit actions. Display processors SHOULD filter such material or reset settings after display operations.

security

Character encoding priority for XML MIME consumers: (1) a BOM (0xFE 0xFF, 0xFF 0xFE, or 0xEF 0xBB 0xBF) is authoritative if present; (2) in the absence of a BOM, the MIME charset parameter is authoritative if present; (3) otherwise the XML encoding declaration or UTF-8 default applies.

For 7-bit transports (e.g., SMTP), XML MIME entities with 8-bit or binary data (UTF-8, UTF-16) MUST use quoted-printable or base64 content-transfer-encoding. For binary-clean transports (e.g., HTTP), no content-transfer-encoding is necessary or possible.