[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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

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 December 29, 2016.

Copyright Notice

   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.




Pot, et al.             Expires December 29, 2016               [Page 1]


Internet-Draft           WebDAV Resource Sharing               June 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  High-level overview . . . . . . . . . . . . . . . . . . . . .   4
   4.  Sharing a resource  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Advertising resource sharing support  . . . . . . . . . .   5
     4.2.  Required privileges . . . . . . . . . . . . . . . . . . .   5
     4.3.  Sharing POST request  . . . . . . . . . . . . . . . . . .   5
       4.3.1.  Example: Sharing a resource . . . . . . . . . . . . .   6
       4.3.2.  Example: Multiple sharee changes  . . . . . . . . . .   7
     4.4.  New WebDAV properties on shared resources . . . . . . . .   8
       4.4.1.  DAV:share-access Property . . . . . . . . . . . . . .   8
       4.4.2.  DAV:invite Property . . . . . . . . . . . . . . . . .   9
       4.4.3.  DAV:share-resource-uri Property . . . . . . . . . . .   9
     4.5.  Handling the share process  . . . . . . . . . . . . . . .  10
       4.5.1.  The invitation process  . . . . . . . . . . . . . . .  10
       4.5.2.  Instant sharing . . . . . . . . . . . . . . . . . . .  11
     4.6.  Notification Definitions  . . . . . . . . . . . . . . . .  11
       4.6.1.  Invite Notification . . . . . . . . . . . . . . . . .  11
         4.6.1.1.  Example: An invite notification . . . . . . . . .  11
       4.6.2.  Invite Reply  . . . . . . . . . . . . . . . . . . . .  13
         4.6.2.1.  Example: An invite reply  . . . . . . . . . . . .  13
     4.7.  Sharee Actions on Shared Resources  . . . . . . . . . . .  14
       4.7.1.  Replying to a Sharing Invite  . . . . . . . . . . . .  14
         4.7.1.1.  Example: Accepting an invite  . . . . . . . . . .  15
       4.7.2.  Ignoring an invitation  . . . . . . . . . . . . . . .  15
       4.7.3.  Making modifications to a shared resource . . . . . .  15
       4.7.4.  Removing a shared resource  . . . . . . . . . . . . .  16
     4.8.  General Considerations  . . . . . . . . . . . . . . . . .  16
       4.8.1.  Per-instance WebDAV Properties  . . . . . . . . . . .  16
       4.8.2.  Sharees and instances . . . . . . . . . . . . . . . .  16
       4.8.3.  Relationship between sharing access levels and WebDAV
               ACL . . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.  XML Element Definitions . . . . . . . . . . . . . . . . . . .  18
     5.1.  DAV:share-resource  . . . . . . . . . . . . . . . . . . .  18
     5.2.  DAV:share . . . . . . . . . . . . . . . . . . . . . . . .  19
     5.3.  DAV:share-invite-notification . . . . . . . . . . . . . .  19
     5.4.  DAV:share-reply-notification  . . . . . . . . . . . . . .  20
     5.5.  DAV:invite  . . . . . . . . . . . . . . . . . . . . . . .  21
     5.6.  DAV:share-access  . . . . . . . . . . . . . . . . . . . .  22
     5.7.  DAV:invite-reply  . . . . . . . . . . . . . . . . . . . .  23
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     6.1.  Forced shares . . . . . . . . . . . . . . . . . . . . . .  23
     6.2.  Notification spamming . . . . . . . . . . . . . . . . . .  24
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  25
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  25



Pot, et al.             Expires December 29, 2016               [Page 2]


Internet-Draft           WebDAV Resource Sharing               June 2016


   Appendix A.  Backwards compatibility  . . . . . . . . . . . . . .  26
   Appendix B.  Change History (to be removed prior to publication
                as an RFC  . . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

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

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

   Sharer  A user who is sharing a resource with other users.

   Sharee  A user to whom a resource has been shared.



Pot, et al.             Expires December 29, 2016               [Page 3]


Internet-Draft           WebDAV Resource Sharing               June 2016


   Sharing Invite  A message sent by a sharer to a sharee to notify a
      sharee of an invitation or update.

   Sharing Reply  A message sent by a sharee to a sharer to indicate the
      answer to an invite.

   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.

3.  High-level 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 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.

4.  Sharing a resource








Pot, et al.             Expires December 29, 2016               [Page 4]


Internet-Draft           WebDAV Resource Sharing               June 2016


4.1.  Advertising resource sharing support

   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

4.2.  Required privileges

   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.

4.3.  Sharing POST request

   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 (Section 5.1).

   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.




Pot, et al.             Expires December 29, 2016               [Page 5]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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:

   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.

   DAV:no-access  When present this indicates that access to the
      resource is revoked for the sharee.

   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.

4.3.1.  Example: Sharing a resource

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




















Pot, et al.             Expires December 29, 2016               [Page 6]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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

4.3.2.  Example: Multiple sharee changes

   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.



















Pot, et al.             Expires December 29, 2016               [Page 7]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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>

4.4.  New WebDAV properties on shared resources

   The following new or modified WebDAV properties are defined for
   resources and used to view or manipulate shared resources features.

4.4.1.  DAV:share-access Property

   Name:  share-access

   Namespace:  DAV:

   Purpose:  Allows a client to see if a resource is a shared resource
      and the access level.

   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:  Resources that are shared must have a DAV:share-access
      property.  It's value should be one of four elements:





Pot, et al.             Expires December 29, 2016               [Page 8]


Internet-Draft           WebDAV Resource Sharing               June 2016


      *  DAV:not-shared: Used to indicate that the resource is not
         shared.  This is the default, which means that if the
         DAV:share-access is omitted, this value is implied.

      *  DAV:shared-owner: used to indicate that the resource is owned
         by the current user and is being shared by them.

      *  DAV:read-write: used to indicate that the resource is shared,
         and the current instance is the 'shared instance' which has
         read-write access.

      *  DAV:read: used to indicate that the resource is shared, and the
         current instance is the 'shared instance', and only read access
         is provided.

4.4.2.  DAV:invite Property

   Name:  invite

   Namespace:  DAV:

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

   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.  In those cases a server may hide information about
      other sharees.

4.4.3.  DAV:share-resource-uri Property

   Name:  share-resource-uri

   Namespace:  DAV:



Pot, et al.             Expires December 29, 2016               [Page 9]


Internet-Draft           WebDAV Resource Sharing               June 2016


   Purpose:  A unique URI that identifies the 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 SHOULD 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.  The property MUST
      contain a URI that uniquely identifies the original shared
      resource.  The URI MAY refer to a resource hosted on the same
      server, but MAY also refer to a URN.  A key requirement is that
      this URI remains stable during the life-time of a share.

4.5.  Handling the share process

   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.

4.5.1.  The invitation process

   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
   (Section 4.4.2) property.  Each sharee will have one of the following
   elements:

   DAV:invite-noresponse  The sharee was invited, but has not yet
      responded to the invite.

   DAV:invite-accepted  The sharee has accepted the invite.

   DAV:invite-declined  The sharee has declined the invite.



Pot, et al.             Expires December 29, 2016              [Page 10]


Internet-Draft           WebDAV Resource Sharing               June 2016


   DAV:invite-invalid  The invitation was invalid or could not be
      delivered.

   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 (Section 4.6.1) in their notification collection.  After
   the sharee has accepted or declined the invite, their status will
   reflect this response.

4.5.2.  Instant sharing

   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.

4.6.  Notification Definitions

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

4.6.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.6.1.1.  Example: An invite notification

   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.










Pot, et al.             Expires December 29, 2016              [Page 11]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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



Pot, et al.             Expires December 29, 2016              [Page 12]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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.

4.6.2.  Invite Reply

   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.

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

   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.



Pot, et al.             Expires December 29, 2016              [Page 13]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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.

4.7.  Sharee Actions on Shared Resources

4.7.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 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 (Section 5.7).

   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 (Section 5.7) 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.




Pot, et al.             Expires December 29, 2016              [Page 14]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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 (Section 5.4) notification to the sharer.

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

4.7.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:comment>Thanks for the share!</D:comment>
   </D:invite-reply>

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

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





Pot, et al.             Expires December 29, 2016              [Page 15]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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.

4.7.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 (Section 4.4.2) property.

4.8.  General Considerations

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

4.8.2.  Sharees and instances

   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.





Pot, et al.             Expires December 29, 2016              [Page 16]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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.

4.8.3.  Relationship between sharing access levels and WebDAV ACL

   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



Pot, et al.             Expires December 29, 2016              [Page 17]


Internet-Draft           WebDAV Resource Sharing               June 2016


   the original sharer to have any privileges to any of the sharee
   instances.

5.  XML Element Definitions

   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.

5.1.  DAV:share-resource

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







Pot, et al.             Expires December 29, 2016              [Page 18]


Internet-Draft           WebDAV Resource Sharing               June 2016


5.2.  DAV:share

   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>

5.3.  DAV:share-invite-notification

   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





































Pot, et al.             Expires December 29, 2016              [Page 19]


Internet-Draft           WebDAV Resource Sharing               June 2016


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

5.4.  DAV:share-reply-notification

   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





Pot, et al.             Expires December 29, 2016              [Page 20]


Internet-Draft           WebDAV Resource Sharing               June 2016


   <!-- 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)>

5.5.  DAV:invite

   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.


























Pot, et al.             Expires December 29, 2016              [Page 21]


Internet-Draft           WebDAV Resource Sharing               June 2016


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

5.6.  DAV:share-access

   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.







Pot, et al.             Expires December 29, 2016              [Page 22]


Internet-Draft           WebDAV Resource Sharing               June 2016


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

5.7.  DAV:invite-reply

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

6.  Security Considerations

6.1.  Forced shares

   When this specification is implemented without the use of the
   notification flow, as described in Section 4.5.2, it may be possible




Pot, et al.             Expires December 29, 2016              [Page 23]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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.

6.2.  Notification spamming

   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.

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



Pot, et al.             Expires December 29, 2016              [Page 24]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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

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

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

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






Pot, et al.             Expires December 29, 2016              [Page 25]


Internet-Draft           WebDAV Resource Sharing               June 2016


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

   [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 -04:

   1.  Corrected the application/davsharing+xml mimetype where it was
       misspelled.

   2.  Lots of small spelling/english fixes.

   3.  Changed sharer-resource-uri into share-resource-uri.  This new
       uri makes a bit more sense.

   Changes in -03:

   1.   A major rewrite, making many xml elements self-consistent and
        with other WebDAV specifications.




Pot, et al.             Expires December 29, 2016              [Page 26]


Internet-Draft           WebDAV Resource Sharing               June 2016


   2.   While all of the same data is still there, many xml elements
        have changed.

   3.   Added 'Instant sharing' concept, making notifications
        integration optional.

   4.   Removed DAV:share-mode

   5.   Added DAV:share-access

   6.   Added a DAV:sharee element with a consistent set of information
        about sharees.

   7.   Clarified the nature of DAV:invite-accepted element in
        DAV:invite-notifaction documents.

   8.   Introduced the DAV:reply-url element.

   9.   DAV:sharer-instance-url is now DAV:sharer-instance-uri and may
        contain other uris.

   10.  Added security concerns.

   11.  Complete rewrite of the XML Elements section, using DTDs.

   12.  DAV:invite-notification is now DAV:share-invite-notification.

   13.  DAV:reply-notification is now DAV:share-reply-notification.

   14.  Added design philosophy section.

   15.  Added information about relationship with WebDAV ACL.

   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.



Pot, et al.             Expires December 29, 2016              [Page 27]


Internet-Draft           WebDAV Resource Sharing               June 2016


   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

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 December 29, 2016              [Page 28]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/