Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track January 18, 2008 Expires: July 21, 2008 Generic Synchronization draft-bryan-p2psip-reload-03 Status of this Memo 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 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This brief note discuss the growing needs for a standardized sync protocol for generic information and looks at one possibility of 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. Jennings Expires July 21, 2008 [Page 1] Internet-Draft SYNC January 2008 1. Introduction Synchronization is about keeping a set of data consistent between a set of devices. The classic example of this would be a users 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 ways to deal with sync issues is to have a central server that is the master source of truth and all the devices periodically connect to that server and update. However, that type of environment where every device can reach the master source is not possible in many situations. This note is about synchronization in environments where a a centralized server architecture is not possible. This note looks at systems where all the device and 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. Consider the example where I sync my PAB in my notebook computer to my phone using USB, then I sync my phone to the navigation system in my car using bluetooth. In this case my phone 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 failing below $10 per gigabyte, phones, PDAs, and even just plain USB keys are rapidly becoming usable to synchronizing multiple gigabytes of data which makes 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 users 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 were brutally interrupted by events such as just pulling the plug 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 transfered should not be transfered. 2. Synchronization Approaches 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 which 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 Jennings Expires July 21, 2008 [Page 2] Internet-Draft SYNC January 2008 number may also have an indication of if 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 fields because then you could not have a situation where one device added a new phone number for a particular users and another device added a new email address and then they successfully synchronized. 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 by both sides exchange their UUIDs and compares if any fields are missing from one device to the other and if so transfers them. For fields that have changed on both sides, it compare the time-stamp and selects 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 is done by remove all the data from the field except the UUID, time-stamp, and marking a deleted flag on the field. Devices that are not capable of knowing the time can just slightly increment the time-stamp when they change a field. Each device also has a UUID and when a pair of devices has previously synced, they can optimize the sync by only exchanging records and fields that have changed since the time of 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 and the USB key was used as a ferry between the devices to be synchronized. Jennings Expires July 21, 2008 [Page 3] Internet-Draft SYNC January 2008 Author's Address 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 Jennings Expires July 21, 2008 [Page 4] Internet-Draft SYNC January 2008 Full Copyright Statement Copyright (C) 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jennings Expires July 21, 2008 [Page 5]