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. 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 intended to be an improved version of MIME. 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. Criticisms Issues with HTTP 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,