idnits 2.17.1 draft-ietf-calext-eventpub-extensions-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5545], [RFC5546]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5546, but the abstract doesn't seem to directly say this. It does mention RFC5546 though, so this could be OK. 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) (Using the creation date from RFC5546, updated by this document, for RFC5378 checks: 2005-10-21) -- 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 15, 2018) is 2172 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: 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,5546 (if approved) May 15, 2018 5 Intended status: Standards Track 6 Expires: November 16, 2018 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-07 11 Abstract 13 This specification updates [RFC5545] and [RFC5546] by introducing a 14 number of new iCalendar properties and components which are of 15 particular use for 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 19 an 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 16, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 7 65 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. Redefined Property SOURCE . . . . . . . . . . . . . . . . . . 10 70 7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.1. Participant Type . . . . . . . . . . . . . . . . . . . . 12 72 7.2. Calendar Address . . . . . . . . . . . . . . . . . . . . 13 73 7.3. Styled-Description . . . . . . . . . . . . . . . . . . . 14 74 7.4. Structured-Location . . . . . . . . . . . . . . . . . . . 16 75 7.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 17 76 7.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 19 77 8. New Components . . . . . . . . . . . . . . . . . . . . . . . 21 78 8.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 22 79 8.2. Schedulable Participant . . . . . . . . . . . . . . . . . 24 80 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 24 81 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 24 82 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 25 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 12.1. Additional iCalendar Registrations . . . . . . . . . . . 27 87 12.1.1. Property Registrations . . . . . . . . . . . . . . . 27 88 12.1.2. Parameter Registrations . . . . . . . . . . . . . . 27 89 12.1.3. Component Registrations . . . . . . . . . . . . . . 27 90 12.2. New Registration Tables . . . . . . . . . . . . . . . . 28 91 12.2.1. Participant Types Registry . . . . . . . . . . . . . 28 92 12.2.2. Resource Types Registry . . . . . . . . . . . . . . 28 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 94 14. Normative References . . . . . . . . . . . . . . . . . . . . 29 95 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 30 96 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 30 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 99 1. Introduction 101 The currently existing iCalendar standard [RFC5545] lacks useful 102 methods for referencing additional, external information relating to 103 calendar components. Additionally there is no standard way to 104 provide rich text descriptions or meta-data associated with the 105 event. 107 Current practice is to embed this information as links in the 108 description or to add non-standard properties as defined in [RFC5545] 109 section 3.8.8.2. 111 This document updates [RFC5545] to define a number of properties and 112 a component referencing such external information that can provide 113 additional information about an iCalendar component. The intent is 114 to allow interchange of such information between applications or 115 systems (e.g., between clients, between client and server, and 116 between servers). Formats such as VCARD are likely to be most useful 117 to the receivers of such events as they may be used in other 118 applications - such as address books. 120 This specification defines a new PARTICIPANT component. Many people 121 or groups may participate in an event. This component provides 122 detailed information. Such participants may act as attendees to the 123 event (or derived events) or may just provide a reference - perhaps 124 for mailing lists. 126 The following properties are defined in this specification 128 STYLED-DESCRIPTION: Supports HTML descriptions. Event publishers 129 typically wish to provide more and better formatted information 130 about the event. 132 STRUCTURED-LOCATION: There may be a number of locations associated 133 with an event. This provides detailed information about the 134 location. 136 STRUCTURED-RESOURCE: Events need resources such as rooms, 137 projectors, conferencing capabilities. 139 STRUCTURED-DATA: The existing properties in iCalendar cover key 140 elements of events and tasks such as start time, end time, 141 location, summary, etc. However, different types of events often 142 have other specific "fields" that it is useful to include in the 143 calendar data. For example, an event representing an airline 144 flight could include the airline, flight number, departure and 145 arrival airport codes, check-in and gate-closing times etc. As 146 another example, a sporting event might contain information about 147 the type of sport, the home and away teams, the league the teams 148 are in, information about nearby parking, etc. 150 PARTICIPANT-TYPE: Used in the PARTICIPANT component to define the 151 type. 153 CALENDAR-ADDRESS: Used in the PARTICIPANT component to provide the 154 calendar address of the participant. 156 In addition the SOURCE property defined in [RFC7986] is redefined to 157 allow VALUE=TEXT and broaden its usage. 159 1.1. Conventions Used in This Document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2. Components and properties 169 Previous extensions to the calendaring standards have been largely 170 restricted to the addition of properties or parameters. This is 171 partly because iCalendar libraries had trouble handling components 172 nested deeper than those defined in [RFC5545] 174 In a break with this 'tradition' this specification introduces one of 175 these extensions as a component rather than a property. This is a 176 better match for the way XML and JSON handles such structures and 177 allows richer definitions. 179 It also allows for the addition of extra properties inside the 180 component and resolves some of the problems of trying to add detailed 181 information as a parameter. 183 3. Typed References 185 The properties defined here can all reference external meta-data 186 which may be used by applications to provide enhanced value to users. 187 By providing type information as parameters, clients and servers are 188 able to discover interesting references and make use of them, perhaps 189 for indexing or the presenting of additional related information for 190 the user. 192 The [RFC5545] LOCATION property provides only an unstructured single 193 text value for specifying the location where an event (or task) will 194 occur. This is inadequate for use cases where structured location 195 information (e.g. address, region, country, postal code) is required 196 or preferred, and limits widespread adoption of iCalendar in those 197 settings. 199 Using STRUCTURED-LOCATION, information about a number of interesting 200 locations can be communicated, for example, address, region, country, 201 postal code as well as other informations such as the parking, 202 restaurants and the venue. Servers and clients can retrieve the 203 objects when storing the event and use them to index by geographic 204 location. 206 When a calendar client receives a calendar component it can search 207 the set of supplied properties looking for those of particular 208 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 209 to help the selection. 211 The PARTICIPANT component is designed to handle common use cases in 212 event publication. It is generally important to provide information 213 about the organizers of such events. Sponsors wish to be referenced 214 in a prominent manner. In social calendaring it is often important 215 to identify the active participants in the event, for example a 216 school sports team, and the inactive participants, for example the 217 parents. 219 The PARTICIPANT component can also be used to provide useful extra 220 data about an attendee. For example a LOCATION property inside the 221 PARTICIPANT gives the actual location of a remote attendee. 223 3.1. Use Cases 225 The main motivation for these properties has been event publication 226 but there are opportunities for use elsewhere. The following use 227 cases will describe some possible scenarios. 229 3.1.1. Piano Concert Performance 231 In putting together a concert there are many participants: piano 232 tuner, performer, stage hands etc. In addition there are sponsors 233 and various contacts to be provided. There will also be a number of 234 related locations. A number of events can be created, all of which 235 relate to the performance in different ways. 237 There may be an iTip [RFC5546] meeting request for the piano tuner 238 who will arrive before the performance. Other members of staff may 239 also receive meeting requests. 241 An event can also be created for publication which will have a 242 PARTICIPANT component for the pianist providing a reference to vcard 243 information about the performer. This event would also hold 244 information about parking, local subway stations and the venue 245 itself. In addition, there will be sponsorship information for 246 sponsors of the event and perhaps paid sponsorship properties 247 essentially advertising local establishments. 249 3.1.2. Itineraries 251 These additions also provide opportunities for the travel industry. 252 When booking a flight the PARTICIPANT component can be used to 253 provide references to businesses at the airports and to car hire 254 businesses at the destination. 256 The embedded location information can guide the traveller at the 257 airport or to their final destination. The contact information can 258 provide detailed information about the booking agent, the airlines, 259 car hire companies and the hotel. 261 3.1.2.1. Reserving facilities 263 For a meeting, the size of a room and the equipment needed depends to 264 some extent on the number of attendees actually in the room. 266 A meeting may have 10 attendees non of which are co-located. The 267 current ATTENDEE property dos not allow for the additon of such meta- 268 data. The PARTICIPANT property allows attendees to specify their 269 location. 271 4. Modifications to Calendar Components 273 The following changes to the syntax defined in iCalendar [RFC5545] 274 are made here. New elements are defined in subsequent sections. 276 eventc = "BEGIN" ":" "VEVENT" CRLF 277 eventprop *alarmc *participantc 278 "END" ":" "VEVENT" CRLF 280 eventprop =/ *( 281 ; 282 ; The following are OPTIONAL, 283 ; and MAY occur more than once. 284 ; 285 styleddescription / strucloc / strucres / sdataprop 286 ; 287 ) 289 todoc = "BEGIN" ":" "VTODO" CRLF 290 todoprop *alarmc *participantc 291 "END" ":" "VTODO" CRLF 293 todoprop =/ *( 294 ; 295 ; The following are OPTIONAL, 296 ; and MAY occur more than once. 297 ; 298 styleddescription / strucloc / strucres / sdataprop 299 ; 300 ) 302 journalc = "BEGIN" ":" "VJOURNAL" CRLF 303 jourprop *participantc 304 "END" ":" "VJOURNAL" CRLF 306 jourprop =/ *( 307 ; 308 ; The following are OPTIONAL, 309 ; and MAY occur more than once. 310 ; 311 styleddescription / sdataprop 312 ; 313 ) 315 5. New Property Parameters 317 This specification makes use of the LABEL parameter which is defined 318 in [RFC7986] 320 5.1. Loctype 322 Parameter name: LOCTYPE 324 Purpose: To specify the type of location. 326 Format Definition: 328 This parameter is defined by the following notation: 330 loctypeparam = "LOCTYPE" "=" param-value 332 Description: This parameter MAY be specified on STRUCTURED-LOCATION 333 and provides a way to differentiate multiple properties. For 334 example, it allows event producers to provide location information 335 for the venue and the parking. 337 Values for this parameter are taken from the values defined in 338 [RFC4589]. New location types SHOULD be registered in the manner 339 laid down in that specification 341 5.2. Restype 343 Parameter name: RESTYPE 345 Purpose: To specify the type of resource. 347 Format Definition: 349 This parameter is defined by the following notation: 351 restypeparam = "RESTYPE" "=" restypevalue CRLF 353 restypevalue = ("ROOM" 354 / "PROJECTOR" 355 / "REMOTE-CONFERENCE-AUDIO" 356 / "REMOTE-CONFERENCE-VIDEO" 357 / x-name ; Experimental status 358 / iana-token) ; Other IANA-registered 359 ; values 361 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 362 and provides a way to differentiate multiple properties. 364 The registered values are described below. New resource types 365 SHOULD be registered in the manner laid down in this specification 367 ROOM: A room for the event/meeting. 369 PROJECTOR: Projection equipment. 371 REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities. 373 REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities. 375 5.3. Order 377 Parameter name: ORDER 379 Purpose: To define ordering for the associated property. 381 Format Definition: 383 This parameter is defined by the following notation: 385 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 387 Description: The ORDER parameter is OPTIONAL and is used to indicate 388 the relative ordering of the corresponding instance of a property. 389 Its value MUST be an integer greater than or equal to 1 that 390 quantifies the order with 1 being the first in the ordering. 392 When the parameter is absent, the default MUST be to interpret the 393 property instance as being at the lowest level of ordering, that 394 is, the property will appear after any other instances of the same 395 property with any value of ORDER. 397 Note that the value of this parameter is to be interpreted only in 398 relation to values assigned to other corresponding instances of 399 the same property in the same entity. A given value, or the 400 absence of a value, MUST NOT be interpreted on its own. 402 This parameter MAY be applied to any property that allows multiple 403 instances. 405 5.4. Schema 407 Parameter Name: SCHEMA 409 Purpose: To specify the schema used for the content of a 410 "STRUCTURED-DATA" property value. 412 Format Definition: 414 This parameter is defined by the following notation: 416 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 418 Description: This property parameter SHOULD be specified on 419 "STRUCTURED-DATA" properties. When present it provides 420 identifying information about the nature of the content of the 421 corresponding "STRUCTURED-DATA" property value. This can be used 422 to supplement the media type information provided by the "FMTTYPE" 423 parameter on the corresponding property. 425 Example: 427 STRUCTURED-DATA;FMTTYPE=application/ld+json; 428 SCHEMA="https://schema.org/FlightReservation"; 429 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 431 6. Redefined Property SOURCE 433 The SOURCE property defined in [RFC7986] is redefined to allow 434 VALUE=TEXT and broaden its usage to any component. 436 Property name: SOURCE 438 Purpose: This property provides a reference to information about a 439 component such as a participant possibly as a vcard or optionally 440 a plain text typed value. 442 Value type: The default value type for this property is URI. The 443 value type can also be set to TEXT to indicate plain text content. 445 Property Parameters: Non-standard or format type parameters can be 446 specified on this property. 448 Conformance: This property MAY be appear in any iCalendar component. 450 Description: This property provides information about the component 451 in which it appears. 453 In a resource or participant it may provide a reference to a vcard 454 giving directory information. 456 In a VCALENDAR component this property identifies a location where 457 a client can retrieve updated data for the calendar. Clients 458 SHOULD honor any specified "REFRESH-INTERVAL" value when 459 periodically retrieving data. Note that this property differs 460 from the "URL" property in that "URL" is meant to provide an 461 alternative representation of the calendar data rather than the 462 original location of the data. 464 In a calendar entity component such as an event the SOURCE 465 property may provide a reference to the original source of the 466 event. This may be used by aggregators to provide a link back. 468 Format Definition: 470 This property is defined by the following notation: 472 source = "SOURCE" sourceparam 473 ( 474 ( 475 ";" "VALUE" "=" "URI" 476 ":" uri 477 ) / 478 ( 479 ";" "VALUE" "=" "TEXT" 480 ":" text 481 ) 482 ) 483 CRLF 485 sourceparam = *( 486 ; 487 ; the following are OPTIONAL 488 ; but MUST NOT occur more than once 489 ; 490 (";" fmttypeparam) / 491 ; 492 ; the following is OPTIONAL 493 ; and MAY occur more than once 494 ; 495 (";" other-param) 496 ; 497 ) 499 Example: 501 The following is an example referring to a VCARD. 503 SOURCE;FMTTYPE=text/vcard;VALUE=URL: 504 http://dir.example.com/vcard/contacts/contact1.vcf 506 7. New Properties 508 7.1. Participant Type 510 Property name: PARTICIPANT-TYPE 512 Purpose: To specify the type of participant. 514 Value type: The value type for this property is TEXT. The allowable 515 values are defined below. 517 Property Parameters: Non-standard parameters can be specified on 518 this property. 520 Conformance: This property MUST be specified within a PARTICIPANT 521 component. 523 Description: This property defines the type of participation in 524 events or tasks. Participants can be individuals or 525 organizations, for example a soccer team, the spectators, or the 526 musicians. 528 Format Definition: 530 This parameter is defined by the following notation: 532 participanttype = "PARTICIPANT-TYPE" "=" partvalue CRLF 534 partvalue = ("ACTIVE" 535 / "INACTIVE" 536 / "SPONSOR" 537 / "CONTACT" 538 / "BOOKING-CONTACT" 539 / "EMERGENCY-CONTACT" 540 / "PUBLICITY-CONTACT" 541 / "PLANNER-CONTACT" 542 / "PERFORMER" 543 / "SPEAKER" 544 / x-name ; Experimental status 545 / iana-token) ; Other IANA-registered 546 ; values 548 Example: 550 The following is an example of this property: 552 PARTICIPANT-TYPE:SPEAKER 554 The registered values for the PARTICIPANT-TYPE property have the 555 meanings described here: 557 ACTIVE: A participant taking an active role - for example a team 558 member. 560 INACTIVE: A participant taking an inactive part - for example an 561 audience member. 563 SPONSOR: A sponsor of the event. The ORDER parameter may be used 564 with this participant type to define the relative order of 565 multiple sponsors. 567 CONTACT: Contact information for the event. The ORDER parameter may 568 be used with this participant type to define the relative order of 569 multiple contacts. 571 BOOKING-CONTACT: Contact information for reservations or payment 573 EMERGENCY-CONTACT: Contact in case of emergency 575 PUBLICITY-CONTACT: Contact for publicity 577 PLANNER-CONTACT: Contact for the event planner or organizer 579 PERFORMER: A performer - for example the soloist or the accompanist. 580 The ORDER parameter may be used with this participant type to 581 define the relative order of multiple performers. For example, 582 ORDER=1 could define the principal performer or soloist. 584 SPEAKER: Speaker at an event 586 7.2. Calendar Address 588 Property name: CALENDAR-ADDRESS 590 Purpose: To specify the calendar address for a participant. 592 Value type: CAL-ADDRESS 594 Property Parameters: IANA or non-standard property parameters can be 595 specified on this property. 597 Conformance: This property MAY be specified within a PARTICIPANT 598 component. 600 Description: This property provides a calendar user address for the 601 participant. If there is an ATTENDEE property with the same value 602 then the participant is schedulable. 604 Format Definition: 606 This parameter is defined by the following notation: 608 calendaraddress = "CALENDAR-ADDRESS" "=" cal-address 610 7.3. Styled-Description 612 Property name: STYLED-DESCRIPTION 614 Purpose: This property provides for one or more rich-text 615 descriptions to replace or augment that provided by the 616 DESCRIPTION property. 618 Value type: There is no default value type for this property. The 619 value type can be set to URI or TEXT. Other text-based value 620 types can be used when defined in the future. Clients MUST ignore 621 any properties with value types they do not understand. 623 Property Parameters: IANA, non-standard, id, alternate text 624 representation, format type, and language property parameters can 625 be specified on this property. 627 Conformance: The property can be specified multiple times in the 628 "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. 630 Description: This property is used in the "VEVENT" and "VTODO" to 631 capture lengthy textual descriptions associated with the activity. 632 This property is used in the "VJOURNAL" calendar component to 633 capture one or more textual journal entries. This property is 634 used in the "VALARM" calendar component to capture the display 635 text for a DISPLAY category of alarm, and to capture the body text 636 for an EMAIL category of alarm. 638 VALUE=TEXT is used to provide rich-text variants of the plain-text 639 DESCRIPTION property. 641 VALUE=URI is used to provide a link to rich-text content which is 642 expected to be displayed inline as part of the event. 644 The intent of this property is limited to providing a styled and/ 645 or language specific version of the DESCRIPTION property. The URL 646 property should be used to link to websites or other related 647 information. 649 Applications MAY attempt to guess the media type of the resource 650 via inspection of its content if and only if the media type of the 651 resource is not given by the "FMTTYPE" parameter. If the media 652 type remains unknown, calendar applications SHOULD treat it as 653 type "text/html". 655 Multiple STYLED-DESCRIPTION properties may be used to provide 656 different formats or different language variants. 658 Format Definition: 660 This property is defined by the following notation: 662 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 663 ( 664 ( 665 ";" "VALUE" "=" "URI" 666 ":" uri 667 ) / 668 ( 669 ";" "VALUE" "=" "TEXT" 670 ":" text 671 ) 672 ) 673 CRLF 675 styleddescparam = *( 676 ; 677 ; The following are OPTIONAL, 678 ; but MUST NOT occur more than once. 679 ; 680 (";" altrepparam) / (";" languageparam) / 681 (";" fmttypeparam) / 682 ; 683 ; the following is OPTIONAL 684 ; and MAY occur more than once 685 ; 686 (";" other-param) 687 ) 689 Example: 691 The following is an example of this property. It points to an html 692 description. 694 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 696 7.4. Structured-Location 698 Property name: STRUCTURED-LOCATION 700 Purpose: This property provides a typed reference to external 701 information about the location of an event or optionally a plain 702 text typed value. 704 Value type: There is no default value type for this property. The 705 value type can be set to URI or TEXT. 707 Property Parameters: IANA, non-standard, label, loctype or format 708 type parameters can be specified on this property. 710 Conformance: This property MAY be specified zero or more times in 711 any iCalendar component. 713 Description: When used in a component the value of this property 714 provides information about the event venue or of related services 715 such as parking, dining, stations etc.. 717 When a LABEL parameter is supplied the language of the label must 718 match that of the content and of the LANGUAGE parameter if 719 present. 721 Format Definition: 723 This property is defined by the following notation: 725 strucloc = "STRUCTURED-LOCATION" struclocparam 726 ( 727 ( 728 ";" "VALUE" "=" "URI" 729 ":" uri 730 ) / 731 ( 732 ";" "VALUE" "=" "TEXT" 733 ":" text 734 ) 735 ) 736 CRLF 738 struclocparam = *( 739 ; 740 ; the following are OPTIONAL 741 ; but MUST NOT occur more than once 742 ; 743 (";" fmttypeparam) / 744 (";" labelparam) / 745 (";" languageparam) / 746 (";" loctypeparam) / 747 ; 748 ; the following is OPTIONAL 749 ; and MAY occur more than once 750 ; 751 (";" other-param) 752 ) 754 Example: 756 The following is an example of this property. It points to a venue. 758 STRUCTURED-LOCATION;LABEL="The venue": 759 http://dir.example.com/venues/big-hall.vcf 761 7.5. Structured-Resource 763 Property name: STRUCTURED-RESOURCE 765 Purpose: This property provides a typed reference to external 766 information about a resource or optionally a plain text typed 767 value. Typically a resource is anything that might be required or 768 used by a calendar entity and possibly has a directory entry. 770 Value type: There is no default value type for this property. The 771 value type can be set to URI or TEXT. 773 Property Parameters: IANA, non-standard, label, restype or format 774 type parameters can be specified on this property. 776 Conformance: This property MAY be specified zero or more times in 777 any iCalendar component. 779 Description: When used in a component the value of this property 780 provides information about resources used for the event. 782 Such resources may be a room or a projector. This RESTYPE value 783 registry provides a place in which resource types may be 784 registered for use by scheduling sevices. 786 When a LABEL parameter is supplied the language of the label must 787 match that of the content and of the LANGUAGE parameter if 788 present. 790 Format Definition: 792 This property is defined by the following notation: 794 strucres = "STRUCTURED-RESOURCE" strucresparam / 795 ( 796 ( 797 ";" "VALUE" "=" "URI" 798 ":" uri 799 ) / 800 ( 801 ";" "VALUE" "=" "TEXT" 802 ":" text 803 ) 804 ) 805 CRLF 807 strucresparam = *( 808 ; 809 ; the following are OPTIONAL 810 ; but MUST NOT occur more than once 811 ; 812 (";" fmttypeparam) / 813 (";" labelparam) / 814 (";" languageparam) / 815 (";" restypeparam) / 816 ; 817 ; the following is OPTIONAL 818 ; and MAY occur more than once 819 ; 820 (";" other-param) 821 ) 823 Example: 825 The following is an example of this property. It refers to a 826 projector. 828 STRUCTURED-RESOURCE;value=uri;restype="projector": 829 http://dir.example.com/projectors/3d.vcf 831 7.6. Structured-Data 833 Property Name: STRUCTURED-DATA 835 Purpose: This property specifies ancillary data associated with the 836 calendar component. 838 Value Type: TEXT, BINARY or URI 839 Property Parameters: IANA, non-standard, inline encoding, and value 840 data type property parameters can be specified on this property. 841 The format type and schema parameters can be specified on this 842 property and are RECOMMENDED for text or inline binary encoded 843 content information. 845 Conformance: This property can be specified multiple times in an 846 iCalendar object. Typically it would be used in "VEVENT", 847 "VTODO", or "VJOURNAL" calendar components. 849 Description: This property is used to specify ancillary data in some 850 structured format either directly (inline) as a "TEXT" or "BINARY" 851 value, or as a link via a "URI" value. 853 Rather than define new iCalendar properties for the variety of 854 event types that might occur, it would be better to leverage 855 existing schemas for such data. For example, schemas available at 856 https://schema.org include different event types. By using 857 standard schemas, interoperability can be improved between 858 calendar clients and non-calendaring systems that wish to generate 859 or process the data. 861 This property allows the direct inclusion of ancillary data whose 862 schema is defined elsewhere. This property also includes 863 parameters to clearly identify the type of the schema being used 864 so that clients can quickly and easily spot what is relevant 865 within the calendar data and present that to users or process it 866 within the calendaring system. 868 iCalendar does support an "ATTACH" property which can be used to 869 include documents or links to documents within the calendar data. 870 However, that property does not allow data to be included as a 871 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 872 attachments are often treated as "opaque" data to be processed by 873 some other system rather than the calendar client. Thus the 874 existing "ATTACH" property is not sufficient to cover the specific 875 needs of inclusion of schema data. Extending the "ATTACH" 876 property to support a new value type would likely cause 877 interoperability problems. Thus a new property to support 878 inclusion of schema data is warranted. 880 Format Definition: 882 This property is defined by the following notation: 884 sdataprop = "STRUCTURED-DATA" sdataparam 885 (":" text) / 886 ( 887 ";" "ENCODING" "=" "BASE64" 888 ";" "VALUE" "=" "BINARY" 889 ":" binary 890 ) / 891 ( 892 ";" "VALUE" "=" "URI" 893 ":" uri 894 ) 895 CRLF 897 sdataparam = *( 898 ; 899 ; The following is OPTIONAL for a URI value, 900 ; RECOMMENDED for a TEXT or BINARY value, 901 ; and MUST NOT occur more than once. 902 ; 903 (";" fmttypeparam) / 904 (";" schemaparam) / 905 ; 906 ; The following is OPTIONAL, 907 ; and MAY occur more than once. 908 ; 909 (";" other-param) 910 ; 911 ) 913 Example: The following is an example of this property: 915 STRUCTURED-DATA;FMTTYPE=application/ld+json; 916 SCHEMA="https://schema.org/SportsEvent"; 917 VALUE=TEXT:{\n 918 "@context": "http://schema.org"\,\n 919 "@type": "SportsEvent"\,\n 920 "homeTeam": "Pittsburgh Pirates"\,\n 921 "awayTeam": "San Francisco Giants"\n 922 }\n 924 8. New Components 925 8.1. Participant 927 Component name: PARTICIPANT 929 Purpose: This component provides information about a participant in 930 an event or optionally a plain text typed value. 932 Conformance: This component MAY be appear in any iCalendar 933 component. 935 Description: This component provides information about an 936 participant in an event, task or poll. A participant may be an 937 attendee in a scheduling sense and the ATTENDEE property may be 938 specified in addition. Participants in events can be individuals 939 or organizations, for example a soccer team, the spectators, or 940 the musicians. 942 The SOURCE property if present may refer to an external definition 943 of the participant - such as a vcard. 945 The STRUCTURED-ADDRESS property if present will provide a cal- 946 address. If an ATTENDEE property has the same value the 947 participant is considered schedulable. The PARTICIPANT component 948 can be used to contain additional meta-data related to the 949 attendee. 951 Format Definition: 953 This property is defined by the following notation: 955 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 956 partprop *alarmc 957 "END" ":" "PARTICIPANT" CRLF 959 partprop = *( 960 ; 961 ; The following are REQUIRED, 962 ; but MUST NOT occur more than once. 963 ; 964 dtstamp / participanttype / 965 ; 966 ; The following are OPTIONAL, 967 ; but MUST NOT occur more than once. 968 ; 969 created / description / last-mod / priority / seq / 970 source / status / scheduleaddress / summary / url / 971 ; 972 ; The following are OPTIONAL, 973 ; and MAY occur more than once. 974 ; 975 attach / categories / comment / 976 contact / rstatus / related / 977 resources / x-prop / iana-prop 978 ; 979 ) 981 Note: When the PRIORITY is supplied it defines the ordering of 982 PARTICIPANT components with the same value for the TYPE parameter. 984 Example: 986 The following is an example of this component. It contains a SOURCE 987 property which points to a VCARD providing information about the 988 event participant. 990 BEGIN:PARTICIPANT 991 PARTICIPANT-TYPE:PRINCIPAL_PERFORMER 992 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 993 END:PARTICIPANT 995 Example: 997 The following is an example for the primary contact. 999 BEGIN: PARTICIPANT 1000 SOURCE;FMTTYPE=text/vcard; 1001 http://dir.example.com/vcard/contacts/contact1.vcf 1002 PARTICIPANT-TYPE:PRIMARY-CONTACT 1003 DESCRIPTION:A contact: 1004 END:PARTICIPANT 1006 8.2. Schedulable Participant 1008 A PARTICIPANT component may represent someone or something that needs 1009 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 1010 The PARTICIPANT component may also represent someone or something 1011 that is NOT to receive scheduling messages. 1013 A PARTICIPANT component is defined to be schedulable if 1015 o It contains a CALENDAR-ADDRESS property 1017 o That property value is the same as the value for an ATTENDEE 1018 property. 1020 If both of these conditions apply then the participant defined by the 1021 value of the URL property will take part in scheduling operations as 1022 defined in [RFC5546]. 1024 An appropriate use for the PARTICIPANT component in scheduling would 1025 be to store SEQUENCE and DTSTAMP properties associated with replies 1026 from each ATTENDEE. A LOCATION property within the PARTICIPANT 1027 component might allow better selection of meeting times when 1028 participants are in different timezones. 1030 9. Extended examples 1032 The following are some examples of the use of the properties defined 1033 in this specification. They include additional properties defined in 1034 [RFC7986] which includes IMAGE. 1036 9.1. Example 1 1037 The following is an example of a VEVENT describing a concert. It 1038 includes location information for the venue itself as well as 1039 references to parking and restaurants. 1041 BEGIN:VEVENT 1042 CREATED:20170216T145739Z 1043 DESCRIPTION: Piano Sonata No 3\n 1044 Piano Sonata No 30 1045 DTSTAMP:20171116T145739Z 1046 DTSTART;TZID=America/New_York:20170315T150000Z 1047 DTEND;TZID=America/New_York:20170315T163000Z 1048 LAST-MODIFIED:20170216T145739Z 1049 SUMMARY:Beethoven Piano Sonatas 1050 UID:123456 1051 STRUCTURED-LOCATION;LABEL="The venue": 1052 http://dir.example.com/venues/big-hall.vcf 1053 STRUCTURED-LOCATION;LABEL="The venue": 1054 http://dir.example.com/venues/parking.vcf 1055 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 1056 ttp://example.com/images/concert.png 1057 BEGIN:PARTICIPANT 1058 PARTICIPANT-TYPE:SPONSOR 1059 SOURCE:http://example.com/sponsor.vcf 1060 END:PARTICIPANT 1061 BEGIN:PARTICIPANT 1062 PARTICIPANT-TYPE:PERFORMER: 1063 SOURCE:http://www.example.com/people/johndoe.vcf 1064 END:PARTICIPANT 1065 END:VEVENT 1067 9.2. Example 2 1068 The following is an example of a VEVENT describing a meeting. One of 1069 the attendees is a remote participant. 1071 BEGIN:VEVENT 1072 CREATED:20170216T145739Z 1073 DTSTAMP:20101116T145739Z 1074 DTSTART;TZID=America/New_York:20170315T150000Z 1075 DTEND;TZID=America/New_York:20170315T163000Z 1076 LAST-MODIFIED:20170216T145739Z 1077 SUMMARY:Conference plaaning 1078 UID:123456 1079 ORGANIZER:mailto:a@example.com 1080 ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com 1081 ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com 1082 BEGIN:PARTICIPANT 1083 PARTICIPANT-TYPE:ACTIVE: 1084 SOURCE:http://www.example.com/people/b.vcf 1085 LOCATION:At home 1086 END:PARTICIPANT 1087 END:VEVENT 1089 10. Security Considerations 1091 Applications using these properties need to be aware of the risks 1092 entailed in using the URIs provided as values. See [RFC3986] for a 1093 discussion of the security considerations relating to URIs. 1095 Security considerations relating to the "ATTACH" property, as 1096 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 1097 property. 1099 11. Privacy Considerations 1101 Properties with a "URI" value type can expose their users to privacy 1102 leaks as any network access of the URI data can be tracked. Clients 1103 SHOULD NOT automatically download data referenced by the URI without 1104 explicit instruction from users. This specification does not 1105 introduce any additional privacy concerns beyond those described in 1106 [RFC5545]. 1108 12. IANA Considerations 1110 This section defines updates to the tables defined in [RFC5545] and 1111 new tables. 1113 12.1. Additional iCalendar Registrations 1115 12.1.1. Property Registrations 1117 This document defines the following new iCalendar properties to be 1118 added to the registry defined in Section 8.2.3 of [RFC5545]: 1120 +---------------------+---------+----------------------+ 1121 | Property | Status | Reference | 1122 +---------------------+---------+----------------------+ 1123 | CALENDAR-ADDRESS | Current | RFCXXXX, Section 7.2 | 1124 | PARTICIPANT-TYPE | Current | RFCXXXX, Section 7.1 | 1125 | SOURCE | Current | RFCXXXX, Section 6 | 1126 | STRUCTURED-DATA | Current | RFCXXXX, Section 7.6 | 1127 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 7.3 | 1128 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 7.4 | 1129 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 7.5 | 1130 +---------------------+---------+----------------------+ 1132 12.1.2. Parameter Registrations 1134 This document defines the following new iCalendar property parameters 1135 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1137 +--------------------+---------+----------------------+ 1138 | Property Parameter | Status | Reference | 1139 +--------------------+---------+----------------------+ 1140 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1141 | ORDER | Current | RFCXXXX, Section 5.3 | 1142 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1143 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1144 +--------------------+---------+----------------------+ 1146 12.1.3. Component Registrations 1148 This document defines the following new iCalendar components to be 1149 added to the registry defined in Section 8.3.1 of [RFC5545]: 1151 +-------------+---------+----------------------+ 1152 | Component | Status | Reference | 1153 +-------------+---------+----------------------+ 1154 | PARTICIPANT | Current | RFCXXXX, Section 8.1 | 1155 +-------------+---------+----------------------+ 1157 12.2. New Registration Tables 1159 This section defines new registration tables for PARTICIPANT-TYPE and 1160 RESTYPE values. These tables maybe updated using the same approaches 1161 laid down in Section 8.2.1 of [RFC5545] 1163 12.2.1. Participant Types Registry 1165 The following table has been used to initialize the participant types 1166 registry. 1168 +-------------------+---------+----------------------+ 1169 | Participant Type | Status | Reference | 1170 +-------------------+---------+----------------------+ 1171 | ACTIVE | Current | RFCXXXX, Section 7.1 | 1172 | INACTIVE | Current | RFCXXXX, Section 7.1 | 1173 | SPONSOR | Current | RFCXXXX, Section 7.1 | 1174 | CONTACT | Current | RFCXXXX, Section 7.1 | 1175 | BOOKING-CONTACT | Current | RFCXXXX, Section 7.1 | 1176 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 7.1 | 1177 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 7.1 | 1178 | PLANNER-CONTACT | Current | RFCXXXX, Section 7.1 | 1179 | PERFORMER | Current | RFCXXXX, Section 7.1 | 1180 | SPEAKER | Current | RFCXXXX, Section 7.1 | 1181 +-------------------+---------+----------------------+ 1183 12.2.2. Resource Types Registry 1185 The following table has been used to initialize the resource types 1186 registry. 1188 +-------------------------+---------+----------------------+ 1189 | Resource Type | Status | Reference | 1190 +-------------------------+---------+----------------------+ 1191 | PROJECTOR | Current | RFCXXXX, Section 5.2 | 1192 | ROOM | Current | RFCXXXX, Section 5.2 | 1193 | REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 5.2 | 1194 | REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 5.2 | 1195 +-------------------------+---------+----------------------+ 1197 13. Acknowledgements 1199 The author would like to thank Chuck Norris of eventful.com for his 1200 work which led to the development of this RFC. 1202 The author would also like to thank the members of CalConnect, The 1203 Calendaring and Scheduling Consortium, the Event Publication 1204 technical committee and the following individuals for contributing 1205 their ideas and support: 1207 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, 1209 14. Normative References 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1217 Resource Identifier (URI): Generic Syntax", STD 66, 1218 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1219 . 1221 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1222 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1223 . 1225 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1226 Scheduling Core Object Specification (iCalendar)", 1227 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1228 . 1230 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1231 Interoperability Protocol (iTIP)", RFC 5546, 1232 DOI 10.17487/RFC5546, December 2009, 1233 . 1235 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 1236 DOI 10.17487/RFC7986, October 2016, 1237 . 1239 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1240 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1241 May 2017, . 1243 [W3C.REC-xml-20060816] 1244 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1245 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1246 Edition)", World Wide Web Consortium Recommendation REC- 1247 xml-20060816, August 2006, 1248 . 1250 Appendix A. Open issues 1252 None at the moment 1254 Appendix B. Change log 1256 calext-v04 2017-10-11 MD 1258 o Change SCHEDULE-ADDRESS to CALENDAR-ADDRESS 1260 o Explicitly broaden scope of SOURCE 1262 o Add initial registry for RESTYPE and move new tables into separate 1263 section. 1265 o Fix PARTTYPE/PARTICPANT-TYPE inconsistency 1267 calext-v03 2017-10-09 MD 1269 o Mostly typographical and other minor changes 1271 calext-v02 2017-04-20 MD 1273 o Add SCHEDULE-ADDRESS property 1275 o PARTICIPANT becomes a component rather than a property. Turn many 1276 of the former parameters into properties. 1278 o Use existing ATTENDEE property for scheduling. 1280 calext-v01 2017-02-18 MD 1282 o Change ASSOCIATE back to PARTICIPANT 1284 o PARTICIPANT becomes a component rather than a property. Turn many 1285 of the former parameters into properties. 1287 calext-v00 2016-08-?? MD 1289 o Name changed - taken up by calext working group 1291 v06 2016-06-26 MD 1293 o Fix up abnf 1295 o change ref to ietf from daboo 1297 o take out label spec - use Cyrus spec 1298 v05 2016-06-14 MD 1300 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1302 o Change ORDER to integer >= 1. 1304 o Incorporate Structured-Data into this specification. 1306 v04 2014-02-01 MD 1308 o Added updates attribute. 1310 o Minor typos. 1312 o Resubmitted mostly to refresh the draft. 1314 v03 2013-03-06 MD 1316 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1318 o Added section showing modifications to components. 1320 o Replace ID with GROUP and modify HASH. 1322 o Replace TITLE param with LABEL. 1324 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1326 v02 2012-11-02 MD 1328 o Collapse sections with description of properties and the use cases 1329 into a section with sub-sections. 1331 o New section to describe relating properties. 1333 o Remove idref and upgrade hash to have the reference 1335 o No default value types on properties.. 1337 v01 2012-10-18 MD Many changes. 1339 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1341 o Add a STRUCTURED-RESOURCE property 1343 o STYLED-DESCRIPTION to handle rich text 1345 o Much more... 1347 2011-01-07 1349 o Remove MEDIA - it's going in the Cyrus RFC 1351 o Rename EXTENDED-... to STRUCTURED-... 1353 o Add TYPE parameter to SPONSOR 1355 v00 2007-10-19 MD Initial version 1357 Author's Address 1359 Michael Douglass 1360 Spherical Cow Group 1361 226 3rd Street 1362 Troy, NY 12180 1363 USA 1365 Email: mdouglass@sphericalcowgroup.com 1366 URI: http://sphericalcowgroup.com