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
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).
: 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.