|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 29, 2008.
This brief note discusses the growing need for a standardized sync protocol for generic information and looks at one possibility for what such a protocol might look like. It lists some of the things people are syncing today, introduces a "ferry" concept of synchronization, and briefly sketches a possible synchronization scheme.
Synchronization is about keeping a set of data consistent between a set of devices. The classic example of this would be a user's Personal Address Book (PAB) but there are many other things that are becoming common to sync: media play lists, photo albums, missed call lists on phones or dialed call lists, task lists, gps location tracks, and many more. One way to deal with sync issues is to have a central server that is the master source of truth, with all the devices periodically connecting to that server and updating. However, in many situations having every device connect to a master source is impossible. This note is about synchronization in environments in which a centralized server architecture is impossible.
This note looks at systems in which all the devices are equivalent and there is no master server that all devices can reach. This allows a device to act as ferry to bridge the synced information. As an example, I sync my PAB in my notebook computer to my phone using USB, and then I sync my phone to the navigation system in my car using bluetooth. In this case my phone has acted as a ferry to transfer the data from my PC to car. The car does not have internet connectivity and could not have contacted a central server. With the price of flash memory falling below $10 per gigabyte, phones, PDAs, and even just plain USB keys are rapidly becoming usable to synchronizing multiple gigabytes of data, making it practical to use a device like a phone as a ferry for music and video. The device that is acting as the ferry could easily synchronize information that it did not understand or use itself.
The most critical functionality of any sync system is that a user never wants to see "you have 376 conflicts! how would you like to resolve them?" It is also important that any sync protocol be able to gracefully deal with syncs that have been brutally interrupted by events such as the plug being pulled out part way through the sync. It is also key that when the communication mechanism between the two devices is very slow, large chunks of data that do not need to be transferred should not be transferred.
Data schemas that need to be synchronized need to be designed for this if you want them to have reasonable conflict resolution properties. This note uses two terms: record and fields. Records are just a collection of fields. Fields are an atomic piece of data from a synchronization point of view. A field can be more complex than a single data item. For example in a PAB, a telephone number may contain an indication that it is a mobile, home or work number. This indication would likely be in the same field as the phone number since they need to handled as a single atomic unit when dealing with conflict resolution. However a PAB would not want the the email address and phone number in the same field because then you could not successfully synchronize in a situation in which one device has added a new phone number for a particular user and another device has added a new email address. The point of this is that the data schema needs to clearly outline what the atomic blocks are.
The approach proposed here gives every record and field a UUID and fields have a time-stamp of when they were last modified. One can debate the issues with time synchronization but from a pragmatic point of view, just about every device today has a rough idea of time.
The sync protocol starts with both sides exchanging their UUIDs and checking whether either device has any fields that are missing from the other and if so transferring them. For fields that have changed on both sides, the devices would compare the time-stamps and select the most recent one. It would be possible to query the users about resolving conflicts at this point but for many cases it would not be necessary. Deletion would be done by removing all the data from the field except the UUID and time-stamp, and marking a deleted flag on the field. Devices that were not capable of knowing the time could just slightly increment the time-stamp when they changed a field. Each device would also have a UUID; when a pair of devices had previously synced, they could optimize the sync by only exchanging records and fields that had changed since the previous sync.
This type of sync protocol could be realized other ways. For example one could just have an XML file on a USB key that had all the records and fields in the file; the USB key would be used as a ferry between the devices to be synchronized.
| Cullen Jennings | |
| Cisco | |
| 170 West Tasman Drive | |
| MS: SJC-21/2 | |
| San Jose, CA 95134 | |
| USA | |
| Phone: | +1 408 421-9990 |
| Email: | fluffy@cisco.com |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.