This specification describes the vCard representation of resources.
© 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 the vCard representation of resources.
This document specifies the vCard representation of resources to ease their discovery by clients.
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
Data values MUST have valid representation for the specified value type with respect to escape characters, line folding, and so on.
A resource object definition SHOULD contain all information required to find the right resource. For this, it SHOULD contain all, or a set of properties described in
Properties required to contact the resource are not included in this specification. vCard properties defined in
The following properties MUST be specified in a vCard representing a resource:
FN
UID
KIND
Some of the possible values for the KIND property are “Location”, “Individual”, “Device”, or “Group”.
Location is used for any physical location resource such as room, building, etc.
Individual is used for a human resource such as driver, technician, etc.
Device is used for a computing device such as an appliance, a computer, or a network element.
Group is used to specify a group of resources with a specific skill set. For example: drivers, electricians, etc.
The following properties defined in
ADR
CATEGORIES
FBURL
FN
KIND
MEMBER
NOTE
NICKNAME
ORG
PHOTO
RELATED
TZ
UID
Format and cardinality of new vCard properties are defined as described in
Specify if the resource is accessible to physically disabled people.
Boolean value.
*1
FALSE.
TRUE
Specify special resource accessibility info for the physically disabled people.
URI value. It MAY also be a free-form text value.
*
None
Provide information on the capacity of the resource.
Integer.
*1
None
10
List other resources available as part of this resource.
Value MAY be a URI that could be a vCard. The vCard could be of the KIND group whose members point to the various inventory items.
Value MAY also be a free form text listing one or more inventory items.
*
None
Printer, Projector or
Provide more information on the type of a LOCATION resource.
Text. The value SHOULD be one of the values defined in RFC 4589.
*
None
office
Specify if there are restrictions to physically accessing the resource. For example locked doors, or other barriers.
Boolean value.
*1
FALSE.
Absence of this property indicates no restriction to physically accessing the resource.
TRUE
Specify extra information on physically accessing resources that have restrictions. For example where to pick up keys to a locked resource.
URI value. It MAY also be a free-form text value.
*
None
Specify if there is a cost associated with using the resource.
Boolean value.
*1
If this property is absent, it indicates that the resource may be booked free of cost.
TRUE
TRUE
Provide the URL pointing to complete pricing information for usage of the resource.
URI value. It MAY also be a free-form text value.
*
None
This document specifies the following additional values that can be used as the value for the TYPE parameter of the RELATED property defined in
container: an entity that contains the entity associated with this vCard. For example, the building that contains the room resource specified by the vCard.
manager: an entity that manages the resource entity associated with this vCard.
owner: an entity that owns the resource entity associated with this vCard.
In this example we make use of OBJECTCLASS:schedulable to make this a schedulable resource.
This example also makes use of OBJECTCLASS:schedulable to make this a schedulable resource.
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.
The following new VCard Properties need to be registered by IANA.
| VCard Property Name | VCard Property Definition |
|---|---|
| ACCESSIBLE | |
| ACCESSIBILITYINFO | |
| CAPACITY | |
| COSTINFO | |
| INVENTORY | |
| LOCATIONTYPE | |
| NOCOST | |
| RESTRICTED | |
| RESTRICTEDACCESSINFO |
The following new VCard Parameter Values need to be registered by IANA.
| VCard Property Name | VCard Parameter Name | VCard Parameter Value |
|---|---|---|
| RELATED | TYPE | container |
| RELATED | TYPE | manager |
| RELATED | TYPE | owner |
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, Adrian Apthorp, and Jason Miller.
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?
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]