Subject: [VCARDDAV] Comments on draft-ietf-vcarddav-carddav-05

From: Simon Vaillancourt <[email-masked]>
Date: Mon, 02 Mar 2009 15:02:24 -0500

Hello,

Here are some comments:
7.1.1:
 > Typically, users will group all the address book collections that 
they own under a common collection. 
I would rephrase to "Typically, users will group the entire address book 
collections that they own under a common collection."

 > 7.1.2.  CARDDAV:principal-address
I find the description of this property a bit vague: "The 
CARDDAV:principal-address property is meant to allow users to easily 
find contact information for users represented by principals on the 
system".  I'm having a hard time figuring out how it could be used in a 
real application, could you please provide concrete use-cases for this 
property?

Other than that it looks pretty good!

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 02 Mar 2009 15:14:33 -0500

Simon Vaillancourt wrote:
> 7.1.1:
>> Typically, users will group all the address book collections that they
> own under a common collection. I would rephrase to "Typically, users
> will group the entire address book collections that they own under a
> common collection."

This change confuses me. What's the difference?

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Helge Hess <[email-masked]>
Date: Mon, 2 Mar 2009 21:17:40 +0100

On 02.03.2009, at 21:02, Simon Vaillancourt wrote:
> system".  I'm having a hard time figuring out how it could be used  
> in a real application, could you please provide concrete use-cases  
> for this property?

I think the listed example is a pretty good explanation:
   <C:principal-address xmlns:D="DAV:"    xmlns:C="urn:ietf:params:xml:ns:carddav 
"> <D:href>http://addressbook.example.com/system/cyrus.vcf</D:href> </ 
C:principal-address>
The client somehow got access to a principal URL (eg it queried the  
members of a group) and wants to show more information about the  
principal. The URL then points to the vCard which contains the actual  
info. Pretty nice and something I like to have.

Note: I think it will be very common that the principal URL itself is  
ALSO the principal-address. If a PROPFIND is run on it, it will return  
the appropriate principal properties, if a GET is issued, it would  
return a vCard.

Thanks,
   Helge
-- 
Helge Hess
http://zideone.com/

---

From: Simon Vaillancourt <[email-masked]>
Date: Mon, 02 Mar 2009 15:24:01 -0500

I just ran it through a spell checker which suggested to replace "all
the" with "the entire" so after asking a tech writer here, he agreed it
sounded better. Both sentences mean the same thing, it's just that one
is sounding slightly better. Yes, that is a bit nitpicky.

Simon Perreault wrote:

7.1.1:

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 02 Mar 2009 15:29:16 -0500

Hi Simon,

--On March 2, 2009 3:24:01 PM -0500 Simon Vaillancourt 
<[email-masked]> wrote:

> sounded better. Both sentences mean the same thing, it's just that one is
> sounding slightly better. Yes, that is a bit nitpicky.

I think the spell checker is being dumb. It is only considering "all the 
address" which would be wrong by itself, rather than "all the address book 
collections" which is fine. Now if you really prefer "the entire" it would 
be better as "the entire set of address book collections ...".

-- 
Cyrus Daboo

---

From: Simon Vaillancourt <[email-masked]>
Date: Mon, 02 Mar 2009 15:39:19 -0500

I don't mind, really, I should have put more context in the suggestion 
itself and maybe add a "take it only if you like it" note. I think we 
have wasted enough bytes talking about it :)

Cyrus Daboo wrote:
> I think the spell checker is being dumb. It is only considering "all 
> the address" which would be wrong by itself, rather than "all the 
> address book collections" which is fine. Now if you really prefer "the 
> entire" it would be better as "the entire set of address book 
> collections ...".
>

---

From: Simon Vaillancourt <[email-masked]>
Date: Mon, 02 Mar 2009 21:11:17 -0500

Hello,
 Correct me if I'm wrong but I think you are suggesting that some 
implementations will represent the "principal hierarchy" not only as a 
DAV principal hierarchy but also as a shared, "global address book", for 
all users of a system(At the same location like you propose or in 
another location that mirrors the actual principal hierarchy). I do 
agree that this concept will probably be picked up by many implementors.

What I find interesting is that you imply that client implementors could 
offer to their users the ability to parse DAV groups in order to 
retrieve the contact information of principals that are members of that 
group.

To sum things up "Group Views" could be exposed to users of an 
application by:
- Creating different address book collections for each groups (and maybe 
use bind to have the same contact in different groups?).
- Using the vCard Categories property to group contacts.
- Use the DAV principal groups (for which principal-address would be 
useful, for the "global address book" only).

The issue I have with your use case is effectiveness; one would need to 
read the principal to get the contact url property before actually 
loading it. But it does show that the property can be useful.

Thanks,
Simon

Helge Hess wrote:
>> system".  I'm having a hard time figuring out how it could be used in 
>> a real application, could you please provide concrete use-cases for 
>> this property?
>
>   <C:principal-address xmlns:D="DAV:"    
> xmlns:C="urn:ietf:params:xml:ns:carddav"> 
> <D:href>http://addressbook.example.com/system/cyrus.vcf</D:href> 
> </C:principal-address>

---

From: Mike Douglass <[email-masked]>
Date: Tue, 03 Mar 2009 00:40:43 -0500

I'm mostly fine with the draft. I do have some issues with locking however.

A carddav server is likely to be used as a front end to an enterprise
directory which may be updated through other methods - clients must
still expect that directory data will be updated.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Helge Hess <[email-masked]>
Date: Tue, 3 Mar 2009 15:05:55 +0100

Hi,

On 03.03.2009, at 03:11, Simon Vaillancourt wrote:
> implementations will represent the "principal hierarchy" not only as  
> a DAV principal hierarchy but also as a shared, "global address  
> book", for all users of a system(At the same location like you  
> propose or in another location that mirrors the actual principal  
> hierarchy).

Yes, something like that.

Eg iCalServer works like that (for calendars). Eg, when an iCal server  
principal is entered in our plugin, it sets up a hierarchy like this:

   /		[principal URL]
     /calendars	[homeset property of principal]
     /groups	[membership property of principal]
       /abc	[group principal URL]
       /def	[group principal URL]

Hm, interesting. Actually it would be cool if the group principal URL  
would be an addressbook-collection at the same time, containing vCards  
of the members :-)

Another example is SOGo where the 'entry point URL' is something like:

   http://sogo-demo.inverse.ca/SOGo/so/USER/

In this case that URL is many things:
a) the principal URL for USER (resourcetype queried via PROPFIND)
b) the collection root (~ homeset) for the USER, eg it goes down:
    /USER/calendars, /USER/calendars/personal, etc
c) the root of the Web interface

And I think it would be quite cool if a GET with "Accept: text/x- 
vcard" would return a vCard with a representation of the LDAP  
information on the user.

Note: some servers embed principal information like firstname/lastname  
in additional WebDAV properties. IMHO thats not a good idea, it should  
be a GETable resource with proper ETag support.

> What I find interesting is that you imply that client implementors  
> could offer to their users the ability to parse DAV groups in order  
> to retrieve the contact information of principals that are members  
> of that group.

Yes. Also important to acquire freebusy information in CalDAV scenarios.

> The issue I have with your use case is effectiveness; one would need  
> to read the principal to get the contact url property before  
> actually loading it. But it does show that the property can be useful.

You usually get that anyways for other reasons. And the vCard URL for  
the principal can be queried in a bulk way.

Greets,
   Helge
-- 
Helge Hess
http://helgehess.eu/