Share via

3.3.5.5 Determining the Synchronization Scope

  • Article

To be able to perform an ICS download of mailbox data, a client MUST subdivide all necessary synchronization work into smaller pieces, which clearly define boundaries of synchronization operations in the terms supported by the ICS protocol (see the RopSynchronizationConfigure ROP, as specified in section 2.2.3.2.1.1). Synchronization scope is determined by using the following variables:

  • Synchronization type (Hierarchy or Contents), as indicated by the SynchronizationType enumeration of the RopSynchronizationConfigure ROP request buffer.

  • Folder within the mailbox, as indicated by the InputServerObject field of the RopSynchronizationConfigure ROP request.

  • Restrictions on messages within the folder that are included in the scope (for content synchronization operations only), as indicated by the RestrictionData field of the RopSynchronizationConfigure ROP request.

Synchronization for each of the scopes can be performed independently. For each synchronization scope, a client MUST persist the corresponding ICS state and pass it along when configuring a synchronization operation, as specified in section 2.2.3. ICS state does not reflect the synchronization scope it belongs to. Therefore, a client MUST ensure that the ICS state it passes to a server corresponds to the synchronization scope that it was originally obtained for.

Examples of synchronization scopes include the following:

  • Folder hierarchy that starts with folder X

  • All contents of folder Z

  • All unread messages in folder Y that were received within the last three days

Note that the set of messaging objects that are considered for ICS operation can be further limited with flags, such as Normal or FAI set in the SynchronizationFlags field of the RopSynchronizationConfigure ROP. However, these flags do not modify the synchronization scope; they just filter the output produced by an operation.

For example, consider the following ICS operation:

  • IcsDownload(icsStateX, Normal | FAI) => (diffNormal diffFAI, icsStateZ)

This operation outputs differences for all the messages in a folder. Compare it with the following sequence of ICS operations:

  1. IcsDownload(icsStateX, Normal) => (diffNormal, icsStateY)

  2. IcsDownload(icsStateY, FAI) => (diffFAI, icsStateZ)

This sequence is correct and it produces the same result as the previous single step operation.

The following sequence, however, is incorrect, because it uses a different synchronization scope (by supplying a different value for the restriction field) for the same ICS state:

  1. IcsDownload(icsStateX, Normal | FAI, {PidTagAssociated (section 2.2.1.5) equals FALSE})

    => (diff1, icsStateA)

  2. IcsDownload(icsStateA, Normal | FAI, {PidTagAssociated equals TRUE})

    => (diff2, icsStateB)

As a result, this sequence does not yield the same result:

  • diff1 contains soft deletion notifications for any previously downloaded messaging objects mentioned in icsStateX. The MetaTagIdsetGiven property (section 2.2.1.1.1), which does not have a PidTagAssociated property value equals FALSE.

  • diff2 contains soft deletions for all messaging objects mentioned in icsStateA.MetaTagIdsetGiven.

  • icsStateB.MetaTagIdsetGiven only contains IDs of FAI messages.