Summary

  • RFC 2376 registered text/xml and application/xml, but an omitted charset meant opposite things: text/xml defaulted to US-ASCII even when the XML declaration or BOM said otherwise, while application/xml let an XML processor inspect the entity.
  • The episode separated a registry label, a received header, the body bytes, the decoder's authority rule and the application meaning. RFC 7303 later aligned the two media types and removed the old hidden default.

XML arrived with its own label

XML was designed to carry structure across systems that did not share software, hardware or local character conventions. Its declaration could name an encoding inside the entity, and its byte-order mark could distinguish important forms before the rest of the document was read. This was unusually useful self-description.

But a document crossing the Internet did not travel alone. HTTP, email and WebDAV carried it inside a MIME-style envelope. That envelope had a Content-Type, and the content type could carry a charset. The XML processor therefore received not one possible answer to “what do these bytes mean?” but several.

RFC 2376, published in July 1998, assigned the first general XML media types: text/xml and application/xml. The document was Informational rather than an Internet Standard. Its immediate job was modest and necessary. XML should not be mislabeled as SGML, and independent implementations needed common names for exchanging XML entities.

A presentation choice became an authority choice

The two registrations were meant to guide default handling. Every XML entity could use application/xml; an agent without XML support might simply offer it as an opaque file. text/xml signalled that the entity could be treated as plain text, which was convenient for display and inspection.

That convenience imported the rules of MIME's text top-level type. In RFC 2376, an explicit charset parameter was authoritative for both media types. A receiver was expected to decode according to the envelope even when the document carried an internal declaration.

The sharper difference appeared when the parameter was absent. For application/xml, absence meant that the MIME envelope supplied no encoding information. An XML-aware processor could use the BOM, the initial byte pattern and the XML declaration. An XML-unaware MIME processor was told not to guess.

For text/xml, absence meant US-ASCII. The rule held over HTTP. It also held when the bytes were UTF-8 or UTF-16 and when the entity visibly declared that encoding. The external omission did not leave authority vacant; it activated an inherited default.

The example was deliberately impossible

RFC 2376 made the conflict impossible to overlook. Its omitted-charset example placed a UTF-16 BOM and encoding="utf-16" inside an entity labeled only text/xml. The stated result was still US-ASCII. A conforming processor could not rescue the document by believing what the document said about itself.

The same bytes under application/xml followed a different path. With no charset parameter, the BOM could identify UTF-16. Without a BOM, the XML processor could examine the initial pattern and an internal encoding declaration. One top-level word in the media type changed which evidence counted.

This was not merely a parser curiosity. A gateway might strip a MIME header before storing the body. A transcoder might change the bytes and external charset without updating the internal declaration. A file copied out of its delivery context could therefore lose the label that had governed it. The persistent object was not always self-sufficient.

Self-description still needed a constitution

XML 1.0 recognised the problem. Its in-band declaration made encoding detection practical, but an internal label cannot settle a conflict with external metadata by itself. The XML specification left priority to the higher-level delivery protocol.

That division was sensible. A transport agent can transform bytes in ways the document cannot observe. Yet it also created a governance question: which layer may overrule which other layer, and what happens when a value is missing rather than contradictory?

RFC 2376 answered with a rule inherited partly from MIME history. RFC 3023 replaced it in 2001 and retained the text/xml US-ASCII default. It explained why an explicit MIME charset had operational value, especially when intermediaries transcoded text. But deployed practice and the standards around textual media continued to move.

The repair removed a silent decision

RFC 6657 later required new textual media types to define their charset behavior rather than inherit a general US-ASCII assumption. RFC 7303 then replaced RFC 3023 in 2014 and aligned text/xml with application/xml. The old distinction no longer decided encoding merely because the sender had chosen the text branch.

RFC 7303 described up to three sources of encoding evidence: BOM, MIME charset and XML declaration. Its priority put a BOM first and, when no BOM was present, an explicit charset next. If neither existed, XML's own rules applied. It still recommended application/xml, partly to avoid confusion left by the earlier split.

The successor also strengthened the +xml convention. A type such as an application-specific something+xml can advertise that generic XML tools may inspect the syntax while preserving a more precise account of the document's purpose. Being parseable as XML does not tell a receiver what the vocabulary means or what actions are safe.

A media type is not an execution receipt

The current IANA registry records application/xml and related XML types against RFC 7303. That is a durable coordination fact. It does not prove that a particular response carried the intended header, that a proxy preserved it, that the body matched it, that the parser chose the expected encoding or that application code understood the vocabulary.

Lu Heng's reality-layers lens makes the historical mistake easier to avoid. The registered media type, received header, octets, BOM, XML declaration, decoder result, parsed tree and business action belong to different layers. They may agree. Agreement must be observed rather than assumed.

Running-code primacy points to the decisive evidence: capture the actual header and body bytes, record the processor and rule set, and preserve the resolved character stream. Minimum initial specification explains why the original registration was still valuable. It opened a narrow common path for XML exchange. The later repair did not reject coordination; it removed an authority decision that had been hidden inside a default.