cyrus@daboo.name

Oracle Corporation

600 blvd. de Maisonneuve West Suite 1900 Montreal QC H3A 3J2 CA bernard.desruisseaux@oracle.com http://www.oracle.com/

Open Source Application Foundation

2064 Edgewood Dr. Palo Alto CA 94303 US lisa@osafoundation.org http://www.osafoundation.org/

Applications calsched calsch caldav calendar calendaring scheduling webdav iCal iCalendar text/calendar HTTP This document specifies a set of methods, headers and resource types that define the scheduling extension to the CalDAV protocol. CalDAV itself extends WebDAV, which extends HTTP. The new protocol elements defined here allow interoperable scheduling operations on a CalDAV repository.

This document specifies a set of methods, headers, properties and privileges that define the CalDAV scheduling extensions to the WebDAV protocol. This document also provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol iTIP over WebDAV which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components, as well as search for available busy time information. Discussion of this Internet-Draft is taking place on the mailing list <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

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 . 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. 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 . Because this augmented BNF uses the basic production rules provided in Section 2.2 of , 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 . 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.

A message that describes a transaction such as publish, schedule, reschedule, respond to scheduling requests, negociation of changes or cancel calendar components. A message that describes a transaction such as publish unsolicited busy time information, request busy time information, or respond to a busy time request.

This section lists what functionality is required of a CalDAV scheduling server. To advertise support for this specification a server: MUST support the CalDAV calendar-access feature . MUST support the CALDAV:schedule privilege. MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox collection resource types. MUST support the SCHEDULE method and the Recipient and Originator request headers. MUST support iTIP .

If the server supports the calendar scheduling features described in this document it MUST include "calendar-schedule" as a field in the DAV response header from an OPTIONS request on any resource that supports any scheduling properties, privileges or methods.

>> Request <<

>> Response <<

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

The process of scheduling a meeting between different parties often involves a series of steps with different "actors" playing particular roles during the whole process. Typically there is a meeting "Organizer" whose role is to setup a meeting between one or more meeting "Attendees", and this is done by sending out invitations and handling responses from each Attendee. This process can typically be broken down into two phases. In the first phase the "Organizer" tries to determine a time for the meeting that ought to be the most acceptable to each Attendee. This involves finding out when each Attendee is available during the period of time in which the meeting needs to occur, and determining when the most appropriate time is for which each Attendee is free. This process is called a "free-busy" lookup. In the second phase the "Organizer" sends out invitations to each Attendee using the time determined from the free-busy lookup - or a suitable guess as to an appropriate time based on other factors if free-busy lookup is not feasible. There then follows a process of negotiation between "Organizer" and "Attendees" regarding the invitation. Some Attendees may choose to attend at the original time provided by the Organizer, others may decline to attend at that time, but suggest another time, others may decline to attend at any time. The "Organizer" needs to process each of the replies from the Attendees and take appropriate action to confirm the meeting, reschedule it or perhaps cancel it depending on those replies. The user "expectation" as to how a calendaring and scheduling system should respond in each of these two phases is somewhat different. In the case of a free-busy lookup, users expect to get back results immediately so that they can then move on to the invitation phase as quickly as possible. In the case of invitations, its expected that each Attendee will reply in his or her own time, so delays in receiving replies are anticipated. Thus calendaring and scheduling systems should treat these two operational phases in different ways to accommodate the user expectations, and this specification does that.

It is useful for each participant in a scheduling transaction to maintain their own "history" of invitations sent and received during the process and after to keep track of what was done, and to properly handle updates to invitations as they may change over time. This history is usually kept separate from the actual "booked" event, to-do, or daily journal entry, which would normally be placed in a user's calendar collection. In addition, it is useful to keep outgoing invitations separate from incoming ones for organizational purposes. Also, 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. This specification introduces two new collection resource types that are used for keeping incoming and outgoing scheduling messages separate from other calendar object resources. These can also be used to control who is able to send scheduling messages on behalf of a user, and who is allowed to send scheduling messages to other users by the use of new WebDAV ACL privileges. Note that these collections only contains scheduling messages that pertains to the scheduling of events, to-dos and daily journal entries. Scheduling messages that describes requests for available busy time information, or replies to such request, are not contained in these collections. The scheduling "Inbox" collection contains received scheduling messages. Scheduling messages are contained in calendar object resources. Each calendar object resource has a WebDAV property that indicates whether the scheduling message has already been processed or not so that multiple clients do not repeat the processing actions already done. The scheduling "Outbox" collection contains scheduling message that have been sent, which need to be tracked both to help synchronize between multiple clients and to support delegation use cases. A single user with multiple clients can use this collection to synchronize the outbound request history. Two users coordinating scheduling with one calendar (e.g., a calendar user and her assistant) can see what scheduling messages the other user has sent. The calendar owner would then typically have permission to DELETE the scheduling messages but the assistant might not.

The iCalendar Transport-independent Interoperability Protocol (iTIP) outlines a model for scheduling and free-busy message exchanges to perform scheduling transactions. This specification makes use of scheduling free-busy 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 SCHEDULE method, acting on an Organizer's scheduling Outbox, to trigger schedule processing by the server. This can take one of two forms: for free-busy messages the SCHEDULE 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. The server may support delivery of scheduling messages to other CalDAV servers, and the client may attempt to get the server to do this by specifying remote addresses for the recipients, 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 scheduling messages. Implementations may do this in a proprietary way, with iMIP, 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 SCHEDULE 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.

The CalDAV scheduling extension defines the following new resource types for use with CalDAV.

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:

]]>

Example:

]]>

Every non-collection resource in the scheduling Inbox collection MUST be a valid calendar object resource that defines a scheduling message (e.g., 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 in 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. A new access control privilege can be defined on the scheduling Inbox collection and can be used to control who is allowed to send scheduling messages to the owner of the scheduling Inbox. See for more details.

A scheduling Outbox collection contains outgoing scheduling messages. These may be requests initiated by or on behalf of the owner of the scheduling Outbox, or responses to requests received by the owner of the scheduling Outbox. 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:

]]>

Example:

]]>

Every non-collection resource in the scheduling Outbox collection MUST be a valid calendar object resource that defines a scheduling message (e.g., an iCalendar object that follows the iTIP semantic). When a client targets the SCHEDULE method at a scheduling Outbox, the server MUST create a copy of the scheduling message in that scheduling Outbox, unless the SCHEDULE method corresponds to 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 (e.g., after a period of time or to keep within a quota). The server SHOULD allow deletion of calendar object resources in the scheduling Outbox. A new access control privilege can be defined on the scheduling Outbox collection and can be used to control who is allowed to send scheduling messages on behalf of the owner of the scheduling Outbox. See for more details.

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

calendar-free-busy-set urn:ietf:params:xml:ns:caldav Identify the calendars that contribute to the free-busy information for the owner of the scheduling Inbox. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of ). Support for this property is REQUIRED. This property is required to allow a SCHEDULE request to automatically determine the free busy information for each specified Recipient for immediate return in the response. A server with a fixed set of calendars per user can make this property protected. A server that allows users to create their own calendars SHOULD allow users to change their own property value.

]]>

/calendars/bernard/work/ /calendars/bernard/home/ /public/holidays/CA/ ]]>

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

originator urn:ietf:params:xml:ns:caldav Indicates the Originator of the scheduling message contained in a scheduling Inbox or Outbox collection. This property MUST be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of ). The CALDAV:originator property MUST be defined on calendar object resources stored in an Inbox or Outbox collection as the result of a SCHEDULE request. The value of the property MUST be the value of the Originator request header in the SCHEDULE request that caused the resource to be created in the collection.

DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) ]]>

mailto:bernard@example.com ]]>

recipient urn:ietf:params:xml:ns:caldav On a calendar object resource contained in a scheduling Outbox collection, this indicates the list of Recipients to whom the scheduling message was sent. On a calendar object resource in a scheduling Inbox collection, this indicates the recipient calendar user address that caused the scheduling message to be delivered into the scheduling Inbox. This property MUST be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of ). The CALDAV:recipient property MUST be defined on calendar object resources stored in a scheduling Outbox or Inbox collection as the result of a SCHEDULE request. For calendar object resources in a scheduling Outbox, the value of the property MUST be a list of calendar user addresses formed from all the addresses in any Recipient request headers in the SCHEDULE request that caused the resource to be created in the collection. For calendar object resources in a scheduling Inbox, the value of the property MUST be the calendar user address from the Recipient request header in the SCHEDULE request that caused the resource to be created in the collection. Typically this address will be one of those listed in the CALDAV:calendar-user-address-set (see ) property for the principal that owns the scheduling Inbox. However, it could, for example, be a calendar user address of a group that includes the owner of the scheduling Inbox.

DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) ]]>

mailto:cyrus@example.com mailto:lisa@example.com ]]>

schedule-state urn:ietf:params:xml:ns:caldav Indicates the state of a scheduling message in a scheduling Inbox. This property MAY be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of ). The CALDAV:schedule-state property MUST be defined on any calendar object resource in a scheduling Inbox collection. If present, the property indicates whether the scheduling message has been processed or not. Processing might have occurred as a result of some form of automatic processing by the server or through a client action. Clients MUST ensure that they set this property value to indicate a processed state when they have processed the scheduling message. This ensures that other clients with access to the same resource don't attempt to repeat the actions required to reply. Clients MUST NOT process a scheduling message that has this property indicates the scheduling message has been processed. When the scheduling message is delivered into the scheduling Inbox the server MUST set this property value to indicate that the scheduling message has not been processed.

]]>

]]>

The SCHEDULE 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 SCHEDULE 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. 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 immediatly excecuted 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 SCHEDULE 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 SCHEDULE 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 SCHEDULE request MUST obey all restrictions specified for the SCHEDULE request (e.g., scheduling message follows the restriction of iTIP); (CALDAV:originator-specified): The SCHEDULE request MUST include a valid Originator request header specifying a calendar user address of the currently authenticated user; (CALDAV:originator-allowed): The calendar user identified by the Originator request header in the SCHEDULE request MUST be granted the CALDAV:schedule privilege on the scheduling Outbox collection being targeted by the request; (CALDAV:organizer-allowed): The calendar user identified by the ORGANIZER property in the SCHEDULE request's scheduling message MUST be the owner (or one of the owners) of the scheduling Outbox being targeted by the request; (CALDAV:recipient-specified): The SCHEDULE 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. Postconditions: None

Every SCHEDULE request MUST include an Originator request header that specifies the calendar user address of the originator of a given scheduling message. The value specified in this request header MUST be a calendar user address specified in the CALDAV:calendar-user-address-set property defined on the principal resource of the currently authenticated user. Also, the currently authenticated user MUST have the CALDAV:schedule privilege granted on the targetted scheduling Outbox collection. Typically the Originator request header's value will correspond to the Organizer of the calendar component and to the owner of the Outbox being targeted by the request. However, the Organizer may choose to allow another user to act on his behalf to send scheduling messages. To allow for this a new privilege has been defined to allow the owner of a scheduling Outbox to grant to other users the right to execute SCHEDULE requests on that Outbox. The value of the Originator request header is kept in the CALDAV:originator property on any resources saved as a result of the schedule request. This includes the copy of the scheduling message saved in the scheduling Outbox, and scheduling messages delivered to any scheduling Inbox.

iTIP requires that every scheduling message contains an ORGANIZER property identifying the calendar user address of the Organizer of the calendar object. To prevent 'spoofing' (forgeries) of scheduling messages, CalDAV servers MUST verify that the calendar user address identified by the ORGANIZER property in the scheduling message data corresponds to the principal owning the scheduling Outbox targeted by the SCHEDULE request. This MUST be done during the processing of the SCHEDULE request.

Every SCHEDULE request MUST include one or more Recipient request headers in the headers. The value of this header is a list of one or more calendar user addresses and corresponds to the set of calendar users who will be delivered the scheduling message. The owner of the scheduling Outbox being targeted by the SCHEDULE method MUST have the CALDAV:schedule privilege granted on the scheduling Inbox collection of each recipient. Typically the list of recipients would correspond to any ATTENDEE property values listed in the scheduling message data. However, there are cases when an ATTENDEE is not listed as a Recipient, or when a Recipient is not one of the ATTENDEE's. For example, if the Organizer of an event wishes to attend the event themselves, they must list themselves as one of the ATTENDEE's, as the ORGANIZER of an event does not implicitly attend. However, the Organizer does not need to receive an invitation as they know their own participation status, so there is no need to be listed as a Recipient of the scheduling message. Alternatively, a client may have determined participation status of some ATTENDEE's out-of-band and has no need to send another request via CalDAV. In some cases it is handy to be able to send information about a meeting to someone who is not an ATTENDEE. In that case, there would be a Recipient in the request without a corresponding ATTENDEE property in the scheduling message data. Note that the recipient of a CalDAV scheduling message has no knowledge of who the other recipients were - they only get to see the ATTENDEE information listed in the scheduling message data. So listing a calendar user as a Recipient and not an ATTENDEE is the equivalent of a 'Bcc' (blind-carbon-copy) operation in email.

A SCHEDULE request may deliver a scheduling message to one or more calendar users specified in the Recipient request header. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall SCHEDULE response. This specification defines a new XML response to convey multiple recipient status. A response to a SCHEDULE method that indicates status for one or more recipients MUST be a CALDAV:schedule-response XML element. This MUST contain one or more CALDAV:response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status of the request for that recipient, any error codes and an optional description. See . In the case of a free-busy request, the CALDAV:response elements can also contain CALDAV:calendar-data elements which contain free busy information (e.g., an iCalenedar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the free-busy request for that recipient succeeded.

The following are examples of response codes one would expect to be used for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a response. 200 (OK) - The command succeeded. 400 (Bad Request) - The client has provided an invalid scheduling message. 403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot submit a scheduling message to the specified Request-URI. 404 (Not Found) - The URL in the Request-URI, the Originator, or the Recipient request headers were not present. 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. 502 (Bad Gateway) - The Recipient request header contained a URL which the server considers to be in another domain, which it cannot forward scheduling messages to. 507 (Insufficient Storage) - The server did not have sufficient space to record the scheduling message in a recipient's scheduling inbox.

>> Request <<

>> Response << mailto:bernard@example.com 2.0;Success Delivered to recipient scheduling inbox mailto:cyrus@example.com 2.0;Success Delivered to recipient scheduling inbox ]]>

In this example, the client requests the server to deliver a meeting invitation (scheduling REQUEST) to the calendar users mailto:bernard@example.com and mailto:cyrus@example.com. The response indicates that delivery to the relevant scheduling Inboxes of each recipient was accomplished successfully. Note that the Originator and Organizer calendar user addresses were both set to mailto:lisa@example.com. In order to indicate that she is also attending the meeting, mailto:lisa@example.com also included an ATTENDEE property in the iCalendar data corresponding to her calendar user address, however she did not include a Recipient request header for that calendar user address since she already has here own copy of the meeting stored in a calendar collection.

TODO: In this example, the client requests the server to determine the busy information of the calendar users mailto:bernard@example.com and mailto:cyrus@example.com, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components for each of those calendar users with their busy time indicated.

Incoming scheduling messages will be stored in a scheduling Inbox collection. The same reports work on scheduling collections, so the client can use REPORT to get partial information on scheduling messages in the scheduling inbox.

>> Request <<

>> Response <<

TODO: Need to explain here how to handle incoming scheduling messages. If the client wants to accept a message, it needs to create an event and mark the calendar object resource as "processed". If the client wants to reject it, it simply changes a property. Need to define that property. Also recommend locking the Inbox resource to avoid race conditions with other clients -- or use ETags to verify.

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

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

A CalDAV server MUST support the WebDAV ACLs standard. That standard provides a framework for an extensible list of privileges on WebDAV collections and ordinary resources. A CalDAV server MUST also support the set of calendar-specific privileges defined in this section.

The CALDAV:schedule privilege can be applied to either a scheduling Outbox or Inbox. Its effect depends on the type of collection it is applied to. When used on a scheduling Outbox, the CALDAV:schedule privilege controls the use of the SCHEDULE method to submit a scheduling message via a scheduling Outbox collection. A calendar owner will generally have the CALDAV:schedule privilege granted on their own outbox and never grant that privilege to anybody else. If the privilege is granted to somebody other than the calendar owner, that person is effectively somebody who can issue invitations or replies on behalf of the calendar owner. Thus, if a server receives a SCHEDULE request where the authenticated sender does not have the CALDAV:schedule privilege granted on the Request-URI, the server MUST reject the request. When used on a scheduling Inbox, the CALDAV:schedule privilege governs whether a user may cause new calendar object resources (scheduling messages) to be created in the collection as a result of a SCHEDULE request on that user's own scheduling Outbox. It is similar to the WebDAV DAV:bind privilege but more restricted, because it only allows the user to create new resources as a side-effect of the SCHEDULE method fanout process. Thus, the CALDAV:schedule privilege determines whether an event Organizer is allowed to send an invitation to an Attendee and have it appear in that Attendee's scheduling Inbox. ]]> For example, the following ACE, on Bernard's scheduling Outbox, would only grant the privilege to Bernard to schedule on behalf of himself:

http://cal.example.com/users/bernard ]]>

Whereas, the following ACE's, on Cyrus's scheduling Outbox, would grant the privilege to Cyrus and his assistant Kim to schedule on behalf of Cyrus:

http://cal.example.com/users/cyrus http://cal.example.com/users/kim ]]>

For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to send an invitation to Bernard:

http://cal.example.com/users/lisa ]]>

The CALDAV:schedule privilege MUST be non-abstract, and MUST be aggregated under the DAV:bind privilege. The CALDAV:schedule privilege MUST appear in the DAV:supported-privilege-set property of scheduling Inbox and Outbox collections.

This section defines new properties for WebDAV principal resources as defined in RFC3744. These properties are likely to be protected but the server MAY allow them to be written by appropriate users.

schedule-inbox-URL urn:ietf:params:xml:ns:caldav Identify the URL of the scheduling Inbox collection owned by the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of ). This property is needed for a client to determine where the scheduling Inbox of the current user is located so that processing of scheduling messages can occur.

]]>

schedule-outbox-URL urn:ietf:params:xml:ns:caldav Identify the URL of the scheduling Outbox collection owned by the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of ). This property is needed for a client to determine where the scheduling Outbox of the current user is located so that sending of scheduling messages can occur.

]]>

calendar-user-address-set urn:ietf:params:xml:ns:caldav Identify the calendar addresses of the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of ). Support for this property is REQUIRED. This property SHOULD be searchable using the DAV:principal-property-search REPORT. The DAV:principal-search-property-set REPORT SHOULD identify this property as such. This property is needed to map Originator and Recipient values in a SCHEDULE request to principal resources and their associated scheduling Inbox and Outbox. In the event that a user has no well defined identifier for their calendar user address, the URI of their principal resource can be used.

]]>

mailto:bernard@example.com mailto:bernard.desruisseaux@example.com ]]>

In this example, the client requests the CALDAV:calendar-home-URL of the principal resources whose CALDAV:calendar-user-address-set property contains the substring "mailto:bernard@example.com". In addition, the client requests the DAV:displayname of each principal to also be returned for the matching principals. The response shows that only one principal resource meets the search specification, "mailto:bernard@example.com".

>> Request << mailto:bernard@example.com ]]>

>> Response << /users/bernard /home/bernard/ Bernard Desruisseaux HTTP/1.1 200 OK ]]>

In this example, the client requests the CALDAV:schedule-inbox-URL and CALDAV:schedule-outbox-URL of the currently authenticated user. TODO: principal-match report

This specification extends the CALDAV:calendar-query and CALDAV:calendar-multiget reports to return results for calendar object resources in scheduling Inbox and Outbox collections when the report directly targets such a collection. i.e. the Request-URI for a REPORT MUST be the URI of the scheduling Inbox or Outbox or of a child resource within a scheduling Inbox or Outbox collection. A report run on a regular collection that includes a scheduling Inbox or Outbox as a child resource at any depth MUST NOT examine or return any calendar object resources from within any scheduling Inbox or Outbox collections. Note that the CALDAV:free-busy-query report is NOT supported on scheduling Inbox or Outbox collections.

schedule-response urn:ietf:params:xml:ns:caldav Contains the set of responses for a SCHEDULE method request. See .

]]>

response urn:ietf:params:xml:ns:caldav Contains a single response for a SCHEDULE method request. See .

]]>

recipient urn:ietf:params:xml:ns:caldav The calendar user address (recipient header value) that the enclosing response for a SCHEDULE method request is for. See .

]]>

request-status urn:ietf:params:xml:ns:caldav The iTIP REQUEST-STATUS property value for this response. See .

]]>

The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified absolutely. Servers and clients MUST use an HTTP connection protected with TLS as defined in for all scheduling transactions.

When handling a SCHEDULE request on a scheduling Outbox: 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 on the scheduling Outbox 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 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 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).

This specification does not require any IANA actions.

The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Julian F. Reschke and Jim Whitehead.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

Xerox PARC

3333 Coyote Hill Road Palo Alto CA 94034 +1(415)812-4333 masinter@parc.xerox.com

Applications uniform resource URI A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. This paper describes a "superset" of operations that can be applied to URI. It consists of both a grammar and a description of basic functionality for URI. To understand what is a valid URI, both the grammar and the associated description have to be studied. Some of the functionality described is not applicable to all URI schemes, and some operations are only possible when certain media types are retrieved using the URI, regardless of the scheme used. Lotus Development Corporation

6544 Battleford Drive Raleigh NC 27613-3502 USA +1-919-676-9515 +1-919-676-9564 Frank_Dawson@Lotus.com http://home.earthlink.net/~fdawson

Microsoft Corporation

One Microsoft Way Redmond WA 98052-6399 USA +1-425-936-5522 +1-425-936-7329 deriks@Microsoft.com

Applications calendaring scheduling PIM There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per . However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification. This memo defines the format for specifying iCalendar object methods. An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendent Interoperability Protocol (iTIP) defined in is one such scheduling protocol. Microsoft Corporation

One Microsoft Way Redmond WA 98052-6399 USA +1-425-936-9277 +1-425-936-8019 stevesil@Microsoft.com

Netscape Communications Corporation

501 East Middlefield Road MountainView CA 94043 USA +1-650-937-2378 +1-650-937-2103 sman@netscape.com

Lotus Development Corporation

6544 Battleford Drive Raleigh NC 27613-3502 USA +1-919-676-9515 +1-919-676-9564 Frank_Dawson@Lotus.com http://home.earthlink.net/~fdawson

On Technology, Inc.

434 Fayetteville St.Mall, Two Hannover Square Suite 1600 Raleigh NC 27601 +1-919-890-4036 +1-919-890-4100 rhopson@on.com

Applications calendaring scheduling This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify interoperable methods of communications between systems that use this protocol. The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol (iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols. Lotus Development Corporation

6544 BattlefordDrive Raleigh NC 27613-3502 USA +1-919-676-9515 +1-919-676-9564 fdawson@earthlink.net http://home.earthlink.net/~fdawson

Netscape Communications Corporation

501 East Middlefield Road MountainView CA 94043 USA +1-650-937-2378 +1-650-937-2103 sman@netscape.com

Microsoft Corporation

One Microsoft Way Redmond WA 98052-6399 USA +1-425-936-9277 +1-425-936-8019 stevesil@Microsoft.com

Applications calendaring iMIP This document, [iMIP], specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model are composed using constructs from , , , , and [RFC-2049]. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 . This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. IBM

20 Maguire Road Lexington MA 02421 geoffrey.clemm@us.ibm.com

greenbytes GmbH

Salzmannstrasse 152 Muenster NW 48159 Germany julian.reschke@greenbytes.de

Oracle Corporation

500 Oracle Parkway Redwood Shores CA 94065 eric.sedlar@oracle.com

U.C. Santa Cruz, Dept. of Computer Science

1156 High Street Santa Cruz CA 95064 ejw@cse.ucsc.edu

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1999, and this specification makes minor revisions mostly due to interoperability experience. This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing.

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