Working Draft

CalConnect Standard

•
CC/WD 58013:2013
Objectclass property for vCard
TC VCARD
Ciny JoyAuthor
Oracle Corporation
Cyrus DabooAuthor
Apple Inc.
Michael DouglassAuthor
Spherical Cow Group
CalConnect Standard
Working Draft

Warning for Drafts

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.

© 2013 The Calendaring and Scheduling Consortium, Inc.

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

copyright@calconnect.org
www.calconnect.org





Abstract

This specification describes a new property for vCard Format Specification IETF RFC 6350 to allow the specification of objectclasses.


Introduction

The objectclass concept is used in ldap to allow the specification of a set of properties which describe a given type of object. For example, a schedulable entity SHOULD contain some form of contact and the absence of the AUTOSCHEDULE property implies certain defaults.

Furthermore the OBJECTCLASS property allows for simple searching for a particular class of entry. If we are trying to book a room for example, the query only needs to specify an OBJECTCLASS of schedulable and the type of entry (that is, a room).

Without the OBJECTCLASS property it may be hard to determine that a room is actually schedulable. The resence of an email address does not guarantee that an entity is schedulable. Current scheduling systems also work asynchronously. The user may create scheduling invitations only to learn later on that the scheduled entity is not going to reply.

An ldap objectclass may be of 3 kinds, structural, abstract and auxiliary. The vcard KIND property is equivalent to the structural objectclass in that a vcard can be of only one kind. The kind requires that certain properties be present and also defines defaults for absent properties.

The OBJECTCLASS property defined here is equivalent in many ways to the auxiliary objectclass in ldap. They are not related to each other in some hierarchy and may overlap in their use of properties.

Objectclass definitions can only specify properties which MUST, SHOULD or MAY be present. They cannot disallow the use of properties as these may be required by another objectclass.

Objectclass property for vCard

1.  Scope

This specification describes a new property for vCard Format Specification IETF RFC 6350 to allow the specification of objectclasses.

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

No terms and definitions are listed in this document.

4.  Conventions

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 IETF RFC 2119.

5.  Objectclass Property

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

Property name

OBJECTCLASS

Purpose

To specify the objectclass for this vcard.

ValueType

IANA value.

Cardinality

*

ABNF

OBJECTCLASS-param = any-param
OBJECTCLASS-value = text

Default value

None.

Example value

schedulable

Description

This property MAY be present 1 or more times. For each occurrence of the property the vcard MUST conform to the specification for that objectclass.

6.  Examples

These examples do not draw on any currently defined objectclass but are intended to indicate some uses. Properties used here may not be defined in any specification.

6.1.  Eduperson vcard

The eduperson ldap objectclass provides for a number of attributes considered useful for interaction between members of educational organizations. A corresponding vcard objectclass would allow for better mappping of ldap directories onto a vcard representation.

The 201203 specification of the LDAP objectclass for reference. Note that all attributes are MAY so would have a vcard cardinality of *1 or *.

( 1.3.6.1.4.1.5923.1.1.2
  NAME 'eduPerson'
    AUXILIARY
    MAY ( eduPersonAffiliation $
        eduPersonNickname $
        eduPersonOrgDN $
        eduPersonOrgUnitDN $
        eduPersonPrimaryAffiliation $
        eduPersonPrincipalName $
        eduPersonEntitlement $
        eduPersonPrimaryOrgUnitDN $
        eduPersonScopedAffiliation $
        eduPersonTargetedID $
        eduPersonAssurance)

A vcard mapping would, where possible use existing vcard properties. Where not possible new properties could be defined.

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:eduperson
NICKNAME:Jack
ORGDN: dc=example, dc=edu
AFFILIATION;TYPE=primary:faculty
AFFILIATION;TYPE=scoped:faculty@cs.example.edu
END:VCARD

6.2.  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 needs to be some form of calendar user address. It’s useful to know whether requests can be auto accepted if the slot is available.

Building on the previous example we’ll make Jack schedulable.

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:eduperson
NICKNAME:Jack
ORGDN: dc=example, dc=edu
AFFILIATION;TYPE=primary:faculty
AFFILIATION;TYPE=scoped:faculty@cs.example.edu
OBJECTCLASS:schedulable
CALADRURI:jdoe@example.edu
AUTOSCHEDULE:ACCEPT-IF-FREE
END:VCARD

7.  Security Considerations

As this document only defines a schema related property and does not refer to the actual storage mechanism itself, no special security considerations are required as part of this document.

8.  IANA Considerations

8.1.  New VCard Objectclass Value Registration

New objectclass values will be defined according to the process specified in IETF RFC 6350, Section 10.2.6.

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