Foreword

This specification describes a new property objectclass value for the vcard objectclass property defined in [REF] allowing schedulable entities to be marked as such.

Introduction

The schedulable object class defines a number of properties which are required or useful for schedulable entities.

A schedulable entity may be scheduled for meetings (usually a person) or for use (usually a resource). The properties specified here allow a client to discover such an entity and initiate a scheduling request.

Some of the properties and values may be used by calendar servers to determine the appropriate action when a scheduling request is received. For example, do we auto-accept the request if the entity is available?

Schedulable Objectclass for vCard

1. Scope

This document specifies a new objectclass value for vCard that enables entities to be marked as schedulable. It defines:

A new objectclass value “schedulable”
Required and recommended properties for schedulable entities
New properties specific to scheduling functionality
New parameter values for existing properties

This specification is intended for use by calendar and scheduling systems that need to manage schedulable resources and entities.

2. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 8601:2004, International Organization for Standardization. Data elements and interchange formats — Information interchange — Representation of dates and times. Third edition. 2004. Geneva. https://www.iso.org/standard/40874.html.

IETF RFC 2119, S. BRADNER. Key words for use in RFCs to Indicate Requirement Levels. 1997. RFC Publisher. https://www.rfc-editor.org/info/rfc2119.

IETF RFC 2739, T. SMALL, D. HENNESSY and F. DAWSON. Calendar Attributes for vCard and LDAP. 2000. RFC Publisher. https://www.rfc-editor.org/info/rfc2739.

IETF RFC 3339, G. KLYNE and C. NEWMAN. Date and Time on the Internet: Timestamps. 2002. RFC Publisher. https://www.rfc-editor.org/info/rfc3339.

IETF RFC 4589, H. SCHULZRINNE and H. TSCHOFENIG. Location Types Registry. 2006. RFC Publisher. https://www.rfc-editor.org/info/rfc4589.

IETF RFC 6350, S. PERREAULT. vCard Format Specification. 2011. RFC Publisher. https://www.rfc-editor.org/info/rfc6350.

3. Terms and definitions

For the purposes of this document, the following terms and definitions apply.

3.1. schedulable entity

entity that can be scheduled for meetings or resource usage

3.2. calendar user address

address used by calendaring and scheduling applications to identify a calendar user

3.3. booking window

time period during which a schedulable entity can be booked

3.4. auto-schedule

automatic processing of scheduling requests without manual intervention

3.5. booking restriction

limitation on who can schedule an entity or under what conditions

3.6. simultaneous booking

multiple concurrent bookings of the same schedulable entity

3.7. scheduling administrator

person or system responsible for approving scheduling requests when required

4. Schedulable Objectclass Value

This specification defines a new value for the OBJECTCLASS property deined in [TODO]. The value is registered according to the procedure in Section 10.2.6 of IETF RFC 6350.

Value: schedulable
Purpose: To specify the entity with this objectclass is schedulable.

Conformance This value MAY be used with the OBJECTCLASS property. If used the properties, parameters and values of the vcard MUST conform to the requirements of this specification.

Example: OBJECTCLASS:schedulable

5. Current vCard Properties for use with OBJECTCLASS:schedulable.

The following properties MUST be specified in a vCard representing a calendaring or schedulable resource:

The following properties SHOULD be specified in a vCard representing a calendaring or schedulable resource:

KIND
CALADRURI or EMAIL

5.1. CALADRURI

The CALADRURI value is the address that would be used by a Scheduling and Calendaring application to schedule the resource.

Its value MUST be a uri string, in most cases a mailto: uri. The EMAIL property value of the resource should be used for scheduling, in the absence of this property.

6. New vCard Properties for use with OBJECTCLASS:schedulable.

The following new properties MAY be used with OBJECTCLASS:schedulable.

Format and cardinality of new vCard properties are defined as described in Section 3.3 of IETF RFC 6350.

6.1. AUTOSCHEDULE

Purpose: Specify if the resource is automatically scheduled with no approval process.
ValueType: Text value from the auto schedule values table.
Cardinality: *1
ABNF

AUTOSCHEDULE-param = "VALUE=text" / any-param
AUTOSCHEDULE-value = text

Figure 1

Default value: If the property is absent or unknown, resource bookings are auto accepted, if it does not result in a booking conflict and auto declined if it does.
Default value: AUTO
Example value: AUTO

Table 1 — Auto Schedule Values Table

Auto schedule value	Scheduling action
NONE	no auto scheduling
ACCEPT-IF-FREE	auto accept invitations, if no conflict
DECLINE-IF-BUSY	auto decline invitations that result in a conflict
AUT*	auto accept and auto decline based on booking conflict
ALWAYS-ACCEPT	auto accept all invitations
ALWAYS-DECLINE	auto decline all invitations

6.2. BOOKINGINFO

Purpose: Provide the complete information on scheduling a resource if access rights are set or approval is required.
ValueType: URI value. It MAY also be a free-form text value.
Cardinality: *
ABNF

BOOKINGINFO-param = "VALUE=" ("text" / "uri") /
                     any-param
BOOKINGINFO-value = uri / text

Figure 2

Default value: None
Example value: http://www.example.com/room1_booking.html

6.3. BOOKINGRESTRICTED

Purpose: Specify if there are restrictions to booking the resource specified by access rights in the system. More information is provided by the BOOKINGINFO Clause 6.2 property.
ValueType: Boolean value.
Cardinality: *1
ABNF

BOOKINGRESTRICTED-param = "VALUE=boolean" / any-param
BOOKINGRESTRICTED-value = boolean

Figure 3

Default value: FALSE.

Absence of this property indicates no restriction to booking the resource.

Example value: TRUE

6.4. BOOKINGWINDOWSTART

Purpose: Defines how much time in advance the resource can be booked.
ValueType: Duration value.

The format is based on the ISO 8601:2004 duration representation basic format with designators for the duration of time. The format can represent nominal durations (weeks and days) and accurate durations (hours, minutes, and seconds). The syntax is further defined in Appendix A, “Duration” section of IETF RFC 3339.

Cardinality: *1
ABNF

BOOKINGWINDOWSTART-param = "VALUE=text" / any-param
BOOKINGWINDOWSTART-value = text

Figure 4

Special Notes: The value of this property is used to calculate the earliest date and time when a resource can be reserved for an event starting on a specific date and time.

If this property value is defined, the resource may be booked for an event at a certain time, only if the current time is equal to or after the date and time calculated by subtracting this value from the event’s proposed start time. If this property is absent, then the resource may be booked at any time before the end of the booking window.

Default value: None
Example value: P3M

6.5. BOOKINGWINDOWEND

Purpose: Defines how much time in advance the resource booking is closed.
ValueType: Duration value.

Cardinality: *1
ABNF

BOOKINGWINDOWEND-param = "VALUE=text" / any-param
BOOKINGWINDOWEND-value = text

Figure 5

Special Notes

The value of this property is used to calculate the latest date and time when a resource can be reserved for an event starting on a specific date and time.

If the current time is equal to or before the value obtained by subtracting BookingWindowEnd from the start date and time of the event, then the resource may be booked. If this property is absent, then the resource may be booked anytime from booking window start to the start of the event.

BookingWindow Start and End together provide the window of time a resource can be booked, relative to the start time of the event.

If: BookingWindowStart = BwS,
    BookingWindowEnd = BwE,
    Current Time = CT and
    Event Start Time = ST,
Then a resource can be booked at a certain time only if
    CT is equal to or after (ST - BwS)
    and CT is equal to or before (ST - BwE)

Figure 6

Default value

None

Example value

P5D

6.6. MAXINSTANCES

Purpose: Maximum number of instances of an event, the resource can be scheduled for from NOW.
ValueType: Integer value.
Cardinality: *1
ABNF

MAXINSTANCES-param = "VALUE=integer" / any-param
MAXINSTANCES-value = integer

Figure 7

Special Notes: Value of 0 indicates no limits. Value of 1 indicates that no recurring bookings are allowed. If this property is absent there is no limit to the number of instances it may be booked for at any moment.
Default value: 0
Example value: 60

6.7. MULTIBOOK

Purpose: Number of simultaneous bookings allowed.
ValueType: Integer value. Value of 0 indicates no limits.
Cardinality: *1
ABNF

MULTIBOOK-param = "VALUE=integer" / any-param
MULTIBOOK-value = integer

Figure 8

Special Notes: Value of 0 indicates no limits. If this property is absent the resource may be booked only for one event at a particular moment.
Default value: 1
Example value: 1

7. New Parameter Values

7.1. RELATED TYPE Values

This document specifies the following additional values that can be used as the value for the TYPE parameter of the RELATED property defined in Section 6.6.6 of IETF RFC 6350.

schedule-admin: an entity that performs scheduling approval, when scheduling the entity associated with this vCard, if approval required.

8. Examples

8.1. Schedulable

A schedulable entity can be scheduled for meetings (as a person) or for use (as a resource). For a scheduling system to be able to usefully manage the schedule it needs specific information.

At the very least there MUST be some form of calendar user address. It’s useful to know whether requests can be auto accepted if the slot is available.

BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
FN:J. Doe
N:Doe;J.;;;
EMAIL:jdoe@example.edu
TEL;VALUE=uri:tel:+1-555-555-5555
OBJECTCLASS:schedulable
CALADRURI:jdoe@example.edu
AUTOSCHEDULE:ACCEPT-IF-FREE
END:VCARD

Figure 9

9. Security Considerations

As this document only defines schema for representing entities for calendaring and scheduling and does not refer to the actual storage mechanism itself, or the calendaring and scheduling protocol, no special security considerations are required as part of this document.

10. IANA Considerations

10.1. New VCard Objectclass Value Registration

A objectclass value is be defined according to the process specified in Section 10.2.6 of IETF RFC 6350.

10.2. VCard Property and Value Registration

The following new VCard Properties need to be registered by IANA.

Table 2 — New VCard Properties Table

VCard Property Name	VCard Property Definition
AUTOSCHEDULE	Clause 6.1
BOOKINGINF*	Clause 6.2
BOOKINGRESTRICTED	[restricted]
BOOKINGWINDOWSTART	[windowstart]
BOOKINGWINDOWEND	[windowend]
MAXINSTANCES	[maxinstances]
MULTIBOOK	Clause 6.7

The following new VCard Parameter Values need to be registered by IANA.

Table 3 — New VCard Properties Table

VCard Property Name	VCard Parameter Name	VCard Parameter Value
RELATED	TYPE	schedule-admin Clause 7.1

11. Recommendations for Calendaring Systems

While this document does not mandate how each of the defined property values must be used by calendaring systems, here are some recommendations:

BOOKINGWINDOWSTART (Clause 6.4), BOOKINGWINDOWEND ( Clause 6.5) and MULTIBOOK ( Clause 6.7) information should be used in freebusy calculations. A query for a time slot that falls outside the booking window or one that already has the maximum allowed number of simultaneous bookings, MUST be returned as BUSY_UNAVAILABLE.
Calendaring systems that support the AUTOSCHEDULE (Clause 6.1) property, SHOULD automatically mark the attendee PARTSTAT for a resource as ACCEPTED, if its auto schedule value is AUTO and the scheduling is successful. If scheduling administrator approval is required, the PARTSTAT could be automatically marked as TENTATIVE. Rooms SHOULD have this property defined.
Information from other properties, for example the capacity if a resource can be used by calendaring systems to warn end users if the number of attendees exceed the capacity value. Rooms SHOULD have CAPACITY defined.

Individual calendar servers may regard the values of these properties set in a directory server or a different database as advisory and could further limit what it allows.

Appendix A
(informative)
Acknowledgements

This specification is a result of discussions that took place within the Calendaring and Scheduling Consortium’s Resource Technical Committee. The authors thank the participants of that group.

Warning for Drafts