So we have a calendar server and a dav server both apparently working 
on Vairocana.

We need:
- A way to create calendars and principals
  Each project (e.g. OARC, OxIMC) needs its own calendar
  For each calendar it must be possible for: 
  	$ANYONE to read the calendar and create events
  	$CALMOD to do anything on that calendar
  
- You can create a celendar anywhere. 

SabreDAV
If-None-Match not honoured by GET.
500 Internal Server Error when the date is invalid (40th June) instead of 304.
500 Internal Server Error when the date is invalid (random text) instead of 304.
If-Modified-Since: fails to detect invalid dates.
No ETag for a new PUT.
No DAV:owner is set on PUT
DELETE on a collection with an invalid Depth: header should return 400, not 204
Destination header in all lower-case is not recognised.

OPTIONS on root directory allows DELETE
OPTIONS on non-existent resource allows GET, HEAD, PROPFIND, COPY, REPORT, MOVE, DELETE, PROPPATCH
No creationdate property on newly-created resource.
MKCALENDAR expects a DAV:resourcetype to appear in the request; this is not required by the spec, and is not supportd by the example here
http://tools.ietf.org/html/rfc4791#section-5.3.1
GET with two range specifications returns status 200 and the entire document
LOCK should permit a Timeout: header with more than one timetype production.
LOCK on collection/resource followed byt LOCK on collection should fail with a 207, instead of creating conflicting locks.

Creating principals.
====================
Group principals have no password - you can't log in as a group.
There is always an admins group.
A new user principal MUST have a password.
Everything in the principals collection is owned by admins.
A principal has something similar to "all privs on his own resource.

Groups and ACLs.
================

Therefore the /principals directory should have an ACL like this:
<acl>
	<ace>
		<protected />
		<principal>
			<href>/principals/admins</href>
		</principal>
		<grant>
			<privilege><all></privilege>
		</grant>
	</ace>
</acl>

A principal should have an ACL like this:
<acl>
	<ace>
		<protected />
		<principal>
			<href>/principals/admins</href>
		</principal>
		<grant>
			<privilege><all /></privilege>
		</grant>
	</ace>
	<ace>
		<protected />
		<principal>
			<href>/principals/[princname]</href>
		</principal>
		<grant>
			<privilege><all /></privilege>
		</grant>
	</ace>
</acl>

Calendars aren't working at the moment:
include(/usr/share/php/Sabre/CalDAV/FSExt/Calendar.php)	

They are now!

Exporting Calendars to OARC/Mir
===============================
Mir uses a static page to list events; so a multiget report that lists
an appropriate set of events (like, everything in the future) would get
the required data. The data then needs to be converted to HTML.

OARC uses PHP to interrogate a database, from which the data is extracted.
The same PHP script could in principle interrogate a CalDAV server. OARC 
wants this data:
$number	(used to VIEW the engagement; could be made a uri)
$date
$time
$endtime
$title
$keyholder (could be a custom property)

Something like a calendar-multiget REPORT with a suitable date range 
would do the trick.

ACLs in force.
==============
/principals has no ACL.
jackc has:
<DAV:ace>
 <DAV:principal>
  <DAV:href>/principals/jackc</DAV:href>
 </DAV:principal>
 <DAV:grant>
  <DAV:privilege><DAV:all></DAV:all></DAV:privilege>
 </DAV:grant>
 <DAV:principal><DAV:owner></DAV:owner></DAV:principal>
 <DAV:grant>
  <DAV:privilege><DAV:all></DAV:all></DAV:privilege>
 </DAV:grant>
 <DAV:principal><DAV:href>/principals/admin</DAV:href></DAV:principal>
 <DAV:grant>
  <DAV:privilege><DAV:all></DAV:all></DAV:privilege>
 </DAV:grant>
</DAV:ace> 

/ should be owned by admins.
/principals should be owned by admins.
/principals/[name] should be owned by admins, with <all /> granted to the 
subject principal (i.e. "self") and to the owner. These are protected, meaning
that they can't be "removed".
     

New resources are owned by their creator, and 

All new resources automatically get the default ACL:
 admins: grant all protected
 owner: grant all protected

All new ACLs get initialized with:
 unauthenticated: deny all
 
NOPE: the default case is that if an ACL exists, then anything not explicitly 
granted is denied. In thw absence of an ACL, everything is granted.
 
Actually I think the default SOF is that nobody has any privs, except the 
admins and owner privs. If it isn't granted, you don't have it.
 
You have to be the owner or an admin to change the owner. The owner can't be a 
group (you can't log in as a group, and the owner by default is the logged-in user that
created the resource).

The UI for changing an ACL