Subject: [Ietf-carddav] RFC2518 dependency (draft-daboo-carddav-02 review)
From: Julian Reschke <[email-masked]>
To: [email-masked]
Date: Sun, 27 May 2007 18:45:27 +0200
List-Id: ietf-carddav.osafoundation.org

Hi,

I have started to review the latest draft, but haven't finished yet. 
However, it seems that some points merit separate discussion threads 
anyway, so I'll start with one of those.

Right now, draft-daboo-carddav-02 has a normative dependence on RFC2518, 
and mentions RFC2518bis only informatively. Is this an oversight?

Here's what I'd propose:

- get rid of RFC2518 reference
- make RFC2518bis reference normative (update all references to RFC2518 
accordingly)
- require DAV class 3 support
- RFC3253 is cited for some things that have been updated by RFC2518bis, 
such as pre/postcondition definitions, DAV:error marshalling, and the 
definition of "protected property" -- please update those to refer to 
RFC2518bis (I guess the only RFC3253 dependencies should be on things 
related to the REPORT method).

Best regards, Julian

Date: Thu, 10 May 2007 15:20:54 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE: [Ietf-carddav] carddav and corporate directories
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, [email-masked]

=20

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:[email-masked]]=20
> Envoy=E9 : mercredi 9 mai 2007 18:56
> =C0 : Arnaud Quillaud; [email-masked]
> Objet : Re: [Ietf-carddav] carddav and corporate directories
>=20
> Hi Arnaud,
>=20
> --On May 9, 2007 6:36:45 PM +0200 Arnaud Quillaud=20
> <[email-masked]>
> wrote:
>=20
> > Although it mentions LDAP in its introduction, the spec=20
> does not talk=20
> > about the link between Corporate Directory access and=20
> CardDAV access.
> >
> > Most PIM or email clients that would benefit from a CardDAV acces=
s=20
> > also offer some access to corporate directories, usually LDAP=
=20
> > directories. For an end user, they almost serve the same=20
> purpose (e.g.=20
> > when sending an email, I may select some people from my personal=
=20
> > address book and some from my corporate directory).
> >
> > Nevertheless:
> > - configuring those clients is usually a real pain: server name a=
nd=20
> > port, ssl or no ssl, base dn, search filter, bind dn, etc... - ea=
ch=20
> > client has to deal with schema translation between the corporate=
=20
> > directory schema and the internal representation.
> >
> > Being able from CardDAV to discover public address books=20
> would greatly=20
> > enhance the user experience.  Being able to work against one form=
at
> > (vCard) instead of 2 (vCard + some LDAP schema) would ease=20
> development=20
> > of address book enabled applications.
> >
>=20
> There is nothing to stop a CardDAV server from also being a=20
> (read-only) gateway to LDAP. i.e. the CardDAV server could=20
> expose a public address book that is "backed" by an LDAP=20
> server, so that addresses in the address book were actual=20
> directory entries in LDAP (with the appropriate LDAP->vCard mapping=
).
>=20
> In fact CMU had an extension to IMSP that did just that.
>=20
> I don't think we need to do anything special in CardDAV=20
> itself for this - an implementation could just choose to do=20
> it. The only thing that might be nice would be to have some=20
> WebDAV properties on the mapped addressbook indicating where=20
> the underlying LDAP server is etc But I think that could be=20
> written up as an extension.
>=20

I aggree. One issue related to the CardDAV design is that an LDAP tre=
e can be hierarchical when CardDAV does not allow sub addressbooks. N=
evertheless, most email/pim clients flatten out the hierarchy anyway.

> The only thing that might be missing (and CalDAV has this=20
> issue too) is some way for a client to discover where public=20
> address books/calendars might be. At one point during the=20
> CalDAV discussions there was talk of something like the IMAP=20
> NAMESPACE extension - done as a WebDAV REPORT, say
> - that clients could use to find out the locations of "interesting"=
=20
> calendars or calendar hierarchies that would be good to=20
> present to the user. I still think something like that would=20
> be useful and could be used for CardDAV clients to discover=20
> where the "corporate directory mapped address book" is on the serve=
r.

What about simply defining another Principal Property (similar to adb=
k-home-set) that would contain a set of public address books ?

Unlike "interesting calendars", there is usually a very limited list =
of corporate directories.

Arnaud Q

Date: Thu, 10 May 2007 14:51:58 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE: [Ietf-carddav] minor comments on -01 draft
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, [email-masked]

> >
> > 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?
> 

I brought this up mainly to get a confirmation from the list that no existing software actually does what I have described. Unless somebody objects, I think you should stick with your original design.

Arnaud

Date: Wed, 09 May 2007 10:24:28 -0700
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-carddav] minor comments on -01 draft

Hi Arnaud,

--On May 9, 2007 5:44:34 PM +0200 Arnaud Quillaud <[email-masked]> 
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

Date: Wed, 09 May 2007 09:56:04 -0700
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-carddav] carddav and corporate directories

Hi Arnaud,

--On May 9, 2007 6:36:45 PM +0200 Arnaud Quillaud <[email-masked]> 
wrote:

> Although it mentions LDAP in its introduction, the spec does not talk
> about the link between Corporate Directory access and CardDAV access.
>
> Most PIM or email clients that would benefit from a CardDAV access also
> offer some access to corporate directories, usually LDAP directories. For
> an end user, they almost serve the same purpose (e.g. when sending an
> email, I may select some people from my personal address book and some
> from my corporate directory).
>
> Nevertheless:
> - configuring those clients is usually a real pain: server name and port,
> ssl or no ssl, base dn, search filter, bind dn, etc... - each client has
> to deal with schema translation between the corporate directory schema
> and the internal representation.
>
> Being able from CardDAV to discover public address books would greatly
> enhance the user experience.  Being able to work against one format
> (vCard) instead of 2 (vCard + some LDAP schema) would ease development of
> address book enabled applications.
>

There is nothing to stop a CardDAV server from also being a (read-only) 
gateway to LDAP. i.e. the CardDAV server could expose a public address book 
that is "backed" by an LDAP server, so that addresses in the address book 
were actual directory entries in LDAP (with the appropriate LDAP->vCard 
mapping).

In fact CMU had an extension to IMSP that did just that.

I don't think we need to do anything special in CardDAV itself for this - 
an implementation could just choose to do it. The only thing that might be 
nice would be to have some WebDAV properties on the mapped addressbook 
indicating where the underlying LDAP server is etc But I think that could 
be written up as an extension.

The only thing that might be missing (and CalDAV has this issue too) is 
some way for a client to discover where public address books/calendars 
might be. At one point during the CalDAV discussions there was talk of 
something like the IMAP NAMESPACE extension - done as a WebDAV REPORT, say 
- that clients could use to find out the locations of "interesting" 
calendars or calendar hierarchies that would be good to present to the 
user. I still think something like that would be useful and could be used 
for CardDAV clients to discover where the "corporate directory mapped 
address book" is on the server.

-- 
Cyrus Daboo

Content-return: prohibited
Date: Wed, 09 May 2007 18:36:45 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-carddav] carddav and corporate directories

Hello,

Although it mentions LDAP in its introduction, the spec does not talk about the link between Corporate Directory access and CardDAV access.

Most PIM or email clients that would benefit from a CardDAV access also offer some access to corporate directories, usually LDAP directories. For an end user, they almost serve the same purpose (e.g. when sending an email, I may select some people from my personal address book and some from my corporate directory).

Nevertheless:
- configuring those clients is usually a real pain: server name and port, ssl or no ssl, base dn, search filter, bind dn, etc...
- each client has to deal with schema translation between the corporate directory schema and the internal representation.

Being able from CardDAV to discover public address books would greatly enhance the user experience. 
Being able to work against one format (vCard) instead of 2 (vCard + some LDAP schema) would ease development of address book enabled applications.

Arnaud Q

Content-return: prohibited
Date: Wed, 09 May 2007 17:44:34 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-carddav] minor comments on -01 draft

Some (rather minor) comments on the CardDAV Draft.

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.

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 ?

 
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 ?

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

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 ( http://tools.ietf.org/html/rfc4790 ).

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"

Arnaud Q

Content-return: prohibited
Date: Wed, 09 May 2007 17:34:12 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-carddav] sorting, grouping, paging in CardDAV

Going through the CardDAV mailing list. One message mentions the "Employee Profile Service Specification and the Personal Profile Service Specification created by the Liberty Alliance".

So here I went, to discover that not only do they have such services, but they have also defined a Contact Book Service:

See http://www.projectliberty.org/liberty/content/download/2441/15790/file/liberty-id-sis-contactbook-guidelines-v1.0.pdf and http://www.projectliberty.org/liberty/content/download/2440/15787/file/liberty-id-sis-cb-v1.0.pdf from http://www.projectliberty.org/resource_center/specifications/liberty_alliance_id_sis_1_0_specifications

The spec defines a mapping between vCard 2.1 (http://www.imc.org/pdi/vcard-21.txt), vCard v3 (http://tools.ietf.org/html/rfc2426), vCardRDF (http://www.w3.org/TR/vcard-rdf) and a "Generic vCard" data model, itself based on some XML representation of vCards (http://www.xmpp.org/extensions/xep-0054.html). All (XPATH) queries are done against the data model but the data can be returned (or stored) in any of the other vCard formats (2.1, 3, RDF).

The spec is a little bit hard to digest for someone not familiar with the Liberty Alliance architecture and terminology but it covers 3 functionalities that I would consider key for a Contact Book protocol/service:

    * ability to sort vCards based on some field,
    * ability to group vCards together (they use the term "Distribution List"),
    * ability to get paged results (give me back the first 20 entries, then the next 20,...)

(The third feature is actually define in a more general Data Web Service Specification)

The -01 CardDAV draft does not cover those functionalities. While sorting and paging could probably be added as extensions to the base protocol, I would consider groups as a core functionality because it defines a new type of object (at least at the conceptual level).

The Liberty Alliance Contact Book Service has taken the approach of modeling groups as regular vCard entries with the membership being define in each child vCard as a backpointer to some UID like property (CARDID) of the group. This is in a sense similar to the notion of dynamic groups in LDAP.

Back to carddav, the adbk-query could be used as is to retrieve all the direct members of a given group.

A few other interesting things in the Contact Book Service:

    * ability to tag one vCard as describing SELF (the owner of the book),
    * notion of a predefined "Favorites" group,
    * notion of most frequently/recently requested entries.

I have not spent a lot of time trying to get an in depth understanding of the Liberty Web Services. But my initial feeling is that I don't really see the CardDAV protocol and the Contact Book Web Service as competing technologies. On the other hand, keeping them close enough so that one could "easily" build the Web Service on top of protocol would be nice.

Arnaud Q