SyncML is working towards the adoption of SyncML DM by the major standards organizations, such as 3GPP, WAP Forum, and OSGi™. Other standards organizations, such as the Java Community Process™ (JCP), are also being investigated. The purpose of this adoption is to make synchronization and device management a simple process by having a single, open standard for these activities.
There are other possibilities for SyncML beyond data synchronization and device management. It is possible that the base technology could be applied to other areas, such as:
Digital Rights Management allowing users to buy, sell, and trade copyrighted materials. Organizations such as Napster™ indicate the need to implement a usable Digital Rights mechanism.
SyncML Replication allowing servers to share the data needed for client/server synchronization.
Relational Data allowing clients to have subsets of Relational tables.
The SyncML Initiative is also working on improving the existing specifications. Newer versions are planned with a typical delivery rate of one release per year. SyncML DS will be working on (a nonexclusive list):
Improving the Device Information structure
Adding additional authentication types, including Certificates and Challenge-Response
Improved Transport Bindings to include more details on secure transports, and message chunking in WSP and OBEX
Improvements on initial sync, including ease of use for first time synchronization
SyncML DM is working on (a nonexclusive list):
Improvements on the Device Description Framework
Improvements on initial Server contact with a Client
Making changes to the SCTS to test SyncML DM Clients and Servers
Software Delivery and Management
SyncML has also discussed other improvements, but has generally decided that most of these are too significant to add into a 1.x release and will be reconsidered for a later major release. In particular, SyncML has discussed the use of XML Schemas, and decided that it would produce too much of a change in the parsers and underlying technology. Likewise, other binary encoding schemes, such as XHTTP, will be considered for the next major release.
Of course, if problems arise, Erratas will also be published. Test cases (both manual and SCTS) are continually being refined. The specifications are always being reviewed for errors and possible clarifications. Naturally, if someone finds an error or an enhancement, they should send email to firstname.lastname@example.org.