idnits 2.17.1 draft-ietf-calext-eventpub-extensions-13.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC7986, 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 (May 26, 2019) is 1768 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 normative reference: RFC 2426 (Obsoleted by RFC 6350) Summary: 2 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 M. Douglass 3 Internet-Draft Spherical Cow Group 4 Updates: 5545,7986 (if approved) May 26, 2019 5 Intended status: Standards Track 6 Expires: November 27, 2019 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-13 11 Abstract 13 This specification updates RFC5545 by introducing a number of new 14 iCalendar properties and components which are of particular use for 15 event publishers and in social networking. 17 This specification also defines a new STRUCTURED-DATA property for 18 iCalendar RFC5545 to allow for data that is directly pertinent to an 19 event or task to be included with the calendar data. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 27, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Components and properties . . . . . . . . . . . . . . . . . . 3 58 3. Typed References . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 61 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5 62 3.1.2.1. Reserving facilities . . . . . . . . . . . . . . 5 63 4. Modifications to Calendar Components . . . . . . . . . . . . 6 64 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7 65 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.5. Derived . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Redefined Property SOURCE . . . . . . . . . . . . . . . . . . 10 71 7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.1. Participant Type . . . . . . . . . . . . . . . . . . . . 12 73 7.2. Calendar Address . . . . . . . . . . . . . . . . . . . . 14 74 7.3. Styled-Description . . . . . . . . . . . . . . . . . . . 15 75 7.4. Structured-Location . . . . . . . . . . . . . . . . . . . 17 76 7.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 19 77 7.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 20 78 8. New Components . . . . . . . . . . . . . . . . . . . . . . . 23 79 8.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.2. Schedulable Participant . . . . . . . . . . . . . . . . . 25 81 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 26 82 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 26 83 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 26 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 85 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 12.1. Additional iCalendar Registrations . . . . . . . . . . . 28 88 12.1.1. Properties . . . . . . . . . . . . . . . . . . . . . 28 89 12.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 28 90 12.1.3. Components . . . . . . . . . . . . . . . . . . . . . 28 91 12.2. New Registration Tables . . . . . . . . . . . . . . . . 29 92 12.2.1. Participant Types . . . . . . . . . . . . . . . . . 29 93 12.2.2. Resource Types . . . . . . . . . . . . . . . . . . . 29 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 97 14.2. Informative References . . . . . . . . . . . . . . . . . 31 98 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 31 99 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 31 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 102 1. Introduction 104 The currently existing iCalendar standard [RFC5545] lacks useful 105 methods for referencing additional, external information relating to 106 calendar components. Additionally there is no standard way to 107 provide rich text descriptions or meta-data associated with the 108 event. 110 Current practice is to embed this information as links in the 111 description or to add non-standard properties as defined in [RFC5545] 112 section 3.8.8.2. 114 This document updates [RFC5545] to define a number of properties and 115 a component referencing such external information that can provide 116 additional information about an iCalendar component. The intent is 117 to allow interchange of such information between applications or 118 systems (e.g., between clients, between client and server, and 119 between servers). Formats such as VCARD [RFC2426] are likely to be 120 most useful to the receivers of such events as they may be used in 121 other applications - such as address books. 123 1.1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. Components and properties 133 Previous extensions to the calendaring standards have been largely 134 restricted to the addition of properties or parameters. This is 135 partly because iCalendar libraries had trouble handling components 136 nested deeper than those defined in [RFC5545]. 138 In a break with this 'tradition' this specification defines 139 PARTICIPANT as a component rather than a property. This is a better 140 match for the way [W3C.REC-xml-20081126] and JSON [RFC8259] handle 141 such structures and allows richer definitions. 143 It also allows for the addition of extra properties inside the 144 component and resolves some of the problems of trying to add detailed 145 information as a parameter. 147 Many people or groups may participate in an event. The PARTICIPANT 148 component provides such detailed information. Participants may act 149 as attendees to the event (or derived events) or may just provide a 150 reference - perhaps for mailing lists. 152 3. Typed References 154 The properties defined here can all reference external meta-data 155 which may be used by applications to provide enhanced value to users. 156 By providing type information as parameters, clients and servers are 157 able to discover interesting references and make use of them, perhaps 158 for indexing or the presenting of additional related information for 159 the user. 161 The [RFC5545] LOCATION property provides only an unstructured single 162 text value for specifying the location where an event (or task) will 163 occur. This is inadequate for use cases where structured location 164 information (e.g. address, region, country, postal code) is required 165 or preferred, and limits widespread adoption of iCalendar in those 166 settings. 168 Using STRUCTURED-LOCATION, information about a number of interesting 169 locations can be communicated, for example, address, region, country, 170 postal code as well as other informations such as the parking, 171 restaurants and the venue. Servers and clients can retrieve the 172 objects when storing the event and use them to index by geographic 173 location. 175 When a calendar client receives a calendar component it can search 176 the set of supplied properties looking for those of particular 177 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 178 to help the selection. 180 The PARTICIPANT component is designed to handle common use cases in 181 event publication. It is generally important to provide information 182 about the organizers of such events. Sponsors wish to be referenced 183 in a prominent manner. In social calendaring it is often important 184 to identify the active participants in the event, for example a 185 school sports team, and the inactive participants, for example the 186 parents. 188 The PARTICIPANT component can also be used to provide useful extra 189 data about an attendee. For example a LOCATION property inside the 190 PARTICIPANT gives the actual location of a remote attendee. (But see 191 the note about privacy.) 193 3.1. Use Cases 195 The main motivation for these properties has been event publication 196 but there are opportunities for use elsewhere. The following use 197 cases will describe some possible scenarios. 199 3.1.1. Piano Concert Performance 201 In putting together a concert there are many participants: piano 202 tuner, performer, stage hands etc. In addition there are sponsors 203 and various contacts to be provided. There will also be a number of 204 related locations. A number of events can be created, all of which 205 relate to the performance in different ways. 207 There may be an iTip [RFC5546] meeting request for the piano tuner 208 who will arrive before the performance. Other members of staff may 209 also receive meeting requests. 211 An event can also be created for publication which will have a 212 PARTICIPANT component for the pianist providing a reference to VCARD 213 [RFC2426] information about the performer. This event would also 214 hold information about parking, local subway stations and the venue 215 itself. In addition, there will be sponsorship information for 216 sponsors of the event and perhaps paid sponsorship properties 217 essentially advertising local establishments. 219 3.1.2. Itineraries 221 These additions also provide opportunities for the travel industry. 222 When booking a flight the PARTICIPANT component can be used to 223 provide references to businesses at the airports and to car hire 224 businesses at the destination. 226 The embedded location information can guide the traveller at the 227 airport or to their final destination. The contact information can 228 provide detailed information about the booking agent, the airlines, 229 car hire companies and the hotel. 231 3.1.2.1. Reserving facilities 233 For a meeting, the size of a room and the equipment needed depends to 234 some extent on the number of attendees actually in the room. 236 A meeting may have 10 attendees non of which are co-located. The 237 current ATTENDEE property does not allow for the addition of such 238 meta-data. The PARTICIPANT property allows attendees to specify 239 their location. 241 4. Modifications to Calendar Components 243 The following changes to the syntax defined in iCalendar [RFC5545] 244 are made here. New elements are defined in subsequent sections. 246 eventc = "BEGIN" ":" "VEVENT" CRLF 247 eventprop *alarmc *participantc 248 "END" ":" "VEVENT" CRLF 250 eventprop =/ *( 251 ; 252 ; The following are OPTIONAL, 253 ; and MAY occur more than once. 254 ; 255 styleddescription / strucloc / strucres / sdataprop 256 ; 257 ) 259 todoc = "BEGIN" ":" "VTODO" CRLF 260 todoprop *alarmc *participantc 261 "END" ":" "VTODO" CRLF 263 todoprop =/ *( 264 ; 265 ; The following are OPTIONAL, 266 ; and MAY occur more than once. 267 ; 268 styleddescription / strucloc / strucres / sdataprop 269 ; 270 ) 272 journalc = "BEGIN" ":" "VJOURNAL" CRLF 273 jourprop *participantc 274 "END" ":" "VJOURNAL" CRLF 276 jourprop =/ *( 277 ; 278 ; The following are OPTIONAL, 279 ; and MAY occur more than once. 280 ; 281 styleddescription / sdataprop 282 ; 283 ) 285 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 286 fbprop *participantc 287 "END" ":" "VFREEBUSY" CRLF 289 fbprop =/ *( 290 ; 291 ; The following are OPTIONAL, 292 ; and MAY occur more than once. 293 ; 294 styleddescription 295 ; 296 ) 298 5. New Property Parameters 300 This specification makes use of the LABEL parameter which is defined 301 in [RFC7986] 303 5.1. Loctype 305 Parameter name: LOCTYPE 307 Purpose: To specify the type of location. 309 Format Definition: 311 This parameter is defined by the following notation: 313 loctypeparam = "LOCTYPE" "=" param-value 315 Description: This parameter MAY be specified on STRUCTURED-LOCATION 316 and provides a way to differentiate multiple properties. For 317 example, it allows event producers to provide location information 318 for the venue and the parking. 320 Values for this parameter are taken from the values defined in 321 [RFC4589]. New location types SHOULD be registered in the manner 322 laid down in that specification. 324 5.2. Restype 326 Parameter name: RESTYPE 328 Purpose: To specify the type of resource. 330 Format Definition: 332 This parameter is defined by the following notation: 334 restypeparam = "RESTYPE" "=" restypevalue CRLF 336 restypevalue = ("ROOM" 337 / "PROJECTOR" 338 / "REMOTE-CONFERENCE-AUDIO" 339 / "REMOTE-CONFERENCE-VIDEO" 340 / iana-token) ; Other IANA-registered 341 ; values 343 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 344 and provides a way to differentiate multiple properties. 346 The registered values are described below. New resource types 347 SHOULD be registered in the manner laid down in this 348 specification. 350 ROOM: A room for the event/meeting. 352 PROJECTOR: Projection equipment. 354 REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities. 356 REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities. 358 5.3. Order 360 Parameter name: ORDER 362 Purpose: To define ordering for the associated property. 364 Format Definition: 366 This parameter is defined by the following notation: 368 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 370 Description: The ORDER parameter is OPTIONAL and is used to indicate 371 the relative ordering of the corresponding instance of a property. 372 Its value MUST be an integer greater than or equal to 1 that 373 specifies the order with 1 being the first in the ordering. 375 When the parameter is absent, the default MUST be to interpret the 376 property instance as being at the lowest level of ordering, that 377 is, the property will appear after any other instances of the same 378 property with any value of ORDER. 380 When any ORDER parameters have the same value all the associated 381 properties appear as a group within which there is no defined 382 order. 384 Note that the value of this parameter is to be interpreted only in 385 relation to values assigned to other corresponding instances of 386 the same property in the same entity. 388 This parameter MUST NOT be applied to a property that does not 389 allow multiple instances. 391 Example uses: The ORDER may be applied to the PARTICIPANT-TYPE 392 property to indicate the relative importance of the participant, 393 for example as a sponsor or a performer. For example, ORDER=1 394 could define the principal performer or soloist. 396 5.4. Schema 398 Parameter Name: SCHEMA 400 Purpose: To specify the schema used for the content of a 401 "STRUCTURED-DATA" property value. 403 Format Definition: 405 This parameter is defined by the following notation: 407 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 409 Description: This property parameter SHOULD be specified on 410 "STRUCTURED-DATA" properties. When present it provides 411 identifying information about the nature of the content of the 412 corresponding "STRUCTURED-DATA" property value. This can be used 413 to supplement the media type information provided by the "FMTTYPE" 414 parameter on the corresponding property. 416 Example: 418 STRUCTURED-DATA;FMTTYPE=application/ld+json; 419 SCHEMA="https://schema.org/FlightReservation"; 420 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 422 5.5. Derived 424 Parameter Name: DERIVED 426 Purpose: To specify that the value of the associated property is 427 derived from some other property value or values. 429 Format Definition: 431 This parameter is defined by the following notation: 433 derivedparam = "DERIVED" "=" ("TRUE" / "FALSE") 434 ; Default is FALSE 436 Description: This property parameter can be specified on any 437 property when the value is derived from some other property or 438 properties. When present with a value of TRUE clients MUST NOT 439 update the property. 441 As an example, if a STYLED-DESCRIPTION property is present with 442 FMTTYPE="application/rtf" then there may be an additional STYLED- 443 DESCRIPTION property with FMTTYPE="text/html" and DERIVED=TRUE and 444 a value created from the rtf value. 446 Example: 448 STYLED-DESCRIPTION;FMTTYPE=text/html; 449 DERIVED=TRUE:... 451 6. Redefined Property SOURCE 453 The SOURCE property defined in [RFC7986] is redefined to allow 454 VALUE=TEXT and broaden its usage to any component. 456 Property name: SOURCE 458 Purpose: This property provides a reference to information about a 459 component such as a participant. For example, that information 460 may be a vcard or a plain text typed value. 462 For value type URI and embedded in a VEVENT or VTODO it may 463 provide a location from which the compoent may be refreshed. 465 Value type: There is no default value type for this property. It 466 may be set to URI as in [RFC7986]. The value type can also be set 467 to TEXT to indicate plain text content. 469 Property Parameters: Non-standard or format type parameters can be 470 specified on this property. 472 Conformance: This property can be specified once in an iCalendar 473 object. 475 Description: This property provides information about the component 476 in which it appears. 478 In a PARTICIPANT component it may provide a reference to a vcard 479 giving directory information. 481 In a VCALENDAR component this property identifies a location where 482 a client can retrieve updated data for the calendar. Clients 483 SHOULD honor any specified "REFRESH-INTERVAL" value when 484 periodically retrieving data. Note that this property differs 485 from the "URL" property in that "URL" is meant to provide an 486 alternative representation of the calendar data rather than the 487 original location of the data. 489 In a calendar entity component such as an event the SOURCE 490 property may provide a reference to the original source of the 491 event. This may be used by aggregators to provide a link back. 493 Format Definition: 495 This property is defined by the following notation: 497 source = "SOURCE" sourceparam 498 ( 499 ( 500 ";" "VALUE" "=" "URI" 501 ":" uri 502 ) / 503 ( 504 ";" "VALUE" "=" "TEXT" 505 ":" text 506 ) 507 ) 508 CRLF 510 sourceparam = *( 511 ; 512 ; the following are OPTIONAL 513 ; but MUST NOT occur more than once 514 ; 515 (";" fmttypeparam) / 516 ; 517 ; the following is OPTIONAL 518 ; and MAY occur more than once 519 ; 520 (";" other-param) 521 ; 522 ) 524 Example: 526 The following is an example referring to a VCARD. 528 SOURCE;FMTTYPE=text/vcard;VALUE=URL: 529 http://dir.example.com/vcard/contacts/contact1.vcf 531 7. New Properties 533 7.1. Participant Type 535 Property name: PARTICIPANT-TYPE 537 Purpose: To specify the type of participant. 539 Value type: The value type for this property is TEXT. The allowable 540 values are defined below. 542 Property Parameters: Non-standard parameters can be specified on 543 this property. 545 Conformance: This property MUST be specified once within a 546 PARTICIPANT component. 548 Description: This property defines the type of participation in 549 events or tasks. Participants can be individuals or 550 organizations, for example a soccer team, the spectators, or the 551 musicians. 553 Format Definition: 555 This property is defined by the following notation: 557 participanttype = "PARTICIPANT-TYPE" partvalueparam ":" 558 partvalue CRLF 560 partvalue = ("ACTIVE" 561 / "INACTIVE" 562 / "SPONSOR" 563 / "CONTACT" 564 / "BOOKING-CONTACT" 565 / "EMERGENCY-CONTACT" 566 / "PUBLICITY-CONTACT" 567 / "PLANNER-CONTACT" 568 / "PERFORMER" 569 / "SPEAKER" 570 / iana-token) ; Other IANA-registered 571 ; values 573 partvalueparam = *( 574 ; the following is OPTIONAL 575 ; and MAY occur more than once 576 ; 577 (";" other-param) 578 ) 580 Example: 582 The following is an example of this property: 584 PARTICIPANT-TYPE:SPEAKER 586 The registered values for the PARTICIPANT-TYPE property have the 587 meanings described here: 589 ACTIVE: A participant taking an active role - for example a team 590 member. 592 INACTIVE: A participant taking an inactive part - for example an 593 audience member. 595 SPONSOR: A sponsor of the event. The ORDER parameter may be used 596 with this participant type to define the relative order of 597 multiple sponsors. 599 CONTACT: Contact information for the event. The ORDER parameter may 600 be used with this participant type to define the relative order of 601 multiple contacts. 603 BOOKING-CONTACT: Contact information for reservations or payment 605 EMERGENCY-CONTACT: Contact in case of emergency 607 PUBLICITY-CONTACT: Contact for publicity 609 PLANNER-CONTACT: Contact for the event planner or organizer 611 PERFORMER: A performer - for example the soloist or the accompanist. 612 The ORDER parameter may be used with this participant type to 613 define the relative order of multiple performers. For example, 614 ORDER=1 could define the principal performer or soloist. 616 SPEAKER: Speaker at an event 618 7.2. Calendar Address 620 Property name: CALENDAR-ADDRESS 622 Purpose: To specify the calendar address for a participant. 624 Value type: CAL-ADDRESS 626 Property Parameters: IANA or non-standard property parameters can be 627 specified on this property. 629 Conformance: This property MAY be specified once within a 630 PARTICIPANT component. 632 Description: This property provides a calendar user address for the 633 participant. If there is an ATTENDEE property with the same value 634 then the participant is schedulable. 636 Format Definition: 638 This property is defined by the following notation: 640 calendaraddress = "CALENDAR-ADDRESS" caladdressparam ":" 641 cal-address CRLF 643 caladdressparam = *( 644 ; the following is OPTIONAL 645 ; and MAY occur more than once 646 ; 647 (";" other-param) 648 ) 650 7.3. Styled-Description 652 Property name: STYLED-DESCRIPTION 654 Purpose: This property provides for one or more rich-text 655 descriptions to replace that provided by the DESCRIPTION property. 657 Value type: There is no default value type for this property. The 658 value type can be set to URI or TEXT. Other text-based value 659 types can be used when defined in the future. Clients MUST ignore 660 any properties with value types they do not understand. 662 Property Parameters: IANA, non-standard, id, alternate text 663 representation, format type, derived and language property 664 parameters can be specified on this property. 666 Conformance: The property can be specified multiple times in the 667 "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", "PARTICIPANT", or 668 "VALARM" calendar components. 670 If it does appear more than once there MUST be exactly one 671 instance of the property with no DERIVED parameter or 672 DERIVED=FALSE. All others MUST have DERIVED=TRUE. 674 Additionally, if there is one or more STYLED-DESCRIPTION property 675 then the DESCRIPTION property should be either absent or have the 676 parameter DERIVED=TRUE. 678 Description: This property supports rich-text descriptions, for 679 example HTML. Event publishers typically wish to provide more and 680 better formatted information about the event. 682 This property is used in the "VEVENT" and "VTODO" to capture 683 lengthy textual descriptions associated with the activity. This 684 property is used in the "VJOURNAL" calendar component to capture 685 one or more textual journal entries. This property is used in the 686 "VALARM" calendar component to capture the display text for a 687 DISPLAY category of alarm, and to capture the body text for an 688 EMAIL category of alarm. In the PARTICIPANT component it provides 689 a detailed description of the participant. 691 VALUE=TEXT is used to provide rich-text inline as the property 692 value. 694 VALUE=URI is used to provide a link to rich-text content which is 695 expected to be displayed inline as part of the event. 697 In either case the DESCRIPTION property should be absent or 698 contain a plain text rendering of the styled text. 700 Applications MAY attempt to guess the media type of the resource 701 via inspection of its content if and only if the media type of the 702 resource is not given by the "FMTTYPE" parameter. If the media 703 type remains unknown, calendar applications SHOULD treat it as 704 type "text/html" and process the content as defined in 705 [W3C.REC-html51-20171003] 707 Multiple STYLED-DESCRIPTION properties may be used to provide 708 different formats or different language variants. However all but 709 one MUST have DERIVED=TRUE. 711 Format Definition: 713 This property is defined by the following notation: 715 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 716 styleddescval CRLF 718 styleddescparam = *( 719 ; The following is REQUIRED, 720 ; but MUST NOT occur more than once. 721 ; 722 (";" "VALUE" "=" ("URI" / "TEXT")) / 723 ; 724 ; The following are OPTIONAL, 725 ; but MUST NOT occur more than once. 726 ; 727 (";" altrepparam) / (";" languageparam) / 728 (";" fmttypeparam) / (";" derivedparam) / 729 ; 730 ; the following is OPTIONAL 731 ; and MAY occur more than once 732 ; 733 (";" other-param) 734 ) 736 styleddescval = ( uri / text ) 737 ;Value MUST match value type 739 Example: 741 The following is an example of this property. It points to an html 742 description. 744 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 746 7.4. Structured-Location 748 Property name: STRUCTURED-LOCATION 750 Purpose: This property provides a typed reference to external 751 information about the location of an event or optionally a plain 752 text typed value. 754 Value type: There is no default value type for this property. The 755 value type can be set to URI or TEXT. 757 Property Parameters: IANA, non-standard, label, loctype, related or 758 format type parameters can be specified on this property. 760 Conformance: This property MAY be specified zero or more times in 761 any iCalendar component. 763 Description: There may be a number of locations associated with an 764 event. This provides detailed information about these locations. 766 When used in a component the value of this property provides 767 information about the event venue or of related services such as 768 parking, dining, stations etc.. 770 When a LABEL parameter is supplied the language of the label 771 SHOULD match that of the content and of the LANGUAGE parameter if 772 present. 774 Use of the related parameter: This allows a location to define the 775 start and/or end timezone of the associated component. If a 776 location is specified with a RELATED parameter then the affected 777 DTSTART or DTEND properties MUST be specified as floating DATE- 778 TIME value. 780 If the RELATED parameter is present with a value of START, then 781 the "DTSTART" property MUST be present in the associated "VEVENT" 782 or "VTODO" calendar component. 784 For an event, if the RELATED parameter is present with a value of 785 END, then the "DTEND" property or the "DTSTART" and "DURATION " 786 properties MUST be present in the associated "VEVENT" calendar 787 component. 789 For a to-do with a RELATED value of END, then either the "DUE" 790 property or the "DTSTART" and "DURATION " properties MUST be 791 present in the associated "VTODO" calendar component. 793 If there is a location specified with RELATED=START and no 794 location is specified with RELATED=END then the event is assumed 795 to start and end in the same timezone. 797 Format Definition: 799 This property is defined by the following notation: 801 strucloc = "STRUCTURED-LOCATION" struclocparam ":" 802 struclocval CRLF 804 struclocparam = *( 805 ; The following is REQUIRED, 806 ; but MUST NOT occur more than once. 807 ; 808 (";" "VALUE" "=" ("URI" / "TEXT")) / 809 ; 810 ; the following are OPTIONAL 811 ; but MUST NOT occur more than once 812 ; 813 (";" fmttypeparam) / 814 (";" labelparam) / 815 (";" languageparam) / 816 (";" trigrelparam) / 817 (";" loctypeparam) / 818 ; 819 ; the following is OPTIONAL 820 ; and MAY occur more than once 821 ; 822 (";" other-param) 823 ) 825 struclocval = ( uri / text ) 826 ;Value MUST match value type 828 Example: 830 The following is an example of this property. It points to a venue. 832 STRUCTURED-LOCATION;LABEL="The venue"; 833 VALUE=URI: 834 http://dir.example.com/venues/big-hall.vcf 836 7.5. Structured-Resource 838 Property name: STRUCTURED-RESOURCE 840 Purpose: This property provides a typed reference to external 841 information about a resource or optionally a plain text typed 842 value. Typically a resource is anything that might be required or 843 used by a calendar entity and possibly has a directory entry. 845 Value type: There is no default value type for this property. The 846 value type can be set to URI or TEXT. 848 Property Parameters: IANA, non-standard, label, restype or format 849 type parameters can be specified on this property. 851 Conformance: The property can be specified multiple times in the 852 "VEVENT" or "VTODO" calendar components. 854 Description: When used in a component the value of this property 855 provides information about resources used for the event such as 856 rooms, projectors, conferencing capabilities. 858 Such resources may be a room or a projector. This RESTYPE value 859 registry provides a place in which resource types may be 860 registered for use by scheduling sevices. 862 When a LABEL parameter is supplied the language of the label must 863 match that of the content and of the LANGUAGE parameter if 864 present. 866 Format Definition: 868 This property is defined by the following notation: 870 strucres = "STRUCTURED-RESOURCE" strucresparam ":" 871 strucresval CRLF 873 strucresparam = *( 874 ; The following is REQUIRED, 875 ; but MUST NOT occur more than once. 876 ; 877 (";" "VALUE" "=" ("URI" / "TEXT")) / 878 ; 879 ; the following are OPTIONAL 880 ; but MUST NOT occur more than once 881 ; 882 (";" fmttypeparam) / 883 (";" labelparam) / 884 (";" languageparam) / 885 (";" restypeparam) / 886 ; 887 ; the following is OPTIONAL 888 ; and MAY occur more than once 889 ; 890 (";" other-param) 891 ) 893 strucewaval = ( uri / text ) 894 ;Value MUST match value type 896 Example: 898 The following is an example of this property. It refers to a 899 projector. 901 STRUCTURED-RESOURCE;value=uri;restype="projector": 902 http://dir.example.com/projectors/3d.vcf 904 7.6. Structured-Data 906 Property Name: STRUCTURED-DATA 908 Purpose: This property specifies ancillary data associated with the 909 calendar component. 911 Value Type: TEXT, BINARY or URI 913 Property Parameters: IANA, non-standard, inline encoding, and value 914 data type property parameters can be specified on this property. 916 The format type and schema parameters can be specified on this 917 property and are RECOMMENDED for text or inline binary encoded 918 content information. 920 Conformance: This property can be specified multiple times in an 921 iCalendar object. Typically it would be used in "VEVENT", 922 "VTODO", or "VJOURNAL" calendar components. 924 Description: The existing properties in iCalendar cover key elements 925 of events and tasks such as start time, end time, location, 926 summary, etc. However, different types of events often have other 927 specific "fields" that it is useful to include in the calendar 928 data. For example, an event representing an airline flight could 929 include the airline, flight number, departure and arrival airport 930 codes, check-in and gate-closing times etc. As another example, a 931 sporting event might contain information about the type of sport, 932 the home and away teams, the league the teams are in, information 933 about nearby parking, etc. 935 This property is used to specify ancillary data in some structured 936 format either directly (inline) as a "TEXT" or "BINARY" value, or 937 as a link via a "URI" value. 939 Rather than define new iCalendar properties for the variety of 940 event types that might occur, it would be better to leverage 941 existing schemas for such data. For example, schemas available at 942 https://schema.org include different event types. By using 943 standard schemas, interoperability can be improved between 944 calendar clients and non-calendaring systems that wish to generate 945 or process the data. 947 This property allows the direct inclusion of ancillary data whose 948 schema is defined elsewhere. This property also includes 949 parameters to clearly identify the type of the schema being used 950 so that clients can quickly and easily spot what is relevant 951 within the calendar data and present that to users or process it 952 within the calendaring system. 954 iCalendar does support an "ATTACH" property which can be used to 955 include documents or links to documents within the calendar data. 956 However, that property does not allow data to be included as a 957 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 958 attachments are often treated as "opaque" data to be processed by 959 some other system rather than the calendar client. Thus the 960 existing "ATTACH" property is not sufficient to cover the specific 961 needs of inclusion of schema data. Extending the "ATTACH" 962 property to support a new value type would likely cause 963 interoperability problems. Thus a new property to support 964 inclusion of schema data is warranted. 966 Format Definition: 968 This property is defined by the following notation: 970 sdataprop = "STRUCTURED-DATA" sdataparam 971 (":" text) / 972 ( 973 ";" "ENCODING" "=" "BASE64" 974 ";" "VALUE" "=" "BINARY" 975 ":" binary 976 ) / 977 ( 978 ";" "VALUE" "=" "URI" 979 ":" uri 980 ) 981 CRLF 983 sdataparam = *( 984 ; 985 ; The following is OPTIONAL for a URI value, 986 ; RECOMMENDED for a TEXT or BINARY value, 987 ; and MUST NOT occur more than once. 988 ; 989 (";" fmttypeparam) / 990 (";" schemaparam) / 991 ; 992 ; The following is OPTIONAL, 993 ; and MAY occur more than once. 994 ; 995 (";" other-param) 996 ; 997 ) 999 Example: The following is an example of this property: 1001 STRUCTURED-DATA;FMTTYPE=application/ld+json; 1002 SCHEMA="https://schema.org/SportsEvent"; 1003 VALUE=TEXT:{\n 1004 "@context": "http://schema.org"\,\n 1005 "@type": "SportsEvent"\,\n 1006 "homeTeam": "Pittsburgh Pirates"\,\n 1007 "awayTeam": "San Francisco Giants"\n 1008 }\n 1010 8. New Components 1012 8.1. Participant 1014 Component name: PARTICIPANT 1016 Purpose: This component provides information about a participant in 1017 an event or task. 1019 Conformance: This component can be specified multiple times in a 1020 "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component. 1022 Description: This component provides information about a participant 1023 in an event, task or poll. A participant may be an attendee in a 1024 scheduling sense and the ATTENDEE property may be specified in 1025 addition. Participants in events can be individuals or 1026 organizations, for example a soccer team, the spectators, or the 1027 musicians. 1029 The SOURCE property if present may refer to an external definition 1030 of the participant - such as a vcard. 1032 The CALENDAR-ADDRESS property if present will provide a cal- 1033 address. If an ATTENDEE property has the same value the 1034 participant is considered schedulable. The PARTICIPANT component 1035 can be used to contain additional meta-data related to the 1036 attendee. 1038 Format Definition: 1040 This component is defined by the following notation: 1042 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 1043 partprop 1044 "END" ":" "PARTICIPANT" CRLF 1046 partprop = *( 1047 ; 1048 ; The following are REQUIRED, 1049 ; but MUST NOT occur more than once. 1050 ; 1051 dtstamp / participanttype / uid / 1052 ; 1053 ; The following are OPTIONAL, 1054 ; but MUST NOT occur more than once. 1055 ; 1056 created / description / geo / last-mod / priority / seq / 1057 source / status / calendaraddress / summary / url / 1058 ; 1059 ; The following are OPTIONAL, 1060 ; and MAY occur more than once. 1061 ; 1062 attach / categories / comment / 1063 contact / location / rstatus / related / 1064 resources / strucloc / strucres / styleddescription / 1065 iana-prop 1066 ; 1067 ) 1069 Note: When the PRIORITY is supplied it defines the ordering of 1070 PARTICIPANT components with the same value for the TYPE parameter. 1072 Privacy Issues: When a LOCATION is supplied it provides information 1073 about the location of a participant at a given time or times. 1074 This may represent an unacceptable privacy risk for some 1075 participants. User agents MUST NOT include this information 1076 without informing the participant. 1078 Example: 1080 The following is an example of this component. It contains a SOURCE 1081 property which points to a VCARD providing information about the 1082 event participant. 1084 BEGIN:PARTICIPANT 1085 PARTICIPANT-TYPE:PERFORMER 1086 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 1087 END:PARTICIPANT 1089 Example: 1091 The following is an example for the primary contact. 1093 BEGIN: PARTICIPANT 1094 SOURCE;FMTTYPE=text/vcard; 1095 http://dir.example.com/vcard/contacts/contact1.vcf 1096 PARTICIPANT-TYPE:CONTACT 1097 DESCRIPTION:A contact: 1098 END:PARTICIPANT 1100 8.2. Schedulable Participant 1102 A PARTICIPANT component may represent someone or something that needs 1103 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 1104 The PARTICIPANT component may also represent someone or something 1105 that is NOT to receive scheduling messages. 1107 A PARTICIPANT component is defined to be schedulable if 1109 o It contains a CALENDAR-ADDRESS property 1111 o That property value is the same as the value for an ATTENDEE 1112 property. 1114 If both of these conditions apply then the participant defined by the 1115 value of the URL property will take part in scheduling operations as 1116 defined in [RFC5546]. 1118 An appropriate use for the PARTICIPANT component in scheduling would 1119 be to store SEQUENCE and DTSTAMP properties associated with replies 1120 from each ATTENDEE. A LOCATION property within the PARTICIPANT 1121 component might allow better selection of meeting times when 1122 participants are in different timezones. 1124 9. Extended examples 1126 The following are some examples of the use of the properties defined 1127 in this specification. They include additional properties defined in 1128 [RFC7986] which includes IMAGE. 1130 9.1. Example 1 1132 The following is an example of a VEVENT describing a concert. It 1133 includes location information for the venue itself as well as 1134 references to parking and restaurants. 1136 BEGIN:VEVENT 1137 CREATED:20170216T145739Z 1138 DESCRIPTION: Piano Sonata No 3\n 1139 Piano Sonata No 30 1140 DTSTAMP:20171116T145739Z 1141 DTSTART;TZID=America/New_York:20170315T150000Z 1142 DTEND;TZID=America/New_York:20170315T163000Z 1143 LAST-MODIFIED:20170216T145739Z 1144 SUMMARY:Beethoven Piano Sonatas 1145 UID:123456 1146 STRUCTURED-LOCATION;LABEL="The venue";VALUE=URI: 1147 http://dir.example.com/venues/big-hall.vcf 1148 STRUCTURED-LOCATION;LABEL="Parking for the venue";VALUE=URI: 1149 http://dir.example.com/venues/parking.vcf 1150 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 1151 ttp://example.com/images/concert.png 1152 BEGIN:PARTICIPANT 1153 PARTICIPANT-TYPE:SPONSOR 1154 SOURCE:http://example.com/sponsor.vcf 1155 END:PARTICIPANT 1156 BEGIN:PARTICIPANT 1157 PARTICIPANT-TYPE:PERFORMER: 1158 SOURCE:http://www.example.com/people/johndoe.vcf 1159 END:PARTICIPANT 1160 END:VEVENT 1162 9.2. Example 2 1163 The following is an example of a VEVENT describing a meeting. One of 1164 the attendees is a remote participant. 1166 BEGIN:VEVENT 1167 CREATED:20170216T145739Z 1168 DTSTAMP:20101116T145739Z 1169 DTSTART;TZID=America/New_York:20170315T150000Z 1170 DTEND;TZID=America/New_York:20170315T163000Z 1171 LAST-MODIFIED:20170216T145739Z 1172 SUMMARY:Conference plaaning 1173 UID:123456 1174 ORGANIZER:mailto:a@example.com 1175 ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com 1176 ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com 1177 BEGIN:PARTICIPANT 1178 PARTICIPANT-TYPE:ACTIVE: 1179 SOURCE:http://www.example.com/people/b.vcf 1180 LOCATION:At home 1181 END:PARTICIPANT 1182 END:VEVENT 1184 10. Security Considerations 1186 Applications using these properties need to be aware of the risks 1187 entailed in using the URIs provided as values. See [RFC3986] for a 1188 discussion of the security considerations relating to URIs. 1190 Security considerations relating to the "ATTACH" property, as 1191 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 1192 property. 1194 When processing HTML content applications need to be aware of the 1195 many security and privacy issues as described in the IANA 1196 considerations section of [W3C.REC-html51-20171003] 1198 11. Privacy Considerations 1200 Properties with a "URI" value type can expose their users to privacy 1201 leaks as any network access of the URI data can be tracked. Clients 1202 SHOULD NOT automatically download data referenced by the URI without 1203 explicit instruction from users. This specification does not 1204 introduce any additional privacy concerns beyond those described in 1205 [RFC5545]. 1207 The addition of location information to the new participant component 1208 provides information about the location of participants at a given 1209 time. 1211 12. IANA Considerations 1213 12.1. Additional iCalendar Registrations 1215 12.1.1. Properties 1217 This document defines the following new iCalendar properties to be 1218 added to the registry defined in Section 8.2.3 of [RFC5545]: 1220 +---------------------+---------+----------------------+ 1221 | Property | Status | Reference | 1222 +---------------------+---------+----------------------+ 1223 | CALENDAR-ADDRESS | Current | RFCXXXX, Section 7.2 | 1224 | PARTICIPANT-TYPE | Current | RFCXXXX, Section 7.1 | 1225 | SOURCE | Current | RFCXXXX, Section 6 | 1226 | STRUCTURED-DATA | Current | RFCXXXX, Section 7.6 | 1227 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 7.3 | 1228 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 7.4 | 1229 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 7.5 | 1230 +---------------------+---------+----------------------+ 1232 12.1.2. Parameters 1234 This document defines the following new iCalendar property parameters 1235 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1237 +--------------------+---------+----------------------+ 1238 | Property Parameter | Status | Reference | 1239 +--------------------+---------+----------------------+ 1240 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1241 | ORDER | Current | RFCXXXX, Section 5.3 | 1242 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1243 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1244 +--------------------+---------+----------------------+ 1246 12.1.3. Components 1248 This document defines the following new iCalendar components to be 1249 added to the registry defined in Section 8.3.1 of [RFC5545]: 1251 +-------------+---------+----------------------+ 1252 | Component | Status | Reference | 1253 +-------------+---------+----------------------+ 1254 | PARTICIPANT | Current | RFCXXXX, Section 8.1 | 1255 +-------------+---------+----------------------+ 1257 12.2. New Registration Tables 1259 This section defines new registration tables for PARTICIPANT-TYPE and 1260 RESTYPE values. These tables are updated using the same approaches 1261 laid down in Section 8.2.1 of [RFC5545] 1263 12.2.1. Participant Types 1265 The following table has been used to initialize the participant types 1266 registry. 1268 +-------------------+---------+----------------------+ 1269 | Participant Type | Status | Reference | 1270 +-------------------+---------+----------------------+ 1271 | ACTIVE | Current | RFCXXXX, Section 7.1 | 1272 | INACTIVE | Current | RFCXXXX, Section 7.1 | 1273 | SPONSOR | Current | RFCXXXX, Section 7.1 | 1274 | CONTACT | Current | RFCXXXX, Section 7.1 | 1275 | BOOKING-CONTACT | Current | RFCXXXX, Section 7.1 | 1276 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 7.1 | 1277 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 7.1 | 1278 | PLANNER-CONTACT | Current | RFCXXXX, Section 7.1 | 1279 | PERFORMER | Current | RFCXXXX, Section 7.1 | 1280 | SPEAKER | Current | RFCXXXX, Section 7.1 | 1281 +-------------------+---------+----------------------+ 1283 12.2.2. Resource Types 1285 The following table has been used to initialize the resource types 1286 registry. 1288 +-------------------------+---------+----------------------+ 1289 | Resource Type | Status | Reference | 1290 +-------------------------+---------+----------------------+ 1291 | PROJECTOR | Current | RFCXXXX, Section 5.2 | 1292 | ROOM | Current | RFCXXXX, Section 5.2 | 1293 | REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 5.2 | 1294 | REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 5.2 | 1295 +-------------------------+---------+----------------------+ 1297 13. Acknowledgements 1299 The author would like to thank Chuck Norris of eventful.com for his 1300 work which led to the development of this RFC. 1302 The author would also like to thank the members of CalConnect, The 1303 Calendaring and Scheduling Consortium, the Event Publication 1304 technical committee and the following individuals for contributing 1305 their ideas and support: 1307 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis. 1309 14. References 1311 14.1. Normative References 1313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1314 Requirement Levels", BCP 14, RFC 2119, 1315 DOI 10.17487/RFC2119, March 1997, 1316 . 1318 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 1319 RFC 2426, DOI 10.17487/RFC2426, September 1998, 1320 . 1322 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1323 Resource Identifier (URI): Generic Syntax", STD 66, 1324 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1325 . 1327 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1328 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1329 . 1331 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1332 Scheduling Core Object Specification (iCalendar)", 1333 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1334 . 1336 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1337 Interoperability Protocol (iTIP)", RFC 5546, 1338 DOI 10.17487/RFC5546, December 2009, 1339 . 1341 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 1342 DOI 10.17487/RFC7986, October 2016, 1343 . 1345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1347 May 2017, . 1349 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1350 Interchange Format", STD 90, RFC 8259, 1351 DOI 10.17487/RFC8259, December 2017, 1352 . 1354 [W3C.REC-html51-20171003] 1355 Faulkner, S., Eicholz, A., Leithead, T., and A. Danilo, 1356 "HTML 5.1 2nd Edition", World Wide Web Consortium 1357 Recommendation REC-html51-20171003, October 2017, 1358 . 1360 [W3C.REC-xml-20081126] 1361 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1362 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1363 Edition)", World Wide Web Consortium Recommendation REC- 1364 xml-20081126, November 2008, 1365 . 1367 14.2. Informative References 1369 [iana-property-registry] 1370 "IANA iCalendar Element Registries", 1371 . 1374 Appendix A. Open issues 1376 None at the moment 1378 Appendix B. Change log 1380 calext-v13 2019-05-26 MD 1382 o Respond to various issues. 1384 calext-v12 2019-02-28 MD 1386 o Fix styled-description example. Respond to various AD issues. 1387 Some typos. 1389 calext-v11 2019-02-27 MD 1391 o Add DERIVED parameter for styled-description, RELATED parameter 1392 for structured-location 1394 calext-v09 2018-08-30 MD 1396 o Sorted out inconsistencies in refs to 5546 1397 calext-v08 2018-07-06 MD 1399 o Add some text for equal ORDER values 1401 o Switched scheduleaddress to calendaraddress in participant abnf. 1402 Also added more properties 1404 o Fixed PARTICIPANT abnf 1406 calext-v04 2017-10-11 MD 1408 o Change SCHEDULE-ADDRESS to CALENDAR-ADDRESS 1410 o Explicitly broaden scope of SOURCE 1412 o Add initial registry for RESTYPE and move new tables into separate 1413 section. 1415 o Fix PARTTYPE/PARTICPANT-TYPE inconsistency 1417 calext-v03 2017-10-09 MD 1419 o Mostly typographical and other minor changes 1421 calext-v02 2017-04-20 MD 1423 o Add SCHEDULE-ADDRESS property 1425 o PARTICIPANT becomes a component rather than a property. Turn many 1426 of the former parameters into properties. 1428 o Use existing ATTENDEE property for scheduling. 1430 calext-v01 2017-02-18 MD 1432 o Change ASSOCIATE back to PARTICIPANT 1434 o PARTICIPANT becomes a component rather than a property. Turn many 1435 of the former parameters into properties. 1437 calext-v00 2016-08-?? MD 1439 o Name changed - taken up by calext working group 1441 v06 2016-06-26 MD 1443 o Fix up abnf 1444 o change ref to ietf from daboo 1446 o take out label spec - use Cyrus spec 1448 v05 2016-06-14 MD 1450 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1452 o Change ORDER to integer >= 1. 1454 o Incorporate Structured-Data into this specification. 1456 v04 2014-02-01 MD 1458 o Added updates attribute. 1460 o Minor typos. 1462 o Resubmitted mostly to refresh the draft. 1464 v03 2013-03-06 MD 1466 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1468 o Added section showing modifications to components. 1470 o Replace ID with GROUP and modify HASH. 1472 o Replace TITLE param with LABEL. 1474 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1476 v02 2012-11-02 MD 1478 o Collapse sections with description of properties and the use cases 1479 into a section with sub-sections. 1481 o New section to describe relating properties. 1483 o Remove idref and upgrade hash to have the reference 1485 o No default value types on properties.. 1487 v01 2012-10-18 MD Many changes. 1489 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1491 o Add a STRUCTURED-RESOURCE property 1492 o STYLED-DESCRIPTION to handle rich text 1494 o Much more... 1496 2011-01-07 1498 o Remove MEDIA - it's going in the Cyrus RFC 1500 o Rename EXTENDED-... to STRUCTURED-... 1502 o Add TYPE parameter to SPONSOR 1504 v00 2007-10-19 MD Initial version 1506 Author's Address 1508 Michael Douglass 1509 Spherical Cow Group 1510 226 3rd Street 1511 Troy, NY 12180 1512 USA 1514 Email: mdouglass@sphericalcowgroup.com 1515 URI: http://sphericalcowgroup.com