SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 24, 2003 February 23, 2003
An Application Configuration Access Protocol (ACAP) Dataset Classes
for Presence List and Authorization Policy
draft-rosenberg-simple-acap-data-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This specification discusses the applicability and usage of the
Application Configuration Access Protocol (ACAP) for the client
manipulation of presence lists (also known as buddy lists), and
presence authorization policy. An ACAP dataset class is specified,
and it is analyzed against the requirements that SIMPLE has developed
for this function.
Rosenberg Expires August 24, 2003 [Page 1]
Internet-Draft ACAP for SIMPLE February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of ACAP . . . . . . . . . . . . . . . . . . . . 5
3. Dataset Classes . . . . . . . . . . . . . . . . . . . . 7
3.1 Presence List Dataset Class . . . . . . . . . . . . . . 7
3.1.1 List Entries . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Presentity Entry . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Example Dataset . . . . . . . . . . . . . . . . . . . . 9
3.2 Presence Authorization List Dataset Class . . . . . . . 10
3.2.1 Design of the Data Model . . . . . . . . . . . . . . . . 10
3.2.2 The Dataset . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2.1 List Entries . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2.2 Watcher Entries . . . . . . . . . . . . . . . . . . . . 12
3.2.2.2.1 Subscription Status Attributes . . . . . . . . . . . . . 13
3.2.2.2.2 Notification Attributes . . . . . . . . . . . . . . . . 14
3.2.2.2.3 Content Attributes . . . . . . . . . . . . . . . . . . . 15
3.2.2.2.4 Transformational Attributes . . . . . . . . . . . . . . 16
3.2.2.2.5 Derived Permissions . . . . . . . . . . . . . . . . . . 17
3.2.2.3 Example Dataset . . . . . . . . . . . . . . . . . . . . 17
3.3 Permission Group Dataset Class . . . . . . . . . . . . . 18
3.4 Presence Authorization Capabilities Dataset Class . . . 19
3.5 Collected BNF . . . . . . . . . . . . . . . . . . . . . 21
3.6 Presence Agent Processing . . . . . . . . . . . . . . . 25
3.6.1 On Subscription Requests . . . . . . . . . . . . . . . . 25
3.6.2 On State Changes . . . . . . . . . . . . . . . . . . . . 27
3.6.3 On Entry Changes . . . . . . . . . . . . . . . . . . . . 27
4. Requirements Analysis and Proposal . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 34
Informative References . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . 37
Rosenberg Expires August 24, 2003 [Page 2]
Internet-Draft ACAP for SIMPLE February 2003
1. Introduction
The Session Initiation Protocol for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) working group has been developing
specifications for subscribing to, and receiving notifications of,
user presence [11]. An important aspect of user presence is
authorization policy. Indeed, the presence specification requires a
Presence Agent (PA) to both authenticate and authorize all
subscriptions before accepting them. However, it does not define how
the server determines the authorization status of a subscriber. Users
can set their authorization policy through web pages or voice
response systems. However, there is currently no protocol specified
for setting this policy. A protocol for this purpose is called an
authorization manipulation protocol.
Mechanisms have also been defined to support reactive authorization
[12][13]. Reactive authorization allows the user to be informed when
someone has attempted to subscribe to their presence when the server
is unable to determine an authorization policy. The user can then go
and set an authorization policy for the subscriber, using the same
unspecified mechanism for setting the policy.
Another important aspect of presence systems is the buddy list, also
known as the presence list. This is a list of users that a watcher
wishes to learn presence state for. This list can be stored in the
client, or it can be stored in a centralized server. In the latter
case, the client would subscribe to the list as a whole [14]. The
presence list can be set by using a web page or voice response
application. However, there is no protocol mechanism currently
specified to manage the presence list. Such a protocol is called a
presence list manipulation protocol.
The SIMPLE group has defined requirements for an authorization
manipulation protocol and a presence list manipulation protocol.
These protocols have similar requirements, and are captured in [15].
This document proposes a candidate for the authorization and presence
manipulation protocol. The proposal is based on the Application
Configuration Access Protocol (ACAP) [2]. ACAP is specified in
RFC2244, and was designed to allow manipulation of
application-independent data by end user client devices. However,
rather than using ACAP directly, we propose that its syntax be
abandoned, and a SOAP-based mechanism is used instead. We also
propose that some of its notification capabilities are replaced with
a sip events [5] package.
Section 2 provides a brief overview of ACAP for readers who are not
familiar with the protocol. Section 3 defines dataset classes needed
Rosenberg Expires August 24, 2003 [Page 3]
Internet-Draft ACAP for SIMPLE February 2003
to support authorization and presence list manipulation. Section 4
analyzes ACAP, along with the specified dataset classes, against the
requirements and proposes a path forward.
Rosenberg Expires August 24, 2003 [Page 4]
Internet-Draft ACAP for SIMPLE February 2003
2. Overview of ACAP
The Application Configuration Access Protocol (ACAP) [2] is specified
in RFC 2244, published in 1997. It was designed to solve the problem
of management of per-user application data, such as an address book.
The desire was to have this data portable, so that a client would
have access to the data no matter which device they connected from.
ACAP provides a core set of functionality that includes access
control, synchronization, inheritance, and server independence.
Server independence is perhaps the most fundamental piece of ACAP.
The idea is for an ACAP server to provide data storage for
applications, independent of the particular application. It should be
possible to store address books, buddy lists, bookmarks, and so on,
without the server understanding what the data represents.
Access control is important because not all users should be able to
see all the data stored on a server. All pieces of data in an ACAP
server are associated with an access control list, which defines what
users can modify, read, write or create the data.
ACAP's synchronization capability allows for a client to learn about
changes in data that are made by another client. Therefore, if a user
has a PC and a phone, and updates the address book on the PC, that
change gets propagated to the phone.
ACAP provides an interesting inheritance feature. This feature allows
each user to inherit some data from a common source. As an example, a
company can define a corporate directory, which is the set of people
that work for the company. Each user in the company can have their
own address book. This address book can inherit from the company
address book, so that the company employees appear in everyones
address book. If an employee leaves, the entry is deleted from the
single source, and then disappears from everyones address book. Each
user can also modify the data that they inherit, and those
modifications are local.
ACAP operates similarly to IMAP. It is a text-based protocol, based
on a command-response sequence betwee a client and a server. It runs
over TCP, and assumes the existence of long-lived TCP connections.
ACAP authentication is based on the Simple Authentication and
Security Layer (SASL) [6].
The most important thing in ACAP is its data model. ACAP data is
structured as a tree. Each node in the tree is called an entry. Each
entry has a name, along with a set of attributes. A set of entries
which share the same parent node is called a dataset. In that case,
the parent node (which is an entry) has an attribute called
Rosenberg Expires August 24, 2003 [Page 5]
Internet-Draft ACAP for SIMPLE February 2003
subdataset, whose value is an ACAP URL that represents the dataset.
The ACAP URL can point to datasets on other servers, allowing the
tree to be distributed across a network.
A dataset class is a specification that defines the rules about how
to interpret the attributes of entries within a dataset. As an
example, an address-book dataset class [16] defines attributes like
"addressBook.MiddleName" which is a UTF-8 string that contains the
middle name of a person. Each entry in the dataset corresponds to an
entry in the address book. Indeed, ACAP was designed originally to
support address books. Although it is useful for much more than that,
there is an unquestioned bias towards that class of application data
types throughout the design of ACAP.
Rosenberg Expires August 24, 2003 [Page 6]
Internet-Draft ACAP for SIMPLE February 2003
3. Dataset Classes
Several dataset classes are needed in order to meet the requirements
in [15]. The collected BNF for these dataset classes are in Section
3.5
3.1 Presence List Dataset Class
Datasets whose names begin with "/presence-list" are assumed to
contain presence list entries as defined in this specification. Each
entry within this dataset represents either a presence list, which
can be subscribed to using the SIP event extension for collections
[14], or a presentity. Lists can contain both presentities and
additional lists. This allows a presence list to be structured as a
tree (using ACAP hierarchy), with presentities at any level of the
tree. Whether an entry is a presentity or a list can be determined
based on the presence of the subdataset attribute. When this
attribute is present, the entry represents a list.
A presence-list dataset can usefully inherit from another
presence-list dataset. As discussed in RFC 2244, this is accomplished
by setting dataset.inherit attribute of the "" entry in the dataset
to the ACAP URL to inherit from. Inheritance has many uses for
presence lists. A company can define department wide lists,
containing each member of the department. People in the company can
set their lists to inherit from these department wide lists. They can
then add or remove people from the inherited list, without those
changes affecting the base departmental list.
3.1.1 List Entries
When an entry represents a presence list, it MUST have an entry
attribute. This attribute contains a string that uniquely identifies
this entry within the dataset. It is encoded in UTF-8 and may not be
useful for rendering to human users.
An entry representing a presence list MAY contain the
presence-list.URI attribute. This attribute is multi-valued, where
each value is a URI. These are URIs which are used to the subscribe
to the list. They will often be a SIP URI, but can also be another
URI, such as a pres URI [18]. If multiple URIs are present, each
represents an alias for the others. If the ACAP server supports the
SERVER-PRES-URI capability (ACAP provides a means for the client to
discover the capabilities of the server), the attribute is read-only,
and will be filled in by the server when the entry is created. If the
capability is not supported, the client sets the URI. In that case,
it is the responsibility of the client to select a URI which routes
to the PA for the list, and which is sufficiently random so as not to
Rosenberg Expires August 24, 2003 [Page 7]
Internet-Draft ACAP for SIMPLE February 2003
collide with other URIs. [[OPEN ISSUE: This means that
server-assigned URIs are either enabled for all users, or none of
them. Is that OK? Do we really even want client-specified URIs?]]
When a list is present without the presence-list.URI attribute, it
means that the list is not directly subscribable. Its members would
be subscribed to by subscribing to a parent with such an attribute.
This allows for a list to be constructed as a tree with various
logical "entry points" where it is reasonable to subscribe to the
sub-tree.
An entry representing a list MUST have a subdataset attribute. This
contains the relative ACAP URL which identifies the dataset whose
entries constitute the members of the list. Generally, this will be a
".", indicating that the members are directly beneath the dataset.
However, the subdataset MAY contain any ACAP URL, indicating that the
membership can be defined anywhere, even on another server.
An entry representing a list MAY have a presence-list.DisplayName
attribute. This attribute contains a UTF-8 encoded string that
provides a descriptive name for the list, suitable for consumption by
a human user. Some examples of useful names are "Marketing", and
"Tolkien Fans". When not present, it implies that the hierarchy
present at this node is not meant for human consumption, but present
for some kind of protocol use, such as facilitating inheritance.
An entry representing a list MAY have a presence-list.MaySubscribe
attribute. This attribute is only meaningful when the
presence-list.URI attribute is present. The
presence-list.MaySubscribe attribute is multivalued, and contains a
list of ACAP userid or groupid names [17]. These represent the
authenticated identities which are allowed to susbcribe to the list.
If not present, the set of authorized entities is the same as the set
present in the acl for the dataset. This means, that by default, only
the users who can manipulate the list can subscribe to it. However,
those with permission to modify the list can allow additional users
to subscribe.
An entry representing a list MAY include vendor defined attributes.
The use of those attributes is outside the scope of this
specification.
3.1.2 Presentity Entry
An entry in a presence-list dataset that represents a presentity MUST
NOT have the subdataset attribute defined. This is how a client
determines whether or not its a presentity, as opposed to another
list.
Rosenberg Expires August 24, 2003 [Page 8]
Internet-Draft ACAP for SIMPLE February 2003
An entry representing a presentity MUST have its entry attribute
defined. This attribute contains a string that uniquely identifies
this entry within the dataset. It is encoded in UTF-8 and may not be
useful for rendering to human users.
An entry representing a presentity MUST have a
presence-list.TargetURI attribute. This attribute MUST contain a
single URI that identifies how to obtain the presence for this
presentity. It will generally be a SIP URI, but MAY be a pres URI
[18] [[Editors note: XMPP URIs?]]. When a user subscribes to a list,
by sending a SUBSCRIBE request to the URI from its presence-list.URI
attribute, the list server will traverse the list and obtain the
presence of each presentity using this URI. The URI might be local,
in which case no messages are generated to a remote domain.
An entry representing a presentity MUST have a
presence-list.DisplayName attribute. This attribute contains a UTF-8
encoded string for rendering to the user. It identifies this
presentity in the list.
An entry representing a presentity MAY have a presence-list.Abook
attribute. This attribute contains an ACAP URL that points to an
entry in an ACAP address book dataset [16]. The addressbook dataset
class contains a comprehensive set of addressbook attributes, such as
postal address, phone number, and so on.
[[OPEN ISSUE: This issue is due entirely to my inexperience with
ACAP. It was unclear to me whether or not the presence list could
actually inherit from an addressbook, in which case there would be no
need to have each entry appear twice - once here, and once again the
addressbook. However, ACAP is silent on whether a dataset has to
inherit from one of the same dataset class. Interestingly, attribute
names are scoped, so that there seems to be no technical reason why
it cannot be done. If possible, it is something we should allow, but
not mandate.]]
3.1.3 Example Dataset
The following is an example dataset /presence-list/user/joe for a
user, joe, who has a single buddy list called "friends", which
contains a presentity and another list, "internet-buddies", which
itself has two presentities:
Rosenberg Expires August 24, 2003 [Page 9]
Internet-Draft ACAP for SIMPLE February 2003
Entry /presence-list/user/joe/friends:
attribute entry: friends
attribute subdataset: .
attribute presence-list.URI: sip:joe.myfriends@example.com
attribute presence-list.displayname: My Friends
Entry /presence-list/user/joe/friends/bob
attribute entry: bob
attribute presence-list.targetURI: sip:bob@example.com
attribute presence-list.displayname: Bob Doe
Entry /presence-list/user/joe/friends/internet-buddies
attribute entry: internet-buddies
attribute subdataset: .
attribute presence-list.URI: sip:joe.internet-buddies@example.com
attribute presence-list.displayname: Internet Buddies
Entry /presence-list/user/joe/friends/internet-buddies/jack
attribute entry: jack
attribute presence-list.targetURI: sip:jack@example.com
attribute presence-list.displayname: Jack Smith
Entry /presence-list/user/joe/friends/internet-buddies/sudhir
attribute entry: sudhir
attribute presence-list.targetURI: sip:sudhir@example.com
attribute presence-list.displayname: Sudhir Sinha
3.2 Presence Authorization List Dataset Class
3.2.1 Design of the Data Model
Presence authorization is a complicated problem. There are a number
of different permissions that can be granted. As a result, there are
many ways to structure this data. One way is to create a list of
permissions (each of which is a dataset class), and within each list,
there is a list of users which identify those who have that
permission. Another is to specify the permissions as a script of
logical operations, which refers to lists of users, said lists
represented with dataset classes and not being directly associated
with permissions. Another approach is for each dataset entry to
represent a watcher, and the attributes of that entry specify the
permissions assigned to that watcher.
The design of this dataset class follows the latter model. It has
many benefits. The first is that it is the only one that usefully
works with ACAP inheritance. A company can define a list of watchers
with a default set of permissions (everyone from the company can
Rosenberg Expires August 24, 2003 [Page 10]
Internet-Draft ACAP for SIMPLE February 2003
subscribe). Users can inherit from this list, and then modify those
permissions by overriding the attributes.
This design also has excellent extensibility properties. As new
permission types arise, they can be defined as new attributes, and
therefore do not require any changes in the ACAP server. Vendor
specific permissions can be defined using vendor-specific attributes.
Indeed, Section 3.4 specifies a capabilities dataset class that can
be used by a client to discover what kind of permissions are
supported by the server. We also specify a way in which new
permissions can be defined by the users themselves.
The principle drawback is that it is possible for a single subscriber
to match multiple entries. However, to deal with this, a conflict
resolution algorithm is specified in Section 3.6.
3.2.2 The Dataset
Datasets whose names begin with "/presence-auth-list" are assumed to
contain presence authorization list entries as defined in this
specification. Each entry within this dataset represents either a
list or a watcher. Lists can contain both watchers and additional
lists. This allows a presence authorization list to be structured as
a tree (using ACAP hierarchy), with watchers at any level of the
tree. Whether an entry is a watcher or a list can be determined based
on the presence of the subdataset attribute. When this attribute is
present, the entry represents a list.
A presence authorization list dataset can usefully inherit from
another presence authorization list dataset. As discussed in RFC
2244, this is accomplished by setting dataset.inherit attribute of
the "" entry in the dataset to the ACAP URL to inherit from.
3.2.2.1 List Entries
When an entry represents a list, it MUST have an entry attribute.
This attribute contains a string that uniquely identifies this entry
within the dataset. It is encoded in UTF-8 and may not be useful for
rendering to human users.
An entry representing a list MUST have a subdataset attribute. This
contains the relative ACAP URL which identifies the dataset whose
entries constitute the members of the list. Generally, this will be a
".", indicating that the members are directly beneath the dataset.
However, the subdataset MAY contain any ACAP URL, indicating that the
membership can be defined anywhere, even on another server.
An entry representing a list MAY have a
Rosenberg Expires August 24, 2003 [Page 11]
Internet-Draft ACAP for SIMPLE February 2003
presence-auth-list.DisplayName attribute. This attribute contains a
UTF-8 encoded string that provides a descriptive name for the list,
suitable for consumption by a human user. This allows a user to group
the sets of potential watchers and associate them with names.
The "" entry in the dataset MAY have a
presence-auth-list.PresentityURI attribute. This attribute is
multivalued, and contains a list of URIs that identify the
presentities to whom the authorization list applies. This is useful
in cases where a single user has a number of aliases, each of which
is a separate presentity URI. [[Editors Note: do we really need this?
We could model it as separate users.]]. If this attribute is absent,
the authorization list applies for all presentities bound to the
user.
An entry representing a list MAY include vendor defined attributes.
The use of those attributes is outside the scope of this
specification.
3.2.2.2 Watcher Entries
Watchers are the fundamental unit upon which permissions are defined.
Each watcher entry in a dataset MUST have an entry attribute. This
attribute contains a string that uniquely identifies this entry
within the dataset. It is encoded in UTF-8 and may not be useful for
rendering to human users.
An entry representing a watcher MAY have a
presence-auth-list.DisplayName attribute. This attribute contains a
UTF-8 encoded string that provides a descriptive name for the
watcher, suitable for consumption by a human user. This allows a user
to associate watchers with names.
The most important attribute for a watcher is the
presence-auth-list.AuthID attribute. This attribute is multivalued,
and contains a list of ACAP userid or groupid. These represent the
identities which, if posssesed by the subscriber, and verified with
the authentication mechanisms associated with that user or group ID,
cause it to be associated with this watcher entry. It is very
important to note that this attribute can refer to groups. This means
that a user can have an entry, "marketing", which refers to the
marketing department. The presence-auth-list.AuthID attribute would
point to the set of users in the marketing department, using the
groupid dataset class. Each of those users, in turn, would have a
single userid entry with the set of authentication mechanism specific
identities which identify that user. For SIP, this would typically
include the digest username.
Rosenberg Expires August 24, 2003 [Page 12]
Internet-Draft ACAP for SIMPLE February 2003
The presence-auth-list.AuthID attribute can also contain a "*". This
means that any authenticated identity matches. This is useful for
applying policies across all subscribers.
A watcher can also have a presence-list.Qvalue attribute. This
attribute is a fractional number from 0 to 1. When not present, the
default of one is assumed. It is used to resolve conflicts that arise
when multiple watcher entries match a subscriber. It is RECOMMENDED
that each entry have a unique value.
3.2.2.2.1 Subscription Status Attributes
Each watcher entry has a set of attributes which indicate the overall
status that is to be given to the subscription. The status of a
subscription can be accepted, rejected, or pending. As a result,
there are three groups of attributes - acceptance attributes,
rejection attributes, and pending attributes. Each attribute in one
of these groups describes a particular rule upon which the
acceptance, rejection, or pending decision is made. When a user
subscribes, the set of attributes whose rule matches that
subscription is computed, and used as part of PA processing of the
subscription (see Section 3.6).
Each attribute is of the form presence-auth-list.[group].[rule],
where group is one of "Accept", "Reject" or "Pending". Rule is one of
the following:
Any: Any subscription matches this attribute. The value of the
attribute is irrelevant.
TOD: The value of the attribute contains an iCal [7] object that
specifies the times during which the subscription will match.
ReqStatus: The value of this multivalued attribute is a list of
status types. If the presence subscription contains a filter [20]
that asks to be informed status types (such as basic [19]), all of
which appear in the list, the subscription is a match.
ReqTuples: The value of the attribute is a comma separated list of
tuples, each of which represents a label [21] for a tuple. If the
presence subscription contains a filter that asks to be informed
of all the tuples in the list, the subscription is a match.
Duration: The value of the attribute is an integer, representing a
number of seconds. If the subscription has a duration less than or
equal to the value of this attribute, the subscription is a match.
This attribute is useful for allowing only fetches, by setting it
to zero.
Rosenberg Expires August 24, 2003 [Page 13]
Internet-Draft ACAP for SIMPLE February 2003
OnList: The value of the attribute is an ACAP URL. This URL MUST
resolve to a dataset within the presence list dataset class. If
the subscriber is a member of this list, the subscription is a
match. This attribute is useful for authorizing subscribers that
are on ones own buddy list (so called reciprocal authorization
policy).
AuthMechanism: The value of the attribute is the authentication
mechanism used to authenticate the subscriber. Values include
none, digest, smime, mutualtls, anonymous (referring to the
anonymous digest login) and p-asserted-id [8]. A subscription
matches this rule if the authentication mechanism used for the
subscription equals the value.
CanEncrypt: The value of this attribute is irrelevant. A
subscription matches it if it is possible to encrypt notifications
towards the subscriber using S/MIME.
3.2.2.2.2 Notification Attributes
This set of attributes defines conditions under which a notification
is sent. When an event occurs which would normally cause the server
to send a notification, it checks this list of attributes. If the
specified event is described by any one of the attributes, the
notification is sent, otherwise, it is discarded.
The list of attributes is:
presence-auth-list.OnEvent.Any: All events match this attribute.
This means that all notifications are sent. The value of this
attribute is irrelevant.
presence-auth-list.OnEvent.EnterState: This attribute is
multivalued. Each value is a status type and status value
separated by a colon. When any one of the tuples for a presentity
has a status with the given name that changes to the given value,
the event is a match. For example, a value of basic:open means
that notifications are sent only when the basic status changes to
open.
presence-auth-list.OnEvent.ChangeIn: This attribute is
multi-valued. Each value is a presence status type (for example,
basic). If a presentity changes state, and that change is for a
status of one of the listed types, its a match.
Rosenberg Expires August 24, 2003 [Page 14]
Internet-Draft ACAP for SIMPLE February 2003
presence-auth-list.OnEvent.Transition: This attribute is
multi-valued. Each value represents two presence states. When the
status of the presentity changes from the first to a second, its a
match. For example, basic:open:closed would indicate a transition
from open to closed.
presence-auth-list.OnEvent.Contact: If the change in state is of
the contact, and not of any of the statuses, its a match. The
value of this attribute is irrelevant.
presence-auth-list.OnEvent.Subscription: If the change in state is
for the subscription itself, rather than the underlying
presentity, its a match. The value of this attribute is
irrelevant.
presence-auth-list.OnEvent.Filter: If the change in state is one
that matches a filter that the client has applied for the
subscription, its a match. This allows a user to accept or deny a
filter present in the subscription. The value of the attribute is
irrelevant.
[[Editors Note: We might be able to eliminate event filters by using
just content attributes. Content filters can also cause a
notification to be discarded if nothing has changed. Need to consider
that further.]]
3.2.2.2.3 Content Attributes
These attributes specify the information that is to be reported to
the subscriber in the body of the notifications. When a change in
state occurs, the presence server looks through this list. Only those
elements of the presence document which match at least one of the
attributes is kept. If the result is a document which hasn't changed
from the last notification, no notification is sent. If the result is
an empty document, no notification is sent.
The list of attributes is:
presence-auth-list.Content.Any: Any element of the presence
document matches. The value of the attribute is irrelevant.
presence-auth-list.Content.Contact: The contact element of any
tuple. The value of the attribute is irrelevant.
presence-auth-list.Content.Tuples: This attribute is multi-valued.
Each value is a tuple or a negation of a tuple, where tuples are
identified by a label [21]. A tuple from the presence document
matches this attribute if that tuple name is present, un-negated,
Rosenberg Expires August 24, 2003 [Page 15]
Internet-Draft ACAP for SIMPLE February 2003
in this list, or if it is not present in all of the negations. For
example, if the value of this attribute is "!pc" and
"!cell-phone", any tuple from the presence document which is not
the pc and not the cell-phone, is included. [[OPEN ISSUE: It might
be easier to separate the negations out into a separate
attribute.]]
presence-auth-list.Content.StatusType: This attribute is
multi-valued. Each value is a status types (for example, basic),
or a negation of a status type. A status type from the presence
document matches this attribute if that status type is present,
un-negated, in this list, or if it is not present in all of the
negations. For example, if the value of this attribute is
"!geoloc" and "!placetype", any status from the presence document
which is not geolocation and not the place-type, is included.
[[OPEN ISSUE: It might be easier to separate the negations out
into a separate attribute.]] [[TODO: These probably need to
include the XML namespace qualifications.]]
presence-auth-list.Content.StatusValue: This attribute is
multi-valued. Each value is a status type and value, separated by
a colon, or the negation of the status type and value. A status
type is included in the presence document if the type and value is
present, un-negated, in this list, or if it is not present in all
the negations. For example, if the value of this attribute is
"!placetype:home", it means that the placetype status is included
in the notification if its value is not home. If its value is
home, the attribute is omitted entirely.
presence-auth-list.Content.UseFilter: The value of the attribute
is irrelevant. An element of the presence document matches this
attribute if it also matches any filter specified by the client
for this subscription. This attribute allows the presentity to
simply accept the event filter suggested by the subscriber.
presence-auth-list.Content.Encrypt: The value of the attribute is
irrelevant. This attribute directs the server to encrypt
notifications to the subscriber using S/MIME.
3.2.2.2.4 Transformational Attributes
presence-auth-list.Xform.SendDocument: The value of this attribute
as an XML document, encoded in application/cpim-pidf format, that
is to be sent to the watcher. This is useful for implementing the
polite blocking function. A static document can be specified which
is always sent to that watcher.
Rosenberg Expires August 24, 2003 [Page 16]
Internet-Draft ACAP for SIMPLE February 2003
presence-auth-list.Xform.SetStatus: This attribute is
multi-valued. Each value is a status-type and value separated by a
colon. For any tuple that contains a status of that type, its
value is set to the status. For example, to always appear at home,
the value of this attribute would be placetype:home. [[OPEN ISSUE:
Should these statuses also be added to tuples that don't contain
them?]]
presence-auth-list.Xform.ChangeStatus: This attribute is
multi-valued. Each value is a status-type, old-value, and
new-value separated by colons. For any tuple that contains a
status of that type, whose value is old-value, the value is
changed to new-value. For example, to make yourself look like you
are in a meeting when you are really having a meal, the value of
this attribute would be "category:meal:meeting".
presence-auth-list.Xform.UseFilter: The value of the attribute is
irrelevant. If present, it means that any content transformations
request by a client in a filter present in the subscription will
be applied.
3.2.2.2.5 Derived Permissions
Using the group permissions dataset class, described in Section 3.3,
a user can define new permissions as a combination of the "root"
permissions defined above (plus vendor-specific ones). In that case,
a watcher entry can be placed into one of these permission groups. To
do that, the entry contains a presence-auth-list.DerivedPermission
attribute. This attribute is multi-valued. Each value is the value of
the entry from ~/presence-permission-group that defines the
permission. When there are multiple values, it means that the watcher
is part of all the listed permission groups. These permission groups
may each contain the same attributes, but with different values.
Section 3.6 describes how this is resolved.
3.2.2.3 Example Dataset
A user, Joe, wishes to deny subscriptions from Bob and Jack.
Subscriptions from Jill are to be politely blocked. He wishes to
accept subscriptions from marketing people, but only allow those
folks to see his work phone status. For all other subscribers, their
subscriptions are pending.
The dataset to accomplish this would look like this:
Rosenberg Expires August 24, 2003 [Page 17]
Internet-Draft ACAP for SIMPLE February 2003
Entry /presence-auth-list/user/joe/bob:
attribute entry: bob
attribute presence-auth-list.AuthID: bob
attribute presence-auth-list.Reject.Any: foo
Entry /presence-auth-list/user/joe/jack
attribute entry: jack
attribute presence-auth-list.AuthID: jack
attribute presence-auth-list.Reject.Any: foo
Entry /presence-auth-list/user/joe/jill
attribute entry: jill
attribute presence-auth-list.AuthID: jill
attribute presence-auth-list.Accept.Any: foo
attribute presence-auth-list.Xform.SetStatus: [XML doc to send]
Entry /presence-auth-list/user/joe/marketing
attribute entry: marketing-dept
attribute presence-auth-list.AuthID: marketing
attribute presence-auth-list.Accept.Any: foo
attribute presence-auth-list.Content.Tuples: work-phone
Entry /presence-auth-list/user/joe/others
attribute entry: others
attribute presence-auth-list.AuthID: *
attribute presence-auth-list.Qvalue: 0.0
attribute presence-auth-list.Pending.Any: foo
3.3 Permission Group Dataset Class
It is very useful to be able to define new permissions as
combinations of existing permissions. For example, a user might like
to define a new persmission called "friends", which the user
typically applies to friends. This permission includes
presence-auth-list.acceptance.any, permitting the subscription, but
restricts the tuples that can be seen to their home PC and cell phone
by setting the presence-auth-list.Content.Tuples attribute
appropriately.
Permission groups are defined using the permission group dataset
class. Datasets whose names begin with "/presence-permission-group"
are assumed to contain permission entries as defined in this
specification. Each entry within this dataset represents a new
permission group. A presence permission group dataset can usefully
inherit from another permission group dataset. As discussed in RFC
2244, this is accomplished by setting dataset.inherit attribute of
Rosenberg Expires August 24, 2003 [Page 18]
Internet-Draft ACAP for SIMPLE February 2003
the "" entry in the dataset to the ACAP URL to inherit from.
Each entry in the dataset MUST contain the entry attribute. This
attribute contains a string that uniquely identifies this entry
within the dataset. It is encoded in UTF-8 and may not be useful for
rendering to human users.
Each entry in the dataset SHOULD contain the
presence-permission-group.DisplayName attribute. This attribute
contains a UTF-8 encoded string that provides a descriptive name for
the group, suitable for consumption by a human user. This allows a
user to associate watchers with permissions.
Each entry in the dataset MUST contain the
presence-permission-group.Qvalue attribute. This attribute MUST be
different for each entry. It is used to specify a relative ordering
of the permission groups. It is used by a presence agent to deal with
conflicting rules when a watcher is associated with multiple
permission groups.
Each entry in the dataset MAY contain any attribute from the
presence-auth-list dataset class (excepting DisplayName,
PresentityURI, AuthID and Qvalue), with its dataset class prefix
replaced with presence-permission-group. Beyond the change in prefix,
the syntax and semantics of the attributes remain the same. To make
use of the permission group, a watcher entry in the
presence-auth-list dataset class would have its
presence-auth-list.DerivedPermission attribute set to include the
value of the entry for the permission group to apply.
As an example, to define a new permission called friends, and to
specify that friends see only the status of the cell-phone, but
without geolocation, a user Joe would create the following entry:
Entry /user/joe/presence-permission-group/friends:
attribute entry: friends
attribute presence-permission-group.Qvalue: 1.0
attribute presence-permission-group.DisplayName: My Friends
attribute presence-permission-group.Accept.Any: foo
attribute presence-permission-group.Content.Tuples: cell-phone
attribute presence-permission-group.Content.Status: !geoloc
3.4 Presence Authorization Capabilities Dataset Class
The presence authorization list dataset class presents a large number
of attributes that define specific permissions that can be assigned
to a watcher. However, not all systems will support all of these
Rosenberg Expires August 24, 2003 [Page 19]
Internet-Draft ACAP for SIMPLE February 2003
permission types. Even if they do, a provider may not wish each user
to have access to all of them. For example, premium users might have
access to content filtering capabilities, while basic users may not.
This presents an interoperability problem. How does a client
determine what types of permissions it can assign to a watcher?
The solution to this problem is to define a dataset class
supported-presence-permissions which holds the set of permissions
that the server understands. Datasets whose names begin with "/
supported-presence-permissions" are assumed to contain supported
permission entries as defined in this specification. Each entry
within this dataset represents a permission that is supported.
Each entry in the dataset MUST contain the entry attribute. This
attribute contains a string that uniquely identifies this entry
within the dataset. It is encoded in UTF-8 and may not be useful for
rendering to human users.
Each entry MUST contain the supported-presence-permissions.Permission
attribute. Its value is a string that contains the name of the
permission that is supported. This can be any of the attributes
defined for the presence-auth-list dataset class, but can also be
vendor specific attributes. Typically, the name of the entry will
also be that permission, but it need not be. The name of the entry is
irrelevant.
Each entry SHOULD contain the
supported-presence-permissions.Directions attribute. Its value is a
string which provides the user with a textual description of the
permission. This is very useful for vendor-specific permissions.
Descriptive text can be provided to the user so that they can figure
out how to apply the permission.
When a client first connects, it SHOULD look in /~/
supported-presence-permissions/ for the list of permissions that the
server is allowing the user to use. If this dataset does not exist,
the client SHOULD then check in /supported-presence-permissions/site
to determine domain-wide limitations. This dataset MUST always exist.
Clients SHOULD NOT set permissions that are not listed as being
supported. If they do, it is not a catastrophic error. Those
permissions will simply be ignored. Therefore, the behavior exhibited
by the system may not be as expected.
For example, consider a server that allows a user to just accept or
reject subscriptions, without any kind of content filtering or
transformations. The server also supports permission groups, although
these are primarily useful for allowing the user to define a helpful
Rosenberg Expires August 24, 2003 [Page 20]
Internet-Draft ACAP for SIMPLE February 2003
mnemonic for accepting and rejecting subscriptions. In such a case,
the following dataset would exist in the server:
Entry /supported-presence-permissions/site/allow:
attribute entry: allow
attribute supported-presence-permissions.Permission:
presence-auth-list.accept.any
attribute supported-presence-permissions.Directions:
Allow this user to see you
Entry /supported-presence-permissions/site/deny:
attribute entry: allow
attribute supported-presence-permissions.Permission:
presence-auth-list.reject.any
attribute supported-presence-permissions.Directions:
Deny this user the right to see you
Entry /supported-presence-permissions/site/group:
attribute entry: group
attribute supported-presence-permissions.Permission:
presence-auth-list.derived-permission
attribute supported-presence-permissions.Directions:
Define your own mnemonics for allow and deny
3.5 Collected BNF
This section presents the collected BNF for all of the attributes
defined in the dataset classes introduced in this specification.
presence-list.URI = absoluteURI
;; multi-valued
presence-list.DisplayName = 1*TEXT_UTF8_CHAR ;from RFC 2244
presence-list.MaySubscribe = 1*TEXT_UTF8_CHAR ;from RFC 2244
;; multi-valued
presence-list.TargetURI = absoluteURI
presence-list.Abook = url-acap ;from RFC 2244
presence-auth-list.DisplayName = 1*TEXT_UTF8_CHAR ;from RFC 2244
presence-auth-list.PresentityURI = absoluteURI
;; multi-valued
presence-auth-list.AuthID = 1*TEXT_UTF8_CHAR ;from RFC 2244
;; multi-valued
presence-auth-list.Qvalue = qvalue ;from RFC 3261
presence-auth-list.Accept.Any = 0*TEXT_UTF_CHAR
presence-auth-list.Accept.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
Rosenberg Expires August 24, 2003 [Page 21]
Internet-Draft ACAP for SIMPLE February 2003
presence-auth-list.Accept.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-auth-list.Accept.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-auth-list.Accept.Duration = 1*DIGIT
presence-auth-list.Accept.OnList = url-acap
presence-auth-list.Accept.AuthMechanism = none / digest / smime / mutualtls
/ p-asserted-id / anonymous
presence-auth-list.Accept.CanEncrypt = 0*TEXT_UTF_CHAR
presence-auth-list.Reject.Any = 0*TEXT_UTF_CHAR
presence-auth-list.Reject.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
presence-auth-list.Reject.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-auth-list.Reject.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-auth-list.Reject.Duration = 1*DIGIT
presence-auth-list.Reject.OnList = url-acap
presence-auth-list.Reject.AuthMechanism = none / digest / smime / mutualtls
/ p-asserted-id / anonymous
presence-auth-list.Reject.CanEncrypt = 0*TEXT_UTF_CHAR
presence-auth-list.Pending.Any = 0*TEXT_UTF_CHAR
presence-auth-list.Pending.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
presence-auth-list.Pending.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-auth-list.Pending.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-auth-list.Pending.Duration = 1*DIGIT
presence-auth-list.Pending.OnList = url-acap
presence-auth-list.Pending.AuthMechanism = none / digest / smime / mutualtls
/ p-asserted-id / anonymous
presence-auth-list.Pending.CanEncrypt = 0*TEXT_UTF_CHAR
presence-auth-list.OnEvent.Any = 0*TEXT_UTF_CHAR
presence-auth-list.OnEvent.EnterState = token ":" token
; grammar has issues, i think, since its not token
; and the xml elements can contain colons?
;; multi-valued
presence-auth-list.OnEvent.ChangeIn = token
; grammar issue again
;; multi-valued
presence-auth-list.OnEvent.Transition = token ":" token ":" token
Rosenberg Expires August 24, 2003 [Page 22]
Internet-Draft ACAP for SIMPLE February 2003
; grammar issue again
;; multi-valued
presence-auth-list.OnEvent.Contact = 0*TEXT_UTF_CHAR
presence-auth-list.OnEvent.Subscription = 0*TEXT_UTF_CHAR
presence-auth-list.OnEvent.Filter = 0*TEXT_UTF_CHAR
presence-auth-list.Content.Any = 0*TEXT_UTF_CHAR
presence-auth-list.Content.Contact = 0*TEXT_UTF_CHAR
presence-auth-list.Content.Tuples = token / ("!" token)
; align grammar with RPIDS
;; multi-valued
presence-auth-list.Content.StatusType = token / ("!" token)
; XML grammar alignment
;; multi-valued
presence-auth-list.Content.StatusValue = (token ":" token) /
("!" token ":" token)
; XML grammar alignment
;; multi-valued
presence-auth-list.Content.UseFilter = 0*TEXT_UTF_CHAR
presence-auth-list.Content.Encrypt = 0*TEXT_UTF_CHAR
presence-auth-list.Xform.SendDocument = ??
; XML grammar alignment
presence-auth-list.Xform.SetStatus = token ":" token
; XML grammar alignment
;; multi-valued
presence-auth-list.Xform.ChangeStatus = token ":" token ":" token
; XML grammar alignment
;; multi-valued
presence-auth-list.Xform.UseFilter = 0*TEXT_UTF_CHAR
presence-auth-list.DerivedPermission = 1*UTF8-CHAR
;; multi-valued
presence-permission-group.DisplayName = 1*TEXT_UTF8_CHAR
presence-permission-group.Qvalue = qvalue ;from RFC 3261
presence-permission-group.Accept.Any = 0*TEXT_UTF_CHAR
presence-permission-group.Accept.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
presence-permission-group.Accept.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-permission-group.Accept.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-permission-group.Accept.Duration = 1*DIGIT
presence-permission-group.Accept.OnList = url-acap
presence-permission-group.Accept.AuthMechanism = none / digest /
smime / mutualtls / p-asserted-id / anonymous
presence-permission-group.Accept.CanEncrypt = 0*TEXT_UTF_CHAR
presence-permission-group.Reject.Any = 0*TEXT_UTF_CHAR
Rosenberg Expires August 24, 2003 [Page 23]
Internet-Draft ACAP for SIMPLE February 2003
presence-permission-group.Reject.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
presence-permission-group.Reject.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-permission-group.Reject.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-permission-group.Reject.Duration = 1*DIGIT
presence-permission-group.Reject.OnList = url-acap
presence-permission-group.Reject.AuthMechanism = none / digest /
smime / mutualtls / p-asserted-id / anonymous
presence-permission-group.Reject.CanEncrypt = 0*TEXT_UTF_CHAR
presence-permission-group.Pending.Any = 0*TEXT_UTF_CHAR
presence-permission-group.Pending.TOD = 1*content-line ;from RFC 2445
; this can contain CRLF - is that allowed??
presence-permission-group.Pending.ReqStatus = token
; this is not right; it needs to be the XML grammar for elements
;; multi-valued
presence-permission-group.Pending.ReqTuples = token
; align grammar with RPIDS
;; multi-valued
presence-permission-group.Pending.Duration = 1*DIGIT
presence-permission-group.Pending.OnList = url-acap
presence-permission-group.Pending.AuthMechanism = none / digest /
smime / mutualtls / p-asserted-id / anonymous
presence-permission-group.Pending.CanEncrypt = 0*TEXT_UTF_CHAR
presence-permission-group.OnEvent.Any = 0*TEXT_UTF_CHAR
presence-permission-group.OnEvent.EnterState = token ":" token
; grammar has issues, i think, since its not token
; and the xml elements can contain colons?
;; multi-valued
presence-permission-group.OnEvent.ChangeIn = token
; grammar issue again
;; multi-valued
presence-permission-group.OnEvent.Transition = token ":" token ":" token
; grammar issue again
;; multi-valued
presence-permission-group.OnEvent.Contact = 0*TEXT_UTF_CHAR
presence-permission-group.OnEvent.Subscription = 0*TEXT_UTF_CHAR
presence-permission-group.OnEvent.Filter = 0*TEXT_UTF_CHAR
presence-permission-group.Content.Any = 0*TEXT_UTF_CHAR
presence-permission-group.Content.Contact = 0*TEXT_UTF_CHAR
presence-permission-group.Content.Tuples = token / ("!" token)
; align grammar with RPIDS
;; multi-valued
presence-permission-group.Content.StatusType = token / ("!" token)
; XML grammar alignment
Rosenberg Expires August 24, 2003 [Page 24]
Internet-Draft ACAP for SIMPLE February 2003
;; multi-valued
presence-permission-group.Content.UseFilter = 0*TEXT_UTF_CHAR
presence-permission-group.Xform.SendDocument = ??
; XML grammar alignment
presence-permission-group.Xform.SetStatus = token ":" token
; XML grammar alignment
;; multi-valued
presence-permission-group.Xform.ChangeStatus = token ":" token ":" token
; XML grammar alignment
;; multi-valued
presence-permission-group.Xform.UseFilter = 0*TEXT_UTF_CHAR
presence-permission-group.DerivedPermission = 1*UTF8-CHAR
;; multi-valued
supported-presence-permissions.Permission = 1*UTF8-CHAR
supported-presence-permissions.Direction = 1*UTF8-CHAR
3.6 Presence Agent Processing
Logically speaking, the PA is a client of ACAP, just like the end
user devices. However, the job of the PA is to use the data stored by
the clients into ACAP in order to process subscriptions. This section
specifies the PA behavior that SHOULD take place.
3.6.1 On Subscription Requests
When a server receives a subscription, it authenticates the SUBSCRIBE
request. Using the ACAP userid dataset class, a userid and set of
groupids is determined for this subscriber. These represent the
authorization identities for the subscription.
Next, the PA determines the identity of the presentity [[OPEN ISSUE:
Need a way to map from SIP URI for the presentity, which is in the
request URI, to the userid]]. Call this identity "presentity". Then,
it looks at /presence-auth-list/presentity, and traverses the tree
specified there. As it looks at each entry, it matches the subscriber
identities against the presence-auth-list.AuthID attribute in each
entry. If the watcher identity is listed, or if the
presence-auth-list.AuthID attribute is a "*", the watcher entry is
placed into the match list. This list holds all the matching watcher
policies that apply to this specific subscriber.
From this list, the entry with the largest value of the
presence-auth-list.Qvalue attribute is determined. It is this entry
whose attributes are applied to the subscription. If there were no
matching entries, a provider default policy is applied.
Rosenberg Expires August 24, 2003 [Page 25]
Internet-Draft ACAP for SIMPLE February 2003
If any entry in the match list has a
presence-auth-list.derived-permission attribute, that entry is
modified, for purposes of processing, as follows (there is no actual
modification of the entry as written into the database). For each
value of the derived-permission attribute, the corresponding entry in
the group permission dataset is obtained. Its attributes are changed
from the presence-group-permissions prefix to the presence-auth-list
prefix, and are applied to the entry. If the attribute already exists
in the entry, and it came from another permission group, a conflict
resolution is applied. The attribute from the permission group with
the larger q-value "wins", and is placed into the entry. However,
attributes expanded from permission groups never override attributes
that were explicitly placed into the entry.
The server then determines how to respond to the subscription
request. The subscription is compared to all attributes within the
presence-auth-list.reject prefix. If any of these match the
subscription, the subscription is rejected. If none of them matched,
or there were no such attributes, processing continues. The
subscription is compared to all attributes within the
presence-auth-list.pending prefix. If any of these match the
subscription, the subscription is rejected. If none of them matched,
or there were no such attributes, processing continues. The
subscription is compared to all attributes within the
presence-auth-list.accept prefix. If any of these match the
subscription, the subscription is accepted. If none of them matched,
or there were no such attributes, the entire entry is discarded. The
entry from the match list with the next highest q-value is then
selected, and the process is repeated. This process either terminates
with a matching entry, or with no entries remaining. In the latter
case, provider specific policy is applied. It is RECOMMENDED that
this policy be pending.
[[OPEN ISSUE: An alternate structure is to allow only one status
attribute per entry. Then, if multiple rules are needed for the same
entry, a multiplicity of entries is used, each with the same authid
attribute, but differing q-values and status attributes. That has the
benefit of allowing the client to specfify the ordering of
acceptance, rejection, and pending, instead of the fixed ordering
above. The cost of this is that the content and transformation
attributes would need to be present in each. Perhaps acap hierarchy
plus inheritance can help there?]]
If the status of the subscription was to accept it, a reference to
the entry is stored as part of the subscription state. The
information in this entry is used to guide the generation of
notifications. Furthermore, the PA needs to be aware of changes in
the entry. If the entry changes, the processing in Section 3.6.3 is
Rosenberg Expires August 24, 2003 [Page 26]
Internet-Draft ACAP for SIMPLE February 2003
executed.
Next, a notification is sent containing the current state, as per RFC
3265 [5]. To compute the format of this state, the processing in
Section 3.6.2 is applied.
3.6.2 On State Changes
When a presence or subscription state change occurs, the PA computes
the presence document and subscription state (this combination is
called the presence state) that would be distributed to watchers if
the presentity had not specified any kind of authorization policy.
Then, for each currently subscribed watcher, the entry associated
with that subscription is examined. Any presence-auth-list.on-event
attributes are extracted. The current presence state is compared to
the last one sent to the watcher (if any). The differences are
compared to the rules associated with each on-event attribute. If
none of the differences match any of the attributes, no notification
is sent. Otherwise (including the case where there were no on-event
attributes), processing continues.
The PA next extracts the presence-auth-list.content attributes from
the entry. Each attribute specifies a filter on the data in the
presence state. Any component of the presence state which does not
match at least one attribute is discarded from the presence state.
However, if there were no presence-auth-list.content attributes, the
presence state is unmodified.
Finally, the PA extracts the presence-auth-list.xform attributes from
the entry. Any set-status attributes are applied, followed by
change-status, use-filter, and finally, send-document (which will
override any previous document transformations). [[OPEN-ISSUE: This
is weak. Specifying a fixed ordering makes it hard to extend this
list. An alternative is for there to be a single filter attribute
that contains some kind of XML document which can specify a filter
operation to apply.]]
After the above processing steps, the resulting presence state
(including the subscription state) is examined. If the state is empty
(because it was all filtered out), the notification is not sent. If
the state is not empty, but doesn't differ from the state sent to the
subscriber previously, the notification is not sent unless it is
explicitly a state refresh (i.e., a notification generated as a
result of a SUBSCRIBE refresh).
3.6.3 On Entry Changes
When the entry associated with a subscription changes, the PA runs
Rosenberg Expires August 24, 2003 [Page 27]
Internet-Draft ACAP for SIMPLE February 2003
through the processing as if a brand new subscription was just
received. This may result in a state transition of the subscription
itself (for example, to rejected). Furthermore, the entry change
might alter the presence information sent to the subscriber. If the
resulting data differs from what was last sent, a notification will
be sent.
Note that a PA is not obligated to check for changes in the q-values
of other entries. Such a change would affect whether, should the
subscription be terminated and reinitiated, the same entry is applied
to the subscription or not. Such a change will take effect when the
subscription is terminated and reinitiated. [[OPEN ISSUE: Is that
OK?]]
Rosenberg Expires August 24, 2003 [Page 28]
Internet-Draft ACAP for SIMPLE February 2003
4. Requirements Analysis and Proposal
An ACAP-based mechanism appears to meet most of the requirements
outlined in [15]. ACAP provides more than adequate primitives for
creating, deleting, searching and modifying data. The requirements
related to specific details of authorization policies can always be
met by defining suitable attributes. The more interesting point is
how an ACAP mechanism meets some of the more general requirements.
One requirement that is partially met is REQ 2 for presence lists.
This requirement states that the client can choose the name, and if
its allocated, the server rejects it. This kind of operation is not
obviously supported in ACAP. It may be possible through an extension,
but that is not clear. The proposed mechanism uses an ACAP extension
for the server to generate the URI. A weakness of this approach is
that URI allocation is either always client generated or always
server generated. It cannot be done differently on a per-client
basis.
Some of the security requirements, particularly those for message
integrity and privacy, are not easily met by ACAP alone. ACAP uses
SASL, which does not include a mechanism that would be adequate to
the purpose [[OPEN ISSUE: Need to double-check sasl mechanisms to
verify this.]]. However, RFC 2595 [3] provides a means for ACAP to
run over TLS, which would be sufficient.
We also have a requirement for the mechanism to run through an
intermediary. ACAP has no notion of intermediaries, so this
requirement cannot be met.
The most troubling point relates to the synchronization requirement
over wireless. ACAP provides synchronization through a long-lived
persistent TCP connection established by the server. To get change
notifications, the client does a search, and binds a named context to
the results of that search. The client can request to be notified of
changes to any attributes within that context. The lifetime of the
context is bound to the lifetime of the TCP connection. This has
several problems. A persistent TCP connection is not possible in
wireless, a key customer of this specification. If a connection is
lost, updates to the data made while the connection is broken will
not be sent to the client. Worse yet, there appears to be no easy way
for the client to determine, once it reconnects, whether any data has
changed. The assumption of ACAP appears to be that the client would
simply re-fetch the data when it reconnects. That is unacceptable for
wireless.
Another troubling point is the authentication mechanism. It is based
on SASL. There is a requirement for the authentication mechanisms in
Rosenberg Expires August 24, 2003 [Page 29]
Internet-Draft ACAP for SIMPLE February 2003
SIP to align with those in the data protocol, so that a common
authentication infrastructure can be used. Fortunately, there is a
digest mechanism defined for SASL (RFC 2831 [4]). That should allow
for the digest AKA mechanism [9] to be used with SASL and therefore
ACAP. However, this needs to be validated. Other SIP authentication
mechanisms, such as S/MIME, would not be compatible, nor would
P-Asserted-Identity [8].
A final difficulty is that the ACAP syntax is not consistent with SIP
or HTTP, and is somewhat awkward.
On the plus side, ACAP's data model is quite valuable, and appears to
work very well for the problem at hand. Its not perfect, though. It
doesn't appear to support multiple inheritance or cross-dataset
inheritance, which could be useful for allowing an address book to
serve as a presence-list, for example. Also, the attributes in an
entry can only come from a single dataset class, despite the fact
that the attribute names are scoped to that dataset class [[Editors
Note: Need to verify this with the ACAP authors. There is nothing in
the spec that confirms or denies it explicitly.]]. This makes the
design of the dataset classes awkwards in a few cases. For example,
the permissions group dataset class needs to define its own version
of the attributes from the presence-auth-list class, which is not
desirable. However, we suspect that the reason ACAP has these
limitations is that it is sufficiently complicated to invalidate the
benefits. Building a multiple-inheritance system when the schema is
unknown to the server, in concert with acl policies that may conflict
across dataset classes, is no small task.
Its inheritance feature, although not a requirement, is very useful
for presence lists and authorization lists. Its pagination features
are also useful for wireless devices. Its acl model also appears more
than adequate, and its ability to work for multiple applications is
consistent with SIP and 3gpp design goals.
Based on this, we conclude that while out-of-the-box ACAP could work,
it has some limitations for wireless in particular which prevent it
from being a complete solution. A few solutions therefore present
themselves:
1. Develop our own protocol, from scratch, defining our own data
model and protocol.
2. Define a new protocol based on ACAP, which retains its data model
and semantics, but provides a different encoding, allows for
intermediaries and additional security mechanisms, and supports a
better notification model. This protocol would share the dataset
class definitions with ACAP, so that ACAP or this protocol could
Rosenberg Expires August 24, 2003 [Page 30]
Internet-Draft ACAP for SIMPLE February 2003
be equivalently used.
3. Standardize the data elements based on the ACAP data model.
Explicitly allow for multiple protocols to use those data
elements. ACAP would qualify, and we could investigate whether
other protocols, such as SyncML, could also work with that data
model.
Since it is our goal for a single protocol mechanism to be possible
for wireline and wireless alike, the second option above appears to
be the best choice. Our specific proposal would be to define
something called SEACAP - SOAP Encoded ACAP. This would define SOAP
operations for all of the transactional methods defined in ACAP,
adding only additional semantics where needed to support a better
notification model. To support notifications, a SIP event package
could be defined. Notifications would be delivered indicating that
data has changed (the data itself wouldn't be carried in SIP), and
then a SEACAP query would be made to obtain the new data. This
mechanism would allow a broader range of security mechanisms, would
unify the syntax with other protocols used in SIP systems
(rfc822-style and XML), it would allow for intermediaries, it would
allow us to define a notification framework that works for wireless
and wireline, and it would facilitate a single protocol solution.
It is therefore our proposal to take this route, and spec out the
SEACAP protocol and the accompanying SIP event package.
Assuming this route is taken, there are still some big issues on how
to use the ACAP data model. The proposal here puts most of the data
within a set of flat ACAP attributes. This feels somewhat awkward,
especially for the various content manipulation and filtering
features. An alternative model is to use the filters exactly as
specified in [20]. Then, the ACAP attributes actually contain those
XML documents. As a result, there would likely be a single attribute
called presence-auth-list.filter which contains that document. The
number of ACAP attributes is much smaller as a result. The benefit of
this approach is that filtering is unified between client
subscriptions and presentity policy. Such a unification is critical.
Both mechanisms must support the same semantics, if not the same
syntax. At the moment, there appears to be some divergence in
capabilities between the two. This must be reconciled.
Rosenberg Expires August 24, 2003 [Page 31]
Internet-Draft ACAP for SIMPLE February 2003
5. IANA Considerations
TODO: Add registration of the ACAP attributes and capabilities.
Rosenberg Expires August 24, 2003 [Page 32]
Internet-Draft ACAP for SIMPLE February 2003
6. Security Considerations
Security issues are discussed above where relevant.
Rosenberg Expires August 24, 2003 [Page 33]
Internet-Draft ACAP for SIMPLE February 2003
7. Acknowledgments
Thanks to Chris Newman for helping with many questions the author had
with ACAP.
Rosenberg Expires August 24, 2003 [Page 34]
Internet-Draft ACAP for SIMPLE February 2003
Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[3] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[7] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[8] 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.
[9] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[10] Rosenberg, J. and B. Campbell, "Instant Message Sessions in
SIMPLE", draft-campbell-simple-im-sessions-00 (work in
progress), October 2002.
[11] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[12] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.
[13] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information",
Rosenberg Expires August 24, 2003 [Page 35]
Internet-Draft ACAP for SIMPLE February 2003
draft-ietf-simple-winfo-format-04 (work in progress), January
2003.
[14] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Collections",
draft-ietf-simple-event-list-00 (work in progress), February
2003.
[15] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
Data Elements in SIMPLE Systems", draft-ietf-simple-data-req-00
(work in progress), October 2002.
[16] Newman, C., "ACAP Personal Addressbook Dataset Class",
draft-ietf-acap-abook-03 (work in progress), November 2002.
[17] Hole, S. and A. Melnikov, "ACAP Authorization Identifier
Datasets Classes", draft-ietf-acap-authid-03 (work in
progress), June 2002.
[18] Crocker, D. and J. Peterson, "Common Profile: Presence",
draft-ietf-impp-pres-01 (work in progress), December 2002.
[19] Fujimoto, S. and H. Sugano, "Common Presence and Instant
Messaging (CPIM)Presence Information Data Format",
draft-ietf-impp-cpim-pidf-07 (work in progress), January 2003.
[20] Khartabil, H., "Event Notification Filtering for Presence",
draft-khartabil-simple-presence-filter-00 (work in progress),
January 2003.
[21] Schulzrinne, H., "RPIDS -- Rich Presence Information Data
Format for Presence Based on the Session Initiation Protocol
(SIP)", draft-schulzrinne-simple-rpids-01 (work in progress),
February 2003.
Author's Address
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Rosenberg Expires August 24, 2003 [Page 36]
Internet-Draft ACAP for SIMPLE February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Rosenberg Expires August 24, 2003 [Page 37]
Internet-Draft ACAP for SIMPLE February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires August 24, 2003 [Page 38]