By Arnaudq-Oracle on Oct 17, 2007
What do we have today in terms of standardized LDAP schema for resources ?
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
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" , which contains
the four calendaring attributes.
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).