< draft-ietf-simple-presence-rules-09.txt   draft-ietf-simple-presence-rules-10.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco
Expires: August 31, 2007 February 27, 2007 Intended status: Standards Track July 9, 2007
Expires: January 10, 2008
Presence Authorization Rules Presence Authorization Rules
draft-ietf-simple-presence-rules-09 draft-ietf-simple-presence-rules-10
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 34
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 August 31, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Authorization is a key function in presence systems. Authorization Authorization is a key function in presence systems. Authorization
policies, also known as authorization rules, specify what presence policies, also known as authorization rules, specify what presence
information can be given to which watchers, and when. This information can be given to which watchers, and when. This
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1.1. Acceptable Forms of Authentication . . . . . . . . 5 3.1.1.1. Acceptable Forms of Authentication . . . . . . . . 5
3.1.1.2. Computing a URI for the Watcher . . . . . . . . . 6 3.1.1.2. Computing a URI for the Watcher . . . . . . . . . 6
3.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Subscription Handling . . . . . . . . . . . . . . . . 8 3.2.1. Subscription Handling . . . . . . . . . . . . . . . . 8
3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 10 3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Providing Access to Data Component Elements . . . . . 10 3.3.1. Providing Access to Data Component Elements . . . . . 10
3.3.1.1. Device Information . . . . . . . . . . . . . . . . 10 3.3.1.1. Device Information . . . . . . . . . . . . . . . . 10
3.3.1.2. Person Information . . . . . . . . . . . . . . . . 11 3.3.1.2. Person Information . . . . . . . . . . . . . . . . 12
3.3.1.3. Service Information . . . . . . . . . . . . . . . 12 3.3.1.3. Service Information . . . . . . . . . . . . . . . 12
3.3.2. Providing Access to Presence Attributes . . . . . . . 13 3.3.2. Providing Access to Presence Attributes . . . . . . . 13
3.3.2.1. Provide Activities . . . . . . . . . . . . . . . . 13 3.3.2.1. Provide Activities . . . . . . . . . . . . . . . . 13
3.3.2.2. Provide Class . . . . . . . . . . . . . . . . . . 13 3.3.2.2. Provide Class . . . . . . . . . . . . . . . . . . 14
3.3.2.3. Provide DeviceID . . . . . . . . . . . . . . . . . 14 3.3.2.3. Provide DeviceID . . . . . . . . . . . . . . . . . 14
3.3.2.4. Provide Mood . . . . . . . . . . . . . . . . . . . 14 3.3.2.4. Provide Mood . . . . . . . . . . . . . . . . . . . 14
3.3.2.5. Provide Place-is . . . . . . . . . . . . . . . . . 14 3.3.2.5. Provide Place-is . . . . . . . . . . . . . . . . . 14
3.3.2.6. Provide Place-type . . . . . . . . . . . . . . . . 14 3.3.2.6. Provide Place-type . . . . . . . . . . . . . . . . 14
3.3.2.7. Provide Privacy . . . . . . . . . . . . . . . . . 14 3.3.2.7. Provide Privacy . . . . . . . . . . . . . . . . . 15
3.3.2.8. Provide Relationship . . . . . . . . . . . . . . . 15 3.3.2.8. Provide Relationship . . . . . . . . . . . . . . . 15
3.3.2.9. Provide Sphere . . . . . . . . . . . . . . . . . . 15 3.3.2.9. Provide Sphere . . . . . . . . . . . . . . . . . . 15
3.3.2.10. Provide Status-Icon . . . . . . . . . . . . . . . 15 3.3.2.10. Provide Status-Icon . . . . . . . . . . . . . . . 15
3.3.2.11. Provide Time-Offset . . . . . . . . . . . . . . . 15 3.3.2.11. Provide Time-Offset . . . . . . . . . . . . . . . 15
3.3.2.12. Provide User-Input . . . . . . . . . . . . . . . . 15 3.3.2.12. Provide User-Input . . . . . . . . . . . . . . . . 15
3.3.2.13. Provide Note . . . . . . . . . . . . . . . . . . . 16 3.3.2.13. Provide Note . . . . . . . . . . . . . . . . . . . 16
3.3.2.14. Provide Unknown Attribute . . . . . . . . . . . . 16 3.3.2.14. Provide Unknown Attribute . . . . . . . . . . . . 16
3.3.2.15. Provide All Attributes . . . . . . . . . . . . . . 17 3.3.2.15. Provide All Attributes . . . . . . . . . . . . . . 17
4. When to Apply the Authorization Policies . . . . . . . . . . . 17 4. When to Apply the Authorization Policies . . . . . . . . . . . 18
5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 18 5. Implementation Requirements . . . . . . . . . . . . . . . . . 18
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Example Document . . . . . . . . . . . . . . . . . . . . . . . 19
7. Schema Extensibility . . . . . . . . . . . . . . . . . . . . . 22 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Schema Extensibility . . . . . . . . . . . . . . . . . . . . . 23
8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 23 9. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Application Unique ID . . . . . . . . . . . . . . . . . . 24
8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 23 9.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 23 9.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 24
8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 23 9.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 24
8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 23 9.5. Validation Constraints . . . . . . . . . . . . . . . . . . 24
8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 23 9.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 24
8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 23 9.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 24
8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 24 9.8. Resource Interdependencies . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9.9. Authorization Policies . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.3. XML Schema Registrations . . . . . . . . . . . . . . . . . 26 11.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.3. XML Schema Registrations . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29 13.2. Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) for Instant Messaging and The Session Initiation Protocol (SIP) for Instant Messaging and
Presence (SIMPLE) specifications allow a user, called a watcher, to Presence (SIMPLE) specifications allow a user, called a watcher, to
subscribe to another user, called a presentity [17], in order to subscribe to another user, called a presentity [17], in order to
learn their presence information [18]. This subscription is handled learn their presence information [18]. This subscription is handled
by a presence agent. However, presence information is sensitive, and by a presence agent. However, presence information is sensitive, and
a presence agent needs authorization from the presentity prior to a presence agent needs authorization from the presentity prior to
handing out presence information. As such, a presence authorization handing out presence information. As such, a presence authorization
document format is needed. This specification defines a format for document format is needed. This specification defines a format for
such a document, called a presence authorization document. such a document, called a presence authorization document.
[9] specifies a framework for representing authorization policies, [8] specifies a framework for representing authorization policies,
and is applicable to systems such as geo-location and presence. This and is applicable to systems such as geo-location and presence. This
framework is used as the basis for presence authorization documents. framework is used as the basis for presence authorization documents.
In the framework, an authorization policy is a set of rules. Each In the framework, an authorization policy is a set of rules. Each
rule contains conditions, actions, and transformations. The rule contains conditions, actions, and transformations. The
conditions specify under what conditions the rule is to be applied to conditions specify under what conditions the rule is to be applied to
presence server processing. The actions element tells the server presence server processing. The actions element tells the server
what actions to take. The transformations element indicates how the what actions to take. The transformations element indicates how the
presence data is to be manipulated before being presented to that presence data is to be manipulated before being presented to that
watcher, and as such, defines a privacy filtering operation. [9] watcher, and as such, defines a privacy filtering operation. [8]
identifies a small number of specific conditions common to presence identifies a small number of specific conditions common to presence
and location services, and leaves it to other specifications, such as and location services, and leaves it to other specifications, such as
this one, to fill in usage specific details. this one, to fill in usage specific details.
A presence authorization document can be manipulated by clients using A presence authorization document can be manipulated by clients using
several means. One such mechanism is the XML Configuration Access several means. One such mechanism is the XML Configuration Access
Protocol (XCAP) [2]. This specification defines the details Protocol (XCAP) [2]. This specification defines the details
necessary for using XCAP to manage presence authorization documents. necessary for using XCAP to manage presence authorization documents.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Structure of Presence Authorization Documents 3. Structure of Presence Authorization Documents
A presence authorization document is an XML document, formatted A presence authorization document is an XML document, formatted
according to the schema defined in [9]. Presence authorization according to the schema defined in [8]. Presence authorization
documents inherit the MIME type of common policy documents, documents inherit the MIME type of common policy documents,
application/auth-policy+xml. As described in [9], this document is application/auth-policy+xml. As described in [8], this document is
composed of rules which contain three parts - conditions, actions, composed of rules which contain three parts - conditions, actions,
and transformations. Each action or transformation, which is also and transformations. Each action or transformation, which is also
called a permission, has the property of being a positive grant of called a permission, has the property of being a positive grant of
information to the watcher. As a result, there is a well-defined information to the watcher. As a result, there is a well-defined
mechanism for combining actions and transformations obtained from mechanism for combining actions and transformations obtained from
several sources. This mechanism is privacy safe, since the lack of several sources. This mechanism is privacy safe, since the lack of
any action or transformation can only result in less information any action or transformation can only result in less information
being presented to a watcher. being presented to a watcher.
This section defines the new conditions, actions and transformations This section defines the new conditions, actions and transformations
defined by this specification. defined by this specification.
3.1. Conditions 3.1. Conditions
3.1.1. Identity 3.1.1. Identity
Although the <identity> element is defined in [9], that specification Although the <identity> element is defined in [8], that specification
indicates that the specific usages of the framework document need to indicates that the specific usages of the framework document need to
define details that are protocol and usage specific. In particular, define details that are protocol and usage specific. In particular,
it is necessary for a usage of the common policy framework to: it is necessary for a usage of the common policy framework to:
o Define acceptable means of authentication. o Define acceptable means of authentication.
o Define the procedure for representing the identity of the WR o Define the procedure for representing the identity of the WR
(Watcher/Requestor) as a URI or IRI [15]. (Watcher/Requestor) as a URI or IRI [13].
This sub-section defines those details for systems based on [18]. This sub-section defines those details for systems based on [18]. It
does so in general terms, so that the recommendations defined here
apply to existing and future authentication mechanisms in SIP.
3.1.1.1. Acceptable Forms of Authentication 3.1.1.1. Acceptable Forms of Authentication
When used with SIP, a request is considered authenticated if one of When used with SIP, a request is considered authenticated if one of
the following techniques is used: the following are true:
SIP Digest: The presence agent has authenticated the watcher using The watcher proves its identity to the server through a form of
SIP [5] digest authentication [4]. However, if the anonymous cryptograhic authentication, including authentication based on a
authentication described on page 194 of RFC 3261 [5] was used, the shared secret or a certificate, and that authentication yields an
watcher is not considered authenticated. identity for the watcher.
Asserted Identity: If a request contains a P-Asserted-ID header The request comes from a sender that is asserting the identity of
field [7] and the request is coming from a trusted element, the the watcher, and:
watcher is considered authenticated.
Cryptographically Verified Identity: If a request contains an 1. the assertion includes a claim that the asserting party used a
Identity header field as defined in [11], and it validates the form of cryptographic authentication (as defined above) to
From header field of the request, the request is considered to be determine the identity of the watcher, and
authenticated. Note that this is true even if the request
contained a From header field of the form
sip:anonymous@example.com. As long as the signature verifies that
the request legitimately came from this identity, it is considered
authenticated.
An anonymous From header field with RFC 4474 [11] is considered 2. the server trusts that assertion, and
authenticated, while anonymous digest is not considered 3. the assertion provides an identity in the form of a URI.
authenticated, because the former still involves the usage of an
actual username and credential as part of an authentication operation Based on this definition, examples of valid authentication techniques
in the originating domain. include SIP [5] digest authentication [4], cryptographically verified
identity assertions (RFC 4474 [15]), and identity assertions made in
closed network environments (RFC 3325 [16]).
However, the anonymous authentication described on page 194 of RFC
3261 [5] is not considered a valid mechanism for authentication
because it does not produce an identity for the watcher. However, an
anonymous From header field, when used in conjunction with RFC 4474
[15], is considered an acceptable mechanism for authentication, since
it still implies that the asserting node performed authentication
that produced the identity of the watcher.
3.1.1.2. Computing a URI for the Watcher 3.1.1.2. Computing a URI for the Watcher
For requests that are authenticated using SIP Digest, the identity of Computing the URI for the watcher depends on whether the identity is
the watcher is set equal to the address of record (AoR) for the user being ascertained through authentication or through an asserted
that has authenticated themselves. The AoR is always a URI, and can identity.
be either a SIP URI or tel URI [14]. For example, consider the
following "user record" in a database: If an identity assertion is being utilized, the asserted identity
itself (which is in the form of a URI for acceptable forms of
identity assertion), is utilized as the URI. If the identity
assertion mechanism asserts multiple URI for the watcher, then each
of them is used for the comparisons outlined in [8], and if any of
them match a <one> or <except> element, it is considered a match.
If an identity is being determined directly by a cryptographic
authentication, that authentication must produce a URI, or must
produce some form of identifier which can be linked, through
provisioning, to a URI that is bound to that identifier.
For example, in the case of SIP Digest authentication, the
authentication process produces a username scoped within a realm.
That username and realm are bound to an AOR through provisioning, and
the resulting AOR is used as the watcher URI. Consider the following
"user record" in a database:
SIP AOR: sip:alice@example.com SIP AOR: sip:alice@example.com
digest username: ali digest username: ali
digest password: f779ajvvh8a6s6 digest password: f779ajvvh8a6s6
digest realm: example.com digest realm: example.com
If the presence server receives a SUBSCRIBE request, challenges it If the presence server receives a SUBSCRIBE request, challenges it
with the realm set to "example.com", and the subsequent SUBSCRIBE with the realm set to "example.com", and the subsequent SUBSCRIBE
contains an Authorization header field with a username of "ali" and a contains an Authorization header field with a username of "ali" and a
digest response generated with the password "f779ajvvh8a6s6", the digest response generated with the password "f779ajvvh8a6s6", the
identity used in matching operations is "sip:alice@example.com". identity used in matching operations is "sip:alice@example.com".
For requests that are authenticated using RFC 3325 [7], the identity
of the watcher is equal to the URI in the P-Asserted-ID header field.
If there are multiple values for the P-Asserted-ID header field
(there can be one sip URI and one tel URI [14]), then each of them is
used for the comparisons outlined in [9], and if either of them match
a <one> or <except> element, it is considered a match.
For requests that are authenticated using the SIP Identity mechanism
[11], identity of the WR is equal to the SIP URI in the From header
field of the request, assuming that the signature in the Identity
header field has been validated.
In SIP systems, it is possible for a user to have aliases - that is, In SIP systems, it is possible for a user to have aliases - that is,
there are multiple SIP AoRs "assigned" to a single user. In terms of there are multiple SIP AoRs "assigned" to a single user. In terms of
this specification, there is no relationship between those aliases. this specification, there is no relationship between those aliases.
Each would look like a different user. This will be the consequence Each would look like a different user. This will be the consequence
for systems where the watcher is in a different domain than the for systems where the watcher is in a different domain than the
presentity. However, even if the watcher and presentity are in the presentity. However, even if the watcher and presentity are in the
same domain, and the presence server knows that there are aliases for same domain, and the presence server knows that there are aliases for
the watcher, these aliases are not mapped to each other or used in the watcher, these aliases are not mapped to each other or used in
any way. any way.
SIP also allows for anonymous requests. If a request is anonymous SIP also allows for anonymous requests. If a request is anonymous
because the digest challenge/response used the "anonymous" username, because the watcher utilized an authentication mechanism that does
the request is considered unauthenticated and will match only an not provide an identity to the presence server (such as the SIP
empty <identity> element. If a request is anonymous because it digest "anonymous" username), the request is considered
contains a Privacy header field [16], but still contains a unauthenticated (as discussed above) and will match only an empty
P-Asserted-ID header field, the identity in the P-Asserted-ID header <identity> element. If a request is anonymous because it contains a
field is still used in the authorization computations; the fact that Privacy header field [14], but still contains an asserted identity
the request was anonymous has no impact on the identity processing. meeting the criteria defined above, that identity is utilized, and
However, if the request had traversed a trust boundary and the the fact that the request was anonymous has no impact on the identity
P-Asserted-ID header field and the Privacy header field had been processing.
removed, the request will be considered unauthenticated when it
arrives at the presence server. Finally, if a request contained an
Identity header field that was validated, and the From header field
contained a URI of the form sip:anonymous@example.com, then the
watcher is considered authenticated, and it will have an identity
equal to sip:anonymous@example.com. Had such an identity been placed
into a <one> or <except> element, there will be a match.
It is important to note that SIP frequently uses both SIP URI and tel It is important to note that SIP frequently uses both SIP URI and tel
URI [14] as identifiers, and to make matters more confusing, a SIP URI [12] as identifiers, and to make matters more confusing, a SIP
URI can contain a phone number in its user part, in the same format URI can contain a phone number in its user part, in the same format
used in a tel URI. A WR identity that is a SIP URI with a phone used in a tel URI. A WR identity that is a SIP URI with a phone
number will NOT match the <one> and <except> conditions whose 'id' is number will NOT match the <one> and <except> conditions whose 'id' is
a tel URI with the same number. The same is true in the reverse. If a tel URI with the same number. The same is true in the reverse. If
the WR identity is a tel URI, this will not match a SIP URI in the the WR identity is a tel URI, this will not match a SIP URI in the
<one> or <except> conditions whose user part is a phone number. URIs <one> or <except> conditions whose user part is a phone number. URIs
of different schemes are never equivalent. of different schemes are never equivalent.
3.1.2. Sphere 3.1.2. Sphere
The <sphere> element is defined in [9]. However, each application The <sphere> element is defined in [8]. However, each application
making use of the common policy specification needs to determine how making use of the common policy specification needs to determine how
the presence server computes the value of the sphere to be used in the presence server computes the value of the sphere to be used in
the evaluation of the condition. the evaluation of the condition.
To compute the value of <sphere>, the presence agent examines all To compute the value of <sphere>, the presence agent examines all
published presence documents for the presentity. If at least one of published presence documents for the presentity. If at least one of
them includes the <sphere> element [10] as part of the person data them includes the <sphere> element [9] as part of the person data
component [12], and all of those containing the element have the same component [10], and all of those containing the element have the same
value for it, that is the value used for the sphere in presence value for it, that is the value used for the sphere in presence
policy processing. If, however, the <sphere> element was not present policy processing. If, however, the <sphere> element was not present
in any of the published documents, or it was present but had in any of the published documents, or it was present but had
inconsistent values, its value is considered undefined in terms of inconsistent values, its value is considered undefined in terms of
presence policy processing. presence policy processing.
Care must be taken in using <sphere> as a condition for determining Care must be taken in using <sphere> as a condition for determining
the subscription handling. Since the value of <sphere> changes the subscription handling. Since the value of <sphere> changes
dynamically, a state change can cause a subscription to be suddenly dynamically, a state change can cause a subscription to be suddenly
terminated. The watcher has no way to know, aside from polling, when terminated. The watcher has no way to know, aside from polling, when
skipping to change at page 8, line 19 skipping to change at page 8, line 25
3.2. Actions 3.2. Actions
3.2.1. Subscription Handling 3.2.1. Subscription Handling
The <sub-handling> element specifies the subscription authorization The <sub-handling> element specifies the subscription authorization
decision that the server should make. It also specifies whether or decision that the server should make. It also specifies whether or
not the presence document for the watcher should be constructed using not the presence document for the watcher should be constructed using
"polite blocking" or not. Usage of polite blocking and the "polite blocking" or not. Usage of polite blocking and the
subscription authorization decision are specified jointly since subscription authorization decision are specified jointly since
proper privacy handling requires a correlation between them. As proper privacy handling requires a correlation between them. As
discussed in [9], since the combination algorithm runs independently discussed in [8], since the combination algorithm runs independently
for each permission, if correlations exist between permissions, they for each permission, if correlations exist between permissions, they
must be merged into a single variable. That is what is done here. must be merged into a single variable. That is what is done here.
The <sub-handling> element is an enumerated Integer type. The The <sub-handling> element is an enumerated Integer type. The
defined values are: defined values are:
block: This action tells the server to reject the subscription, block: This action tells the server to reject the subscription,
placing it in the terminated state. It has the value of zero, and placing it in the terminated state. It has the value of zero, and
it represents the default value. No value of the sub-handling it represents the default value. No value of the sub-handling
element can ever be lower than this. Strictly speaking, it is not element can ever be lower than this. Strictly speaking, it is not
necessary for a rule to include an explicit block action, since necessary for a rule to include an explicit block action, since
skipping to change at page 8, line 51 skipping to change at page 9, line 12
include only a single service whose basic status is set to closed include only a single service whose basic status is set to closed
[3]. This action has a value of twenty. [3]. This action has a value of twenty.
allow: This action tells the server to place the subscription into allow: This action tells the server to place the subscription into
the "active" state. This action has a value of thirty. the "active" state. This action has a value of thirty.
NOTE WELL: Placing a value of block for this element does not NOTE WELL: Placing a value of block for this element does not
guarantee that a subscription is denied! If any matching rule has guarantee that a subscription is denied! If any matching rule has
any other value for this element, the subscription will receive any other value for this element, the subscription will receive
treatment based on the maximum of those other values. This is treatment based on the maximum of those other values. This is
based on the combining rules defined in [9]. based on the combining rules defined in [8].
Future specifications that wish to define new types of actions MUST Future specifications that wish to define new types of actions MUST
define an entirely new action (separate from <sub-handling>), and define an entirely new action (separate from <sub-handling>), and
define their own set of values for that action. A document could define their own set of values for that action. A document could
contain both <sub-handling> and a subscription handling action contain both <sub-handling> and a subscription handling action
defined by a future specification; in that case, since each action is defined by a future specification; in that case, since each action is
always a positive grant of information, the resulting action is the always a positive grant of information, the resulting action is the
least restrictive one across both elements. least restrictive one across both elements.
The exact behavior of a presence server upon a change in the sub- The exact behavior of a presence server upon a change in the sub-
handling value can be described by utilizing the subscription handling value can be described by utilizing the subscription
processing state machine in Figure 1 of RFC 3857 [6]. processing state machine in Figure 1 of RFC 3857 [6].
If the sub-handling permission changes value to "block", this causes If the sub-handling permission changes value to "block", this causes
a "rejected" event to be generated into the subscription state a "rejected" event to be generated into the subscription state
machine for all affected subscriptions. This will cause the state machine for all affected subscriptions. This will cause the state
machine to move into the terminated state, resulting in the machine to move into the terminated state, resulting in the
transmission of a NOTIFY to the watcher with a Subscription-State transmission of a NOTIFY to the watcher with a Subscription-State
header field with value "terminated" and a reason of "rejected" [8], header field with value "terminated" and a reason of "rejected" [7],
which terminates their subscription. If a new subscription arrives which terminates their subscription. If a new subscription arrives
later on, and the value of sub-handling that applies to that later on, and the value of sub-handling that applies to that
subscription is "block", the subscription processing follows the subscription is "block", the subscription processing follows the
"subscribe, policy=reject" branch from the init state, and a 403 "subscribe, policy=reject" branch from the init state, and a 403
response to the SUBSCRIBE is generated. response to the SUBSCRIBE is generated.
If the sub-handling permission changes value to confirm, the If the sub-handling permission changes value to confirm, the
processing depends on the states of the affected subscriptions. processing depends on the states of the affected subscriptions.
Unfortunately, the state machine in RFC 3857 does not define an event Unfortunately, the state machine in RFC 3857 does not define an event
corresponding to an authorization decision of "pending". If the corresponding to an authorization decision of "pending". If the
subscription is in the active state, it moves back into the pending subscription is in the active state, it moves back into the pending
state. This causes a NOTIFY to be sent, updating the Subscription- state. This causes a NOTIFY to be sent, updating the Subscription-
State [8] to "pending". No reason is included in the Subscription- State [7] to "pending". No reason is included in the Subscription-
State header field (none are defined to handle this case). No State header field (none are defined to handle this case). No
further documents are sent to this watcher. There is no change in further documents are sent to this watcher. There is no change in
state if the subscription is in the pending, waiting or terminated state if the subscription is in the pending, waiting or terminated
states. If a new subscription arrives later on, and the value of states. If a new subscription arrives later on, and the value of
sub-handling that apples to that subscription is "confirm", the sub-handling that apples to that subscription is "confirm", the
subscription processing follows the "subscribe, no policy" branch subscription processing follows the "subscribe, no policy" branch
from the init state, and a 202 response to the SUBSCRIBE is from the init state, and a 202 response to the SUBSCRIBE is
generated, followed by a NOTIFY with Subscription-State of pending. generated, followed by a NOTIFY with Subscription-State of pending.
No presence document is included in that NOTIFY. No presence document is included in that NOTIFY.
If the sub-handling permission changes value from "blocked" or If the sub-handling permission changes value from "blocked" or
"confirm" to "polite-block" or "allow", this causes an "approved" "confirm" to "polite-block" or "allow", this causes an "approved"
event to be generated into the state machine for all affected event to be generated into the state machine for all affected
subscriptions. If the subscription was in the pending state, the subscriptions. If the subscription was in the pending state, the
state machine will move to the active state, resulting in the state machine will move to the active state, resulting in the
transmission of a NOTIFY with a Subscription-State header field of transmission of a NOTIFY with a Subscription-State header field of
"active", and the inclusion of a presence document in that NOTIFY. "active", and the inclusion of a presence document in that NOTIFY.
If the subscription was in the waiting state, it will move into the If the subscription was in the waiting state, it will move into the
terminated state. If a new subscription arrives later on, and the terminated state. If a new subscription arrives later on, and the
value of sub-handling that applies to that subscription is "polite- value of sub-handling that applies to that subscription is "polite-
block" or "allow", the subscription processing follows the block" or "allow", the subscription processing follows the
"subscribe, policy=accept" branch from the init state, and a 200 OK "subscribe, policy=accept" branch from the init state, and a 200 OK
response to the SUBSCRIBE is generated, followed by a NOTIFY with response to the SUBSCRIBE is generated, followed by a NOTIFY with
Subscription-State of "active" with a presence document in the body Subscription-State of "active" with a presence document in the body
of the NOTIFY. of the NOTIFY.
3.3. Transformations 3.3. Transformations
skipping to change at page 10, line 40 skipping to change at page 10, line 49
3.3.1.1. Device Information 3.3.1.1. Device Information
The <provide-devices> permission allows a watcher to see <device> The <provide-devices> permission allows a watcher to see <device>
information present in the presence document. It is a set variable. information present in the presence document. It is a set variable.
Each member of the set provides a way to identify a device or group Each member of the set provides a way to identify a device or group
of devices. This specification defines three types of elements in of devices. This specification defines three types of elements in
the set - <class>, which identifies a device occurrence by class, the set - <class>, which identifies a device occurrence by class,
<deviceID>, which identifies a device occurrence by device ID, and <deviceID>, which identifies a device occurrence by device ID, and
<occurrence-id>, which identifies a device occurrence by occurrence <occurrence-id>, which identifies a device occurrence by occurrence
ID. The device ID and occurrence ID are defined in [12]. Each ID. The device ID and occurrence ID are defined in [10]. Each
member of the set is identified by its type (class, deviceID or member of the set is identified by its type (class, deviceID or
occurrence-id) and value (value of the class, value of the deviceID, occurrence-id) and value (value of the class, value of the deviceID,
or value of the occurrence-id). or value of the occurrence-id).
For example, consider the following <provide-devices> element: For example, consider the following <provide-devices> element:
<provide-devices> <provide-devices>
<deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID> <deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID>
<class>biz</class> <class>biz</class>
</provide-devices> </provide-devices>
skipping to change at page 13, line 24 skipping to change at page 13, line 33
3.3.2. Providing Access to Presence Attributes 3.3.2. Providing Access to Presence Attributes
The permissions of Section 3.3.1 provide coarse grained access to The permissions of Section 3.3.1 provide coarse grained access to
presence data by allowing or blocking specific services or devices, presence data by allowing or blocking specific services or devices,
and allowing or blocking person information. and allowing or blocking person information.
Once person, device or service information is included in the Once person, device or service information is included in the
document, the permissions in this section define which presence document, the permissions in this section define which presence
attributes are reported there. Certain information is always attributes are reported there. Certain information is always
reported. In particular, the <contact>, <service-class> [10], reported. In particular, the <contact>, <service-class> [9], <basic>
<basic> status and <timestamp> elements in all <tuple> elements, if status and <timestamp> elements in all <tuple> elements, if present,
present, are provided to watchers . The <timestamp> element in all are provided to watchers . The <timestamp> element in all <person>
<person> elements, if present, is provided to watchers. The elements, if present, is provided to watchers. The <timestamp> and
<timestamp> and <deviceID> elements in all <device> elements, if <deviceID> elements in all <device> elements, if present, is provided
present, is provided to all watchers. to all watchers.
3.3.2.1. Provide Activities 3.3.2.1. Provide Activities
This permission controls access to the <activities> element defined This permission controls access to the <activities> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-activities>, and it is a boolean type. If its value is <provide-activities>, and it is a Boolean type. If its value is
TRUE, then the <activities> element in the person data element is TRUE, then the <activities> element in the person data element is
reported to the watcher. If FALSE, this presence attribute is reported to the watcher. If FALSE, this presence attribute is
removed if present. removed if present.
3.3.2.2. Provide Class 3.3.2.2. Provide Class
This permission controls access to the <class> element defined in This permission controls access to the <class> element defined in
[10]. The name of the element providing this permission is <provide- [9]. The name of the element providing this permission is <provide-
class>, and it is a boolean type. If its value is TRUE, then any class>, and it is a Boolean type. If its value is TRUE, then any
<class> element in a person, service or device data element is <class> element in a person, service or device data element is
reported to the watcher. If FALSE, this presence attribute is reported to the watcher. If FALSE, this presence attribute is
removed if present. removed if present.
3.3.2.3. Provide DeviceID 3.3.2.3. Provide DeviceID
This permission controls access to the <deviceID> element in a This permission controls access to the <deviceID> element in a
<tuple> element, as defined in [10]. The name of the element <tuple> element, as defined in [9]. The name of the element
providing this permission is <provide-deviceID>, and it is a boolean providing this permission is <provide-deviceID>, and it is a Boolean
type. If its value is TRUE, then the <deviceID> element in the type. If its value is TRUE, then the <deviceID> element in the
service data element is reported to the watcher. If FALSE, this service data element is reported to the watcher. If FALSE, this
presence attribute is removed if present. Note that the <deviceID> presence attribute is removed if present. Note that the <deviceID>
in a device data element is always included, and not controlled by in a device data element is always included, and not controlled by
this permission. this permission.
3.3.2.4. Provide Mood 3.3.2.4. Provide Mood
This permission controls access to the <mood> element defined in This permission controls access to the <mood> element defined in [9].
[10]. The name of the element providing this permission is <provide- The name of the element providing this permission is <provide-mood>,
mood>, and it is a boolean type. If its value is TRUE, then the and it is a Boolean type. If its value is TRUE, then the <mood>
<mood> element in the person data element is reported to the watcher. element in the person data element is reported to the watcher. If
If FALSE, this presence attribute is removed if present. FALSE, this presence attribute is removed if present.
3.3.2.5. Provide Place-is 3.3.2.5. Provide Place-is
This permission controls access to the <place-is> element defined in This permission controls access to the <place-is> element defined in
[10]. The name of the element providing this permission is <provide- [9]. The name of the element providing this permission is <provide-
place-is>, and it is a boolean type. If its value is TRUE, then the place-is>, and it is a Boolean type. If its value is TRUE, then the
<place-is> element in the person data element is reported to the <place-is> element in the person data element is reported to the
watcher. If FALSE, this presence attribute is removed if present. watcher. If FALSE, this presence attribute is removed if present.
3.3.2.6. Provide Place-type 3.3.2.6. Provide Place-type
This permission controls access to the <place-type> element defined This permission controls access to the <place-type> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-place-type>, and it is a boolean type. If its value is <provide-place-type>, and it is a Boolean type. If its value is
TRUE, then the <place-type> element in the person data element is TRUE, then the <place-type> element in the person data element is
reported to the watcher. If FALSE, this presence attribute is reported to the watcher. If FALSE, this presence attribute is
removed if present. removed if present.
3.3.2.7. Provide Privacy 3.3.2.7. Provide Privacy
This permission controls access to the <privacy> element defined in This permission controls access to the <privacy> element defined in
[10]. The name of the element providing this permission is <provide- [9]. The name of the element providing this permission is <provide-
privacy>, and it is a boolean type. If its value is TRUE, then the privacy>, and it is a Boolean type. If its value is TRUE, then the
<privacy> element in the person or service data element is reported <privacy> element in the person or service data element is reported
to the watcher. If FALSE, this presence attribute is removed if to the watcher. If FALSE, this presence attribute is removed if
present. present.
3.3.2.8. Provide Relationship 3.3.2.8. Provide Relationship
This permission controls access to the <relationship> element defined This permission controls access to the <relationship> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-relationship>, and it is a boolean type. If its value is <provide-relationship>, and it is a Boolean type. If its value is
TRUE, then the <relationship> element in the service data element is TRUE, then the <relationship> element in the service data element is
reported to the watcher. If FALSE, this presence attribute is reported to the watcher. If FALSE, this presence attribute is
removed if present. removed if present.
3.3.2.9. Provide Sphere 3.3.2.9. Provide Sphere
This permission controls access to the <sphere> element defined in This permission controls access to the <sphere> element defined in
[10]. The name of the element providing this permission is <provide- [9]. The name of the element providing this permission is <provide-
sphere>, and it is a boolean type. If its value is TRUE, then the sphere>, and it is a Boolean type. If its value is TRUE, then the
<sphere> element in the person data element is reported to the <sphere> element in the person data element is reported to the
watcher. If FALSE, this presence attribute is removed if present. watcher. If FALSE, this presence attribute is removed if present.
3.3.2.10. Provide Status-Icon 3.3.2.10. Provide Status-Icon
This permission controls access to the <status-icon> element defined This permission controls access to the <status-icon> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-status-icon>, and it is a boolean type. If its value is <provide-status-icon>, and it is a Boolean type. If its value is
TRUE, then any <status-icon> element in the person or service data TRUE, then any <status-icon> element in the person or service data
element is reported to the watcher. If FALSE, this presence element is reported to the watcher. If FALSE, this presence
attribute is removed if present. attribute is removed if present.
3.3.2.11. Provide Time-Offset 3.3.2.11. Provide Time-Offset
This permission controls access to the <time-offset> element defined This permission controls access to the <time-offset> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-time-offset>, and it is a boolean type. If its value is <provide-time-offset>, and it is a Boolean type. If its value is
TRUE, then the <time-offset> element in the person data element is TRUE, then the <time-offset> element in the person data element is
reported to the watcher. If FALSE, this presence attribute is reported to the watcher. If FALSE, this presence attribute is
removed if present. removed if present.
3.3.2.12. Provide User-Input 3.3.2.12. Provide User-Input
This permission controls access to the <user-input> element defined This permission controls access to the <user-input> element defined
in [10]. The name of the element providing this permission is in [9]. The name of the element providing this permission is
<provide-user-input>, and it is an enumerated integer type. Its <provide-user-input>, and it is an enumerated integer type. Its
value defines what information is provided to watchers in person, value defines what information is provided to watchers in person,
device or service data elements: device or service data elements:
false: This value indicates that the <user-input> element is removed false: This value indicates that the <user-input> element is removed
from the document. It is assigned the numeric value of 0. from the document. It is assigned the numeric value of 0.
bare: This value indicates that the <user-input> element is to be bare: This value indicates that the <user-input> element is to be
retained. However, any "idle-threshold" and "since" attributes retained. However, any "idle-threshold" and "since" attributes
are to be removed. This value is assigned the numeric value of are to be removed. This value is assigned the numeric value of
skipping to change at page 16, line 21 skipping to change at page 16, line 27
be retained. However, only the "idle-threshold" attribute is to be retained. However, only the "idle-threshold" attribute is to
be retained. This value is assigned to the numeric value of 20. be retained. This value is assigned to the numeric value of 20.
full: This value indicates that the <user-input> element is to be full: This value indicates that the <user-input> element is to be
retained, including any attributes. This value is assigned to the retained, including any attributes. This value is assigned to the
numeric value of 30. numeric value of 30.
3.3.2.13. Provide Note 3.3.2.13. Provide Note
This permission controls access to the <note> element defined in [3] This permission controls access to the <note> element defined in [3]
for <tuple> and [12] for <person> and <device>. The name of the for <tuple> and [10] for <person> and <device>. The name of the
element providing this permission is <provide-note>, and it is a element providing this permission is <provide-note>, and it is a
boolean type. If its value is TRUE, then any <note> elements in the Boolean type. If its value is TRUE, then any <note> elements in the
person, service or device data elements are reported to the watcher. person, service or device data elements are reported to the watcher.
If FALSE, this presence attribute is removed if present. If FALSE, this presence attribute is removed if present.
This permission has no bearing on any <note> values present within This permission has no bearing on any <note> values present within
<activities>, <mood>, <place-is>, <place-type>, <privacy>, <activities>, <mood>, <place-is>, <place-type>, <privacy>,
<relationship> or <service-class> elements. Notes there are <relationship> or <service-class> elements. Notes there are
essentially values for their respective elements, and are present if essentially values for their respective elements, and are present if
the respective element is permitted in the presence document. For the respective element is permitted in the presence document. For
example, if an <activities> element is present in a presence example, if an <activities> element is present in a presence
document, and there is a <note> value for it, that note is present in document, and there is a <note> value for it, that note is present in
skipping to change at page 16, line 47 skipping to change at page 17, line 5
3.3.2.14. Provide Unknown Attribute 3.3.2.14. Provide Unknown Attribute
It is important that systems be allowed to include proprietary or new It is important that systems be allowed to include proprietary or new
presence information, and that users be able to set permissions for presence information, and that users be able to set permissions for
that information, without requiring an upgrade of the presence server that information, without requiring an upgrade of the presence server
and authorization system. For this reason, the <provide-unknown- and authorization system. For this reason, the <provide-unknown-
attribute> permission is defined. This permission indicates that the attribute> permission is defined. This permission indicates that the
unknown presence attribute with the given name and namespace unknown presence attribute with the given name and namespace
(supplied as mandatory attributes of the <provide-unknown-attribute> (supplied as mandatory attributes of the <provide-unknown-attribute>
element) should be included in the document. Its type is boolean. element) should be included in the document. Its type is Boolean.
The value of the name attribute MUST be an unqualified element name The value of the name attribute MUST be an unqualified element name
(meaning that a namespace prefix MUST NOT be included), and the the (meaning that a namespace prefix MUST NOT be included), and the the
value of the ns attribute MUST be a namespace URI. The two are value of the ns attribute MUST be a namespace URI. The two are
combined to form a qualified element name, which will be matched to combined to form a qualified element name, which will be matched to
all unknown child elements of the PIDF <tuple>, <device> or <person> all unknown child elements of the PIDF <tuple>, <device> or <person>
elements with the same qualified name. In this context, "unknown" elements with the same qualified name. In this context, "unknown"
means that the presence server is not aware of any schemas that means that the presence server is not aware of any schemas that
define authorization policies for that element. By definition, this define authorization policies for that element. By definition, this
will exclude the <provide-unknown-attribute> rule from being applied will exclude the <provide-unknown-attribute> rule from being applied
skipping to change at page 17, line 26 skipping to change at page 17, line 33
<provide-unknown-attribute> with a value of TRUE for some attribute, <provide-unknown-attribute> with a value of TRUE for some attribute,
say foo. This attribute was from a namespace and schema unknown to say foo. This attribute was from a namespace and schema unknown to
the server, and so the attribute was provided to watchers. However, the server, and so the attribute was provided to watchers. However,
after upgrade, the server is now aware of a new namespace and schema after upgrade, the server is now aware of a new namespace and schema
for a permission that grants access to the foo attribute. Now, the for a permission that grants access to the foo attribute. Now, the
<provide-unknown-attribute> permission for the foo attribute will be <provide-unknown-attribute> permission for the foo attribute will be
ignored, resulting in a removal of those elements from presence ignored, resulting in a removal of those elements from presence
documents sent to watchers. The system remains privacy safe, but documents sent to watchers. The system remains privacy safe, but
behavior might not be as expected. Developers of systems which allow behavior might not be as expected. Developers of systems which allow
clients to set policies are advised to check the capabilities of the clients to set policies are advised to check the capabilities of the
server, (using the mechanism described in Section 7) before uploading server, (using the mechanism described in Section 8) before uploading
a new authorization document, to make sure that the behavior will be a new authorization document, to make sure that the behavior will be
as expected. as expected.
3.3.2.15. Provide All Attributes 3.3.2.15. Provide All Attributes
This permission grants access to all presence attributes in all of This permission grants access to all presence attributes in all of
the person, device and tuple elements that are present in the the person, device and tuple elements that are present in the
document (the ones present in the document are determined by the document (the ones present in the document are determined by the
<provide-persons>, <provide-devices> and <provide-services> <provide-persons>, <provide-devices> and <provide-services>
permissions). It is effectively a macro that expands into a set of permissions). It is effectively a macro that expands into a set of
skipping to change at page 18, line 9 skipping to change at page 18, line 15
watcher. watcher.
4. When to Apply the Authorization Policies 4. When to Apply the Authorization Policies
This specification does not mandate at what point in the processing This specification does not mandate at what point in the processing
of presence data the privacy filtering aspects of the authorization of presence data the privacy filtering aspects of the authorization
policy are applied. However, they must be applied such that the policy are applied. However, they must be applied such that the
final presence document sent to the watcher is compliant to the final presence document sent to the watcher is compliant to the
privacy policy described in the authorization documents that apply to privacy policy described in the authorization documents that apply to
the user (there can be more than one; the rules for combining them the user (there can be more than one; the rules for combining them
are described in [9]). More concretely, if the presence document are described in [8]). More concretely, if the presence document
sent to a watcher is D, and the privacy filtering operation applied sent to a watcher is D, and the privacy filtering operation applied
do a presence document x is F(x), then D MUST have the property that do a presence document x is F(x), then D MUST have the property that
D = F(D). In other words, further applications of the privacy D = F(D). In other words, further applications of the privacy
filtering operation would not result in any further changes of the filtering operation would not result in any further changes of the
presence document, making further application of the filtering presence document, making further application of the filtering
operation a no-op. A corollary of this is that F(F(D)) = D for all operation a no-op. A corollary of this is that F(F(D)) = D for all
D. D.
The subscription processing aspects of the document get applied by The subscription processing aspects of the document get applied by
the server when it decides to accept or reject the subscription. the server when it decides to accept or reject the subscription.
5. Example Document 5. Implementation Requirements
The rules defined by the document in this specification form a
"contract" of sorts between a client which creates this document, and
the server which executes the policies it contains. Consequently,
presence servers implementing this specification MUST support all of
the conditions, actions, and transformations defined in this
specification. If servers were to implement a subset of these,
clients would need a mechanism to discover which subset is supported.
No such mechanism is defined.
It is RECOMMENDED that clients support all of the actions,
transformations and conditions defiend in this specification. If a
client supports a subset, it is possible that a user might manipulate
their authorization rules from a different client, supporting a
different subset, and store those results on the server. When the
user goes back to the first client and views their presence
authorization rules there, the client may not be able to properly
render or manipulate the document retrieved from the server, since it
may contain conditions, actions or transformations not supported by
the client. The only reason that this normative requirement is not a
MUST is that there are valid conditions in which a user manipulates
their presence authorization rules from a single client, in which
case this problem does not occur.
This specification makes no normative recommendations on the
mechanism used to transport presence authorization documents from
clients to their servers. Although Section 9 defines how to utilize
XCAP, XCAP is not normatively required by this specification.
6. Example Document
The following presence authorization document specifies permissions The following presence authorization document specifies permissions
for the user "user@example.com". The watcher is allowed to access for the user "user@example.com". The watcher is allowed to access
presence information (the 'allow' value for <sub-handling>). They presence information (the 'allow' value for <sub-handling>). They
will be granted access to the presence data of all services whose will be granted access to the presence data of all services whose
contact URI schemes are sip and mailto. Person information is also contact URI schemes are sip and mailto. Person information is also
provided. However, since there is no <provide-devices>, no device provided. However, since there is no <provide-devices>, no device
information will be given to the watcher. Within the service and information will be given to the watcher. Within the service and
person information provided to the watcher, the <activities> element person information provided to the watcher, the <activities> element
will be shown, as will the <user-input> element. However, any "idle- will be shown, as will the <user-input> element. However, any "idle-
skipping to change at page 19, line 35 skipping to change at page 20, line 35
</pr:provide-persons> </pr:provide-persons>
<pr:provide-activities>true</pr:provide-activities> <pr:provide-activities>true</pr:provide-activities>
<pr:provide-user-input>bare</pr:provide-user-input> <pr:provide-user-input>bare</pr:provide-user-input>
<pr:provide-unknown-attribute <pr:provide-unknown-attribute
ns="urn:vendor-specific:foo-namespace" ns="urn:vendor-specific:foo-namespace"
name="foo">true</pr:provide-unknown-attribute> name="foo">true</pr:provide-unknown-attribute>
</cr:transformations> </cr:transformations>
</cr:rule> </cr:rule>
</cr:ruleset> </cr:ruleset>
6. XML Schema 7. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules" <xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules" xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/> <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:simpleType name="booleanPermission"> <xs:simpleType name="booleanPermission">
<xs:restriction base="xs:boolean"/> <xs:restriction base="xs:boolean"/>
skipping to change at page 22, line 21 skipping to change at page 23, line 21
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:element name="provide-unknown-attribute" <xs:element name="provide-unknown-attribute"
type="pr:unknownBooleanPermission"/> type="pr:unknownBooleanPermission"/>
<xs:element name="provide-all-attributes"> <xs:element name="provide-all-attributes">
<xs:complexType/> <xs:complexType/>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
7. Schema Extensibility 8. Schema Extensibility
It is anticipated that future changes to this specification are It is anticipated that future changes to this specification are
accomplished through extensions that define new types of permissions. accomplished through extensions that define new types of permissions.
These extensions MUST exist within a different namespace. These extensions MUST exist within a different namespace.
Furthermore, the schema defined above and the namespace for elements Furthermore, the schema defined above and the namespace for elements
defined within it MUST NOT be altered by future specifications. defined within it MUST NOT be altered by future specifications.
Changes in the basic schema, or in the interpretation of elements Changes in the basic schema, or in the interpretation of elements
within that schema, may result in violations of user privacy due to within that schema, may result in violations of user privacy due to
mis-interpretation of documents. mis-interpretation of documents.
skipping to change at page 22, line 44 skipping to change at page 23, line 44
(typically a SIP user agent, though not necessarily) to know which (typically a SIP user agent, though not necessarily) to know which
permissions are supported by the server. This allows the agent to permissions are supported by the server. This allows the agent to
know how to build a document which results in the desired behavior, know how to build a document which results in the desired behavior,
since unknown permissions would be ignored by the server. To handle since unknown permissions would be ignored by the server. To handle
this, when presence authorization documents are transported using this, when presence authorization documents are transported using
XCAP, the XCAP capabilities document stored at the server SHOULD XCAP, the XCAP capabilities document stored at the server SHOULD
contain the namespaces for the permissions supported by the presence contain the namespaces for the permissions supported by the presence
server. This way, an agent can query for this list prior to server. This way, an agent can query for this list prior to
constructing a document. constructing a document.
8. XCAP Usage 9. XCAP Usage
The following section defines the details necessary for clients to The following section defines the details necessary for clients to
manipulate presence authorization documents from a server using XCAP. manipulate presence authorization documents from a server using XCAP.
8.1. Application Unique ID 9.1. Application Unique ID
XCAP requires application usages to define a unique application usage XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "pres-rules" AUID within the IETF tree, via specification defines the "pres-rules" AUID within the IETF tree, via
the IANA registration in Section 10. the IANA registration in Section 11.
8.2. XML Schema 9.2. XML Schema
XCAP requires application usages to define a schema for their XCAP requires application usages to define a schema for their
documents. The schema for presence authorization documents is in documents. The schema for presence authorization documents is in
Section 6. Section 7.
8.3. Default Namespace 9.3. Default Namespace
XCAP requires application usages to define the default namespace for XCAP requires application usages to define the default namespace for
their documents. The default namespace is their documents. The default namespace is
urn:ietf:params:xml:ns:pres-rules. urn:ietf:params:xml:ns:pres-rules.
8.4. MIME Type 9.4. MIME Type
XCAP requires application usages to defined the MIME type for XCAP requires application usages to defined the MIME type for
documents they carry. Presence authorization documents inherit the documents they carry. Presence authorization documents inherit the
MIME type of common policy documents, application/auth-policy+xml. MIME type of common policy documents, application/auth-policy+xml.
8.5. Validation Constraints 9.5. Validation Constraints
There are no additional constraints defined by this specification. There are no additional constraints defined by this specification.
8.6. Data Semantics 9.6. Data Semantics
Semantics of a presence authorization document are discussed in Semantics of a presence authorization document are discussed in
Section 3. Section 3.
8.7. Naming Conventions 9.7. Naming Conventions
When a presence agent receives a subscription for some user foo When a presence agent receives a subscription for some user foo
within a domain, it will look for all documents within http://[xcap within a domain, it will look for all documents within http://[xcap
root]/pres-rules/users/foo, and use all documents found beneath that root]/pres-rules/users/foo, and use all documents found beneath that
point to guide authorization policy. If only a single document is point to guide authorization policy. If only a single document is
used, it SHOULD be called "index". used, it SHOULD be called "index".
8.8. Resource Interdependencies 9.8. Resource Interdependencies
There are no additional resource interdependencies defined by this There are no additional resource interdependencies defined by this
application usage. application usage.
8.9. Authorization Policies 9.9. Authorization Policies
This application usage does not modify the default XCAP authorization This application usage does not modify the default XCAP authorization
policy, which is that only a user can read, write or modify their own policy, which is that only a user can read, write or modify their own
documents. A server can allow privileged users to modify documents documents. A server can allow privileged users to modify documents
that they don't own, but the establishment and indication of such that they don't own, but the establishment and indication of such
policies is outside the scope of this document. policies is outside the scope of this document.
9. Security Considerations 10. Security Considerations
Presence authorization policies contain very sensitive information. Presence authorization policies contain very sensitive information.
They indicate which other users are "liked" or "disliked" by a user. They indicate which other users are "liked" or "disliked" by a user.
As such, when these documents are transported over a network, they As such, when these documents are transported over a network, they
SHOULD be encrypted. SHOULD be encrypted.
Modification of these documents by an attacker can disrupt the Modification of these documents by an attacker can disrupt the
service seen by a user, often in subtle ways. As a result, when service seen by a user, often in subtle ways. As a result, when
these documents are transported, the transport SHOULD provide these documents are transported, the transport SHOULD provide
authenticity and message integrity. authenticity and message integrity.
In the case where XCAP is used to transfer the document, clients In the case where XCAP is used to transfer the document, both clients
SHOULD use HTTP over TLS, and servers SHOULD define the root services and servers MUST implement HTTP over TLS and HTTP Digest
URI as an https URI. The server SHOULD authenticate the client over authentication. Sites SHOULD authenticate clients using digest
the resulting TLS connection using HTTP digest. authentication over TLS, and sites SHOULD define the root services
URI as an https URI.
Authorization documents themselves exist for the purposes of Authorization documents themselves exist for the purposes of
providing a security function - privacy. The SIP presence providing a security function - privacy. The SIP presence
specifications [18] require the usage of an authorization function specifications [18] require the usage of an authorization function
prior to the granting of presence information, and this specification prior to the granting of presence information, and this specification
meets that need. Presence authorization documents inherit the meets that need. Presence authorization documents inherit the
privacy properties of the common policy format on which they are privacy properties of the common policy format on which they are
based. This format has been designed to be privacy-safe, which means based. This format has been designed to be privacy-safe, which means
that failure of the presence server to obtain or understand an that failure of the presence server to obtain or understand an
authorization document can never reveal more information than is authorization document can never reveal more information than is
skipping to change at page 25, line 5 skipping to change at page 26, line 5
A consequence of this design is that the results of combining several A consequence of this design is that the results of combining several
authorization documents can be non-obvious to end users. For authorization documents can be non-obvious to end users. For
example, if one authorization document grants permission for all example, if one authorization document grants permission for all
users from the example.com domain to see their presence, and another users from the example.com domain to see their presence, and another
document blocks joe@example.com, the combination of these will still document blocks joe@example.com, the combination of these will still
provide presence to joe@example.com. Designers of user interfaces provide presence to joe@example.com. Designers of user interfaces
are encouraged to carefully pay attention to the results of combining are encouraged to carefully pay attention to the results of combining
multiple rules. multiple rules.
10. IANA Considerations Another concern are cases where a user sets their privacy preferences
from one client, uploads their presence authorization document to a
server, and then modifies them from a different client. If the
clients support different subsets of the document format, users may
be confused about what information is being revealed. Clients
retrieving presence authorization documents from a server SHOULD
render, to the users, information about rules that they do not
understand, so that users can be certain what rules are in place.
11. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
10.1. XCAP Application Usage ID 11.1. XCAP Application Usage ID
This section registers an XCAP Application Usage ID (AUID) according This section registers an XCAP Application Usage ID (AUID) according
to the IANA procedures defined in [2]. to the IANA procedures defined in [2].
Name of the AUID: pres-rules Name of the AUID: pres-rules
Description: Presence rules are documents that describe the Description: Presence rules are documents that describe the
permissions that a presentity [17] has granted to users that seek permissions that a presentity [17] has granted to users that seek
to watch their presence. to watch their presence.
10.2. URN Sub-Namespace Registration 11.2. URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in This section registers a new XML namespace, per the guidelines in
[13] [11]
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:pres-rules. urn:ietf:params:xml:ns:pres-rules.
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:
BEGIN BEGIN
skipping to change at page 26, line 5 skipping to change at page 27, line 23
<title>Presence Rules Namespace</title> <title>Presence Rules Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Permission Statements</h1> <h1>Namespace for Permission Statements</h1>
<h2>urn:ietf:params:xml:ns:pres-rules</h2> <h2>urn:ietf:params:xml:ns:pres-rules</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
10.3. XML Schema Registrations 11.3. XML Schema Registrations
This section registers an XML schema per the procedures in [13]. This section registers an XML schema per the procedures in [11].
URI: urn:ietf:params:xml:schema:pres-rules. URI: urn:ietf:params:xml:schema:pres-rules.
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 6. Section 7.
11. Acknowledgements 12. Acknowledgements
The authors would like to thank Richard Barnes, Jari Urpalainen, Jon The authors would like to thank Richard Barnes, Jari Urpalainen, Jon
Peterson, and Martin Hynar for their comments. Peterson, and Martin Hynar for their comments.
12. References 13. References
12.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., "The Extensible Markup Language (XML) [2] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12 (work in progress), October 2006. draft-ietf-simple-xcap-12 (work in progress), October 2006.
[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)",
skipping to change at page 26, line 49 skipping to change at page 28, line 21
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] 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.
[6] Rosenberg, J., "A Watcher Information Event Template-Package [6] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857, for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004. August 2004.
[7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[9] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007. Expressing Privacy Preferences", RFC 4745, February 2007.
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, [9] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information "RPID: Rich Presence Extensions to the Presence Information
Data Format (PIDF)", RFC 4480, July 2006. Data Format (PIDF)", RFC 4480, July 2006.
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated [10] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[12] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006. July 2006.
[13] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[14] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[15] Duerst, M. and M. Suignard, "Internationalized Resource [13] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[16] Peterson, J., "A Privacy Mechanism for the Session Initiation [14] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
12.2. Informative References 13.2. Informative References
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[16] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [17] 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.
[18] Rosenberg, J., "A Presence Event Package for the Session [18] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco
600 Lanidex Plaza Edison, NJ
Parsippany, NJ 07054
US US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 88 change blocks. 
191 lines changed or deleted 235 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/