[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (#1) CAP Synchronization proposal.
At 09:53 PM 2/13/2002 -0700, Doug Royer wrote:
Because of multiple questions
raised on this list, the editors
have decided that we need a "Synchronization" section in
And because it is a in the CAP requirements document that
a CUA be able to synchronize with a CS.
Here is attempt (#1) at the text for that new section:
I think that the idea of this section is good but it should concentrate
simply on showing that it is possible to query for all changes since the
last time such a query was done. It should not get into assuming how a
sync solution should work. That is for the sync solution implementors of
the world to decide and beyond the scope of CAP. We need to be careful
not to lecture as to how a sync solution should work and I believe that
this version does tread into this area. For example what if a sync
solution implementor decides to only sync booked entries? This is
perfectly valid but this section makes it sound like you MUST worry about
unprocessed ITIP objects. You may want your sync solution to process
them, you might not. It is not for CAP to decide. If it does then it is
really no different then any other CUA.
I had started my own proposal and I will try and make sure it gets posted
before the end of the day (I know that today is a cutoff day for
proposals). It actually covers a lot of the same stuff but focus's more
on how you get changes as opposed to how you do sync.
I have more comments interspersed below...
X. "Synchronization between a CUA and CS"
There are two major issues with synchronization (1), iTIP
updates and dealing with out of order or missing iTIP components,
and (2) updating booked entries.
There are hundreds of major issues with sync and they are all beyond the
scope of CAP. With respect to CAP however the main decision you need to
make when you query for changes is however, whether you only care about
booked entries or whether you also are worried about unprocessed ITIP
Synchronization is a two sided
process. That is you need to update
the CUA with any new object from the CS. And any new objects in the
CUA may need to be deposited into the CS.
Synchronization can be a three sided, four sided, n sided process. Being
clear on what we mean by Synchronization is important but we should be
careful about how we define it.
Below the term "zombie
object" will refer to any out of order ITIP
object that is dead but does not yet know it. As in METHOD:CANCEL,
UID:123, SEQUENCE:10 has been processed, and then you get
METHOD:REQUEST, UID:123, SEQUENCE:9. So the second iTIP object is
waiting to be reaped by the CUA.
X.1 "iTIP and synchronization"
Only concern if you plan to sync more than just booked entries.
There is no difference between the
iMIP handling of iTIP objects
and CAP handling of iTIP messages once the iTIP objects are in the
CUA. So this section will describe some CS and CUA implementation
considerations. Such as how to fetch iTIP objects from the CS, when
to delete them from the CS, and when to leave them in the CS for
When to leave them in the CS for later processing??? If it's been
processed then that's that. Where in CAP does it describe when a CUA
should decide to leave them and when should it scrap them? Perhaps there
is such a heuristic defined somewhere but I don't remember it.
This is not a tutorial on how to
process iTIP objects. This is
an outline of the problems that may be unique to an iTIP objects
when a CUA is synchronizing with a CS.
The section titled "Query for all Non-Booked Entries" shows
of how to fetch for iTIP objects. It is recommended that the CUA
fetch iTIP objects with EXPAND:FALSE in order to simplify the
Fetching of all of the data booked, not booked, and marked for
delete, SHOULD BE performed using one VQUERY to reduce the
bandwidth by not having to keep sending commands to the
CUA which can be expensive on slow networks.
Perhaps but you just downloaded essentially an entire CU's calendar it's
going to be a heavy operation no matter what.
The first step is to fetch all
objects where the LAST-MODIFIED
date is greater then the CUAs last synchronization date.
The next step is to pull out any marked METHOD:CREATE (booked).
These may be new or updated objects. Compare them to the
METHOD:CREATE objects in the CUA with the same UID:
If the CUA does not have that UID - add the new
If the CUA does have that UID:
the SEQUENCE values:
the object with the higher SEQUENCE value
from the CS drop the one in the CUA
and have it use the new one from the CS.
the object with the higher SEQUENCE value
from the CUA, then the CUA must delete the
object from the CS and add the newer
to the CS.
We need to be much more careful with out wording. Sync solution's have
their own policies for conflict resolution when a change has occurred
both client side and server side. We are trying to convey that the server
sequence is out of date so it isn't meaningful and no change has really
occurred on the server so the client change can take precedence but we
are not interfering with any policy the sync solution itself may have.
This isn't really a sync issue though. Any CUA processing ITIP objects
needs to worry about this. This isn't unique to a Sync CUA.
the SEQUENCE numbers are the same then keep
one with the greater LAST-MODIFIED date.
the one with the older LAST-MODIFIED
is from the CS. Then that object
be deleted from the CS and it
be replaced with the newer one
Absolutely not. If they have both been changed since the last sync
and the sequences show that they are both up-to-date then the sync
solution's conflict resolution policy will decide and it is none of CAP's
If the CUA has
UIDs that have a LAST-MODIFIED time greater
than the last synchronization time, and no object came
from the query with the same UID, then those new
need to be added or updated in the CS. This will
a separate query to determine if they exist at all in
before deciding if they are new to the CS or need to
updated in the CS.
How a sync solution determines if a new object exists or not is none of
CAP's business. A typical sync solution keeps some sort of database
linking device side ID's with server side ones so entries on the device
not yet in the database are new. There is no query required. Some
vendors may decide they do want to make a query with their solution but
that is out of scope.
Now examine the
UIDs that you fetched for having METHOD:DELETE.
should note the UID and its SEQUENCE value so that
in later synchronization's the
CUA can know that any out of
order (zombie) iTIP objects
can be deleted from the CS and
otherwise ignored in the CUA.
And drop these from the CUA
and know to later delete them
from the CS if the zombie
point the CUA has two choices:
can delete those METHOD:DELETE objects from
CS with command <delete>.
Do you mean the ITIP object or the booked entry? The ITIP object can be
deleted and the booked entry modified and marked METHOD:DELETE.
it can keep them in the CS in case other CUAs
be synchronizing with that same calendar and
need to know that those UIDs should be deleted
The ITIP object has been processed and therefore should be zapped. The
booked entry is now marked method DELETE so other CUAs can see this.
is up to the CUA or CU and the CS or CS
to decide when the METHOD:DELETE
are to be deleted from the CS. And this
not specified in CAP.
It should be. A CUA which processes an ITP cancel should mark the booked
entry as METHOD:DELETE.
processing the iTIP object in the CUA just like
you would as described in iTIP and iMIP. Then for each
those iTIP object that were processed, update the CS
the latest version of the object, followed by drop
processed iTIP objects from both the CUA and delete
from the CS.
Any iTIP objects that can not be processed yet
METHOD:COUNTER, UID:abc, SEQUENCE:1 when you have not
METHOD:REQUEST, UID:abc in the CUA or CS). These would
in the CS until the CUA or CU and the CS or CS
decided that they were zombies or just too old to care
and then they would be deleted from the CS. And their
time MUST BE updated in the CS so that they would
be fetched for the next synchronization until they
The CUA MUST update the LAST-MODIFIED times of any object that
it updates or adds to the CS. This needs to be done by the
CUA and not the CS in order for there not to be a race condition
that is caused by the CUA object always being older than
the same object in the CS.
Out of scope. All Sync solution implementors know they have to do
something to ensure that the changes they initiated don't come back the
next time they ask for changes. How they do so is implentation
specific. There are hundreds of other things you should be aware of when
doing a sync but just like this one it is out of scope for CAP.
Some optimizations can be done. For
example the CUA may
just use <modify> and not <delete> followed by <create>
update the CS. And many of the updates, deletes, and creates
could be combined and processed at the end, or as they are
determined, which ever works best for the implementations.
Director, Client R&D