idnits 2.17.1 draft-ietf-calext-extensions-04.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 (June 28, 2016) is 2849 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) June 28, 2016 5 Intended status: Standards Track 6 Expires: December 30, 2016 8 New Properties for iCalendar 9 draft-ietf-calext-extensions-04 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 December 30, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 8 63 5.8. SOURCE Property . . . . . . . . . . . . . . . . . . . . . 9 64 5.9. COLOR Property . . . . . . . . . . . . . . . . . . . . . 9 65 5.10. IMAGE Property . . . . . . . . . . . . . . . . . . . . . 10 66 5.11. CONFERENCE Property . . . . . . . . . . . . . . . . . . . 12 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. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. Property Registrations . . . . . . . . . . . . . . . . . 17 76 9.2. Parameter Registrations . . . . . . . . . . . . . . . . . 18 77 9.3. Display Types Registry . . . . . . . . . . . . . . . . . 18 78 9.4. Feature Types Registry . . . . . . . . . . . . . . . . . 19 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 11.2. Informative References . . . . . . . . . . . . . . . . . 20 83 Appendix A. Change History (To be removed by RFC Editor before 84 publication) . . . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 87 1. Introduction 89 The iCalendar [RFC5545] data format is used to represent calendar 90 data and is used with iTIP [RFC5546] to handle scheduling operations 91 between calendar users. iCalendar is in widespread use, and in 92 accordance with provisions in that specification, extension elements 93 have been added by various vendors to the data format in order to 94 support and enhance capabilities. This specification collects a 95 number of these ad-hoc extensions and uses the new IANA registry 96 capability defined in [RFC5545] to register standard variants with 97 clearly defined definitions and semantics. In addition, some new 98 elements are introduced for features that vendors have recently been 99 requesting. 101 2. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 The notation used in this memo is the ABNF notation of [RFC5234] as 109 used by iCalendar [RFC5545]. Any syntax elements shown below that 110 are not explicitly defined in this specification come from iCalendar 111 [RFC5545]. 113 3. Backwards Compatible Extension Properties 115 iCalendar defines properties which can have different value types 116 indicated by a "VALUE" parameter. The definition of a property 117 specifies a "default" value type that is assumed to be used when no 118 "VALUE" parameter is present. However, this poses a problem to 119 iCalendar parser/generator software that does not know about the 120 default values for new properties. For example, if a new property 121 "FOO" were defined with a default value type of URI, and a URI value 122 with a comma was used, an iCalendar generator not aware of this fact 123 would likely treat the property value as "TEXT" and apply backslash 124 escaping to the comma in the value, effectively making it an invalid 125 URI value. 127 To avoid this problem, this specification recommends that all 128 properties not defined in [RFC5545], always include a "VALUE" 129 parameter, if the type is other than "TEXT". i.e., in the example 130 above, the "FOO" property would have a "VALUE=URI" parameter. This 131 allows iCalendar parser/generator software to track the correct types 132 of unknown properties. 134 New properties defined in this specification use the term "no 135 default" in the "Value Type" definition to indicate that the "VALUE" 136 parameter has to be included. 138 4. Modifications to Calendar Components 140 The following changes to the syntax defined in iCalendar [RFC5545] 141 are made here. New elements are defined in subsequent sections. 143 calprops =/ *( 144 ; 145 ; The following are OPTIONAL, 146 ; but MUST NOT occur more than once. 147 ; 148 uid / last-mod / url / 149 refresh / source / color 150 ; 151 ; The following are OPTIONAL, 152 ; and MAY occur more than once. 153 ; 154 name / description / categories / 155 image 156 ; 157 ) 159 eventprop =/ *( 160 ; 161 ; The following are OPTIONAL, 162 ; but MUST NOT occur more than once. 163 ; 164 color / 165 ; 166 ; The following are OPTIONAL, 167 ; and MAY occur more than once. 168 ; 169 conference / image 170 ; 171 ) 173 todoprop =/ *( 174 ; 175 ; The following are OPTIONAL, 176 ; but MUST NOT occur more than once. 177 ; 178 color / 179 ; 180 ; The following are OPTIONAL, 181 ; and MAY occur more than once. 182 ; 183 conference / image 184 ; 185 ) 187 jourprop =/ *( 188 ; 189 ; The following are OPTIONAL, 190 ; but MUST NOT occur more than once. 191 ; 192 color / 193 ; 194 ; The following are OPTIONAL, 195 ; and MAY occur more than once. 196 ; 197 conference / image 198 ; 199 ) 201 5. Properties 203 5.1. NAME Property 205 Property Name: NAME 207 Purpose: This property specifies the name of the calendar. 209 Value Type: TEXT 211 Property Parameters: IANA, non-standard, alternate text 212 representation, and language property parameters can be specified 213 on this property. 215 Conformance: This property can be specified multiple times in an 216 iCalendar object. However, each property MUST represent the name 217 of the calendar in a different language. 219 Description: This property is used to specify a name of the 220 iCalendar object that can be used by calendar user agents when 221 presenting the calendar data to a user. Whilst a calendar only 222 has a single name, multiple language variants can be specified by 223 including this property multiple times with different "LANGUAGE" 224 parameter values on each. 226 Format Definition: This property is defined by the following 227 notation: 229 name = "NAME" nameparam ":" text CRLF 231 nameparam = *( 232 ; 233 ; The following are OPTIONAL, 234 ; but MUST NOT occur more than once. 235 ; 236 (";" altrepparam) / (";" languageparam) / 237 ; 238 ; The following is OPTIONAL, 239 ; and MAY occur more than once. 240 ; 241 (";" other-param) 242 ; 243 ) 245 Example: The following is an example of this property: 247 NAME:Company Vacation Days 249 5.2. DESCRIPTION Property 251 This specification modifies the definition of the "DESCRIPTION" 252 property to allow it to be defined on an iCalendar object. The 253 following additions are made to the definition of this property, 254 originally specified in Section 3.8.1.5 of [RFC5545]. 256 Purpose: This property specifies the description of the calendar. 258 Conformance: This property can be specified multiple times in an 259 iCalendar object. However, each property MUST represent the 260 description of the calendar in a different language. 262 Description: This property is used to specify a lengthy textual 263 description of the iCalendar object that can be used by calendar 264 user agents when describing the nature of the calendar data to a 265 user. Whilst a calendar only has a single description, multiple 266 language variants can be specified by including this property 267 multiple times with different "LANGUAGE" parameter values on each. 269 5.3. UID Property 271 This specification modifies the definition of the "UID" property to 272 allow it to be defined on an iCalendar object. The following 273 additions are made to the definition of this property, originally 274 specified in Section 3.8.4.7 of [RFC5545]. 276 Purpose: This property specifies the persistent, globally unique 277 identifier for the iCalendar object. This can be used, for 278 example, to identify duplicate calendar streams that a client may 279 have been given access to. It can be used in conjunction with the 280 "LAST-MODIFIED" property also specified on the "VCALENDAR" object, 281 to identify the most recent version of a calendar. 283 Conformance: This property can be specified once in an iCalendar 284 object. 286 5.4. LAST-MODIFIED Property 288 This specification modifies the definition of the "LAST-MODIFIED" 289 property to allow it to be defined on an iCalendar object. The 290 following additions are made to the definition of this property, 291 originally specified in Section 3.8.7.3 of [RFC5545]. 293 Purpose: This property specifies the date and time that the 294 information associated with the calendar was last revised. 296 Conformance: This property can be specified once in an iCalendar 297 object. 299 5.5. URL Property 301 This specification modifies the definition of the "URL" property to 302 allow it to be defined on an iCalendar object. The following 303 additions are made to the definition of this property, originally 304 specified in Section 3.8.4.6 of [RFC5545]. 306 Purpose: This property may be used to convey a location where a more 307 dynamic rendition of the calendar information can be found. 309 Conformance: This property can be specified once in an iCalendar 310 object. 312 5.6. CATEGORIES Property 314 This specification modifies the definition of the "CATEGORIES" 315 property to allow it to be defined on an iCalendar object. The 316 following additions are made to the definition of this property, 317 originally specified in Section 3.8.1.2 of [RFC5545]. 319 Purpose: This property defines the categories for an entire 320 calendar. 322 Conformance: This property can be specified multiple times in an 323 iCalendar object. 325 Description: When multiple properties are present, the set of 326 categories that apply to the iCalendar object are the union of all 327 the categories listed in each property value. 329 5.7. REFRESH-INTERVAL Property 331 Property Name: REFRESH-INTERVAL 333 Purpose: This property specifies a suggested minimum interval for 334 polling for changes of the calendar data from the original source 335 of that data. 337 Value Type: DURATION - no default 339 Property Parameters: IANA and non-standard property parameters can 340 be specified on this property. 342 Conformance: This property can be specified once in an iCalendar 343 object. 345 Description: This property specifies a positive duration that gives 346 a suggested minimum polling interval for checking for updates to 347 the calendar data. The value of this property SHOULD be used by 348 calendar user agents to limit the polling interval for calendar 349 data updates to the minimum interval specified. 351 Format Definition: This property is defined by the following 352 notation: 354 refresh = "REFRESH-INTERVAL" refreshparam 355 ":" dur-value CRLF 356 ;consisting of a positive duration of time. 358 refreshparam = *( 359 ; 360 ; The following is REQUIRED, 361 ; but MUST NOT occur more than once. 362 ; 363 (";" "VALUE" "=" "DURATION") / 364 ; 365 ; The following is OPTIONAL, 366 ; and MAY occur more than once. 367 ; 368 (";" other-param) 369 ; 370 ) 372 Example: The following is an example of this property: 374 REFRESH-INTERVAL;VALUE=DURATION:P1W 376 5.8. SOURCE Property 378 Property Name: SOURCE 380 Purpose: This property identified a URI where calendar data can be 381 refreshed from. 383 Value Type: URI - no default 385 Property Parameters: IANA and non-standard property parameters can 386 be specified on this property. 388 Conformance: This property can be specified once in an iCalendar 389 object. 391 Description: This property identifies a location where a client can 392 retrieve updated data for the calendar. Clients SHOULD honor any 393 specified "REFRESH-INTERVAL" value when periodically retrieving 394 data. Note that this property differs from the "URL" property in 395 that "URL" is meant to provide an alternative representation of 396 the calendar data, rather than the original location of the data. 398 Format Definition: This property is defined by the following 399 notation: 401 source = "SOURCE" sourceparam ":" uri CRLF 403 sourceparam = *(";" other-param) 405 Example: The following is an example of this property: 407 SOURCE;VALUE=URI:https://example.com/holidays.ics 409 5.9. COLOR Property 411 Property Name: COLOR 413 Purpose: This property specifies a color used for displaying the 414 calendar, event, todo, or journal data. 416 Value Type: TEXT 418 Property Parameters: IANA and non-standard property parameters can 419 be specified on this property. 421 Conformance: This property can be specified once in an iCalendar 422 object, or "VEVENT", "VTODO", or "VJOURNAL" calendar components. 424 Description: This property specifies a color that clients MAY use 425 when presenting the relevant data to a user. Typically this would 426 appear as the "background" color of events or tasks. The value is 427 a case-insensitive color name taken from the CSS3 set of names, 428 defined in Section 4.3 of [W3C.REC-css3-color-20110607]. 430 Format Definition: This property is defined by the following 431 notation: 433 color = "COLOR" colorparam ":" text CRLF 434 ; Value is CSS3 color name 436 colorparam = *(";" other-param) 438 Example: The following is an example of this property: 440 COLOR:turquoise 442 5.10. IMAGE Property 444 Property Name: IMAGE 446 Purpose: This property specifies an image associated with the 447 calendar or a calendar component. 449 Value Type: URI or BINARY - no default. The value MUST refer to or 450 be data with a media type of "image". 452 Property Parameters: IANA, non-standard, display, inline encoding, 453 and value data type property parameters can be specified on this 454 property. The format type parameter can be specified on this 455 property and is RECOMMENDED for inline binary encoded content 456 information. 458 Conformance: This property can be specified multiple times in an 459 iCalendar object, or "VEVENT", "VTODO", or "VJOURNAL" calendar 460 components. 462 Description: This property specifies an image for an iCalendar 463 object or a calendar component via a uri or directly with inline 464 data that can be used by calendar user agents when presenting the 465 calendar data to a user. Multiple properties MAY be used to 466 specify alternative sets of images with, for example, varying 467 media subtypes, resolutions or sizes. When multiple properties 468 are present, calendar user agents SHOULD display only one of them, 469 picking one that provides the most appropriate image quality, or 470 display none. The "DISPLAY" parameter is used to indicate the 471 intended display mode for the image. The "ALTREP" parameter, 472 defined in [RFC5545], can be used to provide a "clickable" image 473 where the URI in the parameter value can be "launched" by a click 474 on the image in the calendar user agent. 476 Format Definition: This property is defined by the following 477 notation: 479 image = "IMAGE" imageparam 480 ( 481 ( 482 ";" "VALUE" "=" "URI" 483 ":" uri 484 ) / 485 ( 486 ";" "ENCODING" "=" "BASE64" 487 ";" "VALUE" "=" "BINARY" 488 ":" binary 489 ) 490 ) 491 CRLF 493 imageparam = *( 494 ; 495 ; The following is OPTIONAL for a URI value, 496 ; RECOMMENDED for a BINARY value, 497 ; and MUST NOT occur more than once. 498 ; 499 (";" fmttypeparam) / 500 ; 501 ; The following are OPTIONAL, 502 ; and MUST NOT occur more than once. 503 ; 504 (";" altrepparam) / (";" displayparam) / 505 ; 506 ; The following is OPTIONAL, 507 ; and MAY occur more than once. 508 ; 509 (";" other-param) 510 ; 511 ) 513 Example: The following is an example of this property: 515 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 516 ttp://example.com/images/party.png 518 5.11. CONFERENCE Property 520 Property Name: CONFERENCE 522 Purpose: This property specifies information for accessing a 523 conferencing system. 525 Value Type: URI - no default. 527 Property Parameters: IANA, non-standard, feature, and label property 528 parameters can be specified on this property. 530 Conformance: This property can be specified multiple times in a 531 "VEVENT" or "VTODO" calendar component. 533 Description: This property specifies information for accessing a 534 conferencing system for attendees of a meeting or task. This 535 might be a tel: URI [RFC3966] for a telephone-based conference 536 number dial-in (with access codes included), or it might be an 537 http: or https: URI [RFC7230] for a web-based video chat, or a URI 538 for an instant messaging group chat room. If a specific URI for a 539 conferencing system is not available, a data: URI [RFC2397] 540 containing a text description can be used. 542 A conference system can be a bi-directional communication channel, 543 or a uni-directional "broadcast feed". 545 The "FEATURE" property parameter is used to describe the key 546 capabilities of the conference system to allow a client to choose 547 the ones that give the required level of interaction from a set of 548 multiple properties. 550 The "LABEL" property paramater is used to convey additional 551 details on the use of the URI. For example, the URIs or access 552 codes for the moderator and attendee of a teleconference system 553 could be different, and the "LABEL" property parameter could be 554 used to "tag" each "CONFERENCE" property to indicate which is 555 which. 557 Format Definition: This property is defined by the following 558 notation: 560 conference = "CONFERENCE" confparam ":" uri CRLF 562 confparam = *( 563 ; 564 ; The following is REQUIRED, 565 ; but MUST NOT occur more than once. 566 ; 567 (";" "VALUE" "=" "URI") / 568 ; 569 ; The following are OPTIONAL, 570 ; and MUST NOT occur more than once. 571 ; 572 (";" featureparam) / (";" labelparam) / 573 ; 574 ; The following is OPTIONAL, 575 ; and MAY occur more than once. 576 ; 577 (";" other-param) 578 ; 579 ) 581 Example: The following are examples of this property: 583 CONFERENCE;VALUE=URI;FEATURE=PHONE,MODERATOR; 584 LABEL=Moderator dial-in:tel:+1-412-555-0123,,,654321 585 CONFERENCE;VALUE=URI;FEATURE=PHONE; 586 LABEL=Attendee dial-in:tel:+1-412-555-0123,,,555123 587 CONFERENCE;VALUE=URI;FEATURE=PHONE; 588 LABEL=Attendee dial-in:tel:+1-888-555-0456,,,555123 589 CONFERENCE;VALUE=URI;FEATURE=CHAT; 590 LABEL=Chat room:xmpp:chat-123@conference.example.com 591 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO; 592 LABEL=Attendee dial-in:https://chat.example.com/audio?id=123456 594 6. Property Parameters 596 6.1. DISPLAY Property Parameter 598 Parameter Name: DISPLAY 600 Purpose: To specify different ways in which an image for a calendar 601 or component can be displayed. 603 Format Definition: This property parameter is defined by the 604 following notation: 606 displayparam = "DISPLAY" "=" displayval *("," displayval) 608 displayval = ("BADGE" / ; image inline with the title of the 609 ; event 610 "GRAPHIC" / ; a full image replacement for the event 611 ; itself 612 "FULLSIZE" / ; an image that is used to enhance the 613 ; event 614 "THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be 615 ; used when space for the image is 616 ; constrained 617 x-name / ; Experimental type 618 iana-token) ; Other IANA registered type 619 ; 620 ; Default is BADGE 622 Description: This property parameter MAY be specified on "IMAGE" 623 properties. In the absence of this parameter, the value "BADGE" 624 MUST be used for the default behavior. The value determines how a 625 client ought to present an image supplied in iCalendar data to the 626 user. 628 Values for this parameter are registered with IANA as per 629 Section 9.3. New values can be added to this registry following 630 the procedure outlined in Section 8.2.1 of [RFC5545]. 632 Servers and clients MUST handle x-name and iana-token values they 633 don't recognize by not displaying any image at all. 635 Example: 637 IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL;FMTTYPE=image/png:https://exa 638 mple.com/images/weather-cloudy.png 640 6.2. EMAIL Property Parameter 642 Parameter Name: EMAIL 644 Purpose: To specify an email address that is used to identify or 645 contact an organizer or attendee. 647 Format Definition: This property parameter is defined by the 648 following notation: 650 emailparam = "EMAIL" "=" param-value 652 Description: This property parameter MAY be specified on "ORGANIZER" 653 or "ATTENDEE" properties. This property can be used in situations 654 where the calendar user address value of "ORGANIZER" and 655 "ATTENDEE" properties is not likely to be an identifier that 656 recipients of scheduling messages could use to match the calendar 657 user with, for example, an address book entry. The value of this 658 property is an email address that can easily be matched by 659 recipients. Recipients can also use this value as an alternative 660 means of contacting the calendar user via email. If a recipient's 661 calendar user agent allows the recipient to save contact 662 information based on the "ORGANIZER" or "ATTENDEE" properties, 663 those calendar user agents SHOULD use any "EMAIL" property 664 parameter value for the email address of the contact over any 665 mailto: calendar user address specified as the value of the 666 property. Calendar user agents SHOULD NOT include an "EMAIL" 667 property parameter when its value matches the calendar user 668 address specified as the value of the property. 670 Example: 672 ATTENDEE;CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke 673 n-1234@example.com 675 6.3. FEATURE Property Parameter 677 Parameter Name: FEATURE 679 Purpose: To specify a feature or features of a conference or 680 broadcast system. 682 Format Definition: This property parameter is defined by the 683 following notation: 685 featureparam = "FEATURE" "=" featuretext *("," featuretext) 686 featuretext = ("AUDIO" / ; Audio capability 687 "CHAT" / ; Chat or instant messaging 688 "FEED" / ; Blog or Atom feed 689 "MODERATOR" / ; Moderator dial-in code 690 "PHONE" / ; Phone conference 691 "SCREEN" / ; Screen sharing 692 "VIDEO" / ; Video capability 693 x-name / ; Experimental type 694 iana-token) ; Other IANA registered type 696 Description: This property parameter MAY be specified on the 697 "CONFERENCE" property. Multiple values can be specified. The 698 "MODERATOR" value is used to indicate that the property value is 699 specific to the owner/initiator of the conference and contains a 700 URI that "activates" the system (e.g., a "moderator" access code 701 for a phone conference system that is different from the "regular" 702 access code). 704 Example: 706 CONFERENCE;VALUE=URI;FEATURE=AUDIO:rtsp://audio.example.com/ 707 event 708 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO:https://video-chat.exam 709 ple.com/;group-id=1234 711 6.4. LABEL Property Parameter 713 Parameter Name: LABEL 715 Purpose: To provide a human readable label. 717 Format Definition: This property parameter is defined by the 718 following notation: 720 labelparam = "LABEL" "=" param-value 722 Description: This property parameter MAY be specified on the 723 "CONFERENCE" property. It is anticipated that other extensions to 724 iCalendar will re-use this property parameter on new properties 725 that they define. As a result, clients SHOULD expect to find this 726 property parameter present on many different properties. It 727 provides a human readable label that can be presented to calendar 728 users to allow them to discriminate between properties which might 729 be similar, or provide additional information for properties that 730 are not self-describing. 732 Example: 734 CONFERENCE;VALUE=URI;FEATURE=VIDEO; 735 LABEL="Web video chat, access code=76543"; 736 :https://video-chat.example.com/;group-id=1234 738 7. Security Considerations 740 Several of the new properties or parameters defined by this 741 specification allow reference to "external" URIs. Care MUST be taken 742 when accessing data at external URIs as malicious content could be 743 present. Clients SHOULD ensure that suitable permission is granted 744 by calendar users before such URIs are dereferenced. 746 The "REFRESH-INTERVAL" property could be used by an attacker to make 747 a client carry out rapid requests to the server hosting the calendar, 748 by specifying a very short duration (e.g., one second). This could 749 lead to resource consumption on the client or server, and denial-of- 750 service attacks against the server. Clients MUST ensure that they 751 throttle requests to the server to a reasonable rate. In most cases, 752 updating a public calendar once per day would suffice. If the 753 "REFRESH-INTERVAL" is any less than that, clients SHOULD warn the 754 calendar user and allow them to override it with a longer value. 756 The "CONFERENCE" property can include a "FEATURE" property parameter 757 with a "MODERATOR" value. In some cases the access code used by the 758 owner/initiator of a conference might be private to an individual and 759 clients and servers MUST ensure that such properties are not sent to 760 attendees of a scheduled component, or sharees of a shared component. 762 Both the "COLOR" and "IMAGE" properties are likely to be used by 763 calendar users to express their own personal view of the calendar 764 data. In addition, these properties could be used by attackers to 765 produce a confusing display in a calendar user agent. When such 766 properties are encountered in calendar data that has come from other 767 calendar users (e.g., via a scheduling message, "public" calendar 768 subscription, shared calendar etc), it is advisable for the client to 769 give the receiving calendar user the option to remove (or adjust) 770 these properties as the data is imported into their calendar system. 772 Security considerations in [RFC5545], and [RFC5546] MUST also be 773 adhered to. 775 8. Privacy Considerations 777 Several of the new properties or parameters defined by this 778 specification allow reference to "external" URIs. Access to those 779 URIs could be tracked, leading to loss of privacy. Clients SHOULD 780 ensure that suitable permission is granted by calendar users before 781 such URIs are dereferenced. 783 Privacy considerations in [RFC5545], and [RFC5546] MUST also be 784 adhered to. 786 9. IANA Considerations 788 9.1. Property Registrations 790 This document defines the following new iCalendar properties to be 791 added to the registry defined in Section 8.3.2 of [RFC5545]: 793 +------------------+---------+--------------------------------------+ 794 | Property | Status | Reference | 795 +------------------+---------+--------------------------------------+ 796 | NAME | Current | RFCXXXX, Section 5.1 | 797 | DESCRIPTION | Current | RFC5545 Section 3.8.1.5, RFCXXXX, | 798 | | | Section 5.2 | 799 | UID | Current | RFC5545 Section 3.8.4.7, RFCXXXX, | 800 | | | Section 5.3 | 801 | LAST-MODIFIED | Current | RFC5545 Section 3.8.7.3, RFCXXXX, | 802 | | | Section 5.4 | 803 | URL | Current | RFC5545 Section 3.8.4.6, RFCXXXX, | 804 | | | Section 5.5 | 805 | CATEGORIES | Current | RFC5545 Section 3.8.1.2, RFCXXXX, | 806 | | | Section 5.6 | 807 | REFRESH-INTERVAL | Current | RFCXXXX, Section 5.7 | 808 | SOURCE | Current | RFCXXXX, Section 5.8 | 809 | COLOR | Current | RFCXXXX, Section 5.9 | 810 | IMAGE | Current | RFCXXXX, Section 5.10 | 811 | CONFERENCE | Current | RFCXXXX, Section 5.11 | 812 +------------------+---------+--------------------------------------+ 814 9.2. Parameter Registrations 816 This document defines the following new iCalendar property parameters 817 to be added to the registry defined in Section 8.3.3 of [RFC5545]: 819 +--------------------+---------+----------------------+ 820 | Property Parameter | Status | Reference | 821 +--------------------+---------+----------------------+ 822 | DISPLAY | Current | RFCXXXX, Section 6.1 | 823 | EMAIL | Current | RFCXXXX, Section 6.2 | 824 | FEATURE | Current | RFCXXXX, Section 6.3 | 825 | LABEL | Current | RFCXXXX, Section 6.4 | 826 +--------------------+---------+----------------------+ 828 9.3. Display Types Registry 830 This document defines the following new iCalendar value registry as 831 per Section 8.2.6 of [RFC5545]: 833 +--------------+---------+----------------------+ 834 | Display Type | Status | Reference | 835 +--------------+---------+----------------------+ 836 | BADGE | Current | RFCXXXX, Section 6.1 | 837 | GRAPHIC | Current | RFCXXXX, Section 6.1 | 838 | FULLSIZE | Current | RFCXXXX, Section 6.1 | 839 | THUMBNAIL | Current | RFCXXXX, Section 6.1 | 840 +--------------+---------+----------------------+ 842 9.4. Feature Types Registry 844 This document defines the following new iCalendar value registry as 845 per Section 8.2.6 of [RFC5545]: 847 +--------------+---------+----------------------+ 848 | Feature Type | Status | Reference | 849 +--------------+---------+----------------------+ 850 | AUDIO | Current | RFCXXXX, Section 6.3 | 851 | CHAT | Current | RFCXXXX, Section 6.3 | 852 | FEED | Current | RFCXXXX, Section 6.3 | 853 | MODERATOR | Current | RFCXXXX, Section 6.3 | 854 | PHONE | Current | RFCXXXX, Section 6.3 | 855 | SCREEN | Current | RFCXXXX, Section 6.3 | 856 | VIDEO | Current | RFCXXXX, Section 6.3 | 857 +--------------+---------+----------------------+ 859 10. Acknowledgments 861 Thanks to the following for feedback: Bernard Desruisseaux, Mike 862 Douglass, Lucia Fedorova, Ken Murchison, Arnaud Quillaud, and Dave 863 Thewlis. 865 This specification came about via discussions at the Calendaring and 866 Scheduling Consortium. 868 11. References 870 11.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 878 Specifications: ABNF", STD 68, RFC 5234, 879 DOI 10.17487/RFC5234, January 2008, 880 . 882 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 883 Scheduling Core Object Specification (iCalendar)", 884 RFC 5545, DOI 10.17487/RFC5545, September 2009, 885 . 887 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 888 Interoperability Protocol (iTIP)", RFC 5546, 889 DOI 10.17487/RFC5546, December 2009, 890 . 892 [W3C.REC-css3-color-20110607] 893 A‡elik, T., Lilley, C., and D. Baron, "CSS Color 894 Module Level 3", World Wide Web Consortium Recommendation 895 REC-css3-color-20110607, June 2011, 896 . 898 11.2. Informative References 900 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 901 DOI 10.17487/RFC2397, August 1998, 902 . 904 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 905 RFC 3966, DOI 10.17487/RFC3966, December 2004, 906 . 908 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 909 Protocol (HTTP/1.1): Message Syntax and Routing", 910 RFC 7230, DOI 10.17487/RFC7230, June 2014, 911 . 913 Appendix A. Change History (To be removed by RFC Editor before 914 publication) 916 Changes in draft-ietf-calext-extensions-04: 918 1. SECDIR: Added new items to Security Considerations and added 919 Privacy Considerations. 921 2. SECDIR: fixed missing conference item in component ABNF 922 definitions. 924 3. SECDIR: editorial fixes. 926 Changes in draft-ietf-calext-extensions-03: 928 1. AD: fixed =/ ABNF syntax. 930 2. AD: added description for CATEGORIES. 932 3. AD: Removed extra / in image ABNF. 934 4. AD: Fixed VALUE=URI in image ABNF. 936 5. AD: Mention https in addition to http. Changed all examples to 937 use https: 939 6. AD: fixed DISPLAY ABNF syntax. 941 Changes in draft-ietf-calext-extensions-02: 943 1. Refresh expired draft - no changes. 945 Changes in draft-ietf-calext-extensions-01: 947 1. Clarified difference between SOURCE and URL properties. 949 2. Use labelparam not infoparam. 951 Changes in draft-ietf-calext-extensions-00: 953 1. Document renamed after WG adoption. 955 2. Fixed tel: URI reference. 957 Changes in draft-daboo-icalendar-extensions-09: 959 1. Re-instated a trimmed down version of the CONFERENCE property 960 after serious interest expressed by implementors. 962 2. LABEL property used instead of INFO - appropriated from another 963 iCalendar draft. 965 Changes in draft-daboo-icalendar-extensions-08: 967 1. Trimmed down the display values to a minimal set. 969 Changes in draft-daboo-icalendar-extensions-07: 971 1. Removed ALTURI parameter - now use ALTREP. 973 2. Removed VALID property. 975 3. Removed TIMEZONE-ID property. 977 4. Added FULLSIZE and THUMBNAIL display values. 979 5. Added EMAIL property parameter. 981 6. Added LAST-MODIFIED property for use with VCALENDAR. 983 7. Added CATEGORIES property for use with VCALENDAR. 985 8. URL use now aligned with 5545. 987 9. Added SOURCE property. 989 10. COLOR now uses CSS3 values. 991 Changes in draft-daboo-icalendar-extensions-06: 993 1. Removed BROADCAST/CONFERENCE properties and related parameters. 995 Changes in draft-daboo-icalendar-extensions-05: 997 1. Added section with recommendation on handling extension 998 properties. 1000 2. Added VALID property. 1002 Changes in draft-daboo-icalendar-extensions-04: 1004 1. TZID changed to new property TIMEZONE-ID. 1006 2. Minor formal syntax changes. 1008 Changes in draft-daboo-icalendar-extensions-03: 1010 1. Dropped CALENDAR- prefix 1012 2. DESCRIPTION, UID and TZID now based on existing RFC5545 1013 properties 1015 3. COLOR now on both the calendar and component level 1017 4. IMAGE now on both the calendar and component level 1019 5. Added FEATURE and REGION parameters to CONFERENCE property 1021 6. Added ALTURI parameter to IMAGE property 1023 7. Added FEED value to FEATURE parameter 1025 8. Added BROADCAST property and clarified that CONFERENCE is for bi- 1026 direction channels and BROADCAST is for uni-directional. 1028 Changes in draft-daboo-icalendar-extensions-02: 1030 1. Minor wording changes. 1032 2. Interval is now described as the "minimum interval". 1034 3. Added CONFERENCE property and INFO parameter. 1036 Changes in draft-daboo-icalendar-extensions-01: 1038 1. Fixed DISPLAY parameter handling of x- and iana tokens to state 1039 that clients ignore the image if the token is not recognized. 1041 2. Allow language variants for CALENDAR-NAME and CALENDAR- 1042 DESCRIPTION. 1044 3. Added registry for DISPLAY values. 1046 Author's Address 1048 Cyrus Daboo 1049 Apple Inc. 1050 1 Infinite Loop 1051 Cupertino, CA 95014 1052 USA 1054 Email: cyrus@daboo.name 1055 URI: http://www.apple.com/