CalDAV Scheduling Extensions to WebDAV

Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [W3C.REC-xml-20060816].¶

The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML elements defined in this specification, or in other Standards Track IETF RFCs written to extend CalDAV. It MUST NOT be used for proprietary extensions.¶

Note that the XML declarations used in this document are incomplete, in that they do not include namespace information. Thus, the reader MUST NOT use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element types. Some of the declarations refer to XML elements defined by WebDAV which use the "DAV:" namespace. Wherever such elements appear, they are explicitly given the "DAV:" prefix to help avoid confusion. Additionally, some of the elements used here are defined in CalDAV [RFC4791].¶

Also note that some CalDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care MUST be taken not to confuse the two sets of names.¶

The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], those rules apply to this document as well.¶

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 types respectively.¶

Scheduling message:

A message that describes a transaction such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel calendar components.

Free busy message:

A message that describes a transaction such as publish unsolicited busy time information, request busy time information, or respond to a busy time request.

Outgoing Scheduling message:

A scheduling message that uses an scheduling method set to one of PUBLISH, REQUEST, ADD, CANCEL or DECLINE-COUNTER.

Incoming Scheduling message:

A scheduling message that uses an scheduling method set to one of REPLY, REFRESH or COUNTER.

Calendar User Agent (CUA)

Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information.

>> Request <<

OPTIONS /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
        

>> Response <<

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
Content-Length: 0
        

In this example, the OPTIONS response indicates that the server supports both the calendar-access and calendar-schedule features and that /lisa/calendar/outbox/ can be specified as a Request-URI to the POST method.¶

This specification introduces two new collection resource types that are used for managing incoming and outgoing scheduling messages separate from other calendar object resources.¶

A calendar user may have multiple calendars representing different spheres of activity, but scheduling requests are targeted at calendar user addresses, and there is no formal way to have those indicate which sphere of activity they might apply to. By storing all incoming scheduling requests in a separate collection, clients can process the requests in that collection and choose what calendar the request belongs to and make its own arrangements to place the relevant calendar object in that calendar to "book" it.¶

The scheduling "Outbox" collection is used for sending scheduling messages via a POST request targeted at the collection and containing the scheduling message in the body of the request. Servers MAY save scheduling messages targeted at the scheduling Outbox collection as resources in the collection, and these can then be used to track the history of scheduling messages.¶

The scheduling "Inbox" collection is used to receive scheduling messages, which are stored as calendar object resources in the collection. The server deposits scheduling messages into the scheduling Inbox collection as the result of a scheduling request that targets the calendar user associated with the scheduling Inbox collection. Scheduling messages could be delivered as the result of a POST request targeted at a scheduling Outbox collection (as described above) or as the result of some external process (not defined here).¶

New WebDAV ACL [RFC3744] privileges on each of these new collections can be used to separately control who is able to send scheduling messages on behalf of a user (when applied to a scheduling Outbox collection), or who a user will accept scheduling messages from (when applied to an scheduling Inbox collection).¶

Note that calendar object resources stored in the new scheduling collections MUST obey the restrictions for (iTIP) [RFC2446] calendar objects. The restrictions for calendar object resources stored in regular calendar collections defined in calendar-access do not apply, irrespective of whether the calendar-access feature is available or not.¶

The iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC2446] outlines a model for scheduling and free-busy message exchanges to perform scheduling transactions. This specification makes use of scheduling messages to handle scheduling transactions on the server by having such messages passed between different users on the server depending on their role in the scheduling process.¶

To that end each scheduling message is modeled as a calendar object resource which contains the iCalendar object that conforms to the iTIP requirements for the type of transaction being requested.¶

This specification defines the POST method, acting on an Organizer's scheduling Outbox collection, to trigger schedule processing by the server. This can take one of two forms: for free-busy messages the POST request returns immediately with free busy results; for scheduling messages, a copy of the scheduling message specified in the request body is deposited into each recipient's scheduling Inbox collection.¶

The server may support delivery of scheduling messages to other CalDAV servers if the client specifies a remote calendar user address for any recipient, but the server is not bound to support or complete remote delivery operations even if it advertises support for the "calendar-schedule" feature. Note that remote delivery mechanisms are not defined in this specification. This specification does not define a server-to-server or server-to-client protocol to deliver remote scheduling messages. Implementations may do this in a proprietary way, with iMIP [RFC2447], or with iTIP bindings as yet unspecified.¶

After the delivery is completed, CalDAV clients will see the scheduling message the next time they synchronize or query a scheduling Inbox collection. To reply to a scheduling REQUEST, the client uses the POST method to send another scheduling message (this time a REPLY) back to the Organizer. If the user has decided to accept the REQUEST, the client can create a suitable calendar object resource in the appropriate calendar collection for the recipient. The step of putting the calendar object resource in the calendar is left up to the client, so that the client can make appropriate choices about where to put the calendar object resource, and with what alarms, etc. However, the server MAY be configured to automatically accept or reject invitations, and if the server auto-accepts invitations then the server is responsible for creating calendar object resources in a calendar collection specified by the user, or via some other configuration option.¶

A scheduling Outbox collection is used as the target for initiating the processing of outgoing scheduling messages. These may be requests initiated by or on behalf of the calendar user associated with the scheduling Outbox collection, or responses to requests received by the calendar user associated with the scheduling Outbox collection.¶

A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV:resourcetype property. The element type declaration for CALDAV:schedule-outbox is: ¶

   <!ELEMENT schedule-outbox EMPTY>
          

Example: ¶

   <resourcetype xmlns="DAV:">
     <collection/>
     <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
   </resourcetype>
          

Every non-collection resource in the scheduling Outbox collection MUST be a valid calendar object resource that defines a scheduling message (i.e. an iCalendar object that follows the iTIP semantic). When a client targets the POST method at a scheduling Outbox collection, the server MAY create a copy of the scheduling message in that scheduling Outbox collection, unless the request contains a free-busy message, in which case the server MUST NOT store a copy of the free-busy message. Copies that are created serve as a record of outgoing scheduling messages.¶

The server MAY auto-delete calendar object resources in the scheduling Outbox collection (e.g., after a period of time or to keep within a quota).¶

New access control privileges can be used on the scheduling Outbox collection to control who is allowed to send scheduling messages on behalf of the calendar user associated with the scheduling Outbox collection. See Section 9.1 for more details.¶

When the server also supports the calendar-access feature, a scheduling Outbox collection MUST not be a child (at any depth) of a calendar collection resource.¶

A scheduling Inbox collection contains incoming scheduling messages. These may be requests sent by an Organizer, or replies sent by an Attendee in response to a request.¶

A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV:resourcetype property. The element type declaration for CALDAV:schedule-inbox is: ¶

   <!ELEMENT schedule-inbox EMPTY>
          

Example: ¶

   <resourcetype xmlns="DAV:">
     <collection/>
     <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
   </resourcetype>
          

Every non-collection resource in the scheduling Inbox collection MUST be a valid calendar object resource that defines a scheduling message (i.e. an iCalendar object that follows the iTIP semantic). Note, that unlike calendar collections defined by the calendar-access feature, there are no restrictions on the nature of the resources stored (e.g., there is no need to verify that the UIDs of each resource are unique) beyond the restrictions of iTIP itself. The removal of the UID restriction, in particular, is needed because multiple scheduling messages may be sent for one particular calendar component, and each of those will have the same UID property in the calendar object resource.¶

New access control privileges can be set on the scheduling Inbox collection to control who is allowed to send scheduling messages to the calendar user associated with the scheduling Inbox collection. See Section 9.1 for more details.¶

When the server also supports the calendar-access feature, a scheduling Inbox collection MUST not be a child (at any depth) of a calendar collection resource.¶

This section describes new WebDAV properties on scheduling Inbox collection resources.¶

This section describes new WebDAV properties for calendar object resources stored in scheduling Inbox or Outbox collections.¶

The POST method submits a scheduling or free-busy message to one or more recipients by targeting the request at the URI of a scheduling Outbox collection. The request body of a POST method MUST contain a scheduling message or free-busy message (e.g., an iCalendar object that follows the iTIP semantic). The resource identified by the Request-URI MUST be a resource collection of type CALDAV:schedule-outbox (Section 5.1).¶

A submitted scheduling message will be delivered to the calendar user addresses specified in the Recipient request header. A submitted free-busy message will be immediately executed and a free-busy response returned.¶

Preconditions: ¶

• (CALDAV:supported-collection): The Request-URI MUST identify the location of a scheduling Outbox collection;
• (CALDAV:supported-calendar-data): The resource submitted in the POST request MUST be a supported media type (i.e. text/calendar) for scheduling or free-busy messages;
• (CALDAV:valid-calendar-data): The resource submitted in the POST request MUST be valid data for the media type being specified (i.e. valid iCalendar object);
• (CALDAV:valid-scheduling-message): The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., the scheduling message follows the restrictions of iTIP);
• (CALDAV:originator-specified): The POST request MUST include a valid Originator request header specifying a single calendar user address of the currently authenticated user;
• (CALDAV:originator-allowed): The calendar user identified by the Originator request header in the POST request MUST be granted the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox collection being targeted by the request;
• (CALDAV:organizer-allowed): The calendar user identified by the ORGANIZER property in the POST request's scheduling message MUST be the calendar user (or one of the calendar users) associated with the scheduling Outbox collection being targeted by the request when the scheduling message is an outgoing scheduling message;
• (CALDAV:recipient-specified): The POST request MUST include one or more valid Recipient request headers specifying the calendar user address of users to whom the scheduling message will be delivered.
• (CALDAV:originator-reply): The calendar user identified by the Originator request header in the POST request MUST have previously received the scheduling message that is being replied to when the scheduling message is an incoming scheduling message;
• (CALDAV:max-resource-size): The resource submitted in the POST request MUST have an octet size less than or equal to the value of the CALDAV:max-resource-size property value [RFC4791] on the scheduling Outbox collection targeted by the request;
• (CALDAV:attachments-allowed): The resource submitted in the POST request MUST NOT contain any inline ATTACH properties;

Postconditions: None¶

Incoming scheduling messages will be stored in a scheduling Inbox collection. As per Section 10, CalDAV calendar-access reports work on scheduling collections, so the client can use those to get partial information on scheduling messages in the scheduling inbox.¶

Scheduling messages are delivered into a recipient's scheduling Inbox collection. To process these messages a calendar user agent client needs to follow a sequence of steps to ensure good interoperability with other clients that may also be monitoring or processing the scheduling Inbox collection.¶

Processing a scheduling message in a scheduling Inbox collection requires the client to read the message, determine the nature of the scheduling operation, make appropriate adjustments to the recipients actual calendars, and then, if required, send a response.¶

In order to ensure that only one client at a time is processing scheduling messages in a scheduling Inbox collection, clients SHOULD use the WebDAV locking feature to lock the entire scheduling Inbox collection for the duration of its processing step. Once a collection is locked, other clients attempting to obtain their own lock will fail as the WebDAV server will return a protocol error at that point.¶

When a scheduling message has been processed by a client it MUST delete that message from the scheduling Inbox collection before removing the WebDAV lock on the scheduling Inbox collection. This ensures that other clients will not in the future attempt to process the scheduling message again.¶

Appendix B describes some sample workflows of scheduling message processing.¶

Parameter Name:

RECEIVED-SEQUENCE

Purpose:

To specify the value of the SEQUENCE iCalendar property that was specified in the most recent scheduling message received by the Organizer.

Format Definition:

This iCalendar property parameter is defined by the following notation:

     received-sequenceparam = "RECEIVED-SEQUENCE" "=" integer

Description:

This iCalendar parameter can be specified on the ATTENDEE iCalendar property to specify the value of the SEQUENCE iCalendar property that was specified in the most recent scheduling message received from the corresponding Attendee.

Example:

The following is an example of this parameter on the ATTENDEE property:

     ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2;
      RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com

Parameter Name:

RECEIVED-DTSTAMP

Purpose:

To specify the value of the DTSTAMP iCalendar property that was specified in the most recent scheduling message received by the Organizer or an Attendee.

Format Definition:

This iCalendar property parameter is defined by the following notation:

     received-dtstampparam = "RECEIVED-DTSTAMP" "=" date-time

Description:

This iCalendar parameter can be specified on the ATTENDEE and ORGANIZER iCalendar properties. When specified on the ATTENDEE iCalendar property this parameter specifies the value of the DTSTAMP iCalendar property that was specified in the most recent reply scheduling message received from the corresponding Attendee. When specified on the ORGANIZER iCalendar property this parameter specifies the value of the DTSTAMP iCalendar property that was specified in the most recent scheduling message received from the Organizer. This parameter MUST be specified as a DATE-TIME value in UTC.

Example:

The following are examples of this parameter on the ATTENDEE and ORGANIZER iCalendar properties:

     ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2;
      RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com

     ORGANIZER;CN="Bernard Desruisseaux";RECEIVED-DTSTAMP=20070214T11
      4523Z:mailto:bernard@example.com

The Originator request header value is a URI which specifies the calendar user address of the originator of the scheduling message. Note that the absoluteURI production is defined in RFC3986 [RFC3986].¶

The Recipient request header value is a URI which specifies the calendar user address of the recipients to which the POST method should deliver the submitted scheduling message. Note that the absoluteURI production is defined in RFC3986 [RFC3986] ¶

Server implementations that advertise support for the "calendar-schedule" feature of CalDAV MUST support WebDAV ACL [RFC3744] as well as the scheduling privileges defined in this section.¶

The tables specified in Appendix A clarifies which scheduling methods (e.g., REQUEST, REPLY, etc.) are controlled by each scheduling privilege defined in this section.¶

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

Name:

schedule-response

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

Contains the set of responses for a POST method request.

Description:

See Section 6.1.4.

Definition:

    <!ELEMENT schedule-response (response*)>

Name:

response

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

Contains a single response for a POST method request.

Description:

See Section 6.1.4.

Definition:

<!ELEMENT response (recipient,
                    request-status,
                    calendar-data?,
                    DAV:error?,
                    DAV:responsedescription?)>

Name:

recipient

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

The calendar user address (recipient header value) that the enclosing response for a POST method request is for.

Description:

See Section 6.1.4.

Definition:

                
    <!ELEMENT recipient (DAV:href)>
            
              

Name:

request-status

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

The iTIP REQUEST-STATUS property value for this response.

Description:

See Section 6.1.4.

Definition:

                
    <!ELEMENT request-status (#PCDATA)>
            
              

• Servers MUST verify that the principal associated with the calendar user address specified in the Originator request header in the request matches the currently authenticated user.
• Servers MUST verify that the currently authenticated user has the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox collection targeted by the request.
• Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request contains a CALDAV:schedule-outbox-URL property value that matches the scheduling Outbox collection targeted by the request.
• Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request has the CALDAV:schedule privilege or a suitable sub-privilege on all of the scheduling Inbox collections for the principals associated with all of the calendar user addresses specified in any Recipient request headers in the request.
• The CALDAV:calendar-free-busy-set property on principal resources SHOULD only be accessible when that principal is authenticated (i.e., the property SHOULD be hidden from other principals).

Header field name: Originator¶

Applicable protocol: http¶

Status: standard¶

Author/Change controller: IETF¶

Specification document(s): this specification¶

Related information: none¶

Header field name: Recipient¶

Applicable protocol: http¶

Status: standard¶

Author/Change controller: IETF¶

Specification document(s): this specification¶

Related information: none¶

15.1. Normative References

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2246]

Dierks, T. and C. Allen, “The TLS Protocol Version 1.0”, RFC 2246, January 1999.

[RFC2445]

Dawson, F., Stenerson, D., “Internet Calendaring and Scheduling Core Object Specification (iCalendar)”, RFC 2445, November 1998.

[RFC2446]

Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, “iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries”, RFC 2446, November 1998.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

[RFC2818]

Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.

[RFC3744]

Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, “Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol”, RFC 3744, May 2004.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.

[RFC4346]

Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, April 2006.

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

[W3C.REC-xml-20060816]

Maler, E., Paoli, J., Yergeau, F., Sperberg-McQueen, C., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition)”, World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.

15.2. Informative References

[RFC2447]

Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP)”, RFC 2447, November 1998.

[RFC3864]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

The following tables specify which scheduling privileges can grant the right to a user to have a scheduling message of a specific calendar component type with a specific scheduling method be delivered in the scheduling Inbox of another user.¶

The following tables specify which scheduling privileges can grant the right to a user to submit, with the POST request method, a scheduling message of a specific calendar component type with a specific scheduling method on a scheduling Outbox collection.¶

1. Bernard creates a new event with Lisa, Cyrus and himself as attendees and decides to send Lisa and Cyrus an invitation to this event.
2. Bernard's CUA creates a new event in a calendar collection and submits a scheduling request message through Bernard's scheduling Outbox collection to cause the server to deliver the event invitation to Lisa and Cyrus.
3. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

1. Cyrus' CUA polls his scheduling Inbox collection for new scheduling messages. When the new scheduling request message from Bernard is found, the CUA alerts Cyrus.
2. When Cyrus is ready to process the new scheduling request message, Cyrus' CUA locks the scheduling Inbox collection and retrieves the new scheduling request message. The CUA then searches Cyrus' calendar collections to find an event with the same UID property value as the one specified in the scheduling request message. Here, no event is found since the scheduling request message is for a new event.
3. Cyrus is presented with the new scheduling request message and decides to accept the event invitation and to reply to Bernard.
4. Cyrus' CUA creates a new event in a calendar collection for the event invitation that was received. The created event specifies Cyrus' updated PARTSTAT parameter on his ATTENDEE property, as well as the RECEIVED-DTSTAMP parameter on the ORGANIZER property.
5. Cyrus' CUA submits a scheduling reply message through Cyrus' scheduling Outbox collection to cause the server to deliver the reply to Bernard.
6. Cyrus' CUA deletes the scheduling request message contained in Cyrus' scheduling Inbox collection and unlocks the collection.

1. Bernard's CUA polls his scheduling Inbox collection to retrieve the list of scheduling messages currently contained in the collection. When the new scheduling reply message is found, Bernard's CUA locks the scheduling Inbox collection and retrieves the new scheduling reply message. The CUA will then search Bernard's calendar collections to find an event with the same UID property value as the one specified in the scheduling reply message. The original event created by Bernard will be found.
2. Bernard's CUA updates the PARTSTAT, RECEIVED-DTSTAMP, and RECEIVED-SEQUENCE parameters of Cyrus' ATTENDEE property in the original event that was found.
3. Bernard's CUA deletes the scheduling reply message contained in the Bernard's scheduling Inbox collection and unlocks the collection.

1. Bernard reschedules the event with Lisa and Cyrus and decides to send an updated event invitation to Lisa and Cyrus.
2. Bernard's CUA updates the event in the calendar collection and submits a new scheduling request message through Bernard's scheduling Outbox collection to cause the server to deliver the event invitation to Lisa and Cyrus.
3. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

1. Lisa's CUA polls her scheduling Inbox collection for new scheduling messages.
2. When the new scheduling request message from Bernard is found, Lisa's CUA locks the scheduling Inbox collection and retrieves the new scheduling request message. The CUA will then search Lisa's calendar collections to find an event with the same UID property value as the one specified in the scheduling request message. The event previously created in Lisa's calendar collection will be found.
3. Lisa's CUA automatically updates the event with the new information provided in the new scheduling request message and also updates the PARTSTAT parameter of Lisa's ATTENDEE property to NEEDS-ACTION, as well as the value of the RECEIVED-DTSTAMP parameter on the ORGANIZER property to match the value of the DTSTAMP property specified in the received scheduling request message.
4. Lisa's CUA deletes the scheduling request messages contained in Lisa's scheduling Inbox collection and unlocks the collection.
5. At some later point, Lisa decides to accept the updated event. Lisa's CUA updates the PARTSTAT parameter on her ATTENDEE property for the event stored in her calendar collection.
6. Lisa's CUA submits a scheduling reply message through Lisa's scheduling Outbox collection to cause the server to deliver the reply to Bernard.

1. Updated to rfc3986 reference.
2. Added Appendix with example workflow.
3. Change calendar-home-URL to calendar-home-set.
4. Updated to RFC 4791 reference.
5. Updated to RFC 4918 reference.
6. Changed title.
7. Added text to explain that VTODO and VJOURNAL are also valid scheduling components in CalDAV.
8. Changed order of Inbox and Outbox definition in section 5.
9. Added CALDAV:valid-free-busy-set pre-condition.
10. Re-worked descriptions of originator, recipient request headers to distinguish between iTIP outgoing and incoming modes.
11. Removed 502 status code description for POST.
12. Modified 507 status code description for POST to apply to Outbox storage only.
13. Added example of task assignment.
14. Use application/xml instead of text/xml.
15. Inbox and Outbox cannot be contained within a calendar collection.
16. Added an appendix summarizing scheduling privileges.
17. Added registration for the new HTTP headers.
18. Redefined the set of scheduling privileges.
19. Minor terminology/formatting tweaks.

1. Added free-busy example.
2. Better abstract.
3. Requiring DAV level 2 for locking of Inbox.
4. Do not require servers to actually save Outbox requests.
5. Removed CALDAV:schedule-state Property. Clients now must remove inbox items after processing them, using locking etc to prevent race conditions.
6. Switched back to 2518 reference from 2518bis.
7. Updated to more recent XML reference.
8. Revised required features section to better match caldav-access.

1. Split schedule privilege into three sub-privileges.
2. Made support for caldav-access optional.
3. Changed SCHEDULE method to POST.

1. Updated to latest references including 2518bis.
2. Added principal property CALDAV:calendar-user-address-set.
3. Major changes to schedule method, including addition of preconditions.
4. New principal properties added.
5. Text related to alternative ways of doing scheduling (some speculative) removed.
6. Added Security Considerations text.
7. Added IANA consideration text.