idnits 2.17.1 draft-ietf-calext-eventpub-extensions-02.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 (April 21, 2017) is 2555 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 1079, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 1084, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 3 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) April 21, 2017 5 Intended status: Standards Track 6 Expires: October 23, 2017 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-02 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 October 23, 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 components 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. 113 The following properties and components are defined in this 114 specification 116 Styled-Description: Supports HTML descriptions. Event publishers 117 typically wish to provide more and better formatted information 118 about the event. 120 Structured-Location: There may be a number of locations associated 121 with an event. This provides detailed information about the 122 location. 124 Structured-Resource: Events need resources such as rooms, 125 projectors, conferencing capabilities. 127 Structured-Data: The existing properties in iCalendar cover key 128 elements of events and tasks such as start time, end time, 129 location, summary, etc. However, different types of events often 130 have other specific "fields" that it is useful to include in the 131 calendar data. For example, an event representing an airline 132 flight could include the airline, flight number, departure and 133 arrival airport codes, check-in and gate-closing times etc. As 134 another example, a sporting event might contain information about 135 the type of sport, the home and away teams, the league the teams 136 are in, information about nearby parking, etc. 138 Participant: Many people or groups may participate in an event. 139 This component provides detailed information. Such participants 140 may act as attendees to the event (or derived events) or may just 141 provide a reference - perhaps for mailing lists. 143 1.1. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119]. 150 2. Components and properties 152 Previous extensions to the calendaring standards have been largely 153 restricted to the addition of properties or parameters. This is 154 partly because iCalendar libraries had trouble handling components 155 nested deeper than those defined in [RFC5545] 157 In a break with this 'tradition' this specification introduces some 158 of these extensions as components rather than properties. This is a 159 better match for the way XML and JSON handles such structures and 160 allows richer definitions. 162 It also allows for the addition of extra properties inside the 163 component and resolves some of the problems of trying to add detailed 164 information as a parameter. 166 3. Typed References 168 The properties defined here can all reference external meta-data 169 which may be used by applications to provide enhanced value to users. 170 By providing type information as parameters, clients and servers are 171 able to discover interesting references and make use of them, perhaps 172 for indexing or the presentation of additional related information 173 for the user. 175 These properties are designed to handle common use cases in event 176 publication. It is generally important to provide information about 177 the organizers of such events. Sponsors wish to be referenced in a 178 prominent manner. In social calendaring it is often important to 179 identify the active participants in the event, for example a school 180 sports team, and the inactive participants, for example the parents. 182 The [RFC5545] LOCATION property provides only an unstructured single 183 text value for specifying the location where an event (or task) will 184 occur. This is inadequate for use cases where structured location 185 information (e.g. address, region, country, postal code) is required 186 or preferred, and limits widespread adoption of iCalendar in those 187 settings. 189 Using STRUCTURED-LOCATION, information about a number of interesting 190 locations can be communicated, for example, parking, restaurants and 191 the venue. Servers and clients can retrieve the objects when storing 192 the event and use them to index by geographic location. 194 When a calendar client receives a calendar component it can search 195 the set of supplied properties looking for those of particular 196 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 197 to help the selection. 199 3.1. Use Cases 201 The main motivation for these properties has been event publication 202 but there are opportunities for use elsewhere. The following use 203 cases will describe some possible scenarios. 205 3.1.1. Piano Concert Performance 207 In putting together a concert there are many participants: piano 208 tuner, performer, stage hands etc. In addition there are sponsors 209 and various contacts to be provided. There will also be a number of 210 related locations. A number of events can be created, all of which 211 relate to the performance in different ways. 213 There may be an iTip [RFC5545] meeting request for the piano tuner 214 who will arrive before the performance. Other members of staff may 215 also receive meeting requests. 217 An event can also be created for publication which will have a 218 PARTICIPANT component for the pianist providing a reference to vcard 219 information about the performer. This event would also hold 220 information about parking, local subway stations and the venue 221 itself. In addition, there will be sponsorship information for 222 sponsors of the event and perhaps paid sponsorship properties 223 essentially advertising local establishments. 225 3.1.2. Itineraries 227 These additions also provide opportunities for the travel industry. 228 When booking a flight the PARTICIPANT component can be used to 229 provide references to businesses at the airports and to car hire 230 businesses at the destination. 232 The embedded location information can guide the traveller at the 233 airport or to their final destination. The contact information can 234 provide detailed information about the booking agent, the airlines 235 and car hire companies and the hotel. 237 4. Modifications to Calendar Components 239 The following changes to the syntax defined in iCalendar [RFC5545] 240 are made here. New elements are defined in subsequent sections. 242 eventc = "BEGIN" ":" "VEVENT" CRLF 243 eventprop *alarmc *participantc 244 "END" ":" "VEVENT" CRLF 246 eventprop =/ *( 247 ; 248 ; The following are OPTIONAL, 249 ; and MAY occur more than once. 250 ; 251 styleddescription / strucloc / strucres / sdataprop 252 ; 253 ) 255 todoc = "BEGIN" ":" "VTODO" CRLF 256 todoprop *alarmc *participantc 257 "END" ":" "VTODO" CRLF 259 todoprop =/ *( 260 ; 261 ; The following are OPTIONAL, 262 ; and MAY occur more than once. 263 ; 264 styleddescription / strucloc / strucres / sdataprop 265 ; 266 ) 268 journalc = "BEGIN" ":" "VJOURNAL" CRLF 269 jourprop *participantc 270 "END" ":" "VJOURNAL" CRLF 272 jourprop =/ *( 273 ; 274 ; The following are OPTIONAL, 275 ; and MAY occur more than once. 276 ; 277 styleddescription / sdataprop 278 ; 279 ) 281 5. New Property Parameters 283 This specification makes use of the LABEL property parameter which is 284 defined in [I-D.ietf-calext-extensions] 286 5.1. Loctype 288 Parameter name: LOCTYPE 290 Purpose: To specify the type of location. 292 Format Definition: 294 This parameter is defined by the following notation: 296 loctypeparam = "LOCTYPE" "=" param-value 298 Description: This parameter MAY be specified on STRUCTURED-LOCATION 299 and provides a way to differentiate multiple properties. For 300 example, it allows event producers to provide location information 301 for the venue and the parking. 303 Values for this parameter are taken from the values defined in 304 [RFC4589]. New location types SHOULD be registered in the manner 305 laid down in that specification 307 5.2. Restype 309 Parameter name: RESTYPE 311 Purpose: To specify the type of resource. 313 Format Definition: 315 This parameter is defined by the following notation: 317 restypeparam = "RESTYPE" "=" param-value 319 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 320 and provides a way to differentiate multiple properties. 322 Values for this parameter are taken from the values defined in 323 [todo]. New resource types SHOULD be registered in the manner 324 laid down in that specification 326 5.3. Order 328 Parameter name: ORDER 330 Purpose: To define ordering for the associated property. 332 Format Definition: 334 This parameter is defined by the following notation: 336 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 338 Description: The ORDER parameter is OPTIONAL and is used to indicate 339 the relative ordering of the corresponding instance of a property. 340 Its value MUST be an integer greater than or equal to 1 that 341 quantifies the order. Lower values correspond to a higher level 342 of ordering, with 1 being the highest. 344 When the parameter is absent, the default MUST be to interpret the 345 property instance as being at the lowest level of ordering. 347 Note that the value of this parameter is to be interpreted only in 348 relation to values assigned to other corresponding instances of 349 the same property in the same entity. A given value, or the 350 absence of a value, MUST NOT be interpreted on its own. 352 This parameter MAY be applied to any property that allows multiple 353 instances. 355 5.4. Schema 357 Parameter Name: SCHEMA 359 Purpose: To specify the schema used for the content of a 360 "STRUCTURED-DATA" property value. 362 Format Definition: 364 This parameter is defined by the following notation: 366 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 368 Description: This property parameter SHOULD be specified on 369 "STRUCTURED-DATA" properties. When present it provides 370 identifying information about the nature of the content of the 371 corresponding "STRUCTURED-DATA" property value. This can be used 372 to supplement the media type information provided by the "FMTTYPE" 373 parameter on the corresponding property. 375 Example: 377 STRUCTURED-DATA;FMTTYPE=application/ld+json; 378 SCHEMA="https://schema.org/FlightReservation"; 379 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 381 6. New Properties 383 6.1. Participant Type 385 Property name: PARTTYPE 387 Purpose: To specify the type of participant. 389 Value type: The value type for this property is TEXT. The allowable 390 values are defined in Section 8. 392 Property Parameters: Non-standard parameters can be specified on 393 this property. 395 Conformance: This property MUST be specified within a PARTICIPANT 396 component. 398 Description: This property defines the type of participation in 399 events or tasks. Participants can be individuals or 400 organizations, for example a soccer team, the spectators, or the 401 musicians. 403 Format Definition: 405 This parameter is defined by the following notation: 407 participanttype = "PARTICIPANT-TYPE" "=" iana-token 409 6.2. Schedule Address 411 Property name: SCHEDULE-ADDRESS 413 Purpose: To specify the calendar address for a participant. 415 Value type: CAL-ADDRESS 417 Property Parameters: IANA or non-standard property parameters can be 418 specified on this property. 420 Conformance: This property MAY be specified within a PARTICIPANT 421 component. 423 Description: This property provides a calendar user address for the 424 participant. If there is an ATTENDEE property with the same value 425 then the participant is schedulable. 427 Format Definition: 429 This parameter is defined by the following notation: 431 scheduleaddress = "SCHEDULE-ADDRESS" "=" iana-token 433 6.3. Styled-Description 435 Property name: STYLED-DESCRIPTION 437 Purpose: This property provides for one or more rich-text 438 descriptions to replace or augment that provided by the 439 DESCRIPTION property. 441 Value type: There is no default value type for this property. The 442 value type can be set to URI or TEXT. Other text-based value 443 types can be used when defined in the future. Clients MUST ignore 444 any properties with value types they do not understand. 446 Property Parameters: IANA, non-standard, id, alternate text 447 representation, and language property parameters can be specified 448 on this property. 450 Conformance: The property can be specified multiple times in the 451 "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. 453 Description: This property is used in the "VEVENT" and "VTODO" to 454 capture lengthy textual descriptions associated with the activity. 455 This property is used in the "VJOURNAL" calendar component to 456 capture one or more textual journal entries. This property is 457 used in the "VALARM" calendar component to capture the display 458 text for a DISPLAY category of alarm, and to capture the body text 459 for an EMAIL category of alarm. 461 VALUE=TEXT is used to provide rich-text variants of the plain-text 462 DESCRIPTION property. 464 VALUE=URI is used to provide a link to rich-text content which is 465 expected to be displayed inline as part of the event. 467 The intent of this property is limited to providing a styled and/ 468 or language specific version of the DESCRIPTION property. The URL 469 property should be used to link to websites or other related 470 information. 472 Applications MAY attempt to guess the media type of the resource 473 via inspection of its content if and only if the media type of the 474 resource is not given by the "FMTTYPE" parameter. If the media 475 type remains unknown, calendar applications SHOULD treat it as 476 type "text/html". 478 Multiple STYLED-DESCRIPTION properties may be used to provide 479 different formats or different language variants. 481 Format Definition: 483 This property is defined by the following notation: 485 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 486 ( 487 ( 488 ";" "VALUE" "=" "URI" 489 ":" uri 490 ) / 491 ( 492 ";" "VALUE" "=" "TEXT" 493 ":" text 494 ) 495 ) 496 CRLF 498 styleddescparam = *( 499 ; 500 ; The following are OPTIONAL, 501 ; but MUST NOT occur more than once. 502 ; 503 (";" altrepparam) / (";" languageparam) / 504 (";" fmttypeparam) / 505 ; 506 ; the following is OPTIONAL 507 ; and MAY occur more than once 508 ; 509 (";" other-param) 510 ) 512 Example: 514 The following is an example of this property. It points to an html 515 description. 517 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 519 6.4. Structured-Location 521 Property name: STRUCTURED-LOCATION 523 Purpose: This property provides a typed reference to external 524 information about the location of an event or optionally a plain 525 text typed value. 527 Value type: There is no default value type for this property. The 528 value type can be set to URI or TEXT. Other text-based value 529 types 531 Property Parameters: IANA, non-standard, label, loctype or format 532 type parameters can be specified on this property. 534 Conformance: This property MAY be specified zero or more times in 535 any iCalendar component. 537 Description: When used in a component the value of this property 538 provides information about the event venue or of related services 539 such as parking, dining, stations etc.. 541 When a LABEL parameter is supplied the language of the label must 542 match that of the content and of the LANGUAGE parameter if 543 present. 545 Format Definition: 547 This property is defined by the following notation: 549 strucloc = "STRUCTURED-LOCATION" struclocparam 550 ( 551 ( 552 ";" "VALUE" "=" "URI" 553 ":" uri 554 ) / 555 ( 556 ";" "VALUE" "=" "TEXT" 557 ":" text 558 ) 559 ) 560 CRLF 562 struclocparam = *( 563 ; 564 ; the following are OPTIONAL 565 ; but MUST NOT occur more than once 566 ; 567 (";" fmttypeparam) / 568 (";" labelparam) / 569 (";" languageparam) / 570 (";" loctypeparam) / 571 ; 572 ; the following is OPTIONAL 573 ; and MAY occur more than once 574 ; 575 (";" other-param) 576 ) 578 Example: 580 The following is an example of this property. It points to a venue. 582 STRUCTURED-LOCATION;LABEL="The venue": 583 http://dir.example.com/venues/big-hall.vcf 585 6.5. Structured-Resource 587 Property name: STRUCTURED-RESOURCE 589 Purpose: This property provides a typed reference to external 590 information about a resource or optionally a plain text typed 591 value. 593 Value type: The default value type for this property is URI. The 594 value type can also be set to TEXT to indicate plain text content. 596 Property Parameters: IANA, non-standard, label, restype or format 597 type parameters can be specified on this property. 599 Conformance: This property MAY be specified zero or more times in 600 any iCalendar component. 602 Description: When used in a component the value of this property 603 provides information about resources used for the event. 605 When a LABEL parameter is supplied the language of the label must 606 match that of the content and of the LANGUAGE parameter if 607 present. 609 Format Definition: 611 This property is defined by the following notation: 613 strucres = "STRUCTURED-RESOURCE" strucresparam (":" uri) / 614 ( 615 ";" "VALUE" "=" "TEXT" 616 ":" text 617 ) 618 CRLF 620 strucresparam = *( 621 ; 622 ; the following are OPTIONAL 623 ; but MUST NOT occur more than once 624 ; 625 (";" fmttypeparam) / 626 (";" labelparam) / 627 (";" languageparam) / 628 (";" restypeparam) / 629 ; 630 ; the following is OPTIONAL 631 ; and MAY occur more than once 632 ; 633 (";" other-param) 634 ) 636 Example: 638 The following is an example of this property. It refers to a 639 projector. 641 STRUCTURED-RESOURCE;restype="projector": 642 http://dir.example.com/projectors/3d.vcf 644 6.6. Source 646 Property name: SOURCE 648 Purpose: This property provides a reference to vcard information 649 about a participant in an event or optionally a plain text typed 650 value. 652 Value type: The default value type for this property is URI. The 653 value type can also be set to TEXT to indicate plain text content. 655 Property Parameters: Non-standard or format type parameters can be 656 specified on this property. 658 Conformance: This property MAY be appear in any iCalendar component. 660 Description: This property provides information about the component 661 in which it appears. It may provide a refernce to a vcard giving 662 directory information about a resource or participant. 664 Format Definition: 666 This property is defined by the following notation: 668 source = "SOURCE" sourceparam 669 ( 670 ( 671 ";" "VALUE" "=" "URI" 672 ":" uri 673 ) / 674 ( 675 ";" "VALUE" "=" "TEXT" 676 ":" text 677 ) 678 ) 679 CRLF 681 sourceparam = *( 682 ; 683 ; the following are OPTIONAL 684 ; but MUST NOT occur more than once 685 ; 686 (";" fmttypeparam) / 687 ; 688 ; the following is OPTIONAL 689 ; and MAY occur more than once 690 ; 691 (";" other-param) 692 ; 693 ) 695 Example: 697 The following is an example referring to a VCARD. 699 SOURCE;FMTTYPE=text/vcard; 700 http://dir.example.com/vcard/contacts/contact1.vcf 702 6.7. Structured-Data 704 Property Name: STRUCTURED-DATA 706 Purpose: This property specifies ancillary data associated with the 707 calendar component. 709 Value Type: TEXT 711 Property Parameters: IANA, non-standard, inline encoding, and value 712 data type property parameters can be specified on this property. 713 The format type and schema parameters can be specified on this 714 property and are RECOMMENDED for text or inline binary encoded 715 content information. 717 Conformance: This property can be specified multiple times in an 718 iCalendar object. Typically it would be used in "VEVENT", 719 "VTODO", or "VJOURNAL" calendar components. 721 Description: This property is used to specify ancillary data in some 722 structured format either directly (inline) as a "TEXT" or "BINARY" 723 value, or as a link via a "URI" value. 725 Rather than define new iCalendar properties for the variety of 726 event types that might occur, it would be better to leverage 727 existing "schemas" for such data. For example, schemas available 728 at https://schema.org include different event types. By using 729 standard schemas, interoperability can be improved between 730 calendar clients and non-calendaring systems that wish to generate 731 or process the data. 733 This property allows the direct inclusion of ancillary data whose 734 schema is defined elsewhere. This property also includes 735 parameters to clearly identify the type of the schema being used 736 so that clients can quickly and easily spot what is relevant 737 within the calendar data and present that to users or process it 738 within the calendaring system. 740 iCalendar does support an "ATTACH" property which can be used to 741 include documents or links to documents within the calendar data. 742 However, that property does not allow data to be included as a 743 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 744 attachments are often treated as "opaque" data to be processed by 745 some other system rather than the calendar client. Thus the 746 existing "ATTACH" property is not sufficient to cover the specific 747 needs of inclusion of schema data. Extending the "ATTACH" 748 property to support a new value type would likely cause 749 interoperability problems. Thus a new property to support 750 inclusion of schema data is warranted. 752 Format Definition: 754 This property is defined by the following notation: 756 sdataprop = "STRUCTURED-DATA" sdataparam 757 (":" text) / 758 ( 759 ";" "ENCODING" "=" "BASE64" 760 ";" "VALUE" "=" "BINARY" 761 ":" binary 762 ) / 763 ( 764 ";" "VALUE" "=" "URI" 765 ":" uri 766 ) 767 CRLF 769 sdataparam = *( 770 ; 771 ; The following is OPTIONAL for a URI value, 772 ; RECOMMENDED for a TEXT or BINARY value, 773 ; and MUST NOT occur more than once. 774 ; 775 (";" fmttypeparam) / 776 (";" schemaparam) / 777 ; 778 ; The following is OPTIONAL, 779 ; and MAY occur more than once. 780 ; 781 (";" other-param) 782 ; 783 ) 785 Example: The following is an example of this property: 787 STRUCTURED-DATA;FMTTYPE=application/ld+json; 788 SCHEMA="https://schema.org/SportsEvent"; 789 VALUE=TEXT:{\n 790 "@context": "http://schema.org"\,\n 791 "@type": "SportsEvent"\,\n 792 "homeTeam": "Pittsburgh Pirates"\,\n 793 "awayTeam": "San Francisco Giants"\n 794 }\n 796 7. New Components 797 7.1. Participant 799 Component name: PARTICIPANT 801 Purpose: This component provides information about a participant in 802 an event or optionally a plain text typed value. 804 Conformance: This component MAY be appear in any iCalendar 805 component. 807 Description: This component provides information about an 808 participant in an event, task or poll. A participant may be an 809 attendee in a scheduling sense and the ATTENDEE property may be 810 specified in addition. Participants in events can be individuals 811 or organizations, for example a soccer team, the spectators, or 812 the musicians. 814 The SOURCE property if present may refer to an external definition 815 of the participant - such as a vcard. 817 The STRUCTURED-ADDRESS property if present will provide a cal- 818 address. If an ATTENDEE property has the same value the 819 participant is considered schedulable. The PARTICIPANT component 820 can be used to contain additional meta-data related to the 821 attendee. 823 Format Definition: 825 This property is defined by the following notation: 827 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 828 partprop *alarmc 829 "END" ":" "PARTICIPANT" CRLF 831 partprop = *( 832 ; 833 ; The following are REQUIRED, 834 ; but MUST NOT occur more than once. 835 ; 836 dtstamp / participanttype / 837 ; 838 ; The following are OPTIONAL, 839 ; but MUST NOT occur more than once. 840 ; 841 created / description / last-mod / seq / 842 source / status / structuredaddress / summary / url / 843 ; 844 ; The following are OPTIONAL, 845 ; and MAY occur more than once. 846 ; 847 attach / categories / comment / 848 contact / rstatus / related / 849 resources / x-prop / iana-prop 850 ; 851 ) 853 Note: When the PRIORITY is supplied it defines the ordering of 854 PARTICIPANT components with the same value for the TYPE parameter. 856 Example: 858 The following is an example of this component. It contains a SOURCE 859 property which points to a VCARD providing information about the 860 event participant. 862 BEGIN:PARTICIPANT 863 PARTTYPE:PRINCIPAL_PERFORMER 864 SOURCE:http://dir.example.com/vcard/aviolinist.vcf 865 END:PARTICIPANT 867 Example: 869 The following is an example for the primary contact. 871 BEGIN: PARTICIPANT 872 SOURCE;FMTTYPE=text/vcard; 873 http://dir.example.com/vcard/contacts/contact1.vcf 874 PARTTYPE:PRIMARY-CONTACT 875 DESCRIPTION:A contact: 876 END:PARTICIPANT 878 7.2. Schedulable Participant 880 A PARTICIPANT component may represent someone or something that needs 881 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 882 The PARTICIPANT component may also represent someone or something 883 that is NOT to receive scheduling messages. 885 A PARTICIPANT component is defined to be schedulable if 887 o It contains a SCHEDULE-ADDRESS property 889 o That property value is the same as the value for an ATTENDEE 890 property. 892 If both of these conditions apply then the participant defined by the 893 value of the URL property will take part in scheduling operations as 894 defined in [RFC5546]. 896 An appropriate use for the PARTICIPANT component in scheduling would 897 be to store SEQUENCE and DTSTAMP properties associated with replies 898 from each ATTENDEE. A LOCATION property within the PARTICIPANT 899 component might allow better selection of meeting times when 900 particpants are in different timezones. 902 8. Participant Types 904 This section describes types of participation and provide registered 905 values for the PARTTYPE property. 907 ACTIVE: A participant taking an active role - for example a team 908 member. 910 INACTIVE: A participant taking an inactive part - for example an 911 audience member. 913 SPONSOR: A sponsor of the event. The ORDER parameter may be used 914 with this participant type to define the relative order of 915 multiple sponsors. 917 CONTACT: Contact information for the event. The ORDER parameter may 918 be used with this participant type to define the relative order of 919 multiple contacts. 921 BOOKING-CONTACT: Contact information for reservations or payment 923 EMERGENCY-CONTACT: Contact in case of emergency 925 PUBLICITY-CONTACT: Contact for publicity 927 PLANNER-CONTACT: Contact for the event planner or organizer 929 PERFORMER: A performer - for example the soloist or the accompanist. 930 The ORDER parameter may be used with this participant type to 931 define the relative order of multiple performers. For example, 932 ORDER=1 could define the principal performer or soloist. 934 SPEAKER: Speaker at an event 936 9. Extended examples 938 The following are some examples of the use of the properties defined 939 in this specification. They include additional properties defined in 940 [I-D.ietf-calext-extensions] which includes IMAGE and LIVEFEED. 942 9.1. Example 1 943 The following is an example of a VEVENT describing a concert. It 944 includes location information for the venue itself as well as 945 references to parking and restaurants. 947 BEGIN:VEVENT 948 CREATED:20101116T145739Z 949 DESCRIPTION: Piano Sonata No 3\n 950 Piano Sonata No 30 951 DTSTAMP:20101116T145739Z 952 DTSTART;TZID=America/New_York:20110315T150000Z 953 DTEND;TZID=America/New_York:20110315T163000Z 954 LAST-MODIFIED:20101116T145739Z 955 SUMMARY:Beethoven Piano Sonatas 956 UID:123456 957 STRUCTURED-LOCATION;LABEL="The venue": 958 http://dir.example.com/venues/big-hall.vcf 959 STRUCTURED-LOCATION;LABEL="The venue": 960 http://dir.example.com/venues/parking.vcf 961 BEGIN:PARTICIPANT 962 PARTTYPE:SPONSOR 963 SOURCE:http://example.com/sponsor.vcf 964 END:PARTICIPANT 965 BEGIN:PARTICIPANT 966 PARTTYPE:PERFORMER: 967 SOURCE:http://www.example.com/people/johndoe.vcf 968 END:PARTICIPANT 969 END:VEVENT 971 10. Security Considerations 973 Applications using these properties need to be aware of the risks 974 entailed in using the URIs provided as values. See [RFC3986] for a 975 discussion of the security considerations relating to URIs. 977 Security considerations relating to the "ATTACH" property, as 978 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 979 property. 981 11. Privacy Considerations 983 Properties with a "URI" value type can expose their users to privacy 984 leaks as any network access of the URI data can be tracked. Clients 985 SHOULD NOT automatically download data referenced by the URI without 986 explicit instruction from users. This specification does not 987 introduce any additional privacy concerns beyond those described in 988 [RFC5545]. 990 12. IANA Considerations 992 12.1. Property Registrations 994 This document defines the following new iCalendar properties to be 995 added to the registry defined in Section 8.2.3 of [RFC5545]: 997 +---------------------+---------+----------------------+ 998 | Property | Status | Reference | 999 +---------------------+---------+----------------------+ 1000 | PARTTYPE | Current | RFCXXXX, Section 6.1 | 1001 | SCHEDULE-ADDRESS | Current | RFCXXXX, Section 6.2 | 1002 | STRUCTURED-DATA | Current | RFCXXXX, Section 6.7 | 1003 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 6.3 | 1004 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 6.4 | 1005 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 6.5 | 1006 | SOURCE | Current | RFCXXXX, Section 6.6 | 1007 +---------------------+---------+----------------------+ 1009 12.2. Parameter Registrations 1011 This document defines the following new iCalendar property parameters 1012 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1014 +--------------------+---------+----------------------+ 1015 | Property Parameter | Status | Reference | 1016 +--------------------+---------+----------------------+ 1017 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1018 | ORDER | Current | RFCXXXX, Section 5.3 | 1019 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1020 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1021 +--------------------+---------+----------------------+ 1023 12.3. Component Registrations 1025 This document defines the following new iCalendar components to be 1026 added to the registry defined in Section 8.3.1 of [RFC5545]: 1028 +-------------+---------+----------------------+ 1029 | Component | Status | Reference | 1030 +-------------+---------+----------------------+ 1031 | PARTICIPANT | Current | RFCXXXX, Section 7.1 | 1032 +-------------+---------+----------------------+ 1034 12.4. Participant Types Registry 1036 The following table has been used to initialize the participant types 1037 registry. 1039 +-------------------+---------+--------------------+ 1040 | Participant Type | Status | Reference | 1041 +-------------------+---------+--------------------+ 1042 | ACTIVE | Current | RFCXXXX, Section 8 | 1043 | INACTIVE | Current | RFCXXXX, Section 8 | 1044 | SPONSOR | Current | RFCXXXX, Section 8 | 1045 | CONTACT | Current | RFCXXXX, Section 8 | 1046 | BOOKING-CONTACT | Current | RFCXXXX, Section 8 | 1047 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 8 | 1048 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 8 | 1049 | PLANNER-CONTACT | Current | RFCXXXX, Section 8 | 1050 | PERFORMER | Current | RFCXXXX, Section 8 | 1051 | SPEAKER | Current | RFCXXXX, Section 8 | 1052 +-------------------+---------+--------------------+ 1054 13. Acknowledgements 1056 The author would like to thank Chuck Norris of eventful.com for his 1057 work which led to the development of this RFC. 1059 The author would also like to thank the members of the Calendaring 1060 and Scheduling Consortium Event Publication technical committee and 1061 the following individuals for contributing their ideas and support: 1063 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, 1065 The authors would also like to thank the Calendaring and Scheduling 1066 Consortium for advice with this specification. 1068 14. Normative References 1070 [I-D.ietf-calext-extensions] 1071 Daboo, C., "New Properties for iCalendar", draft-ietf- 1072 calext-extensions-05 (work in progress), August 2016. 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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1080 IANA Considerations Section in RFCs", RFC 2434, 1081 DOI 10.17487/RFC2434, October 1998, 1082 . 1084 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1085 DOI 10.17487/RFC3688, January 2004, 1086 . 1088 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1089 Resource Identifier (URI): Generic Syntax", STD 66, 1090 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1091 . 1093 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1094 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1095 . 1097 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1098 Scheduling Core Object Specification (iCalendar)", 1099 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1100 . 1102 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1103 Interoperability Protocol (iTIP)", RFC 5546, 1104 DOI 10.17487/RFC5546, December 2009, 1105 . 1107 [W3C.REC-xml-20060816] 1108 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1109 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1110 Edition)", World Wide Web Consortium Recommendation REC- 1111 xml-20060816, August 2006, 1112 . 1114 Appendix A. Open issues 1116 restype values: Need to determine what if any registry of resource 1117 types already exists and use that. 1119 Appendix B. Change log 1121 calext-v02 2017-04-20 MD 1123 o Add SCHEDULE-ADDRESS property 1125 o PARTICIPANT becomes a component rather than a property. Turn many 1126 of the former parameters into properties. 1128 o Use existing ATTENDEE property for scheduling. 1130 calext-v01 2017-02-18 MD 1132 o Change ASSOCIATE back to PARTICIPANT 1134 o PARTICIPANT becomes a component rather than a property. Turn many 1135 of the former parameters into properties. 1137 calext-v00 2016-08-?? MD 1139 o Name changed - taken up by calext working group 1141 v06 2016-06-26 MD 1143 o Fix up abnf 1145 o change ref to ietf from daboo 1147 o take out label spec - use Cyrus spec 1149 v05 2016-06-14 MD 1151 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1153 o Change ORDER to integer >= 1. 1155 o Incorporate Structured-Data into this specification. 1157 v04 2014-02-01 MD 1159 o Added updates attribute. 1161 o Minor typos. 1163 o Resubmitted mostly to refresh the draft. 1165 v03 2013-03-06 MD 1167 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1169 o Added section showing modifications to components. 1171 o Replace ID with GROUP and modify HASH. 1173 o Replace TITLE param with LABEL. 1175 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1177 v02 2012-11-02 MD 1179 o Collapse sections with description of properties and the use cases 1180 into a section with sub-sections. 1182 o New section to describe relating properties. 1184 o Remove idref and upgrade hash to have the reference 1186 o No default value types on properties.. 1188 v01 2012-10-18 MD Many changes. 1190 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1192 o Add a STRUCTURED-RESOURCE property 1194 o STYLED-DESCRIPTION to handle rich text 1196 o Much more... 1198 2011-01-07 1200 o Remove MEDIA - it's going in the Cyrus RFC 1202 o Rename EXTENDED-... to STRUCTURED-... 1204 o Add TYPE parameter to SPONSOR 1206 v00 2007-10-19 MD Initial version 1208 Author's Address 1210 Michael Douglass 1211 Spherical Cow Group 1212 226 3rd Street 1213 Troy, NY 12180 1214 USA 1216 Email: mdouglass@sphericalcowgroup.com 1217 URI: http://sphericalcowgroup.com