直接インターネットメッセージのカプセル化

Direct Internet Message Encapsulation (DIME) は、インターネット経由でバイナリやその他のカプセル化されたデータをストリーミングするための、2000 年代初頭に Microsoft が提案したインターネット標準です。

IETF のWeb サイトによると、この標準は撤回されており、RFCステータスにはなっていません。ただし、Microsoft はかつてWeb サービス経由でファイルを転送するために DIME を推奨していました。Java EEでも使用されていましたが、プロトコルの実装の違いにより困難でした。^{[引用が必要]}

最初のバージョン^[1]は 2001 年 11 月に IETF に提出され、最後の更新^[2]は 2002 年 6 月に提出されました。2003 年 12 月までに、DIME はMessage Transmission Optimization MechanismおよびSOAP with Attachmentsとの競争に敗れました。^[3] Microsoft は現在、DIME を「SOAP Message Transmission Optimization Mechanism (MTOM) 仕様に置き換えられた」と説明しています^[4]

この標準は、 MIMEの改良版となることを目指していました。^[5]特に、MIME の難しさは、各メッセージをテキストとしてエンコードする必要があり、メッセージのセクションがメッセージ ヘッダーで指定された区切り文字で区切られることです。つまり、データに含まれない区切り文字を選択できるように、送信者は通信を開始する前にデータ ストリーム全体を把握しておかなければなりません。通信の開始時にストリーム全体が利用できない場合や、検索にコストがかかる場合には、これは役に立ちません。DIME はストリーミングに重点を置いており、たとえば、受信側はメッセージ全体を待たずに、メッセージのチャンクが到着するとそれを処理できます。

HTTP に関する問題

DIME は、 OSI モデルのデータ リンク層の転送形式として定義されていますが、通常はHTTP経由で転送されます。ここでの難しさの 1 つは、HTTP メッセージが基本的に任意のサイズ (制限は各チャンクのサイズ情報で、32 ビット、つまり 1 ギガビット) になる可能性があることです。多くの HTTP 受信者はこれほど大きなメッセージに慣れておらず、メッセージをバッファリングすると、ソフトウェアが短いメッセージを期待していたのに長いメッセージを受信したために、単に失敗します。さらに、HTTP 受信者がセキュリティ保護されている場合は、メッセージを受信すると、送信者にチャレンジ メッセージ (400 コード) を送り返します。HTTP はコネクションレス型であるため、チャレンジを受け入れるか拒否するかだけで、送信された大量のデータが完全に失われることがあります。チャレンジへの応答は、もちろん成功する可能性がありますが、そのためにはデータが 2 回送信されることになり、データが膨大であれば、その意味が薄れてしまいます。

代替ソリューションでは、チャレンジ成功の基準 (ユーザー名とパスワードなど) が帯域外で確立されるため、最初にメッセージとともに送信され、チャレンジを受信しません (コネクションレス HTTP プロトコルの副産物として、各メッセージが個別に扱われるため、どのメッセージにもチャレンジ応答を正常に含めることができる必要があります)。

DIME は、他のプロトコルの実際のアプリケーションと比較して非常に高速でした。データは、たとえばBase64でエンコードされたものではなくバイナリであったため、比較的コンパクトで、プロトコルに組み込まれたチャンク化およびパケット化の方法により、メッセージ全体が読み取られる前に、適切な受信者がデータをストリーミングして読み取ることができました。

ネットワーク層の問題

DIME はデータリンク層で定義されているため、DIME メッセージを別の DIME メッセージにカプセル化することが可能でした。これは圧縮にはまったく役立ちませんでしたが、OS モデルのネットワーク層にあるルーターなどのネットワーク インフラストラクチャをバイパスするのに時々役立ちました。そうしないと、カプセル化されたトラフィックがブロックされます (バイナリであるため、疑いの目で扱われる可能性があります)。そうは言っても、MIME などの他のプロトコルも同様に影響を受ける可能性があります。DIME は一般に信頼性が高いクライアント間で使用されていたため、ルーターで特定のポートを開いて、DIME トラフィックを送受信する明確な目的に使用できます。これにより、チャレンジは引き続き発生するため、セキュリティの側面が損なわれることはありませんでしたが、単にバイナリ トラフィックがそのポートの標準であると受け入れ、多数の誤検知が発生しなかっただけです。

• 添付ファイル付きSOAP

• Microsoftによる概要。
• DIMEに関する記事へのリンク
• 最新のIETFドラフト
• DIME ディスカッション リストのアーカイブ 2006-12-05 にWayback Machineにアーカイブされました