Network Working Group R. Sparks Internet-Draft dynamicsoft Expires: April 16, 2004 October 17, 2003 SIMPLE Presence Document Usage Examples draft-sparks-simple-pdoc-usage-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 April 16, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft details several use-cases of systems using SIMPLE presence documents. It explores the interaction of systems with different requirements and assumptions. Sparks Expires April 16, 2004 [Page 1] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Table of Contents 1. Document Status . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Presence Aware Phone . . . . . . . . . . . . . . . . . . . . 3 4. Multimedia (voice, video, IM) device. . . . . . . . . . . . 6 5. Call Center User View . . . . . . . . . . . . . . . . . . . 7 6. Multimedia Call Center Agent View . . . . . . . . . . . . . 8 7. Using a single tuple for a presentity . . . . . . . . . . . 8 8. Basic IM Service . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Service Definition . . . . . . . . . . . . . . . . . . . . . 12 8.2 PIDF Mapping . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2.1 Generation of PIDF Documents . . . . . . . . . . . . . . . . 12 8.2.2 Interpretation of PIDF Documents . . . . . . . . . . . . . . 16 9. Service Level Views . . . . . . . . . . . . . . . . . . . . 17 9.1 Service Level View Definition . . . . . . . . . . . . . . . 17 9.2 Generation of PIDF Documents . . . . . . . . . . . . . . . . 18 10. A power-user exercising many presence enabled applications . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Composing and Grouping Tuples into Different Views . . . . . 21 11.1 Grouping (or pivoting) . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Sparks Expires April 16, 2004 [Page 2] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 1. Document Status This is a work in the early stages of its progress. The document does not yet achieve its goal, but is being issued at this time to gather feedback on its direction. We have descriptions of several environments in which to construct use cases. We have use cases described for some of these environments. The next step is to specify use cases within each environment and show the presence document exchanges involved. Then, we need to analyze how each environment will react to presence documents sent from the other environments. 2. Overview This draft details use cases in the following environments. The primary contributor to each description is listed in parentheses. o Systems that use a single tuple for a presentity (Brian Rosen) o A presence aware phone (Paul Kyzivat) o A presence aware multimedia device) (Paul Kyzivat) o A call center that uses presence aware voice and IM devices (Paul Kyzivat) o A call center that uses presence aware multimedia devices (Paul Kyzivat) o A basic IM with presence service (Jonathan Rosenberg) o A system supporting SIMPLE IM, MMS, SMS, and circuit voice (Jonathan Rosenberg) o A power-user exercising many presence aware applications (Cullen Jennings) The draft also describes a database manipulation model of device composition providing different views (Henning Schulzrinne). 3. Presence Aware Phone This is a sip voice phone that is presence enabled. It is both a publisher of presence and a consumer of presence. It publishes presence in a way that is consistent with how it consumes presence. The phone user may use the presence features to help its user select when to place a call based on availability of the callee to accept Sparks Expires April 16, 2004 [Page 3] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 the call. o phone has a small display, showing "buddylist" (aka "speed dial list") of frequently called numbers/addresses. o the list displays one line for each buddy (AOR/presentity), showing name or number and an icon indicating availability to take a voice call, or as close an approximation to that as can be inferred from the presence data. o associated with each line on the display is a button that causes a voice call to be placed to the corresponding address. (Or a way to select one line on the display plus a single call button.) The placing of a call is unconditional, regardless of availability, and is addressed to the AOR. (This requires the presentity is identified by a sip url, not a pres: url. Otherwise, if there are multiple tuples the phone will have to do its own call forking.) o the availability is derived by subscribing to presence of the corresponding address and taking the "best" result from all returned tuples. The buddy is marked as available if at least one tuple is available for a voice call. o a tuple is considered to be *un*available for a voice call if: * it has no contact address * the contact address is something other than sip:, sips:, or tel: * it has basic status of * it has capabilities indicating it is a message server (Note we currently have no representation for capabilities) * it has capabilities indicating no audio * it has phone status but no free "lines" (this depends on how work on phone status comes out) o a tuple is considered to be available for voice if it is not considered unavailable. (Note that this will err on the side of showing buddies as available even in cases when they might not be able to take voice calls. For instance, a buddy with only an IM device active might show up as available to take voice calls if the IM device has a SIP url but doesn't indicate precisely which media it can support.) Sparks Expires April 16, 2004 [Page 4] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 o The phone is capable of managing some fixed number (>=1) of concurrent calls on a single "line"/number/address, switching the audio resources between these calls. o If an incoming call arrives when there is no more capacity to receive calls, it returns 486 Busy. Otherwise it alerts when an incoming call arrives. o Presence status is automatically updated based on status of the phone. * When not in any calls, a tuple is published containing: + basic status of open + contact address of the phone (or GRUU), as a sip/sips/tel url + capabilities showing voice media available + capabilities showing IM & video media unavailable * When in a call, but capacity to accept another is present it publishes: + status of on-the-phone + basic status of open + contact address of the phone (or GRUU), as a sip/sips/tel url + capabilities, showing voice media available + capabilities showing IM & video media unavailable * When in a call and no capacity for accepting others is present it publishes: + basic status of closed + contact address of the phone (or GRUU), as a sip/sips/tel url + capabilities, showing voice media *un*available + capabilities showing IM & video media unavailable Sparks Expires April 16, 2004 [Page 5] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 4. Multimedia (voice, video, IM) device. o More capable UI than presence aware phone above - bigger screen, has point/click capability. o The UI includes default settings for the media to be offered by default for incoming and outgoing calls, and a way to manipulate these. (E.g. toggling icons.) o The UI has a display with a line for each active or pending call. Among other things, displays the called party and icons representing supported media and whether each is currently present in the call or not. Individual media icons may be toggled to add or remove them from a call. (Generates reinvites.) o The device has a buddylist display. One or more lines on display for each buddy - one for each tuple that it knows how to communicate with. o Each line in the buddylist display shows an icon indicating general availability plus an icon for plus icons for each media capability it supports that is also supported by the device. o The UI has a way to select one of the lines representing a buddy tuple. Doing so initializes a new active call in pending (undialed) state. This sets a bunch of defaults, including the address to be called and the media to be included in the initial offer. This can be defaulted based on available media from the selected buddy as well as the media defaults for this device. o User can toggle the media icons in the pending call to select (deselect) media to be used in a call, and then may click something to place the call. o Device publishes presence based on default settings. o If there are no calls in progress, presence will be published as: * basic status of open * contact address of the phone (or GRUU), as a sip/sips/tel url . capabilities, representing each of the media, available or not according to the current default settings. o If there are calls in progress, but there is capacity to accept and display the status of another pending call, presence will be same as above, with the addition of: Sparks Expires April 16, 2004 [Page 6] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 * status of on-the-phone o If there are calls in progress, and there is no capacity to accept and display the status of another pending call, presence will be published as: * basic status of closed 5. Call Center User View o Call Center has an AOR corresponding to each queue it has. (E.g. Sales, Customer Support, Vendor Support). In addition to accepting calls at these AORs it also publishes presence for them. o A single tuple is published for each AOR. For an operational call center the presence will typically consist of: * status of open * specifying the AOR * service * on-the-phone * indicating expected wait time for an agent o Note that normal presence indications of availability are not very useful for a call center. When a call center is operating efficiently agents are typically busy almost all the time. So it is generally counterproductive to give callers a way to wait for an agent to be free before calling. o Use of to represent expected wait time is not great, but nothing better is currently available. Perhaps we need something else to explicitly denote this kind of situation. But we need to find a way for this to be rendered reasonably to typical presence clients. o if the call center also supports email requests, another tuple is included with a mailto: contact address. Sparks Expires April 16, 2004 [Page 7] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 6. Multimedia Call Center Agent View Call Center uses agent presence data from call center agents to decide where to route incoming calls. Calls may be voice, IM, or both. Agents may support voice, IM, or both. Agent capability to handle multiple calls varies - generally either one voice call or N IM calls. The actual combination is known to each agent's device. o call center proxy subscribes to presence of agents. Uses results to guide routing of calls to particular agents. o Agent device publishes presence indicating capabilities available for taking a call. Each time the agent receives or completes a call, presence is updated indicating capabilities remaining for taking an additional call. (Typically will only take one voice call at a time, but may be willing/able to handle several IM sessions at once.) The publishing is automated based on policy. o Capabilities are also used to represent language abilities. o "standard" capabilities are used to represent support for media. Some agents may be enables only for voice, others only for IM, some for both. Media are enabled according to agent's availablility to handle. E.g, when doing nothing an agent may be available for Voice & IM. When in a voice call may not be available for anything else. When in an IM call, may be available for another IM call. o "extended" (new, application specific) capabilities indicate subject expertise (e.g. Sales, Customer Support, Vendor Support) o competence and willingness need to be expressed, for subject expertise, language, even media. This might be done using multiple tuples each with the same contact address, and differing priority values to express preference for various combinations of attributes. It might better be done by attaching explicit competence and willingness tags to individual capabilities. 7. Using a single tuple for a presentity Sue is an employee of World Wide Widgets, which recently installed the PresenceMaster 1000 application. Sue is a gadget junkie, travels frequently, and is a junior executive at WWW. Sue has: On her desk A videophone, which she uses for most calls Sparks Expires April 16, 2004 [Page 8] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 A PC In her purse A 3G cellphone with service from Dogleg PCS that also has 802.11 access to the corporate telephony system A wireless PDA with service from PDAlive A Blackberry (the WWW corporate remote email appliance) Her PC runs the following apps: Microsoft Exchange IMable (which is the WWW corporate IM system, and has gateways to AIM and Yahoo IM, which Sue has accounts on) A SIP softphone Sue's business card now looks like: Sue Smart Vice President World Wide Widgets 124 Easy Street Anywhere, MI 22677 mailto:/sip:/im:/pres: sue.smart@worldwidewidgets.com tel:515.555.1212 The PresenceMaster 1000 is integrated with WWW's SipTel telephony system and IMable as well as the Microsoft applications. PresenceMaster, among other things, synchronizes Sue's contact database among the videophone, Exchange, PDA, cellphone and Blackberry as well as IMable. Sue has classified her contacts (family, friends, co-workers, boss, customers, vendors, mother-in-law,...). On her videophone, Sue has selected some of her contacts as speed-dials. The display on the phone shows, by default, presence for each of her speed-dials. Sue has also designated certain of her other contacts as presence subscribed. On the videophone, each contact is represented as a 2.5 x 9mm block containing: Name Sparks Expires April 16, 2004 [Page 9] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Institution A "call" button A "thumbnail" picture of the contact Presence state Presence state has two parts, an icon and a string. The icon attempts to show, graphically, how available the contact is presently. The string shows detail if available, nominally, the "activity" string from RPID. There is a way to get more detailed information on the contact, including more detailed presence information, if available. Sue's presence is available at pres:sue.smart@worldwidewidgets.com A subscriber to Sue's presence nominally must be in her contact database, unless Sue indicates otherwise. For each category in her contact database, Sue has provided a rule set. The rule set has two components: o What level of presence information is revealed o How calls from that watcher are to be handled The former determines how much information will be provided in the presence document. The most restrictive setting is "subscription disallowed", and the next most is "open/closed only", all the way up to all available information. PresenceMaster is pretty smart, and has calendar information, call state, device state from all devices, etc. As a Dogleg PCS user, Sue has paid for the extra cost presence service Dogleg offers. Dogleg has no incentive to allow the phone to supply presence information to any other presence service other than its own, and so it only offers a watcher interface. Similarly, AOL and Yahoo have presence systems where the interface is a watcher. Sue has set the rules for her Dogleg presence system that only allows PresenceMaster as an authorized watcher. PresenceMaster aggregates presence from ALL of Sue's devices, forming a composite view of Sue. The presence information is filtered by PresenceMaster according to Sues rules, by class. A watcher to Sue's presence sees a single tuple, which represents Sue, with a single contact. Anyone who wishes to call Sue, uses the single contact or sip:sue.smart@worldwidewidgets.com Sue's call handling rules define what happens to a call from a class of callers (From:matching in Sparks Expires April 16, 2004 [Page 10] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Sue's contact database). The rules depend not only on caller, but on Sue's presence state. So, for example, Sue's husband can call her even if her presence state is "Do Not Disturb", but her mother-in-law always gets a Busy indication no matter what state Sue is in. In particular, some classes of users will be forwarded to Sue's cellphone in some presence circumstances. No one knows Sue's cell number, they only know her sip URI (or, for more primitive devices, a single E.164). The choice of which device the SipTel proxy will forward a call to depends on: Caller Class Presence State (SipTel is a watcher of Sue's presence) Caller Preferences Media requests in Offer SDP In summary: Sue decides who can see what detail of presence information Sue decides how her calls are handled Sue offers a single aggregate presence source for pres:sue.smart@worldwidewidgets.com Sue offers a single contact point for all calls sip:sue.smart@worldwidewidgets.com Sue is not dependent on a single supplier of presence to obtain these benefits Sue can change devices/preferences/service providers at will, with nothing changing to her callers Sue's callers can see what Sue's state is, not the state of her devices. Sue's callers can reach her from a single point of contact regardless of media choices, time, presence state,... Sue's calls will reach her at the most appropriate device given Sue's state, Sue's preferences and the callers preferences. Where there is a conflict between Sue's preferences and the caller's preferences, Sue's wins. Sparks Expires April 16, 2004 [Page 11] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 8. Basic IM Service In this section, we describe how PIDF is used for a basic IM service. 8.1 Service Definition In this scenario, a provider is offering a service very similar to the instant messaging services offered today by the public providers like AOL, Yahoo, and MSN. In this service, each user has a "screen name" that identifies them in the service. A single client, generally a PC application, connects to the service at a time. When the client connects, this fact is made available to other watchers of that user in the system. The user has the ability to set a textual note that describes what they are doing, and this note is seen by the watchers in the system. The user can set one of several status messages - such as busy, in a meeting, etc., which are pre-defined notes that the system understands. If a user does not type anything on their keyboard for some time, their status changes to idle on the screens of the various watchers of the system. The system also indicates the amount of time that the user has been idle. Whenever a user is connected to the system, they are capable of receiving instant messages. A user can set their status to "invisible", which means that they appear as offline to other users. However, if an IM is sent to them, it will still be delivered. 8.2 PIDF Mapping PIDF documents are generated by the presentity and consumed by the watcher. As such, there are two parts to this use case. The first is how a presentity generates a presence document in this service, and the second is how a watcher interprets a presence document in this service. A watcher associated with this service cannot know that the presence document has been generated according to the conventions described here. Indeed, if a watcher has buddies across systems, those buddies may be generating presence documents in many different ways, and the watcher needs to be prepared for this. 8.2.1 Generation of PIDF Documents The screen name for each user is conveyed in the entity attribute of the presence element. The URI is a SIP address of record, where the user part contains the screen name, and the domain part identifies the provider. The PIDF document distributed to watchers will have a single tuple which indicates availability for the IM service. The contact in this tuple is also the address of record for that user, identical to the Sparks Expires April 16, 2004 [Page 12] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 entity attribute. This is because IM's will need to be sent to the address-of-record for the user in order to be processed by any applications running on behalf of the recipient, such as blocking or forwarding. Furthermore, the presence of firewalls and NATs may preclude the use of direct IM transmission from sender to recipient. To indicate that this tuple represents available for IM, the presentity includes a "contacttype" element from RPID [2], which has a value of "service". It also includes a "prescaps" element [3] that indicates support for the MESSAGE method. It also includes a prescaps element that indicates any special MIME types that can be sent in the IM, typically HTML. The note entered by a user is conveyed in the PIDF "note" element. Any custom notes selected by the user are conveyed in both the "note" element as a text string, along with the RPID "activity" element. Usage of both of these to represent the user status provides broader interoperability. When the presentity is logged in, the "basic" status is set to open, and when the presentity is logged out, it is set to "closed". Invisibility is achieved by setting the status to closed, as if the presentity were not logged in. Once the client application detects that the user has not typed anything for some time, it adds the "idle" element to the PIDF document for that tuple, and sets the time to the current time. Once the client application detects activity once more, the presence document is republished without the "idle" element. 8.2.1.1 Example PIDF Documents This section shows some basic PIDF documents that a presentity would generate for various cases. In all cases, the presentity is a user on the service run by example.com, with a screen name of joe. 8.2.1.1.1 Client Logged Off Before Joe connects to the system, the system generates presence documents for him that indicate he is logged off. This presence document would look like: Sparks Expires April 16, 2004 [Page 13] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 close service MESSAGE OPTIONS sip:joe@example.com 8.2.1.1.2 Client Logs On When Joe's client application connects, the system generates a presence document that now shows his status as open. open service MESSAGE OPTIONS sip:joe@example.com 8.2.1.1.3 Custom Status Next, Joe sets his status to something custom, such as "talking with Paul". This is reflected in the "note" element for the IM service tuple. Sparks Expires April 16, 2004 [Page 14] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 open service MESSAGE OPTIONS sip:joe@example.com Talking with Paul 8.2.1.1.4 Idle Since Joe is talking with Paul, he walks away from his PC, and it goes idle. This results in a new presence document being generated. open service 2003-10-9T16:49:29Z MESSAGE OPTIONS sip:joe@example.com Talking with Paul Sparks Expires April 16, 2004 [Page 15] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 8.2.1.1.5 Preset Status Joe returns to his desk, and now sets his status to "In a Meeting". This results in a new PIDF document being generated with the "idle" element removed, but with a change in the "note" and the addition of the RPID "activity" element. open service meeting MESSAGE OPTIONS sip:joe@example.com In a Meeting 8.2.2 Interpretation of PIDF Documents The recipient of a presence document cannot count on the document being formatted in the way describe above. As such, it needs to be prepared to handle a wide variety of documents, and go through them in order to extract answers to the main question that it needs to ask - is the presentity available for IM. First, the recipient of the document checks the "entity" attribute of the "presence" element. If this attribute contains an IM URI, it implies that the tuples represent connectivity for IM service. The user part of the tuple represents the screen name of the user, and the domain part represents their provider. If any tuples are present with a basic status of "open", it means that the user is available Sparks Expires April 16, 2004 [Page 16] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 for IM, and if all are "closed" it means that they are not available. If there are multiple tupes that contain a note or the RPID "activity" element, the recipient renders the one with the highest priority. If there is no priority, the first tuple is used. If there is a conflict between information in the note and in the rpid "activity" element, the "activity" element is preferred. If the "entity" attribute of the "presence" element is a SIP URI or pres URI, the watcher needs to check the tuples to determine if the presentity is available for IM. If there is any tuple containing the "prescaps" element and a "feature" indicating method support, and the MESSAGE method is listed as supported, then the presentity is capable of IM at that tuple. If there is any tuple containing a contact URI with the IM scheme, the presentity is capable of IM at that tuple. The status shown to the user is online if any tuple indicating IM support is "open". The status shown to the user is "offline" if all tuples indicating IM support are "closed". If there are multiple tupes indicating IM support and "open" status that contain a note or the RPID "activity" element, the recipient renders the one with the highest priority. If there is no priority, the first tuple is used. If there is a conflict between information in the note and in the rpid "activity" element, the "activity" element is preferred. If none of the tuples indicate explicit support for IM (i.e., there is no prescaps element indicating this), and the contact elements are SIP URI, the watcher cannot know, from the presence document, if IM is supported. To make this determination, it sends a SIP OPTIONS request to the contact URI. If the response has an Allow header field with "MESSAGE" listed, the watcher knows that IM is supported. This check is redone if the contact URI changes, or after the status changes from closed to open. 9. Service Level Views In this section, we describe how PIDF is used for representing presence as a sequence of availability for specific services, focusing on mobile services. 9.1 Service Level View Definition In the service level view, each presence tuple represents a particular communications application that a user can be reached on. A communications application represents a particular modality of communications, such that two different communications applications cannot interoperate with each other under normal circumstances. Here, "normal" means that no gateway is in place whose purpose is to explicitly convert from one modality to another. Examples of services are email, instant messaging, voice, video, push-to-talk (PTT), Sparks Expires April 16, 2004 [Page 17] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Multimedia Messaging Service (MMS) and Short Message Service (SMS). A user may be able to communicate with a particular service across one or more devices. For example, a user may be available for voice service and IM service. They can receive voice calls on either their cell phone or landline phone, and can receive IM on either their PC or cell phone. Sometimes, there is a specific URI scheme associated with each service, such that the IM scheme uniquely identifies the service. However, in other cases, a single URI scheme can refer to multiple services. As an example, the mailto [1] URI scheme can be used to communicate with a user through SMS, MMS, or email services. Similarly, a SIP URI can represent communications using voice, video, or PTT. 9.2 Generation of PIDF Documents To generate a PIDF document that describes a service level view, the compositor creates a document where each tuple represents a specific service. The "entity" attribute of the "presence" element conveys a URI, generally a SIP or pres URI, that identifies the user to whom the presence document refers to. Each tuple has a contact that contains a URI appropriate for that specific service type. Generally, this URI will be an address-of-record, since there may be multiple user agents that can process such a service request. Each tuple will contain an RPID "contacttype" element with a value of "service". To indicate what the service is, the tuple needs to contain capabilities or URI schemes that clearly identify the service. The following guidelines seem to make sense: o The URI scheme in the contact is IM, or the "prescaps" element indicates support for the SIP MESSAGE method. This would indicate support for page mode messaging. Session mode messaging would be indicated by support for the "message" media type. o The URI scheme is SIP or tel. In the case of SIP, the "prescaps" element indicates support for the audio media type. In the case of tel, an ENUM dip would indicate an enumservice of voice as being available. [[JDR: yuck.]] o The URI scheme is SIP. The "prescaps" element indicates support for video. o The URI scheme is SIP. The "prescaps" element indicates support for audio. Somewhere there is something that indicates support for floor control, which is the defining feature of PTT. [[JDR: This seems really weak.]] Sparks Expires April 16, 2004 [Page 18] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 o The URI scheme is sms [4], or the URI scheme is mailto, and somehow there is an indication that the mailto URI gateways to SMS. o The URI scheme is mms, or the URI scheme is mailto, and somehow there is an indication that the mailto URI gateways to MMS. o The URI scheme is mailto. Somehow there is an indication that the mailto URI corresponds to email service. There are some fundamental questions here. In cases where, from the senders perspective, the URIs used for the service are identical, and the attributes of the service are identical, are they really different services? For example, MMS and email are very similar. Both can use mailto URI, both can include attachments. Indeed, messages sent to an MMS phone can be forwarded to email. However, from the recipients perspective, there is a difference, and an MMS message and email message will be read by different applications, received in different time frames, and incur differing costs. In that case, what is the appropriate way to differentiate these services from each other? One approach would add additional information like delivery speed and cost as presence attributes. That is, we would continue to define the service by its characteristics, rather than giving it a name. A fundamentally different approach is to create a registry of services, and then have an explicit label for each service. The latter approach would appear to provide much better interoperability at the cost of flexibility, whereas the opposite is true for the former approach. Either way, there is no clear way to represent many services in a PIDF document given the current set of extensions. Another issue is how a compositor determines whether a user is available for a specific service. If the various publishers each indicate availability for specific services (i.e., the publications are for a service view), the process is easy. However, if the publishers present other views, such as a device-centric view, it becomes more complex. For example, lets say a user has a phone that supports voice and SMS, and a PC that supports VoIP and IM. If the phone publishes a device centric view, it might indicate a single tuple containing the tel URI of the phone, and a status of open. How does the compositor know that, if it receives such a document, it means that the user is available for voice and SMS? It would only know this if it had apriori information about the device. 10. A power-user exercising many presence enabled applications Sue, has many devices as described in a previous use case. Sue's cell Sparks Expires April 16, 2004 [Page 19] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 phone is capable of postage stamp size video while her desk video phone does HD quality. Depending on where Sue is, her presence for different types of communications changes. Bob, who wishes to communicate with Sue, can tell is she is available for a given type of communication. Bob can tell is Sue is available for text messaging, voice calls, video call, high quality video calls, or applications sharing session. High quality and low quality video are more or less arbitrarily defined by Sue. What was a high quality video call in the 70's is probably low today. Later when Sue installs a device that can deal with high quality surround sound, stereoscopic images, holograms, or duplicating smell, her presence systems needs to be able to support these devices too. Bob can get notified when Sue is available for work related calls and has access to high quality video so he can show her the latest widget. Sue doesn't go anywhere without her PDA. When Sue's PDA Bluetooth connection finds that it is near her desk phones, it updates her presence to indicate she is available at her desk phone. Similarly, when Sue's cell phones is docked in holder in her car, it switches to a profile where video is disabled and voice goes to a hands free set. If Sue wanted to set things differently should could enable video in her car and have application sharing with her notebook computer projected on the car's heads up display like her friend Rohan does. Sue also has a fax machine at home and a printer at work. Her presence information indicates if she is able to receive documents and Bob can use a fax or imp URL to send a document that will get transcoded to the correct format and sent to the device Sue is at. Negative uses cases: I do not think we should differentiate wideband audio from other. I do not think we should try to specify capabilities to the level of video image resolution, framerate, bitrate, or quality. Sue does not have a speakerphone but when she is in a meeting room at work that has one, her PDA detects this via Bluetooth and updates her presence to make this a way coworkers can reach her. When Sue is at work, her dual mode cell phone tracks which 802.11 access point she is using and provides location information about which building she is in to co-workers. Sue's cell phone provider won't provide geo location information for Sue but her PDA does get information from her car's GPS over Bluetooth then uses Bluetooth to a GPRS interface on her cell to send this information back to here presence system. Sue only makes this information available to her admin from 8 am to 6 pm and her husband. Occasionally she configures the system to lie to her husband and say she is at work when she is not. Sparks Expires April 16, 2004 [Page 20] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Sometimes she temporarily grants limited access to location information to run a specific application where two people get range and bearings or directions to find each other at a location such as a conference. It can also be used to find the nearest Starbucks. Sue can also user her PDA to get direction to the nearest room with video conferencing facilities when she is at work. Sue can indicate the type of topics she is willing to communicate about. She can indicate if she is willing to talk about work related things and can also indicate when is willing to talk about personal things. This has nothing to do with if she is at her office, home, or school. Sue can indicate what time zone she is currently in by updating here cell phone or PDA. She can set her preferences relative to the time zone she is in so that when she is traveling half way around the world she does not receive calls in the middle of the night. Sue can publish a image or video clip to display in her presence information. Negative use cases from vcard. I don't think the categories of telephone numbers included home, work, voice mail or not, preferred or not, cell, video, bbs, modem, car, isdn, voice, pcs, pager are useful. Negative use cases from vcard. I think forcing people to have separate email address to separate personal and work email is lame. The Agent concept from vcard is useful. For certain work replaced things, the availability of Sue's admin may be reflected as Sue's agent. For personal things the agent may be a different person. Perhaps her dog if you really believe in the internet. Other people have access to Sue's work related presence, or personal, or both. They can tell if when is available for IM, voice, video, app sharing, smell sessions and so on. Sue can configure her PDA to let her know when given people are available for a video call and find here a room with video conferencing equipment that is available. 11. Composing and Grouping Tuples into Different Views Presentities may want to expose different levels of detail for themselves, ranging from having one tuple to exporting details for each and every communications device. Sparks Expires April 16, 2004 [Page 21] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 A composing function should be able to systematically and automatically merge multiple tuples in sensible combinations. (Naturally, more complicated combinations may require human intervention or more elaborate rules than the ones presented here.) We start from elementary tuples, i.e., tuples that cannot be further decomposed into multiple SIP or other addresses. (It may still be possible to designate specific capability combinations as a separate SIP URI that maps to the same UA, with the same network address. For example, sip:alice+audio@phone42.example.com may address the audio component of the phone and only enable audio, while sip:alice@phone42.example.com might address all of the device's capabilities. In that case, each of these addresses is represented by an elementary tuple.) Typically, elementary tuples are published by devices themselves. Multiple elementary tuples can be combined into one composed tuple. Composed tuples can be further composed. In this composition model, tuples can be thought of as rows in a relational database. Each row represents an elementary or composed tuple. There are two views of what a column entry represents: (1) It may represent simply the fact that one or more tuples had one of the properties or capabilities. For example, in this model, if we have a column representing the set of media supported, a video-only tuple and an audio-only tuple would merge into an 'audio,video' tuple. This does not indicate that the tuple represents a contact that can support both media. Two contacts that each support both audio and video would yield the same result, even though the capabilities of the contacts are quite different. If one instead defines each column to be binary, e.g., one column describes the boolean 'supports video', another 'supports audio', the composition of the two mono-media tuples would yield 'true,false' for each column. This combination indicates to the watcher that some components of the composed row have the capability, others do not. Clearly, a watcher cannot assume that selecting any random combination of column entries (e.g., via caller preferences) will reach a valid end point. Currently, the RPID and PIDF definitions do not support such sets. Thus, this use case argues for possibly reconsidering this restriction. Sparks Expires April 16, 2004 [Page 22] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 The union model is similar to the centroid model proposed for whois++ (RFC 1835). (2) It represents the property possessed by all tuples that were merged, i.e. the intersection of the values in the rows that contributed to the merged tuple. If there is no common value, the column entry would be empty or undefined. Composition rules can be defined for each presence element. For the element, with an intersection rule, device-specific contacts would be removed, rendering the merged tuple useless. Thus, the merging entity would need to create a dynamic tuple that represents just the merged tuples or, alternatively, each tuple would (also) have to use the presentity's AOR as a Contact. Only tuples with the same AOR could then be merged. This suggests that device-oriented tuples make visible both the AOR that they are reachable under and the device-specific contact (e.g., a GRUU or a network-interface direct contact address.) Here, we define AOR as either being a SIP address-of-record or any URI with another scheme, such as pres:, h323: or im:. (Other URIs do not allow the resolution of an 'umbrella' URI into more specialized URIs.) For example, suppose we have two devices, a PC at alice@pc42.example.com (and maybe as alice-56870@example.com) and a phone, operated by a different company and natively addressed as alice@phone17.example.net (and alice-3456@example.com). These two device elementary tuples can be merged into a single tuple if there is a common AOR, such as alice@example.com. 11.1 Grouping (or pivoting) Grouping is a special kind of compositing, where one parameter is selected as the grouping indicator. Compositors and watchers can perform grouping. Rows are sorted by that parameter values and all rows with an equal parameter value for the grouping column are merged, as above. For example, if we have the rows media mobility placetype privacy activity --------------------------------------------- a,v fixed home private away a mobile NULL public meeting t mobile NULL private meeting Sparks Expires April 16, 2004 [Page 23] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 (Here, a=audio, v=video, t=text) we can group them by media as media mobility placetype privacy activity -------------------------------------------------------- a fix,mob home private away,meeting v fixed home private,public away t mobile NULL private meeting The composition rule 'union' was used for all attributes. Also, all rows were assumed to have the same AOR, as otherwise composition would not be possible. Here, we applied another heuristic, namely to split columns with sets containing more than one element into multiple rows, so that the intermediate step was media mobility placetype privacy activity --------------------------------------------- a fixed home private away v fixed home private away a mobile NULL public meeting t mobile NULL private meeting Grouping also allows the composer or watcher to compress the presence information into the minimal number of rows, by grouping on the AOR, so that each tuple has a unique AOR. 12. Security Considerations This document provides examples of presence document usage. As such, it introduces no new security concerns. As of this version, it does not identify or discuss any security issues with the associated protocols. References [1] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [2] Schulzrinne, H., "RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)", draft-ietf-simple-rpids-01 (work in progress), July 2003. [3] Lonnfors, M. and K. Kiss, "SIMPLE PIDF presence capabilities extension", draft-lonnfors-simple-prescaps-ext-01 (work in progress), June 2003. Sparks Expires April 16, 2004 [Page 24] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 [4] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short Message Service", draft-wilde-sms-uri-04 (work in progress), May 2003. Author's Address Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Expires April 16, 2004 [Page 25] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Sparks Expires April 16, 2004 [Page 26] Internet-Draft SIMPLE Presence Document Usage Examples October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sparks Expires April 16, 2004 [Page 27]