Encapsulación directa de mensajes de Internet

La encapsulación directa de mensajes de Internet (DIME) fue un estándar de Internet propuesto por Microsoft a principios de la década de 2000 para la transmisión de datos binarios y otros datos encapsulados a través de Internet.

Según el sitio web de la IETF , el estándar fue retirado y nunca alcanzó el estatus de RFC . Sin embargo, Microsoft recomendó en su momento DIME para la transmisión de archivos a través de servicios web . También se utilizó en Java EE , pero las diferencias en la implementación del protocolo dificultaron su uso.

La primera versión ^{[ 1 ]} se presentó al IETF en noviembre de 2001; la última actualización ^{[ 2 ]} se presentó en junio de 2002. Para diciembre de 2003, DIME había perdido terreno frente al Mecanismo de Optimización de Transmisión de Mensajes (MTOM) y SOAP con adjuntos . ^{[ 3 ]} Microsoft ahora describe a DIME como "sustituido por la especificación del Mecanismo de Optimización de Transmisión de Mensajes (MTOM) de SOAP" ^{[ 4 ].}

El estándar se concibió como una versión mejorada de MIME . ^{[ 5 ]} En particular, una dificultad de MIME radica en que cada mensaje debe codificarse como texto y sus secciones se separan mediante un separador especificado en la cabecera. Esto implica que el remitente debe conocer todo el flujo de datos antes de iniciar la comunicación, para así poder elegir un separador que no aparezca en los datos. Esto resulta poco útil si el flujo completo no está disponible al iniciar la comunicación o si su búsqueda es costosa. DIME está más orientado al procesamiento en tiempo real, permitiendo, por ejemplo, que el receptor procese fragmentos del mensaje a medida que llegan, sin tener que esperar a que llegue el mensaje completo.

Problemas con HTTP

DIME se definió como el formato de transmisión en la capa de enlace de datos del modelo OSI, aunque normalmente se transmitía a través de HTTP . Una dificultad radicaba en que podía formar un mensaje HTTP de prácticamente cualquier tamaño (el límite era la información de tamaño para cada fragmento, que era de 32 bits, es decir, 1 gigabit). Muchos receptores HTTP no estaban acostumbrados a mensajes tan grandes, y si almacenaban mensajes en búfer, simplemente fallaban, debido a que el software esperaba un mensaje corto, pero recibía uno largo. Además, si el receptor HTTP era seguro, enviaba un mensaje de desafío (código 400) al remitente al recibir el mensaje. Dado que HTTP no tiene conexión, se perdía por completo la posible gran cantidad de datos que se le habían enviado, solo para aceptar o rechazar el desafío. La respuesta al desafío podía, por supuesto, tener éxito, a costa de enviar los datos dos veces, lo que, si eran muy grandes, anulaba su propósito.

En la solución alternativa, los criterios para un desafío exitoso (por ejemplo, un nombre de usuario y una contraseña) se establecen fuera de banda, de modo que se pueden enviar con el mensaje la primera vez y no recibir un desafío (el efecto secundario del protocolo HTTP sin conexión es que, dado que cada mensaje se trata individualmente, cualquier mensaje debe poder incluir correctamente su respuesta al desafío).

DIME era extremadamente rápido en comparación con las aplicaciones prácticas de otros protocolos. Dado que los datos eran binarios en lugar de estar codificados, por ejemplo, en Base64 , eran relativamente compactos, y los métodos de segmentación y paquetes integrados en el protocolo permitían que un receptor adecuado los transmitiera y leyera antes de que se hubiera leído el mensaje completo.

Problemas en la capa de red

Debido a que DIME se definió en la capa de enlace de datos, era posible encapsular un mensaje DIME dentro de otro. Esto no ayudaba en absoluto con la compresión, pero a veces resultaba útil para sortear la infraestructura de red, como los enrutadores en la capa de red del modelo del sistema operativo, que de otro modo bloquearían el tráfico encapsulado (al ser binario, podrían tratarlo con recelo). Dicho esto, otros protocolos como MIME también podrían sufrir este problema. Dado que DIME se usaba generalmente entre clientes de confianza, se podía abrir un puerto específico en el enrutador con el propósito expreso de enviar y recibir tráfico DIME. Esto no comprometía la seguridad, ya que el desafío seguía ocurriendo; simplemente aceptaba que el tráfico binario era la norma en ese puerto y no generaba numerosos falsos positivos .

• SOAP con archivos adjuntos

• Descripción general por Microsoft .
• Enlaces a artículos sobre DIME
• Último borrador del IETF
• Archivos de la lista de discusión de DIME. Archivados el 5 de diciembre de 2006 en Wayback Machine.