Re: [Ietf-carddav] minor comments on -01 draft

Cyrus Daboo <> Wed, 09 May 2007 17:25 UTC

Return-Path: <>
Received: from ( []) by (Postfix) with ESMTP id 8BE347F66D for <>; Wed, 9 May 2007 10:25:36 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 540A4142276 for <>; Wed, 9 May 2007 10:24:41 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at
X-Spam-Score: -2.241
X-Spam-Status: No, score=-2.241 tagged_above=-50 required=4 tests=[AWL=0.281, BAYES_00=-2.599, TW_BD=0.077]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ynWWdAxNUeKj for <>; Wed, 9 May 2007 10:24:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 82583142274 for <>; Wed, 9 May 2007 10:24:38 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id l49HOXre006177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 13:24:36 -0400
Date: Wed, 09 May 2007 10:24:28 -0700
From: Cyrus Daboo <>
To: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>,
Subject: Re: [Ietf-carddav] minor comments on -01 draft
Message-ID: <6CABE81803E106CF3F247E47@caldav3.local>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 May 2007 17:25:36 -0000

Hi Arnaud,

--On May 9, 2007 5:44:34 PM +0200 Arnaud Quillaud <Arnaud.Quillaud@Sun.COM> 

> First of all, I find the name ("adbk") a little bit cryptic.
> "addressbook", "contactbook" would be more clear although a bit long
> since the name is used as a prefix in most xml elements.

OK, I think changing adbk -> addressbook is fine and will do that in -02.

> 1. Introduction and Overview
> ACAP, LDAP and WebDAV are mentioned but SyncML is missing. Shouldn't we
> mention it and explain how it does not address the need ?

OK, I have added a stub section for SyncML. Feel free to send me some 
appropriate text for that, and for the other protocols if you have any 
additional suggestions.

> 3. Requirements Overview:
> Why is the support for MKADDRB a MUST when it is a SHOULD for CalDAV ?
> Not that I care that much but why the difference ?

SHOULD is probably better for the same reasons we have it that way in 
CalDAV. I will change that.

> 5.1 vCard Object Resources
> "UID must be unique within a collection".
> Nevertheless, according to the UID definition in vCard
> (, the UID identifies
> the individual or resource. So potentially, you could have a personal
> vCard and a business vCard corresponding to the same individual. I doubt
> that it will be the case in practice but who knows...

We do need some unique identifier in the vCard data so UID seems to fit the 
bill. Perhaps we can allow vCards with the same UID but require them to be 
stored in the same WebDAV resource?

> 6.2.1 adbk-description
> Although my native language is just "fr" (or is it fr-FR ?) and not
> "fr-CA", I suspect that "Address de Oliver Daboo" is not really correct.
> "Adresses de Oliver Daboo" would be more appropriate.


> 6.3.2.  Creating vCard Object Resources
> The UID property is missing from the example although it is a mandatory
> property.


> 8.3. Searching Text: Collations
> (and other places)
> draft-newman-i18n-comparator is now RFC 4790 (
> ).


> 8.8.  CARDDAV:adbk-sync Report:
> It is mentioned that
> <<
> The "adbk-sync" reports allows the client to specify whether it
>    should receive vCard data for those objects that are new or have
>    changed, and it uses the "adbk-data" element (also used in the "adbk-
>    query" and "adbk-multiget" reports) for that purpose.
> Nevertheless, in the XML definition for abbk-sync (10.9.
> CARDDAV:adbk-sync XML Element) lacks "(DAV:allprop | DAV:propname |
> DAV:prop)?" as potential children.
> BTW, wouldn't it be possible to move the whole abdk-sync report
> definition into another draft so that a common mechanism could be used
> against other types of collections (WebDAV, CalDAV,...) ?
> Still in 8.8, it says "The response body for a successful
> CARDDAV:adbk-multiget REPORT" instead of "The response body for a
> successful CARDDAV:adbk-sync REPORT"

Yes, I was planning on removing the sync stuff from the -02 draft and 
writing a separate generic WebDAV collection synchronization spec, that 
WebDAV or any derivative protocols (CalDAV, CardDAV etc) could use.

Cyrus Daboo