Wednesday Oct 17, 2007

Toward a Standard based LDAP Schema for resources (continued)

More on resources (see my 2 previous posts)...

What do we have today in terms of standardized LDAP schema for resources ?

RFC 4524 defines a room object class (thanks Ludo), but it lacks critical information for it to be really useful in the context of a calendar application:

   The 'room' object class is used to define entries representing rooms.
The 'cn' (commonName) attribute SHOULD be used for naming entries of
this object class.

( 0.9.2342.19200300.100.4.7 NAME 'room'
MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )

Then RFC 2739 (Calendar Attributes for vCard and LDAP), can be used to flag any LDAP entry (people, group or resource) as being calendar enabled:

   The Calendar Entry is a class derived from "TOP" [2], which contains
the four calendaring attributes.

NAME 'calEntry'
MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI

Nevertheless, in the context of CalDAV, this RFC seems a bit outdated. Most of the URI defined there can be discovered by CalDAV enabled clients using some other means. Then 8 attributes are defined by the RFC but only 6 of them show up in the object class definition (calCalAdrURI and calOtherCalAdrURIs are missing). In any case, this object class  lacks resource specific information.

Let's now look at proprietary schemas.

The Sun Calendar Server makes use of the icsCalendarResource object class which "specifies a calendar resource, such as a conference room or piece of equipment that must be scheduled". This object class defines some attributes that are of interest to calendar clients:

  •  the "icsCapacity" attribute is defined as containing and integer describing the "capacity" (e.g. number of seats) of the resource.
  •  the "icsContact" attribute contains a contact name for this resource.

It also defines some attributes that can be leveraged by both clients and servers:

  • the "icsAutoaccept" attribute indicates whether the resource will accept (respond to) invitations automatically (depending on its availability) without human intervention, in a synchronous manner,
  • the "icsDoublebooking" attribute indicates whether the resource can be booked for two different events occurring at the same time,
  • the "mail" and "mailAlternateAddress" attributes define the email address to use when scheduling this resource (actual emails sent to those addresses generally go to some sort of blackhole).
Note: the "icsAutoaccept" and "icsDoublebooking" attributes are also used by the "icsCalendarGroup" object class which defines a calendar created for and used by an LDAP group.

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.

Friday Oct 05, 2007

Calconnect discussions: the resource mess (booking a conference room)

Some more notes from the last Calconnect Roundtable...

The Calconnect Use Case Technical Committee presented their survey of the current state of resources in the context of a calendar application. They started by defining what they meant by resource, using the Calendaring and Scheduling Glossary of Terms definition:

Resource - Shared equipment, materials, or facilities that can be scheduled for use by calendar users.
Examples include: conference rooms, computers, audio visual equipment, and vehicles.

Then they demonstrated, using a single table, how interop is a myth when it comes to resource scheduling: after comparing the resource related attributes of 11 popular calendar products, they found that only 2 attributes were common to most of them (at least at the "conceptual" level and one of them being the name of the resource...).

The table did not include actual interop info showing how calendar client from product X could retrieve and interpret resource info from product Y but I suspect the result would have been close to 0% for most products.

But the discussion did not stay focused on the quest of a minimal interop schema (it was not the goal of the presentation anyway, its title being "Resources Revisited"). Instead it went into different directions. Just to list a few topics that were brought up:

  • Which component of the calendar ecosystem (Calendar Server, Directory,...) should offer the resource query service (e.g. "I have a meeting with 10 people, find a conference room with a projector, as close to my office as possible") ?
  • What are the client (versus server) responsibilities when it comes to finding and scheduling a resource ?
  • Should resources be represented in iCalendar objects (meetings) as a specific subcomponents (i.e. following what is currently done with the VVENUE draft) instead of just relying on things like LOCATION or ATTENDEE ?
  • Where is the boundary between an all-purpose calendaring system and a resource management system ?
  • Scheduling can be role based, hence resources can actually be people (e.g. "restaurant owner needs 3 cooks and one counter staff available on Sunday"). How do you convey that information in iCalendar objects ?



« April 2014