| Network Working Group | E. Pot |
| Internet-Draft | fruux GmbH |
| Expires: June 21, 2015 | C. Daboo |
| E. York | |
| Apple Inc. | |
| December 18, 2014 |
WebDAV Resource Sharing
draft-pot-webdav-resource-sharing-01
This specification defines an extension to WebDAV that enables the sharing of resources between users on a WebDAV server.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Users of CalDAV [RFC4791] and CardDAV [RFC6352] often require a mechanism to share a calendar or address book collection with other users.
This specification introduces a mechanism that allows users of WebDAV servers to invite another user to share a resource or WebDAV collection. The invited user can either accept or reject the invite, which is communicated back to the sharer. If the user chooses to accept the invite, the shared resource will then appear in a location on the server that's accessible by the invitee.
There are existing mechanism that address similar use-cases, such as using WebDAV ACL [RFC3744] for fine-grained access control. Experiences has shown that client developers are averse to using it due its complexity. Many implementations have chosen to only use WebDAV ACL for communicating access control information to clients, but not for modification. WebDAV ACL alone also does not provide the means for a user to invite another user.
HTTP POST operations are used to manage the sharing invitations and replies, and WebDAV properties are used to expose the state of shared resources.
This specification uses WebDAV notifications to communicate to users there are outstanding invitations, or responses to invitations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When XML element types in the namespaces "DAV:" and "urn:ietf:params:xml:ns:caldav" are referenced in this document outside of the context of an XML fragment, the string "DAV:" and "CALDAV:" will be prefixed to the element type names respectively.
Terms Used:
The DTD samples used in this document are for illustrative purposes only. The conventions and restrictions described in [RFC4918] section 17.
This section provides a basic overview of this protocol by way of a simple use case of a sharer sharing a collection with a single sharee.
To share a resource with another user, the sharer's client executes an HTTP POST request against the resource that's to be shared. The POST request body will contain details of the user to whom the resource is to be shared as well as the access right to be granted to them. If the request succeeds, a notification is sent to the sharee with details of the resource being shared to them.
The sharer's client will show the notification to the sharee and present them with the choice to accept or decline the invitation to the shared collection. If the sharee chooses to decline, then nothing changes for that sharee. If the sharee chooses to accept, then a new resource is created at a location that's accessible to the sharee. The server enforces the appropriate access privileges for the sharee.
At any time, the sharer can inspect properties on the resource being shared, and determine the accept/decline status of each sharee. Additional sharees can be added and existing ones removed. The access privileges for existing sharees can also be changed.
Once a sharee has access to the shared resource, they can remove it and decline the sharing invite by simply having their client issue an HTTP DELETE request on the shared collection. That does not delete any data, but rather simply removes the "link" to the sharer's resource and sets the sharee's invite status to declined.
In order to facilitate the process of sharing invitations, this specification uses WebDAV notifications, and defines several new notification types.
When a sharer adds a new sharee to a resource, or updates a sharee, an invite notification is added to the sharee's notification collection.
The notification contains information about the shared resource, the owner and how to respond to the invitation.
This is an example of a response to a GET request on a correct invite notification. Note that several HTTP response headers have been removed for brevity.
HTTP/1.1 200 OK
Content-Type: application/davnotification+xml
Content-Length: xxxx
<D:notification xmlns:D="DAV:">
<D:dtstamp>2014-08-05T13:38:02Z</D:dtstamp>
<D:invite-notification>
<D:principal>
<D:href>/principals/users/evert/</D:href>
</D:principal>
<D:invite-accepted />
<D:href>/calendars/users/evert/offdays/</D:href>
<D:access><D:read-write /></D:access>
<D:prop>
<D:displayname>Vacation days!!</D:displayname>
<D:resourcetype><D:collection /></D:resourcetype>
</D:prop>
</D:invite-notification>
</D:notification>
After a sharee has accepted or declined an invitation, the sharer receives a reply-notification in their notification collection.
This notification contains information about which collection this relates to, and who responded to the invite.
This is an example of a response to a GET request on a correct invite notification. Note that several HTTP response headers have been removed for brevity.
HTTP/1.1 200 OK
Content-Type: application/davnotification+xml
Content-Length: xxxx
<D:notification xmlns:D="DAV:">
<D:dtstamp>2014-09-03T02:30:00Z</D:dtstamp>
<D:reply-notification>
<D:principal>
<D:href>mailto:john@example.org</D:href>
</D:principal>
<D:invite-declined />
<D:href>/calendars/users/evert/offdays/</D:href>
<D:comment>Sorry, I'm not interested</D:comment>
</D:reply-notification>
</D:notification>
A server that supports the features described in this document MUST include "resource-sharing" as a field in the DAV response header from an OPTIONS request on any resource that supports these features.
The following new or modified WebDAV properties are defined for resources and used to view or manipulate shared resources features.
Resources that are shared have elements listed in their DAV:resourcetype property in addition to any elements that may already be there, such as DAV:collection.
<!ELEMENT invite (organizer?, user*)>
<!ELEMENT shared-url (DAV:href)>
To update an existing resource to be shared, the sharer simply adds one or more sharees to the resource as per Section 5.3.2. The server MUST update the DAV:resourcetype property on the collection to ensure it contains a DAV:shared-owner XML element to indicate the resource is now shared.
To unshare a resource, the sharer simply removes all sharees from the DAV:invite property of the resource as per Section 5.3.2. The server MUST update the DAV:resourcetype property on the resource to ensure it does not contain a DAV:shared-owner XML element to indicate the resource is not shared.
The sharer of a shared resource is able to manipulate the sharee list by issuing a POST request targeted at the resource. The POST request MUST contain an XML document as its body with the root element being DAV:share-resource [DAV:share-resource].
The POST request MUST contain a Content-Type HTTP header, which MUST contain "application/davshare+xml" as its value. Servers SHOULD reject the request if this is not the case.
The DAV:share-resource [DAV:share-resource] element in the POST requests MUST contain one or more DAV:set-invitee [DAV:set-invitee] or DAV:remove-invitee [DAV:remove-invitee] elements. For each DAV:set-invitee [DAV:set-invitee] element, the server MUST add the specified sharee access to the resource. For each DAV:remove-invitee [DAV:remove-invitee] element the server MUST remove the specified sharee access from the shared resource. In each case the server MUST send a notification message to any sharees whose status is changed (added, modified or removed), indicating to them a change in status for the shared resource. This is accomplished by sending a DAV:invite-notification [DAV:invite-notification] notification to each sharee. The server SHOULD NOT send notification messages to sharees whose status is unchanged.
Sharees are identified via a DAV:href element whose value is either a principal-URL for a sharee hosted on the same server, an email address, or any other URI identifying a user. In the case of the later two, the sharee might not be a user on the same server - though in that case how invitations are sent or access enabled is out of scope for this specification. A server MAY change the sharee's "address" to any suitable alternative that it might prefer when returning the list of sharees via the DAV:invite property [DAV:invite].
The client MAY include a DAV:displayname element in the DAV:set-invitee [DAV:set-invitee] element. When provided, the value represents the common name for the sharee, and is returned in the list of sharees via the DAV:invite property [DAV:invite]. The server MAY change this to a suitable alternative when it is able to match the sharee to a known user. If absent from the client request, the server SHOULD add a DAV:displayname when it is able to match the sharee with a known user, and a common name for that user can be determined.
This example shows how to add a single sharee (with email address "mailto:eric@example.com") to a shared resource with DAV:read-write access.
>> Request <<
POST /calendars/users/cyrus/shared/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/davsharing+xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:share xmlns:D="DAV:">
<D:set-invitee>
<D:href>mailto:eric@example.com</D:href>
<D:displayname>Eric York</D:displayname>
<D:comment>Shared workspace</D:comment>
<D:read-write />
</D:set-invitee>
</D:share>
>> Response <<
HTTP/1.1 200 OK Cache-Control: no-cache Date: Sat, 11 Nov 2006 09:32:12 GMT
This example shows how multiple sharee's can be manipulated in a single request. The sharee with email address "mailto:eric@example.com" has their access downgraded to CS:read, whilst another sharee is removed from the access list entirely.
>> Request <<
POST /calendars/users/cyrus/shared/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/davsharing+xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:share xmlns:D="DAV:">
<D:set-invitee>
<D:href>mailto:eric@example.com</D:href>
<D:comment>Shared workspace</D:comment>
<D:read-write />
</D:set-invitee>
<D:remove-invitee>
<D:href>mailto:wilfredo@example.com</D:href>
</D:remove-invitee>
</D:share>
>> Response <<
HTTP/1.1 204 No Content Cache-Control: no-cache Date: Sat, 11 Nov 2006 09:32:12 GMT
When a sharee is invited to a shared resource they can accept or decline the invite by issuing a POST request to the resource URI for the invitation notification. The POST request MUST contain an XML document as its body with the root element being DAV:invite-reply [DAV:invite-reply].
The POST request MUST contain a Content-Type HTTP header, which MUST contain "application/davshare+xml" as its value. Servers SHOULD reject the request if this is not the case.
The DAV:invite-reply [DAV:invite-reply] element in the POST request specifies the accept or decline action via the DAV:invite-accepted or DAV:invite-declined elements, and an optional DAV:comment element. IF the invite was accepted, the body MUST also contain a DAV:create-in [DAV:create-in] element. This element contains a single DAV:href element, which content is a URI that will be used as the parent for the new shared resource.
The client MAY also provide a DAV:slug property. The server MAY use the contents of this property to determine the name of the new resource.
All usual preconditions for creating a resource at the DAV:create-in target collection need to be taken into consideration.
Note that some servers may restrict where certain types of resources may be created. A CalDAV server for instance, may only allow calendars to be created in collections identified by the CALDAV:calendar-home-set WebDAV property.
A successful response to an accepted invitation, SHOULD have a HTTP 201 status code, and MUST have a HTTP Location header, containing the full url to the newly created resource.
A successful response to a declined invitation, SHOULD contain a 200 or 204 HTTP status code.
When the sharee replies to an invite, the server SHOULD send a notification to the sharer to update them on the change in the sharee state. This is accomplished by sending a DAV:reply-notification [DAV:reply-notification] notification to the sharer.
After the sharee has issued a reply, the server SHOULD also remove the notification that contained the initial invite.
This is an example of a request that the sharee would send to accept an invitation.
POST /principals/users/evert/notifications/1000455.xml HTTP/1.1
Host: calendar.example.com
Content-Type: application/davsharing+xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:invite-reply xmlns:D="DAV:">
<D:invite-accepted />
<D:create-in>
<D:href>/calendars/users/evert/</D:href>
</D:create-in>
<D:slug>Tech meetups</D:slug>
</D:invite-reply>
For privacy reasons, sharees need to be able to remove invitations without notifiying the sharer.
When the sharee issues a DELETE on an invite-notification, the server MUST remove the notification, and MUST NOT let the sharer know about this.
As a result, from the sharers perspective, the invitation status for that principal will always remain as DAV:invite-noreply.
Any changes that a sharee makes to a shared resource should also be reflected in the sharers instance of the resource.
If the shared resource is a collection, any resources in the collection, or in the collection's child-collections MUST also appear in the sharers instance.
To remove a shared resource a DELETE request is targeted at the shared resource URI. When such a request is received the server MUST remove the shared collection and automatically update the sharee's status in the sharer's DAV:invite property.
Two levels of access can be granted by a sharer to any sharee. These are governed by the DAV:access element used in the DAV:invite/DAV:user element that specifies a shared user invite. DAV:access contains a single empty element that defines the type of access granted:
The function of the DAV:read and DAV:read-write elements is to give a quick indicator for a sharee what kind of access they may expect. The server may still set more fine-grained access control rules. The sharee can find out about these rules by requesting the DAV:current-user-privilege-set property on the shared resource, or its children.
Servers MUST support "per-instance" WebDAV properties on shared resource and MAY support them on resources within shared collections. A "per-instance" WebDAV property is one whose value can be set and retrieved on an instance of a resource, but is not automatically propagated to other instances of the same shared resource. For example, a sharee may change a property on their instance of a shared resource, but the instance of the owner of the resource will not see this updated value.
For shared resources, the server MUST allow all users to write "per-instance" WebDAV properties on the shared resources and MAY allow property writes on resources within the shared resources. This is required even in the case where the sharee has been granted read access only (i.e., the ability to change the resource is disallowed). This requirement ensures that sharees can always change "personal" properties such as display names.
Servers MAY treat any dead property as per-instance.
Servers MUST NOT treat live properties as per-instance.
Servers MAY support sharing on a per-resource basis. This section defines a "DAV:share" WebDAV Access Control (ACL) [RFC3744] privilege for use on collections that may be shared.
This privilege MUST be non-abstract and MAY be protected. This privilege MUST appear in the DAV:supported-privilege-set property for resources that may be shared. In addition, it MUST appear in the DAV:current-user-privilege-set, if the user is allowed to share the collection.
<!ELEMENT shared-owner EMPTY>
<!ELEMENT shared EMPTY>
<!ELEMENT share EMPTY>
<!ELEMENT user (href, displayname?, (invite-noresponse |
invite-accepted | invite-declined | invite-invalid),
access, comment?)>
<!ELEMENT invite-noresponse EMPTY>
<!ELEMENT invite-deleted EMPTY>
<!ELEMENT invite-accepted EMPTY>
<!ELEMENT invite-declined EMPTY>
<!ELEMENT invite-invalid EMPTY>
<!ELEMENT access (read | read-write)>
<!ELEMENT read EMPTY>
<!ELEMENT read-write EMPTY>
<!ELEMENT invite-notification (
dav:href,
(invite-noresponse | invite-deleted |
invite-accepted | invite-declined),
access, organizer,
comment?,
>
<!ELEMENT hosturl (DAV:href)>
<!ELEMENT organizer (href,
displayname?)?)>
<!ELEMENT invite-reply (href,
(invite-accepted | invite-declined),
hosturl, create-in?, comment?>
<!ELEMENT invite-reply (href,
(invite-accepted | invite-declined),
hosturl, create-in?, comment?>
<!ELEMENT create-in (DAV:href)>
<!ELEMENT share-resource (set | remove)*>
<!ELEMENT set-invitee (href, displayname?, comment?,
(read | read-write)>
<!ELEMENT remove-invitee (href)>
<!ELEMENT shared-as (DAV:href)>
TBD
This document does not require any actions on the part of IANA.
The authors would like to thank the members of the Calendaring and Scheduling Consortium's SharingTechnical Committee. In particular, the following individuals have made important contributions to this work: Richard Brigham, John Chaffee, Michael Douglass and Ken Murchison and Dave Thewlis.
This specification originated from work at the Calendaring and Scheduling Consortium, which has supported the development and testing of implementations of the specification.
This document defines a MIME media type for XML documents used in for sharing. This media type SHOULD be used for all POST requests in this specification.
Additional information
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3744] | Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. |
| [RFC4791] | Daboo, C., Desruisseaux, B. and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. |
| [RFC4918] | Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |
| [RFC6352] | Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, August 2011. |
| [RFC7303] | Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, July 2014. |
This specification is based on an earlier effort, often referred to as 'caldav-sharing'. It is possible to remain compatibile with this specification, but it's important to be aware of a number of changes.
The earlier draft uses the http://calendarserver.org/ns/ namespace for all its xml elements. This means that any WebDAV property introduced in this specification, may need to have a similar property in the old namespace.
XML documents as sent by POST requests and responses, and resources returned from notifications can be distinguished by the use of the Content-Type and Accept HTTP headers. The earlier draft does not define new mime-types for these, but this specification does.
Changes in -01: