idnits 2.17.1 draft-vcard-objectclass-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6350]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2013) is 4108 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2739' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC4589' is defined on line 230, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Joy 3 Internet-Draft Oracle 4 Intended status: Standards Track C. Daboo 5 Expires: July 28, 2013 Apple Inc. 6 M. Douglass 7 RPI 8 January 24, 2013 10 Objectclass property for vCard 11 draft-vcard-objectclass-00 13 Abstract 15 This specification describes a new property for vCard Format 16 Specification [RFC6350] to allow the specification of objectclasses. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 28, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 54 3. Objectclass Property . . . . . . . . . . . . . . . . . . . . . 3 55 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Eduperson vcard . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Schedulable . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. New VCard Objectclass Value Registration . . . . . . . . . 6 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The objectclass concept is used in ldap to allow the specification of 67 a set of properties which describe a given type of object. For 68 example, a schedulable entity MUST contain a calendar user address 69 and the absence of the AUTOSCHEDULE property implies certain 70 defaults. 72 An ldap objectclass may be of 3 kinds, structural, abstract and 73 auxiliary. The vcard KIND property is equivalent to the structural 74 objectclass in that a vcard can be of only one kind. The kind 75 requires that certain properties be present and also defines defaults 76 for absent properties. 78 The OBJECTCLASS property defined here is equivalent in many ways to 79 the auxiliary objectclass in ldap. They are not related to each 80 other in some hierarchy and may overlap in their use of properties. 82 Objectclass definitions can only specify properties which MUST, 83 SHOULD or MAY be present. They cannot disallow the use of properties 84 as these may be required by another objectclass. 86 2. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Objectclass Property 94 Format and cardinality of new vCard properties are defined as 95 described in Section 3.3 of [RFC6350]. 97 Property name: OBJECTCLASS 99 Purpose: To specify the objectclass for this vcard. 101 ValueType: IANA value. 103 Cardinality: * 105 ABNF: OBJECTCLASS-param = any-param 106 OBJECTCLASS-value = text 108 Default value: None. 110 Example value: schedulable 112 Description: This property MAY be present 1 or more times. For each 113 occurrence of the property the vcard MUST conform to the 114 specification for that objectclass. 116 4. Examples 118 These examples do not draw on any currently defined objectclass but 119 are intended to indicate some uses. Properties used here may not be 120 defined in any specification. 122 4.1. Eduperson vcard 124 The eduperson ldap objectclass provides for a number of attributes 125 considered useful for interaction between members of educational 126 organizations. A corresponding vcard objectclass would allow for 127 better mappping of ldap directories onto a vcard representation. 129 The 201203 specification of the LDAP objectclass for reference. Note 130 that all attributes are MAY so would have a vcard cardinality of *1 131 or *. 133 ( 1.3.6.1.4.1.5923.1.1.2 134 NAME 'eduPerson' 135 AUXILIARY 136 MAY ( eduPersonAffiliation $ 137 eduPersonNickname $ 138 eduPersonOrgDN $ 139 eduPersonOrgUnitDN $ 140 eduPersonPrimaryAffiliation $ 141 eduPersonPrincipalName $ 142 eduPersonEntitlement $ 143 eduPersonPrimaryOrgUnitDN $ 144 eduPersonScopedAffiliation $ 145 eduPersonTargetedID $ 146 eduPersonAssurance) 148 A vcard mapping would, where possible use existing vcard properties. 149 Where not possible new properties could be defined. 151 BEGIN:VCARD 152 VERSION:4.0 153 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 154 FN:J. Doe 155 N:Doe;J.;;; 156 EMAIL:jdoe@example.edu 157 TEL;VALUE=uri:tel:+1-555-555-5555 158 OBJECTCLASS:eduperson 159 NICKNAME:Jack 160 ORGDN: dc=example, dc=edu 161 AFFILIATION;TYPE=primary:faculty 162 AFFILIATION;TYPE=scoped:faculty@cs.example.edu 163 END:VCARD 165 4.2. Schedulable 167 A schedulable entity can be scheduled for meetings (as a person) or 168 for use (as a resource). For a scheduling system to be able to 169 usefully manage the schedule it needs specific information. 171 At the very least there needs to be some form of calendar user 172 address. It's useful to know whether requests can be auto accepted 173 if the slot is available. 175 Building on the previous example we'll make Jack schedulable. 177 BEGIN:VCARD 178 VERSION:4.0 179 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 180 FN:J. Doe 181 N:Doe;J.;;; 182 EMAIL:jdoe@example.edu 183 TEL;VALUE=uri:tel:+1-555-555-5555 184 OBJECTCLASS:eduperson 185 NICKNAME:Jack 186 ORGDN: dc=example, dc=edu 187 AFFILIATION;TYPE=primary:faculty 188 AFFILIATION;TYPE=scoped:faculty@cs.example.edu 189 OBJECTCLASS:schedulable 190 CALADRURI:jdoe@example.edu 191 AUTOSCHEDULE:ACCEPT-IF-FREE 192 END:VCARD 194 5. Security Considerations 196 As this document only defines a schema related property and does not 197 refer to the actual storage mechanism itself, no special security 198 considerations are required as part of this document. 200 6. IANA Considerations 202 6.1. New VCard Objectclass Value Registration 204 New objectclass values will be defined according to the process 205 specified in Section 10.2.6 of [RFC6350]. 207 7. Acknowledgments 209 This specification is a result of discussions that took place within 210 the Calendaring and Scheduling Consortium's Resource Technical 211 Committee. The authors thank the participants of that group. 213 8. Normative References 215 [ISO.8601.2004] International Organization for Standardization, 216 "Data elements and interchange formats -- 217 Information interchange -- Representation of dates 218 and times", 2004. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar 224 Attributes for vCard and LDAP", RFC 2739, 225 January 2000. 227 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 228 Internet: Timestamps", RFC 3339, July 2002. 230 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 231 Registry", RFC 4589, July 2006. 233 [RFC6350] Perreault, S., "vCard Format Specification", 234 RFC 6350, August 2011. 236 Authors' Addresses 238 Ciny Joy 239 Oracle Corporation 240 4210 Network Circle 241 Santa Clara, CA 95054 242 USA 244 EMail: ciny.joy@oracle.com 245 URI: http://www.oracle.com/ 247 Cyrus Daboo 248 Apple Inc. 249 1 Infinite Loop 250 Cupertino, CA 95014 251 USA 253 EMail: cyrus@daboo.name 254 URI: http://www.apple.com/ 256 Michael Douglass 257 Rensselaer Polytechnic Institute 258 110 8th Street 259 Troy, NY 12180 260 USA 262 EMail: douglm@rpi.edu 263 URI: http://www.rpi.edu/