idnits 2.17.1 draft-ietf-calext-eventpub-extensions-12.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (April 8, 2019) is 1817 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: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 (if approved) April 8, 2019 5 Intended status: Standards Track 6 Expires: October 10, 2019 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-12 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 October 10, 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 . . . . . . . . . . . . 4 57 2. Components and properties . . . . . . . . . . . . . . . . . . 4 58 3. Typed References . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 6 61 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.2.1. Reserving facilities . . . . . . . . . . . . . . 6 63 4. Modifications to Calendar Components . . . . . . . . . . . . 6 64 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 65 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.5. Derived . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Redefined Property SOURCE . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 18 77 7.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 20 78 8. New Components . . . . . . . . . . . . . . . . . . . . . . . 22 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 are likely to be most useful 120 to the receivers of such events as they may be used in other 121 applications - such as address books. 123 This specification defines a new PARTICIPANT component. Many people 124 or groups may participate in an event. This component provides 125 detailed information. Such participants may act as attendees to the 126 event (or derived events) or may just provide a reference - perhaps 127 for mailing lists. 129 Additionally this specification defines a new use for the RELATED 130 parameter to allow locations to be defined as the start and/or end 131 location of a component. 133 The following properties are defined in this specification 135 STYLED-DESCRIPTION: Supports rich-text descriptions, for example 136 HTML. Event publishers typically wish to provide more and better 137 formatted information about the event. 139 STRUCTURED-LOCATION: There may be a number of locations associated 140 with an event. This provides detailed information about the 141 location. 143 STRUCTURED-RESOURCE: Events need resources such as rooms, 144 projectors, conferencing capabilities. 146 STRUCTURED-DATA: The existing properties in iCalendar cover key 147 elements of events and tasks such as start time, end time, 148 location, summary, etc. However, different types of events often 149 have other specific "fields" that it is useful to include in the 150 calendar data. For example, an event representing an airline 151 flight could include the airline, flight number, departure and 152 arrival airport codes, check-in and gate-closing times etc. As 153 another example, a sporting event might contain information about 154 the type of sport, the home and away teams, the league the teams 155 are in, information about nearby parking, etc. 157 PARTICIPANT-TYPE: Used in the PARTICIPANT component to define the 158 type. 160 CALENDAR-ADDRESS: Used in the PARTICIPANT component to provide the 161 calendar address of the participant. 163 In addition the SOURCE property defined in [RFC7986] is redefined to 164 allow VALUE=TEXT and broaden its usage. 166 1.1. Conventions Used in This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 2. Components and properties 176 Previous extensions to the calendaring standards have been largely 177 restricted to the addition of properties or parameters. This is 178 partly because iCalendar libraries had trouble handling components 179 nested deeper than those defined in [RFC5545] 181 In a break with this 'tradition' this specification introduces one of 182 these extensions as a component rather than a property. This is a 183 better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] 184 handles such structures and allows richer definitions. 186 It also allows for the addition of extra properties inside the 187 component and resolves some of the problems of trying to add detailed 188 information as a parameter. 190 3. Typed References 192 The properties defined here can all reference external meta-data 193 which may be used by applications to provide enhanced value to users. 194 By providing type information as parameters, clients and servers are 195 able to discover interesting references and make use of them, perhaps 196 for indexing or the presenting of additional related information for 197 the user. 199 The [RFC5545] LOCATION property provides only an unstructured single 200 text value for specifying the location where an event (or task) will 201 occur. This is inadequate for use cases where structured location 202 information (e.g. address, region, country, postal code) is required 203 or preferred, and limits widespread adoption of iCalendar in those 204 settings. 206 Using STRUCTURED-LOCATION, information about a number of interesting 207 locations can be communicated, for example, address, region, country, 208 postal code as well as other informations such as the parking, 209 restaurants and the venue. Servers and clients can retrieve the 210 objects when storing the event and use them to index by geographic 211 location. 213 When a calendar client receives a calendar component it can search 214 the set of supplied properties looking for those of particular 215 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 216 to help the selection. 218 The PARTICIPANT component is designed to handle common use cases in 219 event publication. It is generally important to provide information 220 about the organizers of such events. Sponsors wish to be referenced 221 in a prominent manner. In social calendaring it is often important 222 to identify the active participants in the event, for example a 223 school sports team, and the inactive participants, for example the 224 parents. 226 The PARTICIPANT component can also be used to provide useful extra 227 data about an attendee. For example a LOCATION property inside the 228 PARTICIPANT gives the actual location of a remote attendee. (But see 229 the note about privacy.) 231 3.1. Use Cases 233 The main motivation for these properties has been event publication 234 but there are opportunities for use elsewhere. The following use 235 cases will describe some possible scenarios. 237 3.1.1. Piano Concert Performance 239 In putting together a concert there are many participants: piano 240 tuner, performer, stage hands etc. In addition there are sponsors 241 and various contacts to be provided. There will also be a number of 242 related locations. A number of events can be created, all of which 243 relate to the performance in different ways. 245 There may be an iTip [RFC5546] meeting request for the piano tuner 246 who will arrive before the performance. Other members of staff may 247 also receive meeting requests. 249 An event can also be created for publication which will have a 250 PARTICIPANT component for the pianist providing a reference to vcard 251 information about the performer. This event would also hold 252 information about parking, local subway stations and the venue 253 itself. In addition, there will be sponsorship information for 254 sponsors of the event and perhaps paid sponsorship properties 255 essentially advertising local establishments. 257 3.1.2. Itineraries 259 These additions also provide opportunities for the travel industry. 260 When booking a flight the PARTICIPANT component can be used to 261 provide references to businesses at the airports and to car hire 262 businesses at the destination. 264 The embedded location information can guide the traveller at the 265 airport or to their final destination. The contact information can 266 provide detailed information about the booking agent, the airlines, 267 car hire companies and the hotel. 269 3.1.2.1. Reserving facilities 271 For a meeting, the size of a room and the equipment needed depends to 272 some extent on the number of attendees actually in the room. 274 A meeting may have 10 attendees non of which are co-located. The 275 current ATTENDEE property does not allow for the addition of such 276 meta-data. The PARTICIPANT property allows attendees to specify 277 their location. 279 4. Modifications to Calendar Components 281 The following changes to the syntax defined in iCalendar [RFC5545] 282 are made here. New elements are defined in subsequent sections. 284 eventc = "BEGIN" ":" "VEVENT" CRLF 285 eventprop *alarmc *participantc 286 "END" ":" "VEVENT" CRLF 288 eventprop =/ *( 289 ; 290 ; The following are OPTIONAL, 291 ; and MAY occur more than once. 292 ; 293 styleddescription / strucloc / strucres / sdataprop 294 ; 295 ) 297 todoc = "BEGIN" ":" "VTODO" CRLF 298 todoprop *alarmc *participantc 299 "END" ":" "VTODO" CRLF 301 todoprop =/ *( 302 ; 303 ; The following are OPTIONAL, 304 ; and MAY occur more than once. 305 ; 306 styleddescription / strucloc / strucres / sdataprop 307 ; 308 ) 310 journalc = "BEGIN" ":" "VJOURNAL" CRLF 311 jourprop *participantc 312 "END" ":" "VJOURNAL" CRLF 314 jourprop =/ *( 315 ; 316 ; The following are OPTIONAL, 317 ; and MAY occur more than once. 318 ; 319 styleddescription / sdataprop 320 ; 321 ) 323 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 324 fbprop *participantc 325 "END" ":" "VFREEBUSY" CRLF 327 5. New Property Parameters 329 This specification makes use of the LABEL parameter which is defined 330 in [RFC7986] 332 5.1. Loctype 334 Parameter name: LOCTYPE 336 Purpose: To specify the type of location. 338 Format Definition: 340 This parameter is defined by the following notation: 342 loctypeparam = "LOCTYPE" "=" param-value 344 Description: This parameter MAY be specified on STRUCTURED-LOCATION 345 and provides a way to differentiate multiple properties. For 346 example, it allows event producers to provide location information 347 for the venue and the parking. 349 Values for this parameter are taken from the values defined in 350 [RFC4589]. New location types SHOULD be registered in the manner 351 laid down in that specification. 353 5.2. Restype 355 Parameter name: RESTYPE 357 Purpose: To specify the type of resource. 359 Format Definition: 361 This parameter is defined by the following notation: 363 restypeparam = "RESTYPE" "=" restypevalue CRLF 365 restypevalue = ("ROOM" 366 / "PROJECTOR" 367 / "REMOTE-CONFERENCE-AUDIO" 368 / "REMOTE-CONFERENCE-VIDEO" 369 / x-name ; Experimental status 370 / iana-token) ; Other IANA-registered 371 ; values 373 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 374 and provides a way to differentiate multiple properties. 376 The registered values are described below. New resource types 377 SHOULD be registered in the manner laid down in this 378 specification. 380 ROOM: A room for the event/meeting. 382 PROJECTOR: Projection equipment. 384 REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities. 386 REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities. 388 5.3. Order 390 Parameter name: ORDER 392 Purpose: To define ordering for the associated property. 394 Format Definition: 396 This parameter is defined by the following notation: 398 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 400 Description: The ORDER parameter is OPTIONAL and is used to indicate 401 the relative ordering of the corresponding instance of a property. 402 Its value MUST be an integer greater than or equal to 1 that 403 quantifies the order with 1 being the first in the ordering. 405 When the parameter is absent, the default MUST be to interpret the 406 property instance as being at the lowest level of ordering, that 407 is, the property will appear after any other instances of the same 408 property with any value of ORDER. 410 When any ORDER parameters have the same value all the associated 411 properties appear as a group within which there is no defined 412 order. 414 Note that the value of this parameter is to be interpreted only in 415 relation to values assigned to other corresponding instances of 416 the same property in the same entity. A given value, or the 417 absence of a value, MUST NOT be interpreted on its own. 419 This parameter MAY be applied to any property that allows multiple 420 instances. 422 5.4. Schema 424 Parameter Name: SCHEMA 426 Purpose: To specify the schema used for the content of a 427 "STRUCTURED-DATA" property value. 429 Format Definition: 431 This parameter is defined by the following notation: 433 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 435 Description: This property parameter SHOULD be specified on 436 "STRUCTURED-DATA" properties. When present it provides 437 identifying information about the nature of the content of the 438 corresponding "STRUCTURED-DATA" property value. This can be used 439 to supplement the media type information provided by the "FMTTYPE" 440 parameter on the corresponding property. 442 Example: 444 STRUCTURED-DATA;FMTTYPE=application/ld+json; 445 SCHEMA="https://schema.org/FlightReservation"; 446 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 448 5.5. Derived 450 Parameter Name: DERIVED 452 Purpose: To specify that the value of the associated property is 453 derived from some other property value or values. 455 Format Definition: 457 This parameter is defined by the following notation: 459 derivedparam = "DERIVED" "=" ("TRUE" / "FALSE") 460 ; Default is FALSE 462 Description: This property parameter can be specified on any 463 property when the value is derived from some other property or 464 properties. When present with a value of TRUE clients MUST NOT 465 update the property. 467 As an example, if a STYLED-DESCRIPTION property is present with 468 FMTTYPE="application/rtf" then there may be an additional STYLED- 469 DESCRIPTION property with FMTTYPE="text/html" and DERIVED=TRUE and 470 a value created from the rtf value. 472 Example: 474 STYLED-DESCRIPTION;FMTTYPE=text/html; 475 DERIVED=TRUE:... 477 6. Redefined Property SOURCE 479 The SOURCE property defined in [RFC7986] is redefined to allow 480 VALUE=TEXT and broaden its usage to any component. 482 Property name: SOURCE 484 Purpose: This property provides a reference to information about a 485 component such as a participant possibly as a vcard or optionally 486 a plain text typed value. 488 Value type: The default value type for this property is URI. The 489 value type can also be set to TEXT to indicate plain text content. 491 Property Parameters: Non-standard or format type parameters can be 492 specified on this property. 494 Conformance: This property MAY appear in any iCalendar component. 496 Description: This property provides information about the component 497 in which it appears. 499 In a resource or participant it may provide a reference to a vcard 500 giving directory information. 502 In a VCALENDAR component this property identifies a location where 503 a client can retrieve updated data for the calendar. Clients 504 SHOULD honor any specified "REFRESH-INTERVAL" value when 505 periodically retrieving data. Note that this property differs 506 from the "URL" property in that "URL" is meant to provide an 507 alternative representation of the calendar data rather than the 508 original location of the data. 510 In a calendar entity component such as an event the SOURCE 511 property may provide a reference to the original source of the 512 event. This may be used by aggregators to provide a link back. 514 Format Definition: 516 This property is defined by the following notation: 518 source = "SOURCE" sourceparam 519 ( 520 ( 521 ";" "VALUE" "=" "URI" 522 ":" uri 523 ) / 524 ( 525 ";" "VALUE" "=" "TEXT" 526 ":" text 527 ) 528 ) 529 CRLF 531 sourceparam = *( 532 ; 533 ; the following are OPTIONAL 534 ; but MUST NOT occur more than once 535 ; 536 (";" fmttypeparam) / 537 ; 538 ; the following is OPTIONAL 539 ; and MAY occur more than once 540 ; 541 (";" other-param) 542 ; 543 ) 545 Example: 547 The following is an example referring to a VCARD. 549 SOURCE;FMTTYPE=text/vcard;VALUE=URL: 550 http://dir.example.com/vcard/contacts/contact1.vcf 552 7. New Properties 554 7.1. Participant Type 556 Property name: PARTICIPANT-TYPE 558 Purpose: To specify the type of participant. 560 Value type: The value type for this property is TEXT. The allowable 561 values are defined below. 563 Property Parameters: Non-standard parameters can be specified on 564 this property. 566 Conformance: This property MUST be specified within a PARTICIPANT 567 component. 569 Description: This property defines the type of participation in 570 events or tasks. Participants can be individuals or 571 organizations, for example a soccer team, the spectators, or the 572 musicians. 574 Format Definition: 576 This parameter is defined by the following notation: 578 participanttype = "PARTICIPANT-TYPE" "=" partvalue CRLF 580 partvalue = ("ACTIVE" 581 / "INACTIVE" 582 / "SPONSOR" 583 / "CONTACT" 584 / "BOOKING-CONTACT" 585 / "EMERGENCY-CONTACT" 586 / "PUBLICITY-CONTACT" 587 / "PLANNER-CONTACT" 588 / "PERFORMER" 589 / "SPEAKER" 590 / x-name ; Experimental status 591 / iana-token) ; Other IANA-registered 592 ; values 594 Example: 596 The following is an example of this property: 598 PARTICIPANT-TYPE:SPEAKER 600 The registered values for the PARTICIPANT-TYPE property have the 601 meanings described here: 603 ACTIVE: A participant taking an active role - for example a team 604 member. 606 INACTIVE: A participant taking an inactive part - for example an 607 audience member. 609 SPONSOR: A sponsor of the event. The ORDER parameter may be used 610 with this participant type to define the relative order of 611 multiple sponsors. 613 CONTACT: Contact information for the event. The ORDER parameter may 614 be used with this participant type to define the relative order of 615 multiple contacts. 617 BOOKING-CONTACT: Contact information for reservations or payment 619 EMERGENCY-CONTACT: Contact in case of emergency 621 PUBLICITY-CONTACT: Contact for publicity 623 PLANNER-CONTACT: Contact for the event planner or organizer 625 PERFORMER: A performer - for example the soloist or the accompanist. 626 The ORDER parameter may be used with this participant type to 627 define the relative order of multiple performers. For example, 628 ORDER=1 could define the principal performer or soloist. 630 SPEAKER: Speaker at an event 632 7.2. Calendar Address 634 Property name: CALENDAR-ADDRESS 636 Purpose: To specify the calendar address for a participant. 638 Value type: CAL-ADDRESS 640 Property Parameters: IANA or non-standard property parameters can be 641 specified on this property. 643 Conformance: This property MAY be specified within a PARTICIPANT 644 component. 646 Description: This property provides a calendar user address for the 647 participant. If there is an ATTENDEE property with the same value 648 then the participant is schedulable. 650 Format Definition: 652 This parameter is defined by the following notation: 654 calendaraddress = "CALENDAR-ADDRESS" "=" cal-address 656 7.3. Styled-Description 658 Property name: STYLED-DESCRIPTION 660 Purpose: This property provides for one or more rich-text 661 descriptions to replace that provided by the DESCRIPTION property. 663 Value type: There is no default value type for this property. The 664 value type can be set to URI or TEXT. Other text-based value 665 types can be used when defined in the future. Clients MUST ignore 666 any properties with value types they do not understand. 668 Property Parameters: IANA, non-standard, id, alternate text 669 representation, format type, derived and language property 670 parameters can be specified on this property. 672 Conformance: The property can be specified multiple times in the 673 "VEVENT", "VTODO", "VJOURNAL", "PARTICIPANT", or "VALARM" calendar 674 components. 676 If it does appear more than once there MUST be exactly one 677 instance of the property with no DERIVED parameter or 678 DERIVED=FALSE. All others MUST have DERIVED=TRUE. 680 Additionally, if there is one or more STYLED-DESCRIPTION property 681 then the DESCRIPTION property should be either absent or have the 682 parameter DERIVED=TRUE. 684 Description: This property is used in the "VEVENT" and "VTODO" to 685 capture lengthy textual descriptions associated with the activity. 686 This property is used in the "VJOURNAL" calendar component to 687 capture one or more textual journal entries. This property is 688 used in the "VALARM" calendar component to capture the display 689 text for a DISPLAY category of alarm, and to capture the body text 690 for an EMAIL category of alarm. In the PARTICIPANT component it 691 provides a detailed description of the participant. 693 VALUE=TEXT is used to provide rich-text inline as the property 694 value. 696 VALUE=URI is used to provide a link to rich-text content which is 697 expected to be displayed inline as part of the event. 699 In either case the DESCRIPTION property should be absent or 700 contain a plain text rendering of the styled text. 702 Applications MAY attempt to guess the media type of the resource 703 via inspection of its content if and only if the media type of the 704 resource is not given by the "FMTTYPE" parameter. If the media 705 type remains unknown, calendar applications SHOULD treat it as 706 type "text/html" and process the content as defined in 707 [W3C.REC-html51-20171003] 709 Multiple STYLED-DESCRIPTION properties may be used to provide 710 different formats or different language variants. However all but 711 one MUST have DERIVED=TRUE. 713 Format Definition: 715 This property is defined by the following notation: 717 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 718 ( 719 ( 720 ";" "VALUE" "=" "URI" 721 ":" uri 722 ) / 723 ( 724 ";" "VALUE" "=" "TEXT" 725 ":" text 726 ) 727 ) 728 CRLF 730 styleddescparam = *( 731 ; 732 ; The following are OPTIONAL, 733 ; but MUST NOT occur more than once. 734 ; 735 (";" altrepparam) / (";" languageparam) / 736 (";" fmttypeparam) / (";" derivedparam) / 737 ; 738 ; the following is OPTIONAL 739 ; and MAY occur more than once 740 ; 741 (";" other-param) 742 ) 744 Example: 746 The following is an example of this property. It points to an html 747 description. 749 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 751 7.4. Structured-Location 753 Property name: STRUCTURED-LOCATION 755 Purpose: This property provides a typed reference to external 756 information about the location of an event or optionally a plain 757 text typed value. 759 Value type: There is no default value type for this property. The 760 value type can be set to URI or TEXT. 762 Property Parameters: IANA, non-standard, label, loctype, related or 763 format type parameters can be specified on this property. 765 Conformance: This property MAY be specified zero or more times in 766 any iCalendar component. 768 Description: When used in a component the value of this property 769 provides information about the event venue or of related services 770 such as parking, dining, stations etc.. 772 When a LABEL parameter is supplied the language of the label must 773 match that of the content and of the LANGUAGE parameter if 774 present. 776 Use of the related parameter: This allows a location to define the 777 start and/or end timezone of the associated component. If a 778 location is specified with a RELATED parameter then the affected 779 DTSTART or DTEND properties MUST be specified as floating DATE- 780 TIME value. 782 If the RELATED parameter is present with a value of START, then 783 the "DTSTART" property MUST be present in the associated "VEVENT" 784 or "VTODO" calendar component. 786 For an event, if the RELATED parameter is present with a value of 787 END, then the "DTEND" property or the "DTSTART" and "DURATION " 788 properties MUST be present in the associated "VEVENT" calendar 789 component. 791 For a to-do with a RELATED value of END, then either the "DUE" 792 property or the "DTSTART" and "DURATION " properties MUST be 793 present in the associated "VTODO" calendar component. 795 If there is a location specified with RELATED=START and no 796 location is specified with RELATED=END then the event is assumed 797 to start and end in the same timezone. 799 Format Definition: 801 This property is defined by the following notation: 803 strucloc = "STRUCTURED-LOCATION" struclocparam 804 ( 805 ( 806 ";" "VALUE" "=" "URI" 807 ":" uri 808 ) / 809 ( 810 ";" "VALUE" "=" "TEXT" 811 ":" text 812 ) 813 ) 814 CRLF 816 struclocparam = *( 817 ; 818 ; the following are OPTIONAL 819 ; but MUST NOT occur more than once 820 ; 821 (";" fmttypeparam) / 822 (";" labelparam) / 823 (";" languageparam) / 824 (";" trigrelparam) / 825 (";" loctypeparam) / 826 ; 827 ; the following is OPTIONAL 828 ; and MAY occur more than once 829 ; 830 (";" other-param) 831 ) 833 Example: 835 The following is an example of this property. It points to a venue. 837 STRUCTURED-LOCATION;LABEL="The venue"; 838 VALUE=URI: 839 http://dir.example.com/venues/big-hall.vcf 841 7.5. Structured-Resource 843 Property name: STRUCTURED-RESOURCE 844 Purpose: This property provides a typed reference to external 845 information about a resource or optionally a plain text typed 846 value. Typically a resource is anything that might be required or 847 used by a calendar entity and possibly has a directory entry. 849 Value type: There is no default value type for this property. The 850 value type can be set to URI or TEXT. 852 Property Parameters: IANA, non-standard, label, restype or format 853 type parameters can be specified on this property. 855 Conformance: This property MAY be specified zero or more times in 856 any iCalendar component. 858 Description: When used in a component the value of this property 859 provides information about resources used for the event. 861 Such resources may be a room or a projector. This RESTYPE value 862 registry provides a place in which resource types may be 863 registered for use by scheduling sevices. 865 When a LABEL parameter is supplied the language of the label must 866 match that of the content and of the LANGUAGE parameter if 867 present. 869 Format Definition: 871 This property is defined by the following notation: 873 strucres = "STRUCTURED-RESOURCE" strucresparam / 874 ( 875 ( 876 ";" "VALUE" "=" "URI" 877 ":" uri 878 ) / 879 ( 880 ";" "VALUE" "=" "TEXT" 881 ":" text 882 ) 883 ) 884 CRLF 886 strucresparam = *( 887 ; 888 ; the following are OPTIONAL 889 ; but MUST NOT occur more than once 890 ; 891 (";" fmttypeparam) / 892 (";" labelparam) / 893 (";" languageparam) / 894 (";" restypeparam) / 895 ; 896 ; the following is OPTIONAL 897 ; and MAY occur more than once 898 ; 899 (";" other-param) 900 ) 902 Example: 904 The following is an example of this property. It refers to a 905 projector. 907 STRUCTURED-RESOURCE;value=uri;restype="projector": 908 http://dir.example.com/projectors/3d.vcf 910 7.6. Structured-Data 912 Property Name: STRUCTURED-DATA 914 Purpose: This property specifies ancillary data associated with the 915 calendar component. 917 Value Type: TEXT, BINARY or URI 918 Property Parameters: IANA, non-standard, inline encoding, and value 919 data type property parameters can be specified on this property. 920 The format type and schema parameters can be specified on this 921 property and are RECOMMENDED for text or inline binary encoded 922 content information. 924 Conformance: This property can be specified multiple times in an 925 iCalendar object. Typically it would be used in "VEVENT", 926 "VTODO", or "VJOURNAL" calendar components. 928 Description: This property is used to specify ancillary data in some 929 structured format either directly (inline) as a "TEXT" or "BINARY" 930 value, or as a link via a "URI" value. 932 Rather than define new iCalendar properties for the variety of 933 event types that might occur, it would be better to leverage 934 existing schemas for such data. For example, schemas available at 935 https://schema.org include different event types. By using 936 standard schemas, interoperability can be improved between 937 calendar clients and non-calendaring systems that wish to generate 938 or process the data. 940 This property allows the direct inclusion of ancillary data whose 941 schema is defined elsewhere. This property also includes 942 parameters to clearly identify the type of the schema being used 943 so that clients can quickly and easily spot what is relevant 944 within the calendar data and present that to users or process it 945 within the calendaring system. 947 iCalendar does support an "ATTACH" property which can be used to 948 include documents or links to documents within the calendar data. 949 However, that property does not allow data to be included as a 950 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 951 attachments are often treated as "opaque" data to be processed by 952 some other system rather than the calendar client. Thus the 953 existing "ATTACH" property is not sufficient to cover the specific 954 needs of inclusion of schema data. Extending the "ATTACH" 955 property to support a new value type would likely cause 956 interoperability problems. Thus a new property to support 957 inclusion of schema data is warranted. 959 Format Definition: 961 This property is defined by the following notation: 963 sdataprop = "STRUCTURED-DATA" sdataparam 964 (":" text) / 965 ( 966 ";" "ENCODING" "=" "BASE64" 967 ";" "VALUE" "=" "BINARY" 968 ":" binary 969 ) / 970 ( 971 ";" "VALUE" "=" "URI" 972 ":" uri 973 ) 974 CRLF 976 sdataparam = *( 977 ; 978 ; The following is OPTIONAL for a URI value, 979 ; RECOMMENDED for a TEXT or BINARY value, 980 ; and MUST NOT occur more than once. 981 ; 982 (";" fmttypeparam) / 983 (";" schemaparam) / 984 ; 985 ; The following is OPTIONAL, 986 ; and MAY occur more than once. 987 ; 988 (";" other-param) 989 ; 990 ) 992 Example: The following is an example of this property: 994 STRUCTURED-DATA;FMTTYPE=application/ld+json; 995 SCHEMA="https://schema.org/SportsEvent"; 996 VALUE=TEXT:{\n 997 "@context": "http://schema.org"\,\n 998 "@type": "SportsEvent"\,\n 999 "homeTeam": "Pittsburgh Pirates"\,\n 1000 "awayTeam": "San Francisco Giants"\n 1001 }\n 1003 8. New Components 1004 8.1. Participant 1006 Component name: PARTICIPANT 1008 Purpose: This component provides information about a participant in 1009 an event or task. 1011 Conformance: This component MAY appear in any iCalendar component. 1013 Description: This component provides information about an 1014 participant in an event, task or poll. A participant may be an 1015 attendee in a scheduling sense and the ATTENDEE property may be 1016 specified in addition. Participants in events can be individuals 1017 or organizations, for example a soccer team, the spectators, or 1018 the musicians. 1020 The SOURCE property if present may refer to an external definition 1021 of the participant - such as a vcard. 1023 The CALENDAR-ADDRESS property if present will provide a cal- 1024 address. If an ATTENDEE property has the same value the 1025 participant is considered schedulable. The PARTICIPANT component 1026 can be used to contain additional meta-data related to the 1027 attendee. 1029 Format Definition: 1031 This property is defined by the following notation: 1033 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 1034 partprop 1035 "END" ":" "PARTICIPANT" CRLF 1037 partprop = *( 1038 ; 1039 ; The following are REQUIRED, 1040 ; but MUST NOT occur more than once. 1041 ; 1042 dtstamp / participanttype / 1043 ; 1044 ; The following are OPTIONAL, 1045 ; but MUST NOT occur more than once. 1046 ; 1047 created / description / last-mod / priority / seq / 1048 source / status / calendaraddress / summary / url / 1049 ; 1050 ; The following are OPTIONAL, 1051 ; and MAY occur more than once. 1052 ; 1053 attach / categories / comment / 1054 contact / location / rstatus / related / 1055 resources / strucloc / strucres / styleddescription / 1056 x-prop / iana-prop 1057 ; 1058 ) 1060 Note: When the PRIORITY is supplied it defines the ordering of 1061 PARTICIPANT components with the same value for the TYPE parameter. 1063 Privacy Issues: When a LOCATION is supplied it provides information 1064 about the location of a participant at a given time or times. 1065 This may represent an unacceptable privacy risk for some 1066 participants. User agents MUST NOT include this information 1067 without informing the participant. 1069 Example: 1071 The following is an example of this component. It contains a SOURCE 1072 property which points to a VCARD providing information about the 1073 event participant. 1075 BEGIN:PARTICIPANT 1076 PARTICIPANT-TYPE:PERFORMER 1077 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 1078 END:PARTICIPANT 1080 Example: 1082 The following is an example for the primary contact. 1084 BEGIN: PARTICIPANT 1085 SOURCE;FMTTYPE=text/vcard; 1086 http://dir.example.com/vcard/contacts/contact1.vcf 1087 PARTICIPANT-TYPE:CONTACT 1088 DESCRIPTION:A contact: 1089 END:PARTICIPANT 1091 8.2. Schedulable Participant 1093 A PARTICIPANT component may represent someone or something that needs 1094 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 1095 The PARTICIPANT component may also represent someone or something 1096 that is NOT to receive scheduling messages. 1098 A PARTICIPANT component is defined to be schedulable if 1100 o It contains a CALENDAR-ADDRESS property 1102 o That property value is the same as the value for an ATTENDEE 1103 property. 1105 If both of these conditions apply then the participant defined by the 1106 value of the URL property will take part in scheduling operations as 1107 defined in [RFC5546]. 1109 An appropriate use for the PARTICIPANT component in scheduling would 1110 be to store SEQUENCE and DTSTAMP properties associated with replies 1111 from each ATTENDEE. A LOCATION property within the PARTICIPANT 1112 component might allow better selection of meeting times when 1113 participants are in different timezones. 1115 9. Extended examples 1117 The following are some examples of the use of the properties defined 1118 in this specification. They include additional properties defined in 1119 [RFC7986] which includes IMAGE. 1121 9.1. Example 1 1123 The following is an example of a VEVENT describing a concert. It 1124 includes location information for the venue itself as well as 1125 references to parking and restaurants. 1127 BEGIN:VEVENT 1128 CREATED:20170216T145739Z 1129 DESCRIPTION: Piano Sonata No 3\n 1130 Piano Sonata No 30 1131 DTSTAMP:20171116T145739Z 1132 DTSTART;TZID=America/New_York:20170315T150000Z 1133 DTEND;TZID=America/New_York:20170315T163000Z 1134 LAST-MODIFIED:20170216T145739Z 1135 SUMMARY:Beethoven Piano Sonatas 1136 UID:123456 1137 STRUCTURED-LOCATION;LABEL="The venue";VALUE=URI: 1138 http://dir.example.com/venues/big-hall.vcf 1139 STRUCTURED-LOCATION;LABEL="Parking for the venue";VALUE=URI: 1140 http://dir.example.com/venues/parking.vcf 1141 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 1142 ttp://example.com/images/concert.png 1143 BEGIN:PARTICIPANT 1144 PARTICIPANT-TYPE:SPONSOR 1145 SOURCE:http://example.com/sponsor.vcf 1146 END:PARTICIPANT 1147 BEGIN:PARTICIPANT 1148 PARTICIPANT-TYPE:PERFORMER: 1149 SOURCE:http://www.example.com/people/johndoe.vcf 1150 END:PARTICIPANT 1151 END:VEVENT 1153 9.2. Example 2 1154 The following is an example of a VEVENT describing a meeting. One of 1155 the attendees is a remote participant. 1157 BEGIN:VEVENT 1158 CREATED:20170216T145739Z 1159 DTSTAMP:20101116T145739Z 1160 DTSTART;TZID=America/New_York:20170315T150000Z 1161 DTEND;TZID=America/New_York:20170315T163000Z 1162 LAST-MODIFIED:20170216T145739Z 1163 SUMMARY:Conference plaaning 1164 UID:123456 1165 ORGANIZER:mailto:a@example.com 1166 ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com 1167 ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com 1168 BEGIN:PARTICIPANT 1169 PARTICIPANT-TYPE:ACTIVE: 1170 SOURCE:http://www.example.com/people/b.vcf 1171 LOCATION:At home 1172 END:PARTICIPANT 1173 END:VEVENT 1175 10. Security Considerations 1177 Applications using these properties need to be aware of the risks 1178 entailed in using the URIs provided as values. See [RFC3986] for a 1179 discussion of the security considerations relating to URIs. 1181 Security considerations relating to the "ATTACH" property, as 1182 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 1183 property. 1185 When processing HTML content applications need to be aware of the 1186 many security and privacy issues as described in the IANA 1187 considerations section of [W3C.REC-html51-20171003] 1189 11. Privacy Considerations 1191 Properties with a "URI" value type can expose their users to privacy 1192 leaks as any network access of the URI data can be tracked. Clients 1193 SHOULD NOT automatically download data referenced by the URI without 1194 explicit instruction from users. This specification does not 1195 introduce any additional privacy concerns beyond those described in 1196 [RFC5545]. 1198 The addition of location information to the new participant component 1199 provides information about the location of participants at a given 1200 time. 1202 12. IANA Considerations 1204 This section defines updates to the tables defined in [RFC5545] and 1205 new tables. 1207 12.1. Additional iCalendar Registrations 1209 12.1.1. Properties 1211 This document defines the following new iCalendar properties to be 1212 added to the registry defined in Section 8.2.3 of [RFC5545]: 1214 +---------------------+---------+----------------------+ 1215 | Property | Status | Reference | 1216 +---------------------+---------+----------------------+ 1217 | CALENDAR-ADDRESS | Current | RFCXXXX, Section 7.2 | 1218 | PARTICIPANT-TYPE | Current | RFCXXXX, Section 7.1 | 1219 | SOURCE | Current | RFCXXXX, Section 6 | 1220 | STRUCTURED-DATA | Current | RFCXXXX, Section 7.6 | 1221 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 7.3 | 1222 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 7.4 | 1223 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 7.5 | 1224 +---------------------+---------+----------------------+ 1226 12.1.2. Parameters 1228 This document defines the following new iCalendar property parameters 1229 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1231 +--------------------+---------+----------------------+ 1232 | Property Parameter | Status | Reference | 1233 +--------------------+---------+----------------------+ 1234 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1235 | ORDER | Current | RFCXXXX, Section 5.3 | 1236 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1237 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1238 +--------------------+---------+----------------------+ 1240 12.1.3. Components 1242 This document defines the following new iCalendar components to be 1243 added to the registry defined in Section 8.3.1 of [RFC5545]: 1245 +-------------+---------+----------------------+ 1246 | Component | Status | Reference | 1247 +-------------+---------+----------------------+ 1248 | PARTICIPANT | Current | RFCXXXX, Section 8.1 | 1249 +-------------+---------+----------------------+ 1251 12.2. New Registration Tables 1253 This section defines new registration tables for PARTICIPANT-TYPE and 1254 RESTYPE values. These tables may be updated using the same 1255 approaches laid down in Section 8.2.1 of [RFC5545] 1257 12.2.1. Participant Types 1259 The following table has been used to initialize the participant types 1260 registry. 1262 +-------------------+---------+----------------------+ 1263 | Participant Type | Status | Reference | 1264 +-------------------+---------+----------------------+ 1265 | ACTIVE | Current | RFCXXXX, Section 7.1 | 1266 | INACTIVE | Current | RFCXXXX, Section 7.1 | 1267 | SPONSOR | Current | RFCXXXX, Section 7.1 | 1268 | CONTACT | Current | RFCXXXX, Section 7.1 | 1269 | BOOKING-CONTACT | Current | RFCXXXX, Section 7.1 | 1270 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 7.1 | 1271 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 7.1 | 1272 | PLANNER-CONTACT | Current | RFCXXXX, Section 7.1 | 1273 | PERFORMER | Current | RFCXXXX, Section 7.1 | 1274 | SPEAKER | Current | RFCXXXX, Section 7.1 | 1275 +-------------------+---------+----------------------+ 1277 12.2.2. Resource Types 1279 The following table has been used to initialize the resource types 1280 registry. 1282 +-------------------------+---------+----------------------+ 1283 | Resource Type | Status | Reference | 1284 +-------------------------+---------+----------------------+ 1285 | PROJECTOR | Current | RFCXXXX, Section 5.2 | 1286 | ROOM | Current | RFCXXXX, Section 5.2 | 1287 | REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 5.2 | 1288 | REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 5.2 | 1289 +-------------------------+---------+----------------------+ 1291 13. Acknowledgements 1293 The author would like to thank Chuck Norris of eventful.com for his 1294 work which led to the development of this RFC. 1296 The author would also like to thank the members of CalConnect, The 1297 Calendaring and Scheduling Consortium, the Event Publication 1298 technical committee and the following individuals for contributing 1299 their ideas and support: 1301 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, 1303 14. References 1305 14.1. Normative References 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, 1309 DOI 10.17487/RFC2119, March 1997, 1310 . 1312 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1313 Resource Identifier (URI): Generic Syntax", STD 66, 1314 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1315 . 1317 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1318 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1319 . 1321 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1322 Scheduling Core Object Specification (iCalendar)", 1323 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1324 . 1326 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1327 Interoperability Protocol (iTIP)", RFC 5546, 1328 DOI 10.17487/RFC5546, December 2009, 1329 . 1331 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 1332 DOI 10.17487/RFC7986, October 2016, 1333 . 1335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1337 May 2017, . 1339 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1340 Interchange Format", STD 90, RFC 8259, 1341 DOI 10.17487/RFC8259, December 2017, 1342 . 1344 [W3C.REC-html51-20171003] 1345 Faulkner, S., Eicholz, A., Leithead, T., and A. Danilo, 1346 "HTML 5.1 2nd Edition", World Wide Web Consortium 1347 Recommendation REC-html51-20171003, October 2017, 1348 . 1350 [W3C.REC-xml-20081126] 1351 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1352 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1353 Edition)", World Wide Web Consortium Recommendation REC- 1354 xml-20081126, November 2008, 1355 . 1357 14.2. Informative References 1359 [iana-property-registry] 1360 "IANA iCalendar Element Registries", 1361 . 1364 Appendix A. Open issues 1366 None at the moment 1368 Appendix B. Change log 1370 calext-v12 2019-02-28 MD 1372 o Fix styled-description example. Respond to various AD issues. 1373 Some typos. 1375 calext-v11 2019-02-27 MD 1377 o Add DERIVED parameter for styled-description, RELATED parameter 1378 for structured-location 1380 calext-v09 2018-08-30 MD 1382 o Sorted out inconsistencies in refs to 5546 1384 calext-v08 2018-07-06 MD 1386 o Add some text for equal ORDER values 1388 o Switched scheduleaddress to calendaraddress in participant abnf. 1389 Also added more properties 1391 o Fixed PARTICIPANT abnf 1392 calext-v04 2017-10-11 MD 1394 o Change SCHEDULE-ADDRESS to CALENDAR-ADDRESS 1396 o Explicitly broaden scope of SOURCE 1398 o Add initial registry for RESTYPE and move new tables into separate 1399 section. 1401 o Fix PARTTYPE/PARTICPANT-TYPE inconsistency 1403 calext-v03 2017-10-09 MD 1405 o Mostly typographical and other minor changes 1407 calext-v02 2017-04-20 MD 1409 o Add SCHEDULE-ADDRESS property 1411 o PARTICIPANT becomes a component rather than a property. Turn many 1412 of the former parameters into properties. 1414 o Use existing ATTENDEE property for scheduling. 1416 calext-v01 2017-02-18 MD 1418 o Change ASSOCIATE back to PARTICIPANT 1420 o PARTICIPANT becomes a component rather than a property. Turn many 1421 of the former parameters into properties. 1423 calext-v00 2016-08-?? MD 1425 o Name changed - taken up by calext working group 1427 v06 2016-06-26 MD 1429 o Fix up abnf 1431 o change ref to ietf from daboo 1433 o take out label spec - use Cyrus spec 1435 v05 2016-06-14 MD 1437 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1439 o Change ORDER to integer >= 1. 1441 o Incorporate Structured-Data into this specification. 1443 v04 2014-02-01 MD 1445 o Added updates attribute. 1447 o Minor typos. 1449 o Resubmitted mostly to refresh the draft. 1451 v03 2013-03-06 MD 1453 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1455 o Added section showing modifications to components. 1457 o Replace ID with GROUP and modify HASH. 1459 o Replace TITLE param with LABEL. 1461 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1463 v02 2012-11-02 MD 1465 o Collapse sections with description of properties and the use cases 1466 into a section with sub-sections. 1468 o New section to describe relating properties. 1470 o Remove idref and upgrade hash to have the reference 1472 o No default value types on properties.. 1474 v01 2012-10-18 MD Many changes. 1476 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1478 o Add a STRUCTURED-RESOURCE property 1480 o STYLED-DESCRIPTION to handle rich text 1482 o Much more... 1484 2011-01-07 1486 o Remove MEDIA - it's going in the Cyrus RFC 1488 o Rename EXTENDED-... to STRUCTURED-... 1490 o Add TYPE parameter to SPONSOR 1492 v00 2007-10-19 MD Initial version 1494 Author's Address 1496 Michael Douglass 1497 Spherical Cow Group 1498 226 3rd Street 1499 Troy, NY 12180 1500 USA 1502 Email: mdouglass@sphericalcowgroup.com 1503 URI: http://sphericalcowgroup.com