Share via

3.3.5.2.1 Client-Assigned Internal Identifiers

  • Article

When using this most preferred approach, clients MUST send a request to a server to allocate a range of internal identifiers for their exclusive use by using RopGetLocalReplicaIds ROP. Once the range is allocated, a client can stay offline and use identifiers from that range until the range is exhausted, at which point the client would have to allocate a new range by connecting to the server and executing the RopGetLocalReplicaIds ROP before being able to assign new client-assigned internal identifiers. Clients can then assign these IDs to any new folders or messages within their local replica and communicate these assignments back when performing ICS upload by using the RopSynchronizationImportHierarchyChange ROP (section 2.2.3.2.4.3) or the RopSynchronizationImportMessageChange ROP (section 2.2.3.2.4.2). Note that these IDs MUST NOT be used for change numbers as it would result in change numbers that did not increase per namespace replica, or clients having different ranges from the same namespace, leading to undefined server behavior.

Clients MUST generate foreign identifiers to identify changes to objects in the local replica, as specified in section 3.3.5.2.3.

This mechanism is being serviced by two ROPs, RopGetLocalReplicaIds (section 2.2.3.2.4.7) and RopSetLocalReplicaMidsetDeleted (section 2.2.3.2.4.8).

To help compression of IDSET structures and to alleviate fragmentation of the deleted item list, if a server maintains an IDSET for a folder, clients SHOULD assign consecutive IDs from the allocated range to messages within the same folder. This can be achieved by allocating a contiguous subset of allocated IDs to each folder.

Clients MUST report IDs assigned to objects in a client replica that were deleted without ever being uploaded through the RopSynchronizationImportDeletes ROP.

Clients MUST report ranges of server-allocated IDs, which will never be used for any messages in a folder, through the RopSetLocalReplicaMidsetDeleted ROP. For more details, see section 3.3.5.8.13.