Saturday Oct 06, 2007

Toward a Standard based LDAP Schema for resources

The Calconnect presentation on resources (see my previous post) has caught my attention. I will now try to give my own perspectives on the subject.

I think we could already make a huge step forward in terms of user experience by solving the most basic interoperability scenario:

Given a calendar client from vendor X and a calendar server from vendor Y and assuming standard based protocols, how do I schedule a meeting with 10 people while also booking an available and large enough conference room.

Ideally, we should try to solve this scenario using existing building blocks.

The CalDAV Scheduling IETF Draft is the emerging standard for calendar scheduling. While the iCalendar family of protocols often makes use of terms associated with people ("calendar user", "attendee",...), there is nothing that prevents a resource from being represented as a regular calendar that can be looked up for freebusy info, then invited (the CUTYPE parameter of the ATTENDEE iCalendar property includes values such as ROOM and RESOURCE). And indeed, whether using standard or proprietary protocols, most vendors have adopted that model to "book" resources.

There are still a few things that are special about calendars not associated with users:

  • in many cases, responses to meeting invitation should be generated without any human intervention (auto accept), based on some criteria (e.g. double booking not allowed),
  • those calendars still need to have a human "owner" that can administer it or respond manually to booking requests,
  • the resource needs to have an email address in order to schedule it, although actual emails sent to this address may be ignored,
  • ideally, booking a resource should be a synchronous operation (to avoid the race condition of 2 organizers booking the same no double booking resource at the same time),

Now to the discovery part. Here, LDAP sounds like the obvious choice (OK, at least from the point of view of someone working at a company that sells LDAP based solutions...):

  • LDAP is the recognized open standard to search for structured and hierarchical objects in a corporate or academic environment,
  • conference rooms and other resources already often reside in LDAP and are used by other applications (e.g. quick address book lookup to find the phone number of a conference room or its building number),
  • LDAP is already used by most calendar clients to find people,
  • several major calendar server vendors have already modeled resources as LDAP entries.

The third point is quite important as it allows those calendar clients to offer minimal resource handling without any code modification (as long as the resources have a name and email address).

So what is missing in my opinion is "just" a standard LDAP schema to model:

  1. calendar enabled resources,
  2. most frequently used types of resources like conference room, projector,...

With such a schema, the following scenario becomes possible:

  1. From the calendar client of his choice, the organizer composes a meeting invitation with 10 invitees (selected from his personal address book or from the LDAP Corporate Directory).
  2. Calendar client does a CalDAV freebusy lookup for each invitee.
  3. Calendar client presents the organizer with a freebusy grid view, showing the first timeslot where all parties are free.
  4. User acknowledges the timeslot and click on a "find conference room" button.
  5. Calendar client does an LDAP lookup to find the physical location of the organizer (e.g. building number).
  6. Calendar clients does an LDAP lookup to find all conference rooms in the location retrieved at step 4. and with a capacity of 10 people.
  7. Calendar clients does a CalDAV freebusy lookup on all conference rooms retrieved at step 6. and picks up the first one that is free for the selected timeslot.
  8. Calendar client automatically adds that conference room in the list of invitees.
While different variations of the above already exist in most calendar products, those products are all using proprietary LDAP schema. A standard schema would allow this to work across vendors. Before trying to draft such a schema, I would like to enumerate a few existing proprietary schema in an upcoming post. So if you happen to know one... comments are welcomed.



« February 2017