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. See also SOAP with Attachments References External links Overview by Microsoft. Links to articles about DIME Latest IETF draft Archives of the DIME Discussion list Microsoft initiatives Email Web services