Resumen

  • RFC 1874 reservó text/sgml para entidades cuyo sentido general seguía siendo comprensible sin software SGML; las demás debían usar application/sgml.
  • El juego de caracteres, la transformación SGML-bctf y la referencia SGML-boot pertenecían a capas distintas. Declararlas no demostraba que el receptor las entendiera ni que poseyera la pieza referenciada.
  • Un sistema SGML podía permitir órdenes al sistema. La legibilidad de la salida degradada no era una autorización para la ruta activa, y la posterior separación de XML confirmó que una familia sintáctica no garantizaba procesadores compatibles.

El contrato empezaba por la pérdida aceptable

RFC 1874 no clasificó SGML según la belleza de su estructura, sino según lo que quedaba cuando el receptor no podía interpretarla. Si una persona aún podía captar el contenido, correspondía text/sgml. Si la estructura era indispensable, correspondía application/sgml.

Para proteger aquella salida mínima, el RFC 1874 exigía que cada registro SGML de la variante textual coincidiera con una línea del cuerpo MIME. Un visor ordinario podía mostrar esas líneas sin conocer declaraciones, entidades o instrucciones de procesamiento.

Era una promesa de degradación, no de equivalencia. El lector podía entender un párrafo y perder su jerarquía. Podía ver una referencia y no el objeto al que remitía. Podía recibir el mensaje general sin reproducir la composición prevista por el emisor.

El RFC 2046 explicó después la razón general de los tipos de primer nivel. Incluso sin reconocer el subtipo, un agente sabe algo útil sobre el tratamiento posible. Mostrar datos desconocidos puede ser razonable para texto, pero no para audio o imagen. Por eso un subtipo textual debía conservar la idea general sin depender del programa especializado.

El nombre dirigía la conducta ante la ignorancia. No describía todos los poderes de un programa que sí conociera SGML.

Tres parámetros no formaban un único sello

El charset ayudaba a la ruta que trataba text/sgml como texto común. En cambio, SGML-bctf indicaba cómo transformar las combinaciones de bits del modelo SGML en los octetos transportados. El valor por defecto era identity; el documento enumeraba también formatos fijos y transformaciones variables.

Un cliente podía reconocer los caracteres según MIME y no implementar el BCTF. Otro podía aplicar una transformación y aun así interpretar mal la declaración. La presencia del parámetro demostraba qué regla anunció el remitente, no qué regla ejecutó el receptor.

SGML-boot separaba aún más la cadena. El parámetro guardaba un Content-ID, no los datos de arranque. Ese identificador debía resolver a otra parte MIME application/octet-stream que contenía tripletas numéricas para mapear caracteres significativos de la declaración SGML.

La distinción entre referencia y posesión era material. La pieza podía faltar, repetirse bajo el mismo identificador o quedar separada durante una transformación del mensaje. Después de encontrarla, el receptor todavía debía interpretar correctamente las tripletas. Un encabezado perfecto podía encabezar un paquete incompleto.

El RFC 1590 proporcionó el procedimiento público para registrar tipos de medios. El registro fijaba un nombre y una especificación consultable. No examinaba los bytes de cada mensaje, el inventario de analizadores ni la política local.

Procesar añadía una autoridad que mostrar no tenía

La advertencia de seguridad de RFC 1874 fue directa: los sistemas SGML podían procesar instrucciones y algunos permitían cadenas de órdenes al sistema. Las instrucciones de presentación o composición planteaban riesgos parecidos a los de PostScript.

Por tanto, text/sgml no significaba «contenido inerte». Significaba que existía un modo útil de verlo sin activar el procesador SGML. Al invocarlo, el receptor cruzaba una frontera: del acceso humano a caracteres hacia software con capacidad para resolver, transformar y quizá ejecutar.

El resultado de un lado no servía como recibo del otro. Que el visor mostrara palabras no demostraba que el árbol SGML fuera válido. Que el árbol se construyera no demostraba que una instrucción estuviera autorizada. Que una orden estuviera bloqueada no implicaba que el documento careciera de valor textual.

MIME, además, pedía ignorar parámetros desconocidos. Esa regla evitaba que cada extensión rompiera el transporte. Pero un agente que ignoraba SGML-boot podía aceptar el envoltorio y perder la clave necesaria para una interpretación fiel. La interoperabilidad de la capa exterior no garantizaba la de la aplicación.

XML convirtió la incompatibilidad en un nombre distinto

XML heredó una relación formal con SGML, pero no heredó automáticamente sus programas. El RFC 2376 justificó text/xml y application/xml con tres hechos: muchos procesadores XML no manejaban todo SGML; los procesadores SGML no siempre aceptaban las correcciones empleadas por XML; y los parámetros SGML-bctf y SGML-boot no correspondían a XML.

Aquello separó una proposición taxonómica de una operacional. Ser subconjunto no era lo mismo que poder pasar por el mismo binario. Compartir marcas angulares no hacía apropiadas las mismas opciones de decodificación.

El RFC 3023 llevó la idea a formatos aplicados con el sufijo +xml. El nombre completo conservaba el dominio; el sufijo informaba de una sintaxis aprovechable por herramientas genéricas.

El RFC 6838 creó reglas de registro para esos sufijos estructurados. La ficha debía explicar codificación, interoperabilidad, fragmentos y seguridad. Esa revisión hacía pública la afirmación, pero no medía su adopción.

El RFC 7303 pidió que el software verificara la supuesta sintaxis XML con un procesador antes de continuar. También reconoció que algunos formatos debían evitar +xml si el procesamiento genérico resultaba inadecuado. El sufijo autorizaba una comprobación, no una acción sin contexto.

El mismo RFC distinguió documentos, subconjuntos DTD externos, entidades analizadas externas y entidades de parámetro. Todos pertenecían a XML, pero no ocupaban el mismo lugar. Una prueba de sintaxis no decidía el rol.

La historia no necesitaba un éxito inventado

No hay que demostrar que un producto concreto ejecutó una orden para entender el mecanismo. Los documentos primarios fijan una cadena suficiente: tipo anunciado, bytes recibidos, parámetro comprendido, transformación aplicada, referencia resuelta, declaración analizada, política consultada y resultado producido.

Nombrar cada etapa evita atribuir al RFC más de lo que publicó. El registro no era implantación. La lectura degradada no era fidelidad. El parseo no era permiso. La salida no era intención del usuario. RFC 1874 hizo visible esa separación precisamente al combinar un tipo de texto con una advertencia sobre procesamiento activo.

Fuentes y límites

Los RFC 1590, 1874 y 2046 documentan el registro, los tipos SGML y el comportamiento MIME. Los RFC 2376, 3023, 6838 y 7303 documentan la separación XML y los sufijos estructurados. No prueban despliegue actual, conformidad de un producto, análisis exitoso, ejecución real, ataque, daño ni resultado comercial.