Network Working Group E. Pot
Internet-Draft fruux GmbH
Expires: June 18, 2015 C. Daboo
E. York
Apple Inc.
December 15, 2014
WebDAV Resource Sharing
draft-pot-webdav-resource-sharing-00
Abstract
This specification defines an extension to WebDAV that enables the
sharing of resources between users on a WebDAV server.
Status of This Memo
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 18, 2015.
Copyright Notice
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.
Pot, et al. Expires June 18, 2015 [Page 1]
Internet-Draft WebDAV Resource Sharing December 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Notification Definitions . . . . . . . . . . . . . . . . . . 5
5.1. Invite Notification . . . . . . . . . . . . . . . . . . . 5
5.1.1. Example: An invite notification . . . . . . . . . . . 5
5.2. Invite Reply . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Example: An invite reply . . . . . . . . . . . . . . 6
6. Resource sharing . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Feature Discovery . . . . . . . . . . . . . . . . . . . . 7
6.2. Additional Properties for resources . . . . . . . . . . . 7
6.2.1. DAV:resourcetype Property . . . . . . . . . . . . . . 7
6.2.2. DAV:invite Property . . . . . . . . . . . . . . . . . 7
6.2.3. DAV:shared-url Property . . . . . . . . . . . . . . . 8
6.3. Sharer Actions on Shared Resource . . . . . . . . . . . . 9
6.3.1. Sharing or Unsharing a Resource . . . . . . . . . . . 9
6.3.2. Manipulating Sharees of a Shared Resource . . . . . . 9
6.3.2.1. Example: Successful Sharee Add Request . . . . . 10
6.3.2.2. Example: Successful Multiple Sharee Change
Request . . . . . . . . . . . . . . . . . . . . . 10
6.4. Sharee Actions on Shared Resources . . . . . . . . . . . 11
6.4.1. Replying to a Sharing Invite . . . . . . . . . . . . 11
6.4.1.1. Example: Accepting an invite . . . . . . . . . . 12
6.4.2. Ignoring an invitation . . . . . . . . . . . . . . . 13
6.4.3. Making modifications to a shared resource . . . . . . 13
6.4.4. Removing a shared resource . . . . . . . . . . . . . 13
6.5. General Considerations . . . . . . . . . . . . . . . . . 13
6.5.1. Access Levels . . . . . . . . . . . . . . . . . . . . 13
6.5.2. Per-instance WebDAV Properties . . . . . . . . . . . 14
7. Sharing privileges . . . . . . . . . . . . . . . . . . . . . 14
8. XML Element Definitions . . . . . . . . . . . . . . . . . . . 14
8.1. DAV:shared-owner . . . . . . . . . . . . . . . . . . . . 14
8.2. DAV:shared . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. DAV:share . . . . . . . . . . . . . . . . . . . . . . . . 15
8.4. DAV:user . . . . . . . . . . . . . . . . . . . . . . . . 15
8.5. DAV:invite-noresponse . . . . . . . . . . . . . . . . . . 16
8.6. DAV:invite-deleted . . . . . . . . . . . . . . . . . . . 16
8.7. DAV:invite-accepted . . . . . . . . . . . . . . . . . . . 17
8.8. DAV:invite-declined . . . . . . . . . . . . . . . . . . . 17
8.9. DAV:invite-invalid . . . . . . . . . . . . . . . . . . . 17
8.10. DAV:access . . . . . . . . . . . . . . . . . . . . . . . 18
8.11. DAV:read . . . . . . . . . . . . . . . . . . . . . . . . 18
8.12. DAV:read-write . . . . . . . . . . . . . . . . . . . . . 18
8.13. DAV:invite-notification . . . . . . . . . . . . . . . . . 19
8.14. DAV:hosturl . . . . . . . . . . . . . . . . . . . . . . . 19
Pot, et al. Expires June 18, 2015 [Page 2]
Internet-Draft WebDAV Resource Sharing December 2014
8.15. DAV:organizer . . . . . . . . . . . . . . . . . . . . . . 20
8.16. DAV:invite-reply . . . . . . . . . . . . . . . . . . . . 20
8.17. DAV:reply-notification . . . . . . . . . . . . . . . . . 20
8.18. DAV:create-in . . . . . . . . . . . . . . . . . . . . . . 21
8.19. DAV:share . . . . . . . . . . . . . . . . . . . . . . . . 21
8.20. DAV:set-invitee . . . . . . . . . . . . . . . . . . . . . 21
8.21. DAV:remove-invitee . . . . . . . . . . . . . . . . . . . 22
8.22. DAV:shared-as . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Normative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24
Appendix B. Backwards compatibility . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
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.
Pot, et al. Expires June 18, 2015 [Page 3]
Internet-Draft WebDAV Resource Sharing December 2014
2. Open Issues
1. ...
3. Conventions Used in This Document
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:
Sharer A user who is sharing a resource with other users.
Sharee A user to whom a resource has been shared.
Sharing Invite A message sent by a sharer to a sharee to indicate
the status of a shared resource.
Sharing Reply A message sent by a sharee to a sharer to indicate the
status of a shared resource.
4. Overview
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.
Pot, et al. Expires June 18, 2015 [Page 4]
Internet-Draft WebDAV Resource Sharing December 2014
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.
5. Notification Definitions
In order to facilitate the process of sharing invitations, this
specification uses WebDAV notifications, and defines several new
notification types.
5.1. Invite Notification
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.
5.1.1. Example: An invite notification
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.
Pot, et al. Expires June 18, 2015 [Page 5]
Internet-Draft WebDAV Resource Sharing December 2014
HTTP/1.1 200 OK
Content-Type: application/davnotification+xml
Content-Length: xxxx
2014-08-05T13:38:02Z
/principals/users/evert/
/calendars/users/evert/offdays/
Vacation days!!
5.2. Invite Reply
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.
5.2.1. Example: An invite reply
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.
Pot, et al. Expires June 18, 2015 [Page 6]
Internet-Draft WebDAV Resource Sharing December 2014
HTTP/1.1 200 OK
Content-Type: application/davnotification+xml
Content-Length: xxxx
2014-09-03T02:30:00Z
mailto:john@example.org
/calendars/users/evert/offdays/
Sorry, I'm not interested
6. Resource sharing
6.1. Feature Discovery
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.
6.2. Additional Properties for resources
The following new or modified WebDAV properties are defined for
resources and used to view or manipulate shared resources features.
6.2.1. DAV:resourcetype Property
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.
o DAV:shared-owner (Section 8.1): used to indicate that the resource
is owned by the current user and is being shared by them.
o DAV:shared (Section 8.2): used to indicate that the resource is
owned by another user and is being shared to the current user.
6.2.2. DAV:invite Property
Name: invite
Namespace: DAV:
Purpose: Used to show to whom a resource has been shared.
Pot, et al. Expires June 18, 2015 [Page 7]
Internet-Draft WebDAV Resource Sharing December 2014
Protected: This property MUST be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
COPY/MOVE behavior: This property value MUST be preserved in MOVE
operations, but MUST NOT be preserved in COPY operations.
Description: This WebDAV property is present on a resource that has
been shared by the owner, or on the resources for the sharees. It
provides a list of users to whom the resource has been shared,
along with the "status" of the sharing invites sent to each user.
In addition, servers SHOULD include a DAV:organizer XML element on
resources of the sharees to provide clients with a fast way to
determine who the sharer is. A server's local privacy policy may
prevent sharees from knowing about other sharees on a shared
calendar. If that is so server will not include DAV:user XML
elements for other sharees.
Definition:
6.2.3. DAV:shared-url Property
Name: shared-url
Namespace: DAV:
Purpose: Indicates the URL of the owner's copy of a shared resource.
Protected: This property MUST be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations.
Description: This WebDAV property MAY be present on a shared
resource. Its content is a single DAV:href element whose value is
the URL of the sharer's resource being shared.
Definition:
Pot, et al. Expires June 18, 2015 [Page 8]
Internet-Draft WebDAV Resource Sharing December 2014
6.3. Sharer Actions on Shared Resource
6.3.1. Sharing or Unsharing a Resource
To update an existing resource to be shared, the sharer simply adds
one or more sharees to the resource as per Section 6.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 6.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.
6.3.2. Manipulating Sharees of a Shared Resource
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 (Section 8.3).
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 (Section 8.3) element in the POST requests MUST contain
one or more DAV:set-invitee (Section 8.20) or DAV:remove-invitee
(Section 8.21) elements. For each DAV:set-invitee (Section 8.20)
element, the server MUST add the specified sharee access to the
resource. For each DAV:remove-invitee (Section 8.21) 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 (Section 8.13)
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
Pot, et al. Expires June 18, 2015 [Page 9]
Internet-Draft WebDAV Resource Sharing December 2014
returning the list of sharees via the DAV:invite property
(Section 6.2.2).
The client MAY include a DAV:displayname element in the DAV:set-
invitee (Section 8.20) 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 (Section 6.2.2). 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.
6.3.2.1. Example: Successful Sharee Add Request
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
mailto:eric@example.com
Eric York
Shared workspace
>> Response <<
HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
6.3.2.2. Example: Successful Multiple Sharee Change Request
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.
Pot, et al. Expires June 18, 2015 [Page 10]
Internet-Draft WebDAV Resource Sharing December 2014
>> Request <<
POST /calendars/users/cyrus/shared/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/davsharing+xml; charset="utf-8"
Content-Length: xxxx
mailto:eric@example.com
Shared workspace
mailto:wilfredo@example.com
>> Response <<
HTTP/1.1 204 No Content
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
6.4. Sharee Actions on Shared Resources
6.4.1. Replying to a Sharing Invite
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
(Section 8.16).
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 (Section 8.16) 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 (Section 8.18) 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.
Pot, et al. Expires June 18, 2015 [Page 11]
Internet-Draft WebDAV Resource Sharing December 2014
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
(Section 8.17) notification to the sharer.
After the sharee has issued a reply, the server SHOULD also remove
the notification that contained the initial invite.
6.4.1.1. Example: Accepting an 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"
/calendars/users/evert/
Tech meetups
Pot, et al. Expires June 18, 2015 [Page 12]
Internet-Draft WebDAV Resource Sharing December 2014
6.4.2. Ignoring an invitation
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.
6.4.3. Making modifications to a shared resource
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.
6.4.4. Removing a shared resource
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.
6.5. General Considerations
6.5.1. Access Levels
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:
DAV:read When present this indicates that sharees can read
information from the resource, but cannot change it. This applies
to the resource, but if the shared resource is a collection, it
also applies to the collection's children.
DAV:read-write When present this indicates that sharees can read and
write information from the resource.
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.
Pot, et al. Expires June 18, 2015 [Page 13]
Internet-Draft WebDAV Resource Sharing December 2014
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.
6.5.2. Per-instance WebDAV Properties
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.
7. Sharing privileges
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.
8. XML Element Definitions
8.1. DAV:shared-owner
Name: shared-owner
Namespace: DAV:
Pot, et al. Expires June 18, 2015 [Page 14]
Internet-Draft WebDAV Resource Sharing December 2014
Purpose: Used to indicate that a resource is being shared by the
owner.
Description: This property appears in the DAV:resourcetype property
on the resource shared by a sharer. See Section 6.2.
Definition:
8.2. DAV:shared
Name: shared
Namespace: DAV:
Purpose: Used to indicate that a resources is being shared to a
sharee.
Description: This property appears in the DAV:resourcetype property
on a resource that is shared to a sharee. See Section 6.2.
Definition:
8.3. DAV:share
Name: share
Namespace: DAV:
Purpose: A WebDAV ACL privilege to control sharing.
Description: This element represents a WebDAV ACL privilege
[RFC3744], and indicates that the current principal is allowed to
share the resource on which it is defined.
Definition:
8.4. DAV:user
Name: user
Namespace: DAV:
Pot, et al. Expires June 18, 2015 [Page 15]
Internet-Draft WebDAV Resource Sharing December 2014
Purpose: Used to show status of sharing invites sent to sharees.
Description: This element provides the "status" of a sharing invite
sent to a particular user. See Section 6.2.2.
Definition:
8.5. DAV:invite-noresponse
Name: invite-noresponse
Namespace: DAV:
Purpose: Sharing invite status.
Description: When used in a DAV:user (Section 8.4) element, this
element is used to indicate that the sharee has never replied to
the corresponding sharing invite. When used in a DAV:invite-
notification (Section 8.13) element, this element is used to
indicate to the sharee that a sharing reply is needed.
Definition:
8.6. DAV:invite-deleted
Name: invite-deleted
Namespace: DAV:
Purpose: Sharing invite status.
Description: When used in a DAV:invite-notification (Section 8.13)
element, this element is used to indicate to the sharee that a
shared resource has been unshared by the sharer.
Definition:
Pot, et al. Expires June 18, 2015 [Page 16]
Internet-Draft WebDAV Resource Sharing December 2014
8.7. DAV:invite-accepted
Name: invite-accepted
Namespace: DAV:
Purpose: Sharing invite status.
Description: When used in a DAV:user (Section 8.4) element, this
element is used to indicate that the sharee has accepted the
corresponding sharing invite. When used in a DAV:invite-
notification (Section 8.13) element, this element is used to
indicate to the sharee that the sharing invite is an update for
one they previously accepted.
Definition:
8.8. DAV:invite-declined
Name: invite-declined
Namespace: DAV:
Purpose: Sharing invite status.
Description: When used in a DAV:user (Section 8.4) element, this
element is used to indicate that the sharee has declined the
corresponding sharing invite. When used in a DAV:invite-
notification (Section 8.13) element, this element is used to
indicate to the sharee that the sharing invite is an update for
one they previously declined.
Definition:
8.9. DAV:invite-invalid
Name: invite-invalid
Namespace: DAV:
Purpose: Sharing invite status.
Pot, et al. Expires June 18, 2015 [Page 17]
Internet-Draft WebDAV Resource Sharing December 2014
Description: When used in a DAV:user (Section 8.4) element, this
element is used to indicate that the corresponding sharee is not a
valid user known to the server.
Definition:
8.10. DAV:access
Name: access
Namespace: DAV:
Purpose: Shared resource access level.
Description: When used in a DAV:user (Section 8.4) element, this
element is used to indicate the sharing access level granted to
the corresponding sharee.
Definition:
8.11. DAV:read
Name: read
Namespace: DAV:
Purpose: Shared resource access level privilege.
Description: Indicates that the access level granted only allows
sharees to read data in the shared resource (though they can write
per-instance data (Section 6.5.2)).
Definition:
8.12. DAV:read-write
Name: read-write
Namespace: DAV:
Purpose: Shared resource access level privilege.
Pot, et al. Expires June 18, 2015 [Page 18]
Internet-Draft WebDAV Resource Sharing December 2014
Description: Indicates that the access level granted allows sharees
to read and write all data in the resource.
Definition:
8.13. DAV:invite-notification
Name: invite-notification
Namespace: DAV:
Purpose: A notification used as a shared resource invite.
Description: Defines a notification message sent automatically by
the server when a sharer adds, changes or removes a sharee from a
shared resource. The DAV:href element specifies the URI of the
sharee to whom the message was sent.
Definition:
8.14. DAV:hosturl
Name: hosturl
Namespace: DAV:
Purpose: Identifies the source URL of a shared resource.
Description: Contains a single DAV:href element that refers to the
source of a shared resource - i.e., the URL of the resource shared
by the sharer.
Definition:
Pot, et al. Expires June 18, 2015 [Page 19]
Internet-Draft WebDAV Resource Sharing December 2014
8.15. DAV:organizer
Name: organizer
Namespace: DAV:
Purpose: Identifies the sharer of a shared resource.
Description: Contains a single DAV:href element that identifies the
URI of the sharer of a shared resource, and an optional
DAV:displayname element that matches that user.
Definition:
8.16. DAV:invite-reply
Name: invite-reply
Namespace: DAV:
Purpose: Root element for a POST request used to respond to a share
invitation.
Description: When a user responds to an invitation, the user issues
a POST request with an xml body. DAV:invite-reply is the root
element for this xml document.
Definition:
8.17. DAV:reply-notification
Name: reply-notification
Namespace: DAV:
Purpose: A notification used as a reply to a shared resource invite.
Description: Defines a notification message sent automatically by
the server when a sharee replies to a shared resource invite. The
DAV:href element specifies the URI of the sharee to whom the
original invite message was sent.
Pot, et al. Expires June 18, 2015 [Page 20]
Internet-Draft WebDAV Resource Sharing December 2014
Definition:
8.18. DAV:create-in
Name: create-in
Namespace: DAV:
Purpose: The target url for the new resource.
Description: When a user accepts an invitation to share a resource,
this URI will be used to create the new shared resource.
Definition:
8.19. DAV:share
Name: share
Namespace: DAV:
Purpose: Describes changes to sharees.
Description: The root element used in POST requests on resources by
sharers to manipulate the sharee list of a shared resource.
Definition:
8.20. DAV:set-invitee
Name: set-invitee
Namespace: DAV:
Purpose: Sets access for a sharee.
Description: Used to add or modify sharee access to a shared
resource. The specified access to the shared resource is given to
the sharee.
Pot, et al. Expires June 18, 2015 [Page 21]
Internet-Draft WebDAV Resource Sharing December 2014
Definition:
8.21. DAV:remove-invitee
Name: remove-invitee
Namespace: DAV:
Purpose: Removes access for a sharee.
Description: Used to remove sharee access to a shared resource. All
access to the shared resource is removed for the sharee.
Definition:
8.22. DAV:shared-as
Name: shared-as
Namespace: DAV:
Purpose: Identifies a shared resource.
Description: Returned by the server for a POST request by a sharee
accepting a shared resource invite. The DAV:href element
specifies the URI of the resource created by the acceptance.
Definition:
9. Security Considerations
TBD
10. IANA Considerations
This document does not require any actions on the part of IANA.
Pot, et al. Expires June 18, 2015 [Page 22]
Internet-Draft WebDAV Resource Sharing December 2014
11. Acknowledgments
This specification is the result of discussions between the Apple
calendar server and client teams.
12. IANA Considerations
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.
Type name: application
Subtype name: davsharing+xml
Required parameters: none
Optional parameters: none
Encoding considerations: Identical to those of "application/xml" as
described in RFC7303 [RFC7303].
Security considerations: N/A.
Interoperability considerations: There are no known interoperability
issues.
Published specification: This specification.
Applications that use this media type: No known applications
currently use this media type.
Fragment identifier considerations: N/A.
Additional information
Deprecated alias names for this type N/A.
Magic number(s) N/A.
File extension(s) xml
Macintosh file type code(s) TEXT
Person & email address to contact for further information:
me@evertpot.com
Intended usage COMMON
Pot, et al. Expires June 18, 2015 [Page 23]
Internet-Draft WebDAV Resource Sharing December 2014
Restrictions on usage There are no restrictions on where this media
Author See the "Authors' Addresses" section of this document.
Change Controller IETF
13. Normative References
[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.
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
CalDAV", RFC 6638, June 2012.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
July 2014.
Appendix A. Change History
Changes in -03:
1. Fixed access element DTD.
2. Remove MKxxx and PROPPATCH mechanism for upgrading/downgrading
shared state on a calendar collection. Instead the server
implicitly sets the state based on whether there are any sharees
or not..
3. Added CS:first-name and CS:last-name optional element to
CS:organizer.
4. Added CALDAV:supported-calendar-component-set optional element to
CS:invite-notification.
Pot, et al. Expires June 18, 2015 [Page 24]
Internet-Draft WebDAV Resource Sharing December 2014
Changes in -02:
1. Removed read-write-shared access mode - now a server that does
not support shared scheduling should advertise that via a DAV
header
Changes in -01:
1. Added CS:shared-url property
2. Clarified that notifications are only required to be sent when
sharee status is changed
Appendix B. Backwards compatibility
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.
Authors' Addresses
Evert Pot
fruux GmbH
Koenigsstrasse 32
Muenster, NRW 48143
Germany
Email: me@evertpot.com
URI: https://fruux.com/
Pot, et al. Expires June 18, 2015 [Page 25]
Internet-Draft WebDAV Resource Sharing December 2014
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Eric York
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
URI: http://www.apple.com/
Pot, et al. Expires June 18, 2015 [Page 26]