Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV
From: Cyrus Daboo <[email-masked]>
To: Mark Paterson <[email-masked]>
Cc: Bernard Desruisseaux <[email-masked]>, CardDAV DevList <[email-masked]>
Date: Thu, 27 Oct 2005 15:07:14 -0400
List-Id: ietf-carddav.osafoundation.org

Hi Mark,

--On October 25, 2005 2:50:24 PM -0400 Mark Paterson 
<[email-masked]> 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

Date: Tue, 25 Oct 2005 14:50:24 -0400
From: Mark Paterson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Bernard Desruisseaux <[email-masked]>, CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV

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:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

Date: Wed, 19 Oct 2005 15:58:24 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV

Doug,

You can already use the DIR parameter on ATTENDEE properties
for this purpose.

Cheers,
Bernard

Doug Royer wrote:
> 
> 
> Carsten Guenther wrote:
> 
>> I agree, and it begs the question if those two (CalDAV and CardDAV)  
>> should be rolled into one standard.
> 
> 
> This is really separate from CalDAV or CALSIFY:
> 
> I think that vCard and iCal should be able to be transported in
> the same multipart/related mime object so that the iCal object
> can transfer information needed about the entities.
> 
> This could also work with iMIP and any other transport.
> 
> If ATTENDEE were extended to include a ATTACH (or ATTACH like)
> parameter then the vCard could just be another attachment. Or
> maybe an ALTREP. Or maybe a new VCARD parameter that takes a URL
> value?
> 
> If it used a CID, then it could be embedded into the same
> MIME object, with that CID object specifying its own MIME
> type of vCARD.
> 
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Content-Class: urn:content-classes:message
Date: Wed, 19 Oct 2005 10:05:58 -0700
From: Cameron Stillion <[email-masked]>
To: "Carsten Guenther" <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Paterson <[email-masked]>, CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] RE: [Ietf-caldav] Off topic: CardDAV

I actually think there is value in having them separate - just as iCal
should never have contained tasks... They are fundamentally different
data types.  BUT, they need to have a connection.  The protocol and
schema should connect - clearly and purposefully.

cam

-----Original Message-----
From: Carsten Guenther [mailto:[email-masked]]=20
Sent: Wednesday.19.October.2005 09.41
To: Cameron Stillion
Cc: Mark Paterson; Cyrus Daboo; CalDAV DevList; CardDAV DevList
Subject: Re: [Ietf-caldav] Off topic: CardDAV

I agree, and it begs the question if those two (CalDAV and CardDAV)
should be rolled into one standard.

On Oct 19, 2005, at 9:38 AM, Cameron Stillion wrote:

>
> I would like to just add that strategically, vCard and iCal are=20
> intimately related.  Endeavors in this area are necessarily going to=20
> reference each other.  As soon as you begin implementing any PIM=20
> features of relative value, it becomes very clear.  Distributing=20
> Calendars needs a way to associate an owner with a calendar,=20
> especially the kind that represent your actual schedule, as opposed to

> the calendar for the little league team you coach on the weekends. =20
> Likewise, as soon as you begin distributing your contact information,=20
> the next piece you want to share is your schedule.  Both standards=20
> need to have a way to associate back and forth.  A standard or=20
> protocol that mentions one but not the other, is IMHO - incomplete,=20
> and unfinished.
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mark=20
> Paterson
> Sent: Wednesday.19.October.2005 08.59
> To: Cyrus Daboo
> Cc: CalDAV DevList; CardDAV DevList
> Subject: Re: [Ietf-caldav] Off topic: CardDAV
>
> Nice idea but you may want to consider a cardsify initiative to go=20
> 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=20
>> provides a set of WebDAV extensions and a data model for access to=20
>> vCard objects stored on a server. CardDAV is very similar to CalDAV=20
>> because of the similarities between iCalendar and vCard formats.
>>
>> There is a separate discussion list setup for CardDAV, so please=20
>> 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:  514.905.8649
> Mobile: 514.862.8505
> mailto: [email-masked]
> http:   www.oracle.com
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See=20
> http://ietf.webdav.org/caldav/ for more CalDAV resources=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See=20
> http://ietf.webdav.org/caldav/ for more CalDAV resources=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Date: Wed, 19 Oct 2005 09:41:27 -0700
From: "Carsten Guenther" <[email-masked]>
To: Cameron Stillion <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Paterson <[email-masked]>, CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV

I agree, and it begs the question if those two (CalDAV and CardDAV)  
should be rolled into one standard.

On Oct 19, 2005, at 9:38 AM, Cameron Stillion wrote:

>
> I would like to just add that strategically, vCard and iCal are
> intimately related.  Endeavors in this area are necessarily going to
> reference each other.  As soon as you begin implementing any PIM
> features of relative value, it becomes very clear.  Distributing
> Calendars needs a way to associate an owner with a calendar,  
> especially
> the kind that represent your actual schedule, as opposed to the  
> calendar
> for the little league team you coach on the weekends.  Likewise, as  
> soon
> as you begin distributing your contact information, the next piece you
> want to share is your schedule.  Both standards need to have a way to
> associate back and forth.  A standard or protocol that mentions one  
> but
> not the other, is IMHO - incomplete, and unfinished.
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mark
> Paterson
> Sent: Wednesday.19.October.2005 08.59
> To: Cyrus Daboo
> Cc: CalDAV DevList; CardDAV DevList
> Subject: Re: [Ietf-caldav] Off topic: CardDAV
>
> 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:  514.905.8649
> Mobile: 514.862.8505
> mailto: [email-masked]
> http:   www.oracle.com
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See
> http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Content-Class: urn:content-classes:message
Date: Wed, 19 Oct 2005 09:38:17 -0700
From: Cameron Stillion <[email-masked]>
To: "Mark Paterson" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] RE: [Ietf-caldav] Off topic: CardDAV

I would like to just add that strategically, vCard and iCal are
intimately related.  Endeavors in this area are necessarily going to
reference each other.  As soon as you begin implementing any PIM
features of relative value, it becomes very clear.  Distributing
Calendars needs a way to associate an owner with a calendar, especially
the kind that represent your actual schedule, as opposed to the calendar
for the little league team you coach on the weekends.  Likewise, as soon
as you begin distributing your contact information, the next piece you
want to share is your schedule.  Both standards need to have a way to
associate back and forth.  A standard or protocol that mentions one but
not the other, is IMHO - incomplete, and unfinished.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark
Paterson
Sent: Wednesday.19.October.2005 08.59
To: Cyrus Daboo
Cc: CalDAV DevList; CardDAV DevList
Subject: Re: [Ietf-caldav] Off topic: CardDAV

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.=20
> 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=20
> provides a set of WebDAV extensions and a data model for access to=20
> vCard objects stored on a server. CardDAV is very similar to CalDAV=20
> because of the similarities between iCalendar and vCard formats.
>
> There is a separate discussion list setup for CardDAV, so please=20
> 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:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 19 Oct 2005 11:59:00 -0400
From: Mark Paterson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV

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:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

Date: Tue, 18 Oct 2005 16:44:32 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Cc: CardDAV DevList <[email-masked]>
Subject: [Ietf-carddav] Off topic: CardDAV

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>

-- 
Cyrus Daboo