A SyncML Message is represented as a MIME type. This implies that SyncML Messages can be carried by almost any common transport protocol. It is quite obvious that implementations supporting SyncML cannot support all possible protocols. Thus, they have to decide which protocol interfaces are supported. These decisions might well be based on the following questions:
Which type of physical connection is desired, wireless or wired?
Is the physical connection short-range or remote?
Is there a need to start a synchronization session from a server?
Is an IP-based or non-IP-based transport connection desired?
Should the transport connection be standard-based or can it be proprietary?
After answering these questions, Server and Client implementations can decide to support one or more transport protocols. In addition, if a SyncML standard-based transport protocol is desired, the selection can be found among the three transport bindings defined by the SyncML Initiative. SyncML has defined the transport protocol bindings for HTTP, WSP, and OBEX.
In the future, more transports might be utilized by SyncML applications. Some of them may not be standardized if used for proprietary purposes. Future standard protocol alternatives may be related to different messaging protocols and methods, like email or MMS (multimedia messaging).
As defined by IETF, the Hyper Text Transfer Protocol (HTTP) [RFC2616] is an application-level protocol for distributed, collaborative, and hypermedia information systems. It is a generic, stateless protocol, which can also be used for many tasks beyond its use for hypertext. A key feature of HTTP is data typing and the negotiation of data representation, allowing systems to be built independent of the data being transferred. Due to this feature, SyncML data (i.e. SyncML Messages) can be conveniently transferred via HTTP.
In the case of SyncML, HTTP (version 1.1) is an ideal protocol for building wide-area distributed systems, such as the synchronization service framework in the Internet environment, whether in the public domain or inside a corporate Intranet. HTTP has proven to be the primary wireline protocol used by SyncML Clients and Servers. HTTP is used over the TCP/IP protocol suite, which is further used over various networks, such as LANs (Local Area Networks). In addition, HTTP can increasingly be used over wireless networks as the bandwidth of wireless networks increases and TCP/IP protocols can be efficiently used over wireless networks.
When using the HTTP binding for a SyncML session, the SyncML Client acts as a HTTP client and the SyncML Server as a HTTP server. The Post method of HTTP is used to carry SyncML Messages from the Client to the Server. The response to the Post method is used to transfer SyncML Messages back to the Client. Because the Client always takes the role of the HTTP client according to the SyncML HTTP Binding specification, the Server alerted sync needs to be done using out-of-band mechanisms like WAP Push. This kind of solution is required, as HTTP does not provide for unsolicited messaging from the server to the client.
Some definite benefits of HTTP are its very wide adoption and the large number of available HTTP products and implementations. In other words, problems related to interoperability and limited support do not exist with HTTP. In addition, there are Open Source HTTP implementations available for both the HTTP clients and servers.
The SyncML WSP Binding specification defines how to use SyncML over Wireless Session Protocol (WSP) [WSP01]. The WSP binding is based on version 1.1/1.2.1 of WSP. Many mobile terminals are adopting the WSP binding, as they also use WSP for other purposes, such as micro-browsing.
The core of the WAP WSP design is a binary form of HTTP. WSP supports all the methods defined by HTTP (version 1.1). In addition, capability negotiation can be used to agree on a set of extended request methods, so that compatibility to HTTP applications can be retained. WSP provides MIME-typed data transfer for the application layer like HTTP. Compact binary encodings are defined for the standard HTTP headers to reduce protocol overhead.
The main differences between WSP and HTTP are very much related to the fact that the WSP client communicates with the HTTP server through the WAP gateway. From a SyncML Server point of view, it does not really matter whether a SyncML Client uses WSP or HTTP. If WSP is utilized, the WAP gateway makes a translation from WSP to HTTP and the Server sees only the HTTP connection. From a mobile terminal standpoint, the WAP gateway can be described to be an access point to a wired network such as the Internet.
During the translation from WSP to HTTP and vice versa, the WSP client in the device does not interpret all the header information in requests and replies. The WAP gateway partially does that. During the session creation process with a WAP gateway, request and reply headers that remain constant over the life of the session can be exchanged between the client and the server. In addition, the lifecycle of a WSP session is not tied to the underlying transport. A WSP session can be suspended while the session is idle to free up network resources or save batteries. In practice, this means that the physical connection between the WSP client and the WSP server can be disconnected but the logical connection is kept alive.
One of the key features of WSP is WAP Push [WPU01]. This means that a Server can send data in an unsolicited manner to a Client. This is great when the Server wants to trigger the Client to start synchronization. WAP Push can be done over an UDP/IP connection but in general, it happens over non-IP connections like the SMS (Short Message Service). SMS offers an efficient way to send a small amount of data in an unsolicited way from the Server. In the SyncML case, the Server Alert (known as Package #0 in the Synchronization Protocol) is transferred over SMS. The next packages usually go over an IP-connection as the Client establishes the IP connection with the Server after receiving the Server Alert.
The SyncML Initiative has selected the Object Exchange (OBEX) protocol [OBEX99] to be one of three specified transport protocols for SyncML. OBEX is commonly exploited over different local media such as IR (InfraRed) and USB (Universal Serial Bus). IrDA® (Infrared Data Association) originally specified it, and due to this, it is also called IrOBEX. The OBEX protocol has been widely adopted by the mobile and PC industry. Most mobile devices (PDAs, mobile phones, etc.) and PCs use it for multiple purposes, such as data-beaming applications.
OBEX is a session layer protocol designed to enable systems of various types to exchange data and commands in a resource-sensitive standardized fashion. The OBEX protocol is optimized for ad-hoc wireless links and can be used to exchange all sorts of objects, like files, pictures, calendar entries, and business cards. OBEX also provides some tools to enable the objects to be recognized and handled intelligently on the receiving side. It is designed to provide push and pull functionality in such a way that an application using OBEX does not need to get involved in managing physical connections. The application only takes an object and sends it to the other side in a "point-and-shoot" manner. This is similar to the role that HTTP serves in the Internet protocol suite, although HTTP is designed more for data retrieval, while OBEX is more evenly balanced for pushing and pulling data.
The SyncML Initiative has defined how to use OBEX over two physical media, IR and BluetoothTM. In both cases, the transfer happens directly over native IrDA and Bluetooth protocols (See Figure 7-4). OBEX could also be run over TCP/IP, but this protocol suite is not commonly found in embedded mobile devices [BlIR01].
 In this context, the "native" protocol means a protocol particularly designed for a specific environment, such as the Bluetooth radio environment.
Figure 7-4. Bluetooth and IrDA protocol stacks for OBEX
In addition to IrDA and Bluetooth, the USB Implementers Forum has defined in an interoperable manner how to use OBEX over USB in the USB Wireless Mobile Communication Devices specification [UWMC01]. Thus, USB can also be used as a physical transport medium for OBEX and SyncML.
Before sending any SyncML Message over OBEX, an OBEX connection needs to be created with the Connect operation. With this operation, the OBEX connection can be dedicated to a SyncML session, and during this connection phase, necessary parameters for the OBEX connection are also negotiated. After the OBEX connection is made, the Put and Get operations of OBEX are used to send and retrieve SyncML Messages, respectively.
The OBEX role (OBEX client or OBEX server) is independent of the role at the SyncML level. In other words, either the SyncML Client or the SyncML Server can start the OBEX connection and to send SyncML Messages. The entity (SyncML Server or SyncML Client) that starts the OBEX connection is also responsible for disconnecting the connection after the SyncML session is over. For instance, if a PC acting as a SyncML Server has started the SyncML synchronization session with a mobile phone acting as a SyncML Client, the PC needs to disconnect the OBEX connection after sending the final package of a SyncML session to the mobile phone.