3.8 Enhanced Presence Aggregation Details

The process of aggregation is modeled as a transformation function. The function computes a single value of a category based only on instances of one or more different categories that have previously been published. After this category's value has been computed, it can be published to multiple containers, and it can be subscribed to, in the same way as any other category.

The server can determine which published categories the computed category is dependent on. When any of these dependent categories are published, the server calls the transformation function to recompute the new aggregate category value.

Each container can have a computed aggregate value that is published by the transformation function. The computed value can be different for different containers, but the transformation function that produces a given category value is identical for any specified container. The transformation function is run for each specified container, but these calls can differ only by the input values that each container supplies to the function.

Each container has attributes that indicate whether it computes any categories and if so, what those categories are. That is, a container can specify zero, one, or more computed categories.

The specification of which categories are computed for which containers is not on a per-publisher basis: it is global. If a category called "state" with a particular instance is computed for containers 2 and 3, it is computed for all publishers who have those containers. Protocol clients do not normally publish computed categories to such containers; however, a category that is flagged as being computed in one container can be published in a different container as long as it is not flagged as being computed there either.

One example of this is the state category. State is not computed in the default container so that a persistent default can be published by a SIP protocol client to this container. This value is then given to subscribers if the user is offline and has had no publications to other containers with which to compute the state category value in those containers.

Generally, the input category instances given to the transformation function come from the same container for which the aggregate category is to be computed. All instances of these input categories from the container for which the value is being computed are provided to the transformation function. Thus, the function needs to be prepared to receive not just one value for each input category, but an array of values for each category.

For example, calendar data can be published only to container 40, because members of that container are allowed to see calendar data, whereas members of containers 10 and 20 are not. However, this calendar data implicitly affects the aggregate state values computed for containers 10 and 20. The transformation function that computes these values in containers 10 and 20 needs access to the calendar data from container 40, because the data is not published in the lower-numbered containers.

To summarize, the transformation function receives a table as input. Each row of this table identifies one of the following unique publications:

§ Container number

§ Category name

§ Instance number

§ Last publish time

§ Category data value

For the categories meant for self-consumption subscriptions to them from other users are not allowed. The main purpose for this restriction is to allow endpoints to be able to use enhanced presence as a mechanism to roam data for their own use.

For the categories marked as read-only in containers, the server cannot allow SIP protocol clients to overwrite or delete these categories in those containers. An example of a read-only category is the userProperties category in container 1. This restriction is used for protecting server publications. For details about server publications, see section 3.2.6.2.