[Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV

[Cyrus Daboo <[e-mail]>]

Hi Mark,

--On October 25, 2005 2:50:24 PM -0400 Mark Paterson 
<[e-mail]> wrote:

> I've had a chance to take a closer look. I suspect that much of this
> could be done using SyncML or some of the other standards you listed but
> it you are building a client that uses CalDAV I can see how this would be
> an obvious nice match. When's TaskDAV and MailDAV coming? (and I say that
> only half jokingly, if you have a client making extensive use of a WebDAV
> based implementation I can certainly see the ease at which a developer
> aught to be able to make use of it for all).

Well, TaskDAV would just be CalDAV with VTODO's, right? Or are you thinking 
about something else? MailDAV is an interesting prospect, but there is 
already a significant investment in IMAP and POP that it would be hard to 
convince people to adopt yet another mail access protocol.

> My main comment for CardDAV is that if it is going to work well then an
> RFC2426bis needs to be put into the works. If you ask people implementing
> OMA DS based solutions, they might tell you that vCard might also be
> considered a disadvantage (your draft lists it as an advantage). It's
> advantage is its obvious wide spread use but once you start working with
> it you soon wish the spec had a little bit more to it :-)

I am not adverse to working on a vCard update. Some folks within Calconnect 
are already looking at extensions to vCard to help with location 
information for public events etc. I guess one question is where should 
that work be done? There probably isn't any need for a CardConnect 
organization, but perhaps this could come under the auspices of Calconnect 
if other members see value in it. Or it could just remain an individual 
effort or formal IETF WG effort.

> Here are some more specific comments on the draft...
> .
> - To modify a contact the client has to do a PUT and provide the full
> vCard if I understand correctly.
> --- It would be nice if you could only send the changes? vCard doesn't
> really provide a way of specifying this.

CalDAV suffers from the same problem. The solution that we would like to 
use is the HTTP PATCH proposal, which proposed a new HTTP method for 
providing a diff to change portions of a resource. The basic idea was that 
there would be different diff formats defined for different data types that 
would allow for efficient changes. So for CalDAV we would defined an 
iCalendar diff format that would allow changes to individual properties in 
a component in such a way that multiple properties of the same type could 
be individually addressed and changed (e.g. multiple ATTENDEEs). A similar 
approach would make sense for vCard. The draft for http-patch appears to 
have expired, but it should be revived.

> --- What if a contact previously had 3 home phone numbers and now there
> are only two? Was the first one deleted? the second? the third? There is
> no true way of knowing since vcard does not suport a way of enumerating
> you types (i.e. you can't specify this is home1 and this is home2, etc...)

Actually that's not quite true. vCard does support the notion of 'groups'. 
Basically you can add a prefix to each property name to give it a group. 
e.g.:

home1.ADR;TYPE=dom,home,postal,parcel:;;123 Main
          Street;Any Town;CA;91921-1234
home2.ADR;TYPE=dom,home,postal,parcel:;;124 Main
          Street;Any Town;MA;91921-1234

The group name could be used as a way to uniquely identify multiple 
occurring properties.

Alternatively to diff a particular property you send the original (or as 
much of it that uniquely identifies it) as well as the new data. You should 
be able to identify which property on the server is being changed by 
looking at the original data sent from the client. i.e. for the following:

ADR;TYPE=dom,home,postal,parcel:;;123 Main
          Street;Any Town;CA;91921-1234
ADR;TYPE=dom,home,postal,parcel:;;124 Main
          Street;Any Town;MA;91921-1234

to change the street address of the first one, a diff might look like:

<vcard-diff>
<original>
ADR;TYPE=dom,home,postal,parcel:;;123 Main
          Street;Any Town;CA;91921-1234
</original>
<change>
ADR;TYPE=dom,home,postal,parcel:;;321 Card
          Avenue;Any Town;CA;91921-1234
</change>
</vcard-diff>

<delete> and <add> elements could also be used to cover the full set of 
sync operations needed.

> --- Is is realistc to expect backend stores to support the endless
> combinations vCard can allow? vCard is very good in allowing endless
> combinations (I can specify my home submarine fax number if I wanted to)
> and this flexibility is nice but most back end adress book stores have
> something a little more fixed. It would be nice if there was some form of
> recommended practices or profile.

There are indeed a multitude of possibilities with vCard, and a strict 
database backend will likely have issues with knowing how best to optimise 
for lookups etc Still, I would prefer not to restrict what the client can 
do, though perhaps as a vCard revision process we could look at actual use 
cases and indicate what is the most common.

> - adbk-query will be very useful but how would I search for all my
> contacts with a phone number that contains the area code 514? vCard does
> not attempt to specify a format for phone numbers so it is a bit of a
> free for all.

For that particular case a regular expression comparator would be needed. 
Alternatively, if you do not mind getting some false positives, a simple 
text search for '-514-' would suffice.

> - The adbk-sync report is a nice addition. A concept that needs to find
> its way into CalDAV eventually.

Right. There is some question about whether this should actually be part of 
a more general 'collection sync' capability for WebDAV as a whole rather 
than have CalDAV/CardDAV/WhateverDAV each define there own. I primarily put 
that in the draft as a 'proof of concept' idea.

> - There is no way of knowing what fields have changed within a contact
> that is reported as changed by the abk-sync report. This would be useful
> for doing merges rather than having to l;et the client or server win the
> sync conflict.

You basically want 'property level' synchronization rather than 'component 
level'. Perhaps the diff format for PATCH could be used as a way to 
accomplish that. An option on adbk-sync would allow you to ask for the diff 
of each changed component, or a new 'adbk-diff' report could do the same 
for selected components.

> - adrbk-sync is really more of a changes report. A sync report would
> allow the caller to provide the server with the client's changes, the
> server would then reconcile these changes versus the changes on the
> server side and then only send back instructions that the client needs to
> follow to be in sync with the server. One HTTP request and it is done.
> With the changes style as defined the client asks for the changes,
> compares against it's own and does the reconcilliation, and then will
> have to do a  series of PUTs to get the server in sync. This means
> several HTTP requests.

Right - I initially did not want to make adbk-sync to complex, instead 
preferring to have the sync logic handled by the client. We certainly could 
consider having a full server-side sync capability if there is demand for 
that.

> If you are interested you might want to look at the Employee Profile
> Service Specification and the Personal Profile Service Specification
> created by the Liberty Alliance. They decided vCard just had too many
> problems for their purposes so they invented something brand new. They
> are really quite nice but due to the vast use of vCard it would have been
> nice if some effort had been put into updating vCard.

I will try and take a look at those.

-- 
Cyrus Daboo