INTRODUCTION

SyncML or Synchronization Markup Language is an XML-based, industry-standard protocol

for synchronizing mobile data across a variety of multiple networks, platforms and devices. It is
a new industry initiative to develop and promote a single, common data synchronization protocol
that can be used industry-wide.
Its aim is to facilitate the synchronization of networked information with various devices running
SyncML-compatible applications. As the first universal synchronization protocol, SyncML
offers true freedom to users of mobile devices by allowing them to send and receive up-to-date
information between their mobile applications and their office or home-based systems regardless
of the platform, manufacturer, or application.
SyncML started as an initiative in mid 2000 by major technology companies such as Ericsson,
IBM, Palm Inc., Lotus, Matsushita Ltd. (Panasonic), Motorola, Nokia, Open wave, Starfish
Software, Psion and Symbian.
Their initiative's goals were to create a universal language from the myriad, proprietary,
synchronization protocols used by mobile devices and provide a complete set of synchronization
functionality for future devices. The consortium released version 1.0 in December 2000. They
then implemented new features and resolved issues with the subsequent version releases,
finalizing the protocol with version 1.1 in February 2002.
SyncML leverages Extensible Markup Language (XML), making SyncML a truly future-proof
platform.
The SyncML protocol is designed with these goals in mind:

As a common language, any device should be able to synchronize with any SyncML service
(a networked data repository).

Any service speaking SyncML should be able to synchronize with any SyncML-capable
device.

The protocol must address the limitations of mobile devices, specifically with respect to
memory storage.
1

It must support a variety of transport protocols such as HTTP, SMTP, Bluetooth and others.

It must deliver common synchronization commands to all devices.

It builds upon existing web technologies, specifically XML.

Support asynchronous communication and error-handling, since the Internet has latency.

SyncML consists of client and server commands enclosed within DTD-defined...

SyncML PROTOCOLS
The SyncML programming framework is based on two protocols: SyncML Representation
protocol and SyncML Synchronization protocol. The SyncML Representation protocol defines
the representation format of SyncML messages (in XML) and details the inner workings of the
SyncML framework.
The SyncML Synchronization protocol defines the actions between a SyncML client and a
SyncML server. In order to build a SyncML-compliant product, you must adhere to the
requirements of these two protocols.
The important components of the SyncML protocol are:
1. Change log
Being a synchronization protocol, SyncML requires that both client and server maintain
information about changes or modifications (i.e., replacement, addition, deletion of data) to the
data in their databases. The mechanism by which this information is tracked is called a change
log. SyncML does not specify the format of the change log; however, upon synchronization each
device must be able to specify the data items that have changed since the previous
synchronization.

2. Map operation
SyncML is based on the principle that the client and the server may each have their own unique
identifiers (IDs) for items in their databases. The client ID is known as a locally unique identifier
(LUID); the server ID is known as a globally unique identifier (GUID). These IDs may or may
not be congruent between client and server.

Because the IDs can be different, the server must maintain an ID mapping table for all items
exchanged between itself and the client. That is, the server must know which client IDs and
which server IDs point to the same data item. LUIDs are always assigned by the client device.
This means that even if the server adds an item to the client device, the client will assign the
LUID for that item. The client will then use the Map operation to send the LUID of the new item
to the server. Following the Map operation, the server will update its mapping table with the
client LUID.

3. Sync anchors
The two sync anchors, Last and Next, are always sent when a synchronization session is
initialized. The Last sync anchor describes the last synchronization event from the point of the
sending device; the Next sync anchor describes the current event of synchronization from the
point of the sending device. In this way, the client and the server send sync anchors to each
other. Upon receiving a Next sync anchor, the receiving device must store it until the next
synchronization. Upon the next synchronization, the receiving device will compare its stored
sync anchors with the sending device's Last sync anchor, to determine whether any failures have
occurred in the sending device's data. If the Last and Next sync anchors match, the receiving
device concludes that no failures have occurred. If they don't match, the device can request an
appropriate action from the other device, such as a slow sync. The stored sync anchor is updated
only when the session has ended successfully.

4. Conflict resolution
A version conflict generally arises when a single data item is modified on both the client and the
server database, resulting in two different versions of the same data. A synchronization protocol
must have a policy for resolving such conflicts. In the SyncML, conflict resolution is a function
of the sync engine. Generally, the SyncML server's sync engine resolves version conflicts; it is
also possible for the SyncML client's engine to provide some of this functionality. The SyncML
Representation Protocol provides both the functionality to notify the SyncML client of a resolved
conflict and the status codes for common resolution policies. If the server's sync engine resolves
a conflict, it will use the status codes and notification functionality to notify the client of the
conflict and define the terms of its resolution.
3

5. Security
SyncML is intended to provide a framework for secure data synchronization. SyncML itself does
not define any new security schemes. Instead, it provides the framework to challenge
authentication and authorization at different layers of the network. SyncML defines a user
authentication mechanism for three different levels of the protocol : the server level, the database
level, and the object level. SyncML mandates only that its authentication mechanism be
supported at the server level. To be compliant with the SyncML protocol, a SyncML client or
server must support both basic and MD5 authentication. Authentication at the database and
object levels is optional.

ADVANTAGES & DISADVANTAGES

ADVANTAGES
It was a good decision to use XML as superset of SyncML, because XML ensures compatibility
with other software applications and libraries. XML is also a human readable format. This would
not have been the case with a binary protocol.
Apart from this, SyncML is a quite well documented, unifying approach to mobile devices
synchronization. Its strategy with freely available specifications may be the key to a future with
painless cross-platform synchronization, because it is not only theoretically a good aproach, but
also backed by many key-players in the mobile device industry.

DISADVANTAGES
Unfortunately, all that glitters is not gold. SyncML is so extensive, that it is hard to understand in
its entirety, not to speak of a complex implementation. It contains too many possibilities where
to place different information, too many and even (deliberate) duplicate operations. It includes
many sub-tasks like meta information, device management, device information - these are surely
important when building complete device management platforms, but complicate matters
needlessly. This leads to the fact that if we wanted to implement a SyncML compatible
application, a lot of developing work had to be done - there is no such thing like a minimal
instance of SyncML.

Another downside may be the fact that Microsoft is not member of the SyncML initiative - Ray
Hegarty wrote in 2001, two years after the SyncML initiative had been launched, ``Microsoft
seems to have finally come off the fence as far as potential support for SyncML is concerned,
saying that the specification is too 'chatty' and relies on too much network bandwidth'' . In other
words, Microsoft will not support SyncML.

This leads to another point: Even when using a binary form of XML (like
WBXML), SyncML uses rather many (too many, in the author's opinion) packets during network
communication. This seems to correlate with the complexity of the protocol.

WHAT DO WE NEED FOR SyncML

SyncML is a protocol based on XML, so we need a XML parser. As wireless devices often have
low-bandwidth network connections, the experts came up with a compressed XML variant called
WBXML (Wireless Binary XML), so we need a parser for that as well.
The content, the actual data sent back and forth with SyncML is formatted as vCal, vCard, vNote
and vTodo items, so we need parsers for those.
Then we need a SyncML server of course, that handles connection, authentication, item ID
mapping.
Last but not least there is the question of synchronization, who 'wins' if items have been modified
on both ends of a connection? So we need some synchronization algorithm.
A short list of what we need
* XML parser
* WBXML decoder/encoder
* vCal, vCard, vNote, vTodo parsers
* SyncML server : Sets up the connection with the client, handles the requests, does the local to
global ID mapping, keeps track of the last sync date for every client and much more.
* Synchronization algorithm

HOW SyncML WORKS

The SyncML representation protocol is defined by a set of well-defined messages (XML
documents or MIME) that are shared between synchronizing devices. It supports data
synchronization models that are based upon a request/response command structure, or those
based upon a "blind push" structure. The SyncML representation protocol specifies what the
result of various synchronization operations should be, based upon a synchronization framework
and format that accommodates different data synchronization models.

SyncML Representation Protocol version 1.0.1

In the above figure, Application A represents a networked service that provides synchronization
with other client applications (Application B). The server and client are connected over any
network transport (HTTP, WSP).

The client uses the Sync Client Agent to access the network and send messages to the server via
the SyncML Adapter and SyncML Interface (SyncML I/F). The server, or Application A,
through the Sync Server Agent, receives or sends messages, and manages the entire sync process
through the Sync Engine. A SyncML I/F is merely an API to the SyncML Adapter.
6

SyncML operations are conceptually bound into a SyncML Package, which is a conceptual
frame for one or more required SyncML messages. A SyncML message is a well-formed XML
document identified by the SyncML root or document element type. The document consists of a
header (SyncHdr element type) and a body (SyncBody element type).
The header specifies routing and versioning information, while the body is a container for one or
more SyncML Commands. The commands are containers for other element types that describe
the specifics of the command, including any synchronization data or meta information.

Incorporated here, too, are features such as SyncML Data Formats (a common set of media types
for commonly accepted information such as calendars and contacts) and SyncML Capabilities
Exchange (in which a SyncML client and server determine what device, user, and application
features each supports) are incorporated.

For example, a mobile phone acts as the SyncML client, and a server acts as the SyncML server.
The SyncML client sends a message to the SyncML server regarding changes to data made on
the client. The server then synchronizes the data within the SyncML messages with data stored
on the server, and returns modifications back to the SyncML client. The SyncML client contains
a sync client agent, and typically has the role of sending modifications first to the server. The
client is typically a mobile phone or PDA, and must also be capable of receiving messages back
from the server.

The SyncML server contains the sync server agent and the sync engine, and usually waits for the
client to initiate synchronization, although the server can initiate synchronizations if unsolicited
commands are supported on the transport protocol level.

TYPES OF SYNCHRONIZATION
SyncML specifies seven different synchronization types, as follows:
1) Two-way sync: Two-way sync is a normal synchronization type in which client and server
exchange information about any modifications to the data each contains. The client always
initiates this exchange by sending a request to the server. The server processes the
synchronization request and the data from the client is compared and unified with the data on the
server. After that, the server sends its modified data to the client device, which is then able to
update its database with the data from the server. Once it has updated its database, the client
sends back the server all the necessary mapping information
2) Slow sync: The slow sync is a form of the two-way synchronization in which all the items in
the client databases are compared with all the items in the server databases on a fieldby- field
basis. A slow sync can be requested if the client and server sync anchors are mismatched or if the
client or server loses its change log information. In practice, the slow sync means that the client
sends all its data to the server and the server does a field by- field analysis, comparing its own
data with that sent by the client. After the sync analysis, the server returns all the modification
information to the client. In turn, the client returns the mapping information for all data items
added by the server.
3) One-way sync from client only: This is a synchronization type in which the client sends its
modifications to the server but the server does not send its modifications back to the client.
4) Refresh sync from client only: Here the client exports all its data from a database to the server.
The server is expected to replace all data in the target database with the data sent by the client.
5) One-way sync from server only: With this, the client gets all modifications from the server but
the client does not send its modifications to the server.
6) Refresh sync from server only: In this scenario the server exports all its data from a database
to the client. The client is expected to replace all data in the target database with the data sent by
the server.

7) Server-alerted sync: Here the server informs the client of the need to initiate a specific type of
synchronization with the server.

SYNCHRONIZATION PROCEDURE
With this basic understanding of SyncML, we can begin to talk in detail about what happens
between a SyncML client and the server during a synchronization procedure. Because two way
synching is the most common synchronization procedure, we'll use that procedure as our
example.
A two-way synchronization procedure can be broken out into the following broad steps:
1) Sync initialization
2) Two-way synchronization
3) Data mapping
Sync initialization
No synchronization procedure can occur until the client and server have exchanged initialization
packages. In an initialization procedure, the server and client devices generally exchange the
following information:
Service and device capabilities Requested databases access, type of sync desired Authentication
information Sync anchors are also exchanged as a part of the initialization procedure.

Above Figure illustrates the basic steps of a SyncML initialization procedure.

Upon initialization, the client sends the server an initialization package (Pkg #1). With this
package, it must inform the server which databases it wants to synchronize with and which types
of synchronization it desires (e.g., two-way sync, slow sync, etc.). The client indicates the
databases it wants to synchronize with by using a series of alert commands. Alert commands are
specifically used to convey notifications and requests. So, for example, a mobile device would
use an alert command to request a "client-initiated, two-way synchronization" with a network
server.
For each database the client wants to synchronize with, it must send a separate alert command. It
is optional for the client to send its authentication information in the first package of the
initialization. If the client does not send this information with the first initialization package, the
server will initiate an authentication procedure by sending the client a challenge command. At
that point the client must be able to provide authentication information.
When the server has received the first initialization package from the client, it completes the
initialization phase by sending its own initialization package (or status update) to the client (Pkg
#2).
To prepare this package, the server checks the status of all the databases the client wants to
synchronize with, compares the device capabilities of the client with its own, and matches the
sync anchors for their respective databases. It then sends the client an initialization package that
includes the alert and related status elements for each database the client wants to synchronize
with. To complete the sync initialization, the client must respond to the commands (e.g., Alert,
Put, and Get) sent by the server. The status elements and result element associated with each
alert command can be returned in the first package of the actual synchronization (Pkg #3).

Two-way synchronization
Two-way synchronization is a normal synchronization type in which the client and the server
exchange modifications to the data each contains. The client always initiates this exchange by
sending its data modifications to the server. This is called a synchronization request. The server
processes the synchronization request, comparing and unifying the data from the client with the
10

data in its databases. After that, the server sends its modified data to the client, which is then able
to update its database with the data from the server.
Figure below illustrates the basic steps of two-way synchronization.

The client always initiates a two-way sync, by sending its modifications to the server (Pkg #3).
The client uses internal change log information to determine all the modifications that have
occurred in its databases since the last synchronization.
You will recall that modifications include the addition of new entities, deletion of previous
entities, or updates to existing entities. Each change type is sent to the server using a different
SyncML command. For example, all additions are sent using the Add command and all deletions
are sent using the Delete command.

On receiving the sync package from the client, the server processes the commands sent by the
client, incorporating all the modifications into its databases. The server is responsible for
handling any version conflicts that may arise in this process. The server then builds a status
report consisting of all the commands sent by the client combined with its own data
modifications and sends its synchronization package to the client (Pkg 4).

11

Data mapping
Upon receiving the synchronization package from the server, the client processes all the
commands. It then creates a data status update to inform the server of the results of the data
update on the client side (Pkg #5). This status update will include a set of map operations, which
allow the server to match up all the LUIDs and GUIDs in its mapping table. The update package
may not be sent if the server has indicated that it does not require a response to its last package.
If the client does not send the update, it must cache the Map operations until the next
synchronization.

12

CONCLUSION
SyncML, launched in February 2000, marked the coming together of industry leaders (Ericsson,
IBM, Motorola, and Nokia, among others) to resolve the synchronization problem. With the
February 2002 release of the SyncML version 1.1 specification, we have our chance to begin
working in earnest with what already promises to be a groundbreaking protocol. SyncML is an
ideal choice for mobile computing, freeing up memory for other applications. In the first half of
2002 first devices equipped with SyncML have reached the market, (e.g. Nokia Communicator
9210 or mobiles from Ericsson like T39m, T68,R520m and T65)).
Nokia was the first company in the world to introduce SyncML-enabled products. SyncML an
open industry specification for data synchronization is designed to meet the needs of the mobile
user and there any-device, any-network synchronization needs. With SyncML, networked
information can be synchronized with any mobile device, and mobile information can be
synchronized with any networked applications. SyncML is not limited to mobile phone users - it
also enables synchronization over other transmission channels such as fixed networks, infrared,
cable, or Bluetooth. In fact, SyncML will even allow users to synchronize information stored on
compatible Web-based applications.

13

REFERENCES
1. Synchronizing and Managing Your Mobile Data book by Riku M. Mettala, Peter Thompson
2. Project thesis on SyncML by Peter Czech at springme.com
3. http://en.wikibooks.org/wiki/XML_Managing_Data_Exchange/SyncML#SyncML_ specifica.

14