wdiff draft-jennings-apps-sync.txt.old draft-jennings-apps-sync.txt

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

Generic Synchronization
draft-bryan-p2psip-reload-03
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 21, 29, 2008.

Abstract

This brief note discuss discusses the growing needs need for a standardized sync
protocol for generic information and looks at one possibility of 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.

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 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 ways way to deal with sync issues is to have a
central server that is the master source of truth and truth, with all the
devices periodically connect connecting to that server and update. updating.
However,
that type of environment where in many situations having every device can reach the connect to a master
source is not possible in many situations. impossible. This note is about synchronization in
environments where a in which a centralized server architecture is not possible.
impossible.

This note looks at systems where in which all the device and 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. Consider
the example where 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 failing falling below $10 per gigabyte, phones, PDAs,
and even just plain USB keys are rapidly becoming usable to
synchronizing multiple gigabytes of data which makes 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 users 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 were have been brutally interrupted by
events such as just pulling 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
transfered
transferred should not be transfered. 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
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 number
may also have contain an indication of if 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 fields field because then you could not have
successfully synchronize in a situation where in which one device has added
a new phone number for a particular users user and another device has added
a new email
address and then they successfully synchronized. 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 by with both sides exchange exchanging their UUIDs and
compares if
checking whether either device has any fields that are missing from one device to
the other and if so transfers transferring them. For fields that have changed
on both sides, it the devices would compare the time-stamp time-stamps and selects 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 is would be done by
remove removing all the data from the
field except the UUID, UUID and time-stamp, and marking a deleted flag on
the field. Devices that are were not capable of knowing the time can could
just slightly increment the time-stamp when they
change changed a field.
Each device would also has have a UUID and UUID; when a pair of devices has had
previously synced, they can could optimize the sync by only exchanging
records and fields that have had 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 file; the USB key was 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: +1 408 421-9990
Email: fluffy@cisco.com

Full Copyright Statement

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