vCard representation of resources for calendaring and scheduling services
draft-cal-resource-vcard-01

Abstract

This specification describes the vCard representation of resources for calendaring and scheduling. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status.

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 April 02, 2013.

Copyright Notice

Copyright (c) 2012 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. General Considerations
• 4. Resource Object
• 5. Resource Properties
• 5.1. Mandatory Properties
• 5.2. Base vCard Properties
• 5.3. New vCard Properties
• 5.3.1. Scheduling Related Properties
• 5.3.1.1. AUTOSCHEDULE
• 5.3.1.2. BOOKINGINFO
• 5.3.1.3. BOOKINGRESTRICTED
• 5.3.1.4. BOOKINGWINDOWSTART
• 5.3.1.5. BOOKINGWINDOWEND
• 5.3.1.6. MAXINSTANCES
• 5.3.1.7. MULTIBOOK
• 5.3.1.8. SCHEDADMIN
• 5.3.2. Other Properties
• 5.3.2.1. ACCESSIBLE
• 5.3.2.2. ACCESSIBILITYINFO
• 5.3.2.3. CAPACITY
• 5.3.2.4. INVENTORYLIST
• 5.3.2.5. INVENTORYURL
• 5.3.2.6. LOCATIONTYPE
• 5.3.2.7. RESOURCEMANAGER
• 5.3.2.8. RESOURCEOWNER
• 5.3.2.9. RESTRICTED
• 5.3.2.10. RESTRICTEDACCESSINFO
• 5.3.2.11. NOCOST
• 5.3.2.12. COSTINFO
• 6. Examples
• 6.1. Location Resource
• 6.2. Role Resources Group
• 7. Security Considerations
• 8. IANA Considerations
• 8.1. VCard Property and Value Registration
• 9. Recommendations for Calendaring Systems
• 10. Acknowledgments
• 11. Unresolved Issues
• 12. References
• Authors' Addresses

1. Introduction

This specification defines the vCard representation of calendaring resources to ease the discovery and scheduling of resources between any calendar client and server.

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

Data values MUST have valid representation for the specified value type with respect to escape characters, line folding, and so on.

4. Resource Object

A resource object definition SHOULD contain all information required to find and schedule the right resource. For this, it SHOULD contain all, or a set of properties described in Section 5. Additional proprietary properties may be defined as well, but MUST begin with "X-". Clients encountering properties they don't know about MUST ignore them.

Properties required to contact the resource are not included in this specification. vCard properties defined in vCard Format Specification [RFC6350] can be used to include additional contact information for the resource.

5. Resource Properties

5.1. Mandatory Properties

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

• FN
• UID
• KIND
• CALADRURI or EMAIL

5.2. Base vCard Properties

The following properties defined in [RFC6350] or [RFC2739] make sense for vCards representing calendaring or schedulable resources (this list is not exhaustive, and other properties might be applicable as well):

5.3. New vCard Properties

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

5.3.1. Scheduling Related Properties

5.3.1.1. AUTOSCHEDULE

5.3.1.2. BOOKINGINFO

5.3.1.3. BOOKINGRESTRICTED

5.3.1.4. BOOKINGWINDOWSTART

5.3.1.5. BOOKINGWINDOWEND

5.3.1.6. MAXINSTANCES

5.3.1.7. MULTIBOOK

5.3.1.8. SCHEDADMIN

5.3.2. Other Properties

5.3.2.1. ACCESSIBLE

5.3.2.2. ACCESSIBILITYINFO

5.3.2.3. CAPACITY

5.3.2.4. INVENTORYLIST

5.3.2.5. INVENTORYURL

5.3.2.6. LOCATIONTYPE

5.3.2.7. RESOURCEMANAGER

5.3.2.8. RESOURCEOWNER

5.3.2.9. RESTRICTED

5.3.2.10. RESTRICTEDACCESSINFO

5.3.2.11. NOCOST

5.3.2.12. COSTINFO

6. Examples

6.1. Location Resource

6.2. Role Resources Group

7. Security Considerations

As this document only defines schema for representing resource information 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.

8. IANA Considerations

8.1. VCard Property and Value Registration

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

New VCard Properties Table:

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

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.

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, and specifically the following individuals for contributing their ideas and support: Arnaud Quillaud, Adam Lewenberg, Andrew Laurence, Guy Stalnaker, Mimi Mugler, Dave Thewlis, Bernard Desruisseaux, Alain Petit, Andrew Sciberras, and Jason Miller.

11. Unresolved Issues

Defining finer granularity of resource KIND - A schedulable resource might not exactly correspond to a specific one in the list of pre-defined values for KIND. Question is how to convey the additional information. Possibilities are extending KIND values to include all combinations, defining an objectclass model where an object is built out of many pre-defined KINDs, or defining standard parameter extensions to KIND to include more information.

Defining RESOURCETYPE - For a location resource, a new property LOCATIONTYPE was added to provide more information. Are similar new properties required for non-location resources? Or do we need a generic RESOURCETYPE property with a set of predefined values?

12. References

Authors' Addresses