This specification describes a new property objectclass value for the vcard objectclass property defined in [REF] allowing schedulable entities to be marked as such.
© 2013 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This specification describes a new property objectclass value for the vcard objectclass property defined in [REF] allowing schedulable entities to be marked as such.
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?
No terms and definitions are listed in this document.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
This specification defines a new value for the OBJECTCLASS property deined in [TODO]. The value is registered according to the procedure in
schedulable
To specify the entity with this objectclass is schedulable.
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.
OBJECTCLASS:schedulable
The following properties MUST be specified in a vCard representing a calendaring or schedulable resource:
FN
UID
The following properties SHOULD be specified in a vCard representing a calendaring or schedulable resource:
KIND
CALADRURI or EMAIL
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.
The following new properties MAY be used with OBJECTCLASS:schedulable.
Format and cardinality of new vCard properties are defined as described in
Specify if the resource is automatically scheduled with no approval process.
Text value from the auto schedule values table.
*1
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.
AUTO
AUTO
| 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 |
| AUTO | auto accept and auto decline based on booking conflict |
| ALWAYS-ACCEPT | auto accept all invitations |
| ALWAYS-DECLINE | auto decline all invitations |
Provide the complete information on scheduling a resource if access rights are set or approval is required.
URI value. It MAY also be a free-form text value.
*
None
Specify if there are restrictions to booking the resource specified by access rights in the system. More information is provided by the BOOKINGINFO
Boolean value.
*1
FALSE.
Absence of this property indicates no restriction to booking the resource.
TRUE
Defines how much time in advance the resource can be booked.
Duration value.
The format is based on the
*1
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.
None
P3M
Defines how much time in advance the resource booking is closed.
Duration value.
The format is based on the
*1
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.
None
P5D
Maximum number of instances of an event, the resource can be scheduled for from NOW.
Integer value.
*1
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.
0
60
Number of simultaneous bookings allowed.
Integer value.
Value of 0 indicates no limits.
*1
Value of 0 indicates no limits. If this property is absent the resource may be booked only for one event at a particular moment.
1
1
This document specifies the following additional values that can be used as the value for the TYPE parameter of the RELATED property defined in
schedule-admin: an entity that performs scheduling approval, when scheduling the entity associated with this vCard, if approval required.
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.
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.
A objectclass value is be defined according to the process specified in
The following new VCard Properties need to be registered by IANA.
| VCard Property Name | VCard Property Definition |
|---|---|
| AUTOSCHEDULE | |
| BOOKINGINF* | |
| BOOKINGRESTRICTED | |
| BOOKINGWINDOWSTART | |
| BOOKINGWINDOWEND | |
| MAXINSTANCES | |
| MULTIBOOK |
The following new VCard Parameter Values need to be registered by IANA.
| VCard Property Name | VCard Parameter Name | VCard Parameter Value |
|---|---|---|
| RELATED | TYPE | schedule-admin |
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.
While this document does not mandate how each of the defined property values must be used by calendaring systems, here are some recommendations:
BOOKINGWINDOWSTART (
Calendaring systems that support the AUTOSCHEDULE (
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.
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.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This memo defines three mechanisms for obtaining a URI to a user’s calendar and free/busy time. [STANDARDS-TRACK]
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]