Subject: Re: [VCARDDAV] Thoughts on relation to WebDAV

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Apr 2008 10:25:22 -0400

Hi Julian,
Catching up after your plea for a response!

--On March 15, 2008 11:55:44 AM +0100 Julian Reschke 
<[email-masked]> wrote:

> here are a few thoughts about how to handle the WebDAV dependencies of
> CardDAV (mostly based on what was discussed in the VCARDDAV WG meeting
> in Philadelphia):
>
> 1) WebDAV base requirements
>
> I think CardDAV should require WebDAV level 3 support, as defined by RFC
> 4918. It seems there was some confusion about what level 3 actually is:
> although 3 > 2, 3 does *not* include locking, it's just level 1 plus a
> few RFC 4918 extensions. And yes, it would be really great if Apache
> mod_dav would incorporate these few extensions.

I agree. Level 3 is a MUST, and Level 2 is MAY. Level 2 is only important 
if we have use cases where say more than one vcard needs to be updated 
simultaneously - e.g. some of the recent discussion surrounding how to 
represent groups in vcard has suggested cards that may contain links to 
each other and that would, ideally, be updated together in one go to avoid 
any possible inconsistencies. In that case locking would be useful.

> 2) Extended MKCOL, Reporting, Syncing
>
> There are several things where CardDAV would benefit from generic WebDAV
> extensions, most of which are covered by Cyrus' proposals:
>
> - using MKCOL to create "special" collections (instead of inventing new
> methods all the time)
> (<http://tools.ietf.org/html/draft-daboo-webdav-mkcol-00.html>)

CardDAV already makes use of that, and the vcarddav WG agreed to adopt that 
spec as a WG item. Some further discussion is still needed to address some 
comments on that.

> - potentially extract the REPORT method definition from RFC3253, and
> move it into a separate spec, including clarifications

Well, I think both 3253 and 3744 could do with being updated - at the very 
least to reference 4918 instead of 2518. Certainly extracting REPORT as a 
separate spec would be useful given that other specs now also use it.

> - enhancements for syncing; Cyrus has proposed a new REPORT for this
> (<http://tools.ietf.org/html/draft-daboo-webdav-sync-00>);

Yes, I would like to get back to that one, but I actually think push 
notifications to be more important a problem to solve right now.

> I think we
> should try come up with a more generic solution to the
> GET-unfriendliness of PROPFIND and REPORT
> (<http://tools.ietf.org/html/draft-reschke-http-get-location-00> and
> <http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.
> html>).

Still not convinced by this draft yet. I need to read it some more.

> 3) Where to discuss
>
> I think it would be great if we would discuss everything that is not
> strictly related to CardDAV on the WebDAV mailing list (it's still an
> IETF mailing list, after all). This would help us to avoid introducing
> special solutions where generic solutions are needed.

Certainly mkcol-ext should be discussed on both lists. As to the rest, both 
CalDAV and CardDAV are likely to be drivers for sync and 
push-notifications, but its probably best to deal with on the general 
WebDAV list.

> These specifications still could be working group items; I'm neutral on
> whether they need to be, as long as they are developed in an open way,
> and get the necessary attention from the IESG when done (hint, hint).

Right. I suspect push notifications for WebDAV will need to integrate with 
a more generic notification protocol/service that many different protocols 
can use (IMAP etc) so that may well require its own WG.

-- 
Cyrus Daboo

---

From: Helge Hess <[email-masked]>
Date: Wed, 23 Apr 2008 17:36:58 +0200

On 23.04.2008, at 16:25, Cyrus Daboo wrote:
> suspect push notifications for WebDAV will need to integrate with a  
> more generic notification protocol/service that many different  
> protocols can use (IMAP etc) so that may well require its own WG.

I haven't read anything about WebDAV push so far (are there any  
documents available on it?).

Do you already have an idea on how to approach push in an HTTP  
environment?
Comet like open connections?
XMPP?
Exchange SUBSCRIBE/NOTIFY, possibly support for httpu?

Thanks a lot,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/