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]