Summary

  • RFC 2376 registró text/xml y application/xml, pero omitir charset activaba reglas opuestas: US-ASCII para el primero, incluso frente a un BOM o declaración XML, y detección propia de XML para el segundo.
  • La historia distingue registro, cabecera recibida, octetos, regla del decodificador y significado de la aplicación. RFC 7303 terminó alineando ambos tipos y eliminó el antiguo valor implícito.

Un formato autodescriptivo dentro de otro contrato

XML nació para mover estructura entre máquinas y programas diferentes. La declaración de codificación dentro de la entidad y la marca de orden de bytes permitían reconocer la serialización antes de interpretar todo el contenido.

Sin embargo, en HTTP, correo o WebDAV el documento llegaba dentro de un envoltorio MIME. Content-Type podía incluir su propio charset. El receptor obtenía así varias respuestas posibles a una sola pregunta: qué caracteres representan estos octetos.

RFC 2376 apareció en julio de 1998 como documento Informational. Registró text/xml y application/xml y rechazó reutilizar tipos SGML que no describían con precisión los procesadores ni los parámetros de XML. La coordinación era necesaria; la dificultad estaba en la prioridad.

La presentación cambió la prueba admisible

Toda entidad XML podía enviarse como application/xml. Un programa sin soporte específico podía tratarla como archivo opaco. text/xml sugería que verla como texto simple era un comportamiento razonable.

Esa elección arrastró las reglas históricas del tipo principal text. Con un charset explícito, RFC 2376 hacía autoritaria la cabecera para ambos tipos. La declaración interna no siempre tenía la última palabra.

Cuando faltaba el parámetro, los caminos se separaban. En application/xml, el envoltorio no aportaba información. Un procesador XML observaba el BOM, el patrón inicial de octetos y la declaración. Un agente MIME que no entendía XML no debía inventar un valor.

En text/xml, la ausencia significaba US-ASCII. La obligación seguía vigente sobre HTTP y aunque el cuerpo fuese UTF-8 o UTF-16 con una declaración clara. Lo que parecía “sin metadato” era en realidad una orden heredada.

El ejemplo enseñaba una derrota interna

La especificación presentó un caso con BOM UTF-16 y encoding="utf-16", pero con una cabecera limitada a text/xml. El resultado normativo seguía siendo US-ASCII. Para cumplir el contrato, el procesador debía desconfiar de lo que el documento decía de sí mismo.

El mismo cuerpo etiquetado como application/xml podía ser reconocido por el BOM. Sin él, XML permitía inspeccionar los primeros bytes y luego la declaración. Una palabra exterior alteraba la jerarquía de evidencias.

El problema continuaba al guardar o transformar datos. Un intermediario podía transcodificar el cuerpo y actualizar sólo la cabecera. Un archivo podía perder la cabecera que había gobernado su lectura. Separar bytes y contexto podía borrar la única prueba de por qué el receptor obtuvo ciertos caracteres.

La autodescripción no define su supremacía

XML 1.0 admite que, ante información externa, el protocolo superior debe establecer la prioridad. Tiene lógica: el transporte puede modificar una representación sin que la declaración interna lo sepa.

Pero esa delegación convierte el diseño en una cuestión de control. ¿Qué capa puede revocar a cuál? ¿La ausencia significa desconocimiento o un valor por defecto? RFC 2376 adoptó una respuesta procedente de la historia MIME.

RFC 3023 la sustituyó en 2001 y mantuvo el US-ASCII implícito de text/xml. Justificó mejor la autoridad de la cabecera cuando agentes intermedios transcodifican contenido. La práctica de implementaciones y las reglas generales de texto siguieron cambiando.

La reparación quitó una decisión escondida

RFC 6657 exigió que los nuevos tipos textuales declarasen su política de charset. En 2014, RFC 7303 alineó text/xml con application/xml; escoger la rama text dejó de producir por sí solo una codificación distinta.

La regla actual ordena hasta tres indicios: primero BOM; si no existe, un charset MIME explícito; y si tampoco existe, las reglas de XML. application/xml continúa recomendado para evitar la confusión histórica.

La convención +xml añadió precisión semántica. Un tipo especializado puede dejar que herramientas genéricas reconozcan XML y, al mismo tiempo, indicar qué clase de documento es. Construir un árbol no equivale a entender el vocabulario ni autorizar su ejecución.

IANA registra nombres, no resultados

El registro IANA actual apunta application/xml y tipos relacionados a RFC 7303. Esa fila prueba una asignación estable, no la cabecera de una respuesta concreta, la fidelidad de sus bytes, la decisión del parser o el efecto en el negocio.

Las capas de realidad de Lu Heng mantienen separados el nombre registrado, la cabecera capturada, los octetos, el BOM, la declaración, la cadena decodificada, el árbol y la acción. La primacía del código ejecutado exige observar cada límite. La especificación inicial mínima permite valorar RFC 2376 sin idealizarla: abrió una vía interoperable; las revisiones posteriores quitaron poder a un valor implícito que ya no reflejaba bien la realidad.