| The SyncML Initiative defined the Synchronization Protocol because simply providing DTDs (i.e., the syntax of messages) did not do enough to enable synchronization between devices. First, full end-to-end interoperability cannot be achieved only by defining the DTDs, as they give too much flexibility. Second, several functions, such as the authentication procedure, need to be defined by the Synchronization Protocol so consistent synchronization can really take place. By following the Synchronization Protocol, implementations know which DTD element types they can use and when they can use them. In addition, the protocol adds extra functionality to the SyncML technology through combinations of element types defined by the DTDs. The design of the Synchronization Protocol was based on common synchronization scenarios, or use cases from the end-user point of view. Such common synchronization scenarios include: Relation to the Representation Protocol and Other DTDs The Representation Protocol defines the format of SyncML Messages, is independent of the other SyncML specifications, and can be used for any synchronization scenario. The Synchronization Protocol is completely different. The Synchronization Protocol is dependent on the format and DTD element types of the Representation Protocol. Also, the Synchronization Protocol is targeted at specific synchronization scenarios. The two other DTDs, the Meta Information DTD (the MetInf DTD) and the Device Information DTD (the DevInf DTD) are tools from the Synchronization Protocol point of view. The MetInf DTD is used for complementing the Representation Protocol when creating completely meaningful SyncML Messages. On the other hand, the Synchronization Protocol utilizes the DevInf DTD to provide basic service discovery functionality within the SyncML technology. Although the MetInf DTD and DevInf DTDs can be utilized outside the SyncML technology, the Synchronization Protocol links them closely to it and uses their element types inside the SyncML Message structure. Figure 5-1 depicts the relation of the Synchronization Protocol to the other SyncML components when creating a logical output from a logical input. The input can be either an internal one (e.g., the user interaction) or an external one (e.g. a SyncML Message). Likewise, the logical output can be internal or external. Figure 5-1. Relation of Synchronization Protocol to other components 
Entities Using the Synchronization Protocol The Synchronization Protocol is not symmetrical, although it is close. Because of this, it is useful to carefully watch the roles defined by the Synchronization Protocol. The roles have a strong impact on implementations and on the SyncML features that need to be supported. Figure 5-2 shows that the Synchronization Protocol is used between two entities, a SyncML Client (hereafter, Client) and a SyncML Server (hereafter, Server). The Synchronization Protocol specification calls them Device Roles. Figure 5-2. Entities using Synchronization Protocol 
When two entities are using the Synchronization Protocol, one of them must take the Client role and another the Server role. However, this does not mean that two servers or two devices could not communicate with each other using this protocol. To do so, one has to temporarily take the Client role or the Server role for enabling the communication. The Synchronization Protocol may not be optimized for this kind of synchronization but there are no restrictions that prevent this. The Client role is usually selected for mobile devices such as mobile phones or PDAs. In some situations, the Client role can also be taken by a PC if the PC synchronizes data with a Server. The Client's functionality is much simpler than the Server's because there are fewer features to be supported at the protocol level, as well on the application level. Basically, the Client is responsible for collecting data to be sent to the Server, sending it, receiving data from the Server, and storing it. However, there are no definite requirements for the Client to analyze payload data itself. Payload is the actual data being synchronized, e.g. contact or calendar data. As a result of the simpler mandatory Client functionality, the memory and footprint requirements are kept to a feasible level. This is very important when considering that SyncML is seen in mass volume products, which, due to cost optimization, cannot provide much extra memory or processing power. SyncML technology does allow for extra functionality in more sophisticated Clients, such as PCs or advanced PDAs. The Server role is definitely more complex than the Client one. Naturally, the desired functionality and quality level affects how complicated the Server implementation needs to be. In addition, the desired Server environment has an impact on the implementation complexity. For instance, an Internet Server handling a large number of Clients has a quite different architecture than a PC implementation synchronizing with only one device at a time. Supported Synchronization Scenarios The Synchronization Protocol defines a set of synchronization scenarios to be implemented. They are called Sync Types. The Sync Types are specified to provide different types of synchronization. These Sync Types are described in Table 5-1. Table 5-1. Sync TypesSync Type | Description |
|---|
Two-way sync | A common Sync Type in which the Client and the Server exchange information about modified data in these devices. | Slow sync | A form of two-way sync in which all items are compared with each other. The Client sends all its data from a datastore to the Server and the Server does the sync analysis for this data and the data in the Server to determine the delta between the Client and the Server, which then needs to be communicated to the Client. | One-way sync from Client only | A Sync Type in which only the Client sends its modifications to the Server. | Refresh sync from Client only | A Sync Type in which only the Client sends all its data from a datastore to the Server. From the Client perspective, this is commonly called the export. | One-way sync from Server only | A Sync Type in which only the Client gets all modifications from the Server. | Refresh sync from Server only | A Sync Type in which only the Server sends all its data from a datastore to the Client. This is commonly called the import operation from the Client perspective. | Server alerted sync | A Sync Type in which the Server alerts the Client to perform sync. |
The Sync Types above can be categorized according to the direction in which payload data is sent. There are Sync Types in which payload data is sent in both directions. There are also Sync Types in which payload data transferred only in one direction, either to the Server or to the Client. One of the Sync Types, the Server alerted sync, does not really belong to any of these groups, as it is only a trigger for synchronization. The four separate Sync Type categories are described in Table 5-2. Table 5-2. Sync Type CategoriesCategory | Description | Included Sync Types |
|---|
Bi-directional data transfer | Data transfer from the Client to the Server and vice versa is provided. | Two-way sync, Slow sync | Unidirectional data transfer to Server | The data can be transferred from the Client to the Server only. | One-way sync from Client only, Refresh sync from Client only | Unidirectional data transfer to Client | The data can be transferred from the Server to the Client only. | One-way sync from Server only, Refresh sync from Server only | Trigger, no payload data transfer | The Server can initiate synchronization by triggering the Client. | Server alerted sync |
It is worth noting that the last category (the Trigger) can be used to initiate any of the Sync Types belonging to the other categories. For example, by using the Server alerted sync the Server could send a trigger for the One-way sync from Server only. | 
