One document matched: draft-sparks-simple-pdoc-usage-00.txt
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 <closed>
* 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:
+ <available> 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 <activity> 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
* <available> 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:
* <basic> status of open
* <contact> specifying the AOR
* <contact-type> service
* <activity> on-the-phone
* <capabilities, indicating availability of each of the media
supported by the call center (e.g. voice & IM)
* capability indicating both automaton and human (ambiguity about
which will be reached)
* a <note> 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 <note> 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:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:rpid-status"
xmlns:cap="urn:ietf:params:xml:ns:simple-prescaps-ext"
entity="sip:joe@example.com">
Sparks Expires April 16, 2004 [Page 13]
Internet-Draft SIMPLE Presence Document Usage Examples October 2003
<tuple id="sg89ae">
<status>
<basic>close</basic>
<rpid:contactype>service</rpid:contacttype>
</status>
<cap:prescaps>
<cap:feature name="methods">
<cap:value>MESSAGE</cap:value>
<cap:value>OPTIONS</cap:value>
</cap:feature>
</cap:prescaps>
<contact>sip:joe@example.com</contact>
</tuple>
</presence>
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.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:rpid-status"
xmlns:cap="urn:ietf:params:xml:ns:simple-prescaps-ext"
entity="sip:joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
<rpid:contactype>service</rpid:contacttype>
</status>
<cap:prescaps>
<cap:feature name="methods">
<cap:value>MESSAGE</cap:value>
<cap:value>OPTIONS</cap:value>
</cap:feature>
</cap:prescaps>
<contact>sip:joe@example.com</contact>
</tuple>
</presence>
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
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:rpid-status"
xmlns:cap="urn:ietf:params:xml:ns:simple-prescaps-ext"
entity="sip:joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
<rpid:contactype>service</rpid:contacttype>
</status>
<cap:prescaps>
<cap:feature name="methods">
<cap:value>MESSAGE</cap:value>
<cap:value>OPTIONS</cap:value>
</cap:feature>
</cap:prescaps>
<contact>sip:joe@example.com</contact>
<note>Talking with Paul</note>
</tuple>
</presence>
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.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:rpid-status"
xmlns:cap="urn:ietf:params:xml:ns:simple-prescaps-ext"
entity="sip:joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
<rpid:contactype>service</rpid:contacttype>
<rpid:idle>2003-10-9T16:49:29Z</rpid:idle>
</status>
<cap:prescaps>
<cap:feature name="methods">
<cap:value>MESSAGE</cap:value>
<cap:value>OPTIONS</cap:value>
</cap:feature>
</cap:prescaps>
<contact>sip:joe@example.com</contact>
<note>Talking with Paul</note>
</tuple>
Sparks Expires April 16, 2004 [Page 15]
Internet-Draft SIMPLE Presence Document Usage Examples October 2003
</presence>
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.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:rpid-status"
xmlns:cap="urn:ietf:params:xml:ns:simple-prescaps-ext"
entity="sip:joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
<rpid:contactype>service</rpid:contacttype>
<rpid:activity>meeting</rpid:activity>
</status>
<cap:prescaps>
<cap:feature name="methods">
<cap:value>MESSAGE</cap:value>
<cap:value>OPTIONS</cap:value>
</cap:feature>
</cap:prescaps>
<contact>sip:joe@example.com</contact>
<note>In a Meeting</note>
</tuple>
</presence>
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
<contact> 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]
| PAFTECH AB 2003-2026 | 2026-04-23 08:58:24 |