Since there is no other protocol that specifically addresses the problem of having multiple personal information managers, the SyncML initiative was founded. It is not surprising that the two vendors of the solutions mentioned before, Palm and Starfish are both founding members of this initiative.
The purpose of this initiative was to create a standard that addresses the synchronization of personal information for one person on multiple devices. The main idea here was the problem of a cell phone and its address books: A phone usually has very small keys and people would much rather like to use a full sized keyboard to type in phone numbers, but want to have them available on the mobile device.
Unlike many other standards, the SyncML protocol by itself is not a complete solution. It needs a transport protocol and a data protocol. The SyncML specification defines encapsulation over HTTP, E-mail, and OBEX, but others are also possible. It even supports different data protocols to be synchronized, such as vCard, vCalender, and iCalender.
On the first impression this may look like a shortcoming - but it is not. It makes the SyncML protocol very extensible. SyncML can be used to synchronize almost every data format.
The SyncML protocol itself is specified as an XML and WBXML application. The XML representation ensures that the protocol is human readable. It also takes care of all 8-bit encoding issues, since these are already specified by the XML specification. The WBXML representation make the protocol small for wireless links, and is thought for mobile devices.
A typical SyncML session consists of 6 data packages that are exchanged between the server and client. Figure 4.4, “SyncML session time line” shows an overview:
Usually a SyncML session is initiated by the client. It might, however, be server initialized. This adds an extra optional first package.
After the transport has established the session, the SyncML protocol takes over, and does its own handshake. This usually includes an exchange of credentials.
Now both machines have to agree with which type of synchronization to continue. The client requests a type and the server confirms this or suggests an other type.
One reason for suggesting a different type of sync is possible inconsistency: During initialization both machines also exchange their last sync anchors. If they differ the server initiates a slow sync as described in the section called “Slow sync”.
Then the client sends its modified data to the server. The server processes this data, merges it with its own, resolves any possible conflicts and sends back its modified data. The client updates its database accordingly.
The client might have assigned new UIDs to its data. Therefore it sends back a mapping table to be stored by the server. At last, the server acknowledges the mappings and the session is terminated.
The SyncML protocol does not specify how conflicts are resolved. But it does specify many messages that can be used in conflict resolution. One example is the slow sync, others are merging, overwriting on client or server, or duplicating. SyncML also addresses the problem of differing UIDs on different machines.
The promises from the SyncML protocol are many. The cell phone companies are pushing it, and its targeted as an industry standard. The only thing missing now are actual working implementations.