On December 7th, 2000, the SyncML consortium, founded by Ericsson, IBM, Lotus, Motorola, Nokia, Palm, Matsushita, Psion and Starfish, released the specifications for version 1.0 of a synchronization protocol based on HTTP and XML. In contrast to its cousin, the WebDAV protocol, the SyncML protocol does not add any new HTTP verbs, but uses the usual HTTP 1.1 verbs like GET and POST. And, similarly to an other cousin, the SOAP protocol, this XML-based protocol uses an XML format to carry its payload.

SyncML's purpose is to allow the synchronization of data. For instance, to synchronize a contact list between local store resident on a palm computer and a network store resident on a corporate server; or to synchronize an event list between a calendar resident on a PC and a calendar resident on a smart mobile phone.

At the dawn of the 21st century, some of us have access to more than one computer:

• a palm computer,
• a desktop computer at home,
• a desktop computer at work,
• a mobile phone, or
• a plain old phone having access to a VoiceXML gateway.

Long gone are the days where a single PC storage device was sufficient to store our data. Now we need to synchronize our data on several devices if we want to get access to it at anytime, anywhere and on any device. If we take a close look at the SyncML consortium founders, we may expect to find SyncML bundled in some of the devices mentioned above in the near future.

Anatomy of the SyncML Protocol

The SyncML protocol sits on top of several transport layers like the usual TCP/IP but on new ones like Bluetooth too. SyncML protocol was designed to work as well with a PC as with mobile phones. Protocol stacks tend to be like Russian dolls. Thus a TCP/IP packet can contain an HTTP message, and an HTTP message may contain a SyncML message.

A SyncML message consists of two parts. You will undoubtedly recognize the pattern:

• a header, and
• a body.

The header is used to convey information about the SyncML message, and it contains metadata. The body section is used to carry the data. So we met again our envelope pattern: header for metadata, body for the data.

<SyncML>
  <SyncHdr>
   <VerDTD>1.0</VerDTD>
   <VerProto>SyncML/1.0</VerProto>
   <SessionID>1</SessionID>
   <MsgID>2</MsgID>
   <Target><LocURI>IMEI:493005100592800</LocURI></Target>
   <Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>
 </SyncHdr>
 <SyncBody>
   <Status>
    <MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
   <TargetRef>http://www.syncml.org/sync-server</TargetRef>
   <SourceRef>IMEI:493005100592800</SourceRef>
   <Data>101</Data> 	<!--Status code for Busy-->
   </Status>
 </SyncBody>
</SyncML>

In the example above, the device sending the SyncML message is a SyncML server identified by the .<source> element. Source is a SyncML server permanently connected to the network and identified by a URI. It synchronizes its content with another device identified by the <target> element. Because the target device is not permanently connected to the network, its location identifier is proprietary. But the <target> element may be set if desired to a URI like, for example, <target>http://www.talvastudio.com/syncML<target>. The header also specifies the DTD version, the SyncML specification version, the session ID and the message ID. (The example message just tells the connected device that it cannot handle the synchronization request because it is busy.)

The repertoire of commands SyncML agents may exchange includes

• <Add> to add data,
• <Alert> to notify the target,
• <Atomic> to inform the originator that a set of commands should be performed with all or nothing semantics,
• <Copy> to copy some data to the target,
• <Delete> to delete some data on the target agent,
• <Exec> to invoke an executable on the target agent,
• <Get> to get some data from the target agent,
• <Map> to allow the originator to ask the recipient to update the identifier mapping between two data collections,
• <Put> to put some data on the target agent's storage,
• <Replace> to replace some data,
• <Search> to perform a query on the target agent,
• <Sequence> to indicate that the commands are to be executed in sequence, and
• <Sync> to allows the originator that the included commands should be treated as part of the Synchronization of two data collections.

To add a vCard on the target agent data base, the source SyncML agent would send

<Add>
    <CmdID>12345</CmdID>
    <Cred>
        <Meta>
            <Type xmlns="syncml:metinf">syncml:auth-md5</Type>
            <Format xmlns="syncml:metinf">b64</Format>
        </Meta>
        <Data>OGNkNDI1ZTZjNjgwMTNiYWZkOWEyN2JjMjNlZDM4YzENCg==</Data>
    </Cred>
    <Meta>
         <Format xmlns="syncml:metinf">chr</Format>
         <Type xmlns="syncml:metinf">text/x-vcard</Type>
     </Meta>
     <Item>
         <Source>
         <LocURI>./2</LocURI>
         </Source>
         <Data>BEGIN:VCARD
          VERSION:2.1
          FN:Bruce Smith
          N:Smith;Bruce
          TEL;WORK;VOICE:+1-919-555-1234
          TEL;WORK;FAX:+1-919-676-9876
          EMAIL;INTERNET:bruce1@host.com
          END:VCARD
          </Data>
     </Item>
</Add>

This <add> command will be contained in a <syncBody> element.

Conclusion

SyncML servers exchange packages of information. To do so, SyncML provides a set of commands that each SyncML agent interprets. SyncML sits on top of several transport protocols, including HTTP and Bluetooth (note: Bluetooth may be used to transport TCP/IP - do you remember the Russian dolls?). The SyncML protocol itself is encoded in XML.

The SyncML consortium provides a toolkit composed of open source modules. These modules, and the SyncML specifications, can be freely downloaded from http://www.syncml.org (look in the download section).

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.