Internet Engineering Task Force IMPP WG Internet Draft Dave Crocker Brandenburg Consulting Athanassios Diacakis Network Projects Inc. Christian Huitema Microsoft Corporation Graham Klyne Content Technologies Limited Florencio Mazzoldi Network Projects Inc. Marshall T. Rose Invisible Worlds, Inc. Jonathan Rosenberg dynamicsoft Robert Sparks dynamicsoft Hiroyasu Sugano Fujitsu Laboratories Ltd. draft-rosenberg-impp-differences-00.txt August 18, 2000 Expires: February 2001 A Framework for Moving IMPP Forward STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents the summary of the findings of the IMPP group of nine that were selected to study the common components and fundamental differences among the three proposals. 1 Introduction At the conclusion of the IMPP working group meeting in Pittsburgh in August of 2000, it was agreed that a team of nine individuals, three from each of the three protocol camps, would spend two weeks coming up with a set of commonalities and differences amongst the various protocol proposals. This document represents the output of that work. It presents a high level overview of what we agreed was common, and then describes the different approaches taken by the three proposals and how they fundamentally differ. A companion document describes the The Nine [Page 1] Internet Draft IM August 18, 2000 details of the common components. 2 Commonalities There was agreement that it must be possible to build gateways between IMPP protocol islands such that the services required by RFC 2779 [1] can, at a mimimum, be interworked between islands. To accomplish this, an abstract protocol, conformant to rfc2779, was defined. It was agreed that all IMPP protocols would need to define a mapping to this abstract protocol, as proof that interworking between islands would be possible. This abstract protocol is described in [2]. The abstract protocol provides subscription, notification, and instant messaging capabilities. It defines protocol parameters that are needed, at a minimum, for successful interworking. There was also agreement on a common addressing format. An IM URL and presence URL formats were defined. It was agreed that all IMPP protocols would be required to carry these URL formats as the identifications for the various entities in the system (presentities, watcher addresses, etc.). It was also agreed that each protocol could define its own native URL formats (i.e., the SIP proposal would also use sip URLs). When communicating with a foreign domain, the foreign domain would be required to list an SRV or A record for its domain listing a gateway server. This gateway would be required to understand protocol messages from all other islands, convert them to its own protocol, and additionally know how to convert the global URL to a native URL format. Details were defined and are described in [2]. There was agreement that all IMPP protocols would be required to use MIME for transport of instant messages and presence data. Furthermore, it was agreed that a common format for presence data would be defined. This format, based on XML, represents the minimal presence format compliant to RFC 2779, and is based on the data model described in RFC 2778 [3]. This allows gateways to simply copy the content from one protocol to another with zero loss of information. The presence format is defined in [2]. There was agreement that end to end authentication and encryption would be supported through gateways using MIME security techniques, including PGP-MIME [4] and S/MIME [5]. 3 Differences Despite these common components, it was clear that the three groups represent fundamentally different approaches to solving the problems The Nine [Page 2] Internet Draft IM August 18, 2000 of IMPP, and that these approaches are not easily reconciled. The subsections which follow describe the differing approaches in more detail. Each section is written by a representative from the respective view. This draft is not an endorsement from the nine for any one, or all, approaches. 3.1 The Session Initiation Protocol The primary advantage that we see with the SIP proposal is the way in which it can integrate voice, video, and other interactive communications services with instant messaging and presence. There are three aspects of this integration - integration of infrastructure, integration of services, and integration of software. The result are benefits to service providers, users, and implementors, respectively. Integration of infrastructure is about reuse. We believe service providers will want to have a single network used to provide the communications services of its customers - voice, video, IM or presence. By basing the IMPP standard on SIP, this becomes achievable. The same proxy servers used in SIP to route calls can route IMs, and they can route presence data. The same data repositories used for storing users' location for calls, can also be used for storing users' locations for IMs, and also their location for presence services. It is not mearly a reuse of the databases, but the data itself. The same SIP phones used to receive calls can instantly become publishers of presence information. This kind of integration of infrastructure results in significant benefits for the service provider. The management and operational costs of running a communications service are vastly reduced, since the addition of presence and IM to an existing SIP network is nowhere close to the costs of building and running a completely separate, parallel network. The equipment costs themselves are reduced, since only one set of proxy and location servers are needed, rather than two. System capacity is improved, since resources can be shared across many services. Infrastructure investments in firewalls, mobility services, etc. that have been put in place for supporting SIP can also be reused. Service providers have also invested a serious amount of intellectual capital in SIP; reusing SIP means these providers have a much shorter learning curve. From the users perspective, the primary benefit is integration of services. Voice, video, IM and presence are all simply different aspects of the general problem of interpersonal interactive communications. Many features and services used in one domain make a The Nine [Page 3] Internet Draft IM August 18, 2000 lot of sense in the other. Take, for example, call screening, which can prevent incoming calls from specific users. A very desirable service would be to extend this to IM - that person can neither call, send an IM, or subscribe to the user of this feature. Development, provisioning, and deployment of these kinds of integrated features is vastly simplified by a single network that provides them. If IM and presence and voice where each separate protocol clouds, it would require separate code, running on separate networks, maintained separately, and kept synchronized. However, if these services all ran on the same network, providing such integrated services would be simple, if not for free (the above service is for free in a SIP proxy, as these provide such services on a method independent basis). As another example, the IP Telephony working group in IETF (iptel) has nearly completed specification of the Call Processing Language (cpl), and XML based scripting language that allows users to define their own services for SIP. CPL enables screening, forwarding, filtering, and notification types of services. For example, a CPL can be written which specifies that calls from Joe are forwarded to a unified messaging server after 5pm, all other calls are routing to a mobile PDA. The specification of the service is method independent; this means this CPL and all the related CPL infrastructure in the network would allow this service to be extended to instant messaging with no additional work. This would allow users to customize their own IM, presence and multimedia services with the same tools. By using a different protocol, or even by modifying SIP in some way for this application, the above benefits are lost. Service providers will not be able to run IM and presence on their deployed SIP networks. Therefore, for service providers deploying SIP networks, there is but a single realistic choice. Choosing a different protocol, or even a modified SIP, results in such substantially higher costs that it acts as a barrier to entering the market. From the implementors perspective, the primary issue is cost and time to market. By using SIP, implementors can readily obtain one of the many existing software development kits and libraries, and build upon that. Both open source and commercial code is available. For implementors who already have their own SIP code, building ontop of that instead of building from scratch is a clear win. There are nearly one hundred seperate implementations of SIP; many from groups which wish to build IM and presence solutions as well as multimedia communications solutions. There are also numerous testing and load generation tools available for SIP; these too can be reused for building IM and presence systems. For this reason, we believe that choosing a single, non-SIP based solution for presence and IM is a non-starter. There is a significant The Nine [Page 4] Internet Draft IM August 18, 2000 community of interest, among both service providers and software manufacturers, for a SIP based solution. 3.2 The IMXP The basic philosophy of IMXP is: o The core mechanism is kept to a minimum: Anything that can be built using the core mechanism is excluded from the core. o Design is based on familiar Internet mail architecture: Applies a wealth of related experience, making the architecture choices extremely safe. The IMXP relay mesh uses lightweight, near-real-time application datagram transfer nodes, analogous to email MTAs: o Relay processing is kept simple: Essential intelligence is kept at or near the network edge to enhance scalability; relays are not required to maintain state concerning message transfer. o Addressing and routing follow the classic email model: This is safely scalable, providing hierarchical addresses (domain names) that can be understood by the entire relay mesh. o Hop-by-hop security framework: Authentication, privacy, and authorization rely on domains "keeping their own houses in order", in line with current Internet infrastructure. End to end security (OpenPGP or S/MIME) may be added to provide better security, but require (pending) PKI deployment. o Transport independence: A convergence layer (BEEP) carries IMXP identically over variety of transports. o Other applications may use the same service: Asynchronous near-real-time message exchange with accessible, predictable behaviour for loosely-coupled applications. In summary, we require than each part of solution must carry its full weight in the overall scheme. It is not enough that the parts of the solution are individually good: all core elements are needed to fulfill essential IM functions, or to provide hooks for building such functions. The design re-applies the lessons of Internet scaling to application design, aiming for minimum processing performed in the network, unimpeded end-to-end transfer of information, and services added at the network edge. The Nine [Page 5] Internet Draft IM August 18, 2000 3.3 PRIM: Presence and Instant Messaging The authors of several IMPP proposals, namely PePP, PITP/IMTP, OneIM, and SIMP, have agreed and actually started working to make a joint proposal based on our existing drafts. Our protocols have extended architectural similarities, and we believe that those are attributed to the fact that our design is based on RFC2778-2779 and consensus formed in the IMPP community so far. In summary, our aim is to develop a minimal specification, which satisfies the IMPP requirements. 3.3.1 PRIM Design Transfer protocol directly atop of TCP: We assume TCP as basic transport mechanism for instant messages and presence information. TCP provides sufficiently reliable transport infrastructure and we think instant messaging (IM) and presence services require this level of reliability. In addition, we design both IM and presence protocols directly atop of TCP. Although these are tightly related services, their characteristics are different in several points. This decision makes the protocols quite simple and lightweight. Long-lived Client/Server connections: Our protocols use long- lived client/server connections in order for clients to receive instant messages and presence notifications. This brings the following advantages. As we adopt TCP as IM and presence transport, use of existing connections reduce much overhead of re-establishing connections and per-connection authentication. This feature is fairly important in the case of some uses where presence notifications are frequent. Once the connection peer (the home domain server) is authenticated, additional authentication for IMs and notification messages may be omitted in the case the home domain servers and the inter-domain relation is considered fully trustworthy. When clients are behind firewalls and connect to the servers outside, using long-lived TCP connections to receive messages from the servers is a practical solution. This situation is quite common at present to utilize the existing IM service providers. Selective Presence Publication: RFC2779 stipulates various requirements for access control; 2.3.x and some of section 5. Among them, we consider the feature of "Polite Blocking" (5.1.15, 5.2.3) very important for presence services. Our proposal contains the mechanism of such selective presence The Nine [Page 6] Internet Draft IM August 18, 2000 publication and the in-band access control mechanism. 3.3.2 Our Perspective We believe that the authors of the various proposals (as grouped by the WG chairs) have different expectations from an IMP protocol. We expect a Presence and IM protocol to have the following characteristics (in no particular order): o It does not carry unnecessary features. The WG was given the task to produce a protocol with a certain feature-set (RFC2779). Extra features can be nice, but should not exist in this protocol, or should be built elsewhere. o It maps well on existing Presence and IM offerings. The migration to the standard should be as painless and seamless as possible. This would remove barriers to adoption. o Existing Presence and IM offerings use architectures that map well on Group 2 proposals. As a result there is a lot of experience on how those architectures perform in solving the Presence and IM requirements. o It is simple and easily understood by developers who will need to implement it. There are a lot of people on the WG that perceive non-Group 2 proposals to be unnecessarily complicated. o It is independent from the work currently being done in other WGs. There is a sense of urgency in producing an IMP protocol, and introducing unnecessary links (that might turn into critical dependencies) to other WG does not help. Work currently being done in other WGs should be used, if applicable, when it is complete. o It does not rely on non-existing technology and implementations. Again, there is a sense of urgency and the IMP protocol should not require an implementation of server X (which currently does not exist) unless that is absolutely necessary. 4 Conclusion In conclusion, the group of nine have agreed on a common set of components for IM and presence that will allow interworking with delivery of services compliant to rfc 2779. This is accomplished through the definition of an abstract protocol, a common addressing format, a common presence data format, a common content format, a and The Nine [Page 7] Internet Draft IM August 18, 2000 a common end to end security format. We have also outlined the differences between the protocols, focusing on what is fundamentally different and not easily reconcilable. Our hope is that this work will serve as a solid foundation for moving IMPP forward. 5 Author's Addresses David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US Phone: +1 408 246 8253 EMail: DCROCKER@BRANDENBURG.COM URI: HTTP://WWW.BRANDENBURG.COM/ Athanassios Diacakis Network Projects Inc. 4516 Henry Street Suite 113 Pittsburgh, PA 15213 US Phone: +1 412 681 6950 EMail: THANOS@NETWORKPROJECTS.COM Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US EMail: HUITEMA@MICROSOFT.COM Graham Klyne Content Technologies Limited 1220 Parkview Arlington Business Park Theale, Reading RG7 4SA UK The Nine [Page 8] Internet Draft IM August 18, 2000 Phone: +44 118 930 1300 EMail: GK@ACM.ORG Florencio Mazzoldi Network Projects Inc. 4516 Henry Street Suite 113 Pittsburgh, PA 15213 US Phone: +1 412 681 6950 EMail: FLO@NETWORKPROJECTS.COM Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US Phone: +1 707 789 3700 EMail: MROSE@INVISIBLE.NET URI: HTTP://INVISIBLE.NET/ Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Robert Sparks dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: rsparks@dynamicsoft.com Hiroyasu Sugano Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 JP EMail: The Nine [Page 9] Internet Draft IM August 18, 2000 SUGA@FLAB.FUJITSU.CO.JP 6 Bibliography [1] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging / presence protocol requirements," Request for Comments 2779, Internet Engineering Task Force, Feb. 2000. [2] D. Crocker, M. Rose, G. Klyne, J. Rosenberg, R. Sparks, C. Huitema, F. Mazzoldi, H. Sugano, and A. Diacakis, "A common profile for instant messaging," Internet Draft, Internet Engineering Task Force, Aug. 2000. Work in progress. [3] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," Request for Comments 2778, Internet Engineering Task Force, Feb. 2000. [4] M. Elkins, D. D. Torto, R. Levien, and T. Roessler, "MIME security with OpenPGP," Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in progress. [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," Request for Comments 2633, Internet Engineering Task Force, June 1999. The Nine [Page 10]