< draft-rosenberg-simple-presence-processing-model-01.txt   draft-rosenberg-simple-presence-processing-model-02.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: January 18, 2006 July 17, 2005 Expires: December 28, 2006 June 26, 2006
A Processing Model for Presence A Processing Model for Presence
draft-rosenberg-simple-presence-processing-model-01 draft-rosenberg-simple-presence-processing-model-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 18, 2006. This Internet-Draft will expire on December 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the underlying data processing operations used This document defines the underlying data processing operations used
by Session Initiation Protocol (SIP) for Instant Messaging Leveraging by Session Initiation Protocol (SIP) for Instant Messaging Leveraging
Presence Extensions (SIMPLE) presence agents and presence user Presence Extensions (SIMPLE) presence agents and presence user
agents. The data processing operations described here include agents. The data processing operations described here include
composition, privacy filtering, and watcher filtering. composition, privacy filtering, and watcher filtering.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Reporting . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Overriding . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Overriding . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Presence Server Processing . . . . . . . . . . . . . . . . . . 7 4. Presence Server Processing . . . . . . . . . . . . . . . . . . 7
4.1 SIP Subscription Processing . . . . . . . . . . . . . . . 7 4.1. SIP Subscription Processing . . . . . . . . . . . . . . . 7
4.2 Presence Document Processing . . . . . . . . . . . . . . . 7 4.2. Presence Document Processing . . . . . . . . . . . . . . . 7
4.2.1 Collection . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Collection . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Composition . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Composition . . . . . . . . . . . . . . . . . . . . . 11
4.2.3 Privacy Filtering . . . . . . . . . . . . . . . . . . 17 4.2.3. Privacy Filtering . . . . . . . . . . . . . . . . . . 17
4.2.4 Watcher Filtering . . . . . . . . . . . . . . . . . . 17 4.2.4. Watcher Filtering . . . . . . . . . . . . . . . . . . 17
4.2.5 Post-Processing Composition . . . . . . . . . . . . . 18 4.2.5. Post-Processing Composition . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . . 18 7. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Presence conveys the ability and willingness of a user to communicate Presence conveys the ability and willingness of a user to communicate
across a set of devices. RFC 2778 [1] defines a model and across a set of devices. RFC 2778 [1] defines a model and
terminology for describing systems that provide presence information. terminology for describing systems that provide presence information.
RFC 3863 [3] defines an XML document format for representing presence RFC 3863 [3] defines an XML document format for representing presence
information. [8] defines a data model for modeling communications information. [6] defines a data model for modeling communications
systems using that document format. systems using that document format.
This specification is a companion to the data modeling specifications This specification is a companion to the data modeling specifications
described above. Rather than describing the meaning of the described above. Rather than describing the meaning of the
underlying presence data, it describes the processing operations used underlying presence data, it describes the processing operations used
by presence agents in processing that data. Other specifications, by presence agents in processing that data. Other specifications,
such as the presence event package [5] and the PUBLISH method [14] such as the presence event package [4] and the PUBLISH method [8]
document the protocol interfaces for moving presence documents document the protocol interfaces for moving presence documents
between these entities. However, none of these specifications define between these entities. However, none of these specifications define
the behaviors these elements can exhibit in terms of processing those the behaviors these elements can exhibit in terms of processing those
documents. This specification defines those procedures, including documents. This specification defines those procedures, including
composition, privacy filtering, and watcher filtering, in more composition, privacy filtering, and watcher filtering, in more
detail. By providing a model for those operations, consistent detail. By providing a model for those operations, consistent
interpretation of authorization policies and composition policies interpretation of authorization policies and composition policies
across implementations can be achieved. This allows for consistent across implementations can be achieved. This allows for consistent
user experiences. user experiences.
skipping to change at page 4, line 41 skipping to change at page 4, line 44
itself, it is called reporting. Reporting is in contrast to itself, it is called reporting. Reporting is in contrast to
overriding, where a software agent publishes about a different overriding, where a software agent publishes about a different
service or device. service or device.
Overriding: When a service or device publishes presence information Overriding: When a service or device publishes presence information
about a different service or device, in an attempt to correct or about a different service or device, in an attempt to correct or
modify that data. modify that data.
3. Publication 3. Publication
Publication is defined as the process by which an event publication Publication is defined as the process by which an event publication
agent (EPA) pushes event state into the network [14]. In this agent (EPA) pushes event state into the network [8]. In this
section, we consider how an EPA for the presence event package would section, we consider how an EPA for the presence event package would
generate the presence document it will publish. generate the presence document it will publish.
3.1 Reporting 3.1. Reporting
Reporting is the process whereby a service publishes about itself, an Reporting is the process whereby a service publishes about itself, an
agent on a device publishes about the device, or an agent agent on a device publishes about the device, or an agent
representing the human user publishes person information elements. representing the human user publishes person information elements.
Reporting is in contrast to overriding, where a software agent Reporting is in contrast to overriding, where a software agent
attempts to publish information about a different service or device. attempts to publish information about a different service or device.
An EPA for presence (also known as a Presence User Agent (PUA)) An EPA for presence (also known as a Presence User Agent (PUA))
computes the presence document as if it had full knowledge of the computes the presence document as if it had full knowledge of the
state of the presentity. That is, it represents the complete view of state of the presentity. That is, it represents the complete view of
skipping to change at page 5, line 24 skipping to change at page 5, line 27
devices can themselves publish information about a presentity, and devices can themselves publish information about a presentity, and
that software agents representing the person, and not their services, that software agents representing the person, and not their services,
can also publish presence documents. For the remainder of this can also publish presence documents. For the remainder of this
discussion, we assume that the entity doing the publishing is a discussion, we assume that the entity doing the publishing is a
service. service.
When a document is created by such a PUA, the presentity URI (encoded When a document is created by such a PUA, the presentity URI (encoded
in the "entity" attribute) will typically be a SIP URI, and equal to in the "entity" attribute) will typically be a SIP URI, and equal to
the AOR of the presentity. This will also usually be the same as the the AOR of the presentity. This will also usually be the same as the
request URI in the PUBLISH request itself, but it need not be so. request URI in the PUBLISH request itself, but it need not be so.
The URI serve different purposes. As described in [14], the request The URI serve different purposes. As described in [8], the request
URI serves as a means to route the request to the appropriate event URI serves as a means to route the request to the appropriate event
state compositor, and identity the target of the publication. As state compositor, and identity the target of the publication. As
such, it is primary a means for targeting the document. The entity such, it is primary a means for targeting the document. The entity
about whom presence is reported is always taken from the "entity" of about whom presence is reported is always taken from the "entity" of
the presence document. the presence document.
A PUA will also publish the services it knows about, and the device A PUA will also publish the services it knows about, and the device
it's associated with. The service URI needs to be a unique it's associated with. The service URI needs to be a unique
identifier that defines the service as far as the PUA is concerned. identifier that defines the service as far as the PUA is concerned.
That URI should be a GRUU, as discussed above. The device ID for the That URI should be a GRUU, as discussed above. The device ID for the
device is obtained from the local operating system. device is obtained from the local operating system.
3.2 Overriding 3.2. Overriding
Overriding is the process whereby a PUA attempts to publish Overriding is the process whereby a PUA attempts to publish
information in an explicit attempt to have that information take the information in an explicit attempt to have that information take the
place of information published by a different PUA for the same place of information published by a different PUA for the same
presentity. presentity.
The motivating use case for this feature is as follows. A user has The motivating use case for this feature is as follows. A user has
an office PC and a home PC, both of which run an Instant Messaging an office PC and a home PC, both of which run an Instant Messaging
(IM) application. While at work, they set the status of their IM (IM) application. While at work, they set the status of their IM
application to "in a meeting". This information is reported in application to "in a meeting". This information is reported in
skipping to change at page 7, line 21 skipping to change at page 7, line 25
to perform an override. At the time of writing, it was anticipated to perform an override. At the time of writing, it was anticipated
that new event packages could be defined to facilitate this that new event packages could be defined to facilitate this
discovery, should the need really arise in practice. discovery, should the need really arise in practice.
4. Presence Server Processing 4. Presence Server Processing
In this section, we outline the processing done by a presence server. In this section, we outline the processing done by a presence server.
This processing is broken into two components - the SIP subscription This processing is broken into two components - the SIP subscription
processing and the presence document processing. processing and the presence document processing.
4.1 SIP Subscription Processing 4.1. SIP Subscription Processing
For the most part, processing of SIP subscriptions is described in For the most part, processing of SIP subscriptions is described in
RFC 3856 [5]. That specification does leave some hooks for policy- RFC 3856 [4]. That specification does leave some hooks for policy-
based decisions in subscription handling, as discussed in Section based decisions in subscription handling, as discussed in Section
6.6.2 of RFC 3856. In particular, when the presence server receives 6.6.2 of RFC 3856. In particular, when the presence server receives
a SUBSCRIBE request, it needs to make an immediate decision to put a SUBSCRIBE request, it needs to make an immediate decision to put
that subscription into one of three states - rejected, successful, that subscription into one of three states - rejected, successful,
and pending. That decision, called the subscription authorization and pending. That decision, called the subscription authorization
decision, is governed by a Presence Authorization document. This decision, is governed by a Presence Authorization document. This
document, discussed below in more detail, also contains information document, discussed below in more detail, also contains information
that guides privacy filtering when the subscription is accepted. that guides privacy filtering when the subscription is accepted.
Users can change their presence authorization documents at any time. Users can change their presence authorization documents at any time.
As a result, a user could change those policies to alter the state of As a result, a user could change those policies to alter the state of
the subscription. Changes in the document need to take effect the subscription. Changes in the document need to take effect
immediately. immediately.
4.2 Presence Document Processing 4.2. Presence Document Processing
Once a subscription has been accepted, presence documents are Once a subscription has been accepted, presence documents are
delivered to the watcher through notifications. This requires the delivered to the watcher through notifications. This requires the
presence server to generate a presence document for the watcher. The presence server to generate a presence document for the watcher. The
process for doing that is called the presence document generation process for doing that is called the presence document generation
process. This process is invoked by the presence server under process. This process is invoked by the presence server under
several conditions: several conditions:
Subscription Transition to Accepted: When the subscription itself Subscription Transition to Accepted: When the subscription itself
transitions to the accepted state, the presence server needs to transitions to the accepted state, the presence server needs to
generate the current state of the presentity and place this in a generate the current state of the presentity and place this in a
NOTIFY to the watcher. To do this, the presence document NOTIFY to the watcher. To do this, the presence document
generation process is invoked. generation process is invoked.
SUBSCRIBE refreshes: Once in the accepted state, SUBSCRIBE refreshes SUBSCRIBE refreshes: Once in the accepted state, SUBSCRIBE refreshes
on the SIP dialog request that the server generate a notification on the SIP dialog request that the server generate a notification
containing the current state of the presentity. To do this, the containing the current state of the presentity. To do this, the
presence document generation process is invoked. presence document generation process is invoked.
Source changes: When one of the sources of presence information for a Source changes: When one of the sources of presence information for a
user changes, the result may change the state of the presentity. user changes, the result may change the state of the presentity.
To determine the new state, the server invokes the presence To determine the new state, the server invokes the presence
document generation process. document generation process.
Policy changes: When one of the policy documents governing the Policy changes: When one of the policy documents governing the
presence document generation process changes, the result may presence document generation process changes, the result may
skipping to change at page 9, line 49 skipping to change at page 9, line 49
+-----------+ +-----------+
| | | |
| Final | | Final |
| Presence | | Presence |
| Document | | Document |
| | | |
| | | |
+-----------+ +-----------+
Figure 1 Figure 1
4.2.1 Collection 4.2.1. Collection
The first step is the process of collection. Collection is defined The first step is the process of collection. Collection is defined
as the process of obtaining the set of event state that is necessary as the process of obtaining the set of event state that is necessary
for performing the composition operation that creates the initial for performing the composition operation that creates the initial
view. A view is defined as the particular stream of presence view. A view is defined as the particular stream of presence
documents seen by a watcher after the application of policy. In this documents seen by a watcher after the application of policy. In this
case, the initial view is the view of the presentity before the case, the initial view is the view of the presentity before the
application of privacy and watcher filtering. application of privacy and watcher filtering.
The event state that is collected includes all of the presence The event state that is collected includes all of the presence
skipping to change at page 10, line 27 skipping to change at page 10, line 27
definition, is the set of documents whose "entity" attribute in the definition, is the set of documents whose "entity" attribute in the
<presence> element in the presence document is the same as that of <presence> element in the presence document is the same as that of
the presentity. However, it may also include other presence the presentity. However, it may also include other presence
documents for other presentities, in cases where the presence server documents for other presentities, in cases where the presence server
knows that the state of one presentity is a function of the state of knows that the state of one presentity is a function of the state of
another. An example is the helpdesk presentity, whose state is a another. An example is the helpdesk presentity, whose state is a
function of the state of the users in the help desk. function of the state of the users in the help desk.
In addition to presence events, other event state can be used as In addition to presence events, other event state can be used as
well. As an example, registration state [2] has a bearing on well. As an example, registration state [2] has a bearing on
presence, as does dialog state [23], and the state of non-SIP presence, as does dialog state [12], and the state of non-SIP
systems, such as traditional telephony equipment, layer 2 devices, systems, such as traditional telephony equipment, layer 2 devices,
and so on. This state can be obtained by a presence server in and so on. This state can be obtained by a presence server in
several ways. Firstly, publishers for that state can send PUBLISH several ways. Firstly, publishers for that state can send PUBLISH
requests for it to the presence server. In another approach, the requests for it to the presence server. In another approach, the
presence server acts as a watcher, and subscribes to the event state presence server acts as a watcher, and subscribes to the event state
for the resources it needs. This is referred to as a back-end for the resources it needs. This is referred to as a back-end
subscription. subscription.
Each of these non-presence events can then be converted into a piece Each of these non-presence events can then be converted into a piece
of presence state (presentity, device or service information) based of presence state (presentity, device or service information) based
skipping to change at page 10, line 52 skipping to change at page 10, line 52
services on the device. services on the device.
Registration state is of particular importance. It can be obtained Registration state is of particular importance. It can be obtained
by a presence server by having the presence server co-located with by a presence server by having the presence server co-located with
the registrar, or by having the presence server subscribe to the the registrar, or by having the presence server subscribe to the
registration event package for the user [2]. Each registered contact registration event package for the user [2]. Each registered contact
is considered a service. The service URI (expressed in the <contact> is considered a service. The service URI (expressed in the <contact>
element in each tuple of the presence document) is obtained from the element in each tuple of the presence document) is obtained from the
GRUU for each contact, if it exists, else it is set to the Contact GRUU for each contact, if it exists, else it is set to the Contact
URI from the registration. Service parameters can be extracted from URI from the registration. Service parameters can be extracted from
any callee capabilities provided in the registration [15]. The any callee capabilities provided in the registration [9]. The
presentity URI is set to the address-of-record. This mapping has the presentity URI is set to the address-of-record. This mapping has the
advantage that it is readily correlated to any service information advantage that it is readily correlated to any service information
that might also be PUBLISHed explicitly by that UA. As such, a UA that might also be PUBLISHed explicitly by that UA. As such, a UA
that registers should also PUBLISH its state, in the event the that registers should also PUBLISH its state, in the event the
presence server cannot access registration information. presence server cannot access registration information.
Once the non-presence event state is converted into pieces of Once the non-presence event state is converted into pieces of
presence state, the compositor will have, at its disposal, a set of presence state, the compositor will have, at its disposal, a set of
presence data, each of which is for the same presentity. presence data, each of which is for the same presentity.
4.2.2 Composition 4.2.2. Composition
The next step in the process is the composition operation, which The next step in the process is the composition operation, which
produces the raw presence document, also known as the initial view, produces the raw presence document, also known as the initial view,
from the document sources. This document is "raw" because it from the document sources. This document is "raw" because it
contains more information than any watcher might actually see. contains more information than any watcher might actually see.
Privacy and watcher filtering may eliminate some of the data from the Privacy and watcher filtering may eliminate some of the data from the
document. document.
Composition is governed by the rules defined in the composition Composition is governed by the rules defined in the composition
policy. The composition policy is a document selected by the policy. The composition policy is a document selected by the
presence authorization document. Since different composition presence authorization document. Since different composition
policies may have differing implications on privacy, the policies may have differing implications on privacy, the
authorization rules themselves need to select the composition policy. authorization rules themselves need to select the composition policy.
As an example, "polite blocking", defined in RFC 2779 [6], is As an example, "polite blocking", defined in RFC 2779 [5], is
actually the selection of a specific composition policy - one which actually the selection of a specific composition policy - one which
generates a view that falsely represents the watcher as unavailable. generates a view that falsely represents the watcher as unavailable.
The decision as to whether to invoke this composition policy or not The decision as to whether to invoke this composition policy or not
is dictated by the authorization document. is dictated by the authorization document.
The authorization rules applicable to the presence document The authorization rules applicable to the presence document
generation process can themselves depend on the current state of the generation process can themselves depend on the current state of the
presentity, which is derived from the initial view in the raw presentity, which is derived from the initial view in the raw
presence document. This results in a seemingly circular decision - presence document. This results in a seemingly circular decision -
the composition policy to generate the raw presence document is based the composition policy to generate the raw presence document is based
skipping to change at page 12, line 5 skipping to change at page 12, line 5
presence document. However, as discussed below, this problem is presence document. However, as discussed below, this problem is
avoided by using a specific composition policy (the default policy) avoided by using a specific composition policy (the default policy)
to compute the view used to assist in the selection of the to compute the view used to assist in the selection of the
authorization policy. That authorization policy can select a authorization policy. That authorization policy can select a
different composition policy to generate the document actually sent different composition policy to generate the document actually sent
to a watcher. to a watcher.
Composition policies can be complex and rich. However, there are Composition policies can be complex and rich. However, there are
some general tools and techniques that merit discussion. some general tools and techniques that merit discussion.
4.2.2.1 Correlation 4.2.2.1. Correlation
A key part of composition is using information in one presence A key part of composition is using information in one presence
document, describing a person, service or device, to affect document, describing a person, service or device, to affect
information in another. As an example, if the presence server has a information in another. As an example, if the presence server has a
document indicating that the user has a telephony service that is document indicating that the user has a telephony service that is
busy, the server can use this to extract information about the person busy, the server can use this to extract information about the person
- that they are on the phone. Similarly, if one document indicates - that they are on the phone. Similarly, if one document indicates
that a device with ID 1 is off, and another document that indicates a that a device with ID 1 is off, and another document that indicates a
telephony service is running on the device with ID 1, the server can telephony service is running on the device with ID 1, the server can
determine that the telephony service is closed. determine that the telephony service is closed.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
identifiers have uniqueness and temporal persistence properties that identifiers have uniqueness and temporal persistence properties that
make them useful for purposes of correlation. Indeed, its not just make them useful for purposes of correlation. Indeed, its not just
that the identifiers have temporal persistence; its that they have a that the identifiers have temporal persistence; its that they have a
common value that is used persistently across different sources. In common value that is used persistently across different sources. In
the example above, the device ID of 1 is useful for correlating the the example above, the device ID of 1 is useful for correlating the
device state to the service state, if, and only if, the source device state to the service state, if, and only if, the source
indicating the device state uses the same device ID as the source indicating the device state uses the same device ID as the source
indicating the service state. This makes selection of the device ID indicating the service state. This makes selection of the device ID
a critically important operation. a critically important operation.
4.2.2.2 Conflict Resolution 4.2.2.2. Conflict Resolution
In some cases, there may be multiple sources that provide conflicting In some cases, there may be multiple sources that provide conflicting
information about a service, person, or device. In this case, information about a service, person, or device. In this case,
"conflicting" means that there are multiple person data elements that "conflicting" means that there are multiple person data elements that
say different things, multiple service data elements for the same say different things, multiple service data elements for the same
service (where the same service is defined as two services with the service (where the same service is defined as two services with the
same service URI), or multiple device data elements with the same same service URI), or multiple device data elements with the same
device ID. device ID.
Conflicting person information is very likely. The typical situation Conflicting person information is very likely. The typical situation
skipping to change at page 14, line 6 skipping to change at page 14, line 6
not change the value. not change the value.
Conflicts of services or devices are less likely to occur in the Conflicts of services or devices are less likely to occur in the
model presented here, due to the unique nature of the service URI and model presented here, due to the unique nature of the service URI and
device ID. However, it is possible. Indeed, a client might device ID. However, it is possible. Indeed, a client might
explicitly choose to publish with the same service URI as another explicitly choose to publish with the same service URI as another
client, if its goal is to explicitly override the service of the client, if its goal is to explicitly override the service of the
other. Using the same service ID is the "hint" to the presence other. Using the same service ID is the "hint" to the presence
server that conflicting data exists, and one needs to be chosen. server that conflicting data exists, and one needs to be chosen.
4.2.2.3 Merging 4.2.2.3. Merging
Merging is an operation that allows a presence server to combine Merging is an operation that allows a presence server to combine
together a set of different services or devices into a single together a set of different services or devices into a single
composite service or device. Two services are different if they have composite service or device. Two services are different if they have
different service URIs, and two devices are different if they have different service URIs, and two devices are different if they have
different device IDs. This operation is a common one in composition different device IDs. This operation is a common one in composition
operations. operations.
The merging process involves three steps. The first is to select the The merging process involves three steps. The first is to select the
set of services or devices to merge. The second is to combine the set of services or devices to merge. The second is to combine the
skipping to change at page 14, line 30 skipping to change at page 14, line 30
One way to identify the set of services that will be combined is by One way to identify the set of services that will be combined is by
defining a "pivot". A pivot is a particular attribute (either defining a "pivot". A pivot is a particular attribute (either
characteristic or status) of a service that is used as the selector. characteristic or status) of a service that is used as the selector.
All of the services in the raw presence document for whom the pivot All of the services in the raw presence document for whom the pivot
attribute has the same value, are all combined together, and the attribute has the same value, are all combined together, and the
resulting service will clearly have that value for that particular resulting service will clearly have that value for that particular
pivot attribute. If the raw presence document has three distinct pivot attribute. If the raw presence document has three distinct
values for the pivot attribute, the presence document, after values for the pivot attribute, the presence document, after
combination, will have three services. combination, will have three services.
For example, if the video prescaps [17] attribute is used as the For example, if the video prescaps [10] attribute is used as the
pivot, then all services that support video will be combined, and all pivot, then all services that support video will be combined, and all
of those that don't will be combined. The resulting presence of those that don't will be combined. The resulting presence
document after merging will have two services - one with a document after merging will have two services - one with a
characteristic of video, and one with a characteristic of no-video. characteristic of video, and one with a characteristic of no-video.
An important pivot is the SIP address-of-record. When a PUA An important pivot is the SIP address-of-record. When a PUA
publishes a presence document, it includes its GRUU as the service publishes a presence document, it includes its GRUU as the service
URI in the <contact> element in the tuple. If the presence server URI in the <contact> element in the tuple. If the presence server
has access to registrar data, it can determine the AOR associated has access to registrar data, it can determine the AOR associated
with that GRUU (if there is one). By using the implicitly provided with that GRUU (if there is one). By using the implicitly provided
skipping to change at page 16, line 5 skipping to change at page 16, line 5
<tuple>). <tuple>).
If a presence document is obtained by using the device ID within each If a presence document is obtained by using the device ID within each
service element as a pivot, the result is a device view - there is a service element as a pivot, the result is a device view - there is a
single service in the document for each device. If all of the single service in the document for each device. If all of the
services are composed together, so that the final document has a services are composed together, so that the final document has a
single service, it is called a presentity view. A service view is single service, it is called a presentity view. A service view is
used to describe documents where services are either uncombined, or used to describe documents where services are either uncombined, or
are combined using a pivot other than the device ID. are combined using a pivot other than the device ID.
4.2.2.4 Splitting 4.2.2.4. Splitting
Splitting is the process of taking a single service or device data Splitting is the process of taking a single service or device data
element, and splitting into two services or devices. This is useful element, and splitting into two services or devices. This is useful
when the presence server or presence user agent wishes to model a when the presence server or presence user agent wishes to model a
complex application (such as a voice, video and IM enabled client) by complex application (such as a voice, video and IM enabled client) by
a multiplicity of distinct services. a multiplicity of distinct services.
The process of splitting involves taking the attributes (both status The process of splitting involves taking the attributes (both status
and characteristics) for the service, and determine which of the and characteristics) for the service, and determine which of the
component services that attribute will describe. In some cases, a component services that attribute will describe. In some cases, a
skipping to change at page 16, line 48 skipping to change at page 16, line 48
it can manufacture an entirely new URI (in conjunction with the it can manufacture an entirely new URI (in conjunction with the
domain owner, of course) as needed. domain owner, of course) as needed.
When a service is split, there is usually no reason to split the When a service is split, there is usually no reason to split the
device as well. The component services all run on the same device, device as well. The component services all run on the same device,
and there is much benefit to indicating that this is the case. For and there is much benefit to indicating that this is the case. For
example, it would allow a presence server that is compositing the example, it would allow a presence server that is compositing the
presence document for the presentity, to determine that all of the presence document for the presentity, to determine that all of the
component services are inactive if the device should fail. component services are inactive if the device should fail.
4.2.2.5 Default Composition Policy 4.2.2.5. Default Composition Policy
Unless a user specifies otherwise through an explicit composition Unless a user specifies otherwise through an explicit composition
policy statement, it is RECOMMENDED that presence servers follow the policy statement, it is RECOMMENDED that presence servers follow the
default composition policy described here. By following this default composition policy described here. By following this
default, the processing of the presence server becomes more default, the processing of the presence server becomes more
predictable by users and their agents, allowing them to set their predictable by users and their agents, allowing them to set their
presence status in ways that result in the desired predictable presence status in ways that result in the desired predictable
output. If a different default is used, users may be surprised by output. If a different default is used, users may be surprised by
the results of their actions. the results of their actions.
TODO: place default policy here TODO: place default policy here
4.2.3 Privacy Filtering 4.2.3. Privacy Filtering
Once the merging operation has been applied, the next step is to Once the merging operation has been applied, the next step is to
perform privacy filtering. Privacy filtering is a process by which perform privacy filtering. Privacy filtering is a process by which
information is removed or transformed in a raw presence document, for information is removed or transformed in a raw presence document, for
the purposes of withholding sensitive information about the the purposes of withholding sensitive information about the
presentity. Typically, the filtering operation runs at the bequest presentity. Typically, the filtering operation runs at the bequest
of the presentity, in order to protect their own privacy. However, of the presentity, in order to protect their own privacy. However,
privacy filtering can be instantiated by the operator, in order to privacy filtering can be instantiated by the operator, in order to
execute domain filtering policies, or even third parties that are execute domain filtering policies, or even third parties that are
authorized to specify filtering. authorized to specify filtering.
The exact privacy filtering operation that takes place depends on the The exact privacy filtering operation that takes place depends on the
identity of the watcher, and can also depend on other variables, such identity of the watcher, and can also depend on other variables, such
as time of day, the weather in Helsinki, and so on. The set of as time of day, the weather in Helsinki, and so on. The set of
information that dictates the way in which privacy filtering is information that dictates the way in which privacy filtering is
executed is called authorization policy. Authorization policy is executed is called authorization policy. Authorization policy is
expressed using the document format defined in [11]. expressed using the document format defined in [7].
These rules describe how a series of authorization documents are These rules describe how a series of authorization documents are
matched to the subscription, combined together, and then applied. matched to the subscription, combined together, and then applied.
This matching process is based on conditions described in each This matching process is based on conditions described in each
authorization document. These conditions can include the presence authorization document. These conditions can include the presence
state of the presentity itself. The presence state used to determine state of the presentity itself. The presence state used to determine
these authorization policies is different than the presence state these authorization policies is different than the presence state
sent to the watcher. To compute this presence state, the presence sent to the watcher. To compute this presence state, the presence
server runs the presence document generation process using the server runs the presence document generation process using the
default composition policy described above, and then stops the default composition policy described above, and then stops the
process once the raw presence document is generated. This raw process once the raw presence document is generated. This raw
presence document is used for any presence states needed to select presence document is used for any presence states needed to select
the authorization policies applicable to the watcher. the authorization policies applicable to the watcher.
4.2.4 Watcher Filtering 4.2.4. Watcher Filtering
Watcher filtering is the process by which information is further Watcher filtering is the process by which information is further
removed from the presence document. However, it is the watcher which removed from the presence document. However, it is the watcher which
specifies the information subset that they would like to receive. specifies the information subset that they would like to receive.
Watcher filtering is accomplished by including filter documents in Watcher filtering is accomplished by including filter documents in
subscription requests. These filters are then bound to the subscription requests. These filters are then bound to the
subscription, and applied to any presence document generated during subscription, and applied to any presence document generated during
the lifetime of that subscription. the lifetime of that subscription.
Filters are described using the document format defined in [18]. Filters are described using the document format defined in [11].
4.2.5 Post-Processing Composition 4.2.5. Post-Processing Composition
After the privacy and watcher filtering operations have been applied, After the privacy and watcher filtering operations have been applied,
the resulting presence document may contain service or device the resulting presence document may contain service or device
elements which no longer contain enough information to differentiate elements which no longer contain enough information to differentiate
one from another. As discussed above, the purpose of having multiple one from another. As discussed above, the purpose of having multiple
services or devices described in a document is to give the watcher services or devices described in a document is to give the watcher
choice about which service to invoke. If the services defined in a choice about which service to invoke. If the services defined in a
document all appear the same, differing only in the service URI, document all appear the same, differing only in the service URI,
there is no reason for a user to choose one over another. In such a there is no reason for a user to choose one over another. In such a
case, composition rules, and in particular, merging of services, will case, composition rules, and in particular, merging of services, will
skipping to change at page 18, line 48 skipping to change at page 18, line 48
[1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000. and Instant Messaging", RFC 2778, February 2000.
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004. RFC 3863, August 2004.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., "A Presence Event Package for the Session
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[6] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant [5] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, Messaging / Presence Protocol Requirements", RFC 2779,
February 2000. February 2000.
[7] Sparks, R., "SIMPLE Presence Document Usage Examples", [6] Rosenberg, J., "A Data Model for Presence",
draft-sparks-simple-pdoc-usage-00 (work in progress), draft-ietf-simple-presence-data-model-07 (work in progress),
October 2003. January 2006.
[8] Rosenberg, J., "A Data Model for Presence",
draft-ietf-simple-presence-data-model-02 (work in progress),
February 2005.
[9] Roach, A., "Identification of Services in RPID (Rich Presence
Information Data)", draft-roach-simple-service-features-00
(work in progress), February 2004.
[10] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-07 (work in progress), June 2005.
[11] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-02 (work in progress),
February 2005.
[12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[13] Rosenberg, J., "Obtaining and Using Globally Routable User [7] Rosenberg, J., "Presence Authorization Rules",
Agent (UA) URIs (GRUU) in the Session Initiation Protocol draft-ietf-simple-presence-rules-07 (work in progress),
(SIP)", draft-ietf-sip-gruu-03 (work in progress), June 2006.
February 2005.
[14] Niemi, A., "Session Initiation Protocol (SIP) Extension for [8] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004. Event State Publication", RFC 3903, October 2004.
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
[16] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [10] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP)
Preferences for the Session Initiation Protocol (SIP)", User Agent Capability Extension to Presence Information Data
RFC 3841, August 2004. Format (PIDF)", draft-ietf-simple-prescaps-ext-06 (work in
progress), January 2006.
[17] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to
Presence Information Data Format (PIDF)",
draft-ietf-simple-prescaps-ext-04 (work in progress),
June 2005.
[18] Khartabil, H., "An Extensible Markup Language (XML) Based [11] Khartabil, H., "An Extensible Markup Language (XML) Based
Format for Event Notification Filtering", Format for Event Notification Filtering",
draft-ietf-simple-filter-format-05 (work in progress), draft-ietf-simple-filter-format-05 (work in progress),
March 2005. March 2005.
[19] Schulzrinne, H., "Timed Presence Extensions to the Presence [12] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Information Data Format (PIDF) to Indicate Status Information Initiated Dialog Event Package for the Session Initiation
for Past and Future Time Intervals", Protocol (SIP)", RFC 4235, November 2005.
draft-ietf-simple-future-04 (work in progress), June 2005.
[20] Schulzrinne, H., "CIPID: Contact Information in Presence
Information Data Format", draft-ietf-simple-cipid-05 (work in
progress), June 2005.
[21] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short Message
Service", draft-wilde-sms-uri-09 (work in progress),
March 2005.
[22] Mealling, M., "A UUID URN Namespace",
draft-mealling-uuid-urn-05 (work in progress), January 2005.
[23] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-06 (work in progress),
April 2005.
[24] Schulzrinne, H., "The tel URI for Telephone Numbers",
draft-ietf-iptel-rfc2806bis-09 (work in progress), June 2004.
[25] Isomaki, M., "An Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usage for Manipulating Presence
Document Contents",
draft-ietf-simple-xcap-pidf-manipulation-usage-02 (work in
progress), October 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
skipping to change at page 22, line 41 skipping to change at page 21, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 45 change blocks. 
115 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/