idnits 2.17.1 draft-ietf-calext-extensions-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 draft header indicates that this document updates RFC5545, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2015) is 3308 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) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple Inc. 4 Updates: 5545 (if approved) April 6, 2015 5 Intended status: Standards Track 6 Expires: October 8, 2015 8 New Properties for iCalendar 9 draft-ietf-calext-extensions-00 11 Abstract 13 This document defines a set of new properties for iCalendar data as 14 well as extending the use of some existing properties to the entire 15 iCalendar object. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 8, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Backwards Compatible Extension Properties . . . . . . . . . . 3 54 4. Modifications to Calendar Components . . . . . . . . . . . . 3 55 5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. NAME Property . . . . . . . . . . . . . . . . . . . . . . 5 57 5.2. DESCRIPTION Property . . . . . . . . . . . . . . . . . . 6 58 5.3. UID Property . . . . . . . . . . . . . . . . . . . . . . 6 59 5.4. LAST-MODIFIED Property . . . . . . . . . . . . . . . . . 7 60 5.5. URL Property . . . . . . . . . . . . . . . . . . . . . . 7 61 5.6. CATEGORIES Property . . . . . . . . . . . . . . . . . . . 7 62 5.7. REFRESH-INTERVAL Property . . . . . . . . . . . . . . . . 7 63 5.8. SOURCE Property . . . . . . . . . . . . . . . . . . . . . 8 64 5.9. COLOR Property . . . . . . . . . . . . . . . . . . . . . 9 65 5.10. IMAGE Property . . . . . . . . . . . . . . . . . . . . . 10 66 5.11. CONFERENCE Property . . . . . . . . . . . . . . . . . . . 11 67 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. DISPLAY Property Parameter . . . . . . . . . . . . . . . 13 69 6.2. EMAIL Property Parameter . . . . . . . . . . . . . . . . 14 70 6.3. FEATURE Property Parameter . . . . . . . . . . . . . . . 15 71 6.4. LABEL Property Parameter . . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 8.1. Property Registrations . . . . . . . . . . . . . . . . . 17 75 8.2. Parameter Registrations . . . . . . . . . . . . . . . . . 17 76 8.3. Display Types Registry . . . . . . . . . . . . . . . . . 18 77 8.4. Feature Types Registry . . . . . . . . . . . . . . . . . 18 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 10.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. Change History (To be removed by RFC Editor before 83 publication) . . . . . . . . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 The iCalendar [RFC5545] data format is used to represent calendar 89 data and is used with iTIP [RFC5546] to handle scheduling operations 90 between calendar users. iCalendar is in widespread use, and in 91 accordance with provisions in that specification, extension elements 92 have been added by various vendors to the data format in order to 93 support and enhance capabilities. This specification collects a 94 number of these ad-hoc extensions and uses the new IANA registry 95 capability defined in [RFC5545] to register standard variants with 96 clearly defined definitions and semantics. In addition, some new 97 elements are introduced for features that vendors have recently been 98 requesting. 100 2. Conventions Used in This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 The notation used in this memo is the ABNF notation of [RFC5234] as 108 used by iCalendar [RFC5545]. Any syntax elements shown below that 109 are not explicitly defined in this specification come from iCalendar 110 [RFC5545]. 112 3. Backwards Compatible Extension Properties 114 iCalendar defines properties which can have different value types 115 indicated by a "VALUE" parameter. The definition of a property 116 specifies a "default" value type that is assumed to be used when no 117 "VALUE" parameter is present. However, this poses a problem to 118 iCalendar parser/generator software that does not know about the 119 default values for new properties. For example, if a new property 120 "FOO" were defined with a default value type of URI, and a URI value 121 with a comma was used, an iCalendar generator not aware of this fact 122 would likely treat the property value as "TEXT" and apply backslash 123 escaping to the comma in the value, effectively making it an invalid 124 URI value. 126 To avoid this problem, this specification recommends that all 127 properties not defined in [RFC5545], always include a "VALUE" 128 parameter, if the type is other than "TEXT". i.e., in the example 129 above, the "FOO" property would have a "VALUE=URI" parameter. This 130 allows iCalendar parser/generator software to track the correct types 131 of unknown properties. 133 New properties defined in this specification use the term "no 134 default" in the "Value Type" definition to indicate that the "VALUE" 135 parameter has to be included. 137 4. Modifications to Calendar Components 139 The following changes to the syntax defined in iCalendar [RFC5545] 140 are made here. New elements are defined in subsequent sections. 142 calprops /= *( 143 ; 144 ; The following are OPTIONAL, 145 ; but MUST NOT occur more than once. 146 ; 147 uid / last-mod / url / 148 refresh / source / color 149 ; 150 ; The following are OPTIONAL, 151 ; and MAY occur more than once. 152 ; 153 name / description / categories / 154 image 155 ; 156 ) 158 eventprop /= *( 159 ; 160 ; The following are OPTIONAL, 161 ; but MUST NOT occur more than once. 162 ; 163 color / 164 ; 165 ; The following are OPTIONAL, 166 ; and MAY occur more than once. 167 ; 168 image 169 ; 170 ) 172 todoprop /= *( 173 ; 174 ; The following are OPTIONAL, 175 ; but MUST NOT occur more than once. 176 ; 177 color / 178 ; 179 ; The following are OPTIONAL, 180 ; and MAY occur more than once. 181 ; 182 image 183 ; 184 ) 186 jourprop /= *( 187 ; 188 ; The following are OPTIONAL, 189 ; but MUST NOT occur more than once. 190 ; 191 color / 192 ; 193 ; The following are OPTIONAL, 194 ; and MAY occur more than once. 195 ; 196 image 197 ; 198 ) 200 5. Properties 202 5.1. NAME Property 204 Property Name: NAME 206 Purpose: This property specifies the name of the calendar. 208 Value Type: TEXT 210 Property Parameters: IANA, non-standard, alternate text 211 representation, and language property parameters can be specified 212 on this property. 214 Conformance: This property can be specified multiple times in an 215 iCalendar object. However, each property MUST represent the name 216 of the calendar in a different language. 218 Description: This property is used to specify a name of the 219 iCalendar object that can be used by calendar user agents when 220 presenting the calendar data to a user. Whilst a calendar only 221 has a single name, multiple language variants can be specified by 222 including this property multiple times with different "LANGUAGE" 223 parameter values on each. 225 Format Definition: This property is defined by the following 226 notation: 228 name = "NAME" nameparam ":" text CRLF 230 nameparam = *( 231 ; 232 ; The following are OPTIONAL, 233 ; but MUST NOT occur more than once. 234 ; 235 (";" altrepparam) / (";" languageparam) / 236 ; 237 ; The following is OPTIONAL, 238 ; and MAY occur more than once. 239 ; 240 (";" other-param) 241 ; 242 ) 244 Example: The following is an example of this property: 246 NAME:Company Vacation Days 248 5.2. DESCRIPTION Property 250 This specification modifies the definition of the "DESCRIPTION" 251 property to allow it to be defined on an iCalendar object. The 252 following additions are made to the definition of this property. 254 Purpose: This property specifies the description of the calendar. 256 Conformance: This property can be specified multiple times in an 257 iCalendar object. However, each property MUST represent the 258 description of the calendar in a different language. 260 Description: This property is used to specify a lengthy textual 261 description of the iCalendar object that can be used by calendar 262 user agents when describing the nature of the calendar data to a 263 user. Whilst a calendar only has a single description, multiple 264 language variants can be specified by including this property 265 multiple times with different "LANGUAGE" parameter values on each. 267 5.3. UID Property 269 This specification modifies the definition of the "UID" property to 270 allow it to be defined on an iCalendar object. The following 271 additions are made to the definition of this property. 273 Purpose: This property specifies the persistent, globally unique 274 identifier for the iCalendar object. This can be used, for 275 example, to identify duplicate calendar streams that a client may 276 have been given access to. It can be used in conjunction with the 277 "LAST-MODIFIED" property also specified on the "VCALENDAR" object, 278 to identify the most recent version of a calendar. 280 Conformance: This property can be specified once in an iCalendar 281 object. 283 5.4. LAST-MODIFIED Property 285 This specification modifies the definition of the "LAST-MODIFIED" 286 property to allow it to be defined on an iCalendar object. The 287 following additions are made to the definition of this property. 289 Purpose: This property specifies the date and time that the 290 information associated with the calendar was last revised. 292 Conformance: This property can be specified once in an iCalendar 293 object. 295 5.5. URL Property 297 This specification modifies the definition of the "URL" property to 298 allow it to be defined on an iCalendar object. The following 299 additions are made to the definition of this property. 301 Purpose: This property may be used to convey a location where a more 302 dynamic rendition of the calendar information can be found. 304 Conformance: This property can be specified once in an iCalendar 305 object. 307 5.6. CATEGORIES Property 309 This specification modifies the definition of the "CATEGORIES" 310 property to allow it to be defined on an iCalendar object. The 311 following additions are made to the definition of this property. 313 Purpose: This property defines the categories for an entire 314 calendar. 316 Conformance: This property can be specified multiple times in an 317 iCalendar object. 319 5.7. REFRESH-INTERVAL Property 321 Property Name: REFRESH-INTERVAL 322 Purpose: This property specifies a suggested minimum interval for 323 polling for changes of the calendar data from the original source 324 of that data. 326 Value Type: DURATION - no default 328 Property Parameters: IANA and non-standard property parameters can 329 be specified on this property. 331 Conformance: This property can be specified once in an iCalendar 332 object. 334 Description: This property specifies a positive duration that gives 335 a suggested minimum polling interval for checking for updates to 336 the calendar data. The value of this property SHOULD be used by 337 calendar user agents to limit the polling interval for calendar 338 data updates to the minimum interval specified. 340 Format Definition: This property is defined by the following 341 notation: 343 refresh = "REFRESH-INTERVAL" refreshparam 344 ":" dur-value CRLF 345 ;consisting of a positive duration of time. 347 refreshparam = *( 348 ; 349 ; The following is REQUIRED, 350 ; but MUST NOT occur more than once. 351 ; 352 (";" "VALUE" "=" "DURATION") / 353 ; 354 ; The following is OPTIONAL, 355 ; and MAY occur more than once. 356 ; 357 (";" other-param) 358 ; 359 ) 361 Example: The following is an example of this property: 363 REFRESH-INTERVAL;VALUE=DURATION:P1W 365 5.8. SOURCE Property 367 Property Name: SOURCE 368 Purpose: This property identified a URI where calendar data can be 369 refreshed from. 371 Value Type: URI - no default 373 Property Parameters: IANA and non-standard property parameters can 374 be specified on this property. 376 Conformance: This property can be specified once in an iCalendar 377 object. 379 Description: This property identifies a location where a client can 380 retrieve updated data for the calendar. Clients SHOULD honor any 381 specified "REFRESH-INTERVAL" value when periodically retrieving 382 data. 384 Format Definition: This property is defined by the following 385 notation: 387 source = "SOURCE" sourceparam ":" uri CRLF 389 sourceparam = *(";" other-param) 391 Example: The following is an example of this property: 393 SOURCE;VALUE=URI:http://example.com/holidays.ics 395 5.9. COLOR Property 397 Property Name: COLOR 399 Purpose: This property specifies a color used for displaying the 400 calendar, event, todo, or journal data. 402 Value Type: TEXT 404 Property Parameters: IANA and non-standard property parameters can 405 be specified on this property. 407 Conformance: This property can be specified once in an iCalendar 408 object, or "VEVENT", "VTODO", or "VJOURNAL" calendar components. 410 Description: This property specifies a color that clients MAY use 411 when presenting the relevant data to a user. Typically this would 412 appear as the "background" color of events or tasks. The value is 413 a case-insensitive color name taken from the CSS3 set of names, 414 defined in Section 4.3 of [W3C.REC-css3-color-20110607]. 416 Format Definition: This property is defined by the following 417 notation: 419 color = "COLOR" colorparam ":" text CRLF 420 ; Value is CSS3 color name 422 colorparam = *(";" other-param) 424 Example: The following is an example of this property: 426 COLOR:turquoise 428 5.10. IMAGE Property 430 Property Name: IMAGE 432 Purpose: This property specifies an image associated with the 433 calendar or a calendar component. 435 Value Type: URI or BINARY - no default. The value MUST refer to or 436 be data with a media type of "image". 438 Property Parameters: IANA, non-standard, display, inline encoding, 439 and value data type property parameters can be specified on this 440 property. The format type parameter can be specified on this 441 property and is RECOMMENDED for inline binary encoded content 442 information. 444 Conformance: This property can be specified multiple times in an 445 iCalendar object, or "VEVENT", "VTODO", or "VJOURNAL" calendar 446 components. 448 Description: This property specifies an image for an iCalendar 449 object or a calendar component via a uri or directly with inline 450 data that can be used by calendar user agents when presenting the 451 calendar data to a user. Multiple properties MAY be used to 452 specify alternative sets of images with, for example, varying 453 media subtypes, resolutions or sizes. When multiple properties 454 are present, calendar user agents SHOULD display only one of them, 455 picking one that provides the most appropriate image quality, or 456 display none. The "DISPLAY" parameter is used to indicate the 457 intended display mode for the image. The "ALTREP" parameter, 458 defined in [RFC5545], can be used to provide a "clickable" image 459 where the URI in the parameter value can be "launched" by a click 460 on the image in the calendar user agent. 462 Format Definition: This property is defined by the following 463 notation: 465 image = "IMAGE" imageparam ( ":" uri ) / 466 ( 467 ";" "ENCODING" "=" "BASE64" 468 ";" "VALUE" "=" "BINARY" 469 ":" binary 470 ) / 471 CRLF 473 imageparam = *( 474 ; 475 ; The following is REQUIRED, 476 ; but MUST NOT occur more than once. 477 ; 478 (";" "VALUE" "=" "URI") / 479 ; 480 ; The following is OPTIONAL for a URI value, 481 ; RECOMMENDED for a BINARY value, 482 ; and MUST NOT occur more than once. 483 ; 484 (";" fmttypeparam) / 485 ; 486 ; The following are OPTIONAL, 487 ; and MUST NOT occur more than once. 488 ; 489 (";" altrepparam) / (";" displayparam) / 490 ; 491 ; The following is OPTIONAL, 492 ; and MAY occur more than once. 493 ; 494 (";" other-param) 495 ; 496 ) 498 Example: The following is an example of this property: 500 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 501 ttp://example.com/images/party.png 503 5.11. CONFERENCE Property 505 Property Name: CONFERENCE 507 Purpose: This property specifies information for accessing a 508 conferencing system. 510 Value Type: URI - no default. 512 Property Parameters: IANA, non-standard, feature, and label property 513 parameters can be specified on this property. 515 Conformance: This property can be specified multiple times in a 516 "VEVENT" or "VTODO" calendar component. 518 Description: This property specifies information for accessing a 519 conferencing system for attendees of a meeting or task. This 520 might be a tel: URI [RFC3966] for a telephone-based conference 521 number dial-in (with access codes included), or it might be an 522 http: URI [RFC7230] for a web-based video chat, or a URI for an 523 instant messaging group chat room. If a specific URI for a 524 conferencing system is not available, a data: URI [RFC2397] 525 containing a text description can be used. 527 A conference system can be a bi-directional communication channel, 528 or a uni-directional "broadcast feed". 530 The "FEATURE" property parameter is used to describe the key 531 capabilities of the conference system to allow a client to choose 532 the ones that give the required level of interaction from a set of 533 multiple properties. 535 The "LABEL" property paramater is used to convey additional 536 details on the use of the URI. For example, the URIs or access 537 codes for the moderator and attendee of a teleconference system 538 could be different, and the "LABEL" property parameter could be 539 used to "tag" each "CONFERENCE" property to indicate which is 540 which. 542 Format Definition: This property is defined by the following 543 notation: 545 conference = "CONFERENCE" confparam ":" uri CRLF 547 confparam = *( 548 ; 549 ; The following is REQUIRED, 550 ; but MUST NOT occur more than once. 551 ; 552 (";" "VALUE" "=" "URI") / 553 ; 554 ; The following are OPTIONAL, 555 ; and MUST NOT occur more than once. 556 ; 557 (";" featureparam) / (";" labelparam) / 558 ; 559 ; The following is OPTIONAL, 560 ; and MAY occur more than once. 561 ; 562 (";" other-param) 563 ; 564 ) 566 Example: The following are examples of this property: 568 CONFERENCE;VALUE=URI;FEATURE=PHONE,MODERATOR; 569 LABEL=Moderator dial-in:tel:+1-412-555-0123,,,654321 570 CONFERENCE;VALUE=URI;FEATURE=PHONE; 571 LABEL=Attendee dial-in:tel:+1-412-555-0123,,,555123 572 CONFERENCE;VALUE=URI;FEATURE=PHONE; 573 LABEL=Attendee dial-in:tel:+1-888-555-0456,,,555123 574 CONFERENCE;VALUE=URI;FEATURE=CHAT; 575 LABEL=Chat room:xmpp:chat-123@conference.example.com 576 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO; 577 LABEL=Attendee dial-in:http://chat.example.com/audio?id=123456 579 6. Property Parameters 581 6.1. DISPLAY Property Parameter 583 Parameter Name: DISPLAY 585 Purpose: To specify different ways in which an image for a calendar 586 or component can be displayed. 588 Format Definition: This property parameter is defined by the 589 following notation: 591 displayparam = "DISPLAY" "=" displayval *("," displayval) 593 displayval = ("BADGE" / ; image inline with the title of the 594 ; event 595 "GRAPHIC" / ; a full image replacement for the event 596 ; itself 597 "FULLSIZE / ; an image that is used to enhance the 598 ; event 599 "THUMBNAIL / ; a smaller variant of "FULLSIZE" to be 600 ; used when space for the image is 601 ; constrained 602 x-name / ; Experimental type 603 iana-token) ; Other IANA registered type 604 ; 605 ; Default is BADGE 607 Description: This property parameter MAY be specified on "IMAGE" 608 properties. In the absence of this parameter, the value "BADGE" 609 MUST be used for the default behavior. The value determines how a 610 client ought to present an image supplied in iCalendar data to the 611 user. 613 Values for this parameter are registered with IANA as per 614 Section 8.3. New values can be added to this registry following 615 the procedure outlined in Section 8.2.1 of [RFC5545]. 617 Servers and clients MUST handle x-name and iana-token values they 618 don't recognize by not displaying any image at all. 620 Example: 622 IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL,;FMTTYPE=image/png:http://exa 623 mple.com/images/weather-cloudy.png 625 6.2. EMAIL Property Parameter 627 Parameter Name: EMAIL 629 Purpose: To specify an email address that is used to identify or 630 contact an organizer or attendee. 632 Format Definition: This property parameter is defined by the 633 following notation: 635 emailparam = "EMAIL" "=" param-value 637 Description: This property parameter MAY be specified on "ORGANIZER" 638 or "ATTENDEE" properties. This property can be used in situations 639 where the calendar user address value of "ORGANIZER" and 640 "ATTENDEE" properties is not likely to be an identifier that 641 recipients of scheduling messages could use to match the calendar 642 user with, for example, an address book entry. The value of this 643 property is an email address that can easily be matched by 644 recipients. Recipients can also use this value as an alternative 645 means of contacting the calendar user via email. If a recipient's 646 calendar user agent allows the recipient to save contact 647 information based on the "ORGANIZER" or "ATTENDEE" properties, 648 those calendar user agents SHOULD use any "EMAIL" property 649 parameter value for the email address of the contact over any 650 mailto: calendar user address specified as the value of the 651 property. Calendar user agents SHOULD NOT include an "EMAIL" 652 property parameter when its value matches the calendar user 653 address specified as the value of the property. 655 Example: 657 ATTENDEE;CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke 658 n-1234@example.com 660 6.3. FEATURE Property Parameter 662 Parameter Name: FEATURE 664 Purpose: To specify a feature or features of a conference or 665 broadcast system. 667 Format Definition: This property parameter is defined by the 668 following notation: 670 featureparam = "FEATURE" "=" featuretext *("," featuretext) 671 featuretext = ("AUDIO" / ; Audio capability 672 "CHAT" / ; Chat or instant messaging 673 "FEED" / ; Blog or Atom feed 674 "MODERATOR" / ; Moderator dial-in code 675 "PHONE" / ; Phone conference 676 "SCREEN" / ; Screen sharing 677 "VIDEO" / ; Video capability 678 x-name / ; Experimental type 679 iana-token) ; Other IANA registered type 681 Description: This property parameter MAY be specified on the 682 "CONFERENCE" property. Multiple values can be specified. The 683 "MODERATOR" value is used to indicate that the property value is 684 specific to the owner/initiator of the conference and contains a 685 URI that "activates" the system (e.g., a "moderator" access code 686 for a phone conference system that is different from the "regular" 687 access code). 689 Example: 691 CONFERENCE;VALUE=URI;FEATURE=AUDIO:rtsp://audio.example.com/ 692 event 693 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO:http://video-chat.exam 694 ple.com/;group-id=1234 696 6.4. LABEL Property Parameter 698 Parameter Name: LABEL 700 Purpose: To provide a human readable label. 702 Format Definition: This property parameter is defined by the 703 following notation: 705 infoparam = "LABEL" "=" param-value 707 Description: This property parameter MAY be specified on the 708 "CONFERENCE" property. It is anticipated that other extensions to 709 iCalendar will re-use this property parameter on new properties 710 that they define. As a result, clients SHOULD expect to find this 711 property parameter present on many different properties. It 712 provides a human readable label that can be presented to calendar 713 users to allow them to discriminate between properties which might 714 be similar, or provide additional information for properties that 715 are not self-describing. 717 Example: 719 CONFERENCE;VALUE=URI;FEATURE=VIDEO; 720 LABEL="Web video chat, access code=76543"; 721 :http://video-chat.example.com/;group-id=1234 723 7. Security Considerations 725 Several of the new properties or parameters defined by this 726 specification allow reference to "external" URIs. Care MUST be taken 727 when accessing data at external URIs as malicious content could be 728 present. In addition, access to those URIs could be tracked, leading 729 to loss of privacy. 731 The "CONFERENCE" property can include a "FEATURE" property parameter 732 with a "MODERATOR" value. In some cases the access code used by the 733 owner/initiator of a conference might be private to an individual and 734 clients and servers MUST ensure that such properties are not sent to 735 attendees of a scheduled component, or sharees of a shared component. 737 8. IANA Considerations 739 8.1. Property Registrations 741 This document defines the following new iCalendar properties to be 742 added to the registry defined in Section 8.2.3 of [RFC5545]: 744 +------------------+---------+--------------------------------------+ 745 | Property | Status | Reference | 746 +------------------+---------+--------------------------------------+ 747 | NAME | Current | RFCXXXX, Section 5.1 | 748 | DESCRIPTION | Current | RFC5545 Section 3.8.1.5, RFCXXXX, | 749 | | | Section 5.2 | 750 | UID | Current | RFC5545 Section 3.8.4.7, RFCXXXX, | 751 | | | Section 5.3 | 752 | LAST-MODIFIED | Current | RFC5545 Section 3.8.7.3, RFCXXXX, | 753 | | | Section 5.4 | 754 | URL | Current | RFC5545 Section 3.8.4.6, RFCXXXX, | 755 | | | Section 5.5 | 756 | CATEGORIES | Current | RFC5545 Section 3.8.1.2, RFCXXXX, | 757 | | | Section 5.6 | 758 | REFRESH-INTERVAL | Current | RFCXXXX, Section 5.7 | 759 | SOURCE | Current | RFCXXXX, Section 5.8 | 760 | COLOR | Current | RFCXXXX, Section 5.9 | 761 | IMAGE | Current | RFCXXXX, Section 5.10 | 762 | CONFERENCE | Current | RFCXXXX, Section 5.11 | 763 +------------------+---------+--------------------------------------+ 765 8.2. Parameter Registrations 767 This document defines the following new iCalendar property parameters 768 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 770 +--------------------+---------+----------------------+ 771 | Property Parameter | Status | Reference | 772 +--------------------+---------+----------------------+ 773 | DISPLAY | Current | RFCXXXX, Section 6.1 | 774 | EMAIL | Current | RFCXXXX, Section 6.2 | 775 | FEATURE | Current | RFCXXXX, Section 6.3 | 776 | LABEL | Current | RFCXXXX, Section 6.4 | 777 +--------------------+---------+----------------------+ 779 8.3. Display Types Registry 781 This document defines the following new iCalendar value registry as 782 per Section 8.2.6 of [RFC5545]: 784 +--------------+---------+----------------------+ 785 | Display Type | Status | Reference | 786 +--------------+---------+----------------------+ 787 | BADGE | Current | RFCXXXX, Section 6.1 | 788 | GRAPHIC | Current | RFCXXXX, Section 6.1 | 789 | FULLSIZE | Current | RFCXXXX, Section 6.1 | 790 | THUMBNAIL | Current | RFCXXXX, Section 6.1 | 791 +--------------+---------+----------------------+ 793 8.4. Feature Types Registry 795 This document defines the following new iCalendar value registry as 796 per Section 8.2.6 of [RFC5545]: 798 +--------------+---------+----------------------+ 799 | Feature Type | Status | Reference | 800 +--------------+---------+----------------------+ 801 | AUDIO | Current | RFCXXXX, Section 6.3 | 802 | CHAT | Current | RFCXXXX, Section 6.3 | 803 | FEED | Current | RFCXXXX, Section 6.3 | 804 | MODERATOR | Current | RFCXXXX, Section 6.3 | 805 | PHONE | Current | RFCXXXX, Section 6.3 | 806 | SCREEN | Current | RFCXXXX, Section 6.3 | 807 | VIDEO | Current | RFCXXXX, Section 6.3 | 808 +--------------+---------+----------------------+ 810 9. Acknowledgments 812 Thanks to the following for feedback: Bernard Desruisseaux, Mike 813 Douglass, Lucia Fedorova, Ken Murchison, Arnaud Quillaud, and Dave 814 Thewlis. This specification came about via discussions at the 815 Calendaring and Scheduling Consortium. 817 10. References 819 10.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 825 Specifications: ABNF", STD 68, RFC 5234, January 2008. 827 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 828 Core Object Specification (iCalendar)", RFC 5545, 829 September 2009. 831 [W3C.REC-css3-color-20110607] 832 Celik, T., Lilley, C., and D. Baron, "CSS Color Module 833 Level 3", World Wide Web Consortium Recommendation REC- 834 css3-color-20110607, June 2011, 835 . 837 10.2. Informative References 839 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 840 1998. 842 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 843 3966, December 2004. 845 [RFC5546] Daboo, C., "iCalendar Transport-Independent 846 Interoperability Protocol (iTIP)", RFC 5546, December 847 2009. 849 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 850 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 851 2014. 853 Appendix A. Change History (To be removed by RFC Editor before 854 publication) 856 Changes in draft-ietf-calext-extensions-00: 858 1. Document renamed after WG adoption. 860 2. Fixed tel: URI reference. 862 Changes in draft-daboo-icalendar-extensions-09: 864 1. Re-instated a trimmed down version of the CONFERENCE property 865 after serious interest expressed by implementors. 867 2. LABEL property used instead of INFO - appropriated from another 868 iCalendar draft. 870 Changes in draft-daboo-icalendar-extensions-08: 872 1. Trimmed down the display values to a minimal set. 874 Changes in draft-daboo-icalendar-extensions-07: 876 1. Removed ALTURI parameter - now use ALTREP. 878 2. Removed VALID property. 880 3. Removed TIMEZONE-ID property. 882 4. Added FULLSIZE and THUMBNAIL display values. 884 5. Added EMAIL property parameter. 886 6. Added LAST-MODIFIED property for use with VCALENDAR. 888 7. Added CATEGORIES property for use with VCALENDAR. 890 8. URL use now aligned with 5545. 892 9. Added SOURCE property. 894 10. COLOR now uses CSS3 values. 896 Changes in draft-daboo-icalendar-extensions-06: 898 1. Removed BROADCAST/CONFERENCE properties and related parameters. 900 Changes in draft-daboo-icalendar-extensions-05: 902 1. Added section with recommendation on handling extension 903 properties. 905 2. Added VALID property. 907 Changes in draft-daboo-icalendar-extensions-04: 909 1. TZID changed to new property TIMEZONE-ID. 911 2. Minor formal syntax changes. 913 Changes in draft-daboo-icalendar-extensions-03: 915 1. Dropped CALENDAR- prefix 917 2. DESCRIPTION, UID and TZID now based on existing RFC5545 918 properties 920 3. COLOR now on both the calendar and component level 922 4. IMAGE now on both the calendar and component level 923 5. Added FEATURE and REGION parameters to CONFERENCE property 925 6. Added ALTURI parameter to IMAGE property 927 7. Added FEED value to FEATURE parameter 929 8. Added BROADCAST property and clarified that CONFERENCE is for bi- 930 direction channels and BROADCAST is for uni-directional. 932 Changes in draft-daboo-icalendar-extensions-02: 934 1. Minor wording changes. 936 2. Interval is now described as the "minimum interval". 938 3. Added CONFERENCE property and INFO parameter. 940 Changes in draft-daboo-icalendar-extensions-01: 942 1. Fixed DISPLAY parameter handling of x- and iana tokens to state 943 that clients ignore the image if the token is not recognized. 945 2. Allow language variants for CALENDAR-NAME and CALENDAR- 946 DESCRIPTION. 948 3. Added registry for DISPLAY values. 950 Author's Address 952 Cyrus Daboo 953 Apple Inc. 954 1 Infinite Loop 955 Cupertino, CA 95014 956 USA 958 Email: cyrus@daboo.name 959 URI: http://www.apple.com/