Network Working Group A. B. Roach Internet-Draft dynamicsoft Expires: August 6, 2004 February 6, 2004 Identification of Services in RPID (Rich Presence Information Data) draft-roach-simple-service-features-00 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. This Internet-Draft will expire on August 6, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a system by which one can identify certain classes of service using the capabilities published in presence documents. By identifying the probable presence of such services, the chances of a succesful rendezvous are increased. Roach Expires August 6, 2004 [Page 1] Internet-Draft SIMPLE Service Features February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems with Service Enumeration . . . . . . . . . . . . . 3 3. Benefits of Service Deduction . . . . . . . . . . . . . . . 4 4. Reminder on the Nature of Presence Information . . . . . . . 5 5. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Audio Call . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 Videophone . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3 Whiteboarding . . . . . . . . . . . . . . . . . . . . . . . 6 5.4 Application Sharing . . . . . . . . . . . . . . . . . . . . 7 5.5 Instant Messaging . . . . . . . . . . . . . . . . . . . . . 7 5.5.1 Page Mode Instant Messaging . . . . . . . . . . . . . . . . 7 5.5.2 Session Mode Instant Messaging . . . . . . . . . . . . . . . 8 5.6 Walkie-talkie . . . . . . . . . . . . . . . . . . . . . . . 9 5.7 Video walkie-talkie . . . . . . . . . . . . . . . . . . . . 9 5.8 Voice Instant Messaging . . . . . . . . . . . . . . . . . . 9 5.9 Remote Printer . . . . . . . . . . . . . . . . . . . . . . . 10 5.10 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 10 Non-Normative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 Roach Expires August 6, 2004 [Page 2] Internet-Draft SIMPLE Service Features February 2004 1. Introduction Previous discussions of presence document usage [13] have considered several different views of presence information. In particular, one major open question has been whether to indicate service names explicitly in presence information, or to infer the ability of a user to use a particular service based on the combination of attributes that a presentity publishes in its presence document. The following discussion demonstrates why enumeration of services is undesirable, and proposes that a proper interpretation of capabilities published in presence documents is sufficient for consumers of such documents to deduce the likely presence of particular services. The types of services under consideration in this document are those which require support by both parties for successful rendezvous. Many classes of services do not require such bilateral support to work (e.g. call-waiting). This document does not concern itself with such services. 2. Problems with Service Enumeration The approach of enumerating services falls prey to several problems that make such an approach difficult to adopt. One key problem with enumerating services is that doing so results in a combinatorial explosion over time. Consider a universe in which three services exist: IM, voice, and IM with voice. When a new capability is introduced into this system -- for example, video -- the number of potential services doubles in size: IM, Voice, Video, IM with Video, IM with Voice, IM with Voice and Video, Voice with Video. Each additional capability added to the system has a similar explosive effect, such that the number of services that can be identified becomes unmanagable in size. Such a problem extends beyond the size of the database of service names that must be maintained; any device that supports all three capabilities would want to indicate support for all six services. This explosion of service names has a very real impact on the size of presence documents. A second major issue with such enumeration of services is that it requires either (a) a central repository of standardized service names, or (b) use of a namespacing scheme that allows different organizations to specify their own service names. Of course, a hybrid approach would also be possible, but doing so would merely be the worst of both worlds. Roach Expires August 6, 2004 [Page 3] Internet-Draft SIMPLE Service Features February 2004 Enumeration of standardized service names requires a standardization of services. As the general direction that has been conciously taken by the SIP and related working groups has been selection of generality over efficiency -- defining building blocks that can be combined to create services instead of defining services themselves - - such standardization would be a dramatic change of direction, and would unwind untold years of work on the general toolkit that we have built. Allowing other organizations to specify such services suffers from the same problem, but exhibits at least one additional property: doing so allows parallel development of services that may well be compatible, but known by different names. To give a concrete example, the company "example.com" may define a service that uses half-duplex, floor controlled audio and name it "com.example.walkie- talkie". Separately, an industry consortium may define a functionally identical service, and name it "org.example.wt". Since both are based on standard protocols, they actually interoperate -- however, because of the differing names, the ability to rendezvous with a user based on the presence of such a service would be hindered. 3. Benefits of Service Deduction Many of the benefits of deducing services instead of enumerating them can be derived from the preceding section by simply reversing the negative aspects associated with service enumeration: linear expansion as capabilities are added; no need for standardized services; and enhanced interoperability. The final point, however, is more nuanced than may be immediately obvious. Using our previous example of a half-duplex, floor-controlled audio service, consider a wireless service provider that has deployed such a service, which they market as "depress to pester (tm)". A user of this service is monitoring the presence of several associates. One such associate, although not actually using a "depress to pester (tm)" branded wireless terminal, happens to be running a client on his PC which supports all of the capabilities that were used to implement the "depress to pester (tm)" service. Based on these advertised capabilities, the wireless user is presented with an interface that indicates that such a user is available for a "depress to pester (tm)" session. So, he selects that particular associate, and attempts to begin a session. Because the associate's PC client happens to support all of the protocols necessary for the service, the call completes just fine; both users communicate using the service that the caller expected. Of particular interest is not only the fact that the called Roach Expires August 6, 2004 [Page 4] Internet-Draft SIMPLE Service Features February 2004 associate's client wasn't a "depress to pester (tm)" branded client, but that it may have well participated in a service that its creators hadn't even imagined. Simply because it had the proper capabilites and advertised them appropriately, communication was facilitated. 4. Reminder on the Nature of Presence Information One key aspect inherent in published presence information is the following: Presence information is never a guarantee of reachability. Presence information is always only a hint. Using as an example the type of presence information with which most readers should be familiar: when a users status in your favorite instant messaging application is indicated as "available," is that a guarantee that anything you send will be received by that user? Of course not. The user may be logged in, but away from the keyboard. There may be a communications error that prevents delivery of your message. Someone else may have powered up that users' computer. There are myriad reasons that reachability may not be accurately reflected by presence information. The value in presence information is increasing the probabilty of success in contacting a user via a particular mechanism, not guaranteeing that a particular mechanism will be successful. This fundamental property of presence information is key in understanding why deduction of the presence of services is acceptable: even in the corner cases that such deductions are not completely accurate, they cause no more harm to the ability to communicate than other situations in which presence information fails to guarantee an outcome. 5. Services The discussions about presence documents have identified a reasonably small set of bilateral services that are of interest. To demonstrate the points made in the preceding text, the following sections provide examples of how service capabilities can be used to deduce support for these services. A brief description of each service is provided, along with capabilities that consumers of presence information can use to deduce probable support for the service. The examples that follow are not meant to be normative. Developers of applications that consume presence information are free to choose to look for whatever set of capabilities they wish before deciding that a given presentity supports a paritcular service. Publishers of presence information, however, would be well advised to include at Roach Expires August 6, 2004 [Page 5] Internet-Draft SIMPLE Service Features February 2004 least the minimal set of capabilites described below for each of the services they beleive they have implemented. The capabilites used below are taken from the document "User agent capability presence status extension" [1] Many of the services described below can be detected using multiple mechanisms. Most such cases arise when the service can be provided by a contact using a service-specific URI scheme (e.g. tel: [2][3] ) and also using a multi-service URI scheme (e.g. sip: [4]) along with appropriate capabilities. In such cases, both mechanisms for identification of the service are described. 5.1 Audio Call This service provides the equivalent of a traditional voice phone call. Participants can speak to and hear the other party simultaneously. Support for the Audio Call service can be deduced by observing either of the following: o The presence of a contact URI with a scheme of "tel:" o The presence of a contact URI with a scheme of "sip:", associated with the following minimal set of capabilities: