Subject: [VCARDDAV] ping? anybody out there?

From: "Greg Stein" <[email-masked]>
Date: Thu, 8 Nov 2007 15:08:38 -0800

Hey all,

The archives are looking busted, or the list is relatively dead :-P

I've been reading Cyrus' draft, and have a few high-level comments:

* I recognize it as being almost a direct search/replace of "calendar"
with "vcard". I think that makes it overly-complicated when you're
just talking about contacts.

* I think it should use Principals MUCH more. For example, the vCard
should just be a property on a Principal. In this scenario, an
"address book" is simply a collection of Principal resources. Even
better, you can use all the REPORT types for Principals to locate
people. No address-book-specific reports needed.

* Adding Principals would either be a COPY or a BIND into your address
book. Note that the DAV:principal-URL on these will always tell you
where a Principal's canonical location is. These are mere copies (or
via BIND, a reflection)

* By using Principals, there could be other data broken out into
properties which could be mapped to/from the vCard data.

The second part of my feedback deals with the notion of multiple
address books. This seems a bit strange... is that *really* a true use
case? I see a use case for two types of collections of Principals:

1) the set of Principals that I maintain manually. my "address book / contacts"

2) the set of Principals which can auto-fill in (say) an email To:
field. this will autofill from my Contacts, but *also* from all the
people that I've ever sent/received email or chatted with or whatever.

In this sense, I think it would be important to have a property to
programmatically distinguish between the two cases so that the
vcarddav client can use the appropriate collection for each purpose.
For example, the autofill collection would have both DAV:collection
and a DAV:all-known-principals in its DAV:resourcetype. (and yeah, a
server MAY return a failure if you try a Depth:1 PROPFIND on that
collection).

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.

Cheers,
-g

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

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Nov 2007 20:32:10 -0400

Hi Greg,

> just talking about contacts.

It follows the same data model - but doesn't have the added complexity 
needed for scheduling etc

> people. No address-book-specific reports needed.

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 
object itself (e.g. search for specific text in the ADR property only). If 
you stuff the entire vcard into a WebDAV property you would not get that 
level of granularity using the principal-property-search report.

> properties which could be mapped to/from the vCard data.

But how do you create your own contacts, as opposed to contacts already on 
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.

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 
to that). Or maybe the principal resource itself is a vCard, so the 
principal collections are just address books.

> case? I see a use case for two types of collections of Principals:

Its the same argument as for multiple calendars. Multiple address books 
provide a convenient way to group together contacts and maintain those all 
under the same access control privileges (via the ACLs on the collection). 
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.

> "getctag" property and/or the draft synchronization protocol.

The synchronization stuff is no longer in the spec.

I will have a new revision out before the submission deadline next Monday.

-- 
Cyrus Daboo

---

From: "Greg Stein" <[email-masked]>
Date: Thu, 8 Nov 2007 17:57:39 -0800

Thanks for the response! See below...

On Nov 8, 2007 4:32 PM, Cyrus Daboo <[email-masked]> wrote:
>...

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>

>...

A simple PUT and PROPPATCH, I'd think.

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

> principals on the system (we would then have a property somewhere pointing

Cool.

And note that "all principals" is necessarily implying "that you can
see", which can be used well for an autofill field.

> principal collections are just address books.

Yup.

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.

> under the same access control privileges (via the ACLs on the collection).

Ah. Access control.

Okay. I was thinking in terms of a personal address book. In that
case, I'd just be tagging the principals with different labels and
doing a DAV:principal-property-search to find contacts with a specific
label.

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

> indepdently on each contact, but that is a lot more work for clients and

Agreed. I could easily see a departmental or company address book,
separate from your personal work abook, separate from your
personal/home abook.

> The synchronization stuff is no longer in the spec.

Cool. In favor of your other draft, I presume?

Thanks,
-g

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2007 10:31:14 +0100

>   <match vcard-constraint="ADR">sometext</match>

Right. Or a new report could be defined.

So this is orthogonal to the question whether principals should be used, 
IMHO.

> *both* a body and a property. Maybe Julian can elaborate.

Actually, I have no problem with data being in the body, in the 
properties, or both.

What I have a problem with is to put the data into the body, *not* 
expose them as properties, and then to create "pseudo-properties", where 
data from the content sometimes behaves like a property, and sometimes 
doesn't.

Just be consistent.

So... Is there anything VCARDDAV related going on in Vancouver? I don't 
see anything on the agenda so far...

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 09 Nov 2007 11:51:54 -0500

Hi Julian,

--On November 9, 2007 10:31:14 AM +0100 Julian Reschke 
<[email-masked]> wrote:

> What I have a problem with is to put the data into the body, *not* expose
> them as properties, and then to create "pseudo-properties", where data
> from the content sometimes behaves like a property, and sometimes doesn't.

I am not averse to changing the multiget and query reports in CardDAV so 
that the <address-data> element is outside of the <prop> elements in the 
request. The issue is with the response, however. Since the response comes 
back as multi-status with a DAV:response element for each match, the 
question is how to represent the data in the existing DAV:response. The 
problem we had before that lead to the current state in CalDAV and CardDAV 
is how to deal with partial failure - e.g. properties could be read, but 
the body could not (which could happen if ACLs are setup that way).

So right now we have something like:

     <D:response>
       <D:href>/home/bernard/addressbook/v104.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"23ba4d-ff11fc"</D:getetag>
           <C:addressbook-data>BEGIN:VCARD
   VERSION:3.0
   NICKNAME:oliver
   UID:[email-masked]
   FN:Oliver Daboo
   EMAIL:[email-masked]
   END:VCARD
   </C:addressbook-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>

Because <addressbook-data> is a "pseudo" property, if there is a problem 
with the data, it can be returned in a separate propstat with its own 
status indicating the error.

However, if we treat it not as a property, we will need to add some 
additional XML element wrappers to allow its status to be indicated 
separately. e.g.:

     <D:response>
       <D:href>/home/bernard/addressbook/v104.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"23ba4d-ff11fc"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:datastat>
         <C:data>BEGIN:VCARD
   VERSION:3.0
   NICKNAME:oliver
   UID:[email-masked]
   FN:Oliver Daboo
   EMAIL:[email-masked]
   END:VCARD
   </C:data>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:datatat>
     </D:response>

i.e. we need something like <datastat> that con contain a <data> element 
with the actual data and a <status> element. That is a much more 
significant change to the XML definition of DAV:response. However, its just 
XML which is supposed to be easily extensible, so it likely won't be 
difficult to implement.

Is there consensus for such a change along the lines outlined above? Do 
people have other suggestions as to how to not have the data returned as a 
pseudo property?

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 09 Nov 2007 12:22:59 -0500

Hi Greg,

--On November 8, 2007 5:57:39 PM -0800 Greg Stein <[email-masked]> 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
>

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.

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

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

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

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

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

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.

> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2007 19:22:49 +0100

Cyrus Daboo wrote:
> significant change to the XML definition of DAV:response. However, its 
> just XML which is supposed to be easily extensible, so it likely won't 
> be difficult to implement.
> 
> people have other suggestions as to how to not have the data returned as 
> a pseudo property?
> ...

Hi Cyrus,

yes, that's more or less what I had in mind. Either make the 
pseudo-property a real property -- subject to PROPFIND and PROPPATCH, or 
don't ab^H^Hreuse DAV:prop.

So, wouldn't it *much* simpler to make it a full-blown property, 
potentially hidden from PROPFIND/allprop and not writeable in PROPPATCH?

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 09 Nov 2007 13:30:21 -0500

Hi Julian,

> potentially hidden from PROPFIND/allprop and not writeable in PROPPATCH?

The question is whether you want this to be generalized to all WebDAV 
resources, not just calendar/vcard. i.e. should the body of a resource be 
available via a DAV:data property. There are lots of issues with that, of 
course. We would need attributes on the property to indicate content-type, 
we would need to decide how Accept- headers effect what is returned in the 
property etc.

Maybe that is the better way to go in the medium term, but I think it will 
require a lot of work to get it right. So I would still prefer a shorter 
term solution for CardDAV, that eventually could be replaced with the new 
one (and in CalDAV too).

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2007 19:38:40 +0100

Cyrus Daboo wrote:
> resources, not just calendar/vcard. i.e. should the body of a resource 
> be available via a DAV:data property. There are lots of issues with 
> that, of course. We would need attributes on the property to indicate 
> content-type, we would need to decide how Accept- headers effect what is 
> returned in the property etc.

But we already have DAV:getcontenttype. We also already have the problem 
of variant handling / conneg with respect to WebDAV. For instance, for 
DAV:getcontenttype it currently says:

"Contains the Content-Type header value (from Section 14.17 of 
[RFC2616]) as it would be returned by a GET without accept headers."
-- <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.15.5>

So it seems to me that WebDAV already is pretty much restricted with 
respect to content negotiation; in the best case the server will return 
an alternate URI in a Content-Location response header.

> Maybe that is the better way to go in the medium term, but I think it 
> will require a lot of work to get it right. So I would still prefer a 
> shorter term solution for CardDAV, that eventually could be replaced 
> with the new one (and in CalDAV too).

Let's make sure we have considered it before inventing too much stuff. 
But if we decide that something else is needed, please keep it 
consistent with WebDAV -- don't put things into DAV:prop that aren't 
WebDAV properties.

BR, Julian