arnaudq's blog

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'
        SUP top STRUCTURAL
        MUST cn
        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.

      (1.2.840.113556.1.5.87
        NAME 'calEntry'
        TOP
        AUXILIARY
        MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI
        calOtherCAPURLs)
      )

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.

Posted at 11:45AM Oct 17, 2007 by arnaudq in CalDAV  |  Comments[2]