Declaring XML Subtype Media Types with +xml

Specialized XML vocabularies declare subtype media types by appending the +xml structured syntax suffix to a designated subtype name, enabling generic XML parsers and specialized applications to correctly recognize and process the data. This guide covers the standards, naming conventions, encoding specifications, and registration rules defined by RFC 7303 and RFC 6838 for defining custom XML media types such as image/svg+xml and application/soap+xml.

The +xml Structured Syntax Suffix

To indicate that a specialized format is built on XML, the media subtype must end with the +xml suffix. This convention allows generic tools (like generic XML validators, syntax highlighters, and security filters) to recognize the payload as XML without needing prior knowledge of the specific vocabulary. At the same time, the full media type name informs specialized software (like SVG renderers or SOAP endpoints) to apply vocabulary-specific processing rules.

Selecting the Top-Level Media Type

Choose the top-level type based on the primary function and presentation of the data:

• application/: Use for general data interchange, web services, and formats processed by applications (for example, application/soap+xml or application/atom+xml).
• image/: Use when the primary purpose is visual image rendering (for example, image/svg+xml).
• text/: Historically used for human-readable documents, but generally discouraged for modern XML vocabularies in favor of application/ due to legacy charset handling issues.
• model/ or audio/: Used rarely, only when the XML specifically represents 3D models or audio data structures.

Character Encoding and Charset Handling

According to RFC 7303, XML media types should align with standard XML encoding rules:

1. Rely on XML Declarations: It is recommended to let the XML document manage its own encoding using the <?xml version="1.0" encoding="..."?> declaration or standard UTF-8/UTF-16 auto-detection.
2. The charset Parameter: If you declare an optional charset parameter in the media type (e.g., application/example+xml; charset=utf-8), its value must match the actual encoding of the XML document. If there is a mismatch between an external HTTP header charset and the internal XML encoding declaration, RFC 7303 specifies how parsers should resolve the conflict, but avoiding conflicting declarations entirely is best practice.

Fragment Identifiers and Base URIs

When specifying an XML-based media type, you must define:

• Fragment Identifier Semantics: Describe how URI fragment identifiers (#identifier) resolve within the document. Typically, this refers to XML ID attributes, XPointer frameworks, or vocabulary-specific addressing schemes (such as view targets in SVG).
• Base URI Resolution: Define how relative URIs within the payload are resolved, usually conforming to the xml:base specification or RFC 3986.

Security Considerations

The media type definition must document XML-specific security risks, including:

• XML External Entity (XXE) Injection: Risks associated with resolving external DTDs or external entities.
• Denial of Service (DoS): Susceptibility to entity expansion attacks (such as the Billion Laughs attack) or large payload processing.
• Executable Content: Risks if the vocabulary allows embedded scripts (e.g., <script> elements in SVG).

IANA Registration

To formalize the media type, submit a registration template to the Internet Assigned Numbers Authority (IANA) following RFC 6838 procedures:

• Standards Tree: For specifications produced by recognized standards bodies (e.g., application/soap+xml by the W3C).
• Vendor Tree (vnd.): For proprietary or company-specific vocabularies (e.g., application/vnd.company.format+xml).
• Personal Tree (prs.): For experimental or personal projects (e.g., application/prs.name.format+xml).

The registration must include the type name, subtype name with +xml, required/optional parameters, encoding considerations, security considerations, and references to the schema or vocabulary specification.