3.6.3 Initialization

When the ECS client is started, it MUST do the following:

The client MUST set FileMetadataTable to empty.

The client MUST initialize Client_ID with an administratively configured GUID.

The client MUST initialize SyncClientVersion in an implementation-specific<13> manner.

The client MUST initialize GlobalSyncURI based on local configuration.

The client MUST initialize SyncTargetHostList to empty.

The client MUST initialize HostURLPrefix to GlobalSyncURI.

The client MUST use secure HTTP as the transport.

The client MUST set ContinueToken to empty.

The client MUST then synchronize with the data on the server by performing the following steps:

Server Discovery:

The client MUST send a GET request on Server Discovery resource, as specified in section 3.1.5.1, using GlobalSyncURI as the URI.

If the server responds with a status of 200, the client MUST set SyncTargetHostList to the ServerUrls entry that the server returned in the response body.

Share Discovery:

For each host URL Prefix in the SyncTargetHostList:

The client MUST attempt to send a GET request on Share Discovery resource, as specified in section 3.1.5.2.1, using the format "<host-url-prefix>/ Sync/ClientSyncVersion/Discover/Share".

If the server responds with a status of 200, the client MUST store the PartnershipId entry from the response body as SyncTargetPartnershipId. The client MUST set HostURLPrefix to the URL prefix of the server that returned a status code of 200 and skip the remaining entries in the SyncTargetHostList for share discovery. The EnterpriseId identifier from the response signifies the owning entity for all content synchronized with the share. The client SHOULD choose a local storage method that satisfies the requirements of the owning entity as dictated by its policies. These can include encryption, integrity, storage location, and the storage retention policy. The client MUST set Share.EnterpriseId to the EnterpriseId value that is received in the response.

If the server responds with a status code other than 200, the client MUST move to the next entry in the SyncTargetHostList and attempt the share discovery. The server MUST repeat this process until it gets a success response (200) or all the entries in the SyncTargetHostList are exhausted. If all the entries in SyncTargetHostList get exhausted before the client gets a success response, the client MUST wait for an implementation-specific period of time and retry the Server Discovery and Share Discovery steps mentioned earlier.

The client MUST set SyncChangesURL to "HostURLPrefix/Sync/SyncClientVersion/Changes".

Server Capabilities:

The client MUST send a GET request on the Server Capabilities resource, as specified in section 3.1.5.3.1, using the URI format "HostURLPrefix/Sync/ClientSyncVersion/Capabilities".

The client SHOULD<14> check for x-ecs-server-os-version and x-ecs-server-rootdns-name headers in the response.

  • If the x-ecs-server-os-version header is present, the value MUST be returned to the application, otherwise an empty value is returned to the application.

  • If the x-ecs-server-rootdns-name header is present, the value MUST be returned to the application, otherwise an empty value is returned to the application.

If the server responds with a status of 200, the client MUST store the entries in the response body as follows:

  • SyncServerDataTransferType is set to ProtocolType in the response body

Obtain User Configuration:

The client MUST send a GET request on the User Configuration resource, as specified in section 3.3.5.1.1, by using the URI format "HostURLPrefix/Sync/SyncClientVersion/UserConfiguration"

If the server responds with a status code of 200, the client MUST store the entries in the response body as follows:

  • UserUsage member of QuotaUsage entry is set to UserDataUsed.

  • UserDataFreeSpace member of QuotaUsage entry is set to UserDataFree.

Poll for Server Changes:

The client MUST poll for the server changes by sending a HEAD request on the Detect Server Changes resource, as specified in section 3.2.5.1.1, using the URI format SyncChangesURL.

If the server responds with a status code of 200 and the x-ecs-changes-URL header is present, the client MUST set SyncChangesURL to the value in x-ecs-changes-URL header. The client MUST poll for the server changes by sending a HEAD request using the new SyncChangesURL.

If the server responds with a status code of 200 and the x-ecs-changes-URL header is not present, the client MUST initiate the file download process as outlined in section 3.6.5.2. Once the download process is completed, the client MUST continue to poll for the server changes by issuing a new request using the ETag returned by the server in the previous response as the If-None-Match header in the new request.

If the server responds with a status code of 304, the client SHOULD<15> wait for an implementation-specific period of time and reissue the same request.

If the server responds with a status code of 408 or the client HTTP request times out within implementation-specific timeout, the client SHOULD<16> then wait for an implementation-specific period of time to reissue the same request.

If the server does not respond within an implementation-specific timeout<17>, the client MUST reissue the same request.