< draft-ietf-simple-data-req-02.txt   draft-ietf-simple-data-req-03.txt >
Internet Engineering Task Force SIMPLE WG SIMPLE WG J. Rosenberg
Internet Draft J. Rosenberg Internet-Draft Dynamicsoft
dynamicsoft Expires: December 26, 2003 M. Isomaki
M. Isomaki Nokia Research Center
Nokia June 27, 2003
draft-ietf-simple-data-req-02.txt
April 16, 2003
Expires: October 2003
Requirements for Manipulation of Data Elements in Session Requirements for Manipulation of Data Elements in Session Initiation
Initiation Protocol (SIP) for Instant Messaging and Presence Protocol (SIP) for Instant Messaging and Presence Leveraging
Leveraging Extensions (SIMPLE) Systems Extensions (SIMPLE) Systems
draft-ietf-simple-data-req-03
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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://
http://www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see 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 December 26, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
In any presence application, it is frequently necessary for the user In any presence application, it is frequently necessary for the user
to configure a number of pieces of information. Users will need to to configure a number of pieces of information. Users will need to
manipulate their presentity list, adding and removing presentities, manipulate their presentity list, adding and removing presentities,
and manipulate their authorization lists, which specify the set of and manipulate their authorization lists, which specify the set of
users that can subscribe to their presence. In this document, we users that can subscribe to their presence. In this document, we
provide a framework and requirements for such data manipulations. provide a framework and requirements for such data manipulations.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology ......................................... 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Framework ........................................... 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Presentity Collection Manipulation Requirements ..... 6 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Authorization Policy Manipulation ................... 9 5. Resource List Manipulation Requirements . . . . . . . . . . . 6
5.1 Acceptance Policy Requirements ...................... 9 6. Authorization Policy Manipulation . . . . . . . . . . . . . . 8
5.2 Notification Requirements ........................... 10 6.1 Acceptance Policy Requirements . . . . . . . . . . . . . . . . 8
5.3 Content Requirements ................................ 10 6.2 Notification Requirements . . . . . . . . . . . . . . . . . . 9
5.4 General Requirements ................................ 11 6.3 Content Requirements . . . . . . . . . . . . . . . . . . . . . 10
6 Security Considerations ............................. 12 6.4 General Requirements . . . . . . . . . . . . . . . . . . . . . 11
7 To Do ............................................... 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8 Acknowledgements .................................... 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9 Authors Addresses ................................... 13 9. Changes from version 02 . . . . . . . . . . . . . . . . . . . 13
10 Normative References ................................ 13 Informative References . . . . . . . . . . . . . . . . . . . . 13
11 Informative References .............................. 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
1 Introduction 1. Introduction
Consumer-based instant messaging and presence applications typically Consumer-based instant messaging and presence applications typically
provide a rich set of features. In addition to being able to provide a rich set of features. In addition to being able to
subscribe to, and get notified of, changes in presence, users can subscribe to, and get notified of, changes in presence, users can
also configure the operation of the application. also configure the operation of the application.
Most systems allow the user to add or remove users from their "buddy Most systems allow the user to add or remove users from their 'buddy
list", which we refer to here as a presentity collection. The list', which we refer to here as a resource list. The resource list
presentity collection is the set of presentities [1] that a user is is the set of presentities [2] that a user is subscribed to. This
subscribed to. This list is frequently stored on the server, allowing list is frequently stored on the server, allowing the user to
the user to generate a single subscription to the entire list. The generate a single subscription to the entire list. The server then
server then "fans out" that subscription too all the presentities on 'fans out' that subscription to all the presentities on the list.
the list. Subscription to presentity collections is supported through Subscription to resource lists is supported through the SIP event
the SIP event notification extension for collections [2]. However, no notification extension for resource lists [6]. However, no automated
automated means is currently defined to create these lists, add users means is currently defined to create these lists, add users to them,
to them, remove users from them, or query for the set of users on the remove users from them, or query for the set of users on the list.
list.
Similarly, most systems support user-defined authorization policies. Similarly, most systems support user-defined authorization policies.
A user can specify which watchers are (or are not) allowed to A user can specify which watchers are (or are not) allowed to
subscribe to their presence, and furthermore, what aspects of their subscribe to their presence, and furthermore, what aspects of their
presence a watcher is able to see. While SIMPLE [3] systems can presence a watcher is able to see. While SIMPLE [3] systems can
support such authorization policies, besides human-driven techniques, support such authorization policies, besides human-driven techniques,
such as web or voice response, there is no automated way to specify such as web or voice response, there is no automated way to specify
these policies. these policies.
In this document, we propose a framework and a set of requirements In this document, we propose a framework and a set of requirements
for manipulation of presentity collections and authorization for manipulation of resource lists and authorization policies.
policies. Further data manipulation requirements may be defined in the future,
but they are out of the scope of this document.
2 Terminology 2. Conventions
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1]
and indicate requirement levels for compliant implementations.
3. Terminology
This document uses the following terminology: This document uses the following terminology:
Presentity Collection: A presentity collection is a set of Resource list: A resource list is a set of presentities, each of
presentities, each of which is identified by a URI. The which is identified by a URI. The list itself is identified by a
collection itself is identified by a URI (for example, URI (for example, sip:myfriends@example.com). Using the SIP event
sip:myfriends@example.com). Using the SIP event extension extension for resource lists [6], a watcher can subscribe to the
for collections [2], a watcher can subscribe to the resource list and learn about the presence state of all the
presentity collection and learn about the presence state of presentities in the set.
all the presentities in the set.
Presence Authorization Policy: Presence authorization policy Presence Authorization Policy: Presence authorization policy refers
refers to the set of directives given to a presence agent to the set of directives given to a presence agent on what
on what subscriptions to accept, when to generate subscriptions to accept, when to generate notifications for a
notifications for a subscription, and what information subscription, and what information should be placed in those
should be placed in those notifications. notifications.
Acceptance Policy: The component of presence authorization Acceptance Policy: The component of presence authorization policy
policy that determines whether or not to accept a that determines whether or not to accept a subscription from a
subscription from a watcher. watcher.
Notification Policy: The component of presence authorization Notification Policy: The component of presence authorization policy
policy that determines when a notification should be sent that determines when a notification should be sent to a watcher.
to a watcher.
Content Policy: The component of presence authorization that Content Policy: The component of presence authorization that
determines the content of the information provided to a determines the content of the information provided to a watcher in
watcher in a notification. a notification.
SIMPLE Data Elements: SIMPLE data elements are user specified SIMPLE Data Elements: SIMPLE data elements are user specified data
data that determine the behavior of a presence agent. This that determine the behavior of a presence agent. This includes
includes presentity collections and presence authorization resource lists and presence authorization policy.
policy.
Data Manipulation Client: A data manipulation client is a Data Manipulation Client: A data manipulation client is a protocol
protocol agent that reads, writes, and receives agent that reads, writes, and receives notifications of changes in
notifications of changes in SIMPLE data elements. SIMPLE data elements.
Data Manipulation Server: A data manipulation server is a Data Manipulation Server: A data manipulation server is a protocol
protocol agent that receives reads, writes, and sends agent that receives reads, writes, and sends notifications of
notifications of changes in SIMPLE data elements. The changes in SIMPLE data elements. The server is responsible for the
server is responsible for the storage of the SIMPLE data storage of the SIMPLE data elements.
elements.
3 Framework 4. Framework
The framework for the the usage and manipulation of SIMPLE data The framework for the usage and manipulation of SIMPLE data elements
elements is shown in Figure 1. are shown in Figure 1.
SUBSCRIBE |--------|
------------->| |<---| //-----\\
<-------------| PA | | || ||
NOTIFY |--------| |---|\\-----//|
| |
| Storage |
| |
|->|---------|
|--------| |
| |<----|
| Server | Read/Write
|--------|
^ |
| | RL/Auth manipulations
| v
|--------|
| |
| Client |
|--------|
Figure 1: Framework for Data Manipulation
The data manipulation client (just referred to as the client) uses The data manipulation client (just referred to as the client) uses
some protocol, whose requirements are specified here, to interact some protocol, whose requirements are specified here, to interact
with the data manipulation server. Those interactions include with the data manipulation server. Those interactions include
requests to read a SIMPLE data element, write one, or receive requests to read a SIMPLE data element, write one, or receive
notifications in changes to one. The data manipulation server (just notifications in changes to one. The data manipulation server (just
referred to as the server) mananges a persistent store of the SIMPLE referred to as the server) manages a persistent store of the SIMPLE
data elements, and interacts with the client. data elements, and interacts with the client.
When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it
may require access to SIMPLE data elements in order to process the may require access to SIMPLE data elements in order to process the
request. For example, if the subscription is for a presentity request. For example, if the subscription is for a resource list, the
collection, the PA will need to determine that this is the case, and PA will need to determine that this is the case, and secondly,
secondly, "expand" the collection, obtaining the list of URIs for 'expand' the resource list, obtaining the list of URIs for that
that collection. resource list.
SUBSCRIBE +--------+
--------------->| | Read
| PA |<--+ //----\\
<---------------| | | || ||
NOTIFY +--------+ +--- \\----//|
| |
| Storage|
| |
+--------+ | |
| Server |<-----> | |
| | Read/ \ /
| | Write \------/
+--------+
^ |
| |
| | PC/Auth
| | Manipulations
| |
| |
| V
+--------+
| Client |
| |
| |
+--------+
Figure 1: Framework for Data Manipulation
If the SUBSCRIBE request is for a presentity, the PA will need to If the SUBSCRIBE request is for a presentity, the PA will need to
obtain the presence authorization policy of that presentity in order obtain the presence authorization policy of that presentity in order
to process the SUBSCRIBE request. to process the SUBSCRIBE request.
In both cases, the PA requires only read access to the data. As a In both cases, the PA requires only read access to the data. As a
result, it obtains it directly from the data store, rather than result, it obtains it directly from the data store, rather than
interacting with the server. This, of course, is just a model of the interacting with the server. This, of course, is just a model of the
system; a real implementation might involve interaction with the system; a real implementation might involve interaction with the
server before reading the data. server before reading the data.
Between the presentity collection and presence authorization policy, Between the resource list and presence authorization policy, the
the presence authorization policy is a far more complicated piece of presence authorization policy is a far more complicated piece of
data. The authorization policy can be reasonably split into three data. The authorization policy can be reasonably split into three
separate pieces. The first, which we call the acceptance policy, separate pieces. The first, which we call the acceptance policy,
determines whether or not to grant a subscription to the subscriber. determines whether or not to grant a subscription to the subscriber.
This policy results in a binary decision. The second piece, which we This policy results in a binary decision. The second piece, which we
call the notification policy, determines when that particular call the notification policy, determines when that particular
subscriber should receive notifications. For example, a subscriber subscriber should receive notifications. For example, a subscriber
might only be permitted to see when I log in or log out of IM, but might only be permitted to see when I log in or log out of IM, but
not receive notifications when my phone goes on hook. This is closely not receive notifications when my phone goes on hook. This is closely
related to the third piece, which we call the content policy. This related to the third piece, which we call the content policy. This
policy specifies the content of the information present in a policy specifies the content of the information present in a
notification that is sent to a subscriber. notification that is sent to a subscriber.
All of these policies are data that is manipulated by the data All of these policies are data that is manipulated by the data
manipulation protocol. manipulation protocol.
4 Presentity Collection Manipulation Requirements 5. Resource List Manipulation Requirements
The following are the set of requirements for the protocol between The following are the set of requirements for the protocol between
the client and the server for the purposes of manipulation presentity the client and the server for the purposes of manipulation resource
collections. lists. It is obvious that similar requirements would apply to lists
used by other applications than presence as well, but those are
REQ PC-1: It MUST be possible for the client to create a outside the scope of this document.
presentity collection and associate it with a URI.
REQ PC-2: It MUST be possible for the user to specify the URI REQ PC-1: It MUST be possible for the client to create resource
for the presentity collection when one is created. If the lists and associate each of them with a distinct URI.
name cannot be allocated (because it already exists, for
example), it MUST be possible to inform the client of the
failure, and the reason for it.
REQ PC-3: It MUST be possible for the server to provide the REQ PC-2: It MUST be possible for the user to specify the URI for
client a URI for the list when one is created, in the case the resource list when one is created. If the name cannot be
where the client does not provide it. allocated (because it already exists, for example), it MUST be
possible to inform the client of the failure, and the reason for
it.
REQ PC-4: It MUST be possible to add an entry to the presentity REQ PC-3: It MUST be possible for the server to provide the client a
collection. Each entry MUST consist of at least a URI, and URI for the list when one is created, in the case where the client
MAY include a display name. It MUST be possible for the does not provide it.
entry to be any URI that is meaningful in the context of a
presentity collection. Examples would include a SIP URI or
pres URI [4].
REQ PC-5: It MUST be possible for a presentity collection to REQ PC-4: It MUST be possible to associate a display name with a
contain entries which are themselves presentity resource list.
collections. It MUST be possible for the client to
determine whether the entry is a presentity or anoter
presentity collection.
REQ PC-6: It MUST be possible to remove an entry from the REQ PC-5: It MUST be possible to add an entry to the resource list.
presentity collection. If the entry does not exist, it MUST Each entry MUST be able to include at least a URI, and a display
be possible for the server to inform the client of this name. It MUST be possible for the entry to be any URI that is
fact. meaningful in the context of a resource list. Examples would
include a SIP URI or pres URI [7].
REQ PC-7: It MUST be possible to clear all entries from a REQ PC-6: It MUST be possible to extend the set of information
presentity collection. associated with the entries in the resource list and with the list
itself. An example would be a filtering document associated with
the list.
REQ PC-8: It MUST be possible to delete a presentity collection. REQ PC-7: It MUST be possible for a resource list to contain entries
In this context, deleted means that the name of the which are themselves resource lists.
presentity collection is no longer defined, so that
subscriptions to the list would fail.
REQ PC-9: It MUST be possible to query for the set of URIs in a REQ PC-8: It MUST be possible to remove an entry from the resource
particular presentity collection, by providing the URI for list. If the entry does not exist, it MUST be possible for the
the presentity collection. server to inform the client of this fact.
REQ PC-10: It MUST be possible for the presentity collection to REQ PC-9: It MUST be possible to modify an entry in the resource
be associated with a list of authorized users. Those list.
authorized users are the only ones permitted to manipulate
the presentity collection.
REQ PC-11: It MUST be possible for the presentity collection to REQ PC-10: It MUST be possible to clear all entries from a resource
be associated with a list of users that are authorized to list.
subscribe to the list.
REQ PC-12: It MUST be possible for a client to store a cached REQ PC-11: It MUST be possible to query for the set of URIs and
copy of the list. This implies that it MUST be possible for other possible information related to a particular resource list
the server to notify the client of a change in the list. It by providing the URI for the resource list.
MUST be possible for the client to manipulate the local
cached copy even when there is no connectivity to the
server. It MUST be possible to synchronize the cached copy
with the master copy on the server, when connectivity is
re-established.
This particular requirement is crucial for wireless REQ PC-12: It MUST be possible to delete a resource list. In this
systems, where a copy of the list resides ont he handset. context, deleted means that the name of the resource list is no
Without this requirement, a user would not be able to view longer defined, so that subscriptions to the list would fail.
the list, or add a user to it, when they go out of
coverage.
REQ PC-13: It MUST be possible for there to be multiple clients REQ PC-13: It MUST be possible for a user to retrieve the list of
with cached copies of the list. resource lists that they have created.
REQ PC-14: Manipulations of the presentity collection MUST REQ PC-14: It MUST be possible for the resource list to be
exhibit the ACID property; that is, they MUST be atomic, be associated with a list of authorized users who are able to query
consistent, durable, and operate independently. for the set of URIs and other possible information related to the
list.
REQ PC-15: It MAY be possible for the client to batch multiple REQ PC-15: It MUST be possible for the resource list to be
operations (add a presentity, remove a presentity) into a associated with a list of authorized users who are the only ones
single request that is processed atomically. permitted to manipulate the resource list.
REQ PC-16: It MUST be possible for the server to authenticate REQ PC-16: It MUST be possible for the resource list to be
the client. associated with a list of authorized users who are authorized to
subscribe to the list.
REQ PC-17: It MUST be possible to use the same database of REQ PC-17: It MUST be possible for a client to store a cached copy
client credentials used with SIP and SIMPLE, with the data of the list. It MUST be possible for the client to manipulate the
manipulation protocol. local cached copy even when there is no connectivity to the
server. It MUST be possible to synchronize the cached copy with
the master copy on the server, when connectivity is
re-established.
REQ PC-18: It MUST be possible for the client to authenticate This particular requirement is crucial for wireless systems, where
the server. a copy of the list resides on the handset. Without this
requirement, a user would not be able to view the list, or add a
user to it, when they go out of coverage.
REQ PC-19: It MUST be possible for message integrity to be REQ PC-18: It MUST be possible multiple clients to manipulate a
insured between the client and the server. resource list without knowing of each other's actions. This
implies that it MUST be possible for the server to notify each
client of the changes if the client has indicated the need for the
change notifications.
REQ PC-20: It MUST be possible for confidentiality to be ensured REQ PC-19: Manipulations of the resource list MUST exhibit the ACID
between the client and server. As a motivating example, an property; that is, they MUST be atomic, be consistent, durable,
eavesdropper on the protocol could ascertain the set of and operate independently.
people in my presentity collection, resulting in divulging
private information.
REQ PC-21: It MUST be possible for the protocol to operate REQ PC-20: It SHOULD be possible for the client to batch multiple
through an intermediary, such as a proxy. operations (add a presentity, remove a presentity) into a single
request that is processed atomically.
REQ PC-22: It MUST be possible to modify an entry in the REQ PC-21: It MUST be possible for the server to authenticate the
presentity collection. client.
REQ PC-23: It MUST be possible for the protocol to operate with REQ PC-22: It SHOULD be possible to use the same database of client
devices with intermittent and low bandwidth connectivity, credentials used with SIP and SIMPLE, with the data manipulation
such as wireless data devices. protocol.
REQ PC-24: It MUST be possible for the presence collection to be REQ PC-23: It MUST be possible for the client to authenticate the
integrated with a network resident address book. This means server.
that there should be no duplication of data between the
two, and only a single transaction should be needed to add
or remove an entry from both.
REQ PC-25: It MUST be possible for a user to retrieve the list REQ PC-24: It MUST be possible for message integrity to be insured
of collections that they have created. between the client and the server.
REQ PC-26: It MUST be possible to associate a display name with REQ PC-25: It MUST be possible for confidentiality to be ensured
a collection. between the client and server. As a motivating example, an
eavesdropper on the protocol could ascertain the set of people in
my resource list, resulting in divulging private information.
REQ PC-27: It MUST be possible to extend the set of information REQ PC-26: It MUST be possible for the protocol to operate through
associated with entries in the collection. an intermediary, such as a proxy, to allow easier firewall
traversal.
5 Authorization Policy Manipulation 6. Authorization Policy Manipulation
The following are the set of requirements for the protocol between The following are the set of requirements for the protocol between
the client and the server for the purposes of manipulating presence the client and the server for the purposes of manipulating presence
authorization policy. The requirements are divided between acceptance authorization policy. The requirements are divided between acceptance
policy, notification policy, and content policy. policy, notification policy, and content policy. It is obvious that
these requirements would apply to other SIP event packages than
presence as well, but those are outside the scope of this document.
5.1 Acceptance Policy Requirements 6.1 Acceptance Policy Requirements
REQ AP-1: It MUST be possible for the acceptance policy to support
rejection of the subscription if the watcher is present on a
specified list of 'blocked watchers'. When a list is checked in
this fashion, it is referred to as a blocked list.
REQ AP-1: It MUST be possible for the acceptance policy to REQ AP-2: It MUST be possible for the acceptance policy to support
support rejection of the subscription if the watcher is rejection of the subscription if the watcher is not present on a
present on a specified list of "blocked watchers". When a specified list of 'allowed watchers'.
list is checked in this fashion, its referred to as a
blocked list.
REQ AP-2: It MUST be possible for the acceptance policy to REQ AP-3: It MUST be possible for the acceptance policy to support
support rejection of the subscription if the watcher is not making a subscription pending if the watcher is present on neither
present on a specified list of "allowed watchers". an explicit allowed or blocked list. In that case, the watcher
info package [5] can be used for reactive authorization.
REQ AP-3: It MUST be possible for the acceptance policy to REQ AP-4: It MUST be possible for the acceptance policy to check
support making a subscription pending if the watcher is multiple blocked and allowed lists.
present on neither an explicit allowed or blocked list. In
that case, the watcherinfo package [5] can be used for
reactive authorization.
REQ AP-4: It MUST be possible for the acceptance policy to check REQ AP-5: It SHOULD be possible for the policy to be based on the
multiple blocked and allowed lists. means by which the authenticated identity of the watcher was
determined (digest vs. S/MIME, for example).
REQ AP-5: It SHOULD be possible for the policy to be based on REQ AP-6: It SHOULD be possible for the policy to be based on
the means by which the authenticated identity of the whether notifications can be sent encrypted to the subscriber.
watcher was determined (digest vs. s/mime, for example).
REQ AP-6: It SHOULD be possible for the policy to be based on REQ AP-7: It MUST be possible for authorized users to create, read,
whether notifications can be sent encrypted to the modify and delete lists that are checked by the authorization
subscriber. policy (e.g., the allowed and blocked lists).
REQ AP-7: It MUST be possible for a subscription to be accepted REQ AP-8: It MUST be possible for authorized users to read, add,
or rejected based on whether the subscriber is on the remove and modify entries of the lists.
presentity's own buddy list.
REQ AP-8: It MUST be possible for the user to manipulate any REQ AP-9: It MUST be possible for the lists to contain entries with
lists that are checked by by the authorization policy (for wildcards, e.g., allow everyone in a certain domain.
example, the allowed and denied lists). Manipulate means to
add, remove, modify, read, clear and create and delete.
REQ AP-9: It MUST be possible for the acceptance policies to be 6.2 Notification Requirements
applied to subscriptions for SIP event packages [6] besides
presence.
5.2 Notification Requirements REQ N-1: It SHOULD be possible for the user to specify that
notifications are to be sent only when the value of a particular
status type changes.
REQ N-1: It MUST be possible for the user to specify that REQ N-2: It SHOULD be possible for the user to specify that the
notifications are to be sent only when the value of a notifications are to be sent only when a particular status type
particular status type changes. changes to a specified value or set of values.
REQ N-2: It MUST be possible for the user to specify that the REQ N-3: It SHOULD be possible for the user to specify that the
notifications are to be sent only when a particular status notifications are to be sent only when a particular status type
type changes to a specified value or set of values. changes from a specified value to a specified value (e.g., from
open to closed).
REQ N-3: It MUST be possible for the user to specify that the REQ N-4: It SHOULD be possible for the user to specify that the
notifications are to be sent only when a particular status notifications are to be sent only when the value of the contact
type changes from a specified value to a specified value address changes.
(i.e., from open to closed).
REQ N-4: It MUST be possible for the user to specify that the REQ N-5: It SHOULD be possible for the user to specify that the
notifications are to be sent only when the value of the notifications are not, or should be sent on changes in the state
contact address changes. of the subscription (as opposed to the state of the presentity).
REQ N-5: It SHOULD be possible for the user to specify that the 6.3 Content Requirements
notifications are not, or should be sent on changes in the
state of the subscription (as opposed to the state of the
presentity).
5.3 Content Requirements REQ C-1: The user MUST be able to specify that the notification
should only contain information for particular tuples. It SHOULD
be possible to use any presence attribute within a tuple as
criteria for this selection.
REQ C-1: It MUST be possible for the user to specify that the REQ C-2: It MUST be possible for the user to specify that the
notification should or should not contain a contact notification should or should not contain a contact address.
address.
REQ C-2: It MUST be possible for the user to specify that the REQ C-3: It MUST be possible for the user to specify that the
notification should contain only specific status types notification should contain only specific status types (such as
(such as basic). basic).
REQ C-3: The user MUST be able to specify the specific values of REQ C-4: The user MUST be able to specify the specific values of a
a specific status type that the notification should or specific status type that the notification should or should not
should not contain. Values not permitted must result in the contain. Values not permitted must result in the omission of that
omission of that status type. If all status is omitted, the status type. If all status is omitted, the tuple must be omitted
tuple must be omitted as well. As an example, a user can as well. As an example, a user can specify that the notification
specify that the notification should include tuples with should include tuples with OPEN status, but suppress those with
OPEN status, but suppress those with only CLOSED status. only CLOSED status.
REQ C-4: The user MUST be able to specify that the notification REQ C-5: It MUST be possible for the user to specify different
should only contain information for particular tuples. values of the semantically identical presence information, such as
status attribute, to different watchers. It MUST be possible for
the user to give different level of detail of information to
different watchers.
REQ C-5: It SHOULD be possible for the user to specify that the The assumption is that the presentity also publishes the different
value of a status should be modified for a particular values separately (e.g. in separate tuples), so that the
subscriber (i.e., the user wants to lie). authorization rules can simply select which (level of) information
to give to each watcher.
REQ C-6: It SHOULD be possible for the user to specify the REQ C-6: It SHOULD be possible for the user to specify the specific
specific presence document to send to a watcher. presence document to send to a watcher.
REQ C-7: It SHOULD be possible for the user to specify that the REQ C-7: It SHOULD be possible for the user to specify that the
notifications should be encrypted using S/MIME. notifications should be encrypted using S/MIME.
5.4 General Requirements REQ C-8: It SHOULD be possible for the user to specify that a
particular tuple be added, removed or modified based on the value
of another tuple. As an example, a user might want to include
their IM tuple when their phone is busy, but not include it when
the phone is not busy.
6.4 General Requirements
These requirements apply to all of the three components of the These requirements apply to all of the three components of the
authorization policy. authorization policy.
REQ G-1: It MUST be possible for a client to store a cached copy REQ G-1: It MUST be possible for a client to store a cached copy of
of the policies. This implies that it MUST be possible for the policies. It MUST be possible for the client to manipulate the
the server to notify the client of a change in these data. local cached copy even when there is no connectivity to the
It MUST be possible for the client to manipulate the local server. It MUST be possible to synchronize the cached copy with
cached copy even when there is no connectivity to the the master copy on the server, when connectivity is
server. It MUST be possible to synchronize the cached copy re-established.
with the master copy on the server, when connectivity is
re-established.
REQ G-2: It MUST be possible for there to be multiple clients
with cached copies of the data.
REQ G-3: Manipulations of the data MUST exhibit the ACID REQ G-2: It MUST be possible for multiple clients to manipulate the
property; that is, they MUST be atomic, be consistent, same policies without knowing of each others' actions. This
durable, and operate independently. implies that it MUST be possible for the server to notify each
client of the changes if the client has indicated the need for the
change notifications.
REQ G-4: It MAY be possible for the client to batch multiple REQ G-3: Manipulations of the data MUST exhibit the ACID property;
operations (add a user to a list, set a display name) into that is, they MUST be atomic, be consistent, durable, and operate
a single request that is processed atomically. independently.
REQ G-5: It MUST be possible for the server to authenticate the REQ G-4: It MUST be possible to ensure that the authorization
client. policies are always consistent as a whole when transitioning from
one policy state to another. To enable this, it MUST be possible
for the client to batch multiple operations (remove a user from
one list, add the same user to another list) into a single request
that is processed atomically, or to otherwise ensure that the
policies are never left in an inconsistent state.
REQ G-6: It MUST be possible to use the same database of client REQ G-5: It MUST be possible for the server to authenticate the
credentials used with SIP and SIMPLE, with the data client.
manipulation protocol.
REQ G-7: It MUST be possible for the client to authenticate the REQ G-6: It SHOULD be possible to use the same database of client
server. credentials used with SIP and SIMPLE, with the data manipulation
protocol.
REQ G-8: It MUST be possible for message integrity to be ensured REQ G-7: It MUST be possible for the client to authenticate the
between the client and the server. server.
REQ G-9: It MUST be possible for confidentiality to be ensured REQ G-8: It MUST be possible for message integrity to be ensured
between the client and server. As a motivating example, an between the client and the server.
eavesdropper on the protocol could ascertain the set of
people in my allowed list collection, resulting in
divulging private information.
REQ G-10: It MUST be possible for the protocol to operate with REQ G-9: It MUST be possible for confidentiality to be ensured
devices with intermittent and low bandwidth connectivity, between the client and server. As a motivating example, an
such as wireless data devices. eavesdropper on the protocol could ascertain the set of people in
my allowed list, resulting in divulging private information.
REQ G-11: It MUST be possible to extend the authorization REQ G-10: It MUST be possible to extend the authorization policies
policies with new rules. with new types of rules.
REQ G-12: It MUST be possible for a client to discover the types REQ G-11: It MUST be possible for a client to discover the types of
of authorization policies the server can handle. authorization policies the server can handle.
6 Security Considerations 7. Security Considerations
There are many security considerations associated with the protocol There are many security considerations associated with the protocol
whose requirements are defined here. whose requirements are defined here.
The protocol is used to manipulate data that has a signficiant impact The protocol is used to manipulate data that has a significant impact
on the operation of a service provided to a user. In particular, if on the operation of a service provided to a user. In particular, if
the data is manipulated by an attacker, the attacker can: an attacker manipulates the data, the attacker can:
o convey information to subscribers that the presentity wishes o convey information to subscribers that the presentity wishes to
to keep private; keep private;
o launch denial of service attacks by flooding a subscriber with o launch denial of service attacks by flooding a subscriber with
more presence information than they expected; more presence information than they expected;
o deny service to subscribers or to presentities. o deny service to subscribers or to presentities.
To prevent these attacks, the protocol has to ensure than only To prevent these attacks, the protocol has to ensure than only
authorized users can manipulate the data. Requirements for authorized users can manipulate the data. Requirements for
authentication and authorization are defined above. authentication and authorization are defined above.
Information conveyed in the protocol represents sensitive data. It Information conveyed in the protocol represents sensitive data. It
can include the content of presentity collections and lists of can include the content of resource lists and lists of blocked users,
blocked users, both of which reveal personal preferences of a user both of which reveal personal preferences of a user that they do not
that they do not wish to convey. As a result, it is necessary that wish to convey. As a result, it is necessary that the client
the client authenticate the server, to be sure it is passing this authenticate the server, to be sure it is passing this information to
information to a trusted entity. It is also necessary for the a trusted entity. It is also necessary for the protocol to provide
protocol to provide encryption services, so that eavesdroppers cannot encryption services, so that eavesdroppers cannot inspect the data as
inspect the data as it passes by. it passes by.
7 To Do 8. Acknowledgements
o Align this with the ongoing filter work
o Make sure the requirements are consistent with the final The authors would like to thank Paul Kyzivat, Ben Campbell, Krisztian
protocol mechanism. Kiss and Eva Leppanen for their input.
8 Acknowledgements 9. Changes from version 02
The authors would like to thank Paul Kyzivat for his input. o Conventions chapter added.
9 Authors Addresses o To-Do list removed.
Jonathan Rosenberg o Presentity collection renamed resource list.
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Markus Isomaki o Ordering of requirements 'rationalized'.
Nokia
Nokia House
Keilalahti, Espoo
Finland
email: markus.isomaki@nokia.com
10 Normative References o References updated.
11 Informative References o Defined the scope to be explicitly limited to only resource list
and presence authorization policy requirements.
[1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and o Several requirements modified based on SIMPLE WG last call
instant messaging," RFC 2778, Internet Engineering Task Force, Feb. comments by Ben Campbell and Krisztian Kiss.
2000.
[2] A. B. Roach, J. Rosenberg, and B. Campbell, "A session initiation Informative References
protocol (SIP) event notification extension for collections,"
internet draft, Internet Engineering Task Force, Mar. 2003. Work in
progress.
[3] J. Rosenberg, "A presence event package for the session [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
initiation protocol (SIP)," internet draft, Internet Engineering Task Levels", BCP 14, RFC 2119, March 1997.
Force, Jan. 2003. Work in progress.
[4] D. H. Crocker and J. L. Peterson, "Common profile for presence [2] Day, M., "A model for presence and instant messaging", RFC 2778,
(CPP)," internet draft, Internet Engineering Task Force, Mar. 2003. February 2000.
Work in progress.
[5] J. Rosenberg, "A watcher information event template-package for [3] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for
the session initiation protocol (SIP)," internet draft, Internet Presence", draft-ietf-simple-presence-10.txt, January 2003.
Engineering Task Force, Jan. 2003. Work in progress.
[6] A. B. Roach, "Session initiation protocol (sip)-specific event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
notification," RFC 3265, Internet Engineering Task Force, June 2002. Notification", RFC 3265, June 2002.
Intellectual Property Statement [5] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05.txt, January 2003.
[6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists",
draft-ietf-simple-event-list-03.txt, May 2003.
[7] Peterson, J., "Common profile for presence (CPP)",
draft-ietf-impp-pres-03.txt, May 2003.
Authors' Addresses
Jonathan Rosenberg
Dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
USA
Phone:
EMail: jdrosen@dynamicsoft.com
Markus Isomaki
Nokia Research Center
Itamerenkatu 11-13
00180 Helsinki
Finland
Phone:
EMail: markus.isomaki@nokia.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 14, line 34 skipping to change at page 15, line 27
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 121 change blocks. 
392 lines changed or deleted 408 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/