idnits 2.17.1 draft-roach-simple-service-features-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 6, 2004) is 7384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2806 (ref. '2') (Obsoleted by RFC 3966) == Outdated reference: A later version (-09) exists of draft-ietf-iptel-rfc2806bis-02 == Outdated reference: A later version (-20) exists of draft-wilde-sms-uri-03 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-03 ** Obsolete normative reference: RFC 2368 (ref. '12') (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '14') (Obsoleted by RFC 4566) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-10 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft dynamicsoft 4 Expires: August 6, 2004 February 6, 2004 6 Identification of Services in RPID (Rich Presence Information Data) 7 draft-roach-simple-service-features-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes a system by which one can identify certain 39 classes of service using the capabilities published in presence 40 documents. By identifying the probable presence of such services, 41 the chances of a succesful rendezvous are increased. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Problems with Service Enumeration . . . . . . . . . . . . . 3 47 3. Benefits of Service Deduction . . . . . . . . . . . . . . . 4 48 4. Reminder on the Nature of Presence Information . . . . . . . 5 49 5. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 5.1 Audio Call . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 5.2 Videophone . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5.3 Whiteboarding . . . . . . . . . . . . . . . . . . . . . . . 6 53 5.4 Application Sharing . . . . . . . . . . . . . . . . . . . . 7 54 5.5 Instant Messaging . . . . . . . . . . . . . . . . . . . . . 7 55 5.5.1 Page Mode Instant Messaging . . . . . . . . . . . . . . . . 7 56 5.5.2 Session Mode Instant Messaging . . . . . . . . . . . . . . . 8 57 5.6 Walkie-talkie . . . . . . . . . . . . . . . . . . . . . . . 9 58 5.7 Video walkie-talkie . . . . . . . . . . . . . . . . . . . . 9 59 5.8 Voice Instant Messaging . . . . . . . . . . . . . . . . . . 9 60 5.9 Remote Printer . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.10 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Normative References . . . . . . . . . . . . . . . . . . . . 10 64 Non-Normative References . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 66 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 Previous discussions of presence document usage [13] have considered 72 several different views of presence information. In particular, one 73 major open question has been whether to indicate service names 74 explicitly in presence information, or to infer the ability of a user 75 to use a particular service based on the combination of attributes 76 that a presentity publishes in its presence document. 78 The following discussion demonstrates why enumeration of services is 79 undesirable, and proposes that a proper interpretation of 80 capabilities published in presence documents is sufficient for 81 consumers of such documents to deduce the likely presence of 82 particular services. 84 The types of services under consideration in this document are those 85 which require support by both parties for successful rendezvous. 86 Many classes of services do not require such bilateral support to 87 work (e.g. call-waiting). This document does not concern itself 88 with such services. 90 2. Problems with Service Enumeration 92 The approach of enumerating services falls prey to several problems 93 that make such an approach difficult to adopt. 95 One key problem with enumerating services is that doing so results in 96 a combinatorial explosion over time. Consider a universe in which 97 three services exist: IM, voice, and IM with voice. When a new 98 capability is introduced into this system -- for example, video -- 99 the number of potential services doubles in size: IM, Voice, Video, 100 IM with Video, IM with Voice, IM with Voice and Video, Voice with 101 Video. Each additional capability added to the system has a similar 102 explosive effect, such that the number of services that can be 103 identified becomes unmanagable in size. Such a problem extends 104 beyond the size of the database of service names that must be 105 maintained; any device that supports all three capabilities would 106 want to indicate support for all six services. This explosion of 107 service names has a very real impact on the size of presence 108 documents. 110 A second major issue with such enumeration of services is that it 111 requires either (a) a central repository of standardized service 112 names, or (b) use of a namespacing scheme that allows different 113 organizations to specify their own service names. Of course, a 114 hybrid approach would also be possible, but doing so would merely be 115 the worst of both worlds. 117 Enumeration of standardized service names requires a standardization 118 of services. As the general direction that has been conciously taken 119 by the SIP and related working groups has been selection of 120 generality over efficiency -- defining building blocks that can be 121 combined to create services instead of defining services themselves - 122 - such standardization would be a dramatic change of direction, and 123 would unwind untold years of work on the general toolkit that we have 124 built. 126 Allowing other organizations to specify such services suffers from 127 the same problem, but exhibits at least one additional property: 128 doing so allows parallel development of services that may well be 129 compatible, but known by different names. To give a concrete 130 example, the company "example.com" may define a service that uses 131 half-duplex, floor controlled audio and name it "com.example.walkie- 132 talkie". Separately, an industry consortium may define a 133 functionally identical service, and name it "org.example.wt". Since 134 both are based on standard protocols, they actually interoperate -- 135 however, because of the differing names, the ability to rendezvous 136 with a user based on the presence of such a service would be 137 hindered. 139 3. Benefits of Service Deduction 141 Many of the benefits of deducing services instead of enumerating them 142 can be derived from the preceding section by simply reversing the 143 negative aspects associated with service enumeration: linear 144 expansion as capabilities are added; no need for standardized 145 services; and enhanced interoperability. The final point, however, 146 is more nuanced than may be immediately obvious. 148 Using our previous example of a half-duplex, floor-controlled audio 149 service, consider a wireless service provider that has deployed such 150 a service, which they market as "depress to pester (tm)". A user of 151 this service is monitoring the presence of several associates. One 152 such associate, although not actually using a "depress to pester 153 (tm)" branded wireless terminal, happens to be running a client on 154 his PC which supports all of the capabilities that were used to 155 implement the "depress to pester (tm)" service. Based on these 156 advertised capabilities, the wireless user is presented with an 157 interface that indicates that such a user is available for a "depress 158 to pester (tm)" session. So, he selects that particular associate, 159 and attempts to begin a session. Because the associate's PC client 160 happens to support all of the protocols necessary for the service, 161 the call completes just fine; both users communicate using the 162 service that the caller expected. 164 Of particular interest is not only the fact that the called 165 associate's client wasn't a "depress to pester (tm)" branded client, 166 but that it may have well participated in a service that its creators 167 hadn't even imagined. Simply because it had the proper capabilites 168 and advertised them appropriately, communication was facilitated. 170 4. Reminder on the Nature of Presence Information 172 One key aspect inherent in published presence information is the 173 following: 175 Presence information is never a guarantee of reachability. 176 Presence information is always only a hint. 178 Using as an example the type of presence information with which most 179 readers should be familiar: when a users status in your favorite 180 instant messaging application is indicated as "available," is that a 181 guarantee that anything you send will be received by that user? Of 182 course not. The user may be logged in, but away from the keyboard. 183 There may be a communications error that prevents delivery of your 184 message. Someone else may have powered up that users' computer. 185 There are myriad reasons that reachability may not be accurately 186 reflected by presence information. 188 The value in presence information is increasing the probabilty of 189 success in contacting a user via a particular mechanism, not 190 guaranteeing that a particular mechanism will be successful. This 191 fundamental property of presence information is key in understanding 192 why deduction of the presence of services is acceptable: even in the 193 corner cases that such deductions are not completely accurate, they 194 cause no more harm to the ability to communicate than other 195 situations in which presence information fails to guarantee an 196 outcome. 198 5. Services 200 The discussions about presence documents have identified a reasonably 201 small set of bilateral services that are of interest. To demonstrate 202 the points made in the preceding text, the following sections provide 203 examples of how service capabilities can be used to deduce support 204 for these services. A brief description of each service is provided, 205 along with capabilities that consumers of presence information can 206 use to deduce probable support for the service. 208 The examples that follow are not meant to be normative. Developers 209 of applications that consume presence information are free to choose 210 to look for whatever set of capabilities they wish before deciding 211 that a given presentity supports a paritcular service. Publishers of 212 presence information, however, would be well advised to include at 213 least the minimal set of capabilites described below for each of the 214 services they beleive they have implemented. 216 The capabilites used below are taken from the document "User agent 217 capability presence status extension" [1] 219 Many of the services described below can be detected using multiple 220 mechanisms. Most such cases arise when the service can be provided 221 by a contact using a service-specific URI scheme (e.g. tel: [2][3] ) 222 and also using a multi-service URI scheme (e.g. sip: [4]) along with 223 appropriate capabilities. In such cases, both mechanisms for 224 identification of the service are described. 226 5.1 Audio Call 228 This service provides the equivalent of a traditional voice phone 229 call. Participants can speak to and hear the other party 230 simultaneously. 232 Support for the Audio Call service can be deduced by observing either 233 of the following: 235 o The presence of a contact URI with a scheme of "tel:" 237 o The presence of a contact URI with a scheme of "sip:", associated 238 with the following minimal set of capabilities: