Cyrus is talking about the CalDav scheduling draft.
CalDav scheduling builds on CalDAV access, but does not require it – so you could do CalDav Scheduling without having a CalDAV access server. Scheduling uses iTIP as its model for scheduling, which allows clients to reuse existing capabilities. There’s a “Message” oriented Inbox/Outbox design, similar to how iMip functions with email. It’s designed for fast (immediate) free/busy lookups, and there is fin-grained access control, including delegation.
Each user has an Inbox and an Outbox collection. An Organizer deposits an “invitation”, into an Outbox with addressing details for attendees (using HTTP POST). The server delivers the invitation to the attendee’s Inbox and returns delivery success/failure status for each attendee. The attendee responds by depositing response into their Outbox and the server copies that to the Organizer’s Inbox.
With regular invites, the Organizer has to wait for the Attendee to respond. In the case of Free-Busy requests, the request is fulfilled immediately by the servers of the Attendees.
Access Control – there’s a global CALDAV:schedule privilege which controls who can do schedule – on the Outbox it determines who is allowed to schedule on behalf of teh ‘owner’ – e.g. allows ‘proxies’ that can carry out the HTTP POST method on behalf of the owner. On the Inbox it determines who is allowed to send scheduling messages to the owner.
CALDAV:schedule is actually an aggregate of three privileges – CALDAV-schedule-request: who is allowed to book meetings with me; CALDAV:schedule-reply: who is allowed to respond to meeting invites I send out; CALDAV:schedule-free-busy – who is allowed to see my free-busy info.
One or more calendar user addresses are defined on the WebDAV principal for each user who can be scheduled. The CalDAV server will take care of mapping the ATTENDEE calndar user address in the iCalendar data to the principal using the principal property. The Calendar User is multivalued, so allows for multiple addresses for a single user.
The spec is close to last call. There are some implementations already (Apple), with more in progress (RPI).