Features of the SyncML plugin

Transport protocol and OMA DS modes

Please note that Server Alerted Notification (SAN) is only supported for OBEX because you need OTA-HTTP if you want to use it with HTTP. OTA means Over The Air and so we cannot trigger an HTTP client over normal TCP/IP networks.

• OMA DS server over OBEX client (syncml-obex-client)
• OMA DS server over HTTP server (syncml-http-server)
• OMA DS client over HTTP client (syncml-http-client)

Supported OMS DS Synchronization modes

Actually OpenSync? only supports SLOW-SYNC and normal sync so there is no need to implement all the other synchronization modes. If this changes in the future then the other modes are added too.

• SLOW-SYNC
• TWO-WAY-SYNC

HTTP transport features

• basic authentication in client mode (this is not the authentication inside the SyncML protocol - this is out-of-band authentication against the HTTP server)
• SSL CA certificate validation in client mode
• SSL support in server mode (certificate and key)

Capability filtering

There is code which signals the synchronization engine which properties are supported by the connected device. If the plugin does not support a property (e.g. DAYLIGHT) then a warning is printed by glib. If the missing property is a proprietary extension (e.g. X-EPOCALARM) then a normal message is printed. Only supported capabilities are checked by the merger.

Supported SyncML servers

The OMA DS client over HTTP is a little bit of a nightmare if you want to implement a synchronization engine which acts as a client. The reason is that the OMA DS server performs all decisions which is a good idea.

The problem for OpenSync is that one synchronization needs at minimum two OMA DS sessions because OpenSync must synchronize locally with other data sources and must then synchronize the results again. If the OMA DS server thinks there is something to synchronize during the second session then OpenSync had a problem. Usually this does not happen but it is possible (if something happens on the OMA DS server between session one and two).

The tested servers are:

Funambol

• version 5.0 was verified with ScheduleWorld
• version 6.5 together with SyncML 1.1 crashes with the message:

  org.jibx.runtime.JiBXException: Expected "CTCap" end tag, found "CTType" end tag
  

  Usually this happens if only one datastore definition was expected but this is only true for OMA DM 1.2. So the message suggest a XML problem but it is a bug in the protocol implementation.
• version 6.5 together with SyncML 1.2 was verified (6.5.14)
• Funambol demo client v6.5.14 does not work with 2 or more datastores because the client sends all alerts with the same command ID what is not standard compliant.
• Funambol demo client v6.5.14 does not work with 1 datastore too because the client interprets the received status in a wrong way. status/item/data is interpreted as error code but the error code is at status/data and status/item/data must contain the next sync anchor.
• Funambol Outlook v6.5.14 does not work with OpenSync because the client violates the SyncML v1.1.2 represensation protocol section 5.4.1 Status (Protocol Management Elements). The client sends the status commands in the wrong order if the device information is requested by the server.

Oracle Collaboration Suite (OCS)

the calendar component was tested with integrated addressbook