idnits 2.17.1 draft-ietf-calext-eventpub-extensions-01.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 (March 5, 2017) is 2581 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) == Unused Reference: 'RFC2434' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC5546' is defined on line 1051, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 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) March 5, 2017 5 Intended status: Standards Track 6 Expires: September 6, 2017 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-01 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 September 6, 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. Styled-Description . . . . . . . . . . . . . . . . . . . 9 71 6.3. Structured-Location . . . . . . . . . . . . . . . . . . . 11 72 6.4. Structured-Resource . . . . . . . . . . . . . . . . . . . 13 73 6.5. Source . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16 75 7. New Components . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 18 77 8. Participant Types . . . . . . . . . . . . . . . . . . . . . . 20 78 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 20 79 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 21 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 12.1. Property Registrations . . . . . . . . . . . . . . . . . 22 84 12.2. Parameter Registrations . . . . . . . . . . . . . . . . 22 85 12.3. Component Registrations . . . . . . . . . . . . . . . . 22 86 12.4. Participant Types Registry . . . . . . . . . . . . . . . 23 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 88 14. Normative References . . . . . . . . . . . . . . . . . . . . 23 89 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 24 90 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 24 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 The currently existing iCalendar standard [RFC5545] lacks useful 96 methods for referencing additional, external information relating to 97 calendar components. Additionally there is no standard way to 98 provide rich text descriptions or meta-data associated with the 99 event. 101 Current practice is to embed this information as links in the 102 description or to add x-properties. 104 This document defines a number of properties and components 105 referencing such external information that can provide additional 106 information about an iCalendar component. The intent is to allow 107 interchange of such information between applications or systems 108 (e.g., between clients, between client and server, and between 109 servers). Formats such as VCARD are likely to be most useful. 111 The following properties and components are defined in this 112 specification 114 Styled-Description: Supports HTML descriptions. Event publishers 115 typically wish to provide more and better formatted information 116 about the event. 118 Structured-Location: There may be a number of locations associated 119 with an event. This provides detailed information about the 120 location. 122 Structured-Resource: Events need resources such as rooms, 123 projectors, conferencing capabilities. 125 Structured-Data: The existing properties in iCalendar cover key 126 elements of events and tasks such as start time, end time, 127 location, summary, etc. However, different types of events often 128 have other specific "fields" that it is useful to include in the 129 calendar data. For example, an event representing an airline 130 flight could include the airline, flight number, departure and 131 arrival airport codes, check-in and gate-closing times etc. As 132 another example, a sporting event might contain information about 133 the type of sport, the home and away teams, the league the teams 134 are in, information about nearby parking, etc. 136 Participant: Many people or groups may participate in an event. 137 This component provides detailed information. Such participants 138 may act as attendees to the event (or derived events) or may just 139 provide a reference - perhaps for mailing lists. 141 1.1. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119]. 148 2. Components and properties 150 Previous extensions to the calendaring standards have been largely 151 restricted to the addition of properties or parameters. This is 152 partly because iCalendar libraries had trouble handling components 153 nested deeper than those defined in [RFC5545] 155 In a break with this 'tradition' this specification introduces some 156 of these extensions as components rather than properties. This is a 157 better match for the way XML and JSON handles such structures and 158 allows richer definitions. 160 It also allows for the addition of extra properties inside the 161 component and resolves some of the problems of trying to add detailed 162 information as a parameter. 164 3. Typed References 166 The properties defined here can all reference external meta-data 167 which may be used by applications to provide enhanced value to users. 168 By providing type information as parameters, clients and servers are 169 able to discover interesting references and make use of them, perhaps 170 for indexing or the presentation of additional related information 171 for the user. 173 These properties are designed to handle common use cases in event 174 publication. It is generally important to provide information about 175 the organizers of such events. Sponsors wish to be referenced in a 176 prominent manner. In social calendaring it is often important to 177 identify the active participants in the event, for example a school 178 sports team, and the inactive participants, for example the parents. 180 The [RFC5545] LOCATION property provides only an unstructured single 181 text value for specifying the location where an event (or task) will 182 occur. This is inadequate for use cases where structured location 183 information (e.g. address, region, country, postal code) is required 184 or preferred, and limits widespread adoption of iCalendar in those 185 settings. 187 Using STRUCTURED-LOCATION, information about a number of interesting 188 locations can be communicated, for example, parking, restaurants and 189 the venue. Servers and clients can retrieve the objects when storing 190 the event and use them to index by geographic location. 192 When a calendar client receives a calendar component it can search 193 the set of supplied properties looking for those of particular 194 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 195 to help the selection. 197 3.1. Use Cases 199 The main motivation for these properties has been event publication 200 but there are opportunities for use elsewhere. The following use 201 cases will describe some possible scenarios. 203 3.1.1. Piano Concert Performance 205 In putting together a concert there are many participants: piano 206 tuner, performer, stage hands etc. In addition there are sponsors 207 and various contacts to be provided. There will also be a number of 208 related locations. A number of events can be created, all of which 209 relate to the performance in different ways. 211 There may be an iTip [RFC5545] meeting request for the piano tuner 212 who will arrive before the performance. Other members of staff may 213 also receive meeting requests. 215 An event can also be created for publication which will have a 216 PARTICIPANT component for the pianist providing a reference to vcard 217 information about the performer. This event would also hold 218 information about parking, local subway stations and the venue 219 itself. In addition, there will be sponsorship information for 220 sponsors of the event and perhaps paid sponsorship properties 221 essentially advertising local establishments. 223 3.1.2. Itineraries 225 These additions also provide opportunities for the travel industry. 226 When booking a flight the PARTICIPANT component can be used to 227 provide references to businesses at the airports and to car hire 228 businesses at the destination. 230 The embedded location information can guide the traveller at the 231 airport or to their final destination. The contact information can 232 provide detailed information about the booking agent, the airlines 233 and car hire companies and the hotel. 235 4. Modifications to Calendar Components 237 The following changes to the syntax defined in iCalendar [RFC5545] 238 are made here. New elements are defined in subsequent sections. 240 eventc = "BEGIN" ":" "VEVENT" CRLF 241 eventprop *alarmc *participantc 242 "END" ":" "VEVENT" CRLF 244 eventprop =/ *( 245 ; 246 ; The following are OPTIONAL, 247 ; and MAY occur more than once. 248 ; 249 styleddescription / strucloc / strucres / sdataprop 250 ; 251 ) 253 todoc = "BEGIN" ":" "VTODO" CRLF 254 todoprop *alarmc *participantc 255 "END" ":" "VTODO" CRLF 257 todoprop =/ *( 258 ; 259 ; The following are OPTIONAL, 260 ; and MAY occur more than once. 261 ; 262 styleddescription / strucloc / strucres / sdataprop 263 ; 264 ) 266 journalc = "BEGIN" ":" "VJOURNAL" CRLF 267 jourprop *participantc 268 "END" ":" "VJOURNAL" CRLF 270 jourprop =/ *( 271 ; 272 ; The following are OPTIONAL, 273 ; and MAY occur more than once. 274 ; 275 styleddescription / sdataprop 276 ; 277 ) 279 5. New Property Parameters 281 This specification makes use of the LABEL property parameter which is 282 defined in [I-D.ietf-calext-extensions] 284 5.1. Loctype 286 Parameter name: LOCTYPE 288 Purpose: To specify the type of location. 290 Format Definition: 292 This parameter is defined by the following notation: 294 loctypeparam = "LOCTYPE" "=" param-value 296 Description: This parameter MAY be specified on STRUCTURED-LOCATION 297 and provides a way to differentiate multiple properties. For 298 example, it allows event producers to provide location information 299 for the venue and the parking. 301 Values for this parameter are taken from the values defined in 302 [RFC4589]. New location types SHOULD be registered in the manner 303 laid down in that specification 305 5.2. Restype 307 Parameter name: RESTYPE 309 Purpose: To specify the type of resource. 311 Format Definition: 313 This parameter is defined by the following notation: 315 restypeparam = "RESTYPE" "=" param-value 317 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 318 and provides a way to differentiate multiple properties. 320 Values for this parameter are taken from the values defined in 321 [todo]. New resource types SHOULD be registered in the manner 322 laid down in that specification 324 5.3. Order 326 Parameter name: ORDER 328 Purpose: To define ordering for the associated property. 330 Format Definition: 332 This parameter is defined by the following notation: 334 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 336 Description: The ORDER parameter is OPTIONAL and is used to indicate 337 the relative ordering of the corresponding instance of a property. 338 Its value MUST be an integer greater than or equal to 1 that 339 quantifies the order. Lower values correspond to a higher level 340 of ordering, with 1 being the highest. 342 When the parameter is absent, the default MUST be to interpret the 343 property instance as being at the lowest level of ordering. 345 Note that the value of this parameter is to be interpreted only in 346 relation to values assigned to other corresponding instances of 347 the same property in the same entity. A given value, or the 348 absence of a value, MUST NOT be interpreted on its own. 350 This parameter MAY be applied to any property that allows multiple 351 instances. 353 5.4. Schema 355 Parameter Name: SCHEMA 357 Purpose: To specify the schema used for the content of a 358 "STRUCTURED-DATA" property value. 360 Format Definition: 362 This parameter is defined by the following notation: 364 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 366 Description: This property parameter SHOULD be specified on 367 "STRUCTURED-DATA" properties. When present it provides 368 identifying information about the nature of the content of the 369 corresponding "STRUCTURED-DATA" property value. This can be used 370 to supplement the media type information provided by the "FMTTYPE" 371 parameter on the corresponding property. 373 Example: 375 STRUCTURED-DATA;FMTTYPE=application/ld+json; 376 SCHEMA="https://schema.org/FlightReservation"; 377 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 379 6. New Properties 381 6.1. Participant Type 383 Property name: PARTTYPE 385 Purpose: To specify the type of participant. 387 Value type: The value type for this property is TEXT. The allowable 388 values are defined in Section 8. 390 Property Parameters: Non-standard parameters can be specified on 391 this property. 393 Conformance: This property MUST be specified within a PARTICIPANT 394 component. 396 Description: This property defines the type of participation in 397 events or tasks. Participants can be individuals or 398 organizations, for example a soccer team, the spectators, or the 399 musicians. 401 Format Definition: 403 This parameter is defined by the following notation: 405 participanttype = "PARTICIPANT-TYPE" "=" iana-token 407 6.2. Styled-Description 409 Property name: STYLED-DESCRIPTION 411 Purpose: This property provides for one or more rich-text 412 descriptions to replace or augment that provided by the 413 DESCRIPTION property. 415 Value type: There is no default value type for this property. The 416 value type can be set to URI or TEXT. Other text-based value 417 types can be used when defined in the future. Clients MUST ignore 418 any properties with value types they do not understand. 420 Property Parameters: IANA, non-standard, id, alternate text 421 representation, and language property parameters can be specified 422 on this property. 424 Conformance: The property can be specified multiple times in the 425 "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. 427 Description: This property is used in the "VEVENT" and "VTODO" to 428 capture lengthy textual descriptions associated with the activity. 429 This property is used in the "VJOURNAL" calendar component to 430 capture one or more textual journal entries. This property is 431 used in the "VALARM" calendar component to capture the display 432 text for a DISPLAY category of alarm, and to capture the body text 433 for an EMAIL category of alarm. 435 VALUE=TEXT is used to provide rich-text variants of the plain-text 436 DESCRIPTION property. 438 VALUE=URI is used to provide a link to rich-text content which is 439 expected to be displayed inline as part of the event. 441 The intent of this property is limited to providing a styled and/ 442 or language specific version of the DESCRIPTION property. The URL 443 property should be used to link to websites or other related 444 information. 446 Applications MAY attempt to guess the media type of the resource 447 via inspection of its content if and only if the media type of the 448 resource is not given by the "FMTTYPE" parameter. If the media 449 type remains unknown, calendar applications SHOULD treat it as 450 type "text/html". 452 Multiple STYLED-DESCRIPTION properties may be used to provide 453 different formats or different language variants. 455 Format Definition: 457 This property is defined by the following notation: 459 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 460 ( 461 ( 462 ";" "VALUE" "=" "URI" 463 ":" uri 464 ) / 465 ( 466 ";" "VALUE" "=" "TEXT" 467 ":" text 468 ) 469 ) 470 CRLF 472 styleddescparam = *( 473 ; 474 ; The following are OPTIONAL, 475 ; but MUST NOT occur more than once. 476 ; 477 (";" altrepparam) / (";" languageparam) / 478 (";" fmttypeparam) / 479 ; 480 ; the following is OPTIONAL 481 ; and MAY occur more than once 482 ; 483 (";" other-param) 484 ) 486 Example: 488 The following is an example of this property. It points to an html 489 description. 491 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 493 6.3. Structured-Location 495 Property name: STRUCTURED-LOCATION 497 Purpose: This property provides a typed reference to external 498 information about the location of an event or optionally a plain 499 text typed value. 501 Value type: There is no default value type for this property. The 502 value type can be set to URI or TEXT. Other text-based value 503 types 505 Property Parameters: IANA, non-standard, label, loctype or format 506 type parameters can be specified on this property. 508 Conformance: This property MAY be specified zero or more times in 509 any iCalendar component. 511 Description: When used in a component the value of this property 512 provides information about the event venue or of related services 513 such as parking, dining, stations etc.. 515 When a LABEL parameter is supplied the language of the label must 516 match that of the content and of the LANGUAGE parameter if 517 present. 519 Format Definition: 521 This property is defined by the following notation: 523 strucloc = "STRUCTURED-LOCATION" struclocparam 524 ( 525 ( 526 ";" "VALUE" "=" "URI" 527 ":" uri 528 ) / 529 ( 530 ";" "VALUE" "=" "TEXT" 531 ":" text 532 ) 533 ) 534 CRLF 536 struclocparam = *( 537 ; 538 ; the following are OPTIONAL 539 ; but MUST NOT occur more than once 540 ; 541 (";" fmttypeparam) / 542 (";" labelparam) / 543 (";" languageparam) / 544 (";" loctypeparam) / 545 ; 546 ; the following is OPTIONAL 547 ; and MAY occur more than once 548 ; 549 (";" other-param) 550 ) 552 Example: 554 The following is an example of this property. It points to a venue. 556 STRUCTURED-LOCATION;LABEL="The venue": 557 http://dir.example.com/venues/big-hall.vcf 559 6.4. Structured-Resource 561 Property name: STRUCTURED-RESOURCE 563 Purpose: This property provides a typed reference to external 564 information about a resource or optionally a plain text typed 565 value. 567 Value type: The default value type for this property is URI. The 568 value type can also be set to TEXT to indicate plain text content. 570 Property Parameters: IANA, non-standard, label, restype or format 571 type parameters can be specified on this property. 573 Conformance: This property MAY be specified zero or more times in 574 any iCalendar component. 576 Description: When used in a component the value of this property 577 provides information about resources used for the event. 579 When a LABEL parameter is supplied the language of the label must 580 match that of the content and of the LANGUAGE parameter if 581 present. 583 Format Definition: 585 This property is defined by the following notation: 587 strucres = "STRUCTURED-RESOURCE" strucresparam (":" uri) / 588 ( 589 ";" "VALUE" "=" "TEXT" 590 ":" text 591 ) 592 CRLF 594 strucresparam = *( 595 ; 596 ; the following are OPTIONAL 597 ; but MUST NOT occur more than once 598 ; 599 (";" fmttypeparam) / 600 (";" labelparam) / 601 (";" languageparam) / 602 (";" restypeparam) / 603 ; 604 ; the following is OPTIONAL 605 ; and MAY occur more than once 606 ; 607 (";" other-param) 608 ) 610 Example: 612 The following is an example of this property. It refers to a 613 projector. 615 STRUCTURED-RESOURCE;restype="projector": 616 http://dir.example.com/projectors/3d.vcf 618 6.5. Source 620 Property name: SOURCE 622 Purpose: This property provides a reference to vcard information 623 about a participant in an event or optionally a plain text typed 624 value. 626 Value type: The default value type for this property is URI. The 627 value type can also be set to TEXT to indicate plain text content. 629 Property Parameters: Non-standard or format type parameters can be 630 specified on this property. 632 Conformance: This property MAY be appear in any iCalendar component. 634 Description: This property provides information about the component 635 in which it appears. It may provide a refernce to a vcard giving 636 directory information about a resource or participant. 638 Format Definition: 640 This property is defined by the following notation: 642 source = "SOURCE" sourceparam 643 ( 644 ( 645 ";" "VALUE" "=" "URI" 646 ":" uri 647 ) / 648 ( 649 ";" "VALUE" "=" "TEXT" 650 ":" text 651 ) 652 ) 653 CRLF 655 sourceparam = *( 656 ; 657 ; the following are OPTIONAL 658 ; but MUST NOT occur more than once 659 ; 660 (";" fmttypeparam) / 661 ; 662 ; the following is OPTIONAL 663 ; and MAY occur more than once 664 ; 665 (";" other-param) 666 ; 667 ) 669 Example: 671 The following is an example referring to a VCARD. 673 SOURCE;FMTTYPE=text/vcard; 674 http://dir.example.com/vcard/contacts/contact1.vcf 676 6.6. Structured-Data 678 Property Name: STRUCTURED-DATA 680 Purpose: This property specifies ancillary data associated with the 681 calendar component. 683 Value Type: TEXT 685 Property Parameters: IANA, non-standard, inline encoding, and value 686 data type property parameters can be specified on this property. 687 The format type and schema parameters can be specified on this 688 property and are RECOMMENDED for text or inline binary encoded 689 content information. 691 Conformance: This property can be specified multiple times in an 692 iCalendar object. Typically it would be used in "VEVENT", 693 "VTODO", or "VJOURNAL" calendar components. 695 Description: This property is used to specify ancillary data in some 696 structured format either directly (inline) as a "TEXT" or "BINARY" 697 value, or as a link via a "URI" value. 699 Rather than define new iCalendar properties for the variety of 700 event types that might occur, it would be better to leverage 701 existing "schemas" for such data. For example, schemas available 702 at https://schema.org include different event types. By using 703 standard schemas, interoperability can be improved between 704 calendar clients and non-calendaring systems that wish to generate 705 or process the data. 707 This property allows the direct inclusion of ancillary data whose 708 schema is defined elsewhere. This property also includes 709 parameters to clearly identify the type of the schema being used 710 so that clients can quickly and easily spot what is relevant 711 within the calendar data and present that to users or process it 712 within the calendaring system. 714 iCalendar does support an "ATTACH" property which can be used to 715 include documents or links to documents within the calendar data. 716 However, that property does not allow data to be included as a 717 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 718 attachments are often treated as "opaque" data to be processed by 719 some other system rather than the calendar client. Thus the 720 existing "ATTACH" property is not sufficient to cover the specific 721 needs of inclusion of schema data. Extending the "ATTACH" 722 property to support a new value type would likely cause 723 interoperability problems. Thus a new property to support 724 inclusion of schema data is warranted. 726 Format Definition: 728 This property is defined by the following notation: 730 sdataprop = "STRUCTURED-DATA" sdataparam 731 (":" text) / 732 ( 733 ";" "ENCODING" "=" "BASE64" 734 ";" "VALUE" "=" "BINARY" 735 ":" binary 736 ) / 737 ( 738 ";" "VALUE" "=" "URI" 739 ":" uri 740 ) 741 CRLF 743 sdataparam = *( 744 ; 745 ; The following is OPTIONAL for a URI value, 746 ; RECOMMENDED for a TEXT or BINARY value, 747 ; and MUST NOT occur more than once. 748 ; 749 (";" fmttypeparam) / 750 (";" schemaparam) / 751 ; 752 ; The following is OPTIONAL, 753 ; and MAY occur more than once. 754 ; 755 (";" other-param) 756 ; 757 ) 759 Example: The following is an example of this property: 761 STRUCTURED-DATA;FMTTYPE=application/ld+json; 762 SCHEMA="https://schema.org/SportsEvent"; 763 VALUE=TEXT:{\n 764 "@context": "http://schema.org"\,\n 765 "@type": "SportsEvent"\,\n 766 "homeTeam": "Pittsburgh Pirates"\,\n 767 "awayTeam": "San Francisco Giants"\n 768 }\n 770 7. New Components 772 7.1. Participant 774 Component name: PARTICIPANT 776 Purpose: This component provides information about a participant in 777 an event or optionally a plain text typed value. 779 Conformance: This component MAY be appear in any iCalendar 780 component. 782 Description: This component provides information about an 783 participant in an event, task or poll. A participant may be an 784 attendee in a scheduling sense and the ATTENDEE property may be 785 specified in addition (See backwards compatability issues). 786 Participants in events can be individuals or organizations, for 787 example a soccer team, the spectators, or the musicians. 789 The SOURCE property if present may refer to an external definition 790 of the participant - such as a vcard. 792 The URI property (def?) if present will provide a mailto: or other 793 address. If a related ATTENDEE proeprty is generated it will have 794 the same value as the URI. 796 Format Definition: 798 This property is defined by the following notation: 800 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 801 partprop *alarmc 802 "END" ":" "PARTICIPANT" CRLF 804 partprop = *( 805 ; 806 ; The following are REQUIRED, 807 ; but MUST NOT occur more than once. 808 ; 809 dtstamp / participanttype / 810 ; 811 ; The following are OPTIONAL, 812 ; but MUST NOT occur more than once. 813 ; 814 created / description / last-mod / seq / 815 source / status / summary / url / 816 ; 817 ; The following are OPTIONAL, 818 ; and MAY occur more than once. 819 ; 820 attach / categories / comment / 821 contact / rstatus / related / 822 resources / x-prop / iana-prop 823 ; 824 ) 826 Note: When the PRIORITY is supplied it defines the ordering of 827 PARTICIPANT components with the same value for the TYPE parameter. 829 Example: 831 The following is an example of this component. It contains a SOURCE 832 property which points to a VCARD providing information about the 833 event participant. 835 BEGIN:PARTICIPANT 836 PARTTYPE:PRINCIPAL_PERFORMER 837 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 838 END:PARTICIPANT 840 Example: 842 The following is an example for the primary contact. 844 BEGIN: PARTICIPANT 845 SOURCE;FMTTYPE=text/vcard; 846 http://dir.example.com/vcard/contacts/contact1.vcf 847 PARTTYPE:PRIMARY-CONTACT 848 DESCRIPTION:A contact: 849 END:PARTICIPANT 851 8. Participant Types 853 This section describes types of participation and provide registered 854 values for the PARTTYPE property. 856 ACTIVE: A participant taking an active role - for example a team 857 member. 859 INACTIVE: A participant taking an inactive part - for example an 860 audience member. 862 SPONSOR: A sponsor of the event. The ORDER parameter may be used 863 with this participant type to define the relative order of 864 multiple sponsors. 866 CONTACT: Contact information for the event. The ORDER parameter may 867 be used with this participant type to define the relative order of 868 multiple contacts. 870 BOOKING-CONTACT: Contact information for reservations or payment 872 EMERGENCY-CONTACT: Contact in case of emergency 874 PUBLICITY-CONTACT: Contact for publicity 876 PLANNER-CONTACT: Contact for the event planner or organizer 878 PERFORMER: A performer - for example the soloist or the accompanist. 879 The ORDER parameter may be used with this participant type to 880 define the relative order of multiple performers. For example, 881 ORDER=1 could define the principal performer or soloist. 883 SPEAKER: Speaker at an event 885 9. Extended examples 887 The following are some examples of the use of the properties defined 888 in this specification. They include additional properties defined in 889 [I-D.ietf-calext-extensions] which includes IMAGE and LIVEFEED. 891 9.1. Example 1 893 The following is an example of a VEVENT describing a concert. It 894 includes location information for the venue itself as well as 895 references to parking and restaurants. 897 BEGIN:VEVENT 898 CREATED:20101116T145739Z 899 DESCRIPTION: Piano Sonata No 3\n 900 Piano Sonata No 30 901 DTSTAMP:20101116T145739Z 902 DTSTART;TZID=America/New_York:20110315T150000Z 903 DTEND;TZID=America/New_York:20110315T163000Z 904 LAST-MODIFIED:20101116T145739Z 905 SUMMARY:Beethoven Piano Sonatas 906 UID:123456 907 STRUCTURED-LOCATION;LABEL="The venue": 908 http://dir.example.com/venues/big-hall.vcf 909 STRUCTURED-LOCATION;LABEL="The venue": 910 http://dir.example.com/venues/parking.vcf 911 BEGIN:PARTICIPANT 912 PARTTYPE:SPONSOR 913 SOURCE:http://example.com/sponsor.vcf 914 END:PARTICIPANT 915 BEGIN:PARTICIPANT 916 PARTTYPE:PERFORMER: 917 SOURCE:http://www.example.com/people/johndoe.vcf 918 END:PARTICIPANT 919 END:VEVENT 921 10. Security Considerations 923 Applications using these properties need to be aware of the risks 924 entailed in using the URIs provided as values. See [RFC3986] for a 925 discussion of the security considerations relating to URIs. 927 Security considerations relating to the "ATTACH" property, as 928 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 929 property. 931 11. Privacy Considerations 933 Properties with a "URI" value type can expose their users to privacy 934 leaks as any network access of the URI data can be tracked. Clients 935 SHOULD NOT automatically download data referenced by the URI without 936 explicit instruction from users. This specification does not 937 introduce any additional privacy concerns beyond those described in 938 [RFC5545]. 940 12. IANA Considerations 942 12.1. Property Registrations 944 This document defines the following new iCalendar properties to be 945 added to the registry defined in Section 8.2.3 of [RFC5545]: 947 +---------------------+---------+----------------------+ 948 | Property | Status | Reference | 949 +---------------------+---------+----------------------+ 950 | PARTTYPE | Current | RFCXXXX, Section 6.1 | 951 | STRUCTURED-DATA | Current | RFCXXXX, Section 6.6 | 952 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 6.2 | 953 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 6.3 | 954 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 6.4 | 955 | SOURCE | Current | RFCXXXX, Section 6.5 | 956 +---------------------+---------+----------------------+ 958 12.2. Parameter Registrations 960 This document defines the following new iCalendar property parameters 961 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 963 +--------------------+---------+----------------------+ 964 | Property Parameter | Status | Reference | 965 +--------------------+---------+----------------------+ 966 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 967 | ORDER | Current | RFCXXXX, Section 5.3 | 968 | RESTYPE | Current | RFCXXXX, Section 5.2 | 969 | SCHEMA | Current | RFCXXXX, Section 5.4 | 970 +--------------------+---------+----------------------+ 972 12.3. Component Registrations 974 This document defines the following new iCalendar components to be 975 added to the registry defined in Section 8.3.1 of [RFC5545]: 977 +-------------+---------+----------------------+ 978 | Component | Status | Reference | 979 +-------------+---------+----------------------+ 980 | PARTICIPANT | Current | RFCXXXX, Section 7.1 | 981 +-------------+---------+----------------------+ 983 12.4. Participant Types Registry 985 The following table has been used to initialize the participant types 986 registry. 988 +-------------------+---------+--------------------+ 989 | Participant Type | Status | Reference | 990 +-------------------+---------+--------------------+ 991 | ACTIVE | Current | RFCXXXX, Section 8 | 992 | INACTIVE | Current | RFCXXXX, Section 8 | 993 | SPONSOR | Current | RFCXXXX, Section 8 | 994 | CONTACT | Current | RFCXXXX, Section 8 | 995 | BOOKING-CONTACT | Current | RFCXXXX, Section 8 | 996 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 8 | 997 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 8 | 998 | PLANNER-CONTACT | Current | RFCXXXX, Section 8 | 999 | PERFORMER | Current | RFCXXXX, Section 8 | 1000 | SPEAKER | Current | RFCXXXX, Section 8 | 1001 +-------------------+---------+--------------------+ 1003 13. Acknowledgements 1005 The author would like to thank Chuck Norris of eventful.com for his 1006 work which led to the development of this RFC. 1008 The author would also like to thank the members of the Calendaring 1009 and Scheduling Consortium Event Publication technical committee and 1010 the following individuals for contributing their ideas and support: 1012 Cyrus Daboo, John Haug, Dan Mendell, Scott Otis, 1014 The authors would also like to thank the Calendaring and Scheduling 1015 Consortium for advice with this specification. 1017 14. Normative References 1019 [I-D.ietf-calext-extensions] 1020 Daboo, C., "New Properties for iCalendar", draft-ietf- 1021 calext-extensions-05 (work in progress), August 2016. 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, 1025 DOI 10.17487/RFC2119, March 1997, 1026 . 1028 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1029 IANA Considerations Section in RFCs", RFC 2434, 1030 DOI 10.17487/RFC2434, October 1998, 1031 . 1033 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1034 DOI 10.17487/RFC3688, January 2004, 1035 . 1037 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1038 Resource Identifier (URI): Generic Syntax", STD 66, 1039 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1040 . 1042 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1043 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1044 . 1046 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1047 Scheduling Core Object Specification (iCalendar)", 1048 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1049 . 1051 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1052 Interoperability Protocol (iTIP)", RFC 5546, 1053 DOI 10.17487/RFC5546, December 2009, 1054 . 1056 [W3C.REC-xml-20060816] 1057 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1058 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1059 Edition)", World Wide Web Consortium Recommendation REC- 1060 xml-20060816, August 2006, 1061 . 1063 Appendix A. Open issues 1065 restype values: Need to determine what if any registry of resource 1066 types already exists and use that. 1068 Appendix B. Change log 1070 v05 2017-02-18 MD 1072 o Change ASSOCIATE back to PARTICIPANT 1074 o PARTICIPANT becomes a component rather than a property. Turn many 1075 of the former parameters into properties. 1077 v05 2016-08-?? MD 1079 o Name changed - taken up by calext working group 1081 v05 2016-06-26 MD 1083 o Fix up abnf 1085 o change ref to ietf from daboo 1087 o take out label spec - use Cyrus spec 1089 v05 2016-06-14 MD 1091 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1093 o Change ORDER to integer >= 1. 1095 o Incorporate Structured-Data into this specification. 1097 v04 2014-02-01 MD 1099 o Added updates attribute. 1101 o Minor typos. 1103 o Resubmitted mostly to refresh the draft. 1105 v03 2013-03-06 MD 1107 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1109 o Added section showing modifications to components. 1111 o Replace ID with GROUP and modify HASH. 1113 o Replace TITLE param with LABEL. 1115 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1117 v02 2012-11-02 MD 1119 o Collapse sections with description of properties and the use cases 1120 into a section with sub-sections. 1122 o New section to describe relating properties. 1124 o Remove idref and upgrade hash to have the reference 1125 o No default value types on properties.. 1127 v01 2012-10-18 MD Many changes. 1129 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1131 o Add a STRUCTURED-RESOURCE property 1133 o STYLED-DESCRIPTION to handle rich text 1135 o Much more... 1137 2011-01-07 1139 o Remove MEDIA - it's going in the Cyrus RFC 1141 o Rename EXTENDED-... to STRUCTURED-... 1143 o Add TYPE parameter to SPONSOR 1145 v00 2007-10-19 MD Initial version 1147 Author's Address 1149 Michael Douglass 1150 Spherical Cow Group 1151 226 3rd Street 1152 Troy, NY 12180 1153 USA 1155 Email: mdouglass@sphericalcowgroup.com 1156 URI: http://sphericalcowgroup.com