Resumen
- RFC 1523 diseñó
text/enrichedpara que el texto ASCII o compatible resultara tolerable incluso sin MIME, y para que una implementación mínima eliminara las marcas y dejara prosa legible. - Esa degradación no conservaba todo: las órdenes desconocidas perdían su efecto, los parámetros podían quedar invisibles, el receptor decidía la apariencia y otra alternativa MIME podía contener una representación más rica.
El teletipo como prueba de interoperabilidad
RFC 1523, publicado en septiembre de 1993 con categoría Informational, refinó el text/richtext de RFC 1341 y lo llamó text/enriched. Su objetivo no fue trasladar todas las funciones de un procesador de textos al correo. La especificación aceptó menos capacidad para aumentar la probabilidad de una visualización correcta.
La referencia al teletipo fijaba el suelo. Un sistema sencillo debía poder retirar el formato y dejar texto entendible. Con ASCII o un superconjunto de ocho bits, los datos sin procesar también debían ser razonablemente legibles en un programa que ignorase MIME.
La compatibilidad no nacía de hacer idénticas las pantallas. Nacía de ordenar la pérdida: una máquina podía omitir negrita, centrado o sangría sin ocultar las palabras que estaban dentro. El resultado seguía siendo útil, aunque no fuese equivalente al documento concebido por el autor.
Una sintaxis pequeña exigía disciplina
Los comandos eran nombres ASCII sin distinción entre mayúsculas y minúsculas, encerrados entre ángulos y limitados a 60 caracteres. Para escribir un < literal se usaba <<. Los entornos de formato debían cerrarse, estar equilibrados y anidarse correctamente.
La carga recaía primero en quien componía. A cambio, el lector podía funcionar con una pila sencilla. Al abrir un entorno guardaba un estado; al cerrarlo recuperaba el anterior. La recomendación de tolerar estructuras defectuosas no convertía una anidación cruzada en lenguaje válido.
También el CRLF tenía una interpretación deliberada. Uno solo se convertía en espacio; una secuencia de N producía N−1 saltos de línea. Así, un transporte que partiera físicamente una línea no tenía por qué inventar un párrafo. Pero el byte recibido, la línea reconstruida y la página mostrada seguían siendo evidencias distintas.
Lo desconocido pasaba, pero sin su significado visual
Una orden desconocida debía tratarse como una operación nula. Las palabras encerradas sobrevivían; su efecto no. Los nombres X- quedaban disponibles para extensiones privadas y una extensión formal requería un nuevo documento de Internet.
Esa decisión permitía que un lector antiguo recibiera contenido nuevo sin rechazarlo. También creaba una ambigüedad visible solo si se conservaba la traza: una advertencia, una jerarquía o una indicación especializada podía reaparecer como texto ordinario.
Los entornos <param> llevaban información para otra orden. El intérprete podía usarla o ignorarla, pero no debía enseñarla al lector. Por eso, la proyección mínima eliminaba tanto las órdenes como el contenido del parámetro. Un párrafo gramaticalmente completo podía haber perdido un dato decisivo.
nofill y verbatim mostraban que ni siquiera el proceso de quitar formato carecía de contexto. nofill suspendía el relleno y el tratamiento normal de CRLF; verbatim suspendía además la justificación y la interpretación de órdenes internas hasta su cierre.
El destinatario completaba la presentación
Las fuentes disponibles, el ancho de línea, el incremento de sangría, la justificación y algunas combinaciones dependían del receptor. Si no podía representar dos efectos a la vez, podía favorecer la orden reconocida más interna. Dos renderizados diferentes podían cumplir la misma norma.
Para contenido fuera de ese vocabulario, RFC 1523 proponía una relación explícita mediante multipart/alternative: una versión text/enriched de alcance amplio junto a otra más rica, como ODA. Cada cliente escogía según su capacidad. Recibir los mismos bytes no implicaba leer la misma representación.
El documento afirmó entonces que el mecanismo no planteaba problemas de seguridad. Es una declaración histórica de alcance limitado, no una auditoría de extensiones posteriores, implementaciones ni aplicaciones actuales. RFC 1563 dejó obsoleto RFC 1523 y RFC 1896 hizo lo mismo con RFC 1563; esa secuencia prueba revisión documental, no sustitución instantánea del software.
El conjunto de fuentes no identifica ningún lector, despliegue ni mensaje concreto; tampoco mide la adopción, la respuesta de los usuarios ni el resultado observado de una entrada mal formada. Documenta reglas y linaje, no el comportamiento de una instalación determinada.
Una historia verificable conserva las capas por separado: bytes y juego de caracteres, CRLF físicos, pila de órdenes, decisiones sobre comandos conocidos o desconocidos, parámetros ocultos, alternativa escogida, salida visual y lectura humana. La degradación legible fue una política de supervivencia, no un certificado de identidad.
Fuentes
- Ficha de RFC 1523
- RFC 1523 — El tipo MIME text/enriched
- RFC 1341 — MIME
- RFC 1521 — MIME, primera parte
- RFC 1563 — El tipo MIME text/enriched
- RFC 1896 — El tipo MIME text/enriched
- RFC 2046 — MIME, segunda parte
- Heng Lu — Primacía del código operativo
- Heng Lu — Especificación inicial mínima
- Heng Lu — Sobre las capas de realidad
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
