[Ietf-carddav] minor comments on -01 draft

[Cyrus Daboo]

Hi Arnaud,

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

> 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
> (http://tools.ietf.org/html/rfc2426#section-3.6.7), 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.


OK.

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

Fixed.

> 8.3. Searching Text: Collations
> (and other places)
>
> draft-newman-i18n-comparator is now RFC 4790 (
> http://tools.ietf.org/html/rfc4790 ).

Fixed.

> 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