idnits 2.17.1 draft-douglass-calendar-extension-06.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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- 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 (June 27, 2016) is 2850 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 899, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 904, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-calext-extensions-03 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 5 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) June 27, 2016 5 Intended status: Standards Track 6 Expires: December 29, 2016 8 Event Publishing Extensions to iCalendar 9 draft-douglass-calendar-extension-06 11 Abstract 13 This specification introduces a number of new iCalendar properties 14 which are of particular use for event publishers and in social 15 networking. 17 This specification also defines a new STRUCTURED-DATA property for 18 iCalendar (RFC 5545) 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 December 29, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 57 2. Typed References . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 60 2.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5 61 3. Modifications to Calendar Components . . . . . . . . . . . . 5 62 4. New Property Parameters . . . . . . . . . . . . . . . . . . . 6 63 4.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Assoctype . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.4. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Associate . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Styled-Description . . . . . . . . . . . . . . . . . . . 11 71 5.3. Structured-Location . . . . . . . . . . . . . . . . . . . 13 72 5.4. Structured-Resource . . . . . . . . . . . . . . . . . . . 14 73 5.5. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16 74 6. Associate Types . . . . . . . . . . . . . . . . . . . . . . . 17 75 7. Extended examples . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 18 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 10.1. Property Registrations . . . . . . . . . . . . . . . . . 20 81 10.2. Parameter Registrations . . . . . . . . . . . . . . . . 20 82 10.3. Associate Type Registrations . . . . . . . . . . . . . . 20 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 84 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 85 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 22 86 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 22 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 The currently existing iCalendar standard [RFC5545] lacks useful 92 methods for referencing additional, external information relating to 93 calendar components. 95 This document defines a number of properties referencing such 96 external information that can provide additional information about an 97 iCalendar component. The intent is to allow interchange of such 98 information between applications or systems (e.g., between clients, 99 between client and server, and between servers). Formats such as 100 VCARD are likely to be most useful. 102 A new property is also defined to support HTML descriptions. Event 103 publishers typically wish to provide more and better formatted 104 information about the event. 106 Additionally this specification defines a property to allow the 107 inclusion of structured data within the iCalendar object itself. The 108 existing properties in iCalendar cover key elements of events and 109 tasks such as start time, end time, location, summary, etc. However, 110 different types of events often have other specific "fields" that it 111 is useful to include in the calendar data. For example, an event 112 representing an airline flight could include the airline, flight 113 number, departure and arrival airport codes, check-in and gate- 114 closing times etc. As another example, a sporting event might 115 contain information about the type of sport, the home and away teams, 116 the league the teams are in, information about nearby parking, etc. 118 Rather than define new iCalendar properties for the variety of event 119 types that might occur, it would be better to leverage existing 120 "schemas" for such data. For example, schemas available at 121 https://schema.org include different event types. By using standard 122 schemas, interoperability can be improved between calendar clients 123 and non-calendaring systems that wish to generate or process the 124 data. 126 This specification defines a new "STRUCTURED-DATA" iCalendar property 127 to allow for direct inclusion of ancillary data whose schema is 128 defined elsewhere. This property includes parameters to clearly 129 identify the type of the schema being used so that clients can 130 quickly and easily spot what is relevant within the calendar data and 131 present that to users or process it within the calendaring system. 133 iCalendar does support an "ATTACH" property which can be used to 134 include documents or links to documents within the calendar data. 135 However, that property does not allow data to be included as a "TEXT" 136 value (a feature that "STRUCTURED-DATA" does allow), plus attachments 137 are often treated as "opaque" data to be processed by some other 138 system rather than the calendar client. Thus the existing "ATTACH" 139 property is not sufficient to cover the specific needs of inclusion 140 of schema data. Extending the "ATTACH" property to support a new 141 value type would likely cause interoperability problems. Thus a new 142 property to support inclusion of schema data is warranted. 144 1.1. Conventions Used in This Document 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 [RFC2119]. 151 2. Typed References 153 The properties defined here can all reference external meta-data 154 which may be used by applications to provide enhanced value to users. 155 By providing type information as parameters, clients and servers are 156 able to discover interesting references and make use of them, perhaps 157 for indexing or the presentation of additional related information 158 for the user. 160 These properties are designed to handle common use cases in event 161 publication. It is generally important to provide information about 162 the organizers of such org.bedework.util.jms.events. Sponsors wish 163 to be referenced in a prominent manner. In social calendaring it is 164 often important to identify the active associates in the event, for 165 example a school sports team, and the inactive associates, for 166 example the parents. 168 The [RFC5545] LOCATION property provides only an unstructured single 169 text value for specifying the location where an event (or "TODO" 170 item) will occur. This is inadequate for use cases where structured 171 location information (e.g. address, region, country, postal code) is 172 required or preferred, and limits widespread adoption of iCalendar in 173 those settings. 175 Using STRUCTURED-LOCATION, information about a number of interesting 176 locations can be communicated, for example, parking, restaurants and 177 the venue. Servers and clients can retrieve the objects when storing 178 the event and use them to index by geographic location. 180 When a calendar client receives a calendar component it can search 181 the set of supplied properties looking for those of particular 182 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 183 to help the selection. 185 2.1. Use Cases 187 The main motivation for these properties has been event publication 188 but there are opportunities for use elsewhere. The following use 189 cases will describe some possible scenarios. 191 2.1.1. Piano Concert Performance 193 In putting together a concert there are many associates: piano tuner, 194 performer, stage hands etc. In addition there are sponsors and 195 various contacts to be provided. There will also be a number of 196 related locations. A number of events can be created, all of which 197 relate to the performance in different ways. 199 There may be an iTip meeting request for the piano tuner who will 200 arrive before the performance. Other members of staff may also 201 receive meeting requests. 203 An event can also be created for publication which will have an 204 ASSOCIATE reference to the pianist providing vcard information about 205 the performer. This event would also hold information about parking, 206 local subway stations and the venue itself. In addition, there will 207 be sponsorship information for sponsors of the event and perhaps paid 208 sponsorship properties essentially advertising local establishments. 210 2.1.2. Itineraries 212 These properties also provide opportunities for the travel industry. 213 When booking a flight the ASSOCIATE property can be used to provide 214 references to businesses at the airports and to car hire businesses 215 at the destination. 217 The embedded location information can guide the traveller at the 218 airport or to their final destination. The contact information can 219 provide detailed information about the booking agent, the airlines 220 and car hire companies and the hotel. 222 3. Modifications to Calendar Components 224 The following changes to the syntax defined in iCalendar [RFC5545] 225 are made here. New elements are defined in subsequent sections. 227 eventprop =/ *( 228 ; 229 ; The following are OPTIONAL, 230 ; and MAY occur more than once. 231 ; 232 styleddescription / strucloc / strucres / associate / 233 sdataprop 234 ; 235 ) 237 todoprop =/ *( 238 ; 239 ; The following are OPTIONAL, 240 ; and MAY occur more than once. 241 ; 242 styleddescription / strucloc / strucres / associate / 243 sdataprop 244 ; 245 ) 247 jourprop =/ *( 248 ; 249 ; The following are OPTIONAL, 250 ; and MAY occur more than once. 251 ; 252 styleddescription / associate / 253 sdataprop 254 ; 255 ) 257 4. New Property Parameters 259 This specification makes use of the LABEL property parameter which is 260 defined in [I-D.ietf-calext-extensions] 262 4.1. Loctype 264 Parameter name: LOCTYPE 266 Purpose: To specify the type of location. 268 Format Definition: 270 This parameter is defined by the following notation: 272 loctypeparam = "LOCTYPE" "=" param-value 274 Description: This parameter MAY be specified on STRUCTURED-LOCATION 275 and provides a way to differentiate multiple properties. For 276 example, it allows event producers to provide location information 277 for the venue and the parking. 279 Values for this parameter are taken from the values defined in 280 [RFC4589]. New location types SHOULD be registered in the manner 281 laid down in that specification 283 4.2. Assoctype 285 Parameter name: ASSOCTYPE 287 Purpose: To specify the type of associate. 289 Format Definition: 291 This parameter is defined by the following notation: 293 assoctypeparam = "ASSOCTYPE" "=" param-value 295 Description: This parameter MAY be specified on the ASSOCIATE 296 property, and defines the type of association. Allowable values 297 are defined in Section 6. 299 4.3. Restype 301 Parameter name: RESTYPE 303 Purpose: To specify the type of resource. 305 Format Definition: 307 This parameter is defined by the following notation: 309 restypeparam = "RESTYPE" "=" param-value 311 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 312 and provides a way to differentiate multiple properties. 314 Values for this parameter are taken from the values defined in 315 [todo]. New resource types SHOULD be registered in the manner 316 laid down in that specification 318 4.4. Order 320 Parameter name: ORDER 322 Purpose: To define ordering for the associated property. 324 Format Definition: 326 This parameter is defined by the following notation: 328 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 330 Description: The ORDER parameter is OPTIONAL and is used to indicate 331 the relative ordering of the corresponding instance of a property. 332 Its value MUST be an integer greater than or equal to 1 that 333 quantifies the order. Lower values correspond to a higher level 334 of ordering, with 1 being the highest. 336 When the parameter is absent, the default MUST be to interpret the 337 property instance as being at the lowest level of ordering. 339 Note that the value of this parameter is to be interpreted only in 340 relation to values assigned to other corresponding instances of 341 the same property in the same entity. A given value, or the 342 absence of a value, MUST NOT be interpreted on its own. 344 This parameter MAY be applied to any property that allows multiple 345 instances. 347 4.5. Schema 349 Parameter Name: SCHEMA 351 Purpose: To specify the schema used for the content of a 352 "STRUCTURED-DATA" property value. 354 Format Definition: 356 This parameter is defined by the following notation: 358 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 360 Description: This property parameter SHOULD be specified on 361 "STRUCTURED-DATA" properties. When present it provides 362 identifying information about the nature of the content of the 363 corresponding "STRUCTURED-DATA" property value. This can be used 364 to supplement the media type information provided by the "FMTTYPE" 365 parameter on the corresponding property. 367 Example: 369 STRUCTURED-DATA;FMTTYPE=application/ld+json; 370 SCHEMA="https://schema.org/FlightReservation"; 371 ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy 373 5. New Properties 375 5.1. Associate 377 Property name: ASSOCIATE 379 Purpose: This property provides a typed reference to external 380 information about associates in an event or optionally a plain 381 text typed value. 383 Value type: The default value type for this property is URI. The 384 value type can also be set to TEXT to indicate plain text content. 386 Property Parameters: Non-standard, label, assoctype, order or format 387 type parameters can be specified on this property. 389 Conformance: This property MAY be specified in any iCalendar 390 component. 392 Description: When used in a component the value of this property 393 points to information about an event associate. This is NOT an 394 attendee in a scheduling sense and the ATTENDEE property may in 395 fact be specified in addition. Associates in events can be 396 individuals or organizations, for example a soccer team, the 397 spectators, or the musicians. 399 Format Definition: 401 This property is defined by the following notation: 403 associate = "ASSOCIATE" assocparam 404 ( 405 ( 406 ";" "VALUE" "=" "URI" 407 ":" uri 408 ) / 409 ( 410 ";" "VALUE" "=" "TEXT" 411 ":" text 412 ) 413 ) 414 CRLF 416 assocparam = *( 417 ; 418 ; the following are OPTIONAL 419 ; but MUST NOT occur more than once 420 ; 421 (";" fmttypeparam) / 422 (";" labelparam) / 423 (";" orderparam) / 424 (";" assoctypeparam) / 425 ; 426 ; the following is OPTIONAL 427 ; and MAY occur more than once 428 ; 429 (";" other-param) 430 ; 431 ) 433 Note: When the ORDER parameter is supplied it defines the ordering 434 of ASSOCIATE properties with the same value for the TYPE 435 parameter. 437 Example: 439 The following is an example of this property. It points to a VCARD 440 providing information on an event associate. 442 ASSOCIATE;ASSOCTYPE=PRINCIPAL_PERFORMER: 443 http://dir.example.com/vcard/aviolinist.vcf 445 Example: 447 The following is an example referring to a VCARD providing 448 information on the primary contact. 450 ASSOCIATE;FMTTYPE=text/vcard; 451 ASSOCTYPE=PRIMARY-CONTACT;LABEL=A contact: 452 http://dir.example.com/vcard/contacts/contact1.vcf 454 Example: 456 The following is an example of the property used to link to VCARD 457 information on the event planner. 459 ASSOCIATE;FMTTYPE=text/vcard; 460 ASSOCTYPE=PLANNER-CONTACT;LABEL=ClownsIsUs: 461 http://dir.example.com/vcard/clowns-is-us.vcf 463 5.2. Styled-Description 465 Property name: STYLED-DESCRIPTION 467 Purpose: This property provides for one or more rich-text 468 descriptions to replace or augment that provided by the 469 DESCRIPTION property. 471 Value type: There is no default value type for this property. The 472 value type can be set to URI or TEXT. Other text-based value 473 types can be used when defined in the future. Clients MUST ignore 474 any properties with value types they do not understand. 476 Property Parameters: IANA, non-standard, id, alternate text 477 representation, and language property parameters can be specified 478 on this property. 480 Conformance: The property can be specified multiple times in the 481 "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. 483 Description: This property is used in the "VEVENT" and "VTODO" to 484 capture lengthy textual descriptions associated with the activity. 485 This property is used in the "VJOURNAL" calendar component to 486 capture one or more textual journal entries. This property is 487 used in the "VALARM" calendar component to capture the display 488 text for a DISPLAY category of alarm, and to capture the body text 489 for an EMAIL category of alarm. 491 VALUE=TEXT is used to provide rich-text variants of the plain-text 492 DESCRIPTION property. 494 VALUE=URI is used to provide a link to rich-text content which is 495 expected to be displayed inline as part of the event. 497 The intent of this property is limited to providing a styled and/ 498 or language specific version of the DESCRIPTION property. The URL 499 property should be used to link to websites or other related 500 information. 502 Applications MAY attempt to guess the media type of the resource 503 via inspection of its content if and only if the media type of the 504 resource is not given by the "FMTTYPE" parameter. If the media 505 type remains unknown, calendar applications SHOULD treat it as 506 type "text/html". 508 Multiple STYLED-DESCRIPTION properties may be used to provide 509 different formats or different language variants. 511 Format Definition: 513 This property is defined by the following notation: 515 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 516 ( 517 ( 518 ";" "VALUE" "=" "URI" 519 ":" uri 520 ) / 521 ( 522 ";" "VALUE" "=" "TEXT" 523 ":" text 524 ) 525 ) 526 CRLF 528 styleddescparam = *( 529 ; 530 ; The following are OPTIONAL, 531 ; but MUST NOT occur more than once. 532 ; 533 (";" altrepparam) / (";" languageparam) / 534 (";" fmttypeparam) / 535 ; 536 ; the following is OPTIONAL 537 ; and MAY occur more than once 538 ; 539 (";" other-param) 541 Example: 543 The following is an example of this property. It points to an html 544 description. 546 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 548 5.3. Structured-Location 550 Property name: STRUCTURED-LOCATION 552 Purpose: This property provides a typed reference to external 553 information about the location of an event or optionally a plain 554 text typed value. 556 Value type: There is no default value type for this property. The 557 value type can be set to URI or TEXT. Other text-based value 558 types 560 Property Parameters: IANA, non-standard, label, loctype or format 561 type parameters can be specified on this property. 563 Conformance: This property MAY be specified zero or more times in 564 any iCalendar component. 566 Description: When used in a component the value of this property 567 provides information about the event venue or of related services 568 such as parking, dining, stations etc.. 570 When a LABEL parameter is supplied the language of the label must 571 match that of the content and of the LANGUAGE parameter if 572 present. 574 Format Definition: 576 This property is defined by the following notation: 578 strucloc = "STRUCTURED-LOCATION" struclocparam 579 ( 580 ( 581 ";" "VALUE" "=" "URI" 582 ":" uri 583 ) / 584 ( 585 ";" "VALUE" "=" "TEXT" 586 ":" text 587 ) 588 ) 589 CRLF 591 struclocparam = *( 592 ; 593 ; the following are OPTIONAL 594 ; but MUST NOT occur more than once 595 ; 596 (";" fmttypeparam) / 597 (";" labelparam) / 598 (";" languageparam) / 599 (";" loctypeparam) / 600 ; 601 ; the following is OPTIONAL 602 ; and MAY occur more than once 603 ; 604 (";" other-param) 605 ) 607 Example: 609 The following is an example of this property. It points to a venue. 611 STRUCTURED-LOCATION;LABEL="The venue": 612 http://dir.example.com/venues/big-hall.vcf 614 5.4. Structured-Resource 616 Property name: STRUCTURED-RESOURCE 618 Purpose: This property provides a typed reference to external 619 information about a resource or optionally a plain text typed 620 value. 622 Value type: The default value type for this property is URI. The 623 value type can also be set to TEXT to indicate plain text content. 625 Property Parameters: IANA, non-standard, label, restype or format 626 type parameters can be specified on this property. 628 Conformance: This property MAY be specified zero or more times in 629 any iCalendar component. 631 Description: When used in a component the value of this property 632 provides information about resources used for the event. 634 When a LABEL parameter is supplied the language of the label must 635 match that of the content and of the LANGUAGE parameter if 636 present. 638 Format Definition: 640 This property is defined by the following notation: 642 strucres = "STRUCTURED-RESOURCE" strucresparam (":" uri) / 643 ( 644 ";" "VALUE" "=" "TEXT" 645 ":" text 646 ) 647 CRLF 649 strucresparam = *( 650 ; 651 ; the following are OPTIONAL 652 ; but MUST NOT occur more than once 653 ; 654 (";" fmttypeparam) / 655 (";" labelparam) / 656 (";" languageparam) / 657 (";" restypeparam) / 658 ; 659 ; the following is OPTIONAL 660 ; and MAY occur more than once 661 ; 662 (";" other-param) 663 ) 665 Example: 667 The following is an example of this property. It refers to a 668 projector. 670 STRUCTURED-RESOURCE;restype="projector": 671 http://dir.example.com/projectors/3d.vcf 673 5.5. Structured-Data 675 Property Name: STRUCTURED-DATA 677 Purpose: This property specifies ancillary data associated with the 678 calendar component. 680 Value Type: TEXT 682 Property Parameters: IANA, non-standard, inline encoding, and value 683 data type property parameters can be specified on this property. 684 The format type and schema parameters can be specified on this 685 property and are RECOMMENDED for text or inline binary encoded 686 content information. 688 Conformance: This property can be specified multiple times in an 689 iCalendar object. Typically it would be used in "VEVENT", 690 "VTODO", or "VJOURNAL" calendar components. 692 Description: This property is used to specify ancillary data in some 693 structured format either directly (inline) as a "TEXT" or "BINARY" 694 value, or as a link via a "URI" value. 696 Format Definition: 698 This property is defined by the following notation: 700 sdataprop = "STRUCTURED-DATA" sdataparam 701 (":" text) / 702 ( 703 ";" "ENCODING" "=" "BASE64" 704 ";" "VALUE" "=" "BINARY" 705 ":" binary 706 ) / 707 ( 708 ";" "VALUE" "=" "URI" 709 ":" uri 710 ) 711 CRLF 713 sdataparam = *( 714 ; 715 ; The following is OPTIONAL for a URI value, 716 ; RECOMMENDED for a TEXT or BINARY value, 717 ; and MUST NOT occur more than once. 718 ; 719 (";" fmttypeparam) / 720 (";" schemaparam) / 721 ; 722 ; The following is OPTIONAL, 723 ; and MAY occur more than once. 724 ; 725 (";" other-param) 726 ; 727 ) 729 Example: The following is an example of this property: 731 STRUCTURED-DATA;FMTTYPE=application/ld+json; 732 SCHEMA="https://schema.org/SportsEvent"; 733 VALUE=TEXT:{\n 734 "@context": "http://schema.org"\,\n 735 "@type": "SportsEvent"\,\n 736 "homeTeam": "Pittsburgh Pirates"\,\n 737 "awayTeam": "San Francisco Giants"\n 738 }\n 740 6. Associate Types 742 This section describes types of association and provide registered 743 values for the ASSOCIATE property ASSOCTYPE parameter. 745 ACTIVE: An associate taking an active role - for example a team 746 member. 748 INACTIVE: An associate taking an inactive part - for example an 749 audience member. 751 SPONSOR: A sponsor of the event. The ORDER parameter may be used 752 with this associate type to define the relative order of multiple 753 sponsors. 755 CONTACT: Contact information for the event. The ORDER parameter may 756 be used with this associate type to define the relative order of 757 multiple contacts. 759 BOOKING-CONTACT: Contact information for reservations or payment 761 EMERGENCY-CONTACT: Contact in case of emergency 763 PUBLICITY-CONTACT: Contact for publicity 765 PLANNER-CONTACT: Contact for the event planner or organizer 767 PERFORMER: A performer - for example the soloist or the accompanist. 768 The ORDER parameter may be used with this associate type to define 769 the relative order of multiple sponsors. For example, ORDER=1 770 could define the principal performer or soloist. 772 SPEAKER: Speaker at an event 774 7. Extended examples 776 The following are some examples of the use of the properties defined 777 in this specification. They include additional properties defined in 778 [I-D.ietf-calext-extensions] which includes IMAGE and LIVEFEED. 780 7.1. Example 1 781 The following is an example of a VEVENT describing a concert. It 782 includes location information for the venue itself as well as 783 references to parking and restaurants. 785 BEGIN:VEVENT 786 CREATED:20101116T145739Z 787 DESCRIPTION: Piano Sonata No 3\n 788 Piano Sonata No 30 789 DTSTAMP:20101116T145739Z 790 DTSTART;TZID=America/New_York:20110315T150000Z 791 DTEND;TZID=America/New_York:20110315T163000Z 792 LAST-MODIFIED:20101116T145739Z 793 SUMMARY:Beethoven Piano Sonatas 794 UID:123456 795 STRUCTURED-LOCATION;LABEL="The venue": 796 http://dir.example.com/venues/big-hall.vcf 797 STRUCTURED-LOCATION;LABEL="The venue": 798 http://dir.example.com/venues/parking.vcf 799 ASSOCIATE;ASSOCTYPE=SPONSOR:http://example.com/sponsor.vcf 800 ASSOCIATE;ASSOCTYPE=PERFORMER: 801 http://www.example.com/people/johndoe.vcf 802 END:VEVENT 804 8. Security Considerations 806 Applications using these properties need to be aware of the risks 807 entailed in using the URIs provided as values. See [RFC3986] for a 808 discussion of the security considerations relating to URIs. 810 Security considerations relating to the "ATTACH" property, as 811 described in [RFC5545], are applicable to the "STRUCTURED-DATA" 812 property. 814 9. Privacy Considerations 816 Properties with a "URI" value type can expose their users to privacy 817 leaks as any network access of the URI data can be tracked. Clients 818 SHOULD NOT automatically download data referenced by the URI without 819 explicit instruction from users. This specification does not 820 introduce any additional privacy concerns beyond those described in 821 [RFC5545]. 823 10. IANA Considerations 824 10.1. Property Registrations 826 This document defines the following new iCalendar properties to be 827 added to the registry defined in Section 8.2.3 of [RFC5545]: 829 +---------------------+---------+----------------------+ 830 | Property | Status | Reference | 831 +---------------------+---------+----------------------+ 832 | ASSOCIATE | Current | RFCXXXX, Section 5.1 | 833 | STRUCTURED-DATA | Current | RFCXXXX, Section 5.5 | 834 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 5.2 | 835 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 5.3 | 836 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 5.4 | 837 +---------------------+---------+----------------------+ 839 10.2. Parameter Registrations 841 This document defines the following new iCalendar property parameters 842 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 844 +--------------------+---------+----------------------+ 845 | Property Parameter | Status | Reference | 846 +--------------------+---------+----------------------+ 847 | ASSOCTYPE | Current | RFCXXXX, Section 4.2 | 848 | LOCTYPE | Current | RFCXXXX, Section 4.1 | 849 | ORDER | Current | RFCXXXX, Section 4.4 | 850 | RESTYPE | Current | RFCXXXX, Section 4.3 | 851 | SCHEMA | Current | RFCXXXX, Section 4.5 | 852 +--------------------+---------+----------------------+ 854 10.3. Associate Type Registrations 856 The following table has been used to initialize the associate types 857 registry. 859 +-------------------+---------+--------------------+ 860 | Associate Type | Status | Reference | 861 +-------------------+---------+--------------------+ 862 | ACTIVE | Current | RFCXXXX, Section 6 | 863 | INACTIVE | Current | RFCXXXX, Section 6 | 864 | SPONSOR | Current | RFCXXXX, Section 6 | 865 | CONTACT | Current | RFCXXXX, Section 6 | 866 | BOOKING-CONTACT | Current | RFCXXXX, Section 6 | 867 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 6 | 868 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 6 | 869 | PLANNER-CONTACT | Current | RFCXXXX, Section 6 | 870 | PERFORMER | Current | RFCXXXX, Section 6 | 871 | SPEAKER | Current | RFCXXXX, Section 6 | 872 +-------------------+---------+--------------------+ 874 11. Acknowledgements 876 The author would like to thank Chuck Norris of eventful.com for his 877 work which led to the development of this RFC. 879 The author would also like to thank the members of the Calendaring 880 and Scheduling Consortium Event Publication technical committee and 881 the following individuals for contributing their ideas and support: 883 Cyrus Daboo, John Haug, Dan Mendell, Scott Otis, 885 The authors would also like to thank the Calendaring and Scheduling 886 Consortium for advice with this specification. 888 12. Normative References 890 [I-D.ietf-calext-extensions] 891 Daboo, C., "New Properties for iCalendar", draft-ietf- 892 calext-extensions-03 (work in progress), June 2016. 894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 895 Requirement Levels", BCP 14, RFC 2119, 896 DOI 10.17487/RFC2119, March 1997, 897 . 899 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 900 IANA Considerations Section in RFCs", RFC 2434, 901 DOI 10.17487/RFC2434, October 1998, 902 . 904 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 905 DOI 10.17487/RFC3688, January 2004, 906 . 908 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 909 Resource Identifier (URI): Generic Syntax", STD 66, 910 RFC 3986, DOI 10.17487/RFC3986, January 2005, 911 . 913 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 914 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 915 . 917 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 918 Scheduling Core Object Specification (iCalendar)", 919 RFC 5545, DOI 10.17487/RFC5545, September 2009, 920 . 922 [W3C.REC-xml-20060816] 923 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 924 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 925 Edition)", World Wide Web Consortium Recommendation REC- 926 xml-20060816, August 2006, 927 . 929 Appendix A. Open issues 931 restype values: Need to determine what if any registry of resource 932 types already exists and use that. 934 Appendix B. Change log 936 v05 2016-06-26 MD 938 o Fix up abnf 940 o change ref to ietf from daboo 942 o take out label spec - use Cyrus spec 944 v05 2016-06-14 MD 946 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 948 o Change ORDER to integer >= 1. 950 o Incorporate Structured-Data into this specification. 952 v04 2014-02-01 MD 954 o Added updates attribute. 956 o Minor typos. 958 o Resubmitted mostly to refresh the draft. 960 v03 2013-03-06 MD 962 o Replace PARTICIPANT with ASSOCIATE plus related changes. 964 o Added section showing modifications to components. 966 o Replace ID with GROUP and modify HASH. 968 o Replace TITLE param with LABEL. 970 o Fixed STYLED-DESCRIPTION in various ways, correct example. 972 v02 2012-11-02 MD 974 o Collapse sections with description of properties and the use cases 975 into a section with sub-sections. 977 o New section to describe relating properties. 979 o Remove idref and upgrade hash to have the reference 981 o No default value types on properties.. 983 v01 2012-10-18 MD Many changes. 985 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 987 o Add a STRUCTURED-RESOURCE property 989 o STYLED-DESCRIPTION to handle rich text 991 o Much more... 993 2011-01-07 995 o Remove MEDIA - it's going in the Cyrus RFC 997 o Rename EXTENDED-... to STRUCTURED-... 999 o Add TYPE parameter to SPONSOR 1001 v00 2007-10-19 MD Initial version 1003 Author's Address 1005 Michael Douglass 1006 Spherical Cow Group 1007 226 3rd Street 1008 Troy, NY 12180 1009 USA 1011 Email: mdouglass@sphericalcowgroup.com 1012 URI: http://sphericalcowgroup.com