idnits 2.17.1 draft-daboo-icalendar-extensions-07.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 (September 12, 2013) is 3873 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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) September 12, 2013 5 Intended status: Standards Track 6 Expires: March 16, 2014 8 New Properties for iCalendar 9 draft-daboo-icalendar-extensions-07 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 March 16, 2014. 34 Copyright Notice 36 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Backwards Compatible Extension Properties . . . . . . . . . . 3 54 4. Modifications to Calendar Components . . . . . . . . . . . . . 4 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 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 12 67 6.1. DISPLAY Property Parameter . . . . . . . . . . . . . . . . 12 68 6.2. EMAIL Property Parameter . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8.1. Property Registrations . . . . . . . . . . . . . . . . . . 14 72 8.2. Parameter Registrations . . . . . . . . . . . . . . . . . 14 73 8.3. Display Types Registry . . . . . . . . . . . . . . . . . . 14 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 78 Appendix A. Change History (To be removed by RFC Editor 79 before publication) . . . . . . . . . . . . . . . . . 16 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The iCalendar [RFC5545] data format is used to represent calendar 85 data and is used with iTIP [RFC5546] to handle scheduling operations 86 between calendar users. iCalendar is in widespread use, and in 87 accordance with provisions in that specification, extension elements 88 have been added by various vendors to the data format in order to 89 support and enhance capabilities. This specification collects a 90 number of these ad-hoc extensions and uses the new IANA registry 91 capability defined in [RFC5545] to register standard variants with 92 clearly defined definitions and semantics. In addition, some new 93 elements are introduced for features that vendors have recently been 94 requesting. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in 101 [RFC2119]. 103 The notation used in this memo is the ABNF notation of [RFC5234] as 104 used by iCalendar [RFC5545]. Any syntax elements shown below that 105 are not explicitly defined in this specification come from iCalendar 106 [RFC5545]. 108 3. Backwards Compatible Extension Properties 110 iCalendar defines properties which can have different value types 111 indicated by a "VALUE" parameter. The definition of a property 112 specifies a "default" value type that is assumed to be used when no 113 "VALUE" parameter is present. However, this poses a problem to 114 iCalendar parser/generator software that does not know about the 115 default values for new properties. For example, if a new property 116 "FOO" were defined with a default value type of URI, and a URI value 117 with a comma was used, an iCalendar generator not aware of this fact 118 would likely treat the property value as "TEXT" and apply backslash 119 escaping to the comma in the value, effectively making it an invalid 120 URI value. 122 To avoid this problem, this specification recommends that all 123 properties not defined in [RFC5545], always include a "VALUE" 124 parameter, if the type is other than "TEXT". i.e., in the example 125 above, the "FOO" property would have a "VALUE=URI" parameter. This 126 allows iCalendar parser/generator software to track the correct types 127 of unknown properties. 129 New properties defined in this specification use the term "no 130 default" in the "Value Type" definition to indicate that the "VALUE" 131 parameter has to be included. 133 4. Modifications to Calendar Components 135 The following changes to the syntax defined in iCalendar [RFC5545] 136 are made here. New elements are defined in subsequent sections. 138 calprops /= *( 139 ; 140 ; The following are OPTIONAL, 141 ; but MUST NOT occur more than once. 142 ; 143 uid / last-mod / url / 144 refresh / source / color 145 ; 146 ; The following are OPTIONAL, 147 ; and MAY occur more than once. 148 ; 149 name / description / categories / 150 image 151 ; 152 ) 154 eventprop /= *( 155 ; 156 ; The following are OPTIONAL, 157 ; but MUST NOT occur more than once. 158 ; 159 color / 160 ; 161 ; The following are OPTIONAL, 162 ; and MAY occur more than once. 163 ; 164 image 165 ; 166 ) 168 todoprop /= *( 169 ; 170 ; The following are OPTIONAL, 171 ; but MUST NOT occur more than once. 172 ; 173 color / 174 ; 175 ; The following are OPTIONAL, 176 ; and MAY occur more than once. 177 ; 178 image 179 ; 180 ) 182 jourprop /= *( 183 ; 184 ; The following are OPTIONAL, 185 ; but MUST NOT occur more than once. 186 ; 187 color / 188 ; 189 ; The following are OPTIONAL, 190 ; and MAY occur more than once. 191 ; 192 image 193 ; 194 ) 196 5. Properties 198 5.1. NAME Property 200 Property Name: NAME 202 Purpose: This property specifies the name of the calendar. 204 Value Type: TEXT 206 Property Parameters: IANA, non-standard, alternate text 207 representation, and language property parameters can be specified 208 on this property. 210 Conformance: This property can be specified multiple times in an 211 iCalendar object. However, each property MUST represent the name 212 of the calendar in a different language. 214 Description: This property is used to specify a name of the 215 iCalendar object that can be used by calendar user agents when 216 presenting the calendar data to a user. Whilst a calendar only 217 has a single name, multiple language variants can be specified by 218 including this property multiple times with different "LANGUAGE" 219 parameter values on each. 221 Format Definition: This property is defined by the following 222 notation: 224 name = "NAME" nameparam ":" text CRLF 226 nameparam = *( 227 ; 228 ; The following are OPTIONAL, 229 ; but MUST NOT occur more than once. 230 ; 231 (";" altrepparam) / (";" languageparam) / 232 ; 233 ; The following is OPTIONAL, 234 ; and MAY occur more than once. 235 ; 236 (";" other-param) 237 ; 238 ) 240 Example: The following is an example of this property: 242 NAME:Company Vacation Days 244 5.2. DESCRIPTION Property 246 This specification modifies the definition of the "DESCRIPTION" 247 property to allow it to be defined on an iCalendar object. The 248 following additions are made to the definition of this property. 250 Purpose: This property specifies the description of the calendar. 252 Conformance: This property can be specified multiple times in an 253 iCalendar object. However, each property MUST represent the 254 description of the calendar in a different language. 256 Description: This property is used to specify a lengthy textual 257 description of the iCalendar object that can be used by calendar 258 user agents when describing the nature of the calendar data to a 259 user. Whilst a calendar only has a single description, multiple 260 language variants can be specified by including this property 261 multiple times with different "LANGUAGE" parameter values on each. 263 5.3. UID Property 265 This specification modifies the definition of the "UID" property to 266 allow it to be defined on an iCalendar object. The following 267 additions are made to the definition of this property. 269 Purpose: This property specifies the persistent, globally unique 270 identifier for the iCalendar object. This can be used, for 271 example, to identify duplicate calendar streams that a client may 272 have been given access to. It can be used in conjunction with the 273 "LAST-MODIFIED" property also specified on the "VCALENDAR" object, 274 to identify the most recent version of a calendar. 276 Conformance: This property can be specified once in an iCalendar 277 object. 279 5.4. LAST-MODIFIED Property 281 This specification modifies the definition of the "LAST-MODIFIED" 282 property to allow it to be defined on an iCalendar object. The 283 following additions are made to the definition of this property. 285 Purpose: This property specifies the date and time that the 286 information associated with the calendar was last revised. 288 Conformance: This property can be specified once in an iCalendar 289 object. 291 5.5. URL Property 293 This specification modifies the definition of the "URL" property to 294 allow it to be defined on an iCalendar object. The following 295 additions are made to the definition of this property. 297 Purpose: This property may be used to convey a location where a more 298 dynamic rendition of the calendar information can be found. 300 Conformance: This property can be specified once in an iCalendar 301 object. 303 5.6. CATEGORIES Property 305 This specification modifies the definition of the "CATEGORIES" 306 property to allow it to be defined on an iCalendar object. The 307 following additions are made to the definition of this property. 309 Purpose: This property defines the categories for an entire 310 calendar. 312 Conformance: This property can be specified multiple times in an 313 iCalendar object. 315 5.7. REFRESH-INTERVAL Property 317 Property Name: REFRESH-INTERVAL 319 Purpose: This property specifies a suggested minimum interval for 320 polling for changes of the calendar data from the original source 321 of that data. 323 Value Type: DURATION - no default 325 Property Parameters: IANA and non-standard property parameters can 326 be specified on this property. 328 Conformance: This property can be specified once in an iCalendar 329 object. 331 Description: This property specifies a positive duration that gives 332 a suggested minimum polling interval for checking for updates to 333 the calendar data. The value of this property SHOULD be used by 334 calendar user agents to limit the polling interval for calendar 335 data updates to the minimum interval specified. 337 Format Definition: This property is defined by the following 338 notation: 340 refresh = "REFRESH-INTERVAL" refreshparam 341 ":" dur-value CRLF 342 ;consisting of a positive duration of time. 344 refreshparam = *( 345 ; 346 ; The following is REQUIRED, 347 ; but MUST NOT occur more than once. 348 ; 349 (";" "VALUE" "=" "DURATION") / 350 ; 351 ; The following is OPTIONAL, 352 ; and MAY occur more than once. 353 ; 354 (";" other-param) 355 ; 356 ) 358 Example: The following is an example of this property: 360 REFRESH-INTERVAL;VALUE=DURATION:P1W 362 5.8. SOURCE Property 364 Property Name: SOURCE 366 Purpose: This property identified a URI where calendar data can be 367 refreshed from. 369 Value Type: URI 371 Property Parameters: IANA and non-standard property parameters can 372 be specified on this property. 374 Conformance: This property can be specified once in an iCalendar 375 object. 377 Description: This property identifies a location where a client can 378 retrieve updated data for the calendar. Clients SHOULD honor any 379 specified "REFRESH-INTERVAL" value when periodically retrieving 380 data. 382 Format Definition: This property is defined by the following 383 notation: 385 source = "SOURCE" sourceparam ":" uri CRLF 387 sourceparam = *(";" other-param) 389 Example: The following is an example of this property: 391 SOURCE:http://example.com/holidays.ics 393 5.9. COLOR Property 395 Property Name: COLOR 397 Purpose: This property specifies a color used for displaying the 398 calendar, event, todo, or journal data. 400 Value Type: TEXT 402 Property Parameters: IANA and non-standard property parameters can 403 be specified on this property. 405 Conformance: This property can be specified once in an iCalendar 406 object, or "VEVENT", "VTODO", or "VJOURNAL" calendar components. 408 Description: This property specifies a color that clients MAY use 409 when presenting the relevant data to a user. Typically this would 410 appear as the "background" color of events or tasks. The value is 411 a case-insensitive color name taken from the CSS3 set of names, 412 defined in Section 4.3 of [W3C.REC-css3-color-20110607]. 414 Format Definition: This property is defined by the following 415 notation: 417 color = "COLOR" colorparam ":" text CRLF 418 ; Value is CSS3 color name 420 colorparam = *(";" other-param) 422 Example: The following is an example of this property: 424 COLOR:turquoise 426 5.10. IMAGE Property 428 Property Name: IMAGE 430 Purpose: This property specifies an image associated with the 431 calendar or a calendar component. 433 Value Type: URI or BINARY - no default. The value MUST refer to or 434 be data with a media type of "image". 436 Property Parameters: IANA, non-standard, display, inline encoding, 437 and value data type property parameters can be specified on this 438 property. The format type parameter can be specified on this 439 property and is RECOMMENDED for inline binary encoded content 440 information. 442 Conformance: This property can be specified multiple times in an 443 iCalendar object, or "VEVENT", "VTODO", or "VJOURNAL" calendar 444 components. 446 Description: This property specifies an image for an iCalendar 447 object or a calendar component via a uri or directly with inline 448 data that can be used by calendar user agents when presenting the 449 calendar data to a user. Multiple properties MAY be used to 450 specify alternative sets of images with, for example, varying 451 media subtypes, resolutions or sizes. When multiple properties 452 are present, calendar user agents SHOULD display only one of them, 453 picking one that provides the most appropriate image quality, or 454 display none. The "DISPLAY" parameter is used to indicate the 455 intended display mode for the image. The "ALTREP" parameter, 456 defined in [RFC5545], can be used to provide a "clickable" image 457 where the URI in the parameter value can be "launched" by a click 458 on the image in the calendar user agent. 460 Format Definition: This property is defined by the following 461 notation: 463 image = "IMAGE" imageparam ( ":" uri ) / 464 ( 465 ";" "ENCODING" "=" "BASE64" 466 ";" "VALUE" "=" "BINARY" 467 ":" binary 468 ) 469 CRLF 471 imageparam = *( 472 ; 473 ; The following is REQUIRED, 474 ; but MUST NOT occur more than once. 475 ; 476 (";" "VALUE" "=" "URI") / 477 ; 478 ; The following is OPTIONAL for a URI value, 479 ; RECOMMENDED for a BINARY value, 480 ; and MUST NOT occur more than once. 481 ; 482 (";" fmttypeparam) / 483 ; 484 ; The following are OPTIONAL, 485 ; and MUST NOT occur more than once. 486 ; 487 (";" altrepparam) / (";" displayparam) / 488 ; 489 ; The following is OPTIONAL, 490 ; and MAY occur more than once. 491 ; 492 (";" other-param) 493 ; 494 ) 496 Example: The following is an example of this property: 498 IMAGE;VALUE=URI;DISPLAY=BACKGROUND;FMTTYPE=image/png:h 499 ttp://example.com/images/party.png 501 6. Property Parameters 503 6.1. DISPLAY Property Parameter 505 Parameter Name: DISPLAY 507 Purpose: To specify different ways in which an image for a calendar 508 or component can be displayed. 510 Format Definition: This property parameter is defined by the 511 following notation: 513 displayparam = "DISPLAY" "=" 514 ("BADGE" / ; A small "badge" image 515 "BACKGROUND" / ; Use as a background image 516 "OVERLAY" / ; Use as an overlay image 517 "BANNER" / ; Use as a "banner" across the top 518 "FULLSIZE / ; Use to depict the entire event 519 "THUNMBNAIL / ; Smaller version of FULLSIZE 520 x-name / ; Experimental type 521 iana-token) ; Other IANA registered type 522 ; 523 ; Default is BADGE 525 Description: This property parameter MAY be specified on "IMAGE" 526 properties. In the absence of this parameter, the value "BADGE" 527 MUST be used for the default behavior. The value determines how a 528 client ought to present an image supplied in iCalendar data to the 529 user. 531 Values for this parameter are registered with IANA as per 532 Section 8.3. New values can be added to this registry following 533 the procedure outlined in Section 8.2.1 of [RFC5545]. 535 Servers and clients MUST handle x-name and iana-token values they 536 don't recognize by not displaying any image at all. 538 Example: 540 IMAGE;VALUE=URI;DISPLAY=BANNER;FMTTYPE=image/png:http://exa 541 mple.com/images/weather-cloudy.png 543 6.2. EMAIL Property Parameter 544 Parameter Name: EMAIL 546 Purpose: To specify an email address that is used to identify or 547 contact an organizer or attendee. 549 Format Definition: This property parameter is defined by the 550 following notation: 552 emailparam = "EMAIL" "=" param-value 554 Description: This property parameter MAY be specified on "ORGANIZER" 555 or "ATTENDEE" properties. This property can be used in situations 556 where the calendar user address value of "ORGANIZER" and 557 "ATTENDEE" properties is not likely to be an identifier that 558 recipients of scheduling messages could use to match the calendar 559 user with, for example, an address book entry. The value of this 560 property is an email address that can easily be matched by 561 recipients. Recipients can also use this value as an alternative 562 means of contacting the calendar user via email. If a recipient's 563 calendar user agent allows the recipient to save contact 564 information based on the "ORGANIZER" or "ATTENDEE" properties, 565 those calendar user agents SHOULD use any "EMAIL" property 566 parameter value for the email address of the contact over any 567 mailto: calendar user address specified as the value of the 568 property. Calendar user agents SHOULD NOT include an "EMAIL" 569 property parameter when its value matches the calendar user 570 address specified as the value of the property. 572 Example: 574 ATTENDEE;CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke 575 n-1234@example.com 577 7. Security Considerations 579 Several of the new properties or parameters defined by this 580 specification allow reference to "external" URIs. Care MUST be taken 581 when accessing data at external URIs as malicious content could be 582 present. In addition, access to those URIs could be tracked, leading 583 to loss of privacy. 585 8. IANA Considerations 586 8.1. Property Registrations 588 This document defines the following new iCalendar properties to be 589 added to the registry defined in Section 8.2.3 of [RFC5545]: 591 +------------------+---------+--------------------------------------+ 592 | Property | Status | Reference | 593 +------------------+---------+--------------------------------------+ 594 | NAME | Current | RFCXXXX, Section 5.1 | 595 | DESCRIPTION | Current | RFC5545 Section 3.8.1.5, RFCXXXX, | 596 | | | Section 5.2 | 597 | UID | Current | RFC5545 Section 3.8.4.7, RFCXXXX, | 598 | | | Section 5.3 | 599 | LAST-MODIFIED | Current | RFC5545 Section 3.8.7.3, RFCXXXX, | 600 | | | Section 5.4 | 601 | URL | Current | RFC5545 Section 3.8.4.6, RFCXXXX, | 602 | | | Section 5.5 | 603 | CATEGORIES | Current | RFC5545 Section 3.8.1.2, RFCXXXX, | 604 | | | Section 5.6 | 605 | REFRESH-INTERVAL | Current | RFCXXXX, Section 5.7 | 606 | SOURCE | Current | RFCXXXX, Section 5.8 | 607 | COLOR | Current | RFCXXXX, Section 5.9 | 608 | IMAGE | Current | RFCXXXX, Section 5.10 | 609 +------------------+---------+--------------------------------------+ 611 8.2. Parameter Registrations 613 This document defines the following new iCalendar property parameters 614 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 616 +--------------------+---------+----------------------+ 617 | Property Parameter | Status | Reference | 618 +--------------------+---------+----------------------+ 619 | DISPLAY | Current | RFCXXXX, Section 6.1 | 620 | EMAIL | Current | RFCXXXX, Section 6.2 | 621 +--------------------+---------+----------------------+ 623 8.3. Display Types Registry 625 This document defines the following new iCalendar value registry as 626 per Section 8.2.6 of [RFC5545]: 628 +--------------+---------+----------------------+ 629 | Display Type | Status | Reference | 630 +--------------+---------+----------------------+ 631 | BADGE | Current | RFCXXXX, Section 6.1 | 632 | BACKGROUND | Current | RFCXXXX, Section 6.1 | 633 | OVERLAY | Current | RFCXXXX, Section 6.1 | 634 | BANNER | Current | RFCXXXX, Section 6.1 | 635 | FULLSIZE | Current | RFCXXXX, Section 6.1 | 636 | THUMBNAIL | Current | RFCXXXX, Section 6.1 | 637 +--------------+---------+----------------------+ 639 9. Acknowledgments 641 Thanks to the following for feedback: Bernard Desruisseaux, Mike 642 Douglass, Arnaud Quillaud, and Dave Thewlis. This specification came 643 about via discussions at the Calendaring and Scheduling Consortium. 645 10. References 647 10.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 653 Specifications: ABNF", STD 68, RFC 5234, January 2008. 655 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 656 Core Object Specification (iCalendar)", RFC 5545, 657 September 2009. 659 [W3C.REC-css3-color-20110607] 660 Lilley, C., Celik, T., and L. Baron, "CSS Color Module 661 Level 3", World Wide Web Consortium Recommendation REC- 662 css3-color-20110607, June 2011, 663 . 665 10.2. Informative References 667 [RFC5546] Daboo, C., "iCalendar Transport-Independent 668 Interoperability Protocol (iTIP)", RFC 5546, 669 December 2009. 671 Appendix A. Change History (To be removed by RFC Editor before 672 publication) 674 Changes in -07: 676 1. Removed ALTURI parameter - now use ALTREP. 678 2. Removed VALID property. 680 3. Removed TIMEZONE-ID property. 682 4. Added FULLSIZE and THUMBNAIL display values. 684 5. Added EMAIL property parameter. 686 6. Added LAST-MODIFIED property for use with VCALENDAR. 688 7. Added CATEGORIES property for use with VCALENDAR. 690 8. URL use now aligned with 5545. 692 9. Added SOURCE property. 694 10. COLOR now uses CSS3 values. 696 Changes in -06: 698 1. Removed BROADCAST/CONFERENCE properties and related parameters. 700 Changes in -05: 702 1. Added section with recommendation on handling extension 703 properties. 705 2. Added VALID property. 707 Changes in -04: 709 1. TZID changed to new property TIMEZONE-ID. 711 2. Minor formal syntax changes. 713 Changes in -03: 715 1. Dropped CALENDAR- prefix 717 2. DESCRIPTION, UID and TZID now based on existing RFC5545 718 properties 720 3. COLOR now on both the calendar and component level 722 4. IMAGE now on both the calendar and component level 724 5. Added FEATURE and REGION parameters to CONFERENCE property 726 6. Added ALTURI parameter to IMAGE property 728 7. Added FEED value to FEATURE parameter 730 8. Added BROADCAST property and clarified that CONFERENCE is for bi- 731 direction channels and BROADCAST is for uni-directional. 733 Changes in -02: 735 1. Minor wording changes. 737 2. Interval is now described as the "minimum interval". 739 3. Added CONFERENCE property and INFO parameter. 741 Changes in -01: 743 1. Fixed DISPLAY parameter handling of x- and iana tokens to state 744 that clients ignore the image if the token is not recognized. 746 2. Allow language variants for CALENDAR-NAME and CALENDAR- 747 DESCRIPTION. 749 3. Added registry for DISPLAY values. 751 Author's Address 753 Cyrus Daboo 754 Apple Inc. 755 1 Infinite Loop 756 Cupertino, CA 95014 757 USA 759 Email: cyrus@daboo.name 760 URI: http://www.apple.com/