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

[Mark Paterson <[e-mail]>]

Hi Cyrus,

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

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

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.
--- 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...)
--- 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.
- 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.
- The adbk-sync report is a nice addition. A concept that needs to find 
its way into CalDAV eventually.
- 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.
- 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.

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.

Thanks,
Mark

Mark Paterson wrote:

> Nice idea but you may want to consider a cardsify initiative to go 
> along with it. vCard leaves a lot to be desired.:-)
>
> Cyrus Daboo wrote:
>
>> Hi folks,
>> This is a little of topic, but I think it is relevant for most folks. 
>> I have just sent in a draft for a new protocol called CardDAV:
>>
>> <http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>
>>
>> CardDAV does for vCards what CalDAV does for iCalendar. i.e. it 
>> provides a set of WebDAV extensions and a data model for access to 
>> vCard objects stored on a server. CardDAV is very similar to CalDAV 
>> because of the similarities between iCalendar and vCard formats.
>>
>> There is a separate discussion list setup for CardDAV, so please 
>> respond to any comments on that list rather than the CalDAV list. 
>> List details are below:
>>
>> <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>
>>
>

-- 
MARK PATERSON
Director, Software Development
Collaborative Application Services
Oracle Corporation - Server Technologies

Phone:  [phone]
Mobile: [phone]
mailto: [e-mail]
http:   www.oracle.com