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 website, 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.[citation needed]
The first version[1] was submitted to the IETF in November 2001; the last update[2] was submitted in June 2002. By December 2003, DIME had lost out, in competition with Message Transmission Optimization Mechanism and SOAP with Attachments.[3] Microsoft now describes DIME as "superseded by the SOAP Message Transmission Optimization Mechanism (MTOM) specification"[4]
The standard was intended to be an improved version of MIME.[5] In particular a difficulty with MIME is that each message must be encoded as text and that its sections are separated by a separator given in the message header. This means 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 is expensive. DIME is more oriented to streaming, allowing, for example, a receiver to process chunks of the message as they arrive without having to wait for the entire message.
DIME was defined as the transmission format at the data link layer 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 not used to messages as large as this, and if they buffered messages would simply fail, due to the fact that the software expected a short message, but instead received a long one. Moreover, if the HTTP receiver was secured, it would, send back a challenge message (400 code) to the sender upon receiving the message. 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. 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.
In the alternate 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.
Issues at the Network Layer
Because DIME was defined at the data link layer, it was possible to encapsulate 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, which 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 did not give numerous false positives.
^Nielsen, Henrik; Sanders, Henry; Christensen, Eric D.; Huitema, Christian (July 2002). "draft-nielsen-dime-00 Direct Internet Message Encapsulation (DIME)". Retrieved 2021-02-11.
^Nielsen, Henrik; Sanders, Henry; Christensen, Eric D.; Huitema, Christian (July 2002). "draft-nielsen-dime-02 Direct Internet Message Encapsulation (DIME)". Retrieved 2021-02-11.
^Salz, Rich (2003-12-12). . Archived from the original on 2007-09-27. Retrieved 2006-10-31.
^. Microsoft. Archived from the original on 2011-06-06. Retrieved 2006-10-31.
Archives of the DIME Discussion list 2006-12-05 at the Wayback Machine
October 27, 2023
direct, internet, message, encapsulation, dime, microsoft, proposed, internet, standard, early, 2000s, streaming, binary, other, encapsulated, data, over, internet, according, ietf, website, standard, been, withdrawn, never, made, status, however, microsoft, t. 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 website 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 citation needed The first version 1 was submitted to the IETF in November 2001 the last update 2 was submitted in June 2002 By December 2003 DIME had lost out in competition with Message Transmission Optimization Mechanism and SOAP with Attachments 3 Microsoft now describes DIME as superseded by the SOAP Message Transmission Optimization Mechanism MTOM specification 4 The standard was intended to be an improved version of MIME 5 In particular a difficulty with MIME is that each message must be encoded as text and that its sections are separated by a separator given in the message header This means 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 is expensive DIME is more oriented to streaming allowing for example a receiver to process chunks of the message as they arrive without having to wait for the entire message Contents 1 Criticisms 2 See also 3 References 4 External linksCriticisms editIssues with HTTPDIME was defined as the transmission format at the data link layer 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 not used to messages as large as this and if they buffered messages would simply fail due to the fact that the software expected a short message but instead received a long one Moreover if the HTTP receiver was secured it would send back a challenge message 400 code to the sender upon receiving the message 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 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 In the alternate 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 Issues at the Network LayerBecause DIME was defined at the data link layer it was possible to encapsulate 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 which 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 did not give numerous false positives See also editSOAP with AttachmentsReferences edit Nielsen Henrik Sanders Henry Christensen Eric D Huitema Christian July 2002 draft nielsen dime 00 Direct Internet Message Encapsulation DIME Retrieved 2021 02 11 Nielsen Henrik Sanders Henry Christensen Eric D Huitema Christian July 2002 draft nielsen dime 02 Direct Internet Message Encapsulation DIME Retrieved 2021 02 11 Salz Rich 2003 12 12 Re Where can I find out about the current status of DIME Archived from the original on 2007 09 27 Retrieved 2006 10 31 Messaging Specifications Index Page Microsoft Archived from the original on 2011 06 06 Retrieved 2006 10 31 Technical documentation External links editOverview by Microsoft Links to articles about DIME Latest IETF draft Archives of the DIME Discussion list Archived 2006 12 05 at the Wayback Machine Retrieved from https en wikipedia org w index php title Direct Internet Message Encapsulation amp oldid 1152878576, wikipedia, wiki, book, books, library,
