Resumen

  • RFC 1197 decía que ODA representaba documentos complejos mediante entidades abstractas; para intercambiarlos de forma útil hacía falta un document application profile y un mapa hacia el modelo nativo de cada aplicación.
  • EXPRES probó esa superficie para enviar propuestas de investigación a la NSF con un perfil del NIST y funciones de Andrew, Diamond e Interleaf. La breve RFC no publica resultados de fidelidad ni adopción.
  • Las reglas posteriores de MIME y X.400 mantuvieron separados el cuerpo ODA, el perfil y la clase documental. Conservar bytes no demostraba conservar significado, aspecto o capacidad de edición.

La recepción correcta no cerraba la pregunta

Supongamos que una pasarela copia un cuerpo ODA sin modificar un solo octeto. El destinatario verifica el archivo y reconoce su tipo. Aun así, todavía faltan respuestas: ¿qué subconjunto de la arquitectura utilizó el emisor?, ¿qué clase de documento prometió?, ¿cómo convierte el receptor esas entidades en objetos de su editor?, ¿qué estructura quedó después del renderizado?

La RFC 1197 permite reconstruir esa escalera desde su primer peldaño. Mark Sherman la publicó en diciembre de 1990 como una nota de experiencia sobre Office Document Architecture, ISO 8613 y CCITT T.410. El registro de RFC Editor y la ficha de IETF Datatracker confirman que es Informational. No definía un Internet Standard.

Su brevedad impone una frontera. Describe el problema y el proyecto, pero remite las estrategias completas a un libro de 1991 que no forma parte de estas fuentes. Por eso no autoriza a inventar tasas de conversión, diferencias visuales ni una evaluación de productos.

La abstracción era la fuerza y la deuda de ODA

ODA podía representar texto con múltiples fuentes, imágenes raster y gráficos geométricos. Esa amplitud tenía sentido para un formato destinado al correo multimedia y al intercambio de archivos, y ya aparecía en trabajos relacionados con X.400.

Pero la RFC lo llama un estándar muy abstracto. Definía objetos como las clases lógicas compuestas, no entidades corrientes como los párrafos. La frase no afirma que fuese imposible construir algo parecido a un párrafo en ODA. Afirma que la arquitectura general no seleccionaba por sí misma el objeto cotidiano que dos aplicaciones usarían como contrato.

Un modelo neutral evita convertir las decisiones internas de un editor en ley universal. Al mismo tiempo, esa neutralidad deja un trabajo que no puede resolver la sintaxis: escoger qué capacidades forman el terreno común.

El perfil limitaba el acuerdo; el mapa lo hacía operativo

RFC 1197 llamó document application profile, o DAP, al acuerdo necesario. El perfil definía entidades comunes dentro del espacio ODA. Luego había que relacionarlas con las entidades de cada sistema participante.

Son dos superficies de control. El responsable del perfil decide qué parte del estándar usa la comunidad. El implementador decide cómo se materializa cada entidad en su producto. Una función local que no cabe en el perfil puede seguir siendo valiosa, pero no obtiene portabilidad automática.

De ahí que “soporta ODA” sea una afirmación demasiado ancha. Dos productos pueden reconocer la familia de formato y no el mismo DAP. También pueden reconocer el mismo DAP y tratar de modo distinto una propiedad opcional. La evidencia útil debe nombrar perfil, versión, clase, extensiones y mapa local.

El perfil no compite con el estándar. Reduce una posibilidad enorme a una promesa que se puede probar. La interoperabilidad real vive en ese subconjunto ejecutado por ambos extremos.

EXPRES hizo visible la diversidad de los extremos

La National Science Foundation financió EXPRES para investigar el envío electrónico de propuestas de investigación mediante ODA. Participaron grupos de Carnegie Mellon University y University of Michigan junto con McDonnell-Douglas Aerospace Information Systems, NIST e Interleaf.

El trabajo se basó en el DAP del NIST y en las funciones disponibles en Andrew, Diamond e Interleaf. La enumeración importa porque muestra que el perfil no borraba las aplicaciones: se necesitaba precisamente para relacionar tres superficies diferentes.

La RFC no informa de que todas las funciones sobrevivieran, de que un documento pudiera volver a su origen sin cambios ni de que el procedimiento institucional se completara. Los nombres prueban quién formó parte del estudio descrito; no son sellos de conformidad perpetuos ni declaraciones actuales de producto.

El texto también separa autoría y autoridad: el libro citado expresaba las opiniones de sus autores, no las políticas de las instituciones participantes.

MIME necesitó más que application/oda

La RFC 1341, publicada en 1992, incorporó un subtipo MIME application/oda. Indicaba que el cuerpo estaba codificado con las normas ODA en representación ODIF. Además, Content-Type debía identificar el DAP mediante el parámetro profile; el ejemplo era profile=Q112.

El diseño hacía pública la diferencia entre formato y perfil. El subtipo permitía seleccionar una familia de tratamiento. El parámetro precisaba el contrato dentro de esa familia. Ninguno demostraba que el receptor poseyera el software adecuado ni que su mapa local reprodujera la intención.

RFC 1341 está obsoleta. Su valor aquí es histórico: dos años después de EXPRES, el correo de Internet conservó como campos separados la representación y el perfil que la volvía utilizable.

La pasarela podía no tocar el cuerpo y aun tomar decisiones

En 1993, la RFC 1494 definió equivalencias entre cuerpos X.400 y MIME. Para ODA, denominó “Byte copy” a la conversión del cuerpo. Sin embargo, también transformó el identificador de perfil X.400 en profile y la clase de arquitectura en formatted, processable o formatted-processable.

Así aparecían tres registros: datos, perfil y clase. Que el primero pasara intacto no decía que los otros estuvieran presentes, fueran correctos o se entendieran en destino. La clase delimitaba el uso esperado del documento; el perfil acotaba las entidades; el adaptador receptor seguía siendo responsable del modelo nativo.

Cuando faltaban parámetros, la especificación fijaba Q112 y formatted-processable como valores por defecto. La pasarela podía intentar leerlos dentro del documento, pero no estaba obligada porque esas características internas eran opcionales.

El valor por defecto evita una decisión indeterminada. No prueba qué quiso declarar el emisor. Una auditoría debe conservar si el dato llegó en la cabecera, fue extraído del objeto o fue añadido por la regla de conversión.

“Ninguna conversión” seguía necesitando contexto

La RFC 2161 reunió en 1998 las definiciones ODA para MIME y X.400. Era Experimental y decía expresamente que no constituía un Internet Standard. Mantuvo profile, class, Q112 y las tres clases documentales.

Su campo “Conversion: None” se refería al cuerpo ODA. No eliminaba el mapeo de parámetros, los valores por defecto ni los identificadores de la envolvente. Un archivo idéntico podía seguir produciendo resultados distintos en programas con capacidades y mapas diferentes.

La sección de seguridad reconocía estructuras complejas cuyas capacidades podían ser difíciles de descubrir. Como ODA era extensible, nuevas porciones de contenido podían modificar los riesgos. También indicaba que entonces no se conocían riesgos específicos de ODA. Eso aconseja revisar capacidad y versión, no atribuirle un incidente que la fuente no registra.

Un documento útil era una observación posterior

El orden probatorio queda claro: bytes ODIF; declaración de tipo; perfil declarado o inferido; clase; acción de la pasarela; soporte del receptor; mapa hacia entidades nativas; renderizado; estructura editable; ida y vuelta; resultado institucional.

Un hash responde si el artefacto cambió. Un identificador de perfil dice qué subconjunto se reclama. La versión del adaptador explica qué reglas se ejecutaron. Una comparación estructural o visual muestra el resultado. Ninguna respuesta sustituye a las siguientes.

La lección de RFC 1197 no es que todo formato común sea inútil. Es que un centro abstracto debe reconocer sus límites. La comunidad selecciona una promesa pequeña; cada extremo demuestra su implementación; la persona o institución receptora decide si el resultado satisface el uso real.

Fuentes y límites

Las fuentes no prueban adopción actual, cuota de mercado, fidelidad completa de EXPRES, calidad de un producto, una vulnerabilidad conocida ni el éxito de una propuesta concreta.