idnits 2.17.1 draft-vcard-schedulable-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 ([REF]), 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 25, 2013) is 4109 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) == Missing Reference: 'REF' is mentioned on line 16, but not defined == Missing Reference: 'TODO' is mentioned on line 103, but not defined == Unused Reference: 'RFC2739' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC4589' is defined on line 481, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 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 29, 2013 Apple Inc. 6 M. Douglass 7 RPI 8 January 25, 2013 10 Schedulable Objectclass for vCard 11 draft-vcard-schedulable-00 13 Abstract 15 This specification describes a new property objectclass value for the 16 vcard objectclass property defined in [REF] allowing schedulable 17 entities to be marked as such. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 29, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Schedulable Objectclass Value . . . . . . . . . . . . . . . . 3 56 4. Current vCard Properties for use with 57 OBJECTCLASS:schedulable. . . . . . . . . . . . . . . . . . . . 3 58 4.1. CALADRURI . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. New vCard Properties for use with OBJECTCLASS:schedulable. . . 4 60 5.1. AUTOSCHEDULE . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.2. BOOKINGINFO . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.3. BOOKINGRESTRICTED . . . . . . . . . . . . . . . . . . . . 5 63 5.4. BOOKINGWINDOWSTART . . . . . . . . . . . . . . . . . . . . 6 64 5.5. BOOKINGWINDOWEND . . . . . . . . . . . . . . . . . . . . . 7 65 5.6. MAXINSTANCES . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.7. MULTIBOOK . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. New Parameter Values . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. RELATED TYPE Values . . . . . . . . . . . . . . . . . . . 9 69 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Schedulable . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. New VCard Objectclass Value Registration . . . . . . . . . 10 74 9.2. VCard Property and Value Registration . . . . . . . . . . 10 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 11. Recommendations for Calendaring Systems . . . . . . . . . . . 10 77 12. Normative References . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The schedulable object class defines a number of properties which are 82 required or useful for schedulable entities. 84 A schedulable entity may be scheduled for meetings (usually a person) 85 or for use (usually a resource). The properties specified here allow 86 a client to discover such an entity and initiate a scheduling 87 request. 89 Some of the properties and values may be used by calendar servers to 90 determine the appropriate action when a scheduling request is 91 received. For example, do we auto-accept the request if the entity 92 is available? 94 2. Conventions Used in This Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Schedulable Objectclass Value 102 This specification defines a new value for the OBJECTCLASS property 103 deined in [TODO]. The value is registered according to the procedure 104 in Section 10.2.6 of [RFC6350]. 106 Value: schedulable 108 Purpose: To specify the entity with this objectclass is schedulable. 110 Conformance This value MAY be used with the OBJECTCLASS property. 111 If used the properties, parameters and values of the vcard MUST 112 conform to the requirements of this specification. 114 Example: OBJECTCLASS:schedulable 116 4. Current vCard Properties for use with OBJECTCLASS:schedulable. 118 The following properties MUST be specified in a vCard representing a 119 calendaring or schedulable resource: 121 o FN 123 o UID 125 o KIND 126 o CALADRURI or EMAIL 128 4.1. CALADRURI 130 The CALADRURI value is the address that would be used by a Scheduling 131 and Calendaring application to schedule the resource. 133 Its value MUST be a uri string, in most cases a mailto: uri. The 134 EMAIL property value of the resource should be used for scheduling, 135 in the absence of this property. 137 5. New vCard Properties for use with OBJECTCLASS:schedulable. 139 The following new properties are defined for use with OBJECTCLASS: 140 schedulable. 142 Format and cardinality of new vCard properties are defined as 143 described in Section 3.3 of [RFC6350]. 145 5.1. AUTOSCHEDULE 147 Purpose: Specify if the resource is automatically scheduled with no 148 approval process. 150 ValueType: Text value from the auto schedule values table. 152 Cardinality: *1 154 ABNF: 156 AUTOSCHEDULE-param = "VALUE=text" / any-param 157 AUTOSCHEDULE-value = text 159 Default value: If the property is absent or unknown, resource 160 bookings are auto accepted, if it does not result in a booking 161 conflict and auto declined if it does. 163 Default value: AUTO 165 Example value: AUTO 166 Auto Schedule Values Table: 168 +-------------------+-----------------------------------------------+ 169 | Auto schedule | Scheduling action | 170 | value | | 171 +-------------------+-----------------------------------------------+ 172 | NONE | no auto scheduling | 173 | ACCEPT-IF-FREE | auto accept invitations, if no conflict | 174 | DECLINE-IF-BUSY | auto decline invitations that result in a | 175 | | conflict | 176 | AUTO | auto accept and auto decline based on booking | 177 | | conflict | 178 | ALWAYS-ACCEPT | auto accept all invitations | 179 | ALWAYS-DECLINE | auto decline all invitations | 180 +-------------------+-----------------------------------------------+ 182 5.2. BOOKINGINFO 184 Purpose: Provide the complete information on scheduling a resource 185 if access rights are set or approval is required. 187 ValueType: URI value. It MAY also be a free-form text value. 189 Cardinality: * 191 ABNF: 193 BOOKINGINFO-param = "VALUE=" ("text" / "uri") / 194 any-param 195 BOOKINGINFO-value = uri / text 197 Default value: None 199 Example value: http://www.example.com/room1_booking.html 201 5.3. BOOKINGRESTRICTED 203 Purpose: Specify if there are restrictions to booking the resource 204 specified by access rights in the system. More information is 205 provided by the BOOKINGINFO Section 5.2 property. 207 ValueType: Boolean value. 209 Cardinality: *1 210 ABNF: 212 BOOKINGRESTRICTED-param = "VALUE=boolean" / any-param 213 BOOKINGRESTRICTED-value = boolean 215 Default value: FALSE. 217 Absence of this property indicates no restriction to booking the 218 resource. 220 Example value: TRUE 222 5.4. BOOKINGWINDOWSTART 224 Purpose: Defines how much time in advance the resource can be 225 booked. 227 ValueType: Duration value. 229 The format is based on the [ISO.8601.2004] duration representation 230 basic format with designators for the duration of time. The 231 format can represent nominal durations (weeks and days) and 232 accurate durations (hours, minutes, and seconds). The syntax is 233 further defined in Appendix A, "Duration" section of [RFC3339]. 235 Cardinality: 236 *1 238 ABNF: 240 BOOKINGWINDOWSTART-param = "VALUE=text" / any-param 241 BOOKINGWINDOWSTART-value = text 243 Special Notes: The value of this property is used to calculate the 244 earliest date and time when a resource can be reserved for an 245 event starting on a specific date and time. 247 If this property value is defined, the resource may be booked for 248 an event at a certain time, only if the current time is equal to 249 or after the date and time calculated by subtracting this value 250 from the event's proposed start time. If this property is absent, 251 then the resource may be booked at any time before the end of the 252 booking window. 254 Default value: None 255 Example value: P3M 257 5.5. BOOKINGWINDOWEND 259 Purpose: Defines how much time in advance the resource booking is 260 closed. 262 ValueType: Duration value. 264 The format is based on the [ISO.8601.2004] duration representation 265 basic format with designators for the duration of time. The 266 format can represent nominal durations (weeks and days) and 267 accurate durations (hours, minutes, and seconds). The syntax is 268 further defined in Appendix A, "Duration" section of [RFC3339]. 270 Cardinality: *1 272 ABNF: 274 BOOKINGWINDOWEND-param = "VALUE=text" / any-param 275 BOOKINGWINDOWEND-value = text 277 Special Notes: 278 The value of this property is used to calculate the latest date 279 and time when a resource can be reserved for an event starting on 280 a specific date and time. 281 If the current time is equal to or before the value obtained by 282 subtracting BookingWindowEnd from the start date and time of the 283 event, then the resource may be booked. If this property is 284 absent, then the resource may be booked anytime from booking 285 window start to the start of the event. 286 BookingWindow Start and End together provide the window of time a 287 resource can be booked, relative to the start time of the event. 289 If: BookingWindowStart = BwS, 290 BookingWindowEnd = BwE, 291 Current Time = CT and 292 Event Start Time = ST, 293 Then a resource can be booked at a certain time only if 294 CT is equal to or after (ST - BwS) 295 and CT is equal to or before (ST - BwE) 297 Default value: 298 None 300 Example value: 301 P5D 303 5.6. MAXINSTANCES 305 Purpose: Maximum number of instances of an event, the resource can 306 be scheduled for from NOW. 308 ValueType: Integer value. 310 Cardinality: *1 312 ABNF: 314 MAXINSTANCES-param = "VALUE=integer" / any-param 315 MAXINSTANCES-value = integer 317 Special Notes: Value of 0 indicates no limits. Value of 1 indicates 318 that no recurring bookings are allowed. If this property is 319 absent there is no limit to the number of instances it may be 320 booked for at any moment. 322 Default value: 0 324 Example value: 60 326 5.7. MULTIBOOK 328 Purpose: Number of simultaneous bookings allowed. 330 ValueType: Integer value. 331 Value of 0 indicates no limits. 333 Cardinality: *1 335 ABNF: 337 MULTIBOOK-param = "VALUE=integer" / any-param 338 MULTIBOOK-value = integer 340 Special Notes: Value of 0 indicates no limits. If this property is 341 absent the resource may be booked only for one event at a 342 particular moment. 344 Default value: 1 345 Example value: 1 347 6. New Parameter Values 349 6.1. RELATED TYPE Values 351 This document specifies the following additional values that can be 352 used as the value for the TYPE parameter of the RELATED property 353 defined in Section 6.6.6 of [RFC6350]. 355 o schedule-admin: an entity that performs scheduling approval, when 356 scheduling the entity associated with this vCard, if approval 357 required. 359 7. Examples 361 7.1. Schedulable 363 A schedulable entity can be scheduled for meetings (as a person) or 364 for use (as a resource). For a scheduling system to be able to 365 usefully manage the schedule it needs specific information. 367 At the very least there MUST be some form of calendar user address. 368 It's useful to know whether requests can be auto accepted if the slot 369 is available. 371 BEGIN:VCARD 372 VERSION:4.0 373 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 374 FN:J. Doe 375 N:Doe;J.;;; 376 EMAIL:jdoe@example.edu 377 TEL;VALUE=uri:tel:+1-555-555-5555 378 OBJECTCLASS:schedulable 379 CALADRURI:jdoe@example.edu 380 AUTOSCHEDULE:ACCEPT-IF-FREE 381 END:VCARD 383 8. Security Considerations 385 As this document only defines schema for representing entities for 386 calendaring and scheduling and does not refer to the actual storage 387 mechanism itself, or the calendaring and scheduling protocol, no 388 special security considerations are required as part of this 389 document. 391 9. IANA Considerations 393 9.1. New VCard Objectclass Value Registration 395 A objectclass value is be defined according to the process specified 396 in Section 10.2.6 of [RFC6350]. 398 9.2. VCard Property and Value Registration 400 The following new VCard Properties need to be registered by IANA. 402 New VCard Properties Table: 404 +---------------------+---------------------------+ 405 | VCard Property Name | VCard Property Definition | 406 +---------------------+---------------------------+ 407 | AUTOSCHEDULE | Section 5.1 | 408 | BOOKINGINFO | Section 5.2 | 409 | BOOKINGRESTRICTED | Section 5.3 | 410 | BOOKINGWINDOWSTART | Section 5.4 | 411 | BOOKINGWINDOWEND | Section 5.5 | 412 | MAXINSTANCES | Section 5.6 | 413 | MULTIBOOK | Section 5.7 | 414 +---------------------+---------------------------+ 416 The following new VCard Parameter Values need to be registered by 417 IANA. 419 New VCard Properties Table: 421 +--------------------+--------------------+-------------------------+ 422 | VCard Property | VCard Parameter | VCard Parameter Value | 423 | Name | Name | | 424 +--------------------+--------------------+-------------------------+ 425 | RELATED | TYPE | schedule-admin | 426 | | | Section 6.1 | 427 +--------------------+--------------------+-------------------------+ 429 10. Acknowledgments 431 This specification is a result of discussions that took place within 432 the Calendaring and Scheduling Consortium's Resource Technical 433 Committee. The authors thank the participants of that group. 435 11. Recommendations for Calendaring Systems 437 While this document does not mandate how each of the defined property 438 values must be used by calendaring systems, here are some 439 recommendations: 441 1. BOOKINGWINDOWSTART (Section 5.4), BOOKINGWINDOWEND (Section 5.5) 442 and MULTIBOOK (Section 5.7) information should be used in 443 freebusy calculations. A query for a time slot that falls 444 outside the booking window or one that already has the maximum 445 allowed number of simultaneous bookings, MUST be returned as 446 BUSY_UNAVAILABLE. 448 2. Calendaring systems that support the AUTOSCHEDULE ()Section 5.1) 449 property, SHOULD automatically mark the attendee PARTSTAT for a 450 resource as ACCEPTED, if its auto schedule value is AUTO and the 451 scheduling is successful. If scheduling administrator approval 452 is required, the PARTSTAT could be automatically marked as 453 TENTATIVE. Rooms SHOULD have this property defined. 455 3. Information from other properties, for example the capacity if a 456 resource can be used by calendaring systems to warn end users if 457 the number of attendees exceed the capacity value. Rooms SHOULD 458 have CAPACITY defined. 460 Individual calendar servers may regard the values of these properties 461 set in a directory server or a different database as advisory and 462 could further limit what it allows. 464 12. Normative References 466 [ISO.8601.2004] International Organization for Standardization, 467 "Data elements and interchange formats -- 468 Information interchange -- Representation of dates 469 and times", 2004. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar 475 Attributes for vCard and LDAP", RFC 2739, 476 January 2000. 478 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 479 Internet: Timestamps", RFC 3339, July 2002. 481 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 482 Registry", RFC 4589, July 2006. 484 [RFC6350] Perreault, S., "vCard Format Specification", 485 RFC 6350, August 2011. 487 Authors' Addresses 489 Ciny Joy 490 Oracle Corporation 491 4210 Network Circle 492 Santa Clara, CA 95054 493 USA 495 EMail: ciny.joy@oracle.com 496 URI: http://www.oracle.com/ 498 Cyrus Daboo 499 Apple Inc. 500 1 Infinite Loop 501 Cupertino, CA 95014 502 USA 504 EMail: cyrus@daboo.name 505 URI: http://www.apple.com/ 507 Michael Douglass 508 Rensselaer Polytechnic Institute 509 110 8th Street 510 Troy, NY 12180 511 USA 513 EMail: douglm@rpi.edu 514 URI: http://www.rpi.edu/