Resumen

  • RFC 3023 introdujo la convención +xml para que tipos de medios distintos declararan una base XML común y pudieran aprovechar herramientas genéricas.
  • El sufijo no identificaba el vocabulario ni concedía autoridad: tipo exacto, bytes, análisis, validación, permiso y efecto seguían siendo comprobaciones separadas.

XML se extendió porque permitía construir muchos lenguajes sobre una misma infraestructura. Esa ventaja creó un problema de etiquetado. Si un mensaje comercial y un gráfico vectorial recibían ambos application/xml, el receptor conocía la sintaxis pero perdía la identidad de la aplicación. Si cada formato usaba un nombre opaco, conservaba su identidad pero las herramientas genéricas no podían reconocer la estructura compartida.

En enero de 2001, RFC 3023 eligió una unión mínima. El subtipo específico podía terminar en +xml. Lo situado antes del signo más nombraba el formato; la terminación revelaba la familia de representación.

Un camino genérico sin sustituir al camino específico

Un programa que entendiera application/foo+xml debía seguir las reglas de foo: su modelo de datos, su presentación, sus restricciones y sus operaciones. Otro programa que desconociera foo podía detectar los últimos cuatro caracteres y decidir si le bastaba un tratamiento XML genérico, como analizar, buscar, editar o transformar bajo límites propios.

La convención evitaba que cada herramienta tuviera que enumerar todos los vocabularios XML. También evitaba convertir un parámetro MIME en una falsa segunda dimensión. RFC 3023 observó que los despachadores existentes rara vez decidían por parámetros y que la naturaleza XML era invariable para cada instancia del tipo. Crear un nuevo tipo superior habría sido una alteración desproporcionada.

Sin embargo, application/foo y application/foo+xml no se convertían en alias. El apéndice aclaró que un procesador sin conocimiento de XML trataría el sufijo como opaco y que su presencia no podía añadir semántica por sí sola. La variante XML podía cambiar tanto la forma como el significado. El soporte de un tipo no demostraba soporte del otro.

Analizar los bytes no resolvía el vocabulario

El encabezado recibido es una afirmación. Un analizador XML puede contrastarla con los bytes y producir, si todo va bien, una estructura. Esa estructura aún no demuestra que el espacio de nombres sea admitido, que el documento cumpla un perfil, que su firma sea válida o que el firmante tenga derecho a solicitar la acción.

La palabra approve dentro de una etiqueta no aprueba nada. La aplicación debe atribuirle significado; una política debe autorizar al actor; el sistema debe intentar la operación; y un registro posterior debe demostrar el resultado. Del mismo modo, reconocer XML no ordena resolver entidades externas, obtener recursos remotos o ejecutar transformaciones. Son capacidades locales y potencialmente peligrosas.

La utilidad de +xml dependía precisamente de no prometer demasiado. Permitía reutilizar una gramática y conservar el derecho a rechazar el resto.

De convención puntual a registro estructurado

RFC 6838 incorporó los sufijos de sintaxis estructurada al sistema de registro: lo que sigue al último signo más identifica una sintaxis registrada. RFC 6839 formalizó +xml y trazó una división clara. El tipo exacto permite procesamiento semántico específico; el sufijo permite procesamiento genérico cuando no hace falta conocer esa semántica y el analizador no necesita información adicional.

RFC 7303 sustituyó a RFC 3023 y mantuvo la regla. Los nuevos formatos basados en XML deberían terminar en +xml, salvo cuando el procesamiento XML genérico fuera inadecuado. Un receptor podía detectar el sufijo, invocar un analizador para verificar la suposición y continuar de forma controlada. El formato concreto seguía siendo dueño de sus reglas de visualización, edición, seguridad, ejecución y fragmentos.

Los registros actuales de IANA muestran el resultado: una entrada común para +xml y muchos tipos completos diferentes que lo utilizan. La terminación compartida prueba una relación sintáctica. Los nombres distintos preservan la diferencia operacional.

Fuentes

Lu Heng no escribió ni respaldó RFC 3023. Sus ensayos se usan aquí como marcos analíticos declarados.