Direct Internet Message Encapsulation

Last updated

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.

Contents

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.

Criticisms

Issues with HTTP

DIME was defined as the transmission format at the data link layer in the OSI modelalthough 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.

See also

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

<span class="mw-page-title-main">Internet Protocol version 4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

The Internet Protocol (IP) is the network layer communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet.

The Internet protocol suite, commonly known as TCP/IP, is a framework for organizing the set of communication protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). Early versions of this networking model were known as the Department of Defense (DoD) model because the research and development were funded by the United States Department of Defense through DARPA.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

<span class="mw-page-title-main">SOAP</span> Messaging protocol for web services

SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

The RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides out-of-band statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

In telecommunications and computer networking, connection-oriented communication is a communication protocol where a communication session or a semi-permanent connection is established before any useful data can be transferred. The established connection ensures that data is delivered in the correct order to the upper communication layer. The alternative is called connectionless communication, such as the datagram mode communication used by Internet Protocol (IP) and User Datagram Protocol, where data may be delivered out of order, since different network packets are routed independently and may be delivered over different paths.

IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. It is the IP-specific form of multicast and is used for streaming media and other network applications. It uses specially reserved multicast address blocks in IPv4 and IPv6.

Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. No knowledge of the data stream outside the currently-being-processed chunk is necessary for both the sender and the receiver at any given time.

The Stream Control Transmission Protocol (SCTP) has a simpler basic packet structure than TCP. Each consists of two basic sections:

  1. The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
  2. The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks (Chunk N) is highlighted in red. There are several types, including payload data and different control messages.

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge and Firefox support it. Safari implements the protocol, however it is not enabled by default.

NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.

References

  1. ↑ Nielsen, Henrik; Sanders, Henry; Christensen, Eric D.; Huitema, Christian (July 2002). "draft-nielsen-dime-00 Direct Internet Message Encapsulation (DIME)" . Retrieved 2021-02-11.
  2. ↑ Nielsen, Henrik; Sanders, Henry; Christensen, Eric D.; Huitema, Christian (July 2002). "draft-nielsen-dime-02 Direct Internet Message Encapsulation (DIME)" . Retrieved 2021-02-11.
  3. ↑ 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.
  4. ↑ "Messaging Specifications Index Page". Microsoft. Archived from the original on 2011-06-06. Retrieved 2006-10-31.
  5. ↑ "Technical documentation".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.