Re: [VCARDDAV] draft minutes for IETF 72 Dublin vcarddav meeting

["Darryl Champagne" <dgc at funambol.com>]

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault at viagenie.ca]
> Sent: Friday, August 01, 2008 4:59 AM
> To: Darryl Champagne
> Cc: vcarddav at ietf.org
> Subject: Re: [VCARDDAV] draft minutes for IETF 72 Dublin vcarddav meeting
> 
> Darryl Champagne wrote:
> > Do people realize that no-one advocates actually doing triangle sync?
> That
> > every sync vender out there already tells people not to do it?
> 
> Two-party sync is easy: just record diffs as metadata and exchange that
> in the sync protocol. 

I'm sorry, but I absolutely disagree with this - and there isn't a single
sync protocol out there that works this way, including quite a few
proprietary ones that I know of.

There was an entire sequence of messages about why Diffs do not work in that
environment.  I see no reason to repeat something which was not able to be
refuted back then.

Please provide an example of ANYTHING with significant market presence that
actually does this.  There are a few that can (none of which are on
devices), if everything else is perfect, in just certain cases, but they all
must work without it a significant portion of the time.  You have an opinion
that this is easy, but if so, I fail to see why no one else out there ever
made it work well - you appear to be declaring yourself smarter than all the
existing sync engineers who have spent years on the issues, which can be
rather offensive.

> PID/LASTPID are simply a way to put that metadata
> into the vCard.

Not exactly, they are a way to identify specific pieces of data in a format
that does not have order preserved, or indicate deletions.  In most data
formats, the field format is less fluid, so this information would have been
conveyed already by position and empty fields.  PIDs convey essentially the
same information as having a static structure would convey.  Since most
implementations actually store the address book data into static structures,
this allows for device specific behaviors that actually make sense, such as
store the email with the lowest PID value in the first slot in its static
structure, and correlate a particular entry with a particular slot in a
structure at a later point in time, without having to search and compare
against all similar values.
 
> 
> What is the metadata that should go into the vCard (and thus become
> data)? I'm still not convinced that there should be *any*, especially if
> a sync engine still cannot do a reasonable sync job without metadata.

And again - I stress my requirement to not have catastrophic failure if the
metadata gets out of sync with the address book.  Something like simple PIDs
behaves well when present, and if sync metadata is out of sync with the
address book data, still behaves no worse than today if it is completely
absent.  This causes independent failure modes - IF the metadata is
available it works well, OR IF either side still has Metadata it can be
recovered from.  Only if both fail at the same time AND conflicting changes
are done, the behavior is the same as today, and the user gets whatever the
conflict resolution policy is set to.  In contrast, LASTPIDs is brittle - it
assumes that devices have information that they typically don't to figure
out modifications (and if you had it, you already have the information
LASTPIDs provides), and when metadata is lost by either side and conflicting
changes occur it guarantees a conflict.

I also find your exaggeration of the situation ridiculous - "a sync engine
still cannot do a reasonable sync job without metadata".  Sync engines do
quite well for two party sync today, with or without metadata.  Lack of
Metadata reduces speed, but does not cause significant additional problems
(although certain shortcuts are taken regarding which side's changes "win").
Adding PID metadata helps for certain very specific cases - that is a far
cry from being unable to do a reasonable job.  Adding PID metadata also
helps for a significant set of >2 party sync cases, but not all.  If you
insist that it solve every problem or not be implemented, then I have to
strongly disagree.

> 
> If we just don't want to address three-party sync, I would argue against
> having any PID stuff in vCard and instead just exchange diffs.
> 

And again, I repeat my requirements - to fail gracefully when it does occur.
That is NOT the same as ignore the problem and hope it never occurs, or
blindly (and pointlessly) announce that it should not be done.

> If we do want to address three-party sync, I fear PID/LASTPID won't be
> enough to do a reasonable sync job, and in that case I would also argue
> against having any PID stuff in vCard.

And again, I repeat my requirements to improve what actually happens in the
real world today.  Not some theory without any market presence, not some
mythical perfect solution, but a real-world improvement to an existing
problem.

This leads to me reiterating the earlier questions - do we have any
overlapping goals at all?

In contrast to PR "not caring" to "create infrastructure" for devices that
don't have sync metadata (which was not the focus of what I talked about,
but rather an example, and a defining of terms), I only care about issues
that occur in the real world, with things that have a real market presence -
which _all_ occasionally lose sync metadata. 

In contrast to talking about ideal situations where both sides store
vcard-like data, I only care about talking about situations that actually
occur a significant amount in the real world - where virtually every sync
occurs with at least one side that does not store vcard-like data.

Please identify ANY situation with significant market presence that occurs
where both sides store sync meta-information with the address book
information, before spending significant time on it.

> 
> --
> Please try Numb, a STUN/TURN server implementation.
> Free access at http://numb.viagenie.ca/.

_______________________________________________
VCARDDAV mailing list
VCARDDAV at ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav