Scheduling Extensions to CalDAVApple Inc.1 Infinite LoopCupertinoCA95014USAcyrus@daboo.namehttp://www.apple.com/Oracle Corporation600 Blvd. de Maisonneuve WestSuite 1900MontrealQCH3A 3J2CANADAbernard.desruisseaux@oracle.comhttp://www.oracle.com/CommerceNet169 University Ave.Palo AltoCA94301USAldusseault@commerce.nethttp://commerce.net/
Applications
calschedcalschcaldavcalendarcalendaringschedulingwebdaviCaliCalendariTIPtext/calendarHTTP
This document defines extensions to the Web Distributed Authoring
and Versioning (WebDAV) protocol to specify a standard way of
exchanging and processing scheduling messages based on the iCalendar
Transport-Independent Interoperability Protocol (iTIP). This document
defines the "calendar-schedule" feature of CalDAV.
This document specifies a set of 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,
negotiation 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 iCalendar as a
media type for calendar object resource format;
MUST support iTIP .
MUST support WebDAV Class 1 & Class 2
(note that describes
clarifications to that aid interoperability);
MUST support WebDAV ACL with
the additional privilege defined in
of this document;
MUST support transport over TLS
as defined in (note that has been obsoleted by );
MUST support ETags ;
MUST support the CALDAV:schedule privilege and its sub-privileges.
MUST support the CALDAV:schedule-inbox and
CALDAV:schedule-outbox collection resource types.
MUST support the POST method with the Recipient and Originator
request headers targeted at a CALDAV:schedule-outbox
collection resource types.
A CalDAV scheduling server MAY also support the CalDAV
calendar-access feature , and
that adds the following requirements:
MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs
on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection
resource types.
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 POST 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 (or simply
finding a suitable time for all attendees to come together for the
meeting), 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 POST 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 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.
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,
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.
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 set on the scheduling
Inbox collection to control who is allowed to send scheduling
messages to the calendar user associated with 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
calendar user associated with the scheduling Outbox, or responses to requests received
by the calendar user associated with 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 POST method at a scheduling Outbox,
the server MAY create a copy of the scheduling message in that
scheduling Outbox, unless the POST 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).
A new access control privilege 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. 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 calendar user associated with 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 POST 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
12.14.1 of ).
The CALDAV:originator property MUST be defined on calendar
object resources stored in an Inbox or Outbox collection as
the result of a POST request. The value of the property
MUST be the value of the Originator request header in the
POST 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
12.14.1 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 POST 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 POST 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 POST request that caused the resource to be
created in the collection. Typically this calendar user 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 calendar user associated with the scheduling Inbox.
DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
]]>
mailto:cyrus@example.commailto:lisa@example.com
]]>
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.
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., scheduling message follows the
restriction of iTIP);
(CALDAV:originator-specified): The POST 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 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 of the
scheduling Outbox being targeted by the request;
(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.
Postconditions: None
Every POST 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 or a suitable sub-privilege granted on the targeted
scheduling Outbox collection.
Typically the Originator request header's value will correspond
to the Organizer of the calendar component and to the calendar user associated with 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 calendar user associated with a scheduling Outbox to
grant to other users the right to execute POST 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 POST request. This
MUST be done during the processing of the POST request.
Every POST request MUST include one or more Recipient request
header. 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 calendar user associated with of the scheduling Outbox being targeted by
the POST method MUST have the CALDAV:schedule privilege or a
suitable sub-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 POST 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 POST response. This specification defines a new
XML response to convey multiple recipient status.
A response to a POST 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 iCalendar 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.com2.0;SuccessDelivered to recipient
scheduling inboxmailto:cyrus@example.com2.0;SuccessDelivered 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.
>> Request <<>> Response <<mailto:bernard@example.com2.0;SuccessBEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REPLY
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T000000Z
DTEND:20040903T000000Z
UID:34222-232@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
uisseaux:mailto:bernard@example.com
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
20040902T090000Z,20040902T170000Z/20040903T000000Z
END:VFREEBUSY
END:VCALENDAR
Immediate response from recipient
mailto:cyrus@example.com2.0;SuccessBEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REPLY
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T000000Z
DTEND:20040903T000000Z
UID:34222-232@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
mailto:cyrus@example.com
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
20040902T090000Z,20040902T170000Z/20040903T000000Z
FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
END:VFREEBUSY
END:VCALENDAR
Immediate response from recipient
]]>
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. As per , 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.>> Request <<>> Response <<
Scheduling messages are delivered into a recipients 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 Inbox.
Processing a scheduling message in an Inbox collections 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 an Inbox collection, clients MUST use the WebDAV locking feature to lock the entire 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. Clients MUST NOT attempt to process scheduling messages in an Inbox without having obtained a lock first.
When a scheduling message has been processed by a client it MUST delete that message from the Inbox before removing the webDAV lock on the Inbox collection. This ensures that other clients will not in the future attempt to process the scheduling message again.
TODO: provide definitions of new iCalendar parameters RECEIVED-DTSTAMP and RECEIVED-SEQUENCE that will help with schedule processing.
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 POST 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-request privilege controls who can
initiate scheduling requests, and who will accept such requests.
The CALDAV:schedule-request 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-request
privilege controls the use of the POST method to submit a
scheduling message via a scheduling Outbox collection. When
granted to a principal, that principal is allowed to use the
POST method on the schedule Outbox with the following
restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be
REQUEST.
the METHOD property in the iCalendar component in the
request body MUST be either PUBLISH or REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-request
privilege controls whether a scheduling message can be
deposited in the scheduling Inbox collection. When granted to
a principal, that principal is allowed to use the POST
method to deposit scheduling messages with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be
REQUEST.
the METHOD property in the iCalendar component in the
request body MUST be either PUBLISH or REQUEST.
]]>
For example, the following ACE, on Bernard's scheduling Outbox,
would only grant the privilege to Bernard to send schedule request messages 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 send schedule request messages on behalf of Cyrus:http://cal.example.com/users/cyrushttp://cal.example.com/users/kim
]]>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to send a schedule request message to Bernard:http://cal.example.com/users/lisa
]]>
The CALDAV:schedule-reply privilege controls who can
respond to scheduling requests, and who will accept such responses.
The CALDAV:schedule-reply 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-reply
privilege controls the use of the POST method to submit a
scheduling message via a scheduling Outbox collection. When
granted to a principal, that principal is allowed to use the
POST method on the schedule Outbox with the following
restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be
REQUEST.
the METHOD property in the iCalendar component in the
request body MUST NOT be either PUBLISH or REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-reply
privilege controls whether a scheduling message can be
deposited in the scheduling Inbox collection. When granted to
a principal, that principal is allowed to use the POST
method to deposit scheduling messages with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be
REQUEST.
the METHOD property in the iCalendar component in the
request body MUST NOT be either PUBLISH or REQUEST.
]]>
For example, the following ACE, on Bernard's scheduling Outbox,
would only grant the privilege to Bernard to respond to schedule messages 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 respond to schedule messages on behalf of Cyrus:http://cal.example.com/users/cyrushttp://cal.example.com/users/kim
]]>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to send a scheduling reply message to Bernard:http://cal.example.com/users/lisa
]]>
The CALDAV:schedule-free-busy privilege controls who can
initiate free-busy requests, and who will accept such requests.
The CALDAV:schedule-free-busy 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-free-busy
privilege controls the use of the POST method to submit a
scheduling message via a scheduling Outbox collection. When
granted to a principal, that principal is allowed to use the
POST method on the schedule Outbox with the following
restrictions:
the iCalendar component in the request body MUST be a
VFREEBUSY component.
the METHOD property in the iCalendar component in the
request body MUST be REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-free-busy
privilege controls whether a scheduling message can be
deposited in the scheduling Inbox collection. When granted to
a principal, that principal is allowed to use the POST
method to deposit scheduling messages with the following restrictions:
the iCalendar component in the request body MUST be a
VFREEBUSY component.
the METHOD property in the iCalendar component in the
request body MUST be REQUEST.
]]>
For example, the following ACE, on Bernard's scheduling Outbox,
would only grant the privilege to Bernard to request free-busy information 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 free-busy information on behalf of Cyrus:http://cal.example.com/users/cyrushttp://cal.example.com/users/kim
]]>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to retrieve free-busy information for Bernard:http://cal.example.com/users/lisa
]]>
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. This privilege is actually an
aggregate of the CALDAV:schedule-request,
CALDAV:schedule-reply and CALDAV:schedule-free-busy
privileges.
]]>
For example, the following ACE, on Bernard's scheduling Outbox,
would only grant the privilege to Bernard to carry out any schedule operation 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 carry out any schedule operation on behalf of Cyrus:http://cal.example.com/users/cyrushttp://cal.example.com/users/kim
]]>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to carry out any schedule operation with 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.
The CALDAV:schedule-request, CALDAV:schedule-reply and
CALDAV:schedule-free-busy privileges MUST be non-abstract, and
MUST be aggregated under the CALDAV:schedule privilege. These
privileges 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-seturn:ietf:params:xml:ns:caldavIdentify 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
POST 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.commailto: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 DesruisseauxHTTP/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
When the calendar-access feature is supported in addition to
calendar-schedule, 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 when the calendar-access
feature is also present.
schedule-responseurn:ietf:params:xml:ns:caldavContains the set of responses for a POST
method request.
See .
]]>
responseurn:ietf:params:xml:ns:caldavContains a single response for a POST
method request.
See .
]]>recipienturn:ietf:params:xml:ns:caldavThe calendar user address (recipient header
value) that the enclosing response for a
POST method request is for.
See .
]]>
request-statusurn:ietf:params:xml:ns:caldavThe 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 POST 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 or a suitable sub-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 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).
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:
Mike Douglass, Julian F. Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim Whitehead.
The authors would also like to thank the Calendaring and
Scheduling Consortium for advice with this specification,
and for organizing interoperability testing events to help
refine it.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@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.
The TLS Protocol Version 1.0Certicomtdierks@certicom.comCerticomcallen@certicom.comThis document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.Uniform Resource Identifiers (URI): Generic SyntaxWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.orgDepartment of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduXerox PARC3333 Coyote Hill RoadPalo AltoCA94034+1(415)812-4333masinter@parc.xerox.com
Applications
uniform resourceURI
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.
Internet Calendaring and Scheduling Core Object Specification (iCalendar)Lotus Development Corporation6544 Battleford DriveRaleighNC27613-3502USA+1-919-676-9515+1-919-676-9564Frank_Dawson@Lotus.comhttp://home.earthlink.net/~fdawsonMicrosoft CorporationOne Microsoft WayRedmondWA98052-6399USA+1-425-936-5522+1-425-936-7329deriks@Microsoft.com
Applications
calendaringschedulingPIM
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.
iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal EntriesMicrosoft CorporationOne Microsoft WayRedmondWA98052-6399USA+1-425-936-9277+1-425-936-8019stevesil@Microsoft.comNetscape Communications Corporation501 East Middlefield RoadMountainViewCA94043USA+1-650-937-2378+1-650-937-2103sman@netscape.comLotus Development Corporation6544 Battleford DriveRaleighNC27613-3502USA+1-919-676-9515+1-919-676-9564Frank_Dawson@Lotus.comhttp://home.earthlink.net/~fdawsonOn Technology, Inc.434 Fayetteville St.Mall, Two Hannover SquareSuite 1600RaleighNC27601+1-919-890-4036+1-919-890-4100rhopson@on.com
Applications
calendaringscheduling
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.
iCalendar Message-Based Interoperability Protocol (iMIP)Lotus Development Corporation6544 BattlefordDriveRaleighNC27613-3502USA+1-919-676-9515+1-919-676-9564fdawson@earthlink.nethttp://home.earthlink.net/~fdawsonNetscape Communications Corporation501 East Middlefield RoadMountainViewCA94043USA+1-650-937-2378+1-650-937-2103sman@netscape.comMicrosoft CorporationOne Microsoft WayRedmondWA98052-6399USA+1-425-936-9277+1-425-936-8019stevesil@Microsoft.com
Applications
calendaringiMIP
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.
HTTP Extensions for Distributed Authoring -- WEBDAVMicrosoft CorporationOne Microsoft WayRedmondWA98052-6399yarong@microsoft.comDept. Of Information and Computer Science,
University of California, IrvineIrvineCA92697-3425ejw@ics.uci.eduNetscape685 East Middlefield RoadMountain ViewCA94043asad@netscape.comNovell1555 N. Technology WayM/S ORM F111OremUT84097-2399srcarter@novell.comNovell1555 N. Technology WayM/S ORM F111OremUT84097-2399dcjensen@novell.com
This document specifies 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, namespace
manipulation, and resource locking (collision avoidance).
Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@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 .
HTTP Over TLSThis 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. Web Distributed Authoring and Versioning (WebDAV) Access Control ProtocolIBM20 Maguire RoadLexingtonMA02421geoffrey.clemm@us.ibm.comgreenbytes GmbHSalzmannstrasse 152MuensterNW48159Germanyjulian.reschke@greenbytes.deOracle Corporation500 Oracle ParkwayRedwood ShoresCA94065eric.sedlar@oracle.comU.C. Santa Cruz, Dept. of Computer Science1156 High StreetSanta CruzCA95064ejw@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.
The Transport Layer Security (TLS) Protocol Version 1.1This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]Extensible Markup Language (XML) 1.0 (Fourth Edition)Calendaring Extensions to WebDAV (CalDAV)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.HTTP Extensions for Distributed Authoring - WebDAVWebDAV 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.
Added free-busy example.
Better abstract.
Requiring DAV level 2 for locking of Inbox.
Do not require servers to actually save Outbox requests.
Removed CALDAV:schedule-state Property. Clients now must
remove inbox items after processing them, using locking etc
to prevent race conditions.
Switched back to 2518 reference from 2518bis.
Updated to more recent XML reference.
Revised required features section to better match caldav-access.
Split schedule privilege into three sub-privileges.
Made support for caldav-access optional.
Changed SCHEDULE method to POST.
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.