Re: [VCARDDAV] ping? anybody out there?

[Cyrus Daboo <[e-mail]>]

Hi Greg,

--On November 8, 2007 5:57:39 PM -0800 Greg Stein <[e-mail]> wrote:

>> Actually that wouldn't give you the same level of capability as the
>> current query report which lets you query specific properties within the
>> vCard
>
> RFC 3744, section 9.4 doesn't actually specify the search. The
> vcarddav spec *could* do that, however. Thus, you could have do a
> property search on the "vcard" property, with parameters saying "ADR"
> and "sometext". This could be as simple as adding a new attribute to
> the DAV:match element:
>
> <property-search>
>   <prop><vcard/></prop>
>   <match vcard-constraint="ADR">sometext</match>
> </property-search>

Right, but you will pretty much re-invent the current calendar query syntax 
for matching. Its also complicated by i18n issues and match type issues 
(e.g. an address completion operation really needs a "starts-with" match 
operation rather than a "contains" match).

The other thing that the current spec gives is partial retrieval of the 
data. i.e. an email client doing address completion rally only cares about 
the full-name and email addresses - there is no point in it getting ADR or 
PHOTO properties (particularly as PHOTO could be large). Given hat address 
completion must be fast to match user expectations, minimizing the amount 
of data returned is critical. If you stuff the vCard into a property, you 
would have to invent some kind of partial retrieval mechanism for that.

>> ...
>> But how do you create your own contacts, as opposed to contacts already
>> on
>
> A simple PUT and PROPPATCH, I'd think.

So what happens in the case where two users want to maintain there own 
copies of a vCard for the same person, so that they can have their own 
notes or annotations? How would you identify those as separate for each 
user? Wouldn't you have to have some kind of per-user principal hierarchy 
so each could maintain their own? That's pretty much the same as each 
having their own address book.

>> the system? e.g. I want to be able to add contact information for my wife
>> on my corporate carddav server. Are you saying I have to create a
>> principal first? I don't hink that is going to fly as a principal has a
>> lot more significance on a webdav server than a simple contact.
>
> I don't see a problem with it. The server can define where that
> principal goes. Local or pushed back into some kind of directory.

I am extremely nervous about tying address creation to principal creation. 
Principals are tied to authentication/authorization in WebDAV. Having users 
able to create those themselves seems to me to be a layering violation - 
and a critical one given that principals have a significant role to play in 
the security of the system.

Also, some systems do not make principal resources visible to users for 
security/privacy reasons (e.g. it can expose information about group 
membership etc). Those types of servers would not be able to support the 
principal-as-vcard model.

> I can easily see the server representing the address book as a bunch
> of records. *Some* of those records point to the "canonical" location
> of all directory-based prinicpals. Some are free-floating records
> which do not include that pointer. These principals' canonical
> location is the address book itself (sort of "detached", you might
> say).
>
>> That said, I think its not unreasonable to have either a vcard attribute
>> on principals that contains the contact data for that principal, or for
>> the server to maintain a special address book populated with vcards for
>> all principals on the system (we would then have a property somewhere
>> pointing

> Though I think Julian has issues with putting stuff into the resource
> body. Or maybe that was just an issue with surfacing that data as
> *both* a body and a property. Maybe Julian can elaborate.

The body is problematic because some servers may treat principal resources 
as collections (the Apple CalDAV server does that because we have per-user 
principals defined below the main principals that are used for setting up 
calendar delegate/proxy access).

I think my preference right now is this: define a <my-vcard> property on 
principal resources. That will contain a single href pointing to a vcard 
resource. That resource could be one in a "system" address book that 
mirrors the "directory" used to back the principals. Or it could point to 
the principal itself, if the principal resource contains the vCard data. We 
could then have a <principal-addressbook> property defined on all resources 
(similar to <principal-collection-set>) that defines the location (or 
locations) of an addressbook collection containing the vcards of the 
principals. That could point to the "system" address book, or it could 
point to the principal collection itself if the body of principals is the 
vCard.

What this means is that clients may have to do two queries depending on 
what it is doing. One query on the personal address books and one on the 
principal-address book.

>> Ah. Access control.


> In the absence of access control, I'd recommend a label property and
> being able to search that. IIRC, Outlook uses the label-style system
> (but man... it's been a while; anybody?). I know Google is pretty
> label-happy in our products, but it doesn't appear we can do that for
> contacts (well, maybe our groups could be seen as a label).

You're in luck! vCard defines the CATEGORIES property that can easily be 
used for labelling/tagging and can be queried as a vCard property value.

>> Yes it is possible to get by with a single address book and manage the
>> ACLs indepdently on each contact, but that is a lot more work for
>> clients and harder for users.
>
> Agreed. I could easily see a departmental or company address book,
> separate from your personal work abook, separate from your
> personal/home abook.

Yes, this is an important use case. Whilst you could tag/label (as you 
suggest) managing ACLs means doing that on a per-resource basis. One of the 
things being discussed a lot right now in Calconnect's CalDAV technical 
committee is an approach using groups that tries to minimize the number of 
times a client has to use ACL. The calendar proxy/delegate approach I 
discussed above does just that - in fact the client never has to use ACL - 
instead all it does is change group membership in certain principals to 
make another user a delegate.

>> > The last part is about synchronization. I think the vcarddav spec
>> > shouldn't deal with it at all, and just use things like the (draft)
>> > "getctag" property and/or the draft synchronization protocol.
>>
>> The synchronization stuff is no longer in the spec.
>
> Cool. In favor of your other draft, I presume?

Yes. There were a few comments on the sync spec a while back, but I am 
afraid I have been too busy to follow up on those. My goal is to get 
carddav (and the extended MKCOl draft I also have) out before Monday and 
try to get consensus on those towards moving to IETF last call. Then it 
will be time to concentrate on protocol optimization elements such as the 
sync spec and also the PATCH spec (we'll need to define a good diff format 
optimized for iCalendar/vCard style data to make that work well for us in 
the presence of the partial retrieval mode we have for the data in CalDAV 
and CardDAV).

-- 
Cyrus Daboo


_______________________________________________
VCARDDAV mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/vcarddav