idnits 2.17.1 draft-ietf-calext-eventpub-extensions-03.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]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to directly say this. It does mention RFC5545 though, so this could be OK. -- The draft header indicates that this document updates RFC5546, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) (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 4, 2017) is 2542 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 (==), 4 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 4, 2017 5 Intended status: Standards Track 6 Expires: November 5, 2017 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-03 11 Abstract 13 This specification introduces a number of new iCalendar properties 14 and components which are of particular use for event publishers and 15 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 http://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 5, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 5 62 4. Modifications to Calendar Components . . . . . . . . . . . . 6 63 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7 64 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Participant Type . . . . . . . . . . . . . . . . . . . . 9 70 6.2. Schedule Address . . . . . . . . . . . . . . . . . . . . 9 71 6.3. Styled-Description . . . . . . . . . . . . . . . . . . . 10 72 6.4. Structured-Location . . . . . . . . . . . . . . . . . . . 12 73 6.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 13 74 6.6. Source . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 6.7. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16 76 7. New Components . . . . . . . . . . . . . . . . . . . . . . . 18 77 7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 19 78 7.2. Schedulable Participant . . . . . . . . . . . . . . . . . 21 79 8. Participant Types . . . . . . . . . . . . . . . . . . . . . . 21 80 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 22 81 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 22 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 12.1. Property Registrations . . . . . . . . . . . . . . . . . 24 86 12.2. Parameter Registrations . . . . . . . . . . . . . . . . 24 87 12.3. Component Registrations . . . . . . . . . . . . . . . . 24 88 12.4. Participant Types Registry . . . . . . . . . . . . . . . 25 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 90 14. Normative References . . . . . . . . . . . . . . . . . . . . 25 91 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 26 92 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 26 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 The currently existing iCalendar standard [RFC5545] lacks useful 98 methods for referencing additional, external information relating to 99 calendar components. Additionally there is no standard way to 100 provide rich text descriptions or meta-data associated with the 101 event. 103 Current practice is to embed this information as links in the 104 description or to add x-properties. 106 This document defines a number of properties and a component 107 referencing such external information that can provide additional 108 information about an iCalendar component. The intent is to allow 109 interchange of such information between applications or systems 110 (e.g., between clients, between client and server, and between 111 servers). Formats such as VCARD are likely to be most useful to the 112 receivers of such events as they may be used in other applications - 113 such as address books. 115 The following properties are defined in this specification 117 Styled-Description: Supports HTML descriptions. Event publishers 118 typically wish to provide more and better formatted information 119 about the event. 121 Structured-Location: There may be a number of locations associated 122 with an event. This provides detailed information about the 123 location. 125 Structured-Resource: Events need resources such as rooms, 126 projectors, conferencing capabilities. 128 Structured-Data: The existing properties in iCalendar cover key 129 elements of events and tasks such as start time, end time, 130 location, summary, etc. However, different types of events often 131 have other specific "fields" that it is useful to include in the 132 calendar data. For example, an event representing an airline 133 flight could include the airline, flight number, departure and 134 arrival airport codes, check-in and gate-closing times etc. As 135 another example, a sporting event might contain information about 136 the type of sport, the home and away teams, the league the teams 137 are in, information about nearby parking, etc. 139 In addition this specification defines a new PARTICIPANT component. 140 Many people or groups may participate in an event. This component 141 provides detailed information. Such participants may act as 142 attendees to the event (or derived events) or may just provide a 143 reference - perhaps for mailing lists. 145 1.1. Conventions Used in This Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 [RFC2119]. 152 2. Components and properties 154 Previous extensions to the calendaring standards have been largely 155 restricted to the addition of properties or parameters. This is 156 partly because iCalendar libraries had trouble handling components 157 nested deeper than those defined in [RFC5545] 159 In a break with this 'tradition' this specification introduces one of 160 these extensions as a component rather than a property. This is a 161 better match for the way XML and JSON handles such structures and 162 allows richer definitions. 164 It also allows for the addition of extra properties inside the 165 component and resolves some of the problems of trying to add detailed 166 information as a parameter. 168 3. Typed References 170 The properties defined here can all reference external meta-data 171 which may be used by applications to provide enhanced value to users. 172 By providing type information as parameters, clients and servers are 173 able to discover interesting references and make use of them, perhaps 174 for indexing or the presentation of additional related information 175 for the user. 177 The [RFC5545] LOCATION property provides only an unstructured single 178 text value for specifying the location where an event (or task) will 179 occur. This is inadequate for use cases where structured location 180 information (e.g. address, region, country, postal code) is required 181 or preferred, and limits widespread adoption of iCalendar in those 182 settings. 184 Using STRUCTURED-LOCATION, information about a number of interesting 185 locations can be communicated, for example, parking, restaurants and 186 the venue. Servers and clients can retrieve the objects when storing 187 the event and use them to index by geographic location. 189 These PARTICIPANT component is designed to handle common use cases in 190 event publication. It is generally important to provide information 191 about the organizers of such events. Sponsors wish to be referenced 192 in a prominent manner. In social calendaring it is often important 193 to identify the active participants in the event, for example a 194 school sports team, and the inactive participants, for example the 195 parents. 197 When a calendar client receives a calendar component it can search 198 the set of supplied properties looking for those of particular 199 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 200 to help the selection. 202 3.1. Use Cases 204 The main motivation for these properties has been event publication 205 but there are opportunities for use elsewhere. The following use 206 cases will describe some possible scenarios. 208 3.1.1. Piano Concert Performance 210 In putting together a concert there are many participants: piano 211 tuner, performer, stage hands etc. In addition there are sponsors 212 and various contacts to be provided. There will also be a number of 213 related locations. A number of events can be created, all of which 214 relate to the performance in different ways. 216 There may be an iTip [RFC5546] meeting request for the piano tuner 217 who will arrive before the performance. Other members of staff may 218 also receive meeting requests. 220 An event can also be created for publication which will have a 221 PARTICIPANT component for the pianist providing a reference to vcard 222 information about the performer. This event would also hold 223 information about parking, local subway stations and the venue 224 itself. In addition, there will be sponsorship information for 225 sponsors of the event and perhaps paid sponsorship properties 226 essentially advertising local establishments. 228 3.1.2. Itineraries 230 These additions also provide opportunities for the travel industry. 231 When booking a flight the PARTICIPANT component can be used to 232 provide references to businesses at the airports and to car hire 233 businesses at the destination. 235 The embedded location information can guide the traveller at the 236 airport or to their final destination. The contact information can 237 provide detailed information about the booking agent, the airlines 238 and car hire companies and the hotel. 240 4. Modifications to Calendar Components 242 The following changes to the syntax defined in iCalendar [RFC5545] 243 are made here. New elements are defined in subsequent sections. 245 eventc = "BEGIN" ":" "VEVENT" CRLF 246 eventprop *alarmc *participantc 247 "END" ":" "VEVENT" CRLF 249 eventprop =/ *( 250 ; 251 ; The following are OPTIONAL, 252 ; and MAY occur more than once. 253 ; 254 styleddescription / strucloc / strucres / sdataprop 255 ; 256 ) 258 todoc = "BEGIN" ":" "VTODO" CRLF 259 todoprop *alarmc *participantc 260 "END" ":" "VTODO" CRLF 262 todoprop =/ *( 263 ; 264 ; The following are OPTIONAL, 265 ; and MAY occur more than once. 266 ; 267 styleddescription / strucloc / strucres / sdataprop 268 ; 269 ) 271 journalc = "BEGIN" ":" "VJOURNAL" CRLF 272 jourprop *participantc 273 "END" ":" "VJOURNAL" CRLF 275 jourprop =/ *( 276 ; 277 ; The following are OPTIONAL, 278 ; and MAY occur more than once. 279 ; 280 styleddescription / sdataprop 281 ; 282 ) 284 5. New Property Parameters 286 This specification makes use of the LABEL property parameter which is 287 defined in [RFC7986] 289 5.1. Loctype 291 Parameter name: LOCTYPE 293 Purpose: To specify the type of location. 295 Format Definition: 297 This parameter is defined by the following notation: 299 loctypeparam = "LOCTYPE" "=" param-value 301 Description: This parameter MAY be specified on STRUCTURED-LOCATION 302 and provides a way to differentiate multiple properties. For 303 example, it allows event producers to provide location information 304 for the venue and the parking. 306 Values for this parameter are taken from the values defined in 307 [RFC4589]. New location types SHOULD be registered in the manner 308 laid down in that specification 310 5.2. Restype 312 Parameter name: RESTYPE 314 Purpose: To specify the type of resource. 316 Format Definition: 318 This parameter is defined by the following notation: 320 restypeparam = "RESTYPE" "=" param-value 322 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 323 and provides a way to differentiate multiple properties. 325 Values for this parameter are taken from the values defined in 326 [todo]. New resource types SHOULD be registered in the manner 327 laid down in that specification 329 5.3. Order 331 Parameter name: ORDER 333 Purpose: To define ordering for the associated property. 335 Format Definition: 337 This parameter is defined by the following notation: 339 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 341 Description: The ORDER parameter is OPTIONAL and is used to indicate 342 the relative ordering of the corresponding instance of a property. 343 Its value MUST be an integer greater than or equal to 1 that 344 quantifies the order with 1 being the first in the ordering. 346 When the parameter is absent, the default MUST be to interpret the 347 property instance as being at the lowest level of ordering, that 348 is, the property will appear after any other instances of the same 349 property with any value of ORDER. 351 Note that the value of this parameter is to be interpreted only in 352 relation to values assigned to other corresponding instances of 353 the same property in the same entity. A given value, or the 354 absence of a value, MUST NOT be interpreted on its own. 356 This parameter MAY be applied to any property that allows multiple 357 instances. 359 5.4. Schema 361 Parameter Name: SCHEMA 363 Purpose: To specify the schema used for the content of a 364 "STRUCTURED-DATA" property value. 366 Format Definition: 368 This parameter is defined by the following notation: 370 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 372 Description: This property parameter SHOULD be specified on 373 "STRUCTURED-DATA" properties. When present it provides 374 identifying information about the nature of the content of the 375 corresponding "STRUCTURED-DATA" property value. This can be used 376 to supplement the media type information provided by the "FMTTYPE" 377 parameter on the corresponding property. 379 Example: 381 STRUCTURED-DATA;FMTTYPE=application/ld+json; 382 SCHEMA="https://schema.org/FlightReservation"; 383 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 385 6. New Properties 387 6.1. Participant Type 389 Property name: PARTICIPANT-TYPE 391 Purpose: To specify the type of participant. 393 Value type: The value type for this property is TEXT. The allowable 394 values are defined in Section 8. 396 Property Parameters: Non-standard parameters can be specified on 397 this property. 399 Conformance: This property MUST be specified within a PARTICIPANT 400 component. 402 Description: This property defines the type of participation in 403 events or tasks. Participants can be individuals or 404 organizations, for example a soccer team, the spectators, or the 405 musicians. 407 Format Definition: 409 This parameter is defined by the following notation: 411 participanttype = "PARTICIPANT-TYPE" "=" iana-token 413 6.2. Schedule Address 415 Property name: SCHEDULE-ADDRESS 417 Purpose: To specify the calendar address for a participant. 419 Value type: CAL-ADDRESS 421 Property Parameters: IANA or non-standard property parameters can be 422 specified on this property. 424 Conformance: This property MAY be specified within a PARTICIPANT 425 component. 427 Description: This property provides a calendar user address for the 428 participant. If there is an ATTENDEE property with the same value 429 then the participant is schedulable. 431 Format Definition: 433 This parameter is defined by the following notation: 435 scheduleaddress = "SCHEDULE-ADDRESS" "=" cal-address 437 6.3. Styled-Description 439 Property name: STYLED-DESCRIPTION 441 Purpose: This property provides for one or more rich-text 442 descriptions to replace or augment that provided by the 443 DESCRIPTION property. 445 Value type: There is no default value type for this property. The 446 value type can be set to URI or TEXT. Other text-based value 447 types can be used when defined in the future. Clients MUST ignore 448 any properties with value types they do not understand. 450 Property Parameters: IANA, non-standard, id, alternate text 451 representation, format type, and language property parameters can 452 be specified on this property. 454 Conformance: The property can be specified multiple times in the 455 "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. 457 Description: This property is used in the "VEVENT" and "VTODO" to 458 capture lengthy textual descriptions associated with the activity. 459 This property is used in the "VJOURNAL" calendar component to 460 capture one or more textual journal entries. This property is 461 used in the "VALARM" calendar component to capture the display 462 text for a DISPLAY category of alarm, and to capture the body text 463 for an EMAIL category of alarm. 465 VALUE=TEXT is used to provide rich-text variants of the plain-text 466 DESCRIPTION property. 468 VALUE=URI is used to provide a link to rich-text content which is 469 expected to be displayed inline as part of the event. 471 The intent of this property is limited to providing a styled and/ 472 or language specific version of the DESCRIPTION property. The URL 473 property should be used to link to websites or other related 474 information. 476 Applications MAY attempt to guess the media type of the resource 477 via inspection of its content if and only if the media type of the 478 resource is not given by the "FMTTYPE" parameter. If the media 479 type remains unknown, calendar applications SHOULD treat it as 480 type "text/html". 482 Multiple STYLED-DESCRIPTION properties may be used to provide 483 different formats or different language variants. 485 Format Definition: 487 This property is defined by the following notation: 489 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 490 ( 491 ( 492 ";" "VALUE" "=" "URI" 493 ":" uri 494 ) / 495 ( 496 ";" "VALUE" "=" "TEXT" 497 ":" text 498 ) 499 ) 500 CRLF 502 styleddescparam = *( 503 ; 504 ; The following are OPTIONAL, 505 ; but MUST NOT occur more than once. 506 ; 507 (";" altrepparam) / (";" languageparam) / 508 (";" fmttypeparam) / 509 ; 510 ; the following is OPTIONAL 511 ; and MAY occur more than once 512 ; 513 (";" other-param) 514 ) 516 Example: 518 The following is an example of this property. It points to an html 519 description. 521 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 523 6.4. Structured-Location 525 Property name: STRUCTURED-LOCATION 527 Purpose: This property provides a typed reference to external 528 information about the location of an event or optionally a plain 529 text typed value. 531 Value type: There is no default value type for this property. The 532 value type can be set to URI or TEXT. Other text-based value 533 types 535 Property Parameters: IANA, non-standard, label, loctype or format 536 type parameters can be specified on this property. 538 Conformance: This property MAY be specified zero or more times in 539 any iCalendar component. 541 Description: When used in a component the value of this property 542 provides information about the event venue or of related services 543 such as parking, dining, stations etc.. 545 When a LABEL parameter is supplied the language of the label must 546 match that of the content and of the LANGUAGE parameter if 547 present. 549 Format Definition: 551 This property is defined by the following notation: 553 strucloc = "STRUCTURED-LOCATION" struclocparam 554 ( 555 ( 556 ";" "VALUE" "=" "URI" 557 ":" uri 558 ) / 559 ( 560 ";" "VALUE" "=" "TEXT" 561 ":" text 562 ) 563 ) 564 CRLF 566 struclocparam = *( 567 ; 568 ; the following are OPTIONAL 569 ; but MUST NOT occur more than once 570 ; 571 (";" fmttypeparam) / 572 (";" labelparam) / 573 (";" languageparam) / 574 (";" loctypeparam) / 575 ; 576 ; the following is OPTIONAL 577 ; and MAY occur more than once 578 ; 579 (";" other-param) 580 ) 582 Example: 584 The following is an example of this property. It points to a venue. 586 STRUCTURED-LOCATION;LABEL="The venue": 587 http://dir.example.com/venues/big-hall.vcf 589 6.5. Structured-Resource 591 Property name: STRUCTURED-RESOURCE 593 Purpose: This property provides a typed reference to external 594 information about a resource or optionally a plain text typed 595 value. 597 Value type: The default value type for this property is URI. The 598 value type can also be set to TEXT to indicate plain text content. 600 Property Parameters: IANA, non-standard, label, restype or format 601 type parameters can be specified on this property. 603 Conformance: This property MAY be specified zero or more times in 604 any iCalendar component. 606 Description: When used in a component the value of this property 607 provides information about resources used for the event. 609 When a LABEL parameter is supplied the language of the label must 610 match that of the content and of the LANGUAGE parameter if 611 present. 613 Format Definition: 615 This property is defined by the following notation: 617 strucres = "STRUCTURED-RESOURCE" strucresparam (":" uri) / 618 ( 619 ";" "VALUE" "=" "TEXT" 620 ":" text 621 ) 622 CRLF 624 strucresparam = *( 625 ; 626 ; the following are OPTIONAL 627 ; but MUST NOT occur more than once 628 ; 629 (";" fmttypeparam) / 630 (";" labelparam) / 631 (";" languageparam) / 632 (";" restypeparam) / 633 ; 634 ; the following is OPTIONAL 635 ; and MAY occur more than once 636 ; 637 (";" other-param) 638 ) 640 Example: 642 The following is an example of this property. It refers to a 643 projector. 645 STRUCTURED-RESOURCE;restype="projector": 646 http://dir.example.com/projectors/3d.vcf 648 6.6. Source 650 Property name: SOURCE 652 Purpose: This property provides a reference to information about a 653 component such as a participant possibly as a vcard or optionally 654 a plain text typed value. 656 Value type: The default value type for this property is URI. The 657 value type can also be set to TEXT to indicate plain text content. 659 Property Parameters: Non-standard or format type parameters can be 660 specified on this property. 662 Conformance: This property MAY be appear in any iCalendar component. 664 Description: This property provides information about the component 665 in which it appears. It may provide a reference to a vcard giving 666 directory information about a resource or participant. 668 Format Definition: 670 This property is defined by the following notation: 672 source = "SOURCE" sourceparam 673 ( 674 ( 675 ";" "VALUE" "=" "URI" 676 ":" uri 677 ) / 678 ( 679 ";" "VALUE" "=" "TEXT" 680 ":" text 681 ) 682 ) 683 CRLF 685 sourceparam = *( 686 ; 687 ; the following are OPTIONAL 688 ; but MUST NOT occur more than once 689 ; 690 (";" fmttypeparam) / 691 ; 692 ; the following is OPTIONAL 693 ; and MAY occur more than once 694 ; 695 (";" other-param) 696 ; 697 ) 699 Example: 701 The following is an example referring to a VCARD. 703 SOURCE;FMTTYPE=text/vcard; 704 http://dir.example.com/vcard/contacts/contact1.vcf 706 6.7. Structured-Data 708 Property Name: STRUCTURED-DATA 710 Purpose: This property specifies ancillary data associated with the 711 calendar component. 713 Value Type: TEXT, BINARY or URI 715 Property Parameters: IANA, non-standard, inline encoding, and value 716 data type property parameters can be specified on this property. 717 The format type and schema parameters can be specified on this 718 property and are RECOMMENDED for text or inline binary encoded 719 content information. 721 Conformance: This property can be specified multiple times in an 722 iCalendar object. Typically it would be used in "VEVENT", 723 "VTODO", or "VJOURNAL" calendar components. 725 Description: This property is used to specify ancillary data in some 726 structured format either directly (inline) as a "TEXT" or "BINARY" 727 value, or as a link via a "URI" value. 729 Rather than define new iCalendar properties for the variety of 730 event types that might occur, it would be better to leverage 731 existing schemas for such data. For example, schemas available at 732 https://schema.org include different event types. By using 733 standard schemas, interoperability can be improved between 734 calendar clients and non-calendaring systems that wish to generate 735 or process the data. 737 This property allows the direct inclusion of ancillary data whose 738 schema is defined elsewhere. This property also includes 739 parameters to clearly identify the type of the schema being used 740 so that clients can quickly and easily spot what is relevant 741 within the calendar data and present that to users or process it 742 within the calendaring system. 744 iCalendar does support an "ATTACH" property which can be used to 745 include documents or links to documents within the calendar data. 746 However, that property does not allow data to be included as a 747 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 748 attachments are often treated as "opaque" data to be processed by 749 some other system rather than the calendar client. Thus the 750 existing "ATTACH" property is not sufficient to cover the specific 751 needs of inclusion of schema data. Extending the "ATTACH" 752 property to support a new value type would likely cause 753 interoperability problems. Thus a new property to support 754 inclusion of schema data is warranted. 756 Format Definition: 758 This property is defined by the following notation: 760 sdataprop = "STRUCTURED-DATA" sdataparam 761 (":" text) / 762 ( 763 ";" "ENCODING" "=" "BASE64" 764 ";" "VALUE" "=" "BINARY" 765 ":" binary 766 ) / 767 ( 768 ";" "VALUE" "=" "URI" 769 ":" uri 770 ) 771 CRLF 773 sdataparam = *( 774 ; 775 ; The following is OPTIONAL for a URI value, 776 ; RECOMMENDED for a TEXT or BINARY value, 777 ; and MUST NOT occur more than once. 778 ; 779 (";" fmttypeparam) / 780 (";" schemaparam) / 781 ; 782 ; The following is OPTIONAL, 783 ; and MAY occur more than once. 784 ; 785 (";" other-param) 786 ; 787 ) 789 Example: The following is an example of this property: 791 STRUCTURED-DATA;FMTTYPE=application/ld+json; 792 SCHEMA="https://schema.org/SportsEvent"; 793 VALUE=TEXT:{\n 794 "@context": "http://schema.org"\,\n 795 "@type": "SportsEvent"\,\n 796 "homeTeam": "Pittsburgh Pirates"\,\n 797 "awayTeam": "San Francisco Giants"\n 798 }\n 800 7. New Components 801 7.1. Participant 803 Component name: PARTICIPANT 805 Purpose: This component provides information about a participant in 806 an event or optionally a plain text typed value. 808 Conformance: This component MAY be appear in any iCalendar 809 component. 811 Description: This component provides information about an 812 participant in an event, task or poll. A participant may be an 813 attendee in a scheduling sense and the ATTENDEE property may be 814 specified in addition. Participants in events can be individuals 815 or organizations, for example a soccer team, the spectators, or 816 the musicians. 818 The SOURCE property if present may refer to an external definition 819 of the participant - such as a vcard. 821 The STRUCTURED-ADDRESS property if present will provide a cal- 822 address. If an ATTENDEE property has the same value the 823 participant is considered schedulable. The PARTICIPANT component 824 can be used to contain additional meta-data related to the 825 attendee. 827 Format Definition: 829 This property is defined by the following notation: 831 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 832 partprop *alarmc 833 "END" ":" "PARTICIPANT" CRLF 835 partprop = *( 836 ; 837 ; The following are REQUIRED, 838 ; but MUST NOT occur more than once. 839 ; 840 dtstamp / participanttype / 841 ; 842 ; The following are OPTIONAL, 843 ; but MUST NOT occur more than once. 844 ; 845 created / description / last-mod / priority / seq / 846 source / status / scheduleaddress / summary / url / 847 ; 848 ; The following are OPTIONAL, 849 ; and MAY occur more than once. 850 ; 851 attach / categories / comment / 852 contact / rstatus / related / 853 resources / x-prop / iana-prop 854 ; 855 ) 857 Note: When the PRIORITY is supplied it defines the ordering of 858 PARTICIPANT components with the same value for the TYPE parameter. 860 Example: 862 The following is an example of this component. It contains a SOURCE 863 property which points to a VCARD providing information about the 864 event participant. 866 BEGIN:PARTICIPANT 867 PARTTYPE:PRINCIPAL_PERFORMER 868 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 869 END:PARTICIPANT 871 Example: 873 The following is an example for the primary contact. 875 BEGIN: PARTICIPANT 876 SOURCE;FMTTYPE=text/vcard; 877 http://dir.example.com/vcard/contacts/contact1.vcf 878 PARTTYPE:PRIMARY-CONTACT 879 DESCRIPTION:A contact: 880 END:PARTICIPANT 882 7.2. Schedulable Participant 884 A PARTICIPANT component may represent someone or something that needs 885 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 886 The PARTICIPANT component may also represent someone or something 887 that is NOT to receive scheduling messages. 889 A PARTICIPANT component is defined to be schedulable if 891 o It contains a SCHEDULE-ADDRESS property 893 o That property value is the same as the value for an ATTENDEE 894 property. 896 If both of these conditions apply then the participant defined by the 897 value of the URL property will take part in scheduling operations as 898 defined in [RFC5546]. 900 An appropriate use for the PARTICIPANT component in scheduling would 901 be to store SEQUENCE and DTSTAMP properties associated with replies 902 from each ATTENDEE. A LOCATION property within the PARTICIPANT 903 component might allow better selection of meeting times when 904 participants are in different timezones. 906 8. Participant Types 908 This section describes types of participation and provide registered 909 values for the PARTTYPE property. 911 ACTIVE: A participant taking an active role - for example a team 912 member. 914 INACTIVE: A participant taking an inactive part - for example an 915 audience member. 917 SPONSOR: A sponsor of the event. The ORDER parameter may be used 918 with this participant type to define the relative order of 919 multiple sponsors. 921 CONTACT: Contact information for the event. The ORDER parameter may 922 be used with this participant type to define the relative order of 923 multiple contacts. 925 BOOKING-CONTACT: Contact information for reservations or payment 927 EMERGENCY-CONTACT: Contact in case of emergency 929 PUBLICITY-CONTACT: Contact for publicity 931 PLANNER-CONTACT: Contact for the event planner or organizer 933 PERFORMER: A performer - for example the soloist or the accompanist. 934 The ORDER parameter may be used with this participant type to 935 define the relative order of multiple performers. For example, 936 ORDER=1 could define the principal performer or soloist. 938 SPEAKER: Speaker at an event 940 9. Extended examples 942 The following are some examples of the use of the properties defined 943 in this specification. They include additional properties defined in 944 [RFC7986] which includes IMAGE and LIVEFEED. 946 9.1. Example 1 947 The following is an example of a VEVENT describing a concert. It 948 includes location information for the venue itself as well as 949 references to parking and restaurants. 951 BEGIN:VEVENT 952 CREATED:20101116T145739Z 953 DESCRIPTION: Piano Sonata No 3\n 954 Piano Sonata No 30 955 DTSTAMP:20101116T145739Z 956 DTSTART;TZID=America/New_York:20110315T150000Z 957 DTEND;TZID=America/New_York:20110315T163000Z 958 LAST-MODIFIED:20101116T145739Z 959 SUMMARY:Beethoven Piano Sonatas 960 UID:123456 961 STRUCTURED-LOCATION;LABEL="The venue": 962 http://dir.example.com/venues/big-hall.vcf 963 STRUCTURED-LOCATION;LABEL="The venue": 964 http://dir.example.com/venues/parking.vcf 965 BEGIN:PARTICIPANT 966 PARTTYPE:SPONSOR 967 SOURCE:http://example.com/sponsor.vcf 968 END:PARTICIPANT 969 BEGIN:PARTICIPANT 970 PARTTYPE:PERFORMER: 971 SOURCE:http://www.example.com/people/johndoe.vcf 972 END:PARTICIPANT 973 END:VEVENT 975 10. Security Considerations 977 Applications using these properties need to be aware of the risks 978 entailed in using the URIs provided as values. See [RFC3986] for a 979 discussion of the security considerations relating to URIs. 981 Security considerations relating to the "ATTACH" property, as 982 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 983 property. 985 11. Privacy Considerations 987 Properties with a "URI" value type can expose their users to privacy 988 leaks as any network access of the URI data can be tracked. Clients 989 SHOULD NOT automatically download data referenced by the URI without 990 explicit instruction from users. This specification does not 991 introduce any additional privacy concerns beyond those described in 992 [RFC5545]. 994 12. IANA Considerations 996 12.1. Property Registrations 998 This document defines the following new iCalendar properties to be 999 added to the registry defined in Section 8.2.3 of [RFC5545]: 1001 +---------------------+---------+----------------------+ 1002 | Property | Status | Reference | 1003 +---------------------+---------+----------------------+ 1004 | PARTTYPE | Current | RFCXXXX, Section 6.1 | 1005 | SCHEDULE-ADDRESS | Current | RFCXXXX, Section 6.2 | 1006 | STRUCTURED-DATA | Current | RFCXXXX, Section 6.7 | 1007 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 6.3 | 1008 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 6.4 | 1009 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 6.5 | 1010 | SOURCE | Current | RFCXXXX, Section 6.6 | 1011 +---------------------+---------+----------------------+ 1013 12.2. Parameter Registrations 1015 This document defines the following new iCalendar property parameters 1016 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1018 +--------------------+---------+----------------------+ 1019 | Property Parameter | Status | Reference | 1020 +--------------------+---------+----------------------+ 1021 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1022 | ORDER | Current | RFCXXXX, Section 5.3 | 1023 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1024 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1025 +--------------------+---------+----------------------+ 1027 12.3. Component Registrations 1029 This document defines the following new iCalendar components to be 1030 added to the registry defined in Section 8.3.1 of [RFC5545]: 1032 +-------------+---------+----------------------+ 1033 | Component | Status | Reference | 1034 +-------------+---------+----------------------+ 1035 | PARTICIPANT | Current | RFCXXXX, Section 7.1 | 1036 +-------------+---------+----------------------+ 1038 12.4. Participant Types Registry 1040 The following table has been used to initialize the participant types 1041 registry. 1043 +-------------------+---------+--------------------+ 1044 | Participant Type | Status | Reference | 1045 +-------------------+---------+--------------------+ 1046 | ACTIVE | Current | RFCXXXX, Section 8 | 1047 | INACTIVE | Current | RFCXXXX, Section 8 | 1048 | SPONSOR | Current | RFCXXXX, Section 8 | 1049 | CONTACT | Current | RFCXXXX, Section 8 | 1050 | BOOKING-CONTACT | Current | RFCXXXX, Section 8 | 1051 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 8 | 1052 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 8 | 1053 | PLANNER-CONTACT | Current | RFCXXXX, Section 8 | 1054 | PERFORMER | Current | RFCXXXX, Section 8 | 1055 | SPEAKER | Current | RFCXXXX, Section 8 | 1056 +-------------------+---------+--------------------+ 1058 13. Acknowledgements 1060 The author would like to thank Chuck Norris of eventful.com for his 1061 work which led to the development of this RFC. 1063 The author would also like to thank the members of the Calendaring 1064 and Scheduling Consortium Event Publication technical committee and 1065 the following individuals for contributing their ideas and support: 1067 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, 1069 The authors would also like to thank the Calendaring and Scheduling 1070 Consortium for advice with this specification. 1072 14. Normative References 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, 1076 DOI 10.17487/RFC2119, March 1997, 1077 . 1079 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1080 Resource Identifier (URI): Generic Syntax", STD 66, 1081 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1082 . 1084 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1085 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1086 . 1088 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1089 Scheduling Core Object Specification (iCalendar)", 1090 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1091 . 1093 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1094 Interoperability Protocol (iTIP)", RFC 5546, 1095 DOI 10.17487/RFC5546, December 2009, 1096 . 1098 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 1099 DOI 10.17487/RFC7986, October 2016, 1100 . 1102 [W3C.REC-xml-20060816] 1103 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1104 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1105 Edition)", World Wide Web Consortium Recommendation REC- 1106 xml-20060816, August 2006, 1107 . 1109 Appendix A. Open issues 1111 restype values: Need to determine what if any registry of resource 1112 types already exists and use that. 1114 Appendix B. Change log 1116 calext-v02 2017-04-20 MD 1118 o Add SCHEDULE-ADDRESS property 1120 o PARTICIPANT becomes a component rather than a property. Turn many 1121 of the former parameters into properties. 1123 o Use existing ATTENDEE property for scheduling. 1125 calext-v01 2017-02-18 MD 1127 o Change ASSOCIATE back to PARTICIPANT 1129 o PARTICIPANT becomes a component rather than a property. Turn many 1130 of the former parameters into properties. 1132 calext-v00 2016-08-?? MD 1134 o Name changed - taken up by calext working group 1136 v06 2016-06-26 MD 1138 o Fix up abnf 1140 o change ref to ietf from daboo 1142 o take out label spec - use Cyrus spec 1144 v05 2016-06-14 MD 1146 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1148 o Change ORDER to integer >= 1. 1150 o Incorporate Structured-Data into this specification. 1152 v04 2014-02-01 MD 1154 o Added updates attribute. 1156 o Minor typos. 1158 o Resubmitted mostly to refresh the draft. 1160 v03 2013-03-06 MD 1162 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1164 o Added section showing modifications to components. 1166 o Replace ID with GROUP and modify HASH. 1168 o Replace TITLE param with LABEL. 1170 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1172 v02 2012-11-02 MD 1174 o Collapse sections with description of properties and the use cases 1175 into a section with sub-sections. 1177 o New section to describe relating properties. 1179 o Remove idref and upgrade hash to have the reference 1180 o No default value types on properties.. 1182 v01 2012-10-18 MD Many changes. 1184 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1186 o Add a STRUCTURED-RESOURCE property 1188 o STYLED-DESCRIPTION to handle rich text 1190 o Much more... 1192 2011-01-07 1194 o Remove MEDIA - it's going in the Cyrus RFC 1196 o Rename EXTENDED-... to STRUCTURED-... 1198 o Add TYPE parameter to SPONSOR 1200 v00 2007-10-19 MD Initial version 1202 Author's Address 1204 Michael Douglass 1205 Spherical Cow Group 1206 226 3rd Street 1207 Troy, NY 12180 1208 USA 1210 Email: mdouglass@sphericalcowgroup.com 1211 URI: http://sphericalcowgroup.com