[Ietf-caldav] Creating a calendar
Cyrus Daboo
daboo at isamet.com
Thu Aug 26 13:37:25 PDT 2004
Hi Bernard,
--On Thursday, August 26, 2004 4:05 PM -0400 Bernard Desruisseaux
<bernard.desruisseaux at oracle.com> wrote:
> I see calendar creation more as a provisioning issue, and
> thus probably outside the scope of CalDAV.
I disagree - I expect users to be able to create, organize, delete etc a
hierarchy of calendars and that must be possible via the caldav client.
> A user could find the location of his calendars by looking
> at the "calendars" property (see section 11.2) of his own
> principal resource (e.g., http://example.com/users/bernard)
> assuming the user knows the URL of his own principal resource.
> I don't actually know how he would though.
Actually one thing I would like to propose is the equivalent of the IMAP
NAMESPACE extension. Specifically a REPORT that would list key URLs for the
different caldav store paths a user's client should provision itself with.
That would include a URL to the users personal calendars, one for shared
(other users) calendars, and one for public calendars. In addition a URL to
the principals collection would also be handy to make working with ACLs
easy.
In the process of our work I wrote something up on this and have attached a
rough outline of that as a second text part to this message. I would like
to know if this is something we should consider for caldav.
--
Cyrus Daboo
-------------- next part --------------
2.2 Repository Organisation and Namepsace
As per [CALDAV], calendar data may be scattered across multiple parts
of a repository. However, clients need a generalised way to locate
calendar stores within the repository to make browsing easier.
Therefore a CalDAV server will define specific areas within the
repository that are identified as containing (only) calendar
resources. These areas will be identified by specific groupings
indicating the nature of the calendar 'area' being described. This is
akin to IMAP's NAMEPSACE extension which allows different areas
within a mailstore to be identified. The CalDAV server will provide a
special REPORT that returns the store namepsace information.
There are several pre-defined areas:
a. "Personal" - indicates the area that contains the currently
authenticated user's own personal calendar resources. By default,
all data within this hierarchy will be private to the user, but
the user may choose to use WebDAV ACLs to expose specific
resources to other users as appropriate.
b. "Shared" - indicates an area that contains calendars for all
individual users on the caldav server. Typically this area will
be split into hierarchies for each user on the system. By
default, all data within each user hierarchy will be private to
that user, but any user may choose to use WebDAV ACLs to expose
specific resources to other users as appropriate. NB The
currently authenticated user's personal hierarchy will also
appear in the "Shared" area. Clients may choose to suppress
display of that when presenting users with a view of the "Shared"
area, if they also present the "Personal" area separately.
c. "Public" - indicates an area that contains calendars accessible
to all users on the caldav server. Access control can be used to
limit access to any resources within this area, but typically it
would be accessible to all users.
d. "Timezones" - indicates an area where the server stores a common
"library" of iCalendar timezones that clients can use to build
their own timezone lists. , See Section 8.
e. "ACL-Users" - indicates an area where WebDAV ACL principles for
users can be found. This area is provided to allow clients to
lookup users when doing access control operations on calendars.
Clients that do not manipulate access control information can
ignore it.
f. "ACL-Groups" - indicates an area where WebDAV ACL principles for
groups can be found. This area is provided to allow clients to
lookup groups when doing access control operations on calendars.
Clients that do not manipulate access control information can
ignore it.
Servers MUST also permit the use of other areas, that will be user
(server admin) defined. This allows an organisation to map their
organisational structure into the CalDAV space to expose calendars
for internal resources such as meeting rooms, specific devices
(printers, copiers, shared terminals etc). The server MUST advertise
such areas in the NAMESPACE report described in Section 6.1. Each
area will have an associated display name and description in the
NAMESPACE report results that can be used when presenting them to the
user.
Example:
A server uses the following relative URIs for the standard areas
(assuming the currently authenticated user is identified as "joe"):
+--------------+----------------------+------------------------+
| Area | RURI | Display Name |
+--------------+----------------------+------------------------+
| "Personal" | /calendars/user/joe | My Calendars |
| "Shared" | /calendars/user | Other Users' Calendars |
| "Public" | /calendars/public | Public Calendars |
| "Timezones" | /calendars/timezones | |
| "ACL-Users" | /principles/user | |
| "ACL-Groups" | /principles/group | |
+--------------+----------------------+------------------------+
In addition the server may advertise other areas:
+------------+---------------------+-----------------------+
| Area | RURI | Display Name |
+------------+---------------------+-----------------------+
| "Rooms" | /calendars/room | Meeting Room Bookings |
| "Projects" | /calendars/projects | Project Timelines |
+------------+---------------------+-----------------------+
6.1 The 'calendar-store-namespace' report
The namespace report is used by the client to determine the areas of
the CalDAV server's repository where calendar data is stored. CalDAV
servers can divide up their repository into different areas to
group calendar data according to some functional meaning. Section 2.2
describes the areas that servers SHOULD support.
6.1.1 Request for 'calendar-store-namespace'
The REPORT request-body MUST have the root element
'calendar-store-namespace' Section 10.1.
Example:
-------Client Request-------
REPORT /caldav-root HTTP/1.1
Host: caldav.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: XXX
<?xml version="1.0" encoding="utf-8" ?>>
<report xmlns="DAV:">
<c:calendar-store-namespace
xmlns:c="http://www.example.com/caldav" />
</report>
6.1.2 Response for 'calendar-store-namespace'
The response to this report is an XML document containing the
namespace details. The XML document contains a single
'calendar-namespace-response' element Section 10.2, which contains
zero or more 'calendar-namespace' elements for each namespace defined
by the server. Each 'calendar-namespace' element contains a 'type'
attribute identifying the namespace type, and an href element
indicating the location of the resource. It may also contain a
'display-name' element and/or a 'description' element.
Example:
-------Server Response-------
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<c:calendar-namespace-response
xmlns:c="http://www.example.com/caldav">
<c:calendar-namespace type="personal">
<c:href>/calendars/user/joe</c:href>
<c:namespace-display-name>My Calendars</c:namespace-display-name>
<c:namespace-description>Your calendars</c:namespace-description>
</c:calendar-namespace>
<c:calendar-namespace type="shared">
<c:href>/calendars/user</c:href>
<c:namespace-display-name>Other Users'
Calendars</c:namespace-display-name>
<c:namespace-description>Calendars belonging to other users that
have been shared with you</c:namespace-description>
</c:calendar-namespace>
<c:calendar-namespace type="public">
<c:href>/calendars/public</c:href>
<c:namespace-display-name>Public
Calendars</c:namespace-display-name>
<c:namespace-description>Calendars available to all
users</c:namespace-description>
</c:calendar-namespace>
<c:calendar-namespace type="timezones">
<c:href>/calendars/timezones</c:href>
</c:calendar-namespace>
</c:calendar-namespace-response>
More information about the Ietf-caldav
mailing list