PP16: Generic Synchronization

[Lisa Dusseault <[e-mail]>]

Network Working Group                                        C. Jennings
Internet-Draft                                                     Cisco
Intended status:  Standards Track                       January 26, 2008
Expires:  July 29, 2008


                         Generic Synchronization
                       draft-jennings-apps-sync-00

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 29, 2008.

Copyright Notice

    Copyright (C) The IETF Trust (2008).

Abstract

    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.





Jennings                  Expires July 29, 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 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.


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
    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



Jennings                  Expires July 29, 2008                 [Page 2]
Internet-Draft                    SYNC                      January 2008


    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.


Author's Address

    Cullen Jennings
    Cisco
    170 West Tasman Drive
    MS: SJC-21/2
    San Jose, CA  95134
    USA

    Phone:  [phone]
    Email:  [e-mail]




Jennings                  Expires July 29, 2008                 [Page 3]
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
    [e-mail].


Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).





Jennings                  Expires July 29, 2008                 [Page 4]