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]