[Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV
Mark Paterson <mark.paterson@oracle.com> Tue, 25 October 2005 18:50 UTC
Return-Path: <mark.paterson@oracle.com>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A8CDE7F553 for <ietf-carddav@osafoundation.org>; Tue, 25 Oct 2005 11:50:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BA8C142279 for <ietf-carddav@osafoundation.org>; Tue, 25 Oct 2005 11:50:35 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23971-01 for <ietf-carddav@osafoundation.org>; Tue, 25 Oct 2005 11:50:35 -0700 (PDT)
Received: from rgminet03.oracle.com (rgminet03.oracle.com [148.87.122.32]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 19C63142275 for <ietf-carddav@osafoundation.org>; Tue, 25 Oct 2005 11:50:35 -0700 (PDT)
Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j9PIoVse012545; Tue, 25 Oct 2005 12:50:31 -0600
Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j9PIoUqT017387; Tue, 25 Oct 2005 12:50:31 -0600
Received: from [144.23.213.92] (dhcp-ca-montreal2-144-23-213-92.ca.oracle.com [144.23.213.92]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PIoRhe017363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Oct 2005 12:50:28 -0600
Message-ID: <435E7E70.1000100@oracle.com>
Date: Tue, 25 Oct 2005 14:50:24 -0400
From: Mark Paterson <mark.paterson@oracle.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
References: <43A9189ABDD96F8A4BCB7FE1@port35.educause58.ucf.edu> <43566D44.7090406@oracle.com>
In-Reply-To: <43566D44.7090406@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level:
Cc: Bernard Desruisseaux <BERNARD.DESRUISSEAUX@oracle.com>, CardDAV DevList <ietf-carddav@osafoundation.org>
Subject: [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardDAV
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2005 18:50:35 -0000
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: mark.paterson@oracle.com http: www.oracle.com
- [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardD… Cyrus Daboo
- [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardD… Mark Paterson
- [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardD… Bernard Desruisseaux
- [Ietf-carddav] RE: [Ietf-caldav] Off topic: CardD… Cameron Stillion
- [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardD… Carsten Guenther
- [Ietf-carddav] RE: [Ietf-caldav] Off topic: CardD… Cameron Stillion
- [Ietf-carddav] Re: [Ietf-caldav] Off topic: CardD… Mark Paterson
- [Ietf-carddav] Off topic: CardDAV Cyrus Daboo