[MS-ASCMD]: ActiveSync Command Reference Protocol Specification

Element Scope Reference
ClientId Request and Response section 2.2.3.27.2
Fetch Request and Response section 2.2.3.60.2
Wait Request section 2.2.3.171
HeartbeatInterval Request section 2.2.3.75.2
Partial Request section 2.2.3.112
Status Response section 2.2.3.152.16
Limit Response section 2.2.3.82
SoftDelete Response section 2.2.3.147
Responses Response section 2.2.3.131
MoreAvailable Response section 2.2.3.99
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 always 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.154.
The following diagram shows request and response processing by the client.
[MS-ASCMD] — v20110315
ActiveSync Command Reference Protocol Specification
Copyright © 2011 Microsoft Corporation.
Release: Tuesday, March 15, 2011
82 / 369