idnits 2.17.1 draft-ietf-calext-extensions-05.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 (August 22, 2016) is 2775 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) August 22, 2016 5 Intended status: Standards Track 6 Expires: February 23, 2017 8 New Properties for iCalendar 9 draft-ietf-calext-extensions-05 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 February 23, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . 8 61 5.6. CATEGORIES Property . . . . . . . . . . . . . . . . . . . 8 62 5.7. REFRESH-INTERVAL Property . . . . . . . . . . . . . . . . 8 63 5.8. SOURCE Property . . . . . . . . . . . . . . . . . . . . . 9 64 5.9. COLOR Property . . . . . . . . . . . . . . . . . . . . . 10 65 5.10. IMAGE Property . . . . . . . . . . . . . . . . . . . . . 11 66 5.11. CONFERENCE Property . . . . . . . . . . . . . . . . . . . 12 67 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 14 68 6.1. DISPLAY Property Parameter . . . . . . . . . . . . . . . 14 69 6.2. EMAIL Property Parameter . . . . . . . . . . . . . . . . 15 70 6.3. FEATURE Property Parameter . . . . . . . . . . . . . . . 16 71 6.4. LABEL Property Parameter . . . . . . . . . . . . . . . . 17 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 9.1. Property Registrations . . . . . . . . . . . . . . . . . 19 76 9.2. Parameter Registrations . . . . . . . . . . . . . . . . . 20 77 9.3. Property Parameter Value Registries . . . . . . . . . . . 20 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 81 11.2. Informative References . . . . . . . . . . . . . . . . . 22 82 Appendix A. Change History (To be removed by RFC Editor before 83 publication) . . . . . . . . . . . . . . . . . . . . 22 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 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 conference / 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 conference / 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, 253 originally specified in Section 3.8.1.5 of [RFC5545]. 255 Purpose: This property specifies the description of the calendar. 257 Conformance: This property can be specified multiple times in an 258 iCalendar object. However, each property MUST represent the 259 description of the calendar in a different language. 261 Description: This property is used to specify a lengthy textual 262 description of the iCalendar object that can be used by calendar 263 user agents when describing the nature of the calendar data to a 264 user. Whilst a calendar only has a single description, multiple 265 language variants can be specified by including this property 266 multiple times with different "LANGUAGE" parameter values on each. 268 5.3. UID Property 270 This specification modifies the definition of the "UID" property to 271 allow it to be defined on an iCalendar object. The following 272 additions are made to the definition of this property, originally 273 specified in Section 3.8.4.7 of [RFC5545]. 275 Purpose: This property specifies the persistent, globally unique 276 identifier for the iCalendar object. This can be used, for 277 example, to identify duplicate calendar streams that a client may 278 have been given access to. It can be used in conjunction with the 279 "LAST-MODIFIED" property also specified on the "VCALENDAR" object, 280 to identify the most recent version of a calendar. 282 Conformance: This property can be specified once in an iCalendar 283 object. 285 The description of the "UID" property in [RFC5545] contains some 286 recommendations on how the value can be constructed. In particular, 287 it suggests use of host names, IP addresses, and domain names to 288 construct the value. However, this is no longer considered good 289 practice, particularly from a security and privacy standpoint, since 290 use of such values can leak key information about a calendar user, or 291 their client and network environment. This specification updates 292 [RFC5545] by stating that "UID" values MUST NOT include any data that 293 might identify a user, host, domain, or any other security or privacy 294 sensitive information. It is RECOMMENDED that calendar user agents 295 now generate "UID" values that are hex-encoded random UUID values as 296 defined in Sections 4.4 and 4.5 of [RFC4122]. 298 The following is an example of such a property value: 300 UID:5FC53010-1267-4F8E-BC28-1D7AE55A7C99 302 Additionally, if calendar user agents choose to use other forms of 303 opaque identifiers for the "UID" value, they MUST have a length less 304 than 255 octets, and MUST conform to the "iana-token" ABNF syntax 305 defined in Section 3.1 of [RFC5545]. 307 5.4. LAST-MODIFIED Property 309 This specification modifies the definition of the "LAST-MODIFIED" 310 property to allow it to be defined on an iCalendar object. The 311 following additions are made to the definition of this property, 312 originally specified in Section 3.8.7.3 of [RFC5545]. 314 Purpose: This property specifies the date and time that the 315 information associated with the calendar was last revised. 317 Conformance: This property can be specified once in an iCalendar 318 object. 320 5.5. URL Property 322 This specification modifies the definition of the "URL" property to 323 allow it to be defined on an iCalendar object. The following 324 additions are made to the definition of this property, originally 325 specified in Section 3.8.4.6 of [RFC5545]. 327 Purpose: This property may be used to convey a location where a more 328 dynamic rendition of the calendar information can be found. 330 Conformance: This property can be specified once in an iCalendar 331 object. 333 5.6. CATEGORIES Property 335 This specification modifies the definition of the "CATEGORIES" 336 property to allow it to be defined on an iCalendar object. The 337 following additions are made to the definition of this property, 338 originally specified in Section 3.8.1.2 of [RFC5545]. 340 Purpose: This property defines the categories for an entire 341 calendar. 343 Conformance: This property can be specified multiple times in an 344 iCalendar object. 346 Description: When multiple properties are present, the set of 347 categories that apply to the iCalendar object are the union of all 348 the categories listed in each property value. 350 5.7. REFRESH-INTERVAL Property 352 Property Name: REFRESH-INTERVAL 354 Purpose: This property specifies a suggested minimum interval for 355 polling for changes of the calendar data from the original source 356 of that data. 358 Value Type: DURATION - no default 360 Property Parameters: IANA and non-standard property parameters can 361 be specified on this property. 363 Conformance: This property can be specified once in an iCalendar 364 object. 366 Description: This property specifies a positive duration that gives 367 a suggested minimum polling interval for checking for updates to 368 the calendar data. The value of this property SHOULD be used by 369 calendar user agents to limit the polling interval for calendar 370 data updates to the minimum interval specified. 372 Format Definition: This property is defined by the following 373 notation: 375 refresh = "REFRESH-INTERVAL" refreshparam 376 ":" dur-value CRLF 377 ;consisting of a positive duration of time. 379 refreshparam = *( 380 ; 381 ; The following is REQUIRED, 382 ; but MUST NOT occur more than once. 383 ; 384 (";" "VALUE" "=" "DURATION") / 385 ; 386 ; The following is OPTIONAL, 387 ; and MAY occur more than once. 388 ; 389 (";" other-param) 390 ; 391 ) 393 Example: The following is an example of this property: 395 REFRESH-INTERVAL;VALUE=DURATION:P1W 397 5.8. SOURCE Property 399 Property Name: SOURCE 401 Purpose: This property identified a URI where calendar data can be 402 refreshed from. 404 Value Type: URI - no default 406 Property Parameters: IANA and non-standard property parameters can 407 be specified on this property. 409 Conformance: This property can be specified once in an iCalendar 410 object. 412 Description: This property identifies a location where a client can 413 retrieve updated data for the calendar. Clients SHOULD honor any 414 specified "REFRESH-INTERVAL" value when periodically retrieving 415 data. Note that this property differs from the "URL" property in 416 that "URL" is meant to provide an alternative representation of 417 the calendar data, rather than the original location of the data. 419 Format Definition: This property is defined by the following 420 notation: 422 source = "SOURCE" sourceparam ":" uri CRLF 424 sourceparam = *(";" other-param) 426 Example: The following is an example of this property: 428 SOURCE;VALUE=URI:https://example.com/holidays.ics 430 5.9. COLOR Property 432 Property Name: COLOR 434 Purpose: This property specifies a color used for displaying the 435 calendar, event, todo, or journal data. 437 Value Type: TEXT 439 Property Parameters: IANA and non-standard property parameters can 440 be specified on this property. 442 Conformance: This property can be specified once in an iCalendar 443 object, or "VEVENT", "VTODO", or "VJOURNAL" calendar components. 445 Description: This property specifies a color that clients MAY use 446 when presenting the relevant data to a user. Typically this would 447 appear as the "background" color of events or tasks. The value is 448 a case-insensitive color name taken from the CSS3 set of names, 449 defined in Section 4.3 of [W3C.REC-css3-color-20110607]. 451 Format Definition: This property is defined by the following 452 notation: 454 color = "COLOR" colorparam ":" text CRLF 455 ; Value is CSS3 color name 457 colorparam = *(";" other-param) 459 Example: The following is an example of this property: 461 COLOR:turquoise 463 5.10. IMAGE Property 465 Property Name: IMAGE 467 Purpose: This property specifies an image associated with the 468 calendar or a calendar component. 470 Value Type: URI or BINARY - no default. The value MUST refer to or 471 be data with a media type of "image". 473 Property Parameters: IANA, non-standard, display, inline encoding, 474 and value data type property parameters can be specified on this 475 property. The format type parameter can be specified on this 476 property and is RECOMMENDED for inline binary encoded content 477 information. 479 Conformance: This property can be specified multiple times in an 480 iCalendar object, or "VEVENT", "VTODO", or "VJOURNAL" calendar 481 components. 483 Description: This property specifies an image for an iCalendar 484 object or a calendar component via a uri or directly with inline 485 data that can be used by calendar user agents when presenting the 486 calendar data to a user. Multiple properties MAY be used to 487 specify alternative sets of images with, for example, varying 488 media subtypes, resolutions or sizes. When multiple properties 489 are present, calendar user agents SHOULD display only one of them, 490 picking one that provides the most appropriate image quality, or 491 display none. The "DISPLAY" parameter is used to indicate the 492 intended display mode for the image. The "ALTREP" parameter, 493 defined in [RFC5545], can be used to provide a "clickable" image 494 where the URI in the parameter value can be "launched" by a click 495 on the image in the calendar user agent. 497 Format Definition: This property is defined by the following 498 notation: 500 image = "IMAGE" imageparam 501 ( 502 ( 503 ";" "VALUE" "=" "URI" 504 ":" uri 505 ) / 506 ( 507 ";" "ENCODING" "=" "BASE64" 508 ";" "VALUE" "=" "BINARY" 509 ":" binary 510 ) 511 ) 512 CRLF 514 imageparam = *( 515 ; 516 ; The following is OPTIONAL for a URI value, 517 ; RECOMMENDED for a BINARY value, 518 ; and MUST NOT occur more than once. 519 ; 520 (";" fmttypeparam) / 521 ; 522 ; The following are OPTIONAL, 523 ; and MUST NOT occur more than once. 524 ; 525 (";" altrepparam) / (";" displayparam) / 526 ; 527 ; The following is OPTIONAL, 528 ; and MAY occur more than once. 529 ; 530 (";" other-param) 531 ; 532 ) 534 Example: The following is an example of this property: 536 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 537 ttp://example.com/images/party.png 539 5.11. CONFERENCE Property 541 Property Name: CONFERENCE 543 Purpose: This property specifies information for accessing a 544 conferencing system. 546 Value Type: URI - no default. 548 Property Parameters: IANA, non-standard, feature, and label property 549 parameters can be specified on this property. 551 Conformance: This property can be specified multiple times in a 552 "VEVENT" or "VTODO" calendar component. 554 Description: This property specifies information for accessing a 555 conferencing system for attendees of a meeting or task. This 556 might be for a telephone-based conference number dial-in with 557 access codes included (such as a tel: URI [RFC3966] or a sip: or 558 sips: URI [RFC3261]), or it might be for a web-based video chat 559 (such as an http: or https: URI [RFC7230]), or a URI for an 560 instant messaging group chat room (such as an xmpp: URI 561 [RFC5122]). If a specific URI for a conferencing system is not 562 available, a data: URI [RFC2397] containing a text description can 563 be used. 565 A conference system can be a bi-directional communication channel, 566 or a uni-directional "broadcast feed". 568 The "FEATURE" property parameter is used to describe the key 569 capabilities of the conference system to allow a client to choose 570 the ones that give the required level of interaction from a set of 571 multiple properties. 573 The "LABEL" property paramater is used to convey additional 574 details on the use of the URI. For example, the URIs or access 575 codes for the moderator and attendee of a teleconference system 576 could be different, and the "LABEL" property parameter could be 577 used to "tag" each "CONFERENCE" property to indicate which is 578 which. 580 The "LANGUAGE" property parameter can be used to specify the 581 language used for text values used with this property (as per 582 Section 3.2.10 of [RFC5545]. 584 Format Definition: This property is defined by the following 585 notation: 587 conference = "CONFERENCE" confparam ":" uri CRLF 589 confparam = *( 590 ; 591 ; The following is REQUIRED, 592 ; but MUST NOT occur more than once. 593 ; 594 (";" "VALUE" "=" "URI") / 595 ; 596 ; The following are OPTIONAL, 597 ; and MUST NOT occur more than once. 598 ; 599 (";" featureparam) / (";" labelparam) / 600 (";" languageparam ) / 601 ; 602 ; The following is OPTIONAL, 603 ; and MAY occur more than once. 604 ; 605 (";" other-param) 606 ; 607 ) 609 Example: The following are examples of this property: 611 CONFERENCE;VALUE=URI;FEATURE=PHONE,MODERATOR; 612 LABEL=Moderator dial-in:tel:+1-412-555-0123,,,654321 613 CONFERENCE;VALUE=URI;FEATURE=PHONE; 614 LABEL=Attendee dial-in:tel:+1-412-555-0123,,,555123 615 CONFERENCE;VALUE=URI;FEATURE=PHONE; 616 LABEL=Attendee dial-in:tel:+1-888-555-0456,,,555123 617 CONFERENCE;VALUE=URI;FEATURE=CHAT; 618 LABEL=Chat room:xmpp:chat-123@conference.example.com 619 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO; 620 LABEL=Attendee dial-in:https://chat.example.com/audio?id=123456 622 6. Property Parameters 624 6.1. DISPLAY Property Parameter 626 Parameter Name: DISPLAY 628 Purpose: To specify different ways in which an image for a calendar 629 or component can be displayed. 631 Format Definition: This property parameter is defined by the 632 following notation: 634 displayparam = "DISPLAY" "=" displayval *("," displayval) 636 displayval = ("BADGE" / ; image inline with the title of the 637 ; event 638 "GRAPHIC" / ; a full image replacement for the event 639 ; itself 640 "FULLSIZE" / ; an image that is used to enhance the 641 ; event 642 "THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be 643 ; used when space for the image is 644 ; constrained 645 x-name / ; Experimental type 646 iana-token) ; Other IANA registered type 647 ; 648 ; Default is BADGE 650 Description: This property parameter MAY be specified on "IMAGE" 651 properties. In the absence of this parameter, the default value 652 "BADGE" MUST be used. The value determines how a client ought to 653 present an image supplied in iCalendar data to the user. 655 Values for this parameter are registered with IANA as per 656 Section 9.3.1. New values can be added to this registry following 657 the procedure outlined in Section 8.2.1 of [RFC5545]. 659 Servers and clients MUST handle x-name and iana-token values they 660 don't recognize by not displaying any image at all. 662 Example: 664 IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL;FMTTYPE=image/png:https://exa 665 mple.com/images/weather-cloudy.png 667 6.2. EMAIL Property Parameter 669 Parameter Name: EMAIL 671 Purpose: To specify an email address that is used to identify or 672 contact an organizer or attendee. 674 Format Definition: This property parameter is defined by the 675 following notation: 677 emailparam = "EMAIL" "=" param-value 679 Description: This property parameter MAY be specified on "ORGANIZER" 680 or "ATTENDEE" properties. This property can be used in situations 681 where the calendar user address value of "ORGANIZER" and 682 "ATTENDEE" properties is not likely to be an identifier that 683 recipients of scheduling messages could use to match the calendar 684 user with, for example, an address book entry. The value of this 685 property is an email address that can easily be matched by 686 recipients. Recipients can also use this value as an alternative 687 means of contacting the calendar user via email. If a recipient's 688 calendar user agent allows the recipient to save contact 689 information based on the "ORGANIZER" or "ATTENDEE" properties, 690 those calendar user agents SHOULD use any "EMAIL" property 691 parameter value for the email address of the contact over any 692 mailto: calendar user address specified as the value of the 693 property. Calendar user agents SHOULD NOT include an "EMAIL" 694 property parameter when its value matches the calendar user 695 address specified as the value of the property. 697 Example: 699 ATTENDEE;CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke 700 n-1234@example.com 702 6.3. FEATURE Property Parameter 704 Parameter Name: FEATURE 706 Purpose: To specify a feature or features of a conference or 707 broadcast system. 709 Format Definition: This property parameter is defined by the 710 following notation: 712 featureparam = "FEATURE" "=" featuretext *("," featuretext) 713 featuretext = ("AUDIO" / ; Audio capability 714 "CHAT" / ; Chat or instant messaging 715 "FEED" / ; Blog or Atom feed 716 "MODERATOR" / ; Moderator dial-in code 717 "PHONE" / ; Phone conference 718 "SCREEN" / ; Screen sharing 719 "VIDEO" / ; Video capability 720 x-name / ; Experimental type 721 iana-token) ; Other IANA registered type 723 Description: This property parameter MAY be specified on the 724 "CONFERENCE" property. Multiple values can be specified. The 725 "MODERATOR" value is used to indicate that the property value is 726 specific to the owner/initiator of the conference and contains a 727 URI that "activates" the system (e.g., a "moderator" access code 728 for a phone conference system that is different from the "regular" 729 access code). 731 Example: 733 CONFERENCE;VALUE=URI;FEATURE=AUDIO:rtsp://audio.example.com/ 734 event 735 CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO:https://video-chat.exam 736 ple.com/;group-id=1234 738 6.4. LABEL Property Parameter 740 Parameter Name: LABEL 742 Purpose: To provide a human readable label. 744 Format Definition: This property parameter is defined by the 745 following notation: 747 labelparam = "LABEL" "=" param-value 749 Description: This property parameter MAY be specified on the 750 "CONFERENCE" property. It is anticipated that other extensions to 751 iCalendar will re-use this property parameter on new properties 752 that they define. As a result, clients MUST expect to find this 753 property parameter present on many different properties. It 754 provides a human readable label that can be presented to calendar 755 users to allow them to discriminate between properties which might 756 be similar, or provide additional information for properties that 757 are not self-describing. The "LANGUAGE" property parameter can be 758 used to specify the language of the text in the parameter value 759 (as per Section 3.2.10 of [RFC5545]. 761 Example: 763 CONFERENCE;VALUE=URI;FEATURE=VIDEO; 764 LABEL="Web video chat, access code=76543"; 765 :https://video-chat.example.com/;group-id=1234 767 7. Security Considerations 769 Several of the new properties or parameters defined by this 770 specification allow reference to "external" URIs. Care MUST be taken 771 when accessing data at external URIs as malicious content could be 772 present. Clients SHOULD ensure that suitable permission is granted 773 by calendar users before such URIs are dereferenced. 775 The "REFRESH-INTERVAL" property could be used by an attacker to make 776 a client carry out rapid requests to the server hosting the calendar, 777 by specifying a very short duration (e.g., one second). This could 778 lead to resource consumption on the client or server, and denial-of- 779 service attacks against the server. Clients MUST ensure that they 780 throttle requests to the server to a reasonable rate. In most cases, 781 updating a public calendar once per day would suffice. If the 782 "REFRESH-INTERVAL" is any less than that, clients SHOULD warn the 783 calendar user and allow them to override it with a longer value. 785 The "CONFERENCE" property can include a "FEATURE" property parameter 786 with a "MODERATOR" value. In some cases the access code used by the 787 owner/initiator of a conference might be private to an individual and 788 clients and servers MUST ensure that such properties are not sent to 789 attendees of a scheduled component, or sharees of a shared component. 791 Both the "COLOR" and "IMAGE" properties are likely to be used by 792 calendar users to express their own personal view of the calendar 793 data. In addition, these properties could be used by attackers to 794 produce a confusing display in a calendar user agent. When such 795 properties are encountered in calendar data that has come from other 796 calendar users (e.g., via a scheduling message, "public" calendar 797 subscription, shared calendar etc), it is advisable for the client to 798 give the receiving calendar user the option to remove (or adjust) 799 these properties as the data is imported into their calendar system. 801 This specification changes the recommendations on how "UID" property 802 values are constructed to minimize leaking any information that might 803 be security sensitive. 805 Security considerations in [RFC5545], and [RFC5546] MUST also be 806 adhered to. 808 8. Privacy Considerations 810 Several of the new properties or parameters defined by this 811 specification allow reference to "external" URIs. Access to those 812 URIs could be tracked, leading to loss of privacy. Clients SHOULD 813 ensure that suitable permission is granted by calendar users before 814 such URIs are dereferenced. In particular, calendar publishers 815 wishing to help protect the privacy of their subscribers MUST use 816 HTTP with Transport Layer Security [RFC7230] ("https:" URIs instead 817 of "http:" URIs) for access to calendar data or ancillary data such 818 as images. 820 In general, users have to rely on the privacy policies of any 821 conferencing system being accessed via the "CONFERENCE" property, for 822 their own privacy protection. It is entirely possible for such 823 systems to uniquely identify and log the activity and participation 824 (or not) of calendar users in the conference. Calendar user agents 825 SHOULD track which conferencing systems are used and warn users the 826 first time a new one is about to be used. This is particularly 827 important if the client automatically "dials in" to the conference 828 when the event start time occurs. 830 By giving different calendar users different values for the "REFRESH- 831 INTERVAL" property, it is possible for a publisher of calendar data 832 to uniquely identify each refresh from each calendar users' clients, 833 and thereby track user activity and IP address over time. To address 834 this, clients SHOULD add or subtract some random amount of time from 835 the published "REFRESH-INTERVAL" value when doing actual refreshes. 837 This specification changes the recommendations on how "UID" property 838 values are constructed to minimize leaking any information that might 839 be privacy sensitive. 841 Privacy considerations in [RFC5545], and [RFC5546] MUST also be 842 adhered to. 844 9. IANA Considerations 846 9.1. Property Registrations 848 This document defines the following new iCalendar properties to be 849 added to the registry defined in Section 8.3.2 of [RFC5545]: 851 +------------------+---------+--------------------------------------+ 852 | Property | Status | Reference | 853 +------------------+---------+--------------------------------------+ 854 | NAME | Current | RFCXXXX, Section 5.1 | 855 | DESCRIPTION | Current | RFC5545 Section 3.8.1.5, RFCXXXX, | 856 | | | Section 5.2 | 857 | UID | Current | RFC5545 Section 3.8.4.7, RFCXXXX, | 858 | | | Section 5.3 | 859 | LAST-MODIFIED | Current | RFC5545 Section 3.8.7.3, RFCXXXX, | 860 | | | Section 5.4 | 861 | URL | Current | RFC5545 Section 3.8.4.6, RFCXXXX, | 862 | | | Section 5.5 | 863 | CATEGORIES | Current | RFC5545 Section 3.8.1.2, RFCXXXX, | 864 | | | Section 5.6 | 865 | REFRESH-INTERVAL | Current | RFCXXXX, Section 5.7 | 866 | SOURCE | Current | RFCXXXX, Section 5.8 | 867 | COLOR | Current | RFCXXXX, Section 5.9 | 868 | IMAGE | Current | RFCXXXX, Section 5.10 | 869 | CONFERENCE | Current | RFCXXXX, Section 5.11 | 870 +------------------+---------+--------------------------------------+ 872 9.2. Parameter Registrations 874 This document defines the following new iCalendar property parameters 875 to be added to the registry defined in Section 8.3.3 of [RFC5545]: 877 +--------------------+---------+----------------------+ 878 | Property Parameter | Status | Reference | 879 +--------------------+---------+----------------------+ 880 | DISPLAY | Current | RFCXXXX, Section 6.1 | 881 | EMAIL | Current | RFCXXXX, Section 6.2 | 882 | FEATURE | Current | RFCXXXX, Section 6.3 | 883 | LABEL | Current | RFCXXXX, Section 6.4 | 884 +--------------------+---------+----------------------+ 886 9.3. Property Parameter Value Registries 888 Two new IANA registries for iCalendar elements have been added. 889 Additional codes MAY be used, provided the process described in 890 Section 8.2.1 of [RFC5545] is used to register them, using the 891 template in Section 8.2.6 of [RFC5545]. 893 9.3.1. Display Types Registry 895 The following table has been used to initialize the Display Types 896 Registry. 898 +--------------+---------+----------------------+ 899 | Display Type | Status | Reference | 900 +--------------+---------+----------------------+ 901 | BADGE | Current | RFCXXXX, Section 6.1 | 902 | GRAPHIC | Current | RFCXXXX, Section 6.1 | 903 | FULLSIZE | Current | RFCXXXX, Section 6.1 | 904 | THUMBNAIL | Current | RFCXXXX, Section 6.1 | 905 +--------------+---------+----------------------+ 907 9.3.2. Feature Types Registry 909 The following table has been used to initialize the Feature Types 910 Registry. 912 +--------------+---------+----------------------+ 913 | Feature Type | Status | Reference | 914 +--------------+---------+----------------------+ 915 | AUDIO | Current | RFCXXXX, Section 6.3 | 916 | CHAT | Current | RFCXXXX, Section 6.3 | 917 | FEED | Current | RFCXXXX, Section 6.3 | 918 | MODERATOR | Current | RFCXXXX, Section 6.3 | 919 | PHONE | Current | RFCXXXX, Section 6.3 | 920 | SCREEN | Current | RFCXXXX, Section 6.3 | 921 | VIDEO | Current | RFCXXXX, Section 6.3 | 922 +--------------+---------+----------------------+ 924 10. Acknowledgments 926 Thanks to the following for feedback: Bernard Desruisseaux, Mike 927 Douglass, Lucia Fedorova, Ken Murchison, Arnaud Quillaud, and Dave 928 Thewlis. 930 This specification came about via discussions at the Calendaring and 931 Scheduling Consortium. 933 11. References 935 11.1. Normative References 937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 938 Requirement Levels", BCP 14, RFC 2119, 939 DOI 10.17487/RFC2119, March 1997, 940 . 942 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 943 Unique IDentifier (UUID) URN Namespace", RFC 4122, 944 DOI 10.17487/RFC4122, July 2005, 945 . 947 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 948 Specifications: ABNF", STD 68, RFC 5234, 949 DOI 10.17487/RFC5234, January 2008, 950 . 952 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 953 Scheduling Core Object Specification (iCalendar)", 954 RFC 5545, DOI 10.17487/RFC5545, September 2009, 955 . 957 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 958 Interoperability Protocol (iTIP)", RFC 5546, 959 DOI 10.17487/RFC5546, December 2009, 960 . 962 [W3C.REC-css3-color-20110607] 963 A‡elik, T., Lilley, C., and D. Baron, "CSS Color 964 Module Level 3", World Wide Web Consortium Recommendation 965 REC-css3-color-20110607, June 2011, 966 . 968 11.2. Informative References 970 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 971 DOI 10.17487/RFC2397, August 1998, 972 . 974 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 975 A., Peterson, J., Sparks, R., Handley, M., and E. 976 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 977 DOI 10.17487/RFC3261, June 2002, 978 . 980 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 981 RFC 3966, DOI 10.17487/RFC3966, December 2004, 982 . 984 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 985 (IRIs) and Uniform Resource Identifiers (URIs) for the 986 Extensible Messaging and Presence Protocol (XMPP)", 987 RFC 5122, DOI 10.17487/RFC5122, February 2008, 988 . 990 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 991 Protocol (HTTP/1.1): Message Syntax and Routing", 992 RFC 7230, DOI 10.17487/RFC7230, June 2014, 993 . 995 Appendix A. Change History (To be removed by RFC Editor before 996 publication) 998 Changes in draft-ietf-calext-extensions-05: 1000 1. IESG: Fixed IANA section to properly define the two new 1001 registries. 1003 2. IESG: Added xmpp, sip, and sips as example URIs for CONFERENCE. 1005 3. IESG: Added languageparam to CONFERENCE and also indicated it 1006 can appear alongside LABEL. 1008 4. IESG: Changed SHOULD -> MUST for clients to expect LABEL. 1010 5. IESG: Privacy: use https: instead of http:. 1012 6. IESG: Privacy: text on tracking via CONFERENCE. 1014 7. IESG: Privacy: text on tracking via REFRESH-INTERVAL. 1016 8. IESG: Modified UID value generation to be stricter about what is 1017 allowed.. 1019 9. IESG: Other editorial tweaks. 1021 10. Removed CONFERENCE from VJOURNAL ABNF. 1023 Changes in draft-ietf-calext-extensions-04: 1025 1. SECDIR: Added new items to Security Considerations and added 1026 Privacy Considerations. 1028 2. SECDIR: fixed missing conference item in component ABNF 1029 definitions. 1031 3. SECDIR: editorial fixes. 1033 Changes in draft-ietf-calext-extensions-03: 1035 1. AD: fixed =/ ABNF syntax. 1037 2. AD: added description for CATEGORIES. 1039 3. AD: Removed extra / in image ABNF. 1041 4. AD: Fixed VALUE=URI in image ABNF. 1043 5. AD: Mention https in addition to http. Changed all examples to 1044 use https: 1046 6. AD: fixed DISPLAY ABNF syntax. 1048 Changes in draft-ietf-calext-extensions-02: 1050 1. Refresh expired draft - no changes. 1052 Changes in draft-ietf-calext-extensions-01: 1054 1. Clarified difference between SOURCE and URL properties. 1056 2. Use labelparam not infoparam. 1058 Changes in draft-ietf-calext-extensions-00: 1060 1. Document renamed after WG adoption. 1062 2. Fixed tel: URI reference. 1064 Changes in draft-daboo-icalendar-extensions-09: 1066 1. Re-instated a trimmed down version of the CONFERENCE property 1067 after serious interest expressed by implementors. 1069 2. LABEL property used instead of INFO - appropriated from another 1070 iCalendar draft. 1072 Changes in draft-daboo-icalendar-extensions-08: 1074 1. Trimmed down the display values to a minimal set. 1076 Changes in draft-daboo-icalendar-extensions-07: 1078 1. Removed ALTURI parameter - now use ALTREP. 1080 2. Removed VALID property. 1082 3. Removed TIMEZONE-ID property. 1084 4. Added FULLSIZE and THUMBNAIL display values. 1086 5. Added EMAIL property parameter. 1088 6. Added LAST-MODIFIED property for use with VCALENDAR. 1090 7. Added CATEGORIES property for use with VCALENDAR. 1092 8. URL use now aligned with 5545. 1094 9. Added SOURCE property. 1096 10. COLOR now uses CSS3 values. 1098 Changes in draft-daboo-icalendar-extensions-06: 1100 1. Removed BROADCAST/CONFERENCE properties and related parameters. 1102 Changes in draft-daboo-icalendar-extensions-05: 1104 1. Added section with recommendation on handling extension 1105 properties. 1107 2. Added VALID property. 1109 Changes in draft-daboo-icalendar-extensions-04: 1111 1. TZID changed to new property TIMEZONE-ID. 1113 2. Minor formal syntax changes. 1115 Changes in draft-daboo-icalendar-extensions-03: 1117 1. Dropped CALENDAR- prefix 1119 2. DESCRIPTION, UID and TZID now based on existing RFC5545 1120 properties 1122 3. COLOR now on both the calendar and component level 1124 4. IMAGE now on both the calendar and component level 1126 5. Added FEATURE and REGION parameters to CONFERENCE property 1128 6. Added ALTURI parameter to IMAGE property 1130 7. Added FEED value to FEATURE parameter 1132 8. Added BROADCAST property and clarified that CONFERENCE is for bi- 1133 direction channels and BROADCAST is for uni-directional. 1135 Changes in draft-daboo-icalendar-extensions-02: 1137 1. Minor wording changes. 1139 2. Interval is now described as the "minimum interval". 1141 3. Added CONFERENCE property and INFO parameter. 1143 Changes in draft-daboo-icalendar-extensions-01: 1145 1. Fixed DISPLAY parameter handling of x- and iana tokens to state 1146 that clients ignore the image if the token is not recognized. 1148 2. Allow language variants for CALENDAR-NAME and CALENDAR- 1149 DESCRIPTION. 1151 3. Added registry for DISPLAY values. 1153 Author's Address 1155 Cyrus Daboo 1156 Apple Inc. 1157 1 Infinite Loop 1158 Cupertino, CA 95014 1159 USA 1161 Email: cyrus@daboo.name 1162 URI: http://www.apple.com/