application/xml and application/foo+xml SHOULD be treated as completely independent media types. The '+xml' suffix carries no extra semantics for MIME processors unaware of XML, so there is no implied inheritance or compatibility relationship between them.

New XML-specific MIME types were created rather than reusing text/sgml or application/sgml for three reasons: many XML processors cannot handle SGML's larger feature set; SGML processors may not handle XML's technical corrigenda; and the SGML type definitions include SGML-bctf and SGML-boot parameters that are irrelevant and ambiguous for XML.

The charset parameter is authoritative for text/xml (and overrides any internal XML encoding declaration) because some MIME engines transcode text/* bodies without examining content, because text/xml must fall back gracefully to text/plain behavior, and because RFC 2130 recommends the 'charset' parameter as the standard specification scheme.

The '+xml' suffix was chosen over alternatives such as a new subtree, a new top-level type, content sniffing, or MIME parameters because it works within existing MIME registration trees, requires no changes to sending agents, and allows both opaque and generic XML processing to coexist. The '+' character was selected because it semantically conveys that a type is simultaneously both the specific format and XML.

The UTF-16 family of charsets is not allowed for the top-level MIME type 'text' except over HTTP, which uses a MIME-like mechanism exempt from those restrictions. Entities encoded in UTF-16, UCS-4, or UTF-32 cannot be labeled as text/xml outside of HTTP.

http

There is a deliberate inconsistency between this specification and HTTP/1.1: text/xml defaults to 'us-ascii' rather than HTTP's historical default of ISO-8859-1. US-ASCII was chosen as the intersection of UTF-8 and ISO-8859-1 and as a better internationalization baseline for a new format.

http

XML external parsed entities are prohibited from having standalone document declarations or DTDs, so XML documents cannot be reliably used as external parsed entities and vice versa. Identifying them with distinct content types (text/xml-external-parsed-entity, application/xml-external-parsed-entity) enhances interoperability.

Accept headers of the form 'Accept: */*+xml' MUST NOT be used in HTTP, because section 14.1 of HTTP/1.1 does not support this pattern.

http

application/xml and text/xml MUST NOT be used for external parameter entities, external DTD subsets, or external parsed entities unless the entity is also a well-formed document entity referenced as such.

Applications converting XML from 'utf-16' to a non-Unicode encoding MUST strip the BOM before conversion; when converting from another encoding into 'utf-16', the BOM MUST be added after conversion is complete. Conversions between 'utf-16' and 'utf-16be'/'utf-16le' MUST similarly strip or add the BOM.

For 7-bit MIME transports, data in UTF-8 MUST be encoded in quoted-printable or base64. For 8-bit clean transport, the UTF-16 family MUST be encoded in base64. For binary-clean transports such as HTTP, no content-transfer-encoding is necessary.

http

Gateways from HTTP to other MIME applications MUST transform XML MIME entities from text/xml; charset='utf-16' to application/xml; charset='utf-16', because CR/LF/NUL transformations in MIME applications would corrupt UTF-16 multi-octet characters.

http

If a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of 'us-ascii', even when transmitted via HTTP.

If an application/xml entity is received with the charset parameter omitted, conforming XML processors MUST follow the requirements in section 4.3.3 of the XML specification to determine the charset. MIME processors that are not XML processors SHOULD NOT assume a default charset.

Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type header and the XML encoding declaration inside the entity.

The use of the charset parameter is STRONGLY RECOMMENDED for all XML media types, since it allows XML processors to determine the charset authoritatively and supports charset-based content negotiation in HTTP.

http

Unless the received charset is UTF-8 or UTF-16, a recipient that strips the MIME header and stores the XML entity persistently SHOULD also persistently store the charset information, perhaps by embedding a correct XML encoding declaration within the entity.

When a new XML-based MIME media type is introduced, its name SHOULD end with '+xml' to allow generic XML processors to detect and process the entity. Media subtypes that do not represent XML MIME entities MUST NOT be registered with a '+xml' suffix.

registry

XML MIME entities in the charset 'utf-16' MUST begin with a Byte Order Mark (BOM). Entities in 'utf-16le' or 'utf-16be' MUST NOT begin with the BOM but SHOULD contain an encoding declaration.

application/xml-dtd is the media type for external DTD subsets and external parameter entities. Neither external DTD subsets nor external parameter entities parse as XML documents, requiring a dedicated type distinct from text/xml and application/xml.

application/xml is a MIME media type for XML document entities, preferred when the XML content is unreadable by casual users. If the charset parameter is omitted, no charset information is conveyed via MIME, and conforming XML processors must follow XML specification section 4.3.3 to determine encoding.

text/xml-external-parsed-entity and application/xml-external-parsed-entity are media types for XML external parsed entities. External parsed entities cannot have standalone document declarations or DTDs, so they are not interchangeable with XML document entities and require distinct labeling.

text/xml is a MIME media type for XML document entities readable by casual users. The charset parameter is optional but strongly recommended; if omitted, the default charset is 'us-ascii'. MIME agents without explicit text/xml support fall back to treating it as text/plain.

json

The '+xml' suffix convention is a naming standard for MIME media types that represent XML MIME entities but are not labeled as text/xml or application/xml. Applications may match XML MIME entities by comparing the subtype to the pattern '*/*+xml', enabling generic XML processing across diverse document types.

This document registers five new IANA MIME media types: text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd. It also updates the RFC 2048 registration process to accommodate the '+xml' suffix convention for future XML-based media types.

registry

Any information stored outside the direct control of the user—including CSS stylesheets, XSL transformations, entity declarations, and DTDs—can be a source of insecurity. A 'whiteout attack' on a shared stylesheet, or redefinition of default attribute values in a DTD, can affect documents without modifying them directly. The security of any XML document depends recursively on all externally referenced documents.

security

'Entity spoofing' allows attackers to insert malicious text into documents by prepending a declaration that overrides an entity's value; because XML 1.0 permits multiple entity declarations and the first takes precedence, entity references can be redirected to attacker-controlled content.

security

Non-recursive entity expansions, though not prohibited, may cause resource exhaustion on finite computing systems if performed many times. Recursive expansions are prohibited by XML and must be detected by XML processors.

security

XML, like plain text, can contain escape sequences that alter the display processor environment (e.g., locking the keyboard, changing display parameters, or reprogramming keys). Display processors SHOULD filter such material or reset all settings after display; the ability to program keys SHOULD be blocked by filtering or disabling.

security

The Byte Order Mark (BOM) for UTF-16 XML MIME entities is the hexadecimal octet sequence 0xFE 0xFF (big-endian) or 0xFF 0xFE (little-endian). ASCII-compatible XML entities often begin with 0x3C 0x3F 0x78 0x6D 0x6C ('<?xml'). The BOM is an encoding signature and is not part of markup or character data.