| Network Working Group | E. Pot |
| Internet-Draft | fruux GmbH |
| Expires: December 29, 2016 | C. Daboo |
| E. York | |
| Apple Inc. | |
| June 27, 2016 |
WebDAV Resource Sharing
draft-pot-webdav-resource-sharing-04
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 December 29, 2016.
Copyright (c) 2016 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. Experience 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.
In this specification, 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 namespace "DAV:" are referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type names.
Terms Used:
The DTD samples used in this document are for illustrative purposes only. All XML documents in this document follow 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 sharee'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.
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.
A response to this OPTIONS request might look as follows:
HTTP/1.1 200 OK Dav: 1,3,extended-mkcol,resource-sharing Allow: GET,HEAD,POST,OPTIONS,PROPFIND,PROPPATCH
A server that supports sharing on a specific resource, MUST enforce this using the "DAV:share" privilege. Privileges are defined in [RFC3744].
The privilege MAY be 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 property, if the user is in fact allowed to share the resource. This mechanism is also used by a client to discover sharing capabilities on specific resources.
To share a resource or revoke access to a shared resource, the client must issue a POST request to the resource that the user wants to share. 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/davsharing+xml" as its value. Servers SHOULD reject the request if this is not the case.
The DAV:share-resource element can contain one or more DAV:sharee elements. Each DAV:sharee element MUST at least have a DAV:href element containing a URI identifying the sharee.
The URI in DAV:href may be a principal-URL referring to a sharee hosted on the same server, an email address or any other URI identifying a user. In the case of the latter two, the sharee might not be a user on the same server - though in that case how invitations are sent or access is enabled is out of scope for this specification.
The DAV:prop element is optional, and can be used to provide more information about the sharee. The server MAY use this information and later return it when information is requested about the list of sharees. Any valid WebDAV property might be provided here, but it's up to the discretion of the server what to support. A client SHOULD provide at least a DAV:displayname property as a human- readable string identifying the user.
The DAV:share-access element is required. It MUST contain one of the following elements:
Lastly, you may add the optional DAV:comment element. This element may contain some information about the intent of the share, for the sharee, this allows the sharee to send a short message.
The following example grants read-write access to a resource identified by "/calendars/users/cyrus/shared" to a sharee with email address "mailto:eric@example.com".
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-resource xmlns:D="DAV:">
<D:sharee>
<D:href>mailto:eric@example.com</D:href>
<D:prop>
<D:displayname>Eric York</D:displayname>
</D:prop>
<D:comment>Shared workspace</D:comment>
<D:share-access>
<D:read-write />
</D:share-access>
</D:sharee>
</D:share-resource>
If the operation was successful, the server MUST respond with a 204 No Content HTTP status.
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 DAV:read, whilst another sharee is removed from the access list entirely.
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-resource xmlns:D="DAV:">
<D:sharee>
<D:href>mailto:eric@example.com</D:href>
<D:share-access>
<D:read />
</D:share-access>
</D:sharee>
<D:sharee>
<D:href>mailto:wilfredo@example.com</D:href>
<D:share-access>
<D:no-access />
</D:share-access>
</D:sharee>
</D:share-resource>
The following new or modified WebDAV properties are defined for resources and used to view or manipulate shared resources features.
This specification supports two major processes for sharing a resource. The server can either immediately set up the newly shared resource, or the server can provide an invitation process. The former might be useful in small trusted team settings, whereas the invitation process might be used in public servers, where it's desirable for users to explicitly opt-in to getting access to newly shared resources.
This specification provides a invitation and notification mechanism. It might also be possible that servers provide their own out-of-band mechanism for this, but this should not affect clients.
If the server opts to support the standard invitation process, the server MUST support WebDAV notifications.
Sharees for a resource MUST appear up in the DAV:invite [invite-property] property. Each sharee will have one of the following elements:
When sharees are initially invited, they will get the DAV:invite-noresponse status. When a sharee's access has been changed, they will retain their existing status. When a sharee's access has been revoked, they will no longer appear in the DAV:invite property.
After any of these mutations, sharees receive an share-invite-notification [share-invite-notification] in their notification collection. After the sharee has accepted or declined the invite, their status will reflect this response.
Implementing the invitation process is optional. It's also possible for servers to immediately apply changes. The effect is that no notifications may be needed, and the server behaves as if sharees immediately accept invitations. Sharees listed in DAV:invite might immediately receive a DAV:invite-accepted status.
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 reply 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:share-invite-notification>
<D:principal>
<D:href>/principals/users/evert/</D:href>
</D:principal>
<D:invite-accepted />
<D:sharer-resource-uri>
<D:href>/calendars/users/evert/offdays/</D:href>
</D:sharer-resource-uri>
<D:share-access><D:read-write /></D:share-access>
<D:prop>
<D:displayname>Vacation days!!</D:displayname>
<D:resourcetype><D:collection /></D:resourcetype>
</D:prop>
<D:reply-url>
<D:href>?invite-reply</D:href>
</D:reply-url>
</D:share-invite-notification>
</D:notification>
In this notification, DAV:principal indicates which principal is the sharer for the resource.
The notification MUST contain DAV:invite-accepted or DAV:invite-noresponse to indicate the current invitation status of the sharee in the shared resource. New invites to shares would carry the DAV:invite-noresponse status. In case the sharee had accepted an earlier invite, but it's access was changed or revoked, the invitation will have a DAV:invite-accepted status.
DAV:sharer-resource-uri refers to the DAV:sharer-resource-uri that the shared resource will have, and can be used to identify which invitation refers to which existing shared resource. The element MAY refer to the URI of the original shared resource, but may also be a urn, or any other unique URI.
DAV:share-access MUST be one of DAV:read-write, DAV:read or DAV:no-access. This indicates that the invitee either has read-write access, read-only access or no access at all respectively.
DAV:reply-url appears for invitations to new shared resources. The url in this property can be used for a sharee to accept or decline the invite. DAV:reply-url only appears for sharees with the DAV:invite-noresponse status, and does not appear when DAV:share-access is DAV:no-access.
The DAV:prop element is optional, and may contain a list of WebDAV properties associated with the shared resource. Servers SHOULD at least set the DAV:resourcetype, if available. This will allow a client to know what kind of resource is being shared. Some clients may only support responding to invites of certain kinds of resources. For example, a calendaring user agent may only support CalDAV calendars.
The DAV:comment element is also optional, and may return a brief message from the sharer to the sharee. The sharer is able to specify this in the original DAV:share-resource POST request.
After a sharee has accepted or declined an invitation, the sharer receives a share-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:share-reply-notification>
<D:sharee>
<D:href>mailto:john@example.org</D:href>
<D:invite-declined />
</D:sharee>
<D:href>/calendars/users/evert/offdays/</D:href>
<D:comment>Sorry, I'm not interested</D:comment>
</D:share-reply-notification>
</D:notification>
In this notification, the DAV:sharee element MUST appear and contains information about the updated status of the sharee in the shared resource.
The DAV:href element MUST appear and refers to the resource the sharer originally shared.
The DAV:comment element is optional, and may contain a message that the sharee specified when responding to the invite.
When a sharee is invited to a shared resource they can accept or decline the invite by issuing a POST request to the url specified in the DAV:reply-url element, in 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/davsharing+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 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.
The client MAY also provide a small comment in the DAV:comment element. This comment will be sent back to the sharer. Support for DAV:comment is optional.
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:share-reply-notification [DAV:share-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:comment>Thanks for the share!</D:comment>
</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 share-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 [invite-property] property.
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.
A point that may not be immediately obvious, is that there is a separation between sharees and shared instances.
Sharees (and sharers) are effectively only 'actors' in the sharing process and allow shared instances to be created and modified. The sharing "role" or access level that a user has when performing an opteration on a shared resource, is dependent on which intance they are accessing, not who the currently logged in principal is.
To illustrate, take the DAV:share-access WebDAV property. This property should always describe the access-level of the instance, not the current user accessing the property.
An implication is that if an owner of a shared resource also has direct access to a shared instance of a sharee (via normal WebDAV ACL controls for example), requesting the share-access property on that shared resource should always indicate DAV:read or DAV:read-write, but never DAV:shared-owner.
Likewise, if a sharee also has direct access to the original shared (owner) instance on the same server, the DAV:share-access property should always return DAV:shared-owner.
This philosophy must be considered when designing the underlying data-model of the server, and every feature in this specification. That is: the sharing-role a user has when accessing a shared-resource, is generally dependent on the resource being accessed, not the current principal.
This document describes a way for a user to grant access to other resources, sidestepping WebDAV ACL [RFC3744].
WebDAV ACL is still relevant though. The DAV:share ACL privilege is used to indicate that a user is allowed to share a resource.
This specification uses the DAV:read and DAV:read-write access levels to indicate the access level of the shared resource.
These privileges don't directly correlate to ACL privileges. It's left up to the implementor to decide which ACL privileges are the most appropriate for both DAV:read and DAV:read-write.
The following is a suggestion: Sharees with a DAV:read share-access level, may typically at least expect DAV:read, DAV:write-properties, DAV:read-current-user-privilege set.
For DAV:read-write, this also includes DAV:write, DAV:write-content, and if the shared resource is a collection, DAV:bind and DAV:unbind.
These privileges are typically applied to the shared resource and all its child resources (if any).
There is no requirement for the shared instance to have a DAV:owner element that refers to the original sharer. In fact, it SHOULD probably be the sharee. Likewise, there is also no requirement for the original sharer to have any privileges to any of the sharee instances.
The following section contains a definition of all the XML elements used in this document The definitions are written in the form of a DTD. The DTD itself non-normative and for reference only.
It should be noted that several elements in the following sections are repeated, sometimes with varying definitions. This is because some of these elements have slightly different definitions depending on the context in which they appear in.
The following section describes the DAV:share-resource element, which is defined in Section 4.3
<!ELEMENT share-resource (sharee+)> <!-- Each sharee represents a sharee --> <!ELEMENT sharee (href, share-access, prop?, comment?)> <!-- The sharee href, can be a mailto:, http: or any supported scheme --> <!ELEMENT href (#PCDATA)> <!-- Describes the access-level the user will get --> <!ELEMENT share-access (read, read-write, no-access)> <!-- Read-only access --> <!ELEMENT read EMPTY> <!-- Read-write access --> <!ELEMENT read-write EMPTY> <!-- Access is revoked --> <!ELEMENT no-access EMPTY> <!-- A list of properties describing the sharee, such as a displayname -> <!ELEMENT prop ANY> <!-- An optional message to the sharee by the sharer --> <!ELEMENT comment (#PCDATA)>
The share element is a WebDAV ACL [RFC3744] privilege that allows a client to inspect whether a user may be allowed to share a resource. The element is defined in Section 4.2.
<!ELEMENT share EMPTY>
DAV:share-invite-notification is used within a WebDAV notification to communicate to a sharee that a sharer is sharing a resource, or changing the access level to a resource. DAV-share-invite-notification is defined in Section 4.6.1
<!-- Every notification has a DAV:notification root element -->
<!ELEMENT notification (dtstamp, share-invite-notification)>
<!-- This element has all the information about the notification -->
<!ELEMENT share-invite-notification (principal, (invite-accepted|invite-noresponse),
sharer-resource-uri, share-access, prop?, reply-url?, comment?)>
<!-- Indicates that this was a new invitation -->
<!ELEMENT invite-noresponse EMPTY>
<!-- Indicates that this was an update to an existing invitation -->
<!ELEMENT invite-accepted EMPTY>
<!-- A uri that indentifies the original shared resource. -->
<!ELEMENT sharer-resource-uri (href)>
<!-- Information about the sharer -->
<!ELEMENT principal (href, prop?)>
<!-- Describes the access-level the user will get -->
<!ELEMENT share-access (read, read-write, no-access)>
<!-- Read-only access -->
<!ELEMENT read EMPTY>
<!-- Read-write access -->
<!ELEMENT read-write EMPTY>
<!-- Access is revoked -->
<!ELEMENT no-access EMPTY>
<!-- If it was a new share, where to respond to the invitation -->
<!ELEMENT reply-url (href)>
<!-- An optional comment from the sharer to the sharee -->
<!ELEMENT comment (#PCDATA)>
<!-- Common elements -->
<!ELEMENT href (#PCDATA)>
<!ELEMENT prop ANY>
DAV:share-reply-notification is a notification that appears in a sharers notification collection when a sharee responded to an invitation. It is defined in Section 4.6.2
<!-- Every notification has a DAV:notification root element --> <!ELEMENT notification (dtstamp, share-invite-notification)> <!-- This element has all the information about the notification --> <!ELEMENT share-reply-notification (sharee, href, comment?) <!ELEMENT sharee (href, (invite-accepted|invite-declined), comment?)> <!-- A reference to the owner's shared resource --> <!ELEMENT href (#PCDATA)> <!-- Indicates that the sharee accepted the invitation --> <!ELEMENT invite-accepted EMPTY> <!-- Indicates that the sharee declined the invitation --> <!ELEMENT invite-declined EMPTY> <!-- An optional comment from the sharer to the sharee --> <!ELEMENT comment (#PCDATA)>
DAV:invite is a live WebDAV property, defined in Section 4.4.2. This property allows a sharer or sharee to inspect who has access to a particular resource, their invitation status and access level.
<!-- The invite WebDAV property -->
<!ELEMENT invite (sharee*)>
<!-- A person with access to the shared resource -->
<!ELEMENT sharee (href,
(invite-accepted|invite-declined|invite-invalid|invite-noresponse),
share-access, prop
)>
<!-- A reference to the user who access access to the share -->
<!ELEMENT href (#PCDATA)>
<!-- Indicates that the sharee accepted the invitation -->
<!ELEMENT invite-accepted EMPTY>
<!-- Indicates that the sharee declined the invitation -->
<!ELEMENT invite-declined EMPTY>
<!-- Indicates that the sharee has not responsed yet -->
<!ELEMENT invite-noresponse EMPTY>
<!-- Indicates that the server could not deliver the invitation -->
<!ELEMENT invite-invalid EMPTY>
<!-- The level of access the user has -->
<!ELEMENT share-access (read|read-write|shared-owner)>
<!-- The user has read access -->
<!ELEMENT read EMPTY>
<!-- The user has read-write access -->
<!ELEMENT read-write EMPTY>
<!-- The user is actually the owner of the share -->
<!ELEMENT shared-owner EMPTY>
<!-- A list of WebDAV properties describing the user. -->
<!ELEMENT prop ANY>
DAV:invite is a live WebDAV property, defined in Section 4.4.1. This property allows sharer or sharee to inspect the sharing status of the resource.
<!-- The share-access WebDAV property --> <!ELEMENT share-access (read|read-write|shared-owner|not-shared)> <!-- The current instance is a read-only instance of the share --> <!ELEMENT read EMPTY> <!-- The current instance if a read-write instance of the share --> <!ELEMENT read-write EMPTY> <!-- The current instance if the original instance, owned by the sharee --> <!ELEMENT shared-owner EMPTY> <!-- The current instance is not shared at all --> <!ELEMENT not-shared EMPTY>
DAV:invite-reply is the root element of a POST request that a sharee would issue to respond to an invitation. It is defined in Section 4.7.1.
<!ELEMENT invite-reply ((invite-accepted|invite-declined),
create-in?, slug?, comment?)>
<!-- The user is accepting the invite -->
<!ELEMENT invite-accepted EMPTY>
<!-- The user is declining the invite -->
<!ELEMENT invite-declined EMPTY>
<!-- When accepting the invite, the collection in which to create the new
instance in -->
<!ELEMENT create-in (href)>
<!ELEMENT href (#PCDATA)>
<!-- A hint for the server for a new resource name. -->
<!ELEMENT slug (#PCDATA)>
<!-- A comment by the sharee to the sharer -->
<!ELEMENT comment (#PCDATA)>
When this specification is implemented without the use of the notification flow, as described in Section 4.5.2, it may be possible that a malicious user can create unwanted resources for a target user.
If this is a concern, taking advantage of the notification process is highly recommended.
If a server does deploy the entire notification process, a user with malicious intent may still generate a large amount of notifications targetting other users.
Servers SHOULD at the very least ensure that multiple share invitations for the same resource are coalesced into a single invitation.
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
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3744] | Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, DOI 10.17487/RFC3744, May 2004. |
| [RFC4791] | Daboo, C., Desruisseaux, B. and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007. |
| [RFC4918] | Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007. |
| [RFC6352] | Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011. |
| [RFC7303] | Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, 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 -04:
Changes in -03:
Changes in -02:
Changes in -01: