aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/caldav-sharing.txt
diff options
context:
space:
mode:
authorfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
committerfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
commitb35122f7a6ad42756c35bb60ba1f06c3dcd45c77 (patch)
treeccdf373ce6475d264778523259cc32899b732fe7 /vendor/sabre/dav/docs/caldav-sharing.txt
parente3504df514d306cfe6b83e44a11f550664564af4 (diff)
downloadvolse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.gz
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.bz2
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.zip
add sabre (1.8.x) via composer in the !@#$ place it wants to be
Diffstat (limited to 'vendor/sabre/dav/docs/caldav-sharing.txt')
-rw-r--r--vendor/sabre/dav/docs/caldav-sharing.txt1624
1 files changed, 1624 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/caldav-sharing.txt b/vendor/sabre/dav/docs/caldav-sharing.txt
new file mode 100644
index 000000000..c69d6bbbe
--- /dev/null
+++ b/vendor/sabre/dav/docs/caldav-sharing.txt
@@ -0,0 +1,1624 @@
+
+
+
+Calendar Server Extension C. Daboo
+ E. York
+ Apple Inc.
+ September 19, 2012
+
+
+ Shared and Published Calendars in CalDAV
+
+Abstract
+
+ This specification defines an extension to CalDAV that enables the
+ sharing of calendars between users on a CalDAV server.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Additional Principal Properties . . . . . . . . . . . . . 5
+ 4.1.1. CS:notification-URL Property . . . . . . . . . . . . . 6
+ 4.2. Properties on Notification Resources . . . . . . . . . . . 6
+ 4.2.1. CS:notificationtype Property . . . . . . . . . . . . . 6
+ 5. Shared Calendaring . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. Feature Discovery . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. Additional Properties for Calendars . . . . . . . . . . . 7
+ 5.2.1. DAV:resourcetype Property . . . . . . . . . . . . . . 7
+ 5.2.2. CS:invite Property . . . . . . . . . . . . . . . . . . 8
+ 5.2.3. CS:allowed-sharing-modes Property . . . . . . . . . . 8
+ 5.2.4. CS:shared-url Property . . . . . . . . . . . . . . . . 9
+ 5.3. Sharer Actions on Shared Calendars . . . . . . . . . . . . 9
+ 5.3.1. Sharing or Unsharing a Calendar . . . . . . . . . . . 9
+ 5.3.2. Manipulating Sharees of a Shared Calendar . . . . . . 10
+ 5.3.2.1. Example: Successful Sharee Add Request . . . . . . 11
+ 5.3.2.2. Example: Successful Multiple Sharee Change
+ Request . . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. Sharee Actions on Shared Calendars . . . . . . . . . . . . 12
+ 5.4.1. Replying to a Sharing Invite . . . . . . . . . . . . . 12
+ 5.4.2. Removing a Shared Calendar . . . . . . . . . . . . . . 13
+ 5.5. General Considerations . . . . . . . . . . . . . . . . . . 13
+ 5.5.1. Access Levels . . . . . . . . . . . . . . . . . . . . 13
+ 5.5.2. Allowing or Disallowing Sharing . . . . . . . . . . . 13
+ 5.5.3. Per-user WebDAV Properties . . . . . . . . . . . . . . 14
+ 5.5.4. Per-user Calendar Data . . . . . . . . . . . . . . . . 14
+ 5.5.5. Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
+ 6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 16
+ 6.1. CS:shared-owner . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+Daboo & York [Page 1]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ 6.2. CS:shared . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3. CS:can-be-shared . . . . . . . . . . . . . . . . . . . . . 17
+ 6.4. CS:can-be-published . . . . . . . . . . . . . . . . . . . 18
+ 6.5. CS:user . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.6. CS:invite-noresponse . . . . . . . . . . . . . . . . . . . 18
+ 6.7. CS:invite-deleted . . . . . . . . . . . . . . . . . . . . 19
+ 6.8. CS:invite-accepted . . . . . . . . . . . . . . . . . . . . 19
+ 6.9. CS:invite-declined . . . . . . . . . . . . . . . . . . . . 19
+ 6.10. CS:invite-invalid . . . . . . . . . . . . . . . . . . . . 20
+ 6.11. CS:access . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.12. CS:read . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.13. CS:read-write . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.14. CS:summary . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.15. CS:invite-notification . . . . . . . . . . . . . . . . . . 22
+ 6.16. CS:uid . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 6.17. CS:hosturl . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.18. CS:organizer . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.19. CS:common-name . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.20. CS:first-name . . . . . . . . . . . . . . . . . . . . . . 24
+ 6.21. CS:last-name . . . . . . . . . . . . . . . . . . . . . . . 24
+ 6.22. CS:invite-reply . . . . . . . . . . . . . . . . . . . . . 24
+ 6.23. CS:in-reply-to . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.24. CS:notification . . . . . . . . . . . . . . . . . . . . . 25
+ 6.25. CS:dtstamp . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 6.26. CS:share . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 6.27. CS:set . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 6.28. CS:remove . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 6.29. CS:shared-as . . . . . . . . . . . . . . . . . . . . . . . 27
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . . 28
+ Appendix A. Change History . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & York [Page 2]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+1. Introduction
+
+ CalDAV [RFC4791] provides a way for calendar users to store calendar
+ data and exchange this data via scheduling operations. Based on the
+ WebDAV [RFC4918] protocol, it also includes the ability to manage
+ access to calendar data via the WebDAV ACL [RFC3744] extension.
+
+ WebDAV ACL [RFC3744] provides a way to manage fine-grained access
+ controls on WebDAV resources. Whilst this could be used directly to
+ manage sharing of calendars, experience has shown that client
+ developers are averse to using it due to its complexity. Instead a
+ simpler process for sharing calendars is preferred.
+
+ This extension defines a way for individual calendar users to share
+ calendars with other users. This is done via an "opt-in" process in
+ which a sharing invite is sent from the sharer to a sharee, allowing
+ the sharee to accept or decline. If the sharee accepts the sharing
+ invite, the shared calendar is made available to them in their own
+ calendar home collection (i.e., alongside their own personal
+ calendars). HTTP POST operations are used to manage the sharing
+ invitations and replies, and WebDAV properties are used to expose the
+ state of shared calendars.
+
+
+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.
+
+ The namespace "http://calendarserver.org/ns/" is used for XML
+ elements defined in this specification. When XML element types in
+ that namespace are referenced in this document outside of the context
+ of an XML fragment, the string "CS:" will be prefixed to the element
+ type names.
+
+ Terms Used:
+
+ Sharer A calendar user who is sharing a calendar with other calendar
+ users.
+
+
+
+
+
+
+Daboo & York [Page 3]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Sharee A calendar user to whom a calendar has been shared.
+
+ Sharing Invite A message sent by a sharer to a sharee to indicate
+ the status of a shared calendar.
+
+ Sharing Reply A message sent by a sharee to a sharer to indicate the
+ status of a shared calendar.
+
+
+3. Overview
+
+ This section provides a basic overview of this protocol by way of a
+ simple use case of a sharer sharing a calendar with a single sharee.
+
+ To share a calendar with another user, the sharer's client executes
+ an HTTP POST request against the calendar collection resource for the
+ calendar to be shared. The POST request body will contain details of
+ the calendar user to whom the calendar 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 calendar 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 calendar. If the sharee chooses to decline, then nothing
+ changes for that sharee. If the sharee chooses to accept, then the
+ server automatically creates a new calendar collection resource in
+ the sharee's calendar home collection, and ensures that calendar
+ provides a mapping to the actual shared calendar of the sharer. Thus
+ the shared calendar is available to the sharee as just another
+ calendar in their calendar home. The server enforces the appropriare
+ access privileges for the sharee.
+
+ At any time, the sharer can inspect properties on the calendar
+ collection 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 a shared calendar set to appear in their calendar
+ home collection, they can remove it and decline the sharing invite by
+ simply having their client issue an HTTP DELETE request on the shared
+ calendar collection. That does not delete any calendar data, but
+ rather simply removes the "link" to the sharer's calendar collection
+ and sets the sharee's inviate status to declined.
+
+
+
+
+
+
+Daboo & York [Page 4]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+4. Notifications
+
+ In order to facilitate the process of sharing invitations, this
+ specification defines a new generic notification mechanism for CalDAV
+ servers. When this feature is available, a CS:notification-URL
+ (Section 4.1.1) property appears on principal resources for those
+ principals who are able to receive notifications. That property
+ specifies a single DAV:href element whose content refers to a WebDAV
+ collection resource. Notification "messages" are deposited into this
+ collection and can be retrieved by clients and acted on accordingly.
+
+ The notification collection referenced by the CS:notification-URL
+ (Section 4.1.1) property MUST have a DAV:resourcetype property with
+ DAV:collection and CS:notification (Section 6.24) child elements.
+
+ Notification "messages" are XML documents stored as resources in the
+ notification collection. Each XML document contains a CS:
+ notification (Section 6.24) element as its root. The root element
+ contains a CS:dtstamp (Section 6.25) element, and one additional
+ element which represents the type of notification being conveyed in
+ the message. That child element will typically contain additional
+ content that describes the notification.
+
+ Each notification resource has a CS:notificationtype (Section 4.2.1)
+ property which contains as its single child element an empty element
+ that matches the child element of the notification resource XML
+ document root. Any attributes on the child element in the XML
+ document are also present in the property child element.
+
+ Notifications are automatically generated by the server (perhaps in
+ response to a client action) with an appropriate resource stored in
+ the notifications collection of the user to whom the notification is
+ targeted. Clients SHOULD monitor the notification collection looking
+ for new notification resources. When doing so, clients SHOULD look
+ at the CS:notificationtype (Section 4.2.1) property to ensure that
+ the notification is of a type that the client can handle. Once a
+ client has handled the notification in whatever way is appropriate it
+ SHOULD delete the notification resource. Servers MAY delete
+ notification resources on their own if they determine that the
+ notifications are no longer relevant or valid. Servers MAY coalesce
+ notifications as appropriate.
+
+4.1. Additional Principal Properties
+
+ This section defines new properties for WebDAV principal resources as
+ defined in RFC3744 [RFC3744]. These properties are likely to be
+ protected but the server MAY allow them to be written by appropriate
+ users.
+
+
+
+Daboo & York [Page 5]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+4.1.1. CS:notification-URL Property
+
+ Name: notification-URL
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Identify the URL of the notification collection owned by
+ the associated principal resource.
+
+ Protected: This property SHOULD 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 SHOULD be preserved in COPY
+ and MOVE operations.
+
+ Description: This property is needed for a client to determine where
+ the notification collection of the current user is located so that
+ processing of notification messages can occur. If not present,
+ then the associated calendar user is not enabled for notification
+ messages on the server.
+
+ Definition:
+
+ <!ELEMENT notification-URL (DAV:href)>
+
+4.2. Properties on Notification Resources
+
+ The following new WebDAV properties are defined for notification
+ resources.
+
+4.2.1. CS:notificationtype Property
+
+ Name: notificationtype
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Identify the type of notification of the corresponding
+ 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]).
+
+
+
+
+Daboo & York [Page 6]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ COPY/MOVE behavior: This property value MUST be preserved in COPY
+ and MOVE operations.
+
+ Description: This property allows a client, via a PROPFIND Depth:1
+ request, to quickly find notification messages that the client can
+ handle in a notification collection. The single child element is
+ the notification resource root element's child defining the
+ notification itself. This element MUST be empty, though any
+ attributes on the element in the notification resource MUST be
+ present in the property element.
+
+ Definition:
+
+ <!ELEMENT notificationtype (invite-notification | invite-reply)>
+ <!-- Child elements are empty but will have appropriate attributes.
+ Any valid notification message child element can appear.-->
+
+
+5. Shared Calendaring
+
+5.1. Feature Discovery
+
+ A server that supports the features described in this document MUST
+ include "calendarserver-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 Calendars
+
+ The following new or modified WebDAV properties are defined for
+ calendar collections and used to view or manipulate shared calendar
+ features.
+
+5.2.1. DAV:resourcetype Property
+
+ Calendar collections that are shared have addition elements listed in
+ their DAV:resourcetype property in addition to DAV:collection and
+ CALDAV:calendar.
+
+ o CS:shared-owner (Section 6.1): used to indicate that the calendar
+ is owned by the current user and is being shared by them.
+
+ o CS:shared (Section 6.2): used to indicate that the calendar is
+ owned by another user and is being shared to the current user.
+
+
+
+
+
+
+
+Daboo & York [Page 7]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+5.2.2. CS:invite Property
+
+ Name: invite
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to show to whom a calendar 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 COPY
+ and MOVE operations.
+
+ Description: This WebDAV property is present on a calendar
+ collection resource that has been shared by the owner, or on the
+ calendar collection resources of the sharees of the calendar. It
+ provides a list of users to whom the calendar has been shared,
+ along with the "status" of the sharing invites sent to each user.
+ In addition, servers SHOULD include a CS:organizer XML element on
+ calendar collection 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 CS:user XML elements for other sharees.
+
+ Definition:
+
+ <!ELEMENT invite (organizer?, user*)>
+
+5.2.3. CS:allowed-sharing-modes Property
+
+ Name: allowed-sharing-modes
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to show which modes of sharing are supported on a
+ calendar collection.
+
+ 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]).
+
+
+
+
+Daboo & York [Page 8]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ COPY/MOVE behavior: This property value MUST be preserved in COPY
+ and MOVE operations.
+
+ Description: This WebDAV property is present on a calendar
+ collection resource that can been shared or published. It
+ provides a list of options indicating what sharing modes are
+ allowed as per Section 5.5.2.
+
+ Definition:
+
+ <!ELEMENT allowed-sharing-modes
+ (can-be-shared?, can-be-published?)>
+
+5.2.4. CS:shared-url Property
+
+ Name: shared-url
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Indicates the URL of the owner's copy of a shared calendar.
+
+ 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 is present on a shared calendar
+ collection resource that appears in a sharee's calendar home
+ collection. Its content is a single DAV:href element whose value
+ is the URL of the sharer's calendar being shared.
+
+ Definition:
+
+ <!ELEMENT shared-url (DAV:href)>
+
+5.3. Sharer Actions on Shared Calendars
+
+5.3.1. Sharing or Unsharing a Calendar
+
+ To update an existing calendar to be shared, the sharer simply adds
+ one or more sharees to the calendar collection as per Section 5.3.2.
+ The server MUST update the DAV:resourcetype property on the calendar
+ collection to ensure it contains a CS:shared-owner XML element to
+ indicate the calendar collection is now shared.
+
+
+
+Daboo & York [Page 9]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ To unshare a calendar, the sharer simply removes all sharees to the
+ CS:invite property of the calendar collection as per Section 5.3.2.
+ The server MUST update the DAV:resourcetype property on the calendar
+ collection to ensure it does not contain a CS:shared-owner XML
+ element to indicate the calendar collection is not shared.
+
+5.3.2. Manipulating Sharees of a Shared Calendar
+
+ The sharer of a shared calendar is able to manipulate the sharee list
+ by issuing a POST request targeted at the calendar collection
+ resource. The POST request MUST contain an XML document as its body
+ with the root element being CS:share (Section 6.26).
+
+ The CS:share (Section 6.26) element in the POST requests MUST contain
+ one or more CS:set (Section 6.27) or CS:remove (Section 6.28)
+ elements. For each CS:set (Section 6.27) element, the server MUST
+ add the specified sharee access to the calendar. For each CS:remove
+ (Section 6.28) element the server MUST remove the specified sharee
+ access from the shared calendar. 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 calendar. The server SHOULD NOT send notification messages to
+ sharees whose status is unchanged.
+
+ Sharee's are identified via a DAV:href element whose value is either
+ a principal-URL for a sharee hosted on the same server, a calendar
+ user address or email address. 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 CS:invite property (Section 5.2.2).
+
+ The client MAY include a CS:common-name (Section 6.19) element in the
+ CS:set (Section 6.27) element. When provided, the value represents
+ the common name for the sharee, and is returned in the list of
+ sharees via the CS: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 CS:common-name when it is able to match the
+ sharee with a known user, and a common name for that user can be
+ determined.
+
+ When the sharee list on a shared calendar is changed, the server MUST
+ send notifications to each sharee to update them on their current
+ sharing status. This is accomplished by sending a CS:invite-
+ notification (Section 6.15) notification to each sharee.
+
+
+
+
+Daboo & York [Page 10]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+5.3.2.1. Example: Successful Sharee Add Request
+
+ This example shows how to add a single sharee (with calendar user
+ address "mailto:eric@example.com") to a shared calendar with CS:read-
+ write access.
+
+ >> Request <<
+
+ POST /calendars/users/cyrus/shared/ HTTP/1.1
+ Host: calendar.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <CS:share xmlns:D="DAV:"
+ xmlns:CS="http://calendarserver.org/ns/">
+ <CS:set>
+ <D:href>mailto:eric@example.com</D:href>
+ <CS:common-name>Eric York</CS:common-name>
+ <CS:summary>Shared workspace</CS:summary>
+ <CS:read-write />
+ </CS:set>
+ </CS:share>
+
+ >> 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 calendar user address
+ "mailto:eric@example.com" has their access downgraded to CS:read,
+ whilst another sharee is removed from the access list entirely.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & York [Page 11]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ >> Request <<
+
+ POST /calendars/users/cyrus/shared/ HTTP/1.1
+ Host: calendar.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <CS:share xmlns:D="DAV:"
+ xmlns:CS="http://calendarserver.org/ns/">
+ <CS:set>
+ <D:href>mailto:eric@example.com</D:href>
+ <CS:summary>Shared workspace</CS:summary>
+ <CS:read-write />
+ </CS:set>
+ <CS:remove>
+ <D:href>mailto:wilfredo@example.com</D:href>
+ </CS:remove>
+ </CS:share>
+
+ >> Response <<
+
+ HTTP/1.1 200 OK
+ Cache-Control: no-cache
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+
+5.4. Sharee Actions on Shared Calendars
+
+5.4.1. Replying to a Sharing Invite
+
+ When a sharee is invited to a shared calendar they can accept or
+ decline the invite by issuing a POST request to the sharee's calendar
+ home collection resource. The POST request MUST contain an XML
+ document as its body with the root element being CS:invite-reply
+ (Section 6.22).
+
+ The CS:invite-reply (Section 6.22) element in the POST request
+ specifies the sharee who is replying in the DAV:href element, the
+ accept or decline action via the CS:invite-accepted or CS:invite-
+ declined elements, the URL of the shared calendar in the CS:hosturl
+ element, the unique identifier of the invite to which it is a reply
+ in the CS:in-reply-to element, and an optional CS:summary element.
+
+ The response to a POST request that accepts a shared calendar invite
+ MUST be an XML document containing CS:shared-as (Section 6.29) as its
+ root element. That root element contains a single DAV:href element
+ whose content is the URI of the shared calendar in the sharee's
+ calendar home created by the invite acceptance.
+
+
+
+Daboo & York [Page 12]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ 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 CS:invite-reply
+ (Section 6.22) notification to the sharer.
+
+5.4.2. Removing a Shared Calendar
+
+ To remove a shared calendar from a sharee's calendar home collection
+ a DELETE request is targeted at the shared calendar URI. When such a
+ request is received the server MUST remove the shared calendar from
+ the sharee's calendar home and automatically update the sharee's
+ status in the sharer's calendar's CS:invite property.
+
+5.5. General Considerations
+
+5.5.1. Access Levels
+
+ Two levels of access ca be granted by a sharer to any sharee. These
+ are governed by the CS:access element used in the CS:invite/CS:user
+ element that specifies a shared user invite. CS:access contains a
+ single empty element that defines the type of access granted:
+
+ CS:read When present this indicates that sharees can read calendar
+ data but cannot change it.
+
+ CS:read-write When present this indicates that sharees can read and
+ write calendar data.
+
+5.5.2. Allowing or Disallowing Sharing
+
+ Servers MAY support calendar sharing on a per-calendar basis - e.g.,
+ they could treat some calendars as always private (cannot be shared)
+ or always public (always shared). As a result clients need a way to
+ determine which calendar could be shared so they can enable or
+ disable sharing options on a per-calendar basis.
+
+ This specification adds a CS:allowed-sharing-modes (Section 5.2.3)
+ WebDAV property which servers can return on calendar collection
+ resources. This property contains XML elements that describe which
+ sharing or publishing capabilities can be supported by the
+ corresponding calendar collection:
+
+ CS:can-be-shared (Section 6.3): when present indicates that the
+ calendar collection can be shared. When not present, the calendar
+ collection cannot be shared.
+
+ CS:can-be-published (Section 6.4): when present indicates that the
+ calendar collection can be published. When not present, the
+
+
+
+Daboo & York [Page 13]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ calendar collection cannot be published.
+
+ When not present on a calendar collection, sharing or publishing of
+ that calendar is not allowed. Clients SHOULD NOT attempt to use
+ requests to enable sharing or publishing targeted at those calendar
+ collections.
+
+5.5.3. Per-user WebDAV Properties
+
+ Servers MUST support "per-user" WebDAV properties on shared calendar
+ collections and MAY support them on calendar object resources within
+ shared calendar collections. A "per-user" WebDAV property is one
+ whose value can be set and retrieved independently by each user with
+ appropriate access rights. e.g., user "A" changes the DAV:displayname
+ property on a shared calendar in their calendar home to "My
+ calendar", and user "B" changes the same property to "Shared" on the
+ same shared calendar in their calendar home. When each user
+ retrieves the property value they will see their own last stored
+ value and not the value of the other user.
+
+ For shared calendars, the server MUST allow all users to write "per-
+ user" WebDAV properties on the shared calendar collection and MAY
+ allow property writes on calendar object resources within the shared
+ calendar collection. This is required even in the case where the
+ sharee has been granted read access only (i.e., the ability to change
+ calendar data is disallowed). This requirement ensures that sharees
+ can always change "personal" properties such as calendar colors and
+ display names.
+
+ Servers MUST treat the following properties as "per-user":
+
+ DAV:displayname
+
+ CALDAV:calendar-description
+
+ CALDAV:schedule-calendar-transp
+
+ ICAL:calendar-color
+
+ Servers MAY treat any dead property as per-user.
+
+ Servers MUST NOT treat live properties as per-user.
+
+5.5.4. Per-user Calendar Data
+
+ Servers MUST support "per-user" calendar data in calendar object
+ resources stored in shared calendars. This allows each sharee and
+ the sharer to store their own alarms and free busy transparency
+
+
+
+Daboo & York [Page 14]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ status without "interfering" with other users who also have access to
+ the same calendar object resources.
+
+ For calendaring object resources in shared calendar collections, the
+ server MUST treat the following iCalendar data objects as per-user:
+
+ TRANSP property
+
+ VALARM component
+
+ Servers MAY treat any non-standard X- iCalendar properties as per-
+ user.
+
+ When handling per-user data in recurring components, servers SHOULD
+ eliminate overridden instances when returning iCalendar data to
+ clients in the case where there are no differences between the
+ overridden component and the instance that could be derived from the
+ "master" recurrence component. For example, consider a daily
+ recurring event, Monday through Friday, initially defined without any
+ overridden instances, that is in a shared calendar. If user "A"
+ overrides the Tuesday instance and adds their own "VALARM" component
+ only, then when user "A" later retrieves the data again they would
+ see that overridden instance, but when user "B" does so, they would
+ not. This ensures that each user sees the most "compact"
+ representation of the calendar data.
+
+5.5.5. Scheduling
+
+ CalDAV Scheduling [RFC6638] defines how a CalDAV server carries out
+ scheduling operations when calendar object resources are created,
+ modified or deleted and include "ORGANIZER" and "ATTENDEE" iCalendar
+ properties.
+
+ When calendar object resources are created, modified or deleted in
+ shared calendars by sharees, the following restrictions apply:
+
+ 1. The "ORGANIZER" iCalendar property value in the iCalendar data
+ MUST match a calendar user address of the sharer (owner) of the
+ shared calendar. The DAV:owner WebDAV property MUST be present
+ on a shared calendar and MUST provide a reference to a principal-
+ URL of the sharer (owner) of the shared calendar. Clients can
+ use this value to determine what the allowed "ORGANIZER"
+ iCalendar property values are. The server MUST reject any
+ attempt by a sharee to create an iCalendar component with an
+ "ORGANIZER" property value other than the sharer (owner) of the
+ shared calendar.
+
+
+
+
+
+Daboo & York [Page 15]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ 2. The server MUST reject any attempt by a sharee to MOVE a calendar
+ object resource in a shared calendar to some other collection.
+
+ 3. When a sharee is listed as an Attendee in a calendar object
+ resource in a shared calendar, and write access is granted, the
+ sharee is allowed to change not only iCalendar data related to
+ the Organizer, but also data related to the Attendee. i.e., a
+ sharee can change their own participation status on the
+ "ATTENDEE" iCalendar property referring to them. Additionally,
+ if the sharee is not listed as an Attendee, and write access is
+ granted, the sharee can add themselves as an Attendee.
+
+ 4. The default calendar collection defined in Section 6.3 of
+ [RFC6638] MUST NOT be a calendar shared to the corresponding
+ calendar user.
+
+ Following are additional considerations for scheduling with shared
+ calendars:
+
+ 1. A scheduled iCalendar component could appear in more than one
+ calendar collection within a sharee's calendar home if the sharee
+ is an Attendee and the Organizer or other Attendees have shared a
+ calendar with the sharee that includes their copies of the
+ iCalendar component. It is important to note that the scheduled
+ component in the shared calendar could have different access
+ rights than the one in the sharee's owned calendar.
+
+ 2. A scheduled iCalendar component appearing in a sharee's shared
+ calendar could include the sharee as an Attendee. For recurring
+ events, it is possible for the sharee to only be listed as an
+ Attendee in some instances, as opposed to all. Clients will need
+ to be aware of this when allowing sharee's to set their own
+ participation status.
+
+ In addition, when a shared calendar is first accepted by a sharee,
+ the server SHOULD set the CALDAV:schedule-calendar-transp property to
+ the value CALDAV:transparent to ensure newly accepted shared
+ calendars do not contribute to the sharee's freebusy time until the
+ sharee explicitly requests it.
+
+
+6. XML Element Definitions
+
+6.1. CS:shared-owner
+
+
+
+
+
+
+
+Daboo & York [Page 16]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Name: shared-owner
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to indicate that a calendar is being shared by the
+ owner.
+
+ Description: This property appears in the DAV:resourcetype property
+ on the calendar collection resource shared by a sharer. See
+ Section 5.2.
+
+ Definition:
+
+ <!ELEMENT shared-owner EMPTY>
+
+6.2. CS:shared
+
+ Name: shared
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to indicate that a calendar is being shared to a
+ sharee.
+
+ Description: This property appears in the DAV:resourcetype property
+ on a calendar collection resource that is shared to a sharee and
+ appears in the sharee's calendar home collection. See
+ Section 5.2.
+
+ Definition:
+
+ <!ELEMENT shared EMPTY>
+
+6.3. CS:can-be-shared
+
+ Name: can-be-shared
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to indicate that a calendar can be shared.
+
+ Description: This element indicates that a calendar can be shared
+ with other users. See Section 5.2.3
+
+ Definition:
+
+ <!ELEMENT can-be-shared EMPTY>
+
+
+
+
+Daboo & York [Page 17]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+6.4. CS:can-be-published
+
+ Name: can-be-published
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Used to indicate that a calendar can be published.
+
+ Description: This element indicates that a calendar can be published
+ to anyone. See Section 5.2.3
+
+ Definition:
+
+ <!ELEMENT can-be-published EMPTY>
+
+6.5. CS:user
+
+ Name: user
+
+ Namespace: http://calendarserver.org/ns/
+
+ 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 (DAV:href, common-name?, (invite-noresponse |
+ invite-accepted | invite-declined | invite-invalid),
+ access, summary?)>
+
+6.6. CS:invite-noresponse
+
+ Name: invite-noresponse
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Sharing invite status.
+
+ Description: When used in a CS:user (Section 6.5) element, this
+ element is used to indicate that the sharee has never replied to
+ the corresponding sharing invite. When used in a CS:invite-
+ notification (Section 6.15) element, this element is used to
+ indicate to the sharee that a sharing reply is needed.
+
+
+
+
+
+
+Daboo & York [Page 18]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Definition:
+
+ <!ELEMENT invite-noresponse EMPTY>
+
+6.7. CS:invite-deleted
+
+ Name: invite-deleted
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Sharing invite status.
+
+ Description: When used in a CS:invite-notification (Section 6.15)
+ element, this element is used to indicate to the sharee that a
+ shared calendar has been unshared by the sharer.
+
+ Definition:
+
+ <!ELEMENT invite-deleted EMPTY>
+
+6.8. CS:invite-accepted
+
+ Name: invite-accepted
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Sharing invite status.
+
+ Description: When used in a CS:user (Section 6.5) element, this
+ element is used to indicate that the sharee has accepted the
+ corresponding sharing invite. When used in a CS:invite-
+ notification (Section 6.15) 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>
+
+6.9. CS:invite-declined
+
+ Name: invite-declined
+
+ Namespace: http://calendarserver.org/ns/
+
+
+
+
+
+
+
+Daboo & York [Page 19]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Purpose: Sharing invite status.
+
+ Description: When used in a CS:user (Section 6.5) element, this
+ element is used to indicate that the sharee has declined the
+ corresponding sharing invite. When used in a CS:invite-
+ notification (Section 6.15) 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>
+
+6.10. CS:invite-invalid
+
+ Name: invite-invalid
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Sharing invite status.
+
+ Description: When used in a CS:user (Section 6.5) element, this
+ element is used to indicate that the corresponding sharee is not a
+ valid calendar user known to the server.
+
+ Definition:
+
+ <!ELEMENT invite-invalid EMPTY>
+
+6.11. CS:access
+
+ Name: access
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Shared calendar access level.
+
+ Description: When used in a CS:user (Section 6.5) element, this
+ element is used to indicate the sharing access level granted to
+ the corresponding sharee.
+
+ Definition:
+
+ <!ELEMENT access (read | read-write)>
+
+
+
+
+
+
+
+Daboo & York [Page 20]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+6.12. CS:read
+
+ Name: read
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Shared calendar access level privilege.
+
+ Description: Indicates that the access level granted only allows
+ sharees to read data in the shared calendar (though they can write
+ per-user data (Section 5.5.4)).
+
+ Definition:
+
+ <!ELEMENT read EMPTY>
+
+6.13. CS:read-write
+
+ Name: read-write
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Shared calendar access level privilege.
+
+ Description: Indicates that the access level granted allows sharees
+ to read and write all data in the shared calendar, with the
+ exception of components that would trigger scheduling.
+
+ Definition:
+
+ <!ELEMENT read-write EMPTY>
+
+6.14. CS:summary
+
+ Name: summary
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Summary or title of shared calendar.
+
+ Description: A brief description of a shared calendar. This can be
+ used by sharers to communicate the nature of a shared calendar to
+ sharees, as well as used by sharees to indicate back to the sharer
+ how each sharee is refering to the shared calendar.
+
+
+
+
+
+
+
+Daboo & York [Page 21]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Definition:
+
+ <!ELEMENT summary (#PCDATA)>
+
+6.15. CS:invite-notification
+
+ Name: invite-notification
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: A notification used as a shared calendar invite.
+
+ Description: Defines a notification message sent automatically by
+ the server when a sharer adds, changes or removes a sharee from a
+ shared calendar. The DAV:href element specifies the calendar user
+ address of the sharee to whom the message was sent. The CALDAV:
+ supported-calendar-component-set is a copy of the matching WebDAV
+ property on the sharers calendar collection, to allow clients to
+ know what restrictions might apply to the shared calendar before
+ accepting it.
+
+ Definition:
+
+ <!ELEMENT invite-notification (
+ uid, DAV:href,
+ (invite-noresponse | invite-deleted |
+ invite-accepted | invite-declined),
+ access, hosturl, organizer,
+ summary?,
+ CALDAV:supported-calendar-component-set?>
+
+6.16. CS:uid
+
+ Name: uid
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Unique identifier.
+
+ Description: A unique identifier for an invitation to a shared
+ calendar.
+
+ Definition:
+
+ <!ELEMENT uid (#PCDATA)>
+
+
+
+
+
+
+Daboo & York [Page 22]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+6.17. CS:hosturl
+
+ Name: hosturl
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Identifies the source URL of a shared calendar.
+
+ Description: Contains a single DAV:href element that refers to the
+ source of a shared calendar - i.e., the URL of the calendar shared
+ by the sharer.
+
+ Definition:
+
+ <!ELEMENT hosturl (DAV:href)>
+
+6.18. CS:organizer
+
+ Name: organizer
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Identifies the sharer of a shared calendar.
+
+ Description: Contains a single DAV:href element that identifies the
+ calendar user address of the sharer of a shared calendar, and an
+ optional CS:common-name element that matches that user, and an
+ option CS:first-name, CS:last-name pair of elements that match
+ that user. In some cases servers might have directory information
+ that includes only the common name, or only the first or last
+ name, and it is better to expose those directly to the client
+ as-is rather than to try and split or combine the attributes to
+ synthesize one set or the other.
+
+ Definition:
+
+ <!ELEMENT organizer (DAV:href,
+ CS:common-name?,
+ (CS:first-name, CS:last-name)?)>
+
+6.19. CS:common-name
+
+ Name: common-name
+
+ Namespace: http://calendarserver.org/ns/
+
+
+
+
+
+
+Daboo & York [Page 23]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Purpose: The common name of a sharer or sharee.
+
+ Description: The common name is optionally provided by a client when
+ adding a sharee and optionally included (or modified) by the
+ server when returning results for sharers or sharees and in
+ notifications.
+
+ Definition:
+
+ <!ELEMENT common-name (#PCDATA)>
+
+6.20. CS:first-name
+
+ Name: first-name
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: The first name of a sharer or sharee.
+
+ Description: The first name is optionally included by the server
+ when returning results for sharers or sharees and in
+ notifications.
+
+ Definition:
+
+ <!ELEMENT first-name (#PCDATA)>
+
+6.21. CS:last-name
+
+ Name: last-name
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: The last name of a sharer or sharee.
+
+ Description: The last name is optionally included by the server when
+ returning results for sharers or sharees and in notifications.
+
+ Definition:
+
+ <!ELEMENT last-name (#PCDATA)>
+
+6.22. CS:invite-reply
+
+
+
+
+
+
+
+
+Daboo & York [Page 24]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Name: invite-reply
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: A notification used as a reply to a shared calendar invite.
+
+ Description: Defines a notification message sent automatically by
+ the server when a sharee replies to a shared calendar invite. The
+ DAV:href element specifies the calendar user address of the sharee
+ to whom the original invite message was sent.
+
+ Definition:
+
+ <!ELEMENT invite-reply (DAV:href,
+ (invite-accepted | invite-declined),
+ hosturl, in-reply-to, summary?>
+
+6.23. CS:in-reply-to
+
+ Name: in-reply-to
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Unique identifier.
+
+ Description: Specifies the unique identifier of the inviate message
+ that this notification message is a reply to.
+
+ Definition:
+
+ <!ELEMENT in-reply-to (#PCDATA)>
+
+6.24. CS:notification
+
+ Name: notification
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Notification message root element.
+
+ Description: The root element used in notification resources.
+
+ Definition:
+
+ <!ELEMENT notification (CS:dtstamp,
+ (invite-notification | invite-reply)>
+ <!-- Any notification type element can appear after CS:dtstamp,
+ this specification defines only the two listed above -->
+
+
+
+Daboo & York [Page 25]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+6.25. CS:dtstamp
+
+ Name: dtstamp
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Date-time stamp.
+
+ Description: Contains the date-time stamp corresponding to the
+ creation of a notification message.
+
+ Definition:
+
+ <!ELEMENT dtstamp (#PCDATA)>
+
+6.26. CS:share
+
+ Name: share
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Describes changes to sharees.
+
+ Description: The root element used in POST requests on calendars by
+ sharers to manipulate the sharee list of a shared calendar.
+
+ Definition:
+
+ <!ELEMENT share (set | remove)*>
+
+6.27. CS:set
+
+ Name: set
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Sets access for a sharee.
+
+ Description: Used to add or modify sharee access to a shared
+ calendar. The specified access to the shared calendar is given to
+ the sharee.
+
+ Definition:
+
+ <!ELEMENT set (DAV:href, common-name?, summary?,
+ (read | read-write)>
+
+
+
+
+
+Daboo & York [Page 26]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+6.28. CS:remove
+
+ Name: remove
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Removes access for a sharee.
+
+ Description: Used to remove sharee access to a shared calendar. All
+ access to the shared calendar is removed for the sharee.
+
+ Definition:
+
+ <!ELEMENT remove (DAV:href)>
+
+6.29. CS:shared-as
+
+ Name: shared-as
+
+ Namespace: http://calendarserver.org/ns/
+
+ Purpose: Identifies a shared calendar.
+
+ Description: Returned by the server for a POST request by a sharee
+ accepting a shared calendar invite. The DAV:href element
+ specifies the URI of the calendar created by the acceptance.
+
+ Definition:
+
+ <!ELEMENT shared-as (DAV:href)>
+
+
+7. Security Considerations
+
+ Per-user WebDAV properties and iCalendar data MUST only be accessible
+ by the user that created them.
+
+ Alarms set by the sharer SHOULD NOT be propagated to sharees by
+ default. Clients SHOULD NOT automatically enable triggering of
+ alarms on shared calendars that have just been accepted without
+ confirmation by the user.
+
+ TBD
+
+
+8. IANA Considerations
+
+ This document does not require any actions on the part of IANA.
+
+
+
+Daboo & York [Page 27]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+9. Acknowledgments
+
+ This specification is the result of discussions between the Apple
+ calendar server and client teams.
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+ Distributed Authoring and Versioning (WebDAV)
+ Access Control Protocol", RFC 3744, May 2004.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
+ "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+ March 2007.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+ [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
+ CalDAV", RFC 6638, June 2012.
+
+
+Appendix A. Change History
+
+ Changes in -03:
+
+ 1. Fixed access element DTD.
+
+ 2. Remove MKxxx and PROPPATCH mechanism for upgrading/downgrading
+ shared state on a calendar collection. Instead the server
+ implicitly sets the state based on whether there are any sharees
+ or not..
+
+ 3. Added CS:first-name and CS:last-name optional element to CS:
+ organizer.
+
+ 4. Added CALDAV:supported-calendar-component-set optional element to
+ CS:invite-notification.
+
+ Changes in -02:
+
+ 1. Removed read-write-shared access mode - now a server that does
+ not support shared scheduling should advertise that via a DAV
+ header
+
+
+
+Daboo & York [Page 28]
+
+ CalDAV Sharing and Publishing September 2012
+
+
+ Changes in -01:
+
+ 1. Added CS:shared-url property
+
+ 2. Clarified that notifications are only required to be sent when
+ sharee status is changed
+
+
+Authors' Addresses
+
+ 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
+
+ Email:
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & York [Page 29]
+