Direct Internet Message Encapsulation
Encyclopedia
Direct Internet Message Encapsulation (DIME) was a Microsoft
-proposed internet standard in the early 2000s for the streaming of binary and other encapsulated data over the Internet.
According to the IETF
web site, the standard has been withdrawn and never made RFC
status. However, Microsoft did at one time recommend DIME for transmitting files via Web services. It was also used in Java EE, but differences in the implementation of the protocol made it difficult
The first version was submitted to the IETF in November 2001; the last update was submitted in June 2002. By December 2003, DIME had lost out, in competition with Message Transmission Optimization Mechanism and SOAP with Attachments
,. Microsoft now describes DIME as "superseded by the SOAP Message Transmission Optimization Mechanism (MTOM) specification"
The standard was supposed to be an improved version of MIME
(see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service01152002.asp). In particular, the difficulty with MIME is that each message must be encoded as text, and that its sections are separated by a well-known separator given in the message header. This means, unfortunately, that the entire stream of data must be known to the sender before starting the communication, so as to choose a separator that does not occur in the data. This is not useful if the entire stream is not available when the communication is initiated, or when searching it even with a randomly-generated attempt at a unique separator (e.g. a GUID) is expensive. DIME was more oriented to streaming, allowing for example a receiver to process chunks of the message as they arrived, without having to wait for the entire message to arrive.
in the OSI model
although it was typically transmitted over HTTP. One difficulty here was that it could form an HTTP message of, essentially, any size (the limit being the size information for each chunk, which was 32 bits so 1 gigabit). Many HTTP receivers were unused to messages as large as this, and if they buffered messages would simply fail, expecting a short message and receiving a huge one. Moreover, if the HTTP receiver was secured, it would, on receiving the message, send back a challenge message (400 code) to the sender. Because HTTP is connectionless, it would then entirely lose the possibly huge amount of data that had been sent to it, just to accept or deny the challenge. There was no entirely satisfactory solution to this. The response to the challenge could of course succeed, at the expense of sending the data twice, which if it were huge rather defeats its point. (It is fair to say any other method of sending data over HTTP suffers the same problem.) In the alternate, and probably better solution, the criteria for a successful challenge (e.g. a username and password) is established out-of-band, so it can be sent with the message the first time and not receive a challenge (the by-product of the connectionless HTTP protocol being that since each message is treated individual, any message must be able successfully to include its challenge response).
DIME was extremely fast compared to practical applications of other protocols. Because the data was binary rather than, say, Base64
encoded, it was relatively compact, and the chunking and packet methods built into the protocol meant it could be streamed and read by a suitable receiver before the whole message had been read.
a DIME message in another DIME message. This would not help at all for compression purposes, but was occasionally useful to bypass networking infrastructure such as routers at the network layer of the OS model, that would otherwise block the encapsulated traffic (being binary they may treat it with suspicion). That being said, other protocols such as MIME may equally suffer such. Since DIME was generally used between well-trusted clients, a specific port could be opened at the router for the express purpose of sending and receiving DIME traffic. This did not subvert the security aspects, since the challenge would still occur, merely that it accepted that binary traffic was the norm on that port, and not give numerous false positives.
Microsoft
Microsoft Corporation is an American public multinational corporation headquartered in Redmond, Washington, USA that develops, manufactures, licenses, and supports a wide range of products and services predominantly related to computing through its various product divisions...
-proposed internet standard in the early 2000s for the streaming of binary and other encapsulated data over the Internet.
According to the IETF
Internet Engineering Task Force
The Internet Engineering Task Force develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite...
web site, the standard has been withdrawn and never made RFC
Request for Comments
In computer network engineering, a Request for Comments is a memorandum published by the Internet Engineering Task Force describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.Through the Internet Society, engineers and...
status. However, Microsoft did at one time recommend DIME for transmitting files via Web services. It was also used in Java EE, but differences in the implementation of the protocol made it difficult
The first version was submitted to the IETF in November 2001; the last update was submitted in June 2002. By December 2003, DIME had lost out, in competition with Message Transmission Optimization Mechanism and SOAP with Attachments
SOAP with Attachments
SOAP with Attachments or MIME for Web Services refers to the method of using Web Services to send and receive files using a combination of SOAP and MIME, primarily over HTTP....
,. Microsoft now describes DIME as "superseded by the SOAP Message Transmission Optimization Mechanism (MTOM) specification"
The standard was supposed to be an improved version of MIME
MIME
Multipurpose Internet Mail Extensions is an Internet standard that extends the format of email to support:* Text in character sets other than ASCII* Non-text attachments* Message bodies with multiple parts...
(see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service01152002.asp). In particular, the difficulty with MIME is that each message must be encoded as text, and that its sections are separated by a well-known separator given in the message header. This means, unfortunately, that the entire stream of data must be known to the sender before starting the communication, so as to choose a separator that does not occur in the data. This is not useful if the entire stream is not available when the communication is initiated, or when searching it even with a randomly-generated attempt at a unique separator (e.g. a GUID) is expensive. DIME was more oriented to streaming, allowing for example a receiver to process chunks of the message as they arrived, without having to wait for the entire message to arrive.
Problems with the HTTP
DIME was defined the transmission format at the data link layerData link layer
The data link layer is layer 2 of the seven-layer OSI model of computer networking. It corresponds to, or is part of the link layer of the TCP/IP reference model....
in the OSI model
OSI model
The Open Systems Interconnection model is a product of the Open Systems Interconnection effort at the International Organization for Standardization. It is a prescription of characterizing and standardizing the functions of a communications system in terms of abstraction layers. Similar...
although it was typically transmitted over HTTP. One difficulty here was that it could form an HTTP message of, essentially, any size (the limit being the size information for each chunk, which was 32 bits so 1 gigabit). Many HTTP receivers were unused to messages as large as this, and if they buffered messages would simply fail, expecting a short message and receiving a huge one. Moreover, if the HTTP receiver was secured, it would, on receiving the message, send back a challenge message (400 code) to the sender. Because HTTP is connectionless, it would then entirely lose the possibly huge amount of data that had been sent to it, just to accept or deny the challenge. There was no entirely satisfactory solution to this. The response to the challenge could of course succeed, at the expense of sending the data twice, which if it were huge rather defeats its point. (It is fair to say any other method of sending data over HTTP suffers the same problem.) In the alternate, and probably better solution, the criteria for a successful challenge (e.g. a username and password) is established out-of-band, so it can be sent with the message the first time and not receive a challenge (the by-product of the connectionless HTTP protocol being that since each message is treated individual, any message must be able successfully to include its challenge response).
DIME was extremely fast compared to practical applications of other protocols. Because the data was binary rather than, say, Base64
Base64
Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation...
encoded, it was relatively compact, and the chunking and packet methods built into the protocol meant it could be streamed and read by a suitable receiver before the whole message had been read.
Problems at the network layer
Because DIME was defined at the data link layer, it was possible to encapsulateInformation hiding
In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed...
a DIME message in another DIME message. This would not help at all for compression purposes, but was occasionally useful to bypass networking infrastructure such as routers at the network layer of the OS model, that would otherwise block the encapsulated traffic (being binary they may treat it with suspicion). That being said, other protocols such as MIME may equally suffer such. Since DIME was generally used between well-trusted clients, a specific port could be opened at the router for the express purpose of sending and receiving DIME traffic. This did not subvert the security aspects, since the challenge would still occur, merely that it accepted that binary traffic was the norm on that port, and not give numerous false positives.
External links
- Overview by MicrosoftMicrosoftMicrosoft Corporation is an American public multinational corporation headquartered in Redmond, Washington, USA that develops, manufactures, licenses, and supports a wide range of products and services predominantly related to computing through its various product divisions...
. - Links to articles about DIME
- Latest IETF draft
- Archives of the DIME Discussion list