[caldeveloper-l] CalDAV resource scheduling

[Michael Douglass]

You can get as complicated as you want on the server side.

We (calconnect) worked on a bunch of extensions to vcard 4 to support 
resource scheduling (https://github.com/CalConnect/PUBLIC_DRAFTS) - it 
didn't go far because vcard 4 didn't get widely implemented.

This would allow the server to query a directory and get attributes to 
facilitate scheduling.

What we couldn't allow for were certain business rules but we allowed 
for booking windows, automatic replies etc.

Most of this reflected common practice among vendors - it was largely an 
attempt to standardize the representation.

As for rooms a user cannot access the resource simply declines the 
meeting request. It may also do so at a later date if somebody with 
higher priority overrides the request. In that case the meeting needs to 
be rescheduled with a different room or different time.

There's not much different to handling a person.

More below


On 5/8/18 17:31, Helge Hess wrote:
> 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?
Up to the implementation - usually a pattern but nothing you could 
depend on in general
>>
>> - 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?
Calendar per resource
>>
>> - 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?
Just decline - the client ought to recognize that the room is 'special' 
in that it's necessary for the meeting but in reality the client should 
also be able to tell you if a vital human can't attend. No real difference
>>
>> Are there any other special cases I didn’t think of so far?
Probably -
>>
>> 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
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org