Resumen

  • RFC 1865 sustituyó los componentes de transmisión entre sistemas EDI existentes por correo de Internet. La entrega SMTP directa y asegurada terminaba en el sistema del socio, no en la aceptación comercial.
  • RFC 1767 encapsuló objetos X12, EDIFACT y EDI-consent en MIME sin cambiar su sintaxis o semántica ni añadir seguridad por sí solo.
  • RFC 3335 y RFC 4130 combinaron Message-ID, MIC, firma y MDN; aun así, un recibo firmado podía comunicar un fallo y la validez de la transacción seguía en manos de los socios.

La orden estaba dentro; el consentimiento, no

Un proveedor transmite una orden electrónica y recibe una respuesta SMTP positiva. El sistema de correo del comprador conserva los bytes. Todavía puede faltar todo lo que convierte ese objeto en una obligación: identificar al socio correcto, verificar la firma, descartar duplicados, validar la sintaxis, aplicar límites de compra y aceptar precio y plazo.

El RFC 1865 fue un documento Informational de enero de 1996 para la comunidad EDI que comenzaba a usar Internet. Su propuesta mantenía los programas comerciales y los traductores EDI. Cambiaba los módulos de comunicaciones.

La conexión SMTP dedicada, decía, llevaba la información directamente al sistema del socio y aseguraba la entrega; la integridad de una ruta con almacenamiento y reenvío dependía de intermediarios. Era una comparación útil de transporte. Convertirla en aceptación contractual exigiría borrar la palabra “sistema” y sustituirla por una voluntad que el protocolo no poseía.

EDI no era todo el comercio electrónico

RFC 1865 definía EDI como comunicación de información empresarial normalizada entre aplicaciones. Separaba esa actividad del comercio electrónico más amplio, que podía incluir conversaciones humanas, transferencias de dinero y recursos compartidos. El documento normalizado era parte del proceso, no su desenlace.

Los acuerdos bilaterales entre socios también permanecían. Podían cambiar nombres de buzones propietarios por direcciones de Internet, pero seguían decidiendo identidades, obligaciones y remedios. El RFC 1767 reservó expresamente EDI-consent para partes que hubieran llegado a un acuerdo bilateral.

La apertura de la ruta no abría la autoridad. Internet podía reducir la dependencia de un operador de red de valor añadido sin decidir quién podía comprometer a la empresa, cuándo un reintento era duplicado o qué jurisdicción interpretaría el recibo.

MIME sólo ocupó la parte central

RFC 1767 definió tipos MIME para EDI-X12, EDIFACT y EDI-consent. Su secuencia empieza en el programa empresarial, pasa por el traductor EDI, el procesador MIME, el envío de correo y SMTP; en destino, retira la envoltura, traduce y recién entonces entrega a la aplicación.

El RFC no alteraba la sintaxis ni el significado de EDI y no proporcionaba seguridad por sí mismo. MIME describía cómo reconocer y transportar una clase de objeto. No certificaba que el contenido fuera correcto, que el emisor estuviera autorizado, que los bytes no hubieran cambiado o que la aplicación hubiera aceptado la operación.

Esa modestia es importante. La interoperabilidad elimina una barrera y por ello parece resolver el proceso entero. El diagrama del RFC conserva las tareas que quedan a ambos lados.

Un recibo firmado podía ser una prueba de fracaso

El RFC 3335 amplió el modelo con firma, cifrado y MDN firmado. El identificador original correlacionaba la respuesta; el MIC representaba el contenido recibido; la firma atribuía la declaración al receptor según la clave y la política aplicables. El emisor aún debía verificar todo ello.

El texto situó el no repudio de recepción como un acontecimiento jurídico posterior a esa verificación. No convirtió cualquier certificado válido en poder de compra. La identidad de la clave, el mandato del firmante y la consecuencia legal permanecían separados.

El RFC 4130 mostró con claridad por qué. Si se exigía recibo firmado, el receptor debía devolverlo incluso cuando fallaba el procesamiento del contenido. La disposición consignaba el fallo. Así, el recibo no era una luz verde; era una declaración verificable sobre el estado alcanzado.

Si el recibo firmado convenido no aparecía, los socios debían resolver la validez y probablemente considerar inválida la transacción. El transporte apoyaba necesidades probatorias, pero no definía por sí mismo el no repudio porque éste era un requisito comercial o jurídico.

Mostrar tampoco significaba comprender

El RFC 3798 advertía que un receptor podía ignorar la petición de MDN y que una disposición displayed no garantizaba lectura o comprensión. La advertencia desmonta una escalera de inferencias demasiado habitual.

Una respuesta SMTP no es entrega a la aplicación. Un MDN no es procesamiento EDI satisfactorio. Una firma válida no es autoridad comercial. Un acuse funcional no siempre es aceptación contractual. Cada ascenso requiere un emisor distinto y una regla que explique su efecto.

El registro honesto conserva el objeto original, la aceptación o entrega de correo, el MDN correlacionado y su MIC, el resultado del traductor, el acuse de la aplicación y la decisión comercial autorizada. No todos los sistemas generan seis documentos, pero ninguno debería ocultar la frontera entre observación y poder.

Transporte distribuido, gobierno bilateral

RFC 1865 imaginó directorios distribuidos, encaminamiento y resolución cooperativos, además de proveedores y servidores redundantes. La actividad EDI no necesitaba un coordinador central de Internet. Esa arquitectura hacía sustituible una parte que antes podía concentrarse en una red propietaria.

Pero los socios continuaban fijando direcciones, certificados, plazos, duplicados, conservación y solución de disputas. La descentralización afectaba al porte, no a la responsabilidad.

Las fuentes no documentan una instalación empresarial concreta, una orden aceptada, un pago o una sentencia. Demuestran algo más acotado: la entrega técnica ganó pruebas cada vez mejores sin recibir por ello autoridad para decidir el resultado comercial.

Fuentes