< draft-ietf-simple-presence-data-model-06.txt   draft-ietf-simple-presence-data-model-07.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 26, 2006 October 23, 2005 Expires: July 26, 2006 January 22, 2006
A Data Model for Presence A Data Model for Presence
draft-ietf-simple-presence-data-model-06 draft-ietf-simple-presence-data-model-07
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 April 26, 2006. This Internet-Draft will expire on July 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the underlying presence data model used by This document defines the underlying presence data model used by
Session Initiation Protocol (SIP) for Instant Messaging Leveraging Session Initiation Protocol (SIP) for Instant Messaging and Presence
Presence Extensions (SIMPLE) presence agents. The data model Leveraging Extensions (SIMPLE) presence agents. The data model
provides guidance on how to map various communications systems into provides guidance on how to map various communications systems into
presence documents in a consistent fashion. presence documents in a consistent fashion.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Presentity URI . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Presentity URI . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Person . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Person . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Characteristics . . . . . . . . . . . . . . . . . . . 9 3.3.1 Characteristics . . . . . . . . . . . . . . . . . . . 9
3.3.2 Reach Information . . . . . . . . . . . . . . . . . . 10 3.3.2 Reach Information . . . . . . . . . . . . . . . . . . 10
3.3.3 Relative Information . . . . . . . . . . . . . . . . . 13 3.3.3 Relative Information . . . . . . . . . . . . . . . . . 13
3.3.4 Status . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.4 Status . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Device . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4 Device . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Modeling Ambiguity . . . . . . . . . . . . . . . . . . . . 17 3.5 Modeling Ambiguity . . . . . . . . . . . . . . . . . . . . 17
3.6 The Meaning of Nothing . . . . . . . . . . . . . . . . . . 18 3.6 The Meaning of Nothing . . . . . . . . . . . . . . . . . . 18
3.7 Status vs. Characteristics . . . . . . . . . . . . . . . . 19 3.7 Status vs. Characteristics . . . . . . . . . . . . . . . . 19
3.8 Presence Document Properties . . . . . . . . . . . . . . . 19 3.8 Presence Document Properties . . . . . . . . . . . . . . . 19
4. Motivation for the Model . . . . . . . . . . . . . . . . . . . 20 4. Motivation for the Model . . . . . . . . . . . . . . . . . . 21
5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 XML Schemas . . . . . . . . . . . . . . . . . . . . . . . 24 5.1 XML Schemas . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1 Common . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1 Common . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Data Model . . . . . . . . . . . . . . . . . . . . . . 25 5.1.2 Data Model . . . . . . . . . . . . . . . . . . . . . . 25
6. Extending the Presence Model . . . . . . . . . . . . . . . . . 26 6. Extending the Presence Model . . . . . . . . . . . . . . . . 26
7. Example Presence Document . . . . . . . . . . . . . . . . . . 26 7. Example Presence Document . . . . . . . . . . . . . . . . . 27
7.1 Basic IM Client . . . . . . . . . . . . . . . . . . . . . 26 7.1 Basic IM Client . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Internationalization Considerations . . . . . . . . . . . . 29
9.1 URN Sub-Namespace Registration . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
9.2 XML Schema Registrations . . . . . . . . . . . . . . . . . 30 10.1 URN Sub-Namespace Registration . . . . . . . . . . . . . 30
9.2.1 Data Model . . . . . . . . . . . . . . . . . . . . . . 30 10.2 XML Schema Registrations . . . . . . . . . . . . . . . . 31
9.2.2 Common Schema . . . . . . . . . . . . . . . . . . . . 30 10.2.1 Data Model . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10.2.2 Common Schema . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11.1 Normative References . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2 Informative References . . . . . . . . . . . . . . . . . . 31 12.1 Normative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 12.2 Informative References . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 35
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 [5] defines a model and across a set of devices. RFC 2778 [6] defines a model and
terminology for describing systems that provide presence information. terminology for describing systems that provide presence information.
RFC 3863 [1] defines an XML document format for representing presence RFC 3863 [1] defines an XML document format for representing presence
information. In these specifications, presence information is information. In these specifications, presence information is
modeled as a series of tuples, each of which contains a status, modeled as a series of tuples, each of which contains a status,
communications address, and other markup. However, neither communications address, and other markup. However, neither
specification gives guidance on exactly what a tuple is meant to specification gives guidance on exactly what a tuple is meant to
model, and how to map real world communications systems (and in model, and how to map real world communications systems (and in
particular, those built around the Session Initiation Protocol (SIP) particular, those built around the Session Initiation Protocol (SIP)
[6]) into a presence document. [7]) into a presence document.
In particular, several important concepts are not clearly modeled or In particular, several important concepts are not clearly modeled or
well delineated by RFC 2778. These are: well delineated by RFC 2778 and RFC 3863. These are:
Service: A communications service, such as instant messaging or Service: A communications service, such as instant messaging or
telephony, is a system for interaction between users that provides telephony, is a system for interaction between users that provides
certain modalities or content. certain modalities or content.
Device: A communications device is a physical component that a user Device: A communications device is a physical component that a user
interacts with in order to make or receive communications. interacts with in order to make or receive communications.
Examples are a phone, PDA or PC. Examples are a phone, PDA or PC.
Person: A person is the end user, and for the purposes of presence, Person: A person is the end user, and for the purposes of presence,
is characterized by states, such as "busy" or "sad" which impact is characterized by states, such as "busy" or "sad" which impact
their ability and willingness to communicate. their ability and willingness to communicate.
This specification defines these concepts more fully by means of a This specification defines these concepts more fully by means of a
presence data model, and concretely defines how to take real world presence data model, and concretely defines how to take real world
systems and map them into presence documents using that model. systems and map them into presence documents using that model. This
data model is defined in terms of an extension to RFC 3863.
2. Definitions 2. Definitions
This document makes use of many new terms, which are defined here. This document makes use of many additional terms beyond those defined
in RFC 2778 and RFC 3863. These new terms are:
Device: A device models the physical environment in which services Device: A device models the physical environment in which services
manifest themselves for users. Devices have characteristics which manifest themselves for users. Devices have characteristics which
are useful in allowing a user to make a choice about which are useful in allowing a user to make a choice about which
communications service to use. communications service to use.
Service: A service models a form of communications that can be used Service: A service models a form of communications that can be used
to interact with the user. to interact with the user.
Person: A person models the human user and their states that are Person: A person models the human user and their states that are
relevant to presence systems. relevant to presence systems.
Occurrence: A single description of a particular service, a Occurrence: A single description of a particular service, a
particular device or a person. There may be multiple occurrences particular device or a person. There may be multiple occurrences
for a particular service or device, or multiple person occurrences for a particular service or device, or multiple person occurrences
in a document, in cases where there is ambiguity that is best in a Presence Information Format (PIDF) document, in cases where
resolved by the watcher. there is ambiguity that is best resolved by the watcher.
Presentity: A presentity combines devices, services and person Presentity: A presentity combines devices, services and person
information for a complete picture of a user's presence status on information for a complete picture of a user's presence status on
the network. the network.
Presentity URI: A URI that acts as a unique identifier for a Presentity URI: A URI that acts as a unique identifier for a
presentity, and provides a handle for obtaining presence presentity, and provides a handle for obtaining presence
information about that presentity. information about that presentity.
Data Component: One of the device, service, or person parts of a Data Component: One of the device, service, or person parts of a
presence document. presence document.
Status: Generally dynamic information about a service, person or Status: Presence information about a service, person or device that
device. typically changes over time, in contrast to characteristics, which
are generally static.
Characteristics: Generally static information about a service, person Characteristics: Presence information about a service, person or
or device. Useful in providing context that identifies the device that is usually fixed over time, and descriptive in nature.
service or device as different from another service or device. Characteristics are useful in providing context that identifies
the service or device as different from another service or device.
Attribute: A status or characteristic. It represents a single piece Attribute: A status or characteristic. It represents a single piece
of presence information. of presence information.
Presence Attribute: A synonym for attribute. Presence Attribute: A synonym for attribute.
Composition: The act of combining a set of presence and event data Composition: The act of combining a set of presence and event data
about a presentity into a coherent picture of the state of that about a presentity into a coherent picture of the state of that
presentity. presentity.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
| | |+ | |+ | | | |+ | |+ |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
| | | |
| | | |
| Presentity (URI) | | Presentity (URI) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
Figure 1 Figure 1
The data model for presence is shown in Figure 1. The model seeks to The data model for presence is shown in Figure 1. The model seeks to
describe the presentity. There are four components in the model. describe the presentity, identified by a presentity URI. There are
They are the presentity URI, the person, the service, and the device. three components in the model. They are the person, the service, and
The latter three data components contain information (called the device. The latter three data components contain information
attributes) that provide a description about the service, person, or (called attributes) that provide a description of some aspect of the
device. It is central to this model that each attribute is service, person, or device. It is central to this model that each
affilitated with the service, person, or device because they describe attribute is affiliated with the service, person, or device because
that service, presentity or device. This is in contrast to a model they describe that service, presentity or device. This is in
whereby the attributes are associated with the service, presentity, contrast to a model whereby the attributes are associated with the
or device because they were reported by that service, presentity, or service, presentity, or device because they were reported by that
device. As an example, if a cell phone reports that a user is in a service, presentity, or device. As an example, if a cell phone
meeting, this would be done by including an attribute as part of the reports that a user is in a meeting, this would be done by including
person information, indicating a status of "in-a-meeting". The an attribute as part of the person information, indicating a status
presence information may also include information on the cell phone of "in-a-meeting". The presence information may also include
as a device. However, even though it is that device which is information on the cell phone as a device. However, even though it
reporting that the user is in a meeting, the busy indicator is not is that device which is reporting that the user is in a meeting, the
associated with the device, it is associated with the user and thus busy indicator is not associated with the device, it is associated
placed in the person component. with the user and thus placed in the person component.
3.1 Presentity URI 3.1 Presentity URI
The identifier for the presentity is a URI. For each unique The identifier for the presentity is a URI. For each unique
presentity in the network, there is one or more presentity URIs. A presentity in the network, there is one or more presentity URIs. A
presentity may have multiple URI because they are identified by both presentity may have multiple URI because they are identified by both
a pres URI [7] and a protocol specific URI, such as a SIP URI [6] or a URI from the Presence (pres) scheme [8] and a protocol specific
an XMPP URI [8]. Or, it can be because a user has several aliases in URI, such as a SIP URI [7] or an XMPP IRI [9]. Or, it can be because
a domain, all of which are equivalent identifiers for the presentity. a user has several aliases in a domain, all of which are equivalent
identifiers for the presentity.
When a document is constructed, the presentity URI is ideally set to When a document is constructed, the presentity URI is ideally set to
the identifier used to request the document in the first place. For the identifier used to request the document in the first place. For
example, if a document was requested through a SIP SUBSCRIBE request, example, if a document was requested through a SIP SUBSCRIBE request,
the presentity URI would match the Request URI of the SUBSCRIBE the presentity URI would match the Request URI of the SUBSCRIBE
request. This follows the principle of least surprise, since the request. This follows the principle of least surprise, since the
entity requesting the document may not be aware of the other entity requesting the document may not be aware of the other
identifiers for the presentity. identifiers for the presentity.
Independent of its scheme, the presentity URI is independent of any Irrespective of the scheme from which the URI is taken, the
of the services or devices that the presentity possesses. However, presentity URI is independent of any of the services or devices that
the URI is not just a name - it represents a resource that can be the presentity possesses. However, the URI is not just a name - it
subscribed to, in order to find out the status of the user. When the represents a resource that can be subscribed to, in order to find out
URI is a SIP URI, it will often be the address-of-record for the the status of the user. When the URI is a SIP URI, it will often be
user, to which SIP calls can be directed. This equivalence is not the address-of-record for the user, to which SIP calls can be
mandated by this specification, but is a recommended configuration directed. This equivalence is not mandated by this specification,
for easing the burden of remembering and storing identifiers for but is a recommended configuration for easing the burden of
users. remembering and storing identifiers for users.
3.2 Person 3.2 Person
The person data component models information about the user whom the The person data component models information about the user whom the
presence data is trying to describe. This information consists of presence data is trying to describe. This information consists of
characteristics of the user, and their status. characteristics of the user, and their status.
Characteristics of a person are the static information about a user Characteristics of a person are the static information about a user
that does not change under normal circumstances. Such information that does not change under normal circumstances. Such information
might include physical characteristics, such as age and height. might include physical characteristics, such as age and height.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
service. Rather, anything can be considered a service so long as it service. Rather, anything can be considered a service so long as it
exhibits a set of key properties defined by this model. In exhibits a set of key properties defined by this model. In
particular, Each service is associated with characteristics which particular, Each service is associated with characteristics which
identify the nature and capabilities of that service, with reach identify the nature and capabilities of that service, with reach
information that indicates how to connect to the service, with status information that indicates how to connect to the service, with status
information representing the state of that service, and relative information representing the state of that service, and relative
information that describes the ways in which that service relates to information that describes the ways in which that service relates to
others associated with the presentity. others associated with the presentity.
As a consequence, in this model, services are not explicitly As a consequence, in this model, services are not explicitly
enumerated. There is no central registry by which one goes finds the enumerated. There is no central registry where one finds identifiers
identifiers for each service. Consequently, each service does not for each service. Consequently, each service does not have a single
have a single "service" attribute that with values of "ptt" or "service" attribute with values such as "ptt" or "telephony". That
"telephony". That doesnt mean that these consolidated monikers doesnt mean that these consolidated monikers aren't useful; indeed,
aren't useful; indeed, they represent an essential summary of what they represent an essential summary of what the service is. Such
the service is. Such summarization is useful in creating icons that summarization is useful in creating icons that allow a user to choose
allow a user to choose one service over another. A watcher is free one service over another. A watcher is free to create such
to create such summarization information from any of the information summarization information from any of the information associated with
associated with a service. The reach information often provides a service. The reach information often provides valuable information
valuable information for creating such a summarization. Oftentimes, for creating such a summarization. Oftentimes, the scheme of the URI
the scheme of the URI is synonomous with the view of what a service is synonomous with the view of what a service is. An "sms" URI [10]
is. An "sms" URI [9] clearly indicates SMS, for example. For some clearly indicates SMS, for example. For some URIs, there may be many
URIs, there may be many services available, for example, SIP or tel services available, for example, SIP or tel [11], in which case the
[10], in which case the scheme is less meaningful to create a scheme is less meaningful as a way of creating a summarization. The
summarization. The reach information could also indicate that reach information could also indicate that certain application
certain application software has to be invoked (such as a videogame), software has to be invoked (such as a videogame), in which case that
in which case that aspect of the reach information would be useful aspect of the reach information would be useful for generating an
for generating an iconic representation of the game. iconic representation of the game.
3.3.1 Characteristics 3.3.1 Characteristics
Each service is adorned with characteristics that describe the nature Each service is adorned with characteristics that describe the nature
and capabilities of the service that will be experienced when a and capabilities of the service that will be experienced when a
watcher invokes that URI. The nature of a service is a set of watcher invokes that URI. The nature of a service is a set of
properties that are relatively static across communication sessions properties that are relatively static across communication sessions
established to that service. The nature of a service tends to be established to that service. The nature of a service tends to be
descriptive. Examples of the nature of a service are that it descriptive. Examples of the nature of a service are that it
represents an interactive voice response or voicemail server, that it represents an interactive voice response or voicemail server, that it
is an auomata, or that it is a telephony service used for the is an auomata, or that it is a telephony service used for the
purposes of work. Capabilities, on the other hand, represent purposes of work. Capabilities, on the other hand, represent
properties that might be exhibited, and whether or not they are properties that might be exhibited, and whether or not they are
exhibited depends on negotiation and other dynamic functions that exhibited depends on negotiation and other dynamic functions that
take place during session establishment. Examples of such take place during session establishment. Examples of such
capabilities are the type of media that might be used, the capabilities are the type of media that might be used, the
directionality of communications that are permitted, the SIP directionality of communications that are permitted, the SIP
extensions supported, and so on. Capabilities can be very complex; extensions supported, and so on. Capabilities can be very complex;
RFC 2533, for example [11] describes a model for representing for example, RFC 2533 [12] describes a model for representing
capabilities through N-ary boolean functions. It is difficult to capabilities through N-ary boolean functions. It is difficult to
differentiate a capability with one modality (this service only does differentiate a capability with one modality (e.g., this service only
voice) from a characteristic that represents the nature of a service. does voice) from a characteristic that represents the nature of a
However, it is not important to do so. service. However, it is not important to do so.
Characteristics are important when multiple services are indicated. Characteristics are important when multiple services are indicated.
That is because the purpose of listing multiple services in a That is because the purpose of listing multiple services in a
presence document is to give the watcher a *choice*. That is, the presence document is to give the watcher a *choice*. That is, the
presentity is explicitly offering the watcher an opportunity to presentity is explicitly offering the watcher an opportunity to
contact them using a multiplicity of different services. To help the contact them using a multiplicity of different services. To help the
watcher make a decision, the presence document includes watcher make a decision, the presence document includes
characteristics of each service which help differentiate the services characteristics of each service which help differentiate the services
from each other, and give the watcher the context in which to make a from each other, and give the watcher the context in which to make a
choice. choice.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
It is perfectly valid for a presence document to contain just a It is perfectly valid for a presence document to contain just a
single service. This is permitted even if the presentity actually single service. This is permitted even if the presentity actually
has multiple services at their disposal. The lack of multiple has multiple services at their disposal. The lack of multiple
services in the document merely means that the presentity is not services in the document merely means that the presentity is not
offering a choice to the watcher. In such a case, the service offering a choice to the watcher. In such a case, the service
characteristics are less important, but may be helpful in allowing a characteristics are less important, but may be helpful in allowing a
watcher to decide if they wish to communicate at all. watcher to decide if they wish to communicate at all.
3.3.2 Reach Information 3.3.2 Reach Information
The reach information for a service are the instructions for the The reach information for a service provides the instructions for the
recipient of a document on how to correctly contact that service. recipient of a document on how to correctly contact that service.
When a service is accessible over a communications network, reach When a service is accessible over a communications network, reach
information includes a URI that can be "hit" in order to access the information includes a URI that can be "hit" in order to access the
service. This URI is called the service URI. However, some services service. This URI is called the service URI. However, some services
are not accessible over a communications network (such as in-person are not accessible over a communications network (such as in-person
communications or a written letter), and as such, may not utilize a communications or a written letter), and as such, may not utilize a
URI. URI.
Even for services reachable over a communications network, the URI Even for services reachable over a communications network, the URI
skipping to change at page 11, line 38 skipping to change at page 11, line 38
reach information. If this was not the case, the user would have no reach information. If this was not the case, the user would have no
way to choose between the services. This means that the reach way to choose between the services. This means that the reach
information represents a unique identifier for the service. However, information represents a unique identifier for the service. However,
a presence document can contain multiple occurrences of a particular a presence document can contain multiple occurrences of a particular
service, each of which contains the same reach information, but service, each of which contains the same reach information, but
differs in its occurrence identifier. Multiple occurrences of a differs in its occurrence identifier. Multiple occurrences of a
service exist in a document when the state of the service is service exist in a document when the state of the service is
ambiguous, as discussed in Section 3.5. ambiguous, as discussed in Section 3.5.
Because the reach information serves as an idenfifier for a service, Because the reach information serves as an idenfifier for a service,
it also serves as a way to figure out whether something is one it also serves as a way to figure out whether a communications
service or two. Something cannot be a service unless there is a way capability should be represented as one service or more. Something
to reach it separately from another service. As an example, consider cannot be a service unless there is a way to reach it separately from
a softphone application that can do audio and video. It is not another service. As an example, consider a softphone application
possible to describe this softphone as two services - one capable of that is capable of audio and video. It is not possible to describe
just audio, and one capable of just video. That's because there is this softphone as two services - one capable of just audio, and one
no way to reach the video-only service, for example; sending a SIP capable of just video. That's because there is no way to reach the
INVITE with just a video stream doesn't suffice, since one can always video-only service, for example; sending a SIP INVITE with just a
add the audio stream later and it will work. Video and audio, in video stream doesn't suffice, since one can always add the audio
this case, represent capabilities for a single service. stream later and it will work. Video and audio, in this case,
represent capabilities for a single service.
The reach information represents a weak form of contract; the The reach information represents a weak form of contract; the
presentity tells the watcher that, if the watcher utilizes the reach presentity tells the watcher that, if the watcher utilizes the reach
information included in the presence document, the watcher might be information included in the presence document, the watcher might be
connected to a service described by the characteristics included in connected to a service described by the characteristics included in
the presence document. It is important to stress that this is not a the presence document. It is important to stress that this is not a
guarantee in any way. It cannot be a guarantee for two reasons. guarantee in any way. It cannot be a guarantee for two reasons.
Firstly, the service in the document might actually be modelling a Firstly, the service in the document might actually be modelling a
number of actual services used by the user, and it may not be number of actual services used by the user, and it may not be
possible to connect the watcher to a service with all of the possible to connect the watcher to a service with all of the
characteristics described in the presence document. Secondly, the characteristics described in the presence document. Secondly, the
preferences of the presentity always take precedence. The caller preferences of the presentity always take precedence. The caller
might ask to be connected to the video service, but it is permissible might ask to be connected to the video service, but it is permissible
to connect them to a different service if that is the wish of the to connect them to a different service if that is the wish of the
presentity. presentity.
This loose contract also provides some guidance on the type of URI This loose contract also provides some guidance on the type of URI
that are most ideally suited for the service URI. A URN [3] can be that is most ideally suited for the service URI. A URN [3] can be
used as the service URI. However, since a URI could be resolved to used as the service URI. However, since a URN could be resolved to
potentially any number of different URI, the characteristics, status, potentially any number of different URI, the characteristics, status,
and relative information need to be sensible for all of the URI which and relative information need to be sensible for all of the URI which
can be resolved from the URN. As the URN becomes increasingly can be resolved from the URN. As the URN becomes increasingly
"vague" in terms of the service it identifies, the amount of presence "vague" in terms of the service it identifies, the number of presence
attributes that can be included become increasingly small. attributes that can be included decreases correspondingly.
The tel URI [10] shares similar properties with a URN, and the same The tel URI [11] shares similar properties with a URN, and the same
considerations apply. If, for example, the telephone number exists considerations apply. If, for example, the telephone number exists
in enum [13] and multiple enum services are defined, including voice in ENUM [14] and multiple ENUM services are defined, including voice
and messaging, it is likely that very little characteristic and messaging, it is likely that very little characteristic
information can be included in that service. If, however, a tel URI information can be included in that service. If, however, a tel URI
with the enum dip indicator is present [14], or there is no enum has only a single ENUM service defined, and it refers to a telephone
record for that number, it means that the number corresponds to a service on the PSTN, more can be said about its characteristics,
telephone on the PSTN, and more can be said about its status, and relative priority.
characteristics, status, and relative priority.
It is important to point out that there can be a many to one mapping It is important to point out that there can be a many to one mapping
of reach information to a service. That is, a particular service can of reach information to a service. That is, a particular service can
be reachable by potentially an infinite variety of reach information. potentially be reachable through an infinite number of reach
This is true even if the reach information is just the service URI; information sets. This is true even if the reach information is just
it is permissible for multiple service URI to reach the same service. the service URI; it is permissible for multiple service URIs to reach
Within any particular document there will be a single service URI. the same service. Within any particular document there will be a
However, it is allowed and even valuable to provide different service single service URI. However, it is allowed and even valuable to
URIs to different watchers, or to change the service URI provided to provide different service URIs to different watchers, or to change
a particular watcher over time. Doing so affords many benefits, in the service URIs provided to a particular watcher over time. Doing
fact. It can allow the recipient of a communications attempt to so affords many benefits, in fact. It can allow the recipient of a
determine the context for that attempt - that the attempt was made as communications attempt to determine the context for that attempt -
a result of trying to reach a particular service in a particular that the attempt was made as a result of trying to reach a particular
presence document. This can be used as a technique for preventing service in a particular presence document. This can be used as a
communications spam, for example [15]. technique for preventing communications spam, for example [15].
It is also possible for a presence document to contain a service that It is also possible for a presence document to contain a service that
has no reach information at all. In such a case, the presentity is has no reach information at all. In such a case, the presentity is
indicating that the service exists, but is electing not to offer the indicating that the service exists, but is electing not to offer the
watcher the opportunity to connect to it. One such example would be watcher the opportunity to connect to it. One such example would be
to let a watcher know that a user has a telephony service, and that to let a watcher know that a user has a telephony service, and that
they are busy, but in order to avoid receipt of a call, no reach they are busy, but in order to avoid receipt of a call, no reach
information is provided. information is provided.
In an ideal system, the URI alone would represent sufficient reach In an ideal system, the URI alone would represent sufficient reach
skipping to change at page 13, line 43 skipping to change at page 13, line 43
priorities of .2 and .1 respectively. priorities of .2 and .1 respectively.
3.3.4 Status 3.3.4 Status
Each service also has a status. Status represents generally dynamic Each service also has a status. Status represents generally dynamic
information about the availability of communications using that information about the availability of communications using that
service. This is in constrast to characteristics, which describe service. This is in constrast to characteristics, which describe
fairly static properties of the various services. The simplest form fairly static properties of the various services. The simplest form
of status is the basic status, which is a binary indicator of of status is the basic status, which is a binary indicator of
availability for communications using that service. It can have availability for communications using that service. It can have
values of either closed or open. Closed means that communication to values of either "closed" or "open". "Closed" means that
the service will, in all likelihood, fail, or will not reach the communication to the service will, in all likelihood, fail, or will
intended party, or will not result in communications as described by not reach the intended party, or will not result in communications as
the characteristics of the service. As an example, if a call is described by the characteristics of the service. As an example, if a
forwarded to voicemail if the user is busy or unavailable, the call is forwarded to voicemail if the user is busy or unavailable,
service is marked as closed. Similarly, a presentity may include a the service is marked as "closed". Similarly, a presentity may
hotel phone number as a service URI. After check-out, the phone include a hotel phone number as a service URI. After check-out, the
number will still ring, but reach the chambermaid or the next guest. phone number will still ring, but reach the chambermaid or the next
Thus, it would be declared "closed" by that presentity. As another guest. Thus, it would be declared "closed" by that presentity. As
example, if a user has a SIP URI as their service URI, pointing to a another example, if a user has a SIP URI as their service URI,
SIP softphone application, and the PC shuts down, calls to that SIP pointing to a SIP softphone application, and the PC shuts down, calls
URI will return a 480 response code. This service would also be to that SIP URI will return a 480 response code. This service would
declared "closed". Open implies the opposite - the communications to also be declared "closed". "Open" implies the opposite - that
this service will likely succeed and reach the desired target. communications to this service will likely succeed and reach the
desired target.
It is also possible to have status information that is dependent on It is also possible to have status information that is dependent on
the characteristics of the communications session that eventually get the characteristics of the communications session that eventually
set up. For example, a status attribute can be defined that gets set up. For example, a status attribute can be defined that
indicates that a softphone service is available if instant messaging indicates that a softphone service is available if instant messaging
is used, but unavailable if audio is used. is used, but unavailable if audio is used.
Other status information might indicate more details on why the Other status information might indicate more details on why the
service is available or unavailable. For example, a telephony service is available or unavailable. For example, a telephony
service might have additional status to indicate that the user is on service might have additional status to indicate that the user is on
the phone, or that the user is handling 3 calls for that service. the phone, or that the user is handling 3 calls for that service.
Services inherently have a lot of dynamic state associated with them. Services inherently have a lot of dynamic state associated with them.
For example, consider a wireless telephony service (i.e., a cell For example, consider a wireless telephony service (i.e., a cell
phone). There are many dynamic statuses of this service - whether or phone). There are many dynamic statuses of this service - whether or
not the phone is registered, whether or not its roaming, which not the phone is registered, whether or not it is roaming, which
provider it has roamed into, its signal strength, how many calls it provider it has roamed into, its signal strength, how many calls it
has, what the state of those calls are, how long the user has been in has, what the state of those calls are, how long the user has been in
a call, and so on. As another example, consider an IM service. The a call, and so on. As another example, consider an IM service. The
statuses in this service include whether or not the user is statuses in this service include whether or not the user is
registered, how long they have been registered, whether they have an registered, how long they have been registered, whether they have an
IM conversation in progress, how many IM conversations are in IM conversation in progress, how many IM conversations are in
progress, whether the user is typing, to whom they are typing, and so progress, whether the user is typing, to whom they are typing, and so
on. on.
However, not all of this dynamic state is appropriate to include However, not all of this dynamic state is appropriate to include
within a service data component of a presence document. Information within a service data component of a presence document. Information
is included only when it has a bearing on helping the watcher decide is included only when it has a bearing on helping the watcher decide
whether or not to initiate communications with that service, or whether or not to initiate communications with that service, or
helping them decide when to initiate it, if not now. As an example, helping them decide when to initiate it, if not now. As an example,
whether a cell phone has roamed or not does not pass this litmus whether a cell phone has strong signal strength or just good signal
test. Knowing this is not likely to have an impact on a decision to strength does not pass the litmus test. Knowing this is not likely
use this service. to have an impact on a decision to use this service.
3.4 Device 3.4 Device
Devices model the physical operating environment in which services Devices model the physical operating environment in which services
execute. Examples of devices include cell phones, PCs, laptops, execute. Examples of devices include cell phones, PCs, laptops,
PDAs, consumer telephones, enterprise PBX extensions, and operator PDAs, consumer telephones, enterprise PBX extensions, and operator
dispatch consoles. dispatch consoles.
The mapping of services to devices are many to many. A single The mapping of services to devices are many to many. A single
service can execute in multiple devices. Consider a SIP telephony service can execute in multiple devices. Consider a SIP telephony
skipping to change at page 15, line 21 skipping to change at page 15, line 22
Furthermore, a single device can support no services. In such a Furthermore, a single device can support no services. In such a
case, the device has no useful presence information by itself. case, the device has no useful presence information by itself.
However, when composed with other documents that describe this same However, when composed with other documents that describe this same
device in relation to a service, a richer presence document can be device in relation to a service, a richer presence document can be
created. For example, consider a Radio Frequency ID (RFID) tag as a created. For example, consider a Radio Frequency ID (RFID) tag as a
device. This device does not execute any services. However, as a device. This device does not execute any services. However, as a
device, it has properties, such as location, and it may have network device, it has properties, such as location, and it may have network
connectivity with which it can report its status and characteristics. connectivity with which it can report its status and characteristics.
If a video telephone were to report that it was running a video If a video telephone were to report that it was running a video
service, and one of its properties was that it was tagged with that service, and one of its properties was that it was tagged with that
RFID, a compostitor could combine the two documents together, and use RFID, a compositor could combine the two documents together, and use
the location of the RFID to say something about the location of the the location of the RFID to say something about the location of the
video telephony device. video telephony device.
Devices are identified with a device ID. A device ID is a URI that Devices are identified with a device ID. A device ID is a URI that
is a globally and temporally unique identifier for the device. In is a globally and temporally unique identifier for the device. In
particular, a device ID is a URN. The URN has to be unique across particular, a device ID is a URN. The URN has to be unique across
all other devices for a particular presentity. However, it is also all other devices for a particular presentity. However, it is also
highly desirable that it be persistent across time, globally unique, highly desirable that it be persistent across time, globally unique,
and computable in a fashion so that different systems are likely to and computable in a fashion so that different systems are likely to
refer to the device using the same ID. With these properties, refer to the device using the same ID. With these properties,
skipping to change at page 17, line 16 skipping to change at page 17, line 17
available to that service. If there is a desire to indicate that available to that service. If there is a desire to indicate that
higher quality video is available on a device, that should be done by higher quality video is available on a device, that should be done by
including service characteristics that say just that. The speed of including service characteristics that say just that. The speed of
the CPU might be useful in helping the watcher differentiate between the CPU might be useful in helping the watcher differentiate between
a device that is a PC and one that is a cell phone, in the case where a device that is a PC and one that is a cell phone, in the case where
the watcher wishes to call the user's cell phone. the watcher wishes to call the user's cell phone.
Similarly, if there is dynamic device status (such as whether the Similarly, if there is dynamic device status (such as whether the
device is on or off), and this state impacts the state of the device is on or off), and this state impacts the state of the
service, this is represented by adjusting the state of the service. service, this is represented by adjusting the state of the service.
Unless a consumer of a presence document has apriori knowledge Unless a consumer of a presence document has a priori knowledge
indicating otherwise (note that presence agents often do), the state indicating otherwise (note that presence agents often do), the state
of a device has no bearing on the state of the service. of a device has no bearing on the state of the service.
Just like services, there is no enumeration of device types - PCs, Just like services, there is no enumeration of device types - PCs,
PDAs, cell phones, etc. Rather, the device is defined by its PDAs, cell phones, etc. Rather, the device is defined by its
characteristics, from which a watcher can extrapolate whether the characteristics, from which a watcher can extrapolate whether the
device is a PDA, cell phone, or what have you. device is a PDA, cell phone, or what have you.
It is important to point out that the device is a *model* of the It is important to point out that the device is a *model* of the
underlying physical systems in which services execute. There is underlying physical systems in which services execute. There is
nothing that says that this model cannot be used to talk about nothing that says that this model cannot be used to talk about
systems where services run in virtualized systems, rather than real systems where services run in virtualized systems, rather than real
ones. For example, if a PC is executing a virtual machine, and ones. For example, if a PC is executing a virtual machine, and
running services within that virtual machine, it is perfectly running services within that virtual machine, it is perfectly
acceptable to use this model to talk about that PC as being composed acceptable to use this model to talk about that PC as being composed
of two separate devices. of two separate devices.
3.5 Modeling Ambiguity 3.5 Modeling Ambiguity
Ambiguity is a reality of an presence system, and it is explicitly Ambiguity is a reality of a presence system, and it is explicitly
modeled by this specification. Ambiguity exists when there are modeled by this specification. Ambiguity exists when there are
multiple pieces of information about a person, a particular device, multiple pieces of information about a person, a particular device,
or a particular service. This ambiguity naturally arises when or a particular service. This ambiguity naturally arises when
multiple elements publish information about the person, a particular multiple elements publish information about the person, a particular
service, or a particular device. In some cases, a compositor can service, or a particular device. In some cases, a compositor can
resolve the ambiguity in an automated way, and combine together the resolve the ambiguity in an automated way, and combine together the
data about the person, device or service into a single coherent data about the person, device or service into a single coherent
description. In other cases, it cannot, perhaps because the description. In other cases, it cannot, perhaps because the
compositor lacks the ability to do so. compositor lacks the ability to do so.
However, in many cases, the resolution of this ambiguity is best left However, in many cases, the resolution of this ambiguity is best left
to the watcher that consumes the document. This consumer could be an to the watcher that consumes the document. This consumer could be an
application with more information than the compositor, and thus be application with more information than the compositor, and thus be
able to do a better job of resolving the ambiguity. Or, it may be able to do a better job of resolving the ambiguity. Or, it may be
presented to the human user, and the human can often resolve the presented to the human user, and the human can often resolve the
ambiguity. Unsurprisingly, a human can often do this far better than ambiguity. Unsurprisingly, a human can often do this far better than
an automata can. an automaton can.
To model ambiguity, the model allows each service, each device, or To model ambiguity, the model allows each service, each device, or
the person component to contain multiple occurrences. Each the person component to contain multiple occurrences. Each
occurrence has a unique identifier, called the occurrence identifier. occurrence has a unique identifier, called the occurrence identifier.
This identifier is unique across all other identifiers for any This identifier is unique across all other identifiers for any
service, device, or person. That is, its uniqueness is scoped within service, device, or person. That is, its uniqueness is scoped within
all of the services, devices and person elements for a particular all of the services, devices and person elements for a particular
presentity. The identifier ideally persists over time, since it presentity. The identifier ideally persists over time, since it
serves as a valuable handle for setting composition and authorization serves as a valuable handle for setting composition and authorization
policies. Even if there is a single occurrence for a particular policies. Even if there is a single occurrence for a particular
skipping to change at page 18, line 34 skipping to change at page 18, line 35
represents a reasonable choice for a service URI. However, if the represents a reasonable choice for a service URI. However, if the
status of such a UA instance could not be determined unambiguously, a status of such a UA instance could not be determined unambiguously, a
presence document could include two or more occurrences of the presence document could include two or more occurrences of the
service modeling that UA instance. In such a case, each occcurrence service modeling that UA instance. In such a case, each occcurrence
has a unique occurence ID, but they share the same service URI, and has a unique occurence ID, but they share the same service URI, and
consequently, the same instance ID. consequently, the same instance ID.
When multiple occurrences exist in a document, it is important that When multiple occurrences exist in a document, it is important that
some of the attributes of the device, service or person help the some of the attributes of the device, service or person help the
recipient resolve the ambiguity. For humans, the note field and recipient resolve the ambiguity. For humans, the note field and
timestamp serve as valuable tools. For an automata, nearly any timestamp serve as valuable tools. For an automaton, nearly any
attribute of the device, service or person can be used to resolve the attribute of the device, service or person can be used to resolve the
ambiguity. The timestamp in particular is very useful for both ambiguity. The timestamp in particular is very useful for both
humans and automata. As described in RFC 3863 [1], the timestamp humans and automaton. As described in RFC 3863 [1], the timestamp
provides the time of most recent change for the tuple. This provides the time of most recent change for the tuple. This
specification defines the timestamp for person and device components specification defines the timestamp for person and device components
as well, with the same meaning. Absent other information, the as well, with the same meaning. Absent other information, the
person, device, or service that most recently changed can be used as person, device, or service that most recently changed can be used as
the more reliable source of data. However, such a resolution the more reliable source of data. However, such a resolution
algorithm is not normatively required in any way. algorithm is not normatively required in any way.
3.6 The Meaning of Nothing 3.6 The Meaning of Nothing
It is clear that the existence of a presence attribute in a document It is clear that the existence of a presence attribute in a document
tells something to a watcher about the value of that presence tells something to a watcher about the value of that presence
attribute. What, however, does the absence of a presence attribute attribute. What, however, does the absence of a presence attribute
say? This data model follows the lead of RFC 3840 [12], which is say? This data model follows the lead of RFC 3840 [13], which is
used to define capabilities for SIP user agents. In that used to define capabilities for SIP user agents. In that
specification, if a capability declaration omits a particular feature specification, if a capability declaration omits a particular feature
tag, it means that the agent is making no definitive statement either tag, it means that the agent is making no definitive statement either
way about whether this feature tag is supported or not. The same is way about whether this feature tag is supported or not. The same is
true here - the absence of a presence attribute from a document means true here - the absence of a presence attribute from a document means
that a watcher cannot make any definitive statement about the value that a watcher cannot make any definitive statement about the value
for that presence attribute. It may be absent because it is being for that presence attribute. It may be absent because it is being
withheld from the watcher, or it may be absent because that attribute withheld from the watcher, or it may be absent because that attribute
is not supported by the presentity's software. Neither conclusion is not supported by the presentity's software. Neither conclusion
can be drawn. can be drawn.
skipping to change at page 23, line 23 skipping to change at page 23, line 26
which do not have their own <note> element. In other words, if a which do not have their own <note> element. In other words, if a
<person> element has its own <note>, that is the <note> for that <person> element has its own <note>, that is the <note> for that
<person> element. If a <person> element does not have its own <note> <person> element. If a <person> element does not have its own <note>
element, the <note> element that is the direct child of <presence> is element, the <note> element that is the direct child of <presence> is
the <note> for that <person>. If there is no <note> element the <note> for that <person>. If there is no <note> element
underneath the <person> element, and no <note> element that is a underneath the <person> element, and no <note> element that is a
direct child of <presence>, then that <person> element has no <note>. direct child of <presence>, then that <person> element has no <note>.
This specification also introduces the <device> element, which can This specification also introduces the <device> element, which can
appear as a child to <presence>. There can be zero or more appear as a child to <presence>. There can be zero or more
occurrences of this element per document. Each one has a mandatory occurrences of this element per document. The <device> element can
"id" attribute which contains the occurrence identifier for the appear either before or after the <person> element; there are no
device. Like <person>, <device> contains the <status> element, which constraints on order. Each <device> element has a mandatory "id"
contains any number of elements containing dynamic status attribute which contains the occurrence identifier for the device.
information, followed by any number of elements containing Like <person>, <device> contains the <status> element, which contains
characteristic information. This is followed by <deviceID>, which any number of elements containing dynamic status information,
contains the URN for the device ID for this device. This is followed followed by any number of elements containing characteristic
by an optional <note> and optional <timestamp>. information. This is followed by <deviceID>, which contains the URN
for the device ID for this device. This is followed by an optional
<note> and optional <timestamp>.
A client that receives a PIDF document containing the <device> and A client that receives a PIDF document containing the <device> and
<person> elements will ignore them. Furthermore, since the semantics <person> elements, but does not understand them (because it doesn't
of service as defined here are aligned with the meaning of a tuple as implement this specification) will ignore them. Furthermore, since
defined in RFC 2778 and RFC 3863, documents incorporating the the semantics of service as defined here are aligned with the meaning
concepts defined in this model are compliant with older of a tuple as defined in RFC 2778 and RFC 3863, documents
implementations. incorporating the concepts defined in this model are compliant with
older implementations.
It's important to note that the mapping of the presence data model It's important to note that the mapping of the presence data model
into a PIDF document is merely an exercise in syntax. into a PIDF document is merely an exercise in syntax.
Presence documents created according to this model MUST be valid, Presence documents created according to this model MUST be valid,
with the following exception. A compositor is permitted to create a with the following exception. A compositor is permitted to create a
presence document which it cannot fully validate but which otherwise presence document which it cannot fully validate but which otherwise
validates when processed according to the lax processing rules validates when processed according to the lax processing rules
allowed by the schema of the compositor. However, it is not expected allowed by the schema of the compositor. However, it is not expected
that entities receiving these documents would perform schema that entities receiving these documents would perform schema
skipping to change at page 25, line 4 skipping to change at page 25, line 8
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:attributeGroup name="fromUntil"> <xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup> </xs:attributeGroup>
<xs:complexType name="empty"/> <xs:complexType name="empty"/>
</xs:schema> </xs:schema>
5.1.2 Data Model 5.1.2 Data Model
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model" <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model" xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/> <xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t"> <xs:element name="deviceID" type="deviceID_t">
<xs:annotation> <xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation> <xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="device"> <xs:element name="device">
<xs:annotation> <xs:annotation>
<xs:documentation>Contains information about <xs:documentation>Contains information about the
the device</xs:documentation> device</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/> <xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"/> <xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/> <xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/> <xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="person"> <xs:element name="person">
<xs:annotation> <xs:annotation>
<xs:documentation>Contains information about the <xs:documentation>Contains information about the human
human user</xs:documentation> user</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"> minOccurs="0" maxOccurs="unbounded">
<xs:annotation> <xs:annotation>
<xs:documentation>Characteristic and status <xs:documentation>Characteristic and status
information</xs:documentation> information</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:any> </xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"/> <xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/> <xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/> <xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
6. Extending the Presence Model 6. Extending the Presence Model
When new presence attributes are added, any such extension has to When new presence attributes are added, any such extension has to
skipping to change at page 28, line 43 skipping to change at page 28, line 43
<rp:on-the-phone/> <rp:on-the-phone/>
</rp:activities> </rp:activities>
</dm:person> </dm:person>
<dm:device id="pc122"> <dm:device id="pc122">
<rp:user-input>idle</rp:user-input> <rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID> <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
It is worth commenting further on the value of having a separate It is worth commenting further on the value of having a separate
device element just to convey the idle indicator. As described device element just to convey the idle indicator. The idle
above, the idle indication of interest is really an indicator that indication of interest is really an indicator that the device is
the device is idle. By making that explicit, the idle indicator can idle. By making that explicit, the idle indicator can be used by the
be used by the presence server to affect the state of other services presence server to affect the state of other services running on the
running on the same device. For example, let say there is a voip same device. For example, let say there is a VoIP application
application running on the same device. This application reports its running on the same device. This application reports its presence
presence information using the example below. Since it reports that state separately, but indicates that it runs on the same device.
it runs on the same device, the presence server can use the status of Since it has indicated hat it runs on the same device, the presence
the service to further refine the idle indicator of the device. server can use the status of the service to further refine the idle
indicator of the device. Specifically, if the user is using their
Specifically, if the user is using their voip application, the VoIP application, the presence server knows that the device is in
presence server knows that the device is in use, even if the IM use, even if the IM application reports that the device is idle.
application reports that the device is idle. Typically, idleness is Typically, idleness is determined by lack of keyboard or mouse input,
determined by lack of keyboard or mouse input, neither of which might neither of which might be used during a VoIP call.
be used during a voip call.
In a more simplistic case, reporting the idle indicator as part of In a more simplistic case, reporting the idle indicator as part of
the device status allows that indicator to be used for other services the device status allows that indicator to be used for other services
on the same device. Taking, again, the example of the voip on the same device. Taking, again, the example of the VoIP
application on the same device, if the voip application does not application on the same device, if the VoIP application does not
report any device information, and a watcher is not provided report any device information, and a watcher is not provided
information on the IM service, the presence document sent to the information on the IM service, the presence document sent to the
watcher can include the device status. Because of the usage of the watcher can include the device status. Because of the usage of the
device IDs and the device information, the presence server can device IDs and the device information, the presence server can
correlate the device status as reported by the IM application with correlate the device status as reported by the IM application with
the voip service, and use them together. the VoIP service, and use them together.
8. Security Considerations 8. Security Considerations
The presence information described by the model defined here is very The presence information described by the model defined here is very
sensitive. It is for this reason that privacy filtering plays a key sensitive. It is for this reason that privacy filtering plays a key
role in the processing of presence data, as described above. role in the processing of presence data. Privacy filtering is the
Presence systems based on this model need to provide such a privacy act of applying permissions to a presence document for the purposes
capability, and furthermore, need to protect the integrity and of removing information that a watcher is not authorized to see. In
confidentiality of the data. more general terms, privacy filtering is a form of authorization.
Privacy filtering can also ensure that a watcher cannot see any
presence data for a presentity, and indeed, it can even ensure that
the presentity doesn't know that it is being blocked. The SIP
presence specifications (RFC 3856 [17]) require that such
authorization processing be performed before divulging presence
information. Specifications have also been defined for conveying
authorization policies to presence servers [22].
9. IANA Considerations Integrity of presence information is also critical. Modification of
presence data by an attacker can lead to diverted communications, for
example. Protocols used to transport presence data, such as SIP for
presence, are used to provide necessary integrity functions.
9. Internationalization Considerations
This specification defines a data model which contains mostly tokens
that are meant for consumption by programs, not directly by humans.
Programs are expected to translate those tokens into language-
appropriate text strings according to the preferences of the watcher.
However, this specification defines a <note> element that can contain
free text. This element, and other ones defined by extensions to
PIDF which can contain free text SHOULD be labeled with the 'xml:
lang' attribute to indicate their language and script. This
specification allows multiple occurrences of the <note> element so
that the presentity can convey the note in multiple scripts and
languages. If no 'xml:lang' attribute is provided, the default value
is "i-default" [5].
Since the presence model is represented in XML, it provides native
support for encoding information using the Unicode character set and
its more compact representations including UTF-8. Conformant XML
processors recognize both UTF-8 and UTF-16. Though XML includes
provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support
incompatibility exists.
10. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
9.1 URN Sub-Namespace Registration 10.1 URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in [4] This section registers a new XML namespace, per the guidelines in [4]
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:data-model. urn:ietf:params:xml:ns:pidf:data-model.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: XML:
skipping to change at page 30, line 23 skipping to change at page 31, line 7
<title>Presence Data Model Namespace</title> <title>Presence Data Model Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Presence Data Model</h1> <h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2> <h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.2 XML Schema Registrations 10.2 XML Schema Registrations
This section registers two XML schemas per the procedures in [4]. This section registers two XML schemas per the procedures in [4].
9.2.1 Data Model 10.2.1 Data Model
URI: urn:ietf:params:xml:schema:pidf:data-model. URI: urn:ietf:params:xml:schema:pidf:data-model.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5.1.2. Section 5.1.2.
9.2.2 Common Schema 10.2.2 Common Schema
URI: urn:ietf:params:xml:schema:pidf:common-schema. URI: urn:ietf:params:xml:schema:pidf:common-schema.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5.1.1. Section 5.1.1.
10. Acknowledgements 11. Acknowledgements
This document is really a distillation of many ideas discussed over a This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different long period of time. These ideas were contributed by many different
participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat, participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat,
Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam
Roach, Hisham Khartabil, and Jon Peterson contributed many of the Roach, Hisham Khartabil, and Jon Peterson contributed many of the
concepts that are described here. Example presence documents came concepts that are described here. Example presence documents came
from Robert Sparks' example presence documents specification, and from Robert Sparks' example presence documents specification, and
ideas on defining services through characteristics, rather than ideas on defining services through characteristics, rather than
enumeration, come from Adam Roach's service features draft. A enumeration, come from Adam Roach's service features draft. A
special thanks to Steve Donovan for discussions on the topics special thanks to Steve Donovan for discussions on the topics
discussed here. discussed here, and to Elwyn Davies for his final review of the
document.
11. References
11.1 Normative References 12. References
12.1 Normative References
[1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and [1] 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.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
11.2 Informative References [5] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 12.2 Informative References
[6] 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.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[7] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, [8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004. August 2004.
[8] Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme [9] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs)
for the Extensible Messaging and Presence Protocol (XMPP)", and Uniform Resource Identifiers (URIs) for the Extensible
draft-saintandre-xmpp-uri-08 (work in progress), December 2004. Messaging and Presence Protocol (XMPP)",
draft-saintandre-xmpp-iri-02 (work in progress),
September 2005.
[9] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message [10] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message
Service", draft-wilde-sms-uri-10 (work in progress), Service", draft-wilde-sms-uri-10 (work in progress),
August 2005. August 2005.
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[11] Klyne, G., "A Syntax for Describing Media Feature Sets", [12] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999. RFC 2533, March 1999.
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating [13] 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.
[13] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource [14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004. Application (ENUM)", RFC 3761, April 2004.
[14] Stastny, R., "The ENUM Dip Indicator parameter for the "tel"
URI", draft-ietf-iptel-tel-enumdi-01 (work in progress),
April 2005.
[15] Rosenberg, J., "The Session Initiation Protocol (SIP) and [15] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-01 (work in progress), Spam", draft-ietf-sipping-spam-01 (work in progress),
July 2005. July 2005.
[16] Leach, P., Mealling, M., and R. Salz, "A Universally Unique [16] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005. IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[17] Rosenberg, J., "A Presence Event Package for the Session [17] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
skipping to change at page 33, line 5 skipping to change at page 33, line 39
[20] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to [20] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to
Presence Information Data Format (PIDF)", Presence Information Data Format (PIDF)",
draft-ietf-simple-prescaps-ext-04 (work in progress), draft-ietf-simple-prescaps-ext-04 (work in progress),
June 2005. June 2005.
[21] Peterson, J., "A Presence-based GEOPRIV Location Object [21] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004. September 2004.
[22] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-03 (work in progress),
July 2005.
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
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
skipping to change at page 34, line 41 skipping to change at page 35, 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. 71 change blocks. 
232 lines changed or deleted 287 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/