Skip to main content

WebDAV Resource Sharing
draft-pot-webdav-resource-sharing-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Evert Pot , Cyrus Daboo , Eric York
Last updated 2015-07-20
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pot-webdav-resource-sharing-02
Network Working Group                                             E. Pot
Internet-Draft                                                fruux GmbH
Expires: January 21, 2016                                       C. Daboo
                                                                 E. York
                                                              Apple Inc.
                                                           July 20, 2015

                        WebDAV Resource Sharing
                  draft-pot-webdav-resource-sharing-02

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 January 21, 2016.

Copyright Notice

   Copyright (c) 2015 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 January 21, 2016                [Page 1]
Internet-Draft           WebDAV Resource Sharing               July 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Notification Definitions  . . . . . . . . . . . . . . . . . .   5
     4.1.  Invite Notification . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Example: An invite notification . . . . . . . . . . .   5
     4.2.  Invite Reply  . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Example: An invite reply  . . . . . . . . . . . . . .   6
   5.  Resource sharing  . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Feature Discovery . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Additional Properties for resources . . . . . . . . . . .   7
       5.2.1.  DAV:share-mode Property . . . . . . . . . . . . . . .   7
       5.2.2.  DAV:invite Property . . . . . . . . . . . . . . . . .   7
       5.2.3.  DAV:sharer-resource-url Property  . . . . . . . . . .   8
     5.3.  Sharer Actions on Shared Resource . . . . . . . . . . . .   9
       5.3.1.  Sharing or Unsharing a Resource . . . . . . . . . . .   9
       5.3.2.  Manipulating Sharees of a Shared Resource . . . . . .   9
         5.3.2.1.  Example: Successful Sharee Add Request  . . . . .  10
         5.3.2.2.  Example: Successful Multiple Sharee Change
                   Request . . . . . . . . . . . . . . . . . . . . .  10
     5.4.  Sharee Actions on Shared Resources  . . . . . . . . . . .  11
       5.4.1.  Replying to a Sharing Invite  . . . . . . . . . . . .  11
         5.4.1.1.  Example: Accepting an invite  . . . . . . . . . .  12
       5.4.2.  Ignoring an invitation  . . . . . . . . . . . . . . .  13
       5.4.3.  Making modifications to a shared resource . . . . . .  13
       5.4.4.  Removing a shared resource  . . . . . . . . . . . . .  13
     5.5.  General Considerations  . . . . . . . . . . . . . . . . .  13
       5.5.1.  Access Levels . . . . . . . . . . . . . . . . . . . .  13
       5.5.2.  Per-instance WebDAV Properties  . . . . . . . . . . .  14
   6.  Sharing privileges  . . . . . . . . . . . . . . . . . . . . .  14
   7.  XML Element Definitions . . . . . . . . . . . . . . . . . . .  14
     7.1.  DAV:shared-owner  . . . . . . . . . . . . . . . . . . . .  14
     7.2.  DAV:shared  . . . . . . . . . . . . . . . . . . . . . . .  15
     7.3.  DAV:share-mode  . . . . . . . . . . . . . . . . . . . . .  15
     7.4.  DAV:share . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.5.  DAV:user  . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.6.  DAV:invite-noresponse . . . . . . . . . . . . . . . . . .  16
     7.7.  DAV:invite-deleted  . . . . . . . . . . . . . . . . . . .  16
     7.8.  DAV:invite-accepted . . . . . . . . . . . . . . . . . . .  17
     7.9.  DAV:invite-declined . . . . . . . . . . . . . . . . . . .  17
     7.10. DAV:invite-invalid  . . . . . . . . . . . . . . . . . . .  18
     7.11. DAV:access  . . . . . . . . . . . . . . . . . . . . . . .  18
     7.12. DAV:read  . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.13. DAV:read-write  . . . . . . . . . . . . . . . . . . . . .  19
     7.14. DAV:invite-notification . . . . . . . . . . . . . . . . .  19
     7.15. DAV:hosturl . . . . . . . . . . . . . . . . . . . . . . .  19

Pot, et al.             Expires January 21, 2016                [Page 2]
Internet-Draft           WebDAV Resource Sharing               July 2015

     7.16. DAV:organizer . . . . . . . . . . . . . . . . . . . . . .  20
     7.17. DAV:invite-reply  . . . . . . . . . . . . . . . . . . . .  20
     7.18. DAV:reply-notification  . . . . . . . . . . . . . . . . .  21
     7.19. DAV:create-in . . . . . . . . . . . . . . . . . . . . . .  21
     7.20. DAV:share-resource  . . . . . . . . . . . . . . . . . . .  21
     7.21. DAV:set-invitee . . . . . . . . . . . . . . . . . . . . .  22
     7.22. DAV:remove-invitee  . . . . . . . . . . . . . . . . . . .  22
     7.23. DAV:shared-as . . . . . . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  24
   Appendix A.  Backwards compatibility  . . . . . . . . . . . . . .  25
   Appendix B.  Change History (to be removed prior to publication
                as an RFC  . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

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 January 21, 2016                [Page 3]
Internet-Draft           WebDAV Resource Sharing               July 2015

2.  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.

   The DTD samples used in this document are for illustrative purposes
   only.  The conventions and restrictions described in [RFC4918]
   section 17.

3.  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 January 21, 2016                [Page 4]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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.

4.  Notification Definitions

   In order to facilitate the process of sharing invitations, this
   specification uses WebDAV notifications, and defines several new
   notification types.

4.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.

4.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 January 21, 2016                [Page 5]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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>

4.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.

4.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 January 21, 2016                [Page 6]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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>

5.  Resource sharing

5.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.

5.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.

5.2.1.  DAV:share-mode Property

   Resources that are shared must have a DAV:share-mode property.  It's
   value should be one of two elements:

   o  DAV:shared-owner (Section 7.1): used to indicate that the resource
      is owned by the current user and is being shared by them.

   o  DAV:shared (Section 7.2): used to indicate that the resource is
      owned by another user and is being shared to the current user.

5.2.2.  DAV:invite Property

   Name:  invite

   Namespace:  DAV:

   Purpose:  Used to show to whom a resource has been shared.

Pot, et al.             Expires January 21, 2016                [Page 7]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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:principal 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:

   <!ELEMENT invite (organizer?, user*)>

5.2.3.  DAV:sharer-resource-url Property

   Name:  sharer-resource-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:

   <!ELEMENT sharer-resource-url (DAV:href)>

Pot, et al.             Expires January 21, 2016                [Page 8]
Internet-Draft           WebDAV Resource Sharing               July 2015

5.3.  Sharer Actions on Shared Resource

5.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 5.3.2.  The server
   MUST indicate that the resource is now shared by updating the value
   of the DAV:share-mode WebDAV property.

   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 indicate that the resource is no longer shared by removing the
   value from the DAV:share-mode WebDAV property.

5.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-resource (Section 7.20).

   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 (Section 7.20) element in the POST requests
   MUST contain one or more DAV:set-invitee (Section 7.21) or
   DAV:remove-invitee (Section 7.22) elements.  For each DAV:set-invitee
   (Section 7.21) element, the server MUST add the specified sharee
   access to the resource.  For each DAV:remove-invitee (Section 7.22)
   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 7.14) 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
   (Section 5.2.2).

Pot, et al.             Expires January 21, 2016                [Page 9]
Internet-Draft           WebDAV Resource Sharing               July 2015

   The client MAY include a DAV:displayname element in the DAV:set-
   invitee (Section 7.21) 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 5.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.

5.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

   <?xml version="1.0" encoding="utf-8" ?>
   <D:share-resource 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-resource>

   >> Response <<

   HTTP/1.1 200 OK
   Cache-Control: no-cache
   Date: Sat, 11 Nov 2006 09:32:12 GMT

5.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 January 21, 2016               [Page 10]
Internet-Draft           WebDAV Resource Sharing               July 2015

   >> 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-resource 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-resource>

   >> Response <<

   HTTP/1.1 204 No Content
   Cache-Control: no-cache
   Date: Sat, 11 Nov 2006 09:32:12 GMT

5.4.  Sharee Actions on Shared Resources

5.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 7.17).

   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 7.17) 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 7.19) 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 January 21, 2016               [Page 11]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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 7.18) notification to the sharer.

   After the sharee has issued a reply, the server SHOULD also remove
   the notification that contained the initial invite.

5.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"

   <?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>

Pot, et al.             Expires January 21, 2016               [Page 12]
Internet-Draft           WebDAV Resource Sharing               July 2015

5.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.

5.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.

5.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.

5.5.  General Considerations

5.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 January 21, 2016               [Page 13]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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.

5.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.

6.  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.

7.  XML Element Definitions

7.1.  DAV:shared-owner

   Name:  shared-owner

   Namespace:  DAV:

Pot, et al.             Expires January 21, 2016               [Page 14]
Internet-Draft           WebDAV Resource Sharing               July 2015

   Purpose:  Used to indicate that a resource is being shared by the
      owner.

   Description:  This property appears in the DAV:share-mode property on
      the resource shared by a sharer.  See Section 5.2.

   Definition:

   <!ELEMENT shared-owner EMPTY>

7.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:share-mode property on
      a resource that is shared to a sharee.  See Section 5.2.

   Definition:

   <!ELEMENT shared EMPTY>

7.3.  DAV:share-mode

   Name:  share-mode

   Namespace:  DAV:

   Purpose:  Used to indicate that a resource is being shared.

   Description:  This is a WebDAV property that may appear on an
      instance of a shared resource.  See Section 5.2.

   Definition:

   <!ELEMENT share-mode (shared | shared-owner)?>

7.4.  DAV:share

   Name:  share

   Namespace:  DAV:

   Purpose:  A WebDAV ACL privilege to control sharing.

Pot, et al.             Expires January 21, 2016               [Page 15]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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:

   <!ELEMENT share EMPTY>

7.5.  DAV:user

   Name:  user

   Namespace:  DAV:

   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 5.2.2.

   Definition:

   <!ELEMENT user (href, displayname?, (invite-noresponse |
                   invite-accepted | invite-declined | invite-invalid),
                   access, comment?)>

7.6.  DAV:invite-noresponse

   Name:  invite-noresponse

   Namespace:  DAV:

   Purpose:  Sharing invite status.

   Description:  When used in a DAV:user (Section 7.5) 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 7.14) element, this element is used to
      indicate to the sharee that a sharing reply is needed.

   Definition:

   <!ELEMENT invite-noresponse EMPTY>

7.7.  DAV:invite-deleted

   Name:  invite-deleted

   Namespace:  DAV:

Pot, et al.             Expires January 21, 2016               [Page 16]
Internet-Draft           WebDAV Resource Sharing               July 2015

   Purpose:  Sharing invite status.

   Description:  When used in a DAV:invite-notification (Section 7.14)
      element, this element is used to indicate to the sharee that a
      shared resource has been unshared by the sharer.

   Definition:

   <!ELEMENT invite-deleted EMPTY>

7.8.  DAV:invite-accepted

   Name:  invite-accepted

   Namespace:  DAV:

   Purpose:  Sharing invite status.

   Description:  When used in a DAV:user (Section 7.5) element, this
      element is used to indicate that the sharee has accepted the
      corresponding sharing invite.  When used in a DAV:invite-
      notification (Section 7.14) element, this element is used to
      indicate to the sharee that the sharing invite is an update for
      one they previously accepted.

   Definition:

   <!ELEMENT invite-accepted EMPTY>

7.9.  DAV:invite-declined

   Name:  invite-declined

   Namespace:  DAV:

   Purpose:  Sharing invite status.

   Description:  When used in a DAV:user (Section 7.5) element, this
      element is used to indicate that the sharee has declined the
      corresponding sharing invite.  When used in a DAV:invite-
      notification (Section 7.14) element, this element is used to
      indicate to the sharee that the sharing invite is an update for
      one they previously declined.

   Definition:

   <!ELEMENT invite-declined EMPTY>

Pot, et al.             Expires January 21, 2016               [Page 17]
Internet-Draft           WebDAV Resource Sharing               July 2015

7.10.  DAV:invite-invalid

   Name:  invite-invalid

   Namespace:  DAV:

   Purpose:  Sharing invite status.

   Description:  When used in a DAV:user (Section 7.5) element, this
      element is used to indicate that the corresponding sharee is not a
      valid user known to the server.

   Definition:

   <!ELEMENT invite-invalid EMPTY>

7.11.  DAV:access

   Name:  access

   Namespace:  DAV:

   Purpose:  Shared resource access level.

   Description:  When used in a DAV:user (Section 7.5) element, this
      element is used to indicate the sharing access level granted to
      the corresponding sharee.

   Definition:

   <!ELEMENT access (read | read-write)>

7.12.  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 5.5.2)).

   Definition:

   <!ELEMENT read EMPTY>

Pot, et al.             Expires January 21, 2016               [Page 18]
Internet-Draft           WebDAV Resource Sharing               July 2015

7.13.  DAV:read-write

   Name:  read-write

   Namespace:  DAV:

   Purpose:  Shared resource access level privilege.

   Description:  Indicates that the access level granted allows sharees
      to read and write all data in the resource.

   Definition:

   <!ELEMENT read-write EMPTY>

7.14.  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:

   <!ELEMENT invite-notification (
               dav:href,
               (invite-noresponse | invite-deleted |
               invite-accepted | invite-declined),
               access, principal,
               comment?,
   >

7.15.  DAV:hosturl

   Name:  hosturl

   Namespace:  DAV:

   Purpose:  Identifies the source URL of a shared resource.

Pot, et al.             Expires January 21, 2016               [Page 19]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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:

   <!ELEMENT hosturl (DAV:href)>

7.16.  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:

   <!ELEMENT organizer (href,
                        displayname?)?)>

7.17.  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:

   <!ELEMENT invite-reply (href,
                           (invite-accepted | invite-declined),
                           hosturl, create-in?, comment?>

Pot, et al.             Expires January 21, 2016               [Page 20]
Internet-Draft           WebDAV Resource Sharing               July 2015

7.18.  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.

   Definition:

   <!ELEMENT invite-reply (href,
                           (invite-accepted | invite-declined),
                           hosturl, create-in?, comment?>

7.19.  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:

   <!ELEMENT create-in (DAV:href)>

7.20.  DAV:share-resource

   Name:  share-resource

   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:

   <!ELEMENT share-resource (set | remove)*>

Pot, et al.             Expires January 21, 2016               [Page 21]
Internet-Draft           WebDAV Resource Sharing               July 2015

7.21.  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.

   Definition:

   <!ELEMENT set-invitee (href, displayname?, comment?,
                  (read | read-write)>

7.22.  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:

   <!ELEMENT remove-invitee (href)>

7.23.  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:

   <!ELEMENT shared-as (DAV:href)>

Pot, et al.             Expires January 21, 2016               [Page 22]
Internet-Draft           WebDAV Resource Sharing               July 2015

8.  Security Considerations

   TBD

9.  IANA Considerations

   This document does not require any actions on the part of IANA.

10.  Acknowledgments

   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.

11.  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.

Pot, et al.             Expires January 21, 2016               [Page 23]
Internet-Draft           WebDAV Resource Sharing               July 2015

   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

   Restrictions on usage  There are no restrictions on where this media

   Author  See the "Authors' Addresses" section of this document.

   Change Controller  IETF

12.  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, DOI 10.17487/RFC3744, May
              2004, <http://www.rfc-editor.org/info/rfc3744>.

   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
              DOI 10.17487/RFC4791, March 2007,
              <http://www.rfc-editor.org/info/rfc4791>.

   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
              Authoring and Versioning (WebDAV)", RFC 4918,
              DOI 10.17487/RFC4918, June 2007,
              <http://www.rfc-editor.org/info/rfc4918>.

   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
              Authoring and Versioning (WebDAV)", RFC 6352,
              DOI 10.17487/RFC6352, August 2011,
              <http://www.rfc-editor.org/info/rfc6352>.

Pot, et al.             Expires January 21, 2016               [Page 24]
Internet-Draft           WebDAV Resource Sharing               July 2015

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <http://www.rfc-editor.org/info/rfc7303>.

Appendix A.  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.

Appendix B.  Change History (to be removed prior to publication as an
             RFC

   Changes in -02:

   1.  Renamed DAV:shared-url to DAV:sharer-instance-url

   2.  Introduced DAV:share-mode WebDAV property

   3.  Removed additions to DAV:resource-type to indicate that a
       resource is shared.

   Changes in -01:

   1.  Fixed some issues in the DTD declatations of set-invitee and
       remove-invitee.

   2.  Removed an unused normative reference.

   3.  Removed 'open issues' section.

   4.  Added a paragraph about xml/dtd handling with a reference to
       RFC4917

   5.  Renamed DAV:share to DAV:share-resource for the POST request

Pot, et al.             Expires January 21, 2016               [Page 25]
Internet-Draft           WebDAV Resource Sharing               July 2015

Authors' Addresses

   Evert Pot
   fruux GmbH
   Koenigsstrasse 32
   Muenster, NRW  48143
   Germany

   Email: me@evertpot.com
   URI:   https://fruux.com/

   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 January 21, 2016               [Page 26]