idnits 2.17.1 draft-daboo-icalendar-extensions-06.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 (January 31, 2013) is 4103 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) January 31, 2013 5 Intended status: Standards Track 6 Expires: August 4, 2013 8 New Properties for iCalendar 9 draft-daboo-icalendar-extensions-06 11 Abstract 13 This document defines a set of new properties for iCalendar data. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 4, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 51 3. Backwards Compatible Extension Properties . . . . . . . . . . 3 52 4. Modifications to Calendar Components . . . . . . . . . . . . . 4 53 5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5.1. NAME Property . . . . . . . . . . . . . . . . . . . . . . 5 55 5.2. DESCRIPTION Property . . . . . . . . . . . . . . . . . . . 6 56 5.3. UID Property . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.4. URL Property . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.5. TIMEZONE-ID Property . . . . . . . . . . . . . . . . . . . 7 59 5.6. REFRESH-INTERVAL Property . . . . . . . . . . . . . . . . 8 60 5.7. VALID Property . . . . . . . . . . . . . . . . . . . . . . 9 61 5.8. COLOR Property . . . . . . . . . . . . . . . . . . . . . . 10 62 5.9. IMAGE Property . . . . . . . . . . . . . . . . . . . . . . 11 63 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. ALTURI Property Parameter . . . . . . . . . . . . . . . . 13 65 6.2. DISPLAY Property Parameter . . . . . . . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 8.1. Property Registrations . . . . . . . . . . . . . . . . . . 14 69 8.2. Parameter Registrations . . . . . . . . . . . . . . . . . 15 70 8.3. Display Types Registry . . . . . . . . . . . . . . . . . . 15 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Appendix A. Change History (To be removed by RFC Editor 76 before publication) . . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 The iCalendar [RFC5545] data format is used to represent calendar 82 data and is used with iTIP [RFC5546] to handle scheduling operations 83 between calendar users. iCalendar is in widespread use, and in 84 accordance with provisions in that specification, extension elements 85 have been added by various vendors to the data format in order to 86 support and enhance capabilities. This specification collects a 87 number of these ad-hoc extensions and uses the new IANA registry 88 capability defined in [RFC5545] to register standard variants with 89 clearly defined definitions and semantics. In addition, some new 90 elements are introduced for features that vendors have recently been 91 requesting. 93 2. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119]. 100 The notation used in this memo is the ABNF notation of [RFC5234] as 101 used by iCalendar [RFC5545]. Any syntax elements shown below that 102 are not explicitly defined in this specification come from iCalendar 103 [RFC5545]. 105 3. Backwards Compatible Extension Properties 107 iCalendar defines properties which can have different value types 108 indicated by a "VALUE" parameter. The definition of a property 109 specifies a "default" value type that is assumed to be used when no 110 "VALUE" parameter is present. However, this poses a problem to 111 iCalendar parser/generator software that does not know about the 112 default values for new properties. For example, if a new property 113 "FOO" were defined with a default value type of URI, and a URI value 114 with a comma was used, an iCalendar generator not aware of this fact 115 would likely treat the property value as "TEXT" and apply backslash 116 escaping to the comma in the value, effectively making it an invalid 117 URI value. 119 To avoid this problem, this specification recommends that all 120 properties not defined in [RFC5545], always include a "VALUE" 121 parameter, if the type is other than "TEXT". i.e., in the example 122 above, the "FOO" property would have a "VALUE=URI" parameter. This 123 allows iCalendar parser/generator software to track the correct types 124 of unknown properties. 126 New properties defined in this specification use the term "no 127 default" in the "Value Type" definition to indicate that the "VALUE" 128 parameter has to be included. 130 4. Modifications to Calendar Components 132 The following changes to the syntax defined in iCalendar [RFC5545] 133 are made here. New elements are defined in subsequent sections. 135 calprops /= *( 136 ; 137 ; The following are OPTIONAL, 138 ; but MUST NOT occur more than once. 139 ; 140 uid / url / timezid / 141 refresh / valid / color / 142 ; 143 ; The following are OPTIONAL, 144 ; and MAY occur more than once. 145 ; 146 name / description / image 147 ; 148 ) 150 eventprop /= *( 151 ; 152 ; The following are OPTIONAL, 153 ; but MUST NOT occur more than once. 154 ; 155 color / 156 ; 157 ; The following are OPTIONAL, 158 ; and MAY occur more than once. 159 ; 160 image 161 ; 162 ) 164 todoprop /= *( 165 ; 166 ; The following are OPTIONAL, 167 ; but MUST NOT occur more than once. 168 ; 169 color / 170 ; 171 ; The following are OPTIONAL, 172 ; and MAY occur more than once. 173 ; 174 image 175 ; 176 ) 178 jourprop /= *( 179 ; 180 ; The following are OPTIONAL, 181 ; but MUST NOT occur more than once. 182 ; 183 color / 184 ; 185 ; The following are OPTIONAL, 186 ; and MAY occur more than once. 187 ; 188 image 189 ; 190 ) 192 5. Properties 194 5.1. NAME Property 196 Property Name: NAME 198 Purpose: This property specifies the name of the calendar. 200 Value Type: TEXT 202 Property Parameters: IANA, non-standard, alternate text 203 representation, and language property parameters can be specified 204 on this property. 206 Conformance: This property can be specified multiple times in an 207 iCalendar object. However, each property MUST represent the name 208 of the calendar in a different language. 210 Description: This property is used to specify a name (a short, one- 211 line description) of the iCalendar object that can be used by 212 calendar user agents when presenting the calendar data to a user. 213 Whilst a calendar only has a single name, multiple language 214 variants can be specified by including this property multiple 215 times with different "LANGUAGE" parameter values on each. 217 Format Definition: This property is defined by the following 218 notation: 220 name = "NAME" nameparam ":" text CRLF 222 nameparam = *( 223 ; 224 ; The following are OPTIONAL, 225 ; but MUST NOT occur more than once. 226 ; 227 (";" altrepparam) / (";" languageparam) / 228 ; 229 ; The following is OPTIONAL, 230 ; and MAY occur more than once. 231 ; 232 (";" other-param) 233 ; 234 ) 236 Example: The following is an example of this property: 238 NAME:Company Vacation Days 240 5.2. DESCRIPTION Property 242 This specification modifies the definition of the "DESCRIPTION" 243 property to allow it to be defined on an iCalendar object. The 244 following additions are made to the definition of this property. 246 Purpose: This property specifies the description of the calendar. 248 Conformance: This property can be specified multiple times in an 249 iCalendar object. However, each property MUST represent the 250 description of the calendar in a different language. 252 Description: This property is used to specify a lengthy textual 253 description of the iCalendar object that can be used by calendar 254 user agents when describing the nature of the calendar data to a 255 user. Whilst a calendar only has a single description, multiple 256 language variants can be specified by including this property 257 multiple times with different "LANGUAGE" parameter values on each. 259 5.3. UID Property 261 This specification modifies the definition of the "UID" property to 262 allow it to be defined on an iCalendar object. The following 263 additions are made to the definition of this property. 265 Purpose: This property specifies the persistent, globally unique 266 identifier for the iCalendar object. 268 Conformance: This property can be specified once in an iCalendar 269 object. 271 5.4. URL Property 273 This specification modifies the definition of the "URL" property to 274 allow it to be defined on an iCalendar object. The following 275 additions are made to the definition of this property. 277 Purpose: This property specifies a URL from where the calendar data 278 was retrieved or where it can be refreshed. 280 Conformance: This property can be specified once in an iCalendar 281 object. 283 Description: This property specifies a URL identifying the source of 284 the calendar data and a location from where updates can be 285 retrieved. 287 5.5. TIMEZONE-ID Property 289 Property Name: TIMEZONE-ID 291 Purpose: This property specifies the default time zone identifier 292 for the iCalendar object as a whole. 294 Value Type: TEXT 296 Property Parameters: IANA and non-standard property parameters can 297 be specified on this property. 299 Conformance: This property can be specified once in an iCalendar 300 object. 302 Description: This property specifies a time zone identifier that 303 represents the default timezone for which floating time or all-day 304 events in the iCalendar object can be assumed to be relative to. 305 It can also be used to choose an initial time zone for use when 306 creating new components in the iCalendar object. A "VTIMEZONE" 307 component having a "TZID" property matching the value specified in 308 this property MUST be present in the iCalendar object. 310 Format Definition: This property is defined by the following 311 notation: 313 timezid = "TIMEZONE-ID" timezidparam 314 ":" text CRLF 315 ;Same value syntax as "TZID" property. 317 timezidparam = *(";" other-param) 319 Example: The following is an example of this property: 321 TIMEZONE-ID:America/New_York 323 5.6. REFRESH-INTERVAL Property 325 Property Name: REFRESH-INTERVAL 327 Purpose: This property specifies a suggested minimum interval for 328 polling for changes of the calendar data from the original source 329 of that data. 331 Value Type: DURATION - no default 333 Property Parameters: IANA and non-standard property parameters can 334 be specified on this property. 336 Conformance: This property can be specified once in an iCalendar 337 object. 339 Description: This property specifies a positive duration that gives 340 a suggested minimum polling interval for checking for updates to 341 the calendar data. The value of this property SHOULD be used by 342 calendar user agents to limit the polling interval for calendar 343 data updates to the minimum interval specified. 345 Format Definition: This property is defined by the following 346 notation: 348 refresh = "REFRESH-INTERVAL" refreshparam 349 ":" dur-value CRLF 350 ;consisting of a positive duration of time. 352 refreshparam = *( 353 ; 354 ; The following is REQUIRED, 355 ; but MUST NOT occur more than once. 356 ; 357 (";" "VALUE" "=" "DURATION") / 358 ; 359 ; The following is OPTIONAL, 360 ; and MAY occur more than once. 361 ; 362 (";" other-param) 363 ; 364 ) 366 Example: The following is an example of this property: 368 REFRESH-INTERVAL;VALUE=DURATION:P1W 370 5.7. VALID Property 372 Property Name: VALID 374 Purpose: This property specifies when the calendar data is valid. 376 Value Type: DATE-TIME or PERIOD 378 Property Parameters: IANA and non-standard property parameters can 379 be specified on this property. 381 Conformance: This property can be specified once in an iCalendar 382 object. 384 Description: This property specifies a time period for which the 385 calendar data can assumed to be valid. If a "PERIOD" value type 386 is used, the validity is assumed to be a time range defined by the 387 start and end of the period. If a "DATE-TIME" value is used, the 388 date indicates when end date when the calendar data is no longer 389 valid. Once the end date has been reached (or at some convenient 390 time prior) clients SHOULD refresh the calendar data to determine 391 whether an update is available, extending the range of validity. 392 The value MUST be specified in UTC. 394 Format Definition: This property is defined by the following 395 notation: 397 valid = "VALID" validparam ":" validval CRLF 399 validparam = *( 400 ; 401 ; The following is REQUIRED, 402 ; but MUST NOT occur more than once. 403 ; 404 (";" "VALUE" "=" ("DATE-TIME" / "PERIOD")) / 405 ; 406 ; The following is OPTIONAL, 407 ; and MAY occur more than once. 408 ; 409 (";" other-param) 410 ; 411 ) 413 validval = date-time / period 414 ;Value MUST match value type. Value MUST be in UTC. 416 Example: The following is an example of this property: 418 VALID;VALUE=DATE-TIME:20120609T000000Z 419 VALID;VALUE=PERIOD:20120609T000000Z/P365D 421 5.8. COLOR Property 423 Property Name: COLOR 425 Purpose: This property specifies a color used for displaying the 426 calendar, event, todo, or journal data. 428 Value Type: TEXT. The value MUST be three COLON-separated INTEGER 429 values. 431 Property Parameters: IANA and non-standard property parameters can 432 be specified on this property. 434 Conformance: This property can be specified once in an iCalendar 435 object, or "VEVENT", "VTODO", or "VJOURNAL" calendar components. 437 Description: This property specifies a color that client MAY use 438 when presenting the relevant data to a user. Typically this would 439 appear as the "background" color of events or tasks. The value 440 MUST be an RGB value with integer value components in the range 441 0..255. If a color is specified on a "VEVENT", "VTODO" or 442 "VJOURNAL" that SHOULD override any color specified on the 443 enclosing iCalendar object. 445 Format Definition: This property is defined by the following 446 notation: 448 color = "COLOR" colorparam ":" colorvalue CRLF 450 colorparam = *(";" other-param) 452 colorvalue = integer ":" integer ":" integer 453 ; Red, green, and blue values in the range 454 ; 0 - 255. 456 Example: The following is an example of this property: 458 COLOR:255:0:255 460 5.9. IMAGE Property 462 Property Name: IMAGE 464 Purpose: This property specifies an image associated with the 465 calendar or a calendar component. 467 Value Type: URI or BINARY - no default. The value MUST refer to or 468 be data with a media type of "image". 470 Property Parameters: IANA, non-standard, display, inline encoding, 471 and value data type property parameters can be specified on this 472 property. The format type parameter can be specified on this 473 property and is RECOMMENDED for inline binary encoded content 474 information. 476 Conformance: This property can be specified multiple times in an 477 iCalendar object, or "VEVENT", "VTODO", or "VJOURNAL" calendar 478 components. 480 Description: This property specifies an image for an iCalendar 481 object or a calendar component via a uri or directly with inline 482 data that can be used by calendar user agents when presenting the 483 calendar data to a user. Multiple properties MAY be used to 484 specify alternative sets of images with, for example, varying 485 media subtypes, resolutions or sizes. When multiple properties 486 are present, calendar user agents SHOULD display only one of them, 487 picking one that provides the most appropriate image quality, or 488 display none. The "DISPLAY" parameter is used to indicate the 489 intended display mode for the image. An "ALTURI" parameter is 490 used to provide a "clickable" image where the URI in the parameter 491 value can be "launched" by a click on the image in the calendar 492 user agent. 494 Format Definition: This property is defined by the following 495 notation: 497 image = "IMAGE" imageparam ( ":" uri ) / 498 ( 499 ";" "ENCODING" "=" "BASE64" 500 ";" "VALUE" "=" "BINARY" 501 ":" binary 502 ) 503 CRLF 505 imageparam = *( 506 ; 507 ; The following is REQUIRED, 508 ; but MUST NOT occur more than once. 509 ; 510 (";" "VALUE" "=" "URI") / 511 ; 512 ; The following is OPTIONAL for a URI value, 513 ; RECOMMENDED for a BINARY value, 514 ; and MUST NOT occur more than once. 515 ; 516 (";" fmttypeparam) / 517 ; 518 ; The following are OPTIONAL, 519 ; and MUST NOT occur more than once. 520 ; 521 (";" alturiparam) / (";" displayparam) / 522 ; 523 ; The following is OPTIONAL, 524 ; and MAY occur more than once. 525 ; 526 (";" other-param) 527 ; 528 ) 530 Example: The following is an example of this property: 532 IMAGE;VALUE=URI;DISPLAY=BACKGROUND;FMTTYPE=image/png:h 533 ttp://example.com/images/party.png 535 6. Property Parameters 537 6.1. ALTURI Property Parameter 539 Parameter Name: ALTURI 541 Purpose: To specify a URI alternative to a property value. 543 Format Definition: This property parameter is defined by the 544 following notation: 546 alturiparam = "ALTURI" "=" DQUOTE uri DQUOTE 548 Description: This property parameter MAY be specified on "IMAGE" 549 properties. 551 Example: 553 IMAGE;VALUE=URI;FMTTYPE=image/png:ALTURI="http://example.co 554 m/clicked-image1":http://example.com/images/party.png 556 6.2. DISPLAY Property Parameter 558 Parameter Name: DISPLAY 560 Purpose: To specify different ways in which an image for a calendar 561 or component can be displayed. 563 Format Definition: This property parameter is defined by the 564 following notation: 566 displayparam = "DISPLAY" "=" 567 ("BADGE" / ; A small "badge" image 568 "BACKGROUND" / ; Use as a background image 569 "OVERLAY" / ; Use as an overlay image 570 "BANNER" / ; Use as a "banner" across the top 571 x-name / ; Experimental type 572 iana-token) ; Other IANA registered type 573 ; 574 ; Default is BADGE 576 Description: This property parameter MAY be specified on "IMAGE" or 577 "IMAGE" properties. In the absence of this parameter, the value 578 "BADGE" MUST be used for the default behavior. The value 579 determines how a client ought to present an image supplied in 580 iCalendar data to the user. 582 Values for this parameter are registered with IANA as per 583 Section 8.3. New values can be added to this registry following 584 the procedure outlined in Section 8.2.1 of [RFC5545]. 586 Servers and clients MUST handle x-name and iana-token values they 587 don't recognize by not displaying any image at all. 589 Example: 591 IMAGE;VALUE=URI;DISPLAY=BANNER;FMTTYPE=image/png:http://exa 592 mple.com/images/weather-cloudy.png 594 7. Security Considerations 596 Several of the new properties or parameters defined by this 597 specification allow reference to "external" URIs. Care MUST be taken 598 when accessing data at external URIs as malicious content could be 599 present. In addition, access to those URIs could be tracked, leading 600 to loss of privacy. 602 8. IANA Considerations 604 8.1. Property Registrations 606 This document defines the following new iCalendar properties to be 607 added to the registry defined in Section 8.2.3 of [RFC5545]: 609 +------------------+---------+--------------------------------------+ 610 | Property | Status | Reference | 611 +------------------+---------+--------------------------------------+ 612 | NAME | Current | RFCXXXX, Section 5.1 | 613 | DESCRIPTION | Current | RFC5545 Section 3.8.1.5, RFCXXXX, | 614 | | | Section 5.2 | 615 | UID | Current | RFC5545 Section 3.8.4.7, RFCXXXX, | 616 | | | Section 5.3 | 617 | URL | Current | RFC5545 Section 3.8.4.6, RFCXXXX, | 618 | | | Section 5.4 | 619 | TIMEZONE-ID | Current | RFCXXXX, Section 5.5 | 620 | REFRESH-INTERVAL | Current | RFCXXXX, Section 5.6 | 621 | VALID | Current | RFCXXXX, Section 5.7 | 622 | COLOR | Current | RFCXXXX, Section 5.8 | 623 | IMAGE | Current | RFCXXXX, Section 5.9 | 624 +------------------+---------+--------------------------------------+ 626 8.2. Parameter Registrations 628 This document defines the following new iCalendar property parameters 629 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 631 +--------------------+---------+----------------------+ 632 | Property Parameter | Status | Reference | 633 +--------------------+---------+----------------------+ 634 | ALTURI | Current | RFCXXXX, Section 6.1 | 635 | DISPLAY | Current | RFCXXXX, Section 6.2 | 636 +--------------------+---------+----------------------+ 638 8.3. Display Types Registry 640 This document defines the following new iCalendar value registry as 641 per Section 8.2.6 of [RFC5545]: 643 +--------------+---------+----------------------+ 644 | Display Type | Status | Reference | 645 +--------------+---------+----------------------+ 646 | BADGE | Current | RFCXXXX, Section 6.2 | 647 | BACKGROUND | Current | RFCXXXX, Section 6.2 | 648 | OVERLAY | Current | RFCXXXX, Section 6.2 | 649 | BANNER | Current | RFCXXXX, Section 6.2 | 650 +--------------+---------+----------------------+ 652 9. Acknowledgments 654 Thanks to the following for feedback: Bernard Desruisseaux, Mike 655 Douglass, Arnaud Quillaud, and Dave Thewlis. This specification came 656 about via discussions at the Calendaring and Scheduling Consortium. 658 10. References 660 10.1. Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 666 Specifications: ABNF", STD 68, RFC 5234, January 2008. 668 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 669 Core Object Specification (iCalendar)", RFC 5545, 670 September 2009. 672 10.2. Informative References 674 [RFC5546] Daboo, C., "iCalendar Transport-Independent 675 Interoperability Protocol (iTIP)", RFC 5546, 676 December 2009. 678 Appendix A. Change History (To be removed by RFC Editor before 679 publication) 681 Changes in -06: 683 1. Removed BROADCAST/CONFERENCE properties and related parameters. 685 Changes in -05: 687 1. Added section with recommendation on handling extension 688 properties. 690 2. Added VALID property. 692 Changes in -04: 694 1. TZID changed to new property TIMEZONE-ID. 696 2. Minor formal syntax changes. 698 Changes in -03: 700 1. Dropped CALENDAR- prefix 702 2. DESCRIPTION, UID and TZID now based on existing RFC5545 703 properties 705 3. COLOR now on both the calendar and component level 707 4. IMAGE now on both the calendar and component level 709 5. Added FEATURE and REGION parameters to CONFERENCE property 711 6. Added ALTURI parameter to IMAGE property 713 7. Added FEED value to FEATURE parameter 715 8. Added BROADCAST property and clarified that CONFERENCE is for bi- 716 direction channels and BROADCAST is for uni-directional. 718 Changes in -02: 720 1. Minor wording changes. 722 2. Interval is now described as the "minimum interval". 724 3. Added CONFERENCE property and INFO parameter. 726 Changes in -01: 728 1. Fixed DISPLAY parameter handling of x- and iana tokens to state 729 that clients ignore the image if the token is not recognized. 731 2. Allow language variants for CALENDAR-NAME and CALENDAR- 732 DESCRIPTION. 734 3. Added registry for DISPLAY values. 736 Author's Address 738 Cyrus Daboo 739 Apple Inc. 740 1 Infinite Loop 741 Cupertino, CA 95014 742 USA 744 Email: cyrus@daboo.name 745 URI: http://www.apple.com/