W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2014

WebDAV Collection Sharing

From: Evert Pot <me@evertpot.com>
Date: Wed, 16 Apr 2014 20:33:18 -0400
Message-ID: <534F214E.60501@evertpot.com>
To: vcarddav@ietf.org, w3c-dist-auth@w3.org, contacts-pc-l@lists.calconnect.org
Hi All,

At CalConnect, we are looking to standardize a way for users to share
Address Book and Calendar collections with each other.

As of right now, there's a specification to enable this for Calendars,
written by Cyrus Daboo. This is currently already implemented by a wide
range of both clients and servers.

The specification consists of two parts, and can be found here:


On a very high level, this specification operates as follows:

* A user (owner of a calendar) invites a number of people, by email
  address using a POST method on a calendar collection.
* The invitee receives a notification-resource in a notification-
  collection with the invite inforomation.
* The invitee can then choose to accept or reject the invitation with
  a second POST request.
* The owner of the calendar receive a reply in his/her notification
* If the invitee accepted in the invite, the calendar now also appears
  in the invitees calendar home.

This all works pretty well. Recently we've started talking about
implementing something similar for CardDAV, allowing users to also share
Address Books.

Rather than creating both a Card- and CalDAV document for this, we felt
that it may make sense to create something that effectively describes
"WebDAV Collection Sharing" in general.

We felt that there could be a wider interest for this, as many modern
file-sharing services use a similar (but non-standard) systems to
achieve the same thing.

One issue that did pop up, is that there is some overlap with what BIND
does (rfc5842), but we're not using it. A few reasons for this is:

* Due to the invite-based system, the server is responsible for
  creating the binding.
* WebDAV properties may not be shared across instances. A user can give
  his/her instance of a calendar a different displayname, without
  affecting the original.
* In some cases, properties should be shared. A calendar-timezone
  property should be updated across instances for consistency.
* Specifically relating to calendars: even resources within the
  calendar may vary depending on the accessed instance.

We'd love to hear your feedback and concerns about this.

Evert Pot
Received on Thursday, 17 April 2014 09:46:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:46 UTC