| The Synchronization Protocol consists of distinct logical phases or handshakes. The phases together comprise a complete synchronization session. If the Client initiates a synchronization session, the first phase is the Initialization phase. This phase is also introduced as a common beginning stage for all Sync Types in the Synchronization Protocol. The second phase, the Data Exchange phase, is dedicated to transferring modifications between a Client and a Server. The direction of the transfer is dependent on the Sync Type used. The last phase during a SyncML synchronization session, called the Completion phase, is needed to finalize the synchronization session. The Server alerted Sync Type can occur prior to the Initialization phase and it can also be categorized as a fourth phase. As explained earlier, it is a trigger for other Sync Types from the Server side. This phase is optional and it is only run when the Server initiates a synchronization session. The Synchronization Protocol specifies numbered Packages that are associated with different phases. Figure 5-3 depicts a SyncML synchronization session between the Client and the Server in the form of a Package sequence chart. Figure 5-3. Numbered Packages in a SyncML Session 
One SyncML Package can include multiple SyncML Messages. Due to this, a Package with a lower number may not be completely sent before a Package with a higher number is received. However, the Synchronization Protocol defines which commands can be sent in a later Package before the previous Package has been completely received. Thus, it is not a problem that a Package can include multiple Messages. Due to the existence of the phases and the requirement for sequencing them, the Synchronization Protocol can be modeled as a state machine. Naturally, this also means that the implementations utilizing this Protocol cannot really be stateless either in the Client or the Server end. Initialization The Initialization phase is mandatory for any synchronization. Vital functions are performed during Initialization. These functions include: Authentication between the Client and the Server Exchange of the device and service capabilities Indication of synchronized content and the Sync Type Conformity check of a previous synchronization session
The Initialization phase is analogous to the logon procedure to a server or a service. It may simultaneously occur with the Data Exchange phase if desired by the SyncML Client. In practice, most implementations do the Initialization phase separately from the Data Exchange phase. Authentication Authentication between the Client and the Server can be bidirectional. The Client can authenticate itself to the Server and vice versa. SyncML does not mandate bidirectional authentication and allows one party to waive authentication of the other party. Typically, only the Client authenticates itself to the Server, unless it is using the Server alerted Sync Type. If the Client does not automatically authenticate itself, the Server usually challenges the Client to do so. If the Client does not authenticate, and the Server requires authentication, then synchronization is not continued. The SyncML authentication procedure is well defined in the Synchronization Protocol specification, but there are a few critical issues which developers should be aware of when implementing SyncML: Session- or message-based authentication MD5 digest authentication and handling nonce First synchronization between the Client and the Server
It is worth noting that authentication can be accepted for an entire SyncML session or only to authorize a given SyncML Message. In the first case, the authentication takes place once in the Initialization phase. In the latter case, it is done for each Message. In general, since the Server requires authentication of the Client, the Server has the power to decide which scheme is selected. Both schemes have different characteristics, as well as benefits and drawbacks. Every implementation needs to make a decision as to which one is utilized. A positive characteristic associated with the message-based authentication scheme is a higher security level in general. In the case of Basic authentication, the message-based authentication scheme can reveal the password if SyncML is used over a nonencrypted transport. Also, the message-based authentication scheme can offer benefits if the communication is routed to a different Server in the middle of a synchronization session. A benefit of using the session-based authentication scheme is more optimized bandwidth consumption, as less data needs to be transferred. In addition, session-based authentication decreases processing requirements, as the authentication is only done once. When utilizing the MD5 digest authentication, a nonce[1] is transferred between a Client and a Server, which is not the case in Basic authentication. The nonce is typically saved for the next session, but this does not have to be the case, and implementations should be aware of that. If it is not stored for the next SyncML session, the implementations challenging for the MD5 digest authentication need to be prepared to send the nonce again at the beginning of the following SyncML session. This applies whether the authentication scheme is message-based or session-based. [1] A nonce is a uniquely generated data string that creates a digest value when responding to the challenge of an MD5 digest authentication.
When doing the first synchronization between a Client and a Server, the credentials based on the Basic authentication should not be sent in the first Message. The reason is that neither the Client nor the Server can know which authentication procedure, Basic or MD5 digest authentication, is desired by the Server or the Client, respectively. Sending the credentials based on the Basic authentication in the first Message causes a risk that the security benefit gained by later using the MD5 digest authentication will be lost, as the credentials have already been revealed in the first Message. Actually, when doing the first synchronization between a Client and a Server, the Client should not send any credentials to the Server at all in the first Message. The Client should await the authentication challenge in the Server's response to the first Message. After that, the Client knows which authentication type it needs to use with the Server. The same behavior applies to the Server. Exchange of Device Capabilities The purpose of exchanging device capabilities is to inform synchronizing entities about characteristics related to the software and hardware of the entities, as well as services offered by these entities. In principle, this information helps the entities ascertain what they can synchronize with each other and how they can synchronize. In other words, the exchange of device capabilities is similar to a service discovery mechanism. For example, the entities can find out the following characteristics related to a device or a service: The manufacturer, model, and version The supported applications (e.g. a calendar application) The datastore addresses and data formats (e.g. vCalendar) associated with the supported application The supported Sync Types (e.g. Two-way sync)
The exchange of device and service capabilities is especially crucial to the Server. That is, the Server needs the device capabilities of a Client in order to offer a high-quality synchronization service to the Client. This way, the service can be operational and customized according to the Client capabilities. For the Client, the device capabilities of the Server may not be so vital, because many embedded devices are not able to process that information. However, there are also Client products that do require the device capabilities from the Server. The details of the device and service capabilities are considered in Chapter 7. At the Protocol level, the exchange of device capabilities is accomplished by using the Get and Put operations as defined by the Representation Protocol. This means that a Client or a Server can send its own device capabilities and request the capabilities of the other entity. The device capabilities are encoded as defined in the Device Information DTD specification. Indication of Synchronized Content and Sync Type When synchronizing data between a Client and a Server, it is also important to know which datastores are to be synchronized. This information is exchanged during the Initialization phase. The datastores are indicated by specifying Uniform Resource Identifiers (URIs) for datastores. Similarly, there is also a need to exchange information on how data is synchronized. This is done by indicating the Sync Type. To specify all this information, the Alert command defined by the Representation Protocol is exchanged between a Client and a Server. Within an Alert command, the datastore URI and Sync Type are indicated. Figure 5-4 shows an example of an Alert command used in the Initialization Package from a Client to a Server. The figure shows how a Sync Type and the URIs are specified within an Alert command. Figure 5-4. Example of Alert command in Initialization[1] 
[1] The XML encoding is used in the example to make it more readable. Different encodings are discussed in the following chapters.
Conformity check of previous synchronization In the Initialization phase, the Client and the Server are also able to check that they agree on a marker that indicates when they last synchronized. In other words, the Client and the Server can ensure that they have a common understanding of when the previous synchronization took place. The marker can be a timestamp or a sequence number. Comparing the markers enables an entity to detect if something has failed after the previous synchronization time. The reasons for failure may be various. For example, the devices may never have been synchronized with each other, the device may have completely been reset after a previous synchronization time, or a previous synchronization may have failed in the middle of the process. The last case should not usually cause a failure in the conformity check but might do so if an implementation is not well designed. The Synchronization Protocol uses the sync anchors of datastores to enable a conformity check. In other words, the sync anchors are the markers. They are specified within an Alert command as depicted in Figure 5-4. A receiving entity needs to be able to store the anchor called Next such that the conformity check can be processed during the following synchronization session. The Server implementations are required to do this, but it is optional for the Client implementations, because it is assumed that the Server implementations are more robust. Naturally, there has to be a way to recover if the conformity check fails. A Server usually initiates a Slow sync with a Client to recover from this situation. This can cause a lot of data to be exchanged, and synchronization can take a long time. This kind of situation should be avoided if possible. Wireless connections can often be interrupted unpredictably. Consequently, synchronization sessions will also often fail, as the normal end of the session will not be accomplished. Due to this, the timing of updating the sync anchors is essential. Having the update at the very end of a synchronization session can dramatically help to avoid unnecessary slow syncs. Example of Sync Anchor Usage. Figure 5-5 depicts an example of Sync Anchor usage on the Server side. The Client sends the anchors to the Server and the Server stores and analyzes them. In this example, a Client and a Server synchronize twice with each other (Session #1 and Session #2). After Session #1 the persistent memory of the Client is reset. As a result, at the beginning of Session #2, the last sync anchor of the Client does not match the stored sync anchor of the Server. The Server detects this, and sends a slow synchronization alert to the Client. Typically, a Client will begin a slow synchronization with the Server upon receiving this alert. Figure 5-5. Example of Sync Anchor usage 
In this example, Session #1 was started on 07/06/2002 at 08:09 AM. The previous successful session with the Server was started on 07/06/2002 at 03:04 AM. At this synchronization, slow synchronization is not initiated because the last sync anchor sent by the Client matches the last sync anchor that the Server had stored for this Client. Session #2 was started on 07/07/2002 at 01:02 AM. Due to a memory reset between Session #1 and Session #2, the last Sync Anchor is empty. The last sync anchor sent by the Client does not match with the last sync anchor stored by the Server (07/06/2002 at 08:09 AM). The Server therefore alerts the Client to initiate a slow synchronization. Data Exchange The primary goal of the Data Exchange phase is to provide an interaction for transferring all modifications that have happened since a previous synchronization. The modifications can include payload data i.e., data to be synchronized. An Add operation is one type of modification for which payload data needs to be included. It is not always necessary to transfer any payload data in order to exchange a modification between synchronizing entities. A Delete command represents this type of modification. The direction in which modifications are sent is dependent on which Sync Type is being used. In addition to that, the direction is also dependent on whether any modifications have been done to the entities involved since the last synchronization. This means that although a Two-way Sync Type is utilized, modifications will not be sent from an entity to another if there were no modifications since the previous synchronization time. Sometimes, when transferring modifications from a Client to a Server, not all modifications including payload data can be sent in a single SyncML Message. Instead, a SyncML Package includes multiple SyncML Messages. In the case of sending Client modifications, the Server waits until the Client has sent all modifications before the Server starts to send any of its modifications to the Client. This way, the Server has the potential to detect all possible conflicts. A conflict means here that the same data item has been modified in both the Server and the Client since the previous synchronization time. Completion The Completion phase is designed to end a session properly and ensure that the synchronizing entities have received all the information they will need to synchronize with each other again later on. The main functions of the Completion phase are the following: The Client reports how it has succeeded in processing the modifications from the Server. The Client sends the ID mapping information for all added items back to the Server. The Server informs the Client that it has completed everything.
It is mandatory to support the Completion phase, although this phase might not always take place. A synchronization session can be either completed after Package #4 or Package #6. If the Server does not sent any modifications to the Client and it indicates that it does not require a status report as a response to Package #4, then the session is ended after Package #4. When synchronization includes the transfer of modifications from the Server to the Client, the Client needs to respond to the modifications by sending status information back to the Server. The Server can explicitly waive this by informing the Client that it does not want to get the responses to these modifications. This status information is included in Package #5. In Package #5, the possible identifier mapping information is also included. The mapping information is needed if the Server has used one or more Add operations. The need for the mapping operation is based on the fact that Clients and Servers commonly use different identifiers for the data items. By sending the mapping information to the Server, the Client ensures that the Server knows which identifier(s) the Client uses for the data item(s) added by the Server. By knowing this, the Server can use the Client IDs when addressing items on the Client. After sending all the mapping information to the Server, the Client waits to receive the final acknowledgment from the Server. The acknowledgement is delivered by sending the status information for the mapping operations. This status information is included in Package #6. After receiving Package #6, the Client knows that the synchronization session is over. For the Server, the definition of the very end of a session is more difficult because the Server sends the last Package. Thus, the Server cannot be sure on the SyncML level whether the Client has received the last Package or not. However, some lower-layer transport protocols provide capabilities that can offer the ability to check whether the data transfer has been completed successfully. If this kind of functionality is available, the Server can use this information and update the sync anchors when the data transfer has completed successfully. If this kind of functionality is not available, the Server needs to update the sync anchors after sending the last Package to the Client. Server Alert The Server Alert phase cannot really be called a handshake, because only one Package is sent from a Server to a Client. However, the status information related to this Package and the commands inside is sent in Package #1. Thus, this phase can also be thought of as a preinitialization. The main purpose of the Server Alert phase is to indicate to the Client that it should start to synchronize with the Server. The details of the Server Alert phase are very similar to the Initialization phase. The Server Alert serves the following purposes: These functions are also present in the Initialization phase. However, the exchange of device capabilities and the conformity check of a previous synchronization session are not done as part of the Server Alert phase. Authentication is relevant in the Server Alert phase because the general statement that only the Client usually authenticates itself to the Server is not necessarily true here. In this case, the server authentication should prevent a solicitation to synchronize with a hostile Server. An example of the hostile Server could be a Spying Server, which attempts to get all confidential calendar information from a confidential Client. The Spying Server could initiate a synchronization session for calendar data. If the Client did not require any authentication from the Spying Server, the Server could easily download all the information from the Client. As a result, the Client would not be so secure or confidential. To summarize, the Client implementations supporting the Server alerted sync should carefully consider whether to accept the alert from a Server without credentials. At the very least, some sort of user acceptance should be involved if no server authentication is implemented or desired at the Client end. The second main function of the Server Alert phase is to indicate which kind of data (i.e. content) is synchronized and which Sync Type is to be used for that data. This function is similar to the procedure done in the Initialization phase when the Client indicates this type of information to the Server. | 
