2.2.1.21 Sync
The Sync command synchronizes changes in a collection between the client and the server.
The AirSync namespace is the primary namespace for this section. Elements referenced in this section that are not defined in the AirSync namespace use the namespace prefixes defined in section 2.2.4.
The following table lists the elements that are used in Sync command requests and responses.
|
Element name |
Scope |
Reference |
|---|---|---|
|
Sync |
Request and Response |
section 2.2.3.180 |
|
Collections |
Request and Response |
section 2.2.3.31.2 |
|
Collection |
Request and Response |
section 2.2.3.29.2 |
|
SyncKey |
Request and Response |
section 2.2.3.181.4 |
|
CollectionId |
Request and Response |
section 2.2.3.30.6 |
|
Supported |
Request |
section 2.2.3.179 |
|
DeletesAsMoves |
Request |
section 2.2.3.43 |
|
GetChanges |
Request |
section 2.2.3.84 |
|
WindowSize |
Request |
section 2.2.3.199 |
|
ConversationMode |
Request |
section 2.2.3.36.2 |
|
Options |
Request |
section 2.2.3.125.6 |
|
FilterType |
Request |
section 2.2.3.68.2 |
|
Class |
Request and Response |
section 2.2.3.27.6 |
|
Conflict |
Request |
section 2.2.3.34 |
|
MIMESupport |
Request |
section 2.2.3.110.3 |
|
MIMETruncation |
Request |
section 2.2.3.111 |
|
MaxItems |
Request |
section 2.2.3.103.2 |
|
Commands |
Request and Response |
section 2.2.3.32 |
|
Change |
Request and Response |
section 2.2.3.24 |
|
ServerId |
Request and Response |
section 2.2.3.166.8 |
|
ApplicationData |
Request and Response |
section 2.2.3.11 |
|
Delete |
Request and Response |
section 2.2.3.42.2 |
|
Add |
Request and Response |
section 2.2.3.7.2 |
|
ClientId |
Request and Response |
section 2.2.3.28.2 |
|
Fetch |
Request and Response |
section 2.2.3.67.2 |
|
Wait |
Request |
section 2.2.3.198 |
|
HeartbeatInterval |
Request |
section 2.2.3.88.2 |
|
Partial |
Request |
section 2.2.3.131 |
|
Status |
Response |
section 2.2.3.177.17 |
|
Limit |
Response |
section 2.2.3.97 |
|
SoftDelete |
Response |
section 2.2.3.172 |
|
Responses |
Response |
section 2.2.3.154 |
|
MoreAvailable |
Response |
section 2.2.3.116 |
|
airsyncbase:InstanceId |
Request and Response |
[MS-ASAIRS] section 2.2.2.25 |
|
airsyncbase:Location |
Request and Response |
[MS-ASAIRS] section 2.2.2.28 |
|
email2:Send |
Request |
[MS-ASEMAIL] section 2.2.2.69 |
The XML schema for the Sync command request is described in section 6.45. The XML schema for the Sync command response is described in section 6.46.
For more details about the AirSyncBase elements that are used by this command, see [MS-ASAIRS] section 2.2.
Synchronization requires a priming of the system; therefore for each collection that the client wishes to synchronize, it MUST issue an initial Sync request by sending a synchronization key of 0 (zero). This request establishes a synchronization relationship with the server and initializes the synchronization state there. The server responds with an initial value of the synchronization key, which the client MUST then use to get the initial set of objects from the server. (From this point forward, client requests MUST include the synchronization key that was received in the last response from the server.) The client then sends a Sync command request to the server with the response synchronization key and includes any changes that were made on the client.
If the client device has not yet synchronized a folder, there SHOULD be no client-side changes. The device MUST synchronize the full contents of a given folder, and then have its changes, additions, and deletions applied.
The response from the server indicates whether the client's changes were accepted, and includes any changes that were made on the server. The server response also contains a synchronization key that is to be used for the next synchronization session for the folder.
This protocol has been optimized for the case in which there are no changes to any of the collections that are specified in the Sync request. In such a case, the client can receive an empty response from the server. After the client receives an empty response, the client can issue an empty Sync request. The server then re-executes the previous request, which it cached.
Certain ActiveSync classes support ghosted properties. A ghosted property whose value has not changed from the last Sync response can be excluded from the request body, and its value on the server will be preserved instead of being deleted. A client uses the Supported element to specify to the server which properties are managed by the client and not ghosted by the server. For more information, see section 2.2.3.179.
The following diagram shows request and response processing by the client.
Figure 2: Sync command client processing
Protocol Versions
The following table specifies the protocol versions that support this command. The client indicates the protocol version being used by setting either the MS-ASProtocolVersion header, as specified in [MS-ASHTTP] section 2.2.1.1.2.6, or the Protocol version field, as specified in [MS-ASHTTP] section 2.2.1.1.1.1, in the request.
|
Protocol version |
Command support |
|---|---|
|
2.5 |
Yes |
|
12.0 |
Yes |
|
12.1 |
Yes |
|
14.0 |
Yes |
|
14.1 |
Yes |
|
16.0 |
Yes |
|
16.1 |
Yes |