Resumen

  • RFC 2160 definió una ruta antigua mediante un Extended Body Part con OID mime-postscript-body y otra mediante un FTAM Body Part cuya referencia de aplicación era id-mime-ftbp-postscript.
  • En ambas rutas el flujo se copiaba a application/postscript sin convertirlo. Esa regla protegía los octetos, no demostraba que el receptor entendiera el contenedor, que hubiera adoptado FTAM o que el programa produjera una página segura y correcta.

La historia no empieza en una impresora, sino en la etiqueta del paquete. Dos paquetes pueden contener exactamente el mismo documento y exigir mecanismos de apertura diferentes. Si el receptor reconoce uno y desconoce el otro, comparar el contenido no resuelve el problema de entrega.

RFC 2160, publicado en enero de 1998, formalizó esa situación para PostScript entre X.400 y MIME. Mantuvo una representación anterior y presentó otra como preferida. Así dejó visible una verdad de toda migración: la continuidad del contenido y la continuidad de la interfaz no son la misma cosa.

La ruta heredada y la ruta recomendada

El Extended Body Part procedía de RFC 1494. No tenía parámetros; sus datos eran un OCTET STRING, y el OID mime-postscript-body se asignaba bajo { mixer-bp-data 2 }. Aquella especificación llamaba Byte Copy al paso hacia application/postscript.

El FTAM Body Part se reconocía en otro punto de la estructura. FileTransferParameters.environment.application-reference debía contener id-mime-ftbp-postscript, ubicado bajo { mixer-bp-data 6 }.

La diferencia importaba en el software. Un agente podía implementar la forma heredada sin el perfil FTAM, o FTAM sin el mecanismo anterior. La recomendación de RFC 2160 no convertía la nueva ruta en universal; señalaba la dirección deseada mientras el texto seguía documentando la compatibilidad previa.

RFC 2157 organiza por separado los tipos X.400 y sus equivalencias MIME. RFC 2156 explica el marco de MIXER: coherencia entre pasarelas, conservación de información y reversibilidad cuando resulte práctica. Son reglas de diseño, no telemetría de una instalación.

Sin conversión no significa sin cambio de representación

Las dos tablas de RFC 2160 dicen Conversion Type: No conversion. En ambos lados existe un único flujo de octetos, que puede copiarse directamente sin transformar otros datos.

Un hash antes y después permite afirmar algo fuerte: el payload llegó con los mismos bytes. No permite afirmar que el objeto exterior fuera el mismo. El sistema pasó de una clase de body part X.400 a un media type MIME, y dentro de X.400 aún debía distinguir qué clase había sido usada.

Por eso el registro técnico debe guardar tanto el flujo como su identidad de transporte. Si una migración archiva solo el PostScript extraído, borra la prueba de si llegó por EBP o FTAM y de si hubo una caída silenciosa hacia el formato antiguo.

El programa intacto aún puede ser rechazado

RFC 2160 remitía a RFC 1521 para el tipo MIME. RFC 2046 aclara que application/postscript contiene un programa y recomienda las convenciones DSC. Sin estructura adecuada no siempre es posible determinar si funcionará en un entorno, y algunos sistemas pueden negarse a procesarlo.

Además, un intérprete PostScript general puede tocar archivos, modificar estado persistente, cambiar parámetros, utilizar extensiones no estándar o agotar recursos. Deshabilitar operadores o aislar el documento no contradice la entrega; es una decisión de seguridad posterior. Un archivo puede ser íntegro, estar bien tipado y, aun así, no ser ejecutable con la política local.

La ficha de RFC Editor y la ficha de Datatracker acreditan el documento. La búsqueda de erratas no muestra coincidencias actualmente. Ninguna acredita la conducta de un receptor concreto.

Cinco preguntas para una sola transferencia

Conviene preguntar por separado: ¿coinciden los bytes?, ¿qué portador X.400 se usó?, ¿el receptor soporta ese portador?, ¿qué hizo el intérprete?, ¿qué vio finalmente el usuario? Cada respuesta exige un registro distinto: hashes, OID, matriz de capacidades, decisión de política y evidencia de salida.

La especificación inicial mínima de Heng Lu ayuda a limitar la capa común a reglas verificables. La primacía del código en ejecución obliga a medir qué implementaron realmente las pasarelas. La separación entre capas de realidad evita que un hash o una etiqueta suplanten el resultado de usuario.

RFC 2160 resolvió con elegancia la parte pequeña: copiar el flujo. El error posterior sería pedirle que resolviera también la identidad del portador, la adopción, la seguridad y la utilidad. Los bytes intactos son una prueba precisa; su fuerza depende de no convertirlos en una prueba total.

Fuentes