Calendar Server Extensions for WebDAV (CalDAV)Open Source Application Foundation2064 Edgewood Dr.Palo AltoCA94303USlisa@osafoundation.org
Applications
I-DcalschedcalschcaldavcalendarwebdaviCalendarIn the five years since WebDAV was
standardized, at least three groups have
used WebDAV as a basis to provide Internet calendar access with a minimum of
development effort. However, each group decided independently how the
calendaring data model would map to the WebDAV data model and how to deal
with features such as recurrance and queries for free-busy times. This draft
proposes a standard data model mapping and a few extensions to WebDAV that
make WebDAV-server-based calendaring work well for clients while requiring
a minimum of new work (particularly on clients).
This draft was commissioned at the Fall 2003 Minneapolis working group
meeting of the CalSched working group. The concept of using
HTTP and WebDAV
as a basis for a calendaring server is by no means a new concept: it was
discussed in the CalSched working group as early as 1997 or 1998. Several
companies have implemented calendaring servers using HTTP PUT/GET to upload
and download iCalendar events,
and using WebDAV PROPFIND to get listings
of resources. However, those implementations do not interoperate because
there are many small and big decisions to be made in how to model calendaring
data as WebDAV resources and properties, as well as how to implement
required features that aren't already part of WebDAV. This draft is
therefore intended to propose a standard way of modeling calendar data
in WebDAV, plus some additional features to make calendaring work well.
WebDAV properties and other XML element names defined in this specification
all use the "urn:ietf:params:xml:ns:calsch" namespace. Implementors
may find occasion to define new WebDAV properties and other XML elements
in implementing this specification, but this namespace is not intended
for use in custom extensions.
WebDAV offers a number of advantages as a framework or basis for calendar
access. Most of these advantages boil down to a significant reduction in
design costs, implementation costs, interoperability test costs, deployment
costs, and the cost of mistakes. Every new standard author or implementor
finds certain small errors and the IETF spends considerable time and effort
remediating these. Some of the advantages are contingent upon the way
WebDAV is used, which is why this section exploring advantages is inseparable
from the rest of this document for the moment.
WebDAV is an extension of HTTP,
therefore its URLs are HTTP URLs. If
calendar access were an extension of WebDAV then it could also share
HTTP URLs. This can make a lot of sense because it allows very simple
calendar browsing clients to be written for devices that already have
a HTTP stack: the client merely needs to download those calendar
objects and be able to parse their formats. Since the
iCalendar formats
are well-defined and well-supported, there's a natural choice for what
resource to download for a granular calendar object. If HTTP GET can
be used to represent a calendar object, then appointment references
can be easily downloaded, synchronized and shared.
Specifying new URL formats creates additional work for implementors
of clients, servers and related applications that might see those
URLs. Although new URL formats are appropriate in many cases,
sometimes HTTP URLs may be appropriate -- particularly for an
application which extends HTTP and allows all the standard HTTP methods
to work correctly. Not only are HTTP URLs appropriate for
Calendar objects, but they also eliminate the need to specify a new
URL schema and format and implement it.
Calendar functionality is found extremely frequently on the Web. Even
calendaring systems designed primarily for access by smart clients
(smart clients are those which have application logic, as opposed to
thin clients or Web browsers) typically also have a Web interface
accessible by thin clients. Some calendaring applications are
available only via Web interfaces, for example those found on systems
such as Yahoo! Groups.
Because of the frequent use of Web interfaces, and the possibility of
supporting Web services, WebDAV is a particularly suitable framework for
calendar data. HTTP URLs to calendar objects can be used natively in these
systems. WebDAV provides property information in an XML format, easily
consumed by Web services which usually import XML data anyway. Web
interfaces can use stylesheets to transform XML data into HTML
presentation. This approach is described in
<http://www.microsoft.com/technet/prodtechnol/exchange/exchange2000/deploy/confeat/e2kowa.asp>.
The HTTP/WebDAV feature model encourages a wide range of clients, from
extremely simple to very rich. This is because servers must support a
wide range of features, but clients can pick and choose which features
to support. For example, even though a WebDAV server must support the
'lockdiscovery' property, there's no requirement for a client to request
or parse this property value if it has no need to. Generally speaking,
clients may pick and choose which methods and properties to support,
as long as the client has a reasonable response to the error conditions
which might be returned. A simple client can merely download and upload
iCalendar objects and use very little XML or advanced WebDAV functionality.
At the other end of the scale, a rich calendaring client using
WebDAV-based calendaring could choose to implement offline functionality,
free-busy searches crossing multiple servers, advanced tasks and even
some workflow, by using more of the features and possibly defining its own
dead properties. (Note: WebDAV's 'dead' properties are those which the
server allows clients to set but the server has no special behavior
regarding those properties. Other clients may query and use these
dead properties.)
WebDAV includes locking support. Locks are indispensible when multiple
authors may modify or create the same resources. Locks not only
prevent authors from accidentally overwriting each others work (as
ETags do), they also help authors coordinate that work by seeing when
to wait for another author to finish. Calendar users benefit slightly
from this functionality, more so when group calendars or shared calendars
allow booking of large groups of people or broadly-used resources such
as conference rooms or equipment.
The WebDAV ACL specification is
now a standard, and several implementations have already demonstrated
interoperability. Any shared or group calendar application benefits
from interoperable access control. Access control can help define
who can schedule a user for new appointments without having to make
email requests, who can view free/busy time, and who can see the
details of certain appointments.
WebDAV ACLs provide a flexible and extensible list of privileges,
which is both good and bad for calendaring. It's good because it
allows a calendaring-over-WebDAV standard to define additional
privileges that may not be used in normal WebDAV use cases (for
example, the privilege to view a calendar's free-busy information).
However the bad part is that a flexible and extensible list of
privileges is hard for clients to display and explain to users.
This draft attempts to minimize the difficulty by more closely
defining the list of privileges that a CalDAV server must support,
including calendaring-specific privileges.
Implementors should note that WebDAV ACLs are not designed to
limit access to specific properties. For example,
a calendaring application may wish to choose which other users can
view the start/end times of appointments, and separately choose which
users can also see the location of appointments. However, as a standard
and framework, WebDAV ACL provides a valuable base from which to work.
Furthermore, this proposal recommends that advanced access control work
for calendaring be relegated to another document, so that standard
calendaring systems can be built using existing WebDAV ACL support.
Many WebDAV client appliations, servers and APIs already exist. WebDAV
clients exist for modern Microsoft, Unix and Apple platforms.
Open source solutions are common and powerful. This can significantly
improve early interoperability and reduce development and test time.
Much security integration work has already been done for WebDAV. Today's
Web and WebDAV servers all support TLS, providing at a minimum single-hop
privacy and server authentication. HTTP Digest and Basic authentication
may provide adequate client authentication (Basic essentially uses a
clear-text password but this may be appropriate if the connection is
secured with TLS). If not, work is under way to support SASL with HTTP.
As that work nears completion, HTTP/WebDAV implementations will add
SASL support so that work will be done already for a calendaring system.
It seems the HTTP/SASL work is nearing last call
(currently draft-nystrom-http-sasl-09.txt).
Synchronization and offline functionality are useful features in
Calendaring systems. Luckily, these are already well understood for
HTTP/WebDAV technology. HTTP ETags provide a reliable way to determine
whether a document in an offline cache needs to be synchronized. At
least two WebDAV clients supporting synchronization have already been
created: sitecopy (http://www.lyra.org/sitecopy/) and Xythos WebFile
Client (http://www.xythos.com/home/xythos/wfc_features.html).
Many WebDAV working group members are discussing more work to improve
the performance of synchronization betweeen WebDAV clients and WebDAV
repositories. This ongoing work can benefit the calendaring community
at the same time, provided that the calendaring data model fits easily
in the WebDAV data model. The model proposed in this document is one
with which new WebDAV synchronization features are likley to be equally
applicable to calendaring data.
Data migration is almost the same problem as synchronization. One
use of a WebDAV tool like sitecopy is to move data to a new server. The
move is peformed by doing a new synchronization. Once the initial
synchronization is complete and verified, the data on the old system
can be removed or archived. Data portability is a convenient feature
to administrators, particularly when deploying a new system.
Calendaring systems need a mix of fixed, specific searches (such as
a "search" for the events occuring today) and general search support.
WebDAV DASL can provide the functionality for the general search support
(although not always for specific frequently used searches). The only
hitch is that DASL is not yet standardized. The WebDAV WG is currently
putting effort into completing DASL and several interoperable implementations
already exist. In the meantime, if DASL is delayed the specific fixed
searches defined in this document (using the REPORT method, see section
7), together with the ability to browse calendars and request
calendar objects with certain property values, ought to provide quite
reasonable calendar browse/search support.
Note that the property promotion proposed in this document means that
not only can iCalendar documents be searched with "contains" text searches,
but also more sophisticated value matching can be done. For example,
since 'dtstart' is promoted from a VEVENT document body to the resource's
property list, a DASL search can be constructed to find events with
'dtstart' before a specified date.
WebDAV has a clear and proven extensibility model. The major way
functionality is extended is by defining new properties. Servers can extend
functionality by creating new live properties in custom namespaces.
Clients can also extend functionality by creating new dead properties in custom
namespaces. For example, a client might wish to add a "source-device"
property in a custom namespace to record which device created the calendar
item. Dead properties are client-controlled properties, where the namespace,
name and value are entirely controlled by the client. However, the server
is required to store these properties and return them, if requested, in
PROPFIND queries for individual resources or in listings of collection
contents. Some servers support text searching on all dead properties
through the DASL extensions. Dead properties can also be used in reports.
Other proven HTTP/WebDAV extensibility mechanisms include the ability to
define and advertise special WebDAV reports, new HTTP headers, and for ultimate
flexibility, new HTTP methods.
Certain features that are required for modern enterprise-level calendar
systems are not present in HTTP or WebDAV, unsurprisingly. This section
makes clear what those missing features are. The rest of this document is
largely about how those missing features could be filled in.
One of the valuable functions a calendaring server can provide to a
client is fanning out scheduling requests. This allows clients to perform
simple operations (send a single schedule request to the server) and
have the server perform complex and possibly time consuming processing.
The server can send individual scheduling requests to different invitees.
It can choose the most appropriate scheduling request transport for
each invitee, not necessarily using the same technology for each invitee
to the same meeting. The server can then remain online to collect and
collate responses. Fanout is unlike any existing WebDAV feature. Thus,
support for fanout dictates that a Calendaring server cannot simply be
an out-of-the-box WebDAV server with no modifications. A CalDav server
must have fanout logic in addition to its basic WebDAV feature support.
This document defines how fanout works.
Recurring appointments are common in calendaring applications, and these are
the hardest events to fit into a finite resource listing model such
as WebDAV. However, WebDAV does have the functionality to perform
reports. Recurrance expansion is much like the expand-property report
defined in DeltaV. CalDAV defines a
new report type specifically for expanding recurrances.
HTTP has no way for the server to contact the client. HTTP interactions
all begin with a client request and end with a server response. The
server has no obligation to maintain an open connection to the client,
rather the server MAY sever the TCP connection after any response. Thus,
there is no way for the server to send the client alarms. Since HTTP
is not designed for this, it is recommended that a different technology
be used to solve this problem.
There are other IETF technologies much more suitable than HTTP to
provide notifications. Currently, SIP and XMPP are appropriate
technologies for servers to send notifications to subscribed clients.
The SIP SUBSCRIBE method defined in RFC3265
allows custom
event types to be declared and subscribed to, and CalDAV (or a separate
draft) could define a list of types that CalDAV servers could optionally
(or be required to) support. Similarly, XMPP allows clients to subscribe
to events other than presence state change events.
Using a separate technology for notifications has advantages. It can
be seen as an advantage to have notification support optional, at least
for client implementations - a simple CalDav client need not support
notifications at all if it doesn't use alarms, or generates its own
alarms, or stays offline most of the time. Another advantage is that
it allows CalDAV servers to be stateless, handling HTTP requests by
generating responses, plus events that can be fired off to a separate
notification engine (perhaps a separate server) and then forgotten.
Finally, a separate notification system can then deal with scaling to
handle the combinatorial problems of multiple subscribed clients (e.g.
my PDA, my laptop and my desktop)
combined with multiple event sources (e.g. my work calendar server
plus my sports team calendar server plus non-calendaring event sources).
It is likely that CalDAV servers will be required to support notification
once we have more input on which technology to use.
At the least, the server would support notification of new resources
added to collections, so that clients can subscribe to know when new
iTIP requests have been delivered or when other clients have added
new events or other calendaring objects. A CalDAV server might also
initiate notification when a reminder is needed. This could allow
simple non-calendaring clients (e.g. a cell phone) to subscribe only to
reminder event notifications without having to do any other part of
calendaring.
This section lists what functionality is required of a CalDAV server.
To advertise support for CalDAV or claim compliance, a server:
MUST support WebDAV Level 1 and 2 (all of RFC2518
including locking).MUST support WebDAV ACLs with the privilege set
defined in .MAY support WebDAV DeltaV.MUST support DASL.MUST support SSL.MUST support property promotion as described in this document.MUST support scheduling fanout as described in this document.MUST support calendaring REPORTs as described in this document.One of the features which has made WebDAV a successful protocol is its
firm data model. This makes it a useful framework for other applications
such as calendaring. In this proposal, we attempt to follow the same
pattern by developing all new features based on a well-described data model.
In this data model, every iCalendar VEVENT, VALARM, VJOURNAL, VTODO and
VFREEBUSY is stored as a regular HTTP/WebDAV resource. That means each
calendar resource may be individually locked and have individual properties.
These resources are sorted into WebDAV collections with a mostly-fixed
structure.
All resource types defined in this section, and all resources of MIME
type text/calendar appearing within these collections, have certain required
properties. These properties may be defined in this document or in a
separate document. Another TODO:
This section needs more information on what properties are REQUIRED on
each type of collection. The iTIP document has useful tables listing
properties for each method, which might apply to these collections.
A CalDav repository, or server, is a calendaring-aware engine combined
with a WebDAV repository. A WebDAV repository is a set of WebDAV
collections, containing other WebDAV resources, within a unified URL
namespace. For example, the repository "http://example.org/webdav/"
may contain WebDAV collections and resources, all of which have URLs
beginning with "http://example.org/webdav/". Note that the root URL
"http://example.org/" may not itself be a WebDAV repository (for example,
if the WebDAV support is implemented through a servlet or other Web server
extension).
A WebDAV repository may include calendar data in some areas, and
non-calendaring data in other areas. Calendar data will be indicated
through specific container relationships and resource types discussed
in the next sections.
A WebDAV repository may advertise itself as a CalDAV server if it
supports the functionality defined in this specification at any point
within the root of the repository. That might mean that calendaring
data is spread throughout the repository (e.g. in /ldusseault/calendar
as well as in /nborenstein/calendar) or only in certain sections of
the repository (e.g. /caldav/usercals/*). Calendaring features are
only required in the repository sections that are or contain calendaring
objects. So a repository confining calendar data to the /caldav/ collection
would only need to support calendaring REPORTs defined here within
that collection.
The CalDAV server or repository is the canonical location for
calendar data, state information and semantics. The CalDAV server has
significant responsibility to ensure that the data is consistent and
compliant. Clients may submit requests to change data or download
data. Clients may store the calendar offline and attempt to synchronize
when reconnected, but changes to the repository occurring in between
are not considered to be automatically disposable and clients should
consider the repository to be the first authority on state. HTTP Etags
and other tools help this work.
CalDAV defines the following new resource types for use in calendar
repositories.A WebDAV collection which contains one or more calendars is considered
a Calendar Container. It has a new resource type:
A calendar container may contain more than only Calendar resources.
However, non-Calendar resources within a Calendar-Container are not
typically intended for user display. These resources may contain
configuration or application data created by clients or offered by the
server for use by clients.
A WebDAV collection which corresponds to a single calendar or VAGENDA
is a Calendar. It has a new resource type:
The calendar collection contains sub-collections with specific kinds
of calendar objects. It also has certain properties which are required
to be present on calendards (see XML section).
Calendars MUST NOT contain other calendars. Calendars MAY exist inside
calendar-containers or inside normal WebDAV collections. Thus, a repository
may have calendars without having calendar-containers. Calendar-containers
are typically useful so that a client can automatically detect when a user
has multiple calendars, e.g. "/ldusseault/calendars/work" and
"/ldusseault/calendars/karate".
A Calendar has a specified substructure. It MUST contain one event collection
and one alarm collection. It MAY contain one todo collection and one
journal. It MUST NOT contain more than one of any of these specific
collections, although it MAY contain additional collections and
non-collection resources of types not defined here.
Each Calendar MUST have a collection containing events. All
resources within this event collection (even within its sub-collections)
are considered part of the calendar, so substructure can be used to
organize events into smaller collections without affecting the overall
content of the calendar. Clients MUST be prepared to identify and navigate
multiple event collections within a Calendar. An event collection has
its own resource type so these collections are easily identifiable.
Every non-collection resource in a calendar-events collection is considered to be an
event. Thus, listing the resources inside a calendar-events collection
is a good way to find out all the events on a calendar. Each resource
inside an events collection MUST have the default MIME type text/calendar, and
each one contains exactly one VEVENT or VFREEBUSY object.
Each Calendar MUST have a collection containing alarms. All
resources within this alarm collection (even within its sub-collections)
are considered part of the calendar. The alarm collection has
its own resource type.
Every non-collection resource in a alarms collection is considered to be an
alarm. Every resource MUST have the default MIME type text/calendar, and
contains exactly one VALARM.
Each Calendar MAY have a collection containing tasks or todos. All
resources within this todo collection (even within its sub-collections)
are considered part of the calendar. The todo collection has
its own resource type.
Every non-collection resource in a todo collection is considered to be a
todo. Every resource MUST have the default MIME type text/calendar, and
contains exactly one VTODO.
Each Calendar MAY have a collection containing journal items. All
resources within this journal collection (even within its sub-collections)
are considered part of the journal. The journal collection has
its own resource type.
Every non-collection resource in a journal is considered to be a
journal item. Every resource MUST have the default MIME type text/calendar, and
contains exactly one VJOURNAL.
Every Calendar-Container MUST have a child collection to contain invites
received through iTIP. If a Calendar is not inside a Calendar-Container,
then that Calendar MUST have its own invites collection. This collection
is to store received, accepted and archived invitations so that clients
can accept and review scheduling invitations.
Every non-collection resource in the invites collection is considered to be a
REQUEST. Every resource MUST have the default MIME type text/calendar, and
contains exactly one REQUEST.
Every Calendar MUST have a child collection to contain fanout requests and
responses for appointments scheduled by the calendar owner (or other
users of this calendar). This collection is to store REQUESTs initiated
by this calendar server for this calendar, as well as REPLY items
received in reply. This collection is only for review because the CalDAV
server is responsible for parsing incoming REPLY messages and adding
attendee information to events.
Every non-collection resource in the invites collection is considered to be a
REQUEST or REPLY. Every resource MUST have the default MIME type text/calendar, and
contains exactly one REQUEST or exactly one REPLY.
Recurrance is an important part of the data model because it governs
how many resources are expected to exist.
Consider the outcome if recurrance were handled through
the creation of many nearly-identical WebDAV resources. With this model,
it becomes hard to keep their data consistent. Even worse, some features like LOCK
become difficult -- it's hard to lock the right set of resources so that
the user can change the title of all recurrances of an appointment. With
these considerations, this proposal does not treat recurrances as separate
resources.
Instead, this proposal models recurrance patterns as properties of event
resources. This makes for much less data to synchronize, and makes it
easier to make changes to all recurrances or to a recurrance pattern. It
makes it easier to create a recurring event, and easier to delete all
recurrances.
The drawback of the recurrance-is-a-property approach is that it becomes
harder to see what events occur in a given time period. It's a very common
function for calendar views to display all events happening between midnight
yesterday and midnight tonight, or all events happening within one week.
In these views, each recurrance appears as if it were an individual
appointment. To make these views possible, this proposal defines a REPORT
specifically to view events in a time period [TODO - ref section].
Because of this choice, clients MUST NOT create separate resources to
represent a recurring event when the recurrance pattern is known. Otherwise,
it makes it more difficult for other clients to interoperate and modify
the recurring event. Most importantly, clients MUST NOT duplicate events
represented through recurrance patterns with manually created events,
which would appear as duplicates to the server and to other clients.
This is a big issue because CalDAV servers need to know the timezone
of the calendar in order to calculate recurrances in a deterministic
manner. In addition to having a calendar default timezone, individual
events (e.g. those received in a scheduling request from another place)
can have different timezones. Finally, iCalendar has a way to specify
custom timezones.
The default calendar timezone is probably simply a property value on
the calendar collection, which the calendaring client can change.
The event timezone is a piece of VEVENT metadata that would therefore
appear both inside the event in iCalendar format, and as a promoted
property on the event resource. Storing custom timezone definitions
can be through a new collection if necessary. More discussion here
is welcome.
Calendars, calendar-containers, collections of calendar objects, and
individual calendar objects may all be created by either the CalDAV client
or by the CalDAV server. For example, a server might come preconfigured
with a user's calendar collection, or the CalDAV client might create a
new calendar collection. Servers might create event requests as calendar
objects inside a VEVENT collection, or clients might create event requests.
Either way, both client and server MUST comply with the requirements in
this document, and MUST understand objects appearing in calendars or
calendar-containers according to the data model defined here.
When servers create HTTP resources, it's not hard for the server to
choose a unique URL. It's slightly tougher for clients, because a client
might not want to examine all resources in the collection, and might not
want to lock the entire collection to ensure that a new one isn't created
with a name collision. However, there are tools to mitigate this.
If the client intends to create a new non-collection resource, such as a
new VEVENT, the client SHOULD use the HTTP header "If-None-Match: *" on
the PUT request. The Request-URI on the PUT request MUST include the
target collection, where the resource is to be created, plus the name
of the resource in the last path segment. The last path segment could
be a random number, or it could be a sequence number, or a string related
to the object's 'summary' property. No matter how the name is chosen,
the "If-None-Match" header ensures that the client cannot overwrite an
existing resource even if it has accidentally chosen a duplicate resource
name.
The request to change an existing event is the same, but with a specific
ETag in the "If-Match" header, rather than the "If-None-Match" header.
For optimum interoperability with existing HTTP clients, CalDAV clients
and servers MUST use the file extension ".ics" as well as the "text/
icalendar" MIME type, whenever creating Calendar objects of that MIME
type.
Note because of these requirements that there is no semantic value in
any other part of a resource name other the file extension. Thus, a
Calendar collection may be called "calendar", "cal", "Calendario" or
"日历" (Chinese). It's the properties of the resource that define what
it is, not the name.
The WebDAV ACL specification requires that any principal to whom permissions
can be represented via a WebDAV resource (complete with WebDAV properties
and a HTTP URL). Thus, both users may be represented (for example, as
/principals/users/ldusseault) and groups (for example, as
/principals/groups/calsch). This feature offers an excellent framework
for linking users to calendars in a fashion not otherwise easily implemented.
Note that the WebDAV principal resources may not be modifiable through
WebDAV. This is an important consideration because it allows the principal
directory to be merely a WebDAV representation of data which is canonically
stored in an outside system. For example, an enterprise might use an LDAP
server to store and administer all user and group properties. This LDAP
server could be linked into the WebDAV repository through configuration
information. WebDAV server implementations exist which offer principal
resources, but when the principal resources are queried the server actually
makes a LDAP request to get the principal information from its official
source. This saves WebDAV clients from having to implement LDAP and provides
a single URL format for principals regardless of whether the user directory
is stored in LDAP or some other system.
A server supporting CalDAV MUST support additional properties on principal
resources if these principals are associated with calendars. In
addition, certain properties are required on calendars to link to
principal resources. These properties are defined in the properties section.
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.
Calendar users often wish to allow other users to see their free-busy
times, without viewing the other details of the calendar events
(location, subject, attendees). This allows a significant amount
of privacy while still allowing those other users to schedule
meetings at times when the calendar owner is likely to be free.
The view-free-busy privilege in the "urn:ietf:params:xml:ns:calsch"
namespace controls access to view the start times
and end times of free and busy blocks of time. This privilege may
be granted on an entire calendar. It may also make sense to grant
this privilege on individual events (in which case the time allocated
to those events would show up as free in the free-busy rollup to an
unauthorized viewer), but a server MAY forbid the free-busy privilege
from being used on individual events or event containers. A CalDAV
server MUST support the free-busy privilege on a Calendar collection.
]]>
The view-free-busy privilege is aggregated in the standard WebDAV
'read' privilege. Clients can discover support for various privileges
using the 'DAV:supported-privilege-set' property defined in
RFC2518.
Property promotion and demotion (hereafter called simply "property promotion")
is the name for the functionality by which a server ensures that a resource's
internal data and its externally-visible metadata remain consistent. In
WebDAV, a collection listing (PROPFIND) selects a set of property names
to retrieve. For a collection listing to be useful to browse calendars,
certain calendaring information must be exposed as WebDAV properties
(this also makes WebDAV SEARCH useful, and makes the definition of REPORTs
easier). Since a calendar resource of type text/calendar has properties
which duplicate some of its internal state, it's the server's responsibility
to keep those consistent somehow.
The server has some leeway in how it makes properties and bodies consistent,
as long as the response to a GET shows information consistent with the
response to a PROPFIND in the interval in which a calendar object has not
been altered. Thus, the server MAY change property values when a PUT is
performed that alters data exposed as properties, and also change the body
when a PROPPATCH is performed that alters calendar properties. Alternatively,
a server could implement "lazy promotion" and apply consistency changes only
when a GET, PROPFIND, SEARCH or REPORT is issued. Finally, a server might decompose
property data and non-property data into separate locations and recompose
the information only when a GET requests the entire resource. Any of these
approaches MUST be transparent to the client, in that operations behave
consistently, with complete round-trip fidelity of all the data originally
provided. Thus, a server MAY canonicalize its resource bodies (e.g.
eliminate meaningless spaces) but MUST preserve all data.
Not all properties need to be promoted, only those properties most useful
for clients to do property value searching or listings of calendar events
either through PROPFIND or through the recurrance report. All unrecognized
properties can be left in the event body (such as those beginning with x-).
TODO: This section needs further definition and details. Clients can upload
iCalendar files with syntactic or semantic errors, so helpful error codes
must be chosen for these cases:
Property is set which can't be demoted without making the iCalendar body invalidiCalendar body provided isn't valid Scheduling and fanout is a valuable function provided by advanced
calendaring servers. Simple clients clearly benefit from having the
logic handled by the server. Rich clients also benefit from having to
upload less data to various servers (including messaging servers to send
invitations via messages) to accomplish the same things. Servers can sometimes
provide more advanced scheduling functionality than clients - for example,
a server providing fanout could create "unconfirmed" VEVENT resources
within invitees' calendars.
However, rich calendaring clients may prefer to do fanout. Clients
can perform special functionality during scheduling (for example, a client
may be configured to be able to directly put events on others' calendars
if the user has sufficient permissions). Thus, it is proposed that CalDAV
allow the client to either perform fanout and merely create the event
(complete with attendee information) OR request that the server perform
fanout. In other words, the server MUST handle fanout if requested, and
clients MAY perform fanout if the client chooses.
CalDAV servers MUST support iTIP to do fanout when requested, and MUST
fall back to iMIP when iTIP is impossible. Each REQUEST generated on behalf
of a Calendar MUST be stored in the calendar's 'scheduling' collection.
Each REPLY received to those REQUESTs MUST be stored in the same collection.
These REQUEST and REPLY items are available until the client deletes them
so that clients can view extra information (if present). CalDAV servers
MUST parse incoming REPLY messages and update the appropriate event with
attendee information. Thus, it's not necessary for clients to review
REQUEST or REPLY items, although they may.
As well, CalDAV servers MUST
support iTIP to receive scheduling requests. When a CalDAV server receives
an iTIP request, it MUST store the REQUEST object in an "invites" collection
for the client to handle. Each invite resource will have properties indicating
whether it is new, has been accepted, has been rejected, and whether it
is an obsolete REQUEST (the event has passed). Note that when a calendar
server receives iTIP requests it MAY auto-accept based on user configured
preferences. How these preferences are configured is out of the scope of
this specification, but one could imagine that a CalDAV server could host
auto-accept configuration Web pages. A CalDAV server is NOT REQUIRED to
do any auto-accepting, it MAY simply store the requests for the next time
the client is online.
Exact mechanisms for triggering fanout requests must be determined and input is welcome.
There are several ways fanout could be accomplished: (a) A PUT
of the resource triggers fanout, so the body must contain the fanout
information (text and flags), (b) a PROPPATCH triggers fanout if
certain properties are set, (c) a new method requests fanout of a resource
that has already been uploaded. These three approaches are the most obvious
to this author and there is surprisingly little to choose between. More
input is needed, for example input on whether the fanout should be
synchronous or asynchronous. An asynchronous fanout mechanism using PUT
or PROPPATCH would mean that the client would synchronously handle the PUT
or PROPPATCH itself, but send invitations at some later time. A synchronous
fanout mechanism would probably use a new method with a name like INVITE,
because adding new synchronous behavior to existing methods might require
more complicated server implementation work.
When the server does fanout, it may send requests and receive replies.
Probably these requests and responses should be stored as WebDAV resources
so that the client can examine the details if desired. This could be a
separate collection within the calendar collection.
The W3C RDF Calendar group has already defined a namespace
("http://www.w3.org/2002/12/cal/ical#") and XML element
names for many calendaring properties, and these are completely consistent
with iCal. This standard reuses those namespaces, names and definitions,
as much as is consistent with the WebDAV data model.
Additional properties are needed to describe calendars and calendar-containers
because the W3C RDF Calendar group defines properties for the iCalendar-defined
objects only.
When used as a WebDAV property, each property name/namespace
can appear only once because
the property name and namespace is used to identify the property in
requests like PROPFIND and PROPPATCH. Multi-valued elements could either
be promoted to properties by using a container (e.g. an 'attendees' property
could hold each 'attendee' element), or multi-valued elements can remain in
the iCalendar body, and not be promoted as WebDAV properties. That means
clients must download the event body to learn the values for those pieces
of metadata.TODO: Need to reference RFC3339 and put date/time values in that format, and
note where that format differs from that of the iCalendar RFC values.
If any of these properties appear in an iCalendar body stored in
a CalDAV repository they MUST be promoted. All these properties
are in the "http://www.w3.org/2002/12/cal/ical#"The namespace "urn:ietf:params:xml:ns:calsch" is reserved for specifications
written by the CalSch working group or its eventual successors. It MUST
NOT be used for custom extensions. It is the namespace for every new
defined in this section (and every XML element defined in this document).
Note that the XML Schema 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-related XML. Some of the declarations refer to
XML elements defined by WebDAV which use the "DAV:" namespace. Those
WebDAV elements are not redefined in this document.
calendar-ownerMUST appear on a calendar or calendar-container
if there is a principal resources (user or group) with which it is
associated.
This property is used to discover the calendar
owner, or the person or group for which the calendar events are scheduled.
It MAY have the same value as the DAV (ACL) 'owner' property, but not
necessarily. For example, the president may be the calendar-owner,
but her secretary is the owner for all ACL/administrative purposes.
This property contains one 'href' element in the "DAV:" namespace.
<!ELEMENT calendar-owner (href) >MAY contain additional elements, which MUST
be ignored if not understood.
calendarsMUST appear on ACL Principal resources with which
a calendar is associated.
This property is used to browse principals and find
out what calendars they have, for the purpose of then browsing their
calendar or their free/busy published information. It contains one
or more 'href' elements in the "DAV:" namespace (this is a normal WebDAV
approach to putting one or more URL value in a property value).
<!ELEMENT calendars (href+) >MAY contain additional elements, which MUST
be ignored if not understood.
This section defines the reports which a CalDAV server MUST support. These
all provide special query functionality not normally handled by the generic
PROPFIND or SEARCH mechanisms. This can be required when a PROPFIND or
SEARCH cannot be written to request the data required for a common use
case without an reasonable amount of complex calculation or unnecessary
data transmitted. See DeltaV or ACL standards for some examples of reports
required in other situations.
As defined in DeltaV, all REPORT requests include an XML body naming the
type of report requested (only one) and some variables for how that report
is to be compiled. Note that support for the REPORT method does not imply
support for all reports defined in all WebDAV extensions. A CalDAV server
is required to support all the reports defined here and in the ACL standard,
but is not expected to support DeltaV reports unless it advertises them.
Reports are advertised with the 'supported-report-set' property defined
in DeltaV (again, even if versioning-specific features are not at all supported).
Each report defined here comes with specialized errors. In addition, some
WebDAV status codes are applicable to any request or to any REPORT request. This
includes redirect status codes, syntax errors (400 Bad Request), permission
errors or policy errors (401 Unauthorized and 403 Forbidden), 404 Not Found,
or a request-body that isn't XML or is invalid XML (422 Unprocessable Entity).
When an error is defined in this document, it is used in an error response
body inside an XML document (this practice was established with DeltaV and
ACL in order to avoid status code collisions). For example:
The 'calendar-time-range' report returns all objects of a specific type
within a time range, with or without recurrance expanded.
The first use case for this report is to have the server expand recurring
events to make a calendar view of a day's or week's events easy.
The WebDAV PROPFIND and SEARCH syntaxes do not as easily support this use case.
Even when the client doesn't need
recurrance expanded, it can use this report to save itself from the need
to write a SEARCH query which catches all events overlapping any part of the
period requested, or from having to do a PROPFIND and filter itself.
The second use case for this report is for users other than
the calendar owner to find out when the calendar owner is free. This is only
a minor variation, because it's effectively the same objects (VEVENT and
VFREEBUSY), only with
permissions restricting the kind of data the server will return. Servers
MUST allow users with permission to view the free-busy times for a calendar
to use this report. Servers MUST return event properties for visible
events including dtstart, dtend and free-busy type. Other properties MAY be refused.
The third use case for this report is to list all alarms in a time range.
The selection of VALARM objects, instead of VEVENT or VFREEBUSY objects, allows
this use case to be handled with the same report framework.
The REPORT request-body MUST have the root element 'calendar-time-range'.
The root element MAY contain the 'expand-recurrances' element as a flag. The root element MAY contain the 'object-types' element to list what
object types to return. The root element MUST contain the 'prop' element in the "DAV:" namespace
as defined in WebDAV, to list what property values to return.The root element MUST contain one 'dtstart' element The root element MUST contain one 'dtend' element. The Request-URI for this report MUST be a Calendar-container, a calendar
collection, or an events collection. The server MUST collation all the
event data contained within the requested collection.
The response to this report is a WebDAV Multi-Status response, containing
one <response> element for each event AND for each recurrance. This
differs from the PROPFIND response to an event collection only in that
the relevant recurrances each have their own <response> element,
not just the master event.
The server MUST expand all recurring events within the entire collection
(including sub-collections) if requested, and return all those events or recurrances
which overlap the period defined by the start to end. If an event
ends at precisely the requested start time, or begins at precisely the
requested end time, it does not overlap the period requested.
If the user requests properties which may not be seen (e.g. a user with
permission only to see free-busy time requests to see the location of
events), the response uses the regular WebDAV approach for properties
which are private (either 401 Unauthorized if the client is not authenticated,
or 403 Forbidden if the client is authenticated and still the property value
is private). These errors appear within the standard Multi-Status
response.
TODO: I guess an example is probably needed here.The server returns this error when the range
requested in the 'dtstart' and 'dtend' values is an invalid range (e.g.
dtend is earlier than or equal to dtstart value).
CAP offers a way to get timezones. I'm unclear whether this is a
server-wide list, or whether the contents vary by calendar/user. That would
help to decide whether to use a special OPTIONS request, a new REPORT, or a
new collection.
The DASL framework for search requests provides a powerful way to find calendars
in a repository, and to find calendar objects within a calendar. It is
virtually unlimited in variations. It can be used to request and search
on calendar properties as well as WebDAV properties. One drawback of DASL,
however, is that implementations are given great leeway in which properties
support search. That's less acceptable in calendaring applications, so this
specification adds requirements of CalDAV servers to support searches on
specific properties.
CalDAV servers MUST support 'eq' DASL searches on the following properties:
uid, valarm.
CalDAV servers MUST support 'eq', 'gt' and 'lt' DASL searches on the following
properties: dtstart, dtend, dtstamp.
CalDAV servers MUST support 'eq' and 'contains' DASL searches on the following
properties: location, comment, description, summary, organizer, attendee,
categories.WebDAV already provides functionality required to synchronize a collection
or set of collections, make changes offline, and a simple way to resolve
conflicts when reconnected. Strong ETags are the key to making this work,
but these are not required of all WebDAV servers.
Since offline functionality is more important
to Calendar applications than to other WebDAV applications, CalDAV servers
MUST support strong ETags.
Much more work could be done to make disconnected operations work better.
WebDAV implementors have discussed ETag-like tags for collections (CTags?)
which would change whenever the membership (or members?) of a collection
changed. Tombstones might also be useful to synchronize with DELETE
operations. However, all these mechanisms are of general use and not
limited to Calendaring. Therefore, it is suggested that work on advanced
synchronization take place in a separate document independent of the
calendaring-specific features discussed here. Many people are interested
in doing this kind of work and it has wide applicability and usefulness.
Requirements or design contributions from calendaring implementors are welcome.
TODO: this section should be expanded to give more guidance to clients
on how to synchronize WebDAV objects most effectively. In particular,
we need to understand how UID/SEQ metadata works with synchronization.
Note that recurrance isn't a synchronization problem in this model. Recurring items
appear only once in normal PROPFIND responses, so there's no danger that
in synchronizing a client will accidentally create extra recurrances.
Instead, recurrances appear only in a special REPORT which MUST not be
used for synchronization. We believe this separation between data
(recurring appointments) and presentation (the display of a period containing
several recurrances) is crucial to simplifying synchronization.
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.
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 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).
Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)Rational Software20 Maguire RoadLexingtonMA02421USgeoffrey.clemm@rational.comIBM3039 CornwallisResearch Triangle ParkNC27709USjamsden@us.ibm.comIBMHursley ParkWinchesterS021 2JNUKtim_ellison@uk.ibm.comMicrosoftOne Microsoft WayRedmondWA90852USckaler@microsoft.comUC Santa Cruz, Dept. of Computer Science1156 High StreetSanta CruzCA95064USejw@cse.ucsc.edu
This document specifies a set of methods, headers, and resource types
that define the WebDAV (Web Distributed Authoring and Versioning)
versioning extensions to the HTTP/1.1 protocol. WebDAV versioning
will minimize the complexity of clients that are capable of
interoperating with a variety of versioning repository managers, to
facilitate widespread deployment of applications capable of utilizing
the WebDAV Versioning services. WebDAV versioning includes automatic
versioning for versioning-unaware clients, version history
management, workspace management, baseline management, activity
management, and URL namespace versioning.
Session Initiation Protocol (SIP)-Specific Event NotificationThis document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS TRACK] Date and Time on the Internet: TimestampsClearswift Corporation1310 WatersideArlington Business ParkThealeReadingRG7 4SAUK+44 11 8903 8903+44 11 8903 9000GK@ACM.ORGSun Microsystems1050 Lakes Drive, Suite 250West CovinaCA91790USAchris.newman@sun.com
This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar.
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.
iCalendar Schema in RDF/XMLW3CWebDAV SEARCHgreenbytesOracleIntelligent MarketsFilenetCyrus Daboo and Michael Arick have provided substantial feedback for this draft.Added section on privileges for calendaring, extending WebDAV ACL privilege setDefined what to do with unrecognized properties in the bodies of iCalendar events,
with respect to property promotion/demotion