3.7.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 specification does not mandate that implementations adhere to this model as long as their external behavior is consistent with what is described in this specification.
The client uses the following suggested data structures to facilitate implementation of the contact management extensions:
Contact: A data structure to represent a contact for the user. A contact is uniquely identified by a URI and can have other properties, such as its display name and the groups to which it belongs.
Contact List: A list data structure to store all contacts of the user.
Group: A data structure to represent a group of contacts for the user. A group is uniquely identified by its name. The data structure includes references to the set of contacts that belong to this group.
Group List: A list data structure to store all the groups for the user.
Access Control List (ACL): A list data structure to store the access control entries for the user.
The server can use the preceding suggested data structures to store this data for each user who is assigned to this server.
The server can also have a configurable parameter MaxNumberOfContacts for each user to keep track of the limit for how many contacts a specific user has.
In addition, both the client and the server maintain a single nonnegative integer version number for the contact/group list. The client maintains this version number for the user and the server has the version number as an attribute for each user who subscribes to the server for the contact/group list. Anytime the user performs an operation that modifies his contact/group list, the version number is incremented by 1. The server returns this version number to the client in the contact list. The version number allows the client to determine if it has the most up-to-date information and to refresh the contact/group list if its state, as seen by the server, is out-of-sync.
The client and the server also maintain a separate nonnegative integer version number for the ACL. The client maintains this version number for the user and the server has the version number as an attribute for each user who subscribes to the server for the ACL. Anytime the user performs an operation that modifies their ACL, the version number is incremented by 1. The server returns this version number to the client along with the ACL. The version number allows the client to determine if it has the most up-to-date information and to refresh the ACL if its state, as seen by the server, is out-of-sync.
Note The preceding conceptual data can be implemented by using a variety of techniques. An implementation can implement this data in any way that is convenient.