[caldeveloper-l] CalDAV resource scheduling

Helge Hess helge.hess at icloud.com
Tue May 8 14:31:42 PDT 2018


If you are in a CalDAV context, those are usually https/http URLs pointing to the principal representing the resource.

In the larger iCalendar context, they kinda have to be mailto URLs. Because that’s the only deployed cross-server iTIP protocol. Though you can do the principal URL, plus an (X-)EMAIL attribute on the resource ATTENDEE.

> What if a user adds a resource/room, that they are not supposed to access?

That should be covered by the CalDAV scheduling spec, I think, didn’t check, but I’m quite sure ;-) I think in a common CalDAV setup, the user wouldn’t be able to discover or query the mentioned principal URL.

hh

> On May 8, 2018, at 11:24 PM, Georg Ehrke <georg-calconnect at ehrke.email> wrote:
> 
> Hello everybody,
> 
> I’m interested in server side resource scheduling implementations.
> From a CalDAV client’s point of view it’s pretty straight forward:
> Resources and rooms are simple ATTENDEEs of an event, but unlike human attendees
> the CUTYPE (Calendar User Type) is not INDIVIDUAL but RESOURCE or ROOM. [1]
> 
> Something similar applies to FreeBusy requests. Just define a calendar-user-type of
> RESOURCE and ROOM and the server will return FreeBusy information like it would do for humans. [2]
> 
> So far - so good.
> 
> My main questions concern the common practice on the server side:
> - What kind of URIs are commonly used to identify resources and rooms? Is there any pattern to it? 
> 
> - What’s the most common way to implement this on the server side?
> Just have a calendar as if the resource/room was an ordinary human and just add every invitation
> to the calendar to fill up the calendar and thereby provide FreeBusy information? 
> 
> - What if a user adds a resource/room, that they are not supposed to access?
> Should the CalDAV server throw an error when creating the event or should the resource/room
> simply reply by declining the invitation?
> 
> Are there any other special cases I didn’t think of so far?
> 
> Any insights / links / recommendations are highly appreciated!
> 
> Cheers,
> Georg Ehrke
> 
> [1] https://tools.ietf.org/html/rfc5545#section-3.2.3
> [2] https://tools.ietf.org/html/rfc6638#section-2.4.2
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org



More information about the caldeveloper-l mailing list