ESRO: A Foundation for the Development of Efficient Protocols Mohsen Banan public@mohsen.banan.1.byname.net Version 1.3 First Published: August 4, 2000 Last Updated: August 9, 2000 Copyright fcl 2000 Mohsen Banan Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. A Component of The LEAP Manifesto This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the LEAP protocols. For the complete collection of articles see The LEAP Manifesto [16 ], available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Proto- cols Foundation website at http://www.FreeProtocols.org/LEAP/Manifesto/roadMap/index.html. 1 Contents 1 Overview of ESRO 4 1.1 The Need for ESRO . . . . . . . . . . . . 4 1.2 ESRO Requirements and Goals . . . . . . 5 1.3 Terminology . . . . . . . . . . . . . . . . 5 2 Other Related Protocols 6 2.1 RPC . . . . . . . . . . . . . . . . . . . . * * 6 2.2 ROSE . . . . . . . . . . . . . . . . . . . * * 6 2.3 WAP's WTP . . . . . . . . . . . . . . . . 7 2.4 T/TCP . . . . . . . . . . . . . . . . . . . * * 7 2.5 RDP . . . . . . . . . . . . . . . . . . . . * * 7 2.6 VMTP . . . . . . . . . . . . . . . . . . . * * 8 2.7 TCP . . . . . . . . . . . . . . . . . . . . * * 8 2.8 UDP . . . . . . . . . . . . . . . . . . . . * * 8 2.9 UDP Plus Ad Hoc Re-Transmissions . . . 8 3 The ESRO Protocol 9 3.1 Efficiency Characteristics of ESRO . . . . 10 3.2 Why We Adopted the Remote Operations Model . . . . . . . . . . . . . . . . . . . * * 10 3.3 RFC Publication of the ESRO Protocol . . 11 3.4 Maintenance of the ESRO Protocol via ESRO.org . . . . . . . . . . . . . . . . . 11 4 Use of ESRO 11 4.1 Common ESRO Application Design Con- siderations . . . . . . . . . . . . . . . . . * * 12 4.1.1 Presentation - Syntax and Encod- ing . . . . . . . . . . . . . . . . * * 12 4.1.2 Operation Reliability . . . . . . . 13 4.1.3 Idempotency - Duplication De- tection . . . . . . . . . . . . . . . * * 13 4.1.4 Failure Detection and Re-Tries . . 13 4.1.5 Segmentation/Re-Assembly . . . 14 4.1.6 Congestion Control and Flow Con- trol . . . . . . . . . . . . . . . . * * 14 4.1.7 Security . . . . . . . . . . . . . . * *15 2 5 Example Applications 15 5.1 Horizontal Applications . . . . . . . . . . 15 5.2 EMSD: Efficient E-Mail . . . . . . . . . 16 5.3 EHTD: Efficient Web Browsing . . . . . 16 5.4 Other Efficient Horizontal Applications . 16 5.5 Vertical Applications . . . . . . . . . . . 17 6 Existing Implementations of ESRO 17 6.1 ESROS Application Programming Interface 18 List of Figures 1 Anatomy of a Vertical Wireless Application 18 List of Tables 3 1 Overview of ESRO All efficient applications have the requirement for an ef- ficient transport mechanism. For this reason, part of the initial focus of the LEAP protocol development effort has been on creating a general efficient transport mechanism. The resulting protocol is referred to as Efficient Short Remote Operations, or ESRO. ESRO is the efficient transport layer protocol for several LEAP applications. ESRO is a reliable connectionless transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little. The need for efficient protocols extends across all as- pects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP archi- tecture accommodates many of these applications based on the use of ESRO. ESRO was published as RFC-2188 [25 ] in September of 1997. The ESRO protocol is publicly maintained and enhanced by ESRO.org at http://www.esro.org/. Patent free declarations have been made with respect to ESRO through the Free Protocols Foundation. 1.1 The Need for ESRO Considering that: - Many vertical applications in the wireless environ- ment need a reliable, efficient and lightweight data transfer mechanism. - Existing Internet transport protocols (TCP/UDP) do not address these requirements adequately. - Today, most vertical applications either implement their own ad hoc reliability service on top of UDP, or else use non-standard middleware. - A reliable connectionless transport protocol based on open specifications is needed. - Remote Operations is superior to reliable connec- tionless transport as an application development paradigm. ESRO has been designed to address these specific needs. The need to address the requirements that the ESRO protocol addresses has been well recognized for quite a long time. As early as 1995 such requirements were be- ing discussed within the Internet research community. In particular, RFC-955 [3 ], entitled "Towards a Transport 4 Service for Transaction Processing Applications," demon- strates recognition of the need for ESRO. A more re- cent document, RFC-2757 [18 ], entitled "Long Thin Net- works," again recognizes the demand for such a protocol. In the past, this unaddressed demand has given rise to a variety of product oriented proprietary solutions (as opposed to open protocols) which are often referred to as "Middleware Products." This has been particularly widespread in the wireless industry. Often these solutions are vendor specific and do not scale. 1.2 ESRO Requirements and Goals The requirements and goals driving the ESRO protocol and system design include the following: 1. Provide reliability in an efficient manner for a wide range of vertical applications (e.g. wireless). 2. Specify an Internet open protocol. 3. Minimize the number of transmissions. 4. Minimize the number of bytes transmitted. 5. Be fast; minimize latency. 6. Be power efficient, and show respect for the re- source limitations of mobile platforms, including memory, CPU, and battery power limitations. 7. Be lightweight; accommodate miniaturized devices. 1.3 Terminology A description of ESRO includes references to a number of basic data communications concepts and ideas. Be- cause of the informal, ad hoc, and often inconsistent ter- minology used within the Internet technical community, many of these concepts are referred to by a variety of dif- ferent names throughout various documents and RFCs. Many of the RFCs mentioned below refer to ESRO-related concepts in an inconsistent manner. In contrast to this, the ESRO specification uses the well defined and precise terminology of the "Open Sys- tems Interconnection Reference Model" [19 ]. In this pa- per we will also adhere to the same precise terminology. An example of the use of imprecise terminology is the term "Transaction Processing." Various other proto- col specifications refer to the concept of "Remote Op- 5 erations" as "Transaction Processing." In our terminol- ogy, however, Transaction Processing goes above and be- yond Remote Operations, and also includes the concepts of Commitment, Concurrency and Recovery, and chained (related) Remote Operations which may be built on top of ESRO. 2 Other Related Protocols The overall model of ESRO is similar to and consistent with many existing protocols. The distinguishing char- acteristic of ESRO is its efficiency. Also, the scope of ESRO is very narrow and well defined. The options and selections that it provides for are few and clear. A brief comparison of ESRO to other similar proto- cols is provided in the sections below. 2.1 RPC Remote Procedure Call (RPC) is specified in RFC-1831 [23 ] and RFC-1833 [22 ]. The RPC specifications define a remote procedure model that is essentially the same as ESRO. However, the nota- tion of RPC uses a syntax which is quite different from that of ESRO. RPC can rely on a connection-oriented or a connectionless transport mechanism. When using the connectionless mechanism, the retransmission and reli- ability issues are considered to be beyond the scope of the RPC specification. RPC is usually used in combi- nation with External Data Representation, XDR (RFC- 1832) [24 ]. When using RPC over UDP, no meaningful reliable transport mechanism is defined. For this reason use of RPC over UDP has been limited to LANs. 2.2 ROSE Remote Operations Services Element (ROSE) is speci- fied in [6 ] and [7 ]. ROSE is a complete and heavyweight traditional OSI application which assumes availability of all of the underlying OSI layers. The ESRO protocols can accomplish short operations with much less overhead than ROSE. 6 2.3 WAP's WTP The Wireless Appliction Protocol (WAP) includes a layer which is similar to ESRO, called "Wireless Transaction Protocol" (WTP) [1 ]. The WTP specification was published after ESRO was published, and is similar in functionality to ESRO. In many ways WTP can be considered to be patterned af- ter ESRO; however, WTP is in fact a step backwards. The clear and simple Remote Operations model of ESRO is renamed as "Wireless Transactions" in an inap- propriate context. The notation specification conventions are not used, and the state machines are not as robust. More importantly, the WTP specifications are not sta- ble, have not been published as Internet RFCs, and have not been declared to be patent free. As early as 1995, those involved in the development of WTP were made aware of LSROS and ESRO. The only reason we know of for their re-specification of WTP, rather than re-use of ESRO, is the WAP Forum's desire for control. More details on the problems of the WAP Forum's approach are provided in the article The WAP Trap [17 ]. 2.4 T/TCP Transaction/TCP is specified in [4 ] and [5 ]. T/TCP is a backwards-compatible extension of TCP which provides efficient transaction-oriented service in addition to virtual- circuit service. Use of T/TCP often involves replacing existing TCP implementations. This non-evolutionary aspect of T/TCP is one of the reasons why T/TCP has not been widely adopted. Various lessons can be learned from why T/TCP has not been widely adopted. 2.5 RDP Reliable Data Protocol (RDP) is specified in [10 ] and [9 ]. RDP can be considered to be a specialized TCP, spec- ified for particular circumstances in which some of TCP's facilities are needed. One of the reasons why RDP has not been heavily used is because the set of specialized circumstances that it addresses do not justify the cost of implementing it. RDP 7 allows for many options and selections, which makes its use difficult. Various lessons can be learned from why RDP has not been widely adopted. 2.6 VMTP Versatile Message Transaction Protocol (VMTP) is spec- ified in [8 ]. VMTP can be considered to be a specialized transport protocol, targeted for what it calls the transaction model of communications. One of the reasons why VMTP has not been heavily used is because it tries to address too broad of a software engineering-centric model. VMTP allows for many op- tions and selections, which makes its use difficult. Various lessons can be learned from why VMTP has not been widely adopted. 2.7 TCP Transmission Control Protocol (TCP) is specified in [21 ] and [5 ]. TCP is mature, well understood and stable. Congen- stion control and flow control mechanisms for TCP have been developed over the years, and incorporated into TCP implementations. The simplest and shortest TCP interaction involves 5 PDU exchanges. For applications wishing to accomplish short and occasional communications in less than 5 PDU exchanges, ESRO is more efficient that TCP. 2.8 UDP UDP (User Datagram Protocol) is specified in [20 ]. UDP is a very simple and thin layer on top of IP, which does not provide reliability or sequence ordering. Applications requiring a reliable connectionless transport need to build on top of UDP. ESRO provide an efficient and reliable transport service on top of UDP. 2.9 UDP Plus Ad Hoc Re-Transmissions Various protocols have added their own specific re-transmission policies on top of UDP to make it more reliable. 8 Examples of such efforts include the Domain Name System (DNS) [12 ] [13 ], Network Time Protocol (NTP) [11 ], and NNTP for Usenet News Reading. These efforts have all resulted in incomplete and lim- ited solutions. The problems with such approaches were understood as early as 1985 [3 ]. 3 The ESRO Protocol The ESRO specification describes the service model, the notation and the protocol for Efficient Short Remote Op- erations (ESRO). The ESRO service is similar to and is consistent with other Remote Operation and Remote Pro- cedure Call services. The emphasis of the ESRO ser- vice definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g. CDPD) usage in mind. The ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with min- imum overhead. ESRO supports segmentation and re- assembly, concatenation and separation, as well as multi- plexing for service users (applications). ESRO allows for trade-offs between efficiency and re- liability by specifying both 2-way handshake and 3-way handshake based protocols. The ESRO specifications also define a notation and the services provided by an application-service element to support interactive applications in a distributed sys- tems environment. A Remote Operation is invoked by one entity; the other entity attempts to perform the Re- mote Operation and then reports the outcome of the at- tempt. Encoding mechanisms for presentation of the param- eters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mech- anism in use (e.g. XDR, BER, PER) is supported by ESRO. A variety of applications can use the ESRO protocol. Some early applications which use ESRO include: effi- cient short message submission and delivery, credit card authorization, and white pages lookup. 9 3.1 Efficiency Characteristics of ESRO The key requirement driving the design of ESRO is effi- ciency. Reliable transfer of a short message using TCP involves 5 transmissions at a minimum. Reliable trans- fer of a short message using ESRO involves only 3 or 2 transmissions. For many applications in which optimization of effi- cency is desired, it is likely that elimination of the extra 2 transmissions which are inherent to TCP, justifies devia- tion from it and use of ESRO instead. The efficiency premium realized by the use of ESRO rather than TCP can be very significant. For example, EMSD (a mail submission and delivery protocol that uses ESRO) can be upto 5 times more efficient than SMTP, while maintaining precisely the same level of reliabil- ity and security. The paper entitled "Efficiency Study of EMSD vs. SMTP/POP3/IMAP" [14 ] quantifies the effi- ciency of ESRO in comparison to traditional TCP based applications. 3.2 Why We Adopted the Remote Opera- tions Model ESRO is a reliable connectionless transport mechanism. A reasonable question is: Why did we design ESRO's service interface to be based on the Remote Operations model? Many Internet protocols are "text-based" on top of TCP. And the "here is some text" followed by "here is some more text" followed by "here is some text in re- sponse" has become the tradition of simple Internet pro- tocols. Protocols designed on the basis of this "text-based" approach have a good track record of acceptance through- out the Internet, primarily because they are simple to un- derstand and simple to implement. When efficiency matters, however, the traditional text exchange model can be better expressed by the client re- questing a particular operation from the server, and the server responding with the results of that operation, thereby eliminating the traditional "text-based" chit-chat. With such an approach, the design of the protocol becomes a natural fit for the remote operations model. For short interactions, a reliable connectionless trans- port mechanism and the Remote Operations model are simply the same thing. The formalism of Remote Opera- tions is an asset that ESRO exploits. 10 ESRO provides a service which supports interaction of applications based on a remote operation model. A Remote Operation is invoked by one entity; the other en- tity attempts to perform the Remote Operation and then reports the outcome of the attempt. The ESRO protocol is designed to be able to support a large variety of appli- cations. 3.3 RFC Publication of the ESRO Protocol The ESRO protocol is completely open. It has been pub- lished as RFC-2188. For information on how to obtain the ESRO protocol, visit the "Base Protocol Specifications" section of http://www.esro.org/. 3.4 Maintenance of the ESRO Protocol via ESRO.org ESRO.org is a public organization which enables and fa- cilitates the development, maintenance and enhancement of protocols and related technologies which address the efficiency requirements of generic Internet applications. Anyone interested in participating in the development of the ESRO protocol can join ESRO.org by visiting the "Joining the ESRO.org and Related Mailing Lists" sec- tion of http://www.esro.org/. Patent-free declarations have been made with respect to ESRO and RFC-2188 through the Free Protocols Foun- dation. 4 Use of ESRO The ESRO protocol is designed to be able to support many applications, such as mobile messaging, directory ser- vices, micro-browsers, dictionary lookup (white and yel- low pages), data sensors monitoring, telemetry, dispatch, and credit card authorization applications. In this section we discuss various considerations that protocol developers and application designers should make when designing applications which use ESRO. We then build on this by providing various examples. 11 4.1 Common ESRO Application Design Con- siderations When designing applications which use ESRO services, a number of common issues often need to be considered. These include: - Presentation - Syntax and Encoding - Operation Reliability - Idempotency - Duplication Detection - Failure Detection and Re-Tries - Segmentation/Re-Assembly - Congestion and Flow Control - Security Considerations: Authentication, Confiden- tiality, Authorization We discuss each of these in some detail below. 4.1.1 Presentation - Syntax and Encoding Using the remote operations model, Argument, Result and Error parameters are communicated between the in- voker and the performer. The application designer must choose and specify the particular syntax and encoding to be used. Encoding mechanisms for presentation of the param- eters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mech- anism in use is supported by ESRO. The choice of encoding mechanism by the develop- ers often revolves around the efficiency requirements, the complexity of the application to be designed, the avail- ability of tools (e.g. XML, XDR, ASN parser and com- pilers) and the familiarity of the developer with the tools. ESRO can accomodate any syntax and encoding, in- cluding: plain text, XML, ASN.1 (BER, PER etc.) and XDR. The ESRO specification introduces one notation in ASN.1 for representation of Operations. This in no way ties the use of ESRO to ASN.1. Any syntax and encoding can be used, and use of any notation for representation of Operations is not mandatory. 12 4.1.2 Operation Reliability Different applications may need various levels of failure detection for various operations. Any one of the follow- ing three methods may be needed to accomplish the de- sired reliability and semantics of various aspects of appli- cations: - 2-Way Handshake - 3-Way Handshake - 3-Way Handshake with Verify An example of the usage of all three of the above methods is provided by EMSD [2 ]. 4.1.3 Idempotency - Duplication Detection Some operations are idempotent in nature, that is, they can be performed more than once without causing harm. However, other operations are non-idempotent, and should therefore be performed only once. In the case of non- idempotent operations, the performer should be able to detect duplicate operations, and perform each non-idempotent operation only once. Examples of non-idempotent operations are Submis- sion and Delivery of messages, which should not be per- formed more than once. Examples of idempotent oper- ations are enquiries of date and time, which can be per- formed more than once without harm. ESRO Services do not detect duplicate invocation of operations. As a result, the application should detect du- plication when the same operation instance is invoked more than once. An example of how this can be accomplished in a co- herent manner can be found in Section 4 of RFC-2524, entitled "Duplicate Operation Detection Support" [2 ]. 4.1.4 Failure Detection and Re-Tries Based on ESRO's notification of Failures, the application must take necessary measures to re-try the operation. Depending on the nature of the application, use of a general spooler which supports persistence may be rea- sonable. 13 4.1.5 Segmentation/Re-Assembly ESRO provides Segmentation and Re-Assembly, as well as Concatenation and Separation, inside the protocol. How- ever, an application may choose to provide segmentation and re-assembly above ESRO services. The specific requirements of the application and the nature of the networks in use may justify such a design. 4.1.6 Congestion Control and Flow Control The ESRO protocol includes flow control, and allows for various re-transmission timers policies to be implemented. Such policies may include exponential back-off and adap- tive retransmission algorithms. These allow for the use of self-adjusting timers to determine and dynamically set timers to effectively adjust data traffic in the event the link is slower than usual due to congestion or other network or system conditions. However, specification of retransmission timers poli- cies was deliberately not included in the ESRO protocol. Often ESRO will be used on the edges of the Internet, where the characteristics of network behavior between the Invoker and the Performer are deterministic and sta- ble. In such environments, a custom re-transmission timers policies is more effective than a generic one. For exam- ple, timer profiles specific to CDPD or GSM wide area networks which assume the servers are at the edges of the Internet can be tailored to optimize performance. In practice, early usages of ESRO are likely to be in such environments. Congestion Control was also deliberately not included in the ESRO protocol, and is intended to sit on top of ESRO. This is for two reasons. First, indications of congestion in the IP protocol suite violate layering principles, and use of such indications would have made the congestion control mechanism lim- ited to IP. Use of ESRO over non-IP packet networks (such as GSM) is highly desirable in the short term. Second, the indication and source congestion need not be limited to purely network resources, and indica- tions of congestion may come from a variety of sources. In practice, ESRO based congestion control is primarily server driven. Design of ESRO applications should in- clude Congestion Control mechanisms. An example of how Congestion Control on top of ESRO may be designed can be found in SubmissionCon- trol and DeliveryControl sections of RFC-2524, [2 ]. Such 14 control facilities and design makes use of ESRO and EMSD well suited for the End-To-End Internet usage model. 4.1.7 Security Different applications may need various levels of security facilities. It is the requirements and scope of the individ- ual application that drives the nature of security facilities that are appropriate to use. In many cases, the key required security facilities are Authentication, Confidentiality and Authorization. The trade-offs between complexity, efficiency and reliability are best made on a case-by-case basis. In the specific case of Efficient Mail Submission & Delivery (EMSD) [2 ], the existing mainstream Internet security mechanism of Pretty Good Privacy (PGP) can be used to provide end-to-end security facilities. As an underlying general facility, ESRO itself does not provide any generalized security facilities. At some point in time, it makes good sense to create a common security framework for LEAP which is consistent with the broader Internet security framework. We will start incorporating common security features when they become widespread in the broader Internet. When Network Layer Security, Transport Layer Security, PKI, etc. are widespread, they will be incorporated as common facilities within LEAP. 5 Example Applications A variety of applications can make use of the ESRO pro- tocol. In this section we mention and provide references to a number of ESRO based applications. Based on the broadness of their usage and intended audience, we cate- gorize them as either "Horizontal Applications" or "Ver- tical Applications." 5.1 Horizontal Applications Various efficient horizontal applications have been devel- oped or are being developed using ESRO. These include: - EMSD: Mobile and Wireless Messaging, Modern Two-Way Paging - EHTD: Efficient Micro-Browsing 15 - E-DICT: Efficient Dictionary Lookup A brief description of each is provided below. 5.2 EMSD: Efficient E-Mail One of the efficient application layers built on top of ESRO is called Efficient Mail Submission & Delivery, or EMSD. EMSD is the component of LEAP that addresses the Mo- bile Messaging application. EMSD is highly optimized for the submission and de- livery of short (typically 4 kilobytes or less) Internet e- mail messages, and is therefore extremely well suited to the wireless environment. EMSD improves on existing messaging protocols by optimizing the exchange between the server and the end-user device, both in terms of the number of bytes transferred, and in terms of the number of transmissions. For more information on EMSD see the article EMSD: The LEAP E-Mail Component within The LEAP Manifesto, or visit the EMSD website at http://www.emsd.org/. 5.3 EHTD: Efficient Web Browsing The Efficient Hyper Text Delivery (EHTD) layer is a hy- pertext transfer protocol which is optimized for the effi- cient transfer of short markup pages. EHTD is the com- ponent of LEAP which facilitates web browsing. Along with EMSD, EHTD also benefits from the reliable effi- cient services of ESRO. A multiplicity of efficient markup languages can be used in conjunction with EHTD. Devel- opment of the EHTD protocol is currently in progress. 5.4 Other Efficient Horizontal Applications Various other efficient application protocols are either un- der development, or anticipated for future development. One of these is the Efficient Dictionary protocol, or E- DICT, which will enable efficient access to dictionaries and other lookup data structures. A starting point for the E-DICT protocol is currently being created. In develop- ing E-DICT, we intend to build on the existing work al- ready done in the context of the DICT protocol. We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others. 16 5.5 Vertical Applications Various efficient vertical applications have been devel- oped or are being developed using ESRO. These appli- cations include: - Wireless credit card verification - Wireless automated teller machine (ATM) - Dispatch applications - Telemetry - Wireless T.V. ratings - Vehicle tracking (GPS applications etc.) There are a set of common architectural characteris- tics to most of these vertical applications. These common characteristics are illustrated in Figure 1. In this figure, the box labeled "Thin Reliability Layer" represents the position of ESRO. The combination of ESRO as the efficient transport mechanism, the systems modeling represented in Figure 1, and the methods described in Section 4.1 can greatly facilitate and expedite development of efficient vertical applications. 6 Existing Implementations of ESRO A Reference Implementation of ESRO in the form of free software in open-source format is being made available at http://www.MailMeAnywhere.org/. We expect to have the ESRO protocol engine software components subject to the GNU General Public License available at this location by September 2000. On the device side, software will be made available for most generic platforms, including PalmOS, EPOC, WindowsCE, Windows9X, and Windows-NT. On the server side, software will be available on Solaris, Linux and NT. In addition to open-source format, the ESRO Refer- ence Implementation will also be made available for the above mentioned platforms as a ready-to-use Toolkit. For a current list of ESRO free and commercial soft- ware products, visit the "Products and Services" section of http://www.esro.org. 17 Figure 1: Anatomy of a Vertical Wireless Application 6.1 ESROS Application Programming In- terface The "ESRO API Specification" [15 ] defines the ESRO Application Programming Interface (API). This specifi- cation maps ESRO service primitives into C language function calls. This document is available at http://www.esro.org/documents/API.html. References [1] WAP Wireless Transaction Protocol Specification, February 2000. The WAP-201-WTP article available at http://www.wapforum.org/what/technical.htm. [2] M. Banan. Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 18 1.3. Request for Comments (Informational) 2524, Neda Communications, Inc., February 1999. On- line document is available at ftp://ftp.isi.edu/in- notes/rfc2524.txt. [3] B. Braden. Towards a transport service for trans- action processing applications. RFC 955, Internet Engineering Task Force, September 1985. [4] B. Braden. Extending TCP for transactions - con- cepts. Request for Comments (Informational) 1379, Internet Engineering Task Force, November 1992. [5] B. Braden. T/TCP - TCP extensions for transac- tions functional specification. Request for Com- ments (Experimental) 1644, Internet Engineering Task Force, July 1994. [6] Remote Operations: Model, Notation and Service Definition. The International Telegraph and Tele- phone Consultative Committee, March 1988. Rec- ommendation X.219. [7] Remote Operations: Protocol Specification. The International Telegraph and Telephone Consultative Committee, March 1988. Recommendation X.229. [8] D. Cheriton. VMTP: versatile message transaction protocol: Protocol specification. Request for Com- ments (Experimental) 1045, Internet Engineering Task Force, February 1988. [9] B. Hinden and C. Partridge. Version 2 of the reliable data protocol (RDP). Request for Comments (Ex- perimental) 1151, Internet Engineering Task Force, April 1990. [10] B. Hinden and J. Sax. Reliable data protocol. Re- quest for Comments (Experimental) 908, Internet Engineering Task Force, July 1984. (Updated by RFC1151). [11] D. Mills. Network time protocol (v3). Request for Comments (Draft Standard) 1305, Internet En- gineering Task Force, April 1992. (Obsoletes RFC1119). [12] P. Mockapetris. Domain names - concepts and fa- cilities. Request for Comments (Standard) STD 13, 1034, Internet Engineering Task Force, November 1987. (Obsoletes RFC882); (Obsoletes RFC883); (Obsoletes RFC973); (Obsoleted by RFC2065); (Updated by RFC1101); (Updated by RFC1876); (Updated by RFC1982); (Updated by RFC2181); (Updated by RFC2308). 19 [13] P. Mockapetris. Domain names - implementation and specification. Request for Comments (Stan- dard) STD 13, 1035, Internet Engineering Task Force, November 1987. (Obsoletes RFC973); (Ob- soleted by RFC2136); (Obsoleted by RFC2137); (Updated by RFC1348); (Updated by RFC1995); (Updated by RFC1996); (Updated by RFC2065); (Updated by RFC2181); (Updated by RFC2308). [14] Mohsen Banan. Efficiency Study of EMSD vs. SMTP/POP3/IMAP. Neda Published Document 103-101-01.01, EMSD Organiza- tion, 1996. Online document is available at http://www.emsd.org/pubs/biblio/103-101-01- 01/index.html. [15] Mohsen Banan. ESROS Application Programming Interface. Neda Published Document 103-101- 06.03, ESRO Organization, 1996. Online document is available at http://www.esro.org/pubs/biblio/103- 101-06-03/index.html. [16] Mohsen Banan. Lightweight & Efficient Applica- tion Protocol (LEAP) Manifesto. Technical Re- port 108-101-01, LEAP Forum, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-101- 01/index.html. [17] Mohsen Banan. The WAP Trap. FPF Pub- lished Document 108-102-01, Free Proto- cols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108- 102-01/index.html. [18] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, and N. Vaidya. Long Thin Networks. Request for Comments (Informational) 2757, The Internet Soci- ety, January 2000. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2757.txt. [19] Information Processing Systems _ Open Systems Interconnection: Basic Reference Model. Interna- tional Organization for Standardization and Inter- national Electrotechnical Committee, 1984. Inter- ational Standard 7498. [20] J. Postel. User datagram protocol. Request for Comments (Standard) STD 6, 768, Internet Engi- neering Task Force, August 1980. [21] J. Postel. Transmission control protocol. Request for Comments (Standard) STD 7, 793, Internet En- 20 gineering Task Force, September 1981. (Obsoletes RFC761). [22] R. Srinivasan. Binding protocols for ONC RPC version 2. Request for Comments (Proposed Stan- dard) 1833, Internet Engineering Task Force, Au- gust 1995. [23] R. Srinivasan. RPC: remote procedure call pro- tocol specification version 2. Request for Com- ments (Proposed Standard) 1831, Internet Engineer- ing Task Force, August 1995. [24] R. Srinivasan. XDR: external data representation standard. Request for Comments (Proposed Stan- dard) 1832, Internet Engineering Task Force, Au- gust 1995. [25] M. Taylor, J. Cheng, and M. Banan. AT&T/Neda's Efficient Short Remote Operations (ESRO) Proto- col Specification Version 1.2. Request for Com- ments (Informational) 2188, Neda Communica- tions, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2188.txt. 21