To exchange contacts or calendaring data, the SyncML specs requires the use of the well established standards that are vCard and vCalendar. While these standards are somewhat loose, they have the advantage of being widely supported and easy to read and write: they are just a bunch of lines with a key-value association (ie a line with “ORG:ACME Inc.” for the contact’s organization name). These standards require that each line is terminated MS-DOS style, with both a carriage-return and line-feed character to mark each end of line – this is however just an arbitrary choice as a simple line-feed would be enough (this is how lines are terminated on Unix systems).

Problem is, the SyncML specs is also built on XML, which treats spaces, carriage returns, tabs and lines feeds as special “white spaces” and allows XML tools to change them. As such most of these tools consider the carriage-return sign as unimportant, as it is redundant with the line-feed to mark the end of a line.

So what happens when you put a format that requires carriage-return such as vCard inside another format that doesn’t preserve them? Lots of hair pulling, because most XML programming tools will merrily remove any carriage returns they happen to find. Thankfully almost every SyncML application out there doesn’t mind reading vCard or vCalendar data with the wrong line ending as this is trivial to do and doesn’t any difference to the data. But a few will not.

This is most often because:

1. You haven’t supplied the proper database names (spelling mistake or just didn’t change the default ones)
2. You haven’t supplied the proper user name and passwords (the later is case sensitive)
3. There is a bug in your device/program or in picoBeat SyncML module. Or possibly both (ugh!).

The long answer

There’s a lot to say about the standards developed by the telecom industry. Somehow, while a cell-phone is just a tiny computer, the telecom guys seem to live on a different planet than the computer guys, and they seem to insist on doing things “their way”.

When it was decided to bring the Internet to cell-phones, HTML would have been an obvious choice. But no, a different standard was built from scratch: WML. WML 1.0 wasn’t really a big success, for many reasons including the fact that Web developers do not like having to learn a whole new markup language, so WML 2.0 tried to correct this by being some limited form of HTML. Similarly, pictures were expected to be stored in a new WBMP format, rather than one of the many existing image format that already exists and are widely supported.

This bring us to SyncML: it’s a synchronization standard by the telecom industry. Two good things about it: it’s built with XML and it’s pretty flexible. Two bad things about it: XML is encoded in a new custom format called WBXML, somewhat negating the advantage of using XML, and it’s way too flexible. This comes from contradicting constrains: making the standard as flexible and open-ended as possible, but making it work on underpowered devices such as entry-level cell phones. As such the standard requires devices to accept informations in many different ways and to be very flexible in exchanging data, which requires complicated programming and a lot of processing power. But at the same time it allows the phone to signal that it has little memory capacity and bandwith. Why would a device capable of processing a complex XML-based protocol be only capable of storing a handful of appointments or processing more than 2,5 Kb at a time is beyond my understanding.

This flexibility is also the reason there’s no standard name for databases (tasks, appointments, contacts, etc.)  in SyncML and why users have to type them in when configuring their cell-phone. This complexity also means a lot of cell-phones have bugs – some of them so bad as to reboot when receiving certain standard-compliant SyncML data. Sadly there are dozens of phone manufacturers and thousands of models out there and it’s impossible to properly test every one of them with picoBeat, so I know for a fact that some phones just won’t work. Things will improve over time and hopefully most devices will work.