SyncML v1.0 Released SyncML, the initiative founded in Feb 2000 by mobile technology industry leaders Ericsson, IBM, Lotus, Motorola, Nokia, Psion, Palm, Inc. and Starfish Software, has released its first specification and reference toolkit. Download White Paper on SyncML (PDF format) The scope of the SyncML initiative is to define a synchronization standard for all kinds of mobile devices such as PDAs, portable PCs, Communicators, Pagers and Mobile Phones. There are now some 500 members, with such leading companies as America Online, Bell Labs Lucent Technologies, Cisco Systems, Intel, Samsung, Siemens, Sun Microsystems and Yahoo! joining the already blue-chip list of founders to become initiative supporters.  SyncML compliant products will be able to exchange information seamlessly across a wide range of operating platforms and communications technologies. SyncML remote synchronization enables users to quickly and smoothly update and synchronize any kind of application, such as e-mail, calendar and to-do-lists, wherever they are using their mobile mobiles.

The  3GPP  TS  27.103  is  the  first  global  standard  for  remote synchronization specialized for mobile phones. 

Architecture

Outline of the specification
The goal of a common synchronization protocol is symmetric. It would connect any to any, over any network. That is, it would:

• Synchronize networked data with any mobile device
  
• Synchronize a mobile device with any networked data

The data synchronization protocol would synchronize networked data with many different devices, including handheld computers, mobile phones, automotive computers, and desktop PCs. A user could access and manipulate the same set of data from different devices. For example, a user could read e-mail from either a handheld or a mobile phone, and still maintain a consistent, updated record of which messages had been read.

Similarly, with any-to-any synchronization, mobile devices could support more types of data, including e-mail, calendar, contact management information, enterprise data stored in databases, and documents on the web. With such functionality a user who received an order via e-mail could access the company inventory system on the same device to determine a delivery date.

To accomplish this goal, the protocol needs the following characteristics:

• Operate effectively over wireless and wireline networks
  
  
• Support a variety of transport protocols
  
  
• Support arbitrary networked data
  
  
• Enable data access from a variety of applications
  
  
• Address the resource limitations of the mobile device
  
  
• Build upon existing Internet and Web technologies
  
  
• The protocol's minimal function needs to deliver the most commonly required
  synchronization capability across the entire range of devices.
  

Effective Over Wireless and Wireline Networks

A common synchronization protocol must work over all networks used by mobile devices, both wireless and wireline. The various wireless networks commonly used by mobile devices demand the most from a protocol, since these wireless networks share common features of high network latency, limited bandwidth, relatively high packet costs, and low reliability of both data and connectivity.

• High network latency - Network latency is the delay introduced when a packet is momentarily stored, analyzed and then forwarded. Wireless networks, with a high latency, require a robust synchronization protocol.
  
  
• Limited bandwidth - To minimize bandwidth requirements and the associated pro-cessing demands, the protocol should allow alternate binary encoding techniques to both the data and the synchronization commands. The WBXML (WAP Binary XML) standard adopted by the WAP Forum and submitted to the W3C represents a good candidate encoding technique for limited bandwidth environments.
  
  
• Relatively high packet costs - The protocol must minimize the number of request-response interactions between the device and the networked data. An optimal protocol would generate a single request-response pair of messages. In this model, a request from a mobile device would contain all updates to its local data. The response message would provide the updates, with conflicts already identified and possibly resolved. Any protocol adopted by the industry should seek to enable this minimalist messaging model.
  
  
• Low reliability of both data and connectivity - In order to function with only intermittent connection to the network, the protocol must survive inadvertent disconnection during the synchronization procedure. Even when a disconnection is encountered, the protocol must ensure that the device and the networked data repository stay consistent and make progress when the connection is reestablished.

Support Various Transport Protocols and Media

Since wireless networks employ different transport protocols and media, a protocol must work smoothly and efficiently over:

• HTTP 1 (i.e. the Internet)
  
  
• WSP (the Wireless Session Protocol, part of the WAP protocol suite)
  
  
• OBEX (i.e. Bluetooth, IrDA, and other local connectivity)
  It can also be deployed over: ¥ SMTP, POP3, and IMAP
  
  
• Pure TCP/IP networks
  
  
• Proprietary wireless communication protocols

An effective synchronization protocol cannot depend on any capabilities that cannot be made available over these transports. To be efficient, the protocol should minimize duplicating features provided by the transport.

A reliable request-response model can be efficiently deployed across all of these trans-port protocols. An effective protocol could be built on this model. Moreover, defining a MIME (Multi-Purpose Internet Mail Extensions) content-type for the protocol units will allow the protocol to be transported across any of these different transports. Optional enhancements to the transport protocol should include security and compres-sion capabilities.



Support Arbitrary Networked Data

Since a design goal is for mobile devices to communicate with a broad range of networ-ked data, the protocol must support concurrent synchronization with multiple network data repositories. The protocol should not mandate how data is represented or structu-red on the device or within the networked data repository after synchronization is com-plete.

To ensure interoperability, the protocol must describe how common data formats are represented over the network. To ensure extensibility, the protocol should permit the definition of new data formats as needs arise. In addition, the protocol must allow implementers to define experimental, non-standard synchronization protocol primitives.

The common data formats that a protocol must support from the outset include:

• Common personal data formats, such as vCard for contact information, vCalendar
  and iCalendar for calendar, todo, and journal information
  
  
• Collaborative objects such as e-mail and network news
  
  
• Relational data
  
  
• XML (the Extensible Markup Language) and HTML documents
  
  
• Binary data, binary large objects, or "blobs"

Enable Data Access from a Variety of Applications

The specification shall be programming language independent. In order to work effecti-vely with many applications, the synchronization protocol must not make assumptions about the programming language and cannot assume that both ends of the synchroni-zation process share a single language environment.

To facilitate rapid deployment of the protocol the reference code shall be provided for a common programming language. However, this will not restrict any implementation to only this language.

Address the Resource Limitations of the Mobile Device

Mobile devices have limited memory and processor capacity, a characteristic that sets the rules for developing a synchronization protocol.

The protocol implementation needs to fit within the memory footprint of the common mobile devices on the market today, in either static code or run-time execution space. In addition, the data exchanged by the protocol itself should be small and require mini-mal code to transfer it to and from the device. Data exchanged using the protocol may be encoded in a binary format (such as WBXML) to reduce memory requirements for storing received synchronization messages and reduce processor resources needed to parse and process that data.

A small footprint and processor requirement gives the protocol several key advantages. A small code size eases the porting overhead and increases the likelihood that imple-mentations will be available for all processor and/or operating system platforms. It also reduces device manufacturers' cost of adoption, an important consideration.

Optimally, a subset of the protocol would support embedded systems specialized for a particular type of data.


Build Upon Existing Internet and Web Technologies

Where possible, the protocol needs to make use of existing Internet and Web techno-logies. These technologies are implemented widely and are well tested, so their use within the protocol will ensure easy implementation and interoperability testing.

XML, the Extensible Markup Language, is rapidly emerging as the lingua franca for representing structured data over the Web. To the extent possible, the protocol should use XML to represent data being exchanged during a synchronization session.

Other useful standards in this space include MIME for registering the format of the data synchronization protocol messages.

Promote Interoperability

The protocol needs to be interoperable, synchronizing networked data with any mobile device and synchronizing a mobile device with any networked data. This includes a mar-ket space where mobile devices are small-footprint devices with minimal processor and memory resources and powerful network servers capable of executing sophisticated synchronization logic.


Download White Paper on SyncML (PDF format)