Schedulable Objectclass for vCard
draft-vcard-schedulable-00

Abstract

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 29, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 3. Schedulable Objectclass Value
• 4. Current vCard Properties for use with OBJECTCLASS:schedulable.
• 4.1. CALADRURI
• 5. New vCard Properties for use with OBJECTCLASS:schedulable.
• 5.1. AUTOSCHEDULE
• 5.2. BOOKINGINFO
• 5.3. BOOKINGRESTRICTED
• 5.4. BOOKINGWINDOWSTART
• 5.5. BOOKINGWINDOWEND
• 5.6. MAXINSTANCES
• 5.7. MULTIBOOK
• 6. New Parameter Values
• 6.1. RELATED TYPE Values
• 7. Examples
• 7.1. Schedulable
• 8. Security Considerations
• 9. IANA Considerations
• 9.1. New VCard Objectclass Value Registration
• 9.2. VCard Property and Value Registration
• 10. Acknowledgments
• 11. Recommendations for Calendaring Systems
• 12. Normative References
• Authors' Addresses

1. 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?

2. Conventions Used 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 [RFC2119].

3. 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 [RFC6350].

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

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

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

• FN
• UID
• KIND
• CALADRURI or EMAIL

4.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.

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

The following new properties are defined for use with OBJECTCLASS:schedulable.

Format and cardinality of new vCard properties are defined as described in Section 3.3 of [RFC6350].

5.1. AUTOSCHEDULE

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

Purpose:

Specify if the resource is automatically scheduled with no approval process.

ValueType:

Text value from the auto schedule values table.

Cardinality:

*1

ABNF:

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

Auto Schedule Values Table:

5.2. BOOKINGINFO

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

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:

Default value:

None

Example value:

http://www.example.com/room1_booking.html

5.3. BOOKINGRESTRICTED

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

Purpose:

Specify if there are restrictions to booking the resource specified by access rights in the system. More information is provided by the BOOKINGINFO Section 5.2 property.

ValueType:

Boolean value.

Cardinality:

*1

ABNF:

Default value:

FALSE.

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

Example value:

TRUE

5.4. BOOKINGWINDOWSTART

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

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 [RFC3339].

Cardinality:

*1

ABNF:

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

5.5. BOOKINGWINDOWEND

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

              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)
                

Purpose:

Defines how much time in advance the resource booking is closed.

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 [RFC3339].

Cardinality:

*1

ABNF:

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.

Default value:

None

Example value:

P5D

5.6. MAXINSTANCES

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

Purpose:

Maximum number of instances of an event, the resource can be scheduled for from NOW.

ValueType:

Integer value.

Cardinality:

*1

ABNF:

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

5.7. MULTIBOOK

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

Purpose:

Number of simultaneous bookings allowed.

ValueType:

Integer value.
Value of 0 indicates no limits.

Cardinality:

*1

ABNF:

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

6. New Parameter Values

6.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 [RFC6350].

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

7. Examples

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

8. 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.

9. IANA Considerations

9.1. New VCard Objectclass Value Registration

A objectclass value is be defined according to the process specified in Section 10.2.6 of [RFC6350].

9.2. VCard Property and Value Registration

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

New VCard Properties Table:

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

New VCard Properties Table:

10. Acknowledgments

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.

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:

1. BOOKINGWINDOWSTART (Section 5.4), BOOKINGWINDOWEND (Section 5.5) and MULTIBOOK (Section 5.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.
2. Calendaring systems that support the AUTOSCHEDULE ()Section 5.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.
3. 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.

12. Normative References

Authors' Addresses