3.2.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

An enhanced presence server maintains the following elements of state for each self subscriber:

SelfSubscriptionDialogEntry: Information about an individual self subscription dialog. This information includes the subscriber's URI and the subscribed URI. This entry also holds the self subscription scope, which MUST be any combination of the literal strings "categories", "containers", "subscribers" and "delegates". The SelfSubscriptionDialogEntry is a SIP SUBSCRIBE request, as defined in [RFC3265] section 3.1.

An enhanced presence server maintains the following elements of state for each category subscriber:

CategorySubscriptionDialogEntry: Each category subscriber is represented at the server by a CategorySubscriptionDialogEntry that has a list of publishers that the category subscriber is currently subscribed to. This information includes the subscriber's URI. Each category that is subscribed to has an associated container ID that corresponds to the publisher's container, to which the subscriber has been resolved for this category. This container ID is invalid if the subscriber did not resolve to any container. The CategorySubscriptionDialogEntry element also contains the state required to process a SIP SUBSCRIBE request, as specified in [RFC3265] section 3.1.

An enhanced presence server maintains the following elements of state for each publisher in addition to the publisher URI:

ContainerSet: A set of ContainerEntry, one ContainerEntry for each container that has an published member or a published category instance. Entries are keyed on the ID of the container.

ContainerEntry: Information about an individual container. This information includes the container ID. The entry also holds a set of the container's members and a set of categories that have one or more published instances in that container.

ContainerMemberSet: A set of entries, one for each member that belongs to the container. Entries are keyed on the container ID, the member type, and the member value. The set has an associated version number that is used to synchronize updates from multiple endpoints of the same publisher.

ContainerMemberEntry: Information about a member that belongs to the container. This information includes the container ID, the member type, which MUST be "domain", "everyone", "federated", "publicCloud", "sameEnterprise", or "user", and an optional member value. Members of type "domain" MUST have a value that specifies a domain name, and members of type "user" MUST have a value that specifies a user-URI. The member value MUST be omitted for all other member types.

ContainerCategorySet: A set of entries, one for each category that has a published instance in that container. Entries are keyed on the container ID and category name.

ContainerCategoryEntry: Information about an individual category belonging to the container. This information includes the container ID and the category name. The entry also holds a set of category instances and the related publisher URI. This set of category instances is built from published instances of this category to the container. Each instance has an associated instance number, version number, an expiry type, which MUST be "static", "endpoint", "user", or "time", an optional expiry time, the ID of the publishing endpoint ID, and the published XML data. As always, the version number is used to synchronize updates from multiple endpoints of the same publisher. The version number allows multiple endpoints of the same publisher to synchronize their publications and allows self subscribers to determine whether to accept a notification. The name attribute of the category element in a categories document is compared to a list of the names of agreed-upon schemas.<31>  The agreed-upon schema with an exact matching name is used to interpret the body of the element.