idnits 2.17.1 draft-ietf-calext-eventpub-extensions-15.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 are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. 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) -- 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 (October 8, 2019) is 1652 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) ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 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 (if approved) October 8, 2019 5 Intended status: Standards Track 6 Expires: April 10, 2020 8 Event Publishing Extensions to iCalendar 9 draft-ietf-calext-eventpub-extensions-15 11 Abstract 13 This specification updates RFC5545 by introducing a number of new 14 iCalendar properties and components which are of particular use for 15 event publishers and in social networking. 17 This specification also defines a new STRUCTURED-DATA property for 18 iCalendar RFC5545 to allow for data that is directly pertinent to an 19 event or task to be included with the calendar data. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 10, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 1.2. Terms Used in This Document . . . . . . . . . . . . . . . 3 58 2. Components and properties . . . . . . . . . . . . . . . . . . 4 59 3. Typed References . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 62 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5 63 3.1.2.1. Reserving facilities . . . . . . . . . . . . . . 6 64 4. Modifications to Calendar Components . . . . . . . . . . . . 6 65 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7 66 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.5. Derived . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Participant Type . . . . . . . . . . . . . . . . . . . . 11 73 6.2. Calendar Address . . . . . . . . . . . . . . . . . . . . 13 74 6.3. Styled-Description . . . . . . . . . . . . . . . . . . . 14 75 6.4. Structured-Location . . . . . . . . . . . . . . . . . . . 16 76 6.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 18 77 6.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 19 78 7. New Components . . . . . . . . . . . . . . . . . . . . . . . 22 79 7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 22 80 7.2. Schedulable Participant . . . . . . . . . . . . . . . . . 24 81 8. Extended examples . . . . . . . . . . . . . . . . . . . . . . 25 82 8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 25 83 8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 25 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 85 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 11.1. Additional iCalendar Registrations . . . . . . . . . . . 27 88 11.1.1. Properties . . . . . . . . . . . . . . . . . . . . . 27 89 11.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 27 90 11.1.3. Components . . . . . . . . . . . . . . . . . . . . . 28 91 11.2. New Registration Tables . . . . . . . . . . . . . . . . 28 92 11.2.1. Participant Types . . . . . . . . . . . . . . . . . 28 93 11.2.2. Resource Types . . . . . . . . . . . . . . . . . . . 28 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 97 13.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 30 99 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 30 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 102 1. Introduction 104 The currently existing iCalendar standard [RFC5545] lacks useful 105 methods for referencing additional, external information relating to 106 calendar components. Additionally there is no standard way to 107 provide rich text descriptions or meta-data associated with the 108 event. 110 Current practice is to embed this information as links in the 111 description or to add non-standard properties as defined in [RFC5545] 112 section 3.8.8.2. 114 This document updates [RFC5545] to define a number of properties and 115 a component referencing such external information that can provide 116 additional information about an iCalendar component. The intent is 117 to allow interchange of such information between applications or 118 systems (e.g., between clients, between client and server, and 119 between servers). Formats such as vCard [RFC2426] are likely to be 120 most useful to the receivers of such events as they may be used in 121 other applications - such as address books. 123 1.1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 1.2. Terms Used in This Document 133 Event: When the word 'event' is used (perhaps with a capitalised 'E' 134 we are referring to gatherings, formal or informal. For example a 135 sports event, a party or a concert. 137 Social Calendaring: Historically, calendar data and scheduling has 138 been heavily biased towards meetings in a corporate environment. 139 Some of the features defined in this document are to support a 140 more informal, i.e. social, model. For example, we may want to 141 record who is participating in a public event. 143 2. Components and properties 145 Previous extensions to the calendaring standards have been largely 146 restricted to the addition of properties or parameters. This is 147 partly because iCalendar libraries had trouble handling components 148 nested deeper than those defined in [RFC5545]. 150 In a break with this 'tradition' this specification defines 151 PARTICIPANT as a component rather than a property. This is a better 152 match for the way [W3C.REC-xml-20081126] and JSON [RFC8259] handle 153 such structures and allows richer definitions. 155 It also allows for the addition of extra properties inside the 156 component and resolves some of the problems of trying to add detailed 157 information as a parameter. 159 Many people or groups may participate in an event. The PARTICIPANT 160 component provides such detailed information. Participants may act 161 as attendees to the event (or derived events) or may just provide a 162 reference - perhaps for mailing lists. 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 presenting of additional related information for 171 the user. 173 The [RFC5545] LOCATION property provides only an unstructured single 174 text value for specifying the location where an event (or task) will 175 occur. This is inadequate for use cases where structured location 176 information (e.g. address, region, country, postal code) is required 177 or preferred, and limits widespread adoption of iCalendar in those 178 settings. 180 Using STRUCTURED-LOCATION, rich information about multiple locations 181 can be communicated, for example, address, region, country, postal 182 code as well as other information such as the parking, restaurants 183 and the venue. Servers and clients can retrieve the objects when 184 storing the event and use them to index by geographic location. 186 When a calendar client receives a calendar component it can search 187 the set of supplied properties looking for those of particular 188 interest. The TYPE and FMTTYPE parameters, if supplied, can be used 189 to help the selection. 191 The PARTICIPANT component is designed to handle common use cases in 192 event publication. It is generally important to provide information 193 about the organizers of such events. Sponsors wish to be referenced 194 in a prominent manner. In social calendaring it is often important 195 to identify the active participants in the event, for example a 196 school sports team, and the inactive participants, for example the 197 parents. 199 The PARTICIPANT component can also be used to provide useful extra 200 data about an attendee. For example a LOCATION property inside the 201 PARTICIPANT gives the actual location of a remote attendee. (But see 202 the note about privacy.) 204 3.1. Use Cases 206 The main motivation for these properties has been event publication 207 but there are opportunities for use elsewhere. The following use 208 cases will describe some possible scenarios. 210 3.1.1. Piano Concert Performance 212 In putting together a concert there are many participants: piano 213 tuner, performer, stage hands etc. In addition there are sponsors 214 and various contacts to be provided. There will also be a number of 215 related locations. A number of events can be created, all of which 216 relate to the performance in different ways. 218 There may be an iTip [RFC5546] meeting request for the piano tuner 219 who will arrive before the performance. Other members of staff may 220 also receive meeting requests. 222 An event can also be created for publication which will have a 223 PARTICIPANT component for the pianist providing a reference to vCard 224 [RFC2426] information about the performer. This event would also 225 hold information about parking, local subway stations and the venue 226 itself. In addition, there may be sponsorship information for 227 sponsors of the event and perhaps paid sponsorship properties 228 essentially advertising local establishments. 230 3.1.2. Itineraries 232 These additions also provide opportunities for the travel industry. 233 When booking a flight the PARTICIPANT component can be used to 234 provide references to businesses at the airports and to car hire 235 businesses at the destination. 237 The embedded location information can guide the traveler at the 238 airport or to their final destination. The contact information can 239 provide detailed information about the booking agent, the airlines, 240 car hire companies and the hotel. 242 3.1.2.1. Reserving facilities 244 For a meeting, the size of a room and the equipment needed depends to 245 some extent on the number of attendees actually in the room. 247 A meeting may have 10 attendees none of which are co-located. The 248 current ATTENDEE property does not allow for the addition of such 249 meta-data. The PARTICIPANT property allows attendees to specify 250 their location. 252 4. Modifications to Calendar Components 254 The following changes to the syntax defined in iCalendar [RFC5545] 255 are made here. New elements are defined in subsequent sections. 257 eventc = "BEGIN" ":" "VEVENT" CRLF 258 eventprop *alarmc *participantc 259 "END" ":" "VEVENT" CRLF 261 eventprop =/ *( 262 ; 263 ; The following are OPTIONAL, 264 ; and MAY occur more than once. 265 ; 266 styleddescription / strucloc / strucres / sdataprop 267 ; 268 ) 270 todoc = "BEGIN" ":" "VTODO" CRLF 271 todoprop *alarmc *participantc 272 "END" ":" "VTODO" CRLF 274 todoprop =/ *( 275 ; 276 ; The following are OPTIONAL, 277 ; and MAY occur more than once. 278 ; 279 styleddescription / strucloc / strucres / sdataprop 280 ; 281 ) 283 journalc = "BEGIN" ":" "VJOURNAL" CRLF 284 jourprop *participantc 285 "END" ":" "VJOURNAL" CRLF 287 jourprop =/ *( 288 ; 289 ; The following are OPTIONAL, 290 ; and MAY occur more than once. 291 ; 292 styleddescription / sdataprop 293 ; 294 ) 296 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF 297 fbprop *participantc 298 "END" ":" "VFREEBUSY" CRLF 300 fbprop =/ *( 301 ; 302 ; The following are OPTIONAL, 303 ; and MAY occur more than once. 304 ; 305 styleddescription 306 ; 307 ) 309 5. New Property Parameters 311 This specification makes use of the LABEL parameter which is defined 312 in [RFC7986] 314 5.1. Loctype 316 Parameter name: LOCTYPE 318 Purpose: To specify the type of location. 320 Format Definition: 322 This parameter is defined by the following notation: 324 loctypeparam = "LOCTYPE" "=" param-value 326 Description: This parameter MAY be specified on STRUCTURED-LOCATION 327 and provides a way to differentiate multiple properties. For 328 example, it allows event producers to provide location information 329 for the venue and the parking. 331 Values for this parameter are taken from the values defined in 332 [RFC4589] section 3. New location types SHOULD be registered in 333 the manner laid down in section 5 of that specification. 335 5.2. Restype 337 Parameter name: RESTYPE 339 Purpose: To specify the type of resource. 341 Format Definition: 343 This parameter is defined by the following notation: 345 restypeparam = "RESTYPE" "=" restypevalue CRLF 347 restypevalue = ("ROOM" 348 / "PROJECTOR" 349 / "REMOTE-CONFERENCE-AUDIO" 350 / "REMOTE-CONFERENCE-VIDEO" 351 / iana-token) ; Other IANA-registered 352 ; values 354 Description: This parameter MAY be specified on STRUCTURED-RESOURCE 355 and provides a way to differentiate multiple properties. 357 The registered values are described below. New resource types 358 SHOULD be registered in the manner laid down in this 359 specification. 361 ROOM: A room for the event/meeting. 363 PROJECTOR: Projection equipment. 365 REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities. 367 REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities. 369 5.3. Order 371 Parameter name: ORDER 373 Purpose: To define ordering for the associated property. 375 Format Definition: 377 This parameter is defined by the following notation: 379 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 380 Description: The ORDER parameter is OPTIONAL and is used to indicate 381 the relative ordering of the corresponding instance of a property. 382 Its value MUST be an integer greater than or equal to 1 that 383 specifies the order with 1 being the first in the ordering. 385 When the parameter is absent, the default MUST be to interpret the 386 property instance as being at the lowest level of ordering, that 387 is, the property will appear after any other instances of the same 388 property with any value of ORDER. 390 When any ORDER parameters have the same value all the associated 391 properties appear as a group within which there is no defined 392 order. 394 Note that the value of this parameter is to be interpreted only in 395 relation to values assigned to other corresponding instances of 396 the same property in the same entity. 398 This parameter MUST NOT be applied to a property that does not 399 allow multiple instances. 401 Example uses: The ORDER may be applied to the PARTICIPANT-TYPE 402 property to indicate the relative importance of the participant, 403 for example as a sponsor or a performer. For example, ORDER=1 404 could define the principal performer or soloist. 406 5.4. Schema 408 Parameter Name: SCHEMA 410 Purpose: To specify the schema used for the content of a 411 "STRUCTURED-DATA" property value. 413 Format Definition: 415 This parameter is defined by the following notation: 417 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE 419 Description: This property parameter SHOULD be specified on 420 "STRUCTURED-DATA" properties. When present it provides 421 identifying information about the nature of the content of the 422 corresponding "STRUCTURED-DATA" property value. This can be used 423 to supplement the media type information provided by the "FMTTYPE" 424 parameter on the corresponding property. 426 Example: 428 STRUCTURED-DATA;FMTTYPE=application/ld+json; 429 SCHEMA="https://schema.org/FlightReservation"; 430 ENCODING=BASE64;VALUE=BINARY:ICAgIDxzY3JpcHQgdHlwZT0iYXBwb 431 GljYXRpb24vbGQranNvbiI+CiAgICB7CiAgICAgICJAY29 432 udGV4dCI6ICJodHRwOi8vc2NoZW1hLm9yZyIsCiAgICAgICJAdHlwZSI 433 6ICJGbGlnaHRSZXNlcnZhdGlvbiIsCiAgICAgICJyZXNlcnZhdGlvbkl 434 kIjogIlJYSjM0UCIsCiAgICAgICJyZXNlcnZhdGlvblN0YXR1cyI6ICJ 435 odHRwOi8vc2NoZW1hLm9yZy9SZXNlcnZhdGlvbkNvbmZpcm1lZCIsCiA 436 gICAgICJwYXNzZW5nZXJQcmlvcml0eVN0YXR1cyI6ICJGYXN0IFRyYWN 437 rIiwKICAgICAgInBhc3NlbmdlclNlcXVlbmNlTnVtYmVyIjogIkFCQzE 438 yMyIsCiAgICAgICJzZWN1cml0eVNjcmVlbmluZyI6ICJUU0EgUHJlQ2h 439 lY2siLAogICAgICAidW5kZXJOYW1lIjogewogICAgICAgICJAdHlwZSI 440 6ICJQZXJzb24iLAogICAgICAgICJuYW1lIjogIkV2YSBHcmVlbiIKICA 441 gICAgfSwKICAgICAgInJlc2VydmF0aW9uRm9yIjogewogICAgICAgICJ 442 AdHlwZSI6ICJGbGlnaHQiLAogICAgICAgICJmbGlnaHROdW1iZXIiOiA 443 iVUExMTAiLAogICAgICAgICJwcm92aWRlciI6IHsKICAgICAgICAgICJ 444 AdHlwZSI6ICJBaXJsaW5lIiwKICAgICAgICAgICJuYW1lIjogIkNvbnR 445 pbmVudGFsIiwKICAgICAgICAgICJpYXRhQ29kZSI6ICJDTyIsCiAgICA 446 gICAgICAiYm9hcmRpbmdQb2xpY3kiOiAiaHR0cDovL3NjaGVtYS5vcmc 447 vWm9uZUJvYXJkaW5nUG9saWN5IgogICAgICAgIH0sCiAgICAgICAgInN 448 lbGxlciI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJsaW5lIiwKICA 449 gICAgICAgICJuYW1lIjogIlVuaXRlZCIsCiAgICAgICAgICAiaWF0YUN 450 vZGUiOiAiVUEiCiAgICAgICAgfSwKICAgICAgICAiZGVwYXJ0dXJlQWl 451 ycG9ydCI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJwb3J0IiwKICA 452 gICAgICAgICJuYW1lIjogIlNhbiBGcmFuY2lzY28gQWlycG9ydCIsCiA 453 gICAgICAgICAiaWF0YUNvZGUiOiAiU0ZPIgogICAgICAgIH0sCiAgICA 454 gICAgImRlcGFydHVyZVRpbWUiOiAiMjAxNy0wMy0wNFQyMDoxNTowMC0 455 wODowMCIsCiAgICAgICAgImFycml2YWxBaXJwb3J0IjogewogICAgICA 456 gICAgIkB0eXBlIjogIkFpcnBvcnQiLAogICAgICAgICAgIm5hbWUiOiA 457 iSm9obiBGLiBLZW5uZWR5IEludGVybmF0aW9uYWwgQWlycG9ydCIsCiA 458 gICAgICAgICAiaWF0YUNvZGUiOiAiSkZLIgogICAgICAgIH0sCiAgICA 459 gICAgImFycml2YWxUaW1lIjogIjIwMTctMDMtMDVUMDY6MzA6MDAtMDU 460 6MDAiCiAgICAgIH0KICAgIH0KICAgIDwvc2NyaXB0Pg== 462 5.5. Derived 464 Parameter Name: DERIVED 466 Purpose: To specify that the value of the associated property is 467 derived from some other property value or values. 469 Format Definition: 471 This parameter is defined by the following notation: 473 derivedparam = "DERIVED" "=" ("TRUE" / "FALSE") 474 ; Default is FALSE 476 Description: This property parameter MAY be specified on any 477 property when the value is derived from some other property or 478 properties. When present with a value of TRUE clients MUST NOT 479 update the property. 481 As an example, if a STYLED-DESCRIPTION property is present with 482 FMTTYPE="application/rtf" then there may be an additional STYLED- 483 DESCRIPTION property with FMTTYPE="text/html" and DERIVED=TRUE and 484 a value created from the rtf value. 486 Example: 488 STYLED-DESCRIPTION;FMTTYPE=text/html; 489 DERIVED=TRUE:... 491 6. New Properties 493 6.1. Participant Type 495 Property name: PARTICIPANT-TYPE 497 Purpose: To specify the type of participant. 499 Value type: The value type for this property is TEXT. The allowable 500 values are defined below. 502 Property Parameters: Non-standard parameters can be specified on 503 this property. 505 Conformance: This property MUST be specified once within a 506 PARTICIPANT component. 508 Description: This property defines the type of participation in 509 events or tasks. Participants can be individuals or 510 organizations, for example a soccer team, the spectators, or the 511 musicians. 513 Format Definition: 515 This property is defined by the following notation: 517 participanttype = "PARTICIPANT-TYPE" partvalueparam ":" 518 partvalue CRLF 520 partvalue = ("ACTIVE" 521 / "INACTIVE" 522 / "SPONSOR" 523 / "CONTACT" 524 / "BOOKING-CONTACT" 525 / "EMERGENCY-CONTACT" 526 / "PUBLICITY-CONTACT" 527 / "PLANNER-CONTACT" 528 / "PERFORMER" 529 / "SPEAKER" 530 / iana-token) ; Other IANA-registered 531 ; values 533 partvalueparam = *( 534 ; the following is OPTIONAL 535 ; and MAY occur more than once 536 ; 537 (";" other-param) 538 ) 540 Example: 542 The following is an example of this property: 544 PARTICIPANT-TYPE:SPEAKER 546 The registered values for the PARTICIPANT-TYPE property have the 547 meanings described here: 549 ACTIVE: A participant taking an active role - for example a team 550 member. 552 INACTIVE: A participant taking an inactive part - for example an 553 audience member. 555 SPONSOR: A sponsor of the event. The ORDER parameter may be used 556 with this participant type to define the relative order of 557 multiple sponsors. 559 CONTACT: Contact information for the event. The ORDER parameter may 560 be used with this participant type to define the relative order of 561 multiple contacts. 563 BOOKING-CONTACT: Contact information for reservations or payment 565 EMERGENCY-CONTACT: Contact in case of emergency 567 PUBLICITY-CONTACT: Contact for publicity 569 PLANNER-CONTACT: Contact for the event planner or organizer 571 PERFORMER: A performer - for example the soloist or the accompanist. 572 The ORDER parameter may be used with this participant type to 573 define the relative order of multiple performers. For example, 574 ORDER=1 could define the principal performer or soloist. 576 SPEAKER: Speaker at an event 578 6.2. Calendar Address 580 Property name: CALENDAR-ADDRESS 582 Purpose: To specify the calendar address for a participant. 584 Value type: CAL-ADDRESS 586 Property Parameters: IANA or non-standard property parameters can be 587 specified on this property. 589 Conformance: This property MAY be specified once within a 590 PARTICIPANT component. 592 Description: This property provides a calendar user address for the 593 participant. If there is an ATTENDEE property with the same value 594 then the participant is schedulable. 596 Format Definition: 598 This property is defined by the following notation: 600 calendaraddress = "CALENDAR-ADDRESS" caladdressparam ":" 601 cal-address CRLF 603 caladdressparam = *( 604 ; the following is OPTIONAL 605 ; and MAY occur more than once 606 ; 607 (";" other-param) 608 ) 610 6.3. Styled-Description 612 Property name: STYLED-DESCRIPTION 614 Purpose: This property provides for one or more rich-text 615 descriptions to replace that provided by the DESCRIPTION property. 617 Value type: There is no default value type for this property. The 618 value type can be set to URI or TEXT. Other text-based value 619 types can be used when defined in the future. Clients MUST ignore 620 any properties with value types they do not understand. 622 Property Parameters: IANA, non-standard, id, alternate text 623 representation, format type, derived and language property 624 parameters can be specified on this property. 626 Conformance: The property can be specified multiple times in the 627 "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", "PARTICIPANT", or 628 "VALARM" calendar components. 630 If it does appear more than once there MUST be exactly one 631 instance of the property with no DERIVED parameter or 632 DERIVED=FALSE. All others MUST have DERIVED=TRUE. 634 Additionally, if there is one or more STYLED-DESCRIPTION property 635 then the DESCRIPTION property should be either absent or have the 636 parameter DERIVED=TRUE. 638 Description: This property supports rich-text descriptions, for 639 example HTML. Event publishers typically wish to provide more and 640 better formatted information about the event. 642 This property is used in the "VEVENT" and "VTODO" to capture 643 lengthy textual descriptions associated with the activity. This 644 property is used in the "VJOURNAL" calendar component to capture 645 one or more textual journal entries. This property is used in the 646 "VALARM" calendar component to capture the display text for a 647 DISPLAY category of alarm, and to capture the body text for an 648 EMAIL category of alarm. In the PARTICIPANT component it provides 649 a detailed description of the participant. 651 VALUE=TEXT is used to provide rich-text inline as the property 652 value. 654 VALUE=URI is used to provide a link to rich-text content which is 655 expected to be displayed inline as part of the event. 657 In either case the DESCRIPTION property should be absent or 658 contain a plain text rendering of the styled text. 660 Applications MAY attempt to guess the media type of the resource 661 via inspection of its content if and only if the media type of the 662 resource is not given by the "FMTTYPE" parameter. If the media 663 type remains unknown, calendar applications SHOULD treat it as 664 type "text/html" and process the content as defined in 665 [W3C.REC-html51-20171003] 667 Multiple STYLED-DESCRIPTION properties may be used to provide 668 different formats or different language variants. However all but 669 one MUST have DERIVED=TRUE. 671 Format Definition: 673 This property is defined by the following notation: 675 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":" 676 styleddescval CRLF 678 styleddescparam = *( 679 ; The following is REQUIRED, 680 ; but MUST NOT occur more than once. 681 ; 682 (";" "VALUE" "=" ("URI" / "TEXT")) / 683 ; 684 ; The following are OPTIONAL, 685 ; but MUST NOT occur more than once. 686 ; 687 (";" altrepparam) / (";" languageparam) / 688 (";" fmttypeparam) / (";" derivedparam) / 689 ; 690 ; the following is OPTIONAL 691 ; and MAY occur more than once 692 ; 693 (";" other-param) 694 ) 696 styleddescval = ( uri / text ) 697 ;Value MUST match value type 699 Example: 701 The following is an example of this property. It points to an html 702 description. 704 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html 706 6.4. Structured-Location 708 Property name: STRUCTURED-LOCATION 710 Purpose: This property provides a typed reference to external 711 information about the location of an event or optionally a plain 712 text typed value. 714 Value type: There is no default value type for this property. The 715 value type can be set to URI or TEXT. 717 Property Parameters: IANA, non-standard, label, loctype, related or 718 format type parameters can be specified on this property. 720 Conformance: This property MAY be specified zero or more times in 721 any iCalendar component. 723 Description: There may be a number of locations associated with an 724 event. This provides detailed information about these locations. 726 When used in a component the value of this property provides 727 information about the event venue or of related services such as 728 parking, dining, stations etc.. 730 When a LABEL parameter is supplied the language of the label 731 SHOULD match that of the content and of the LANGUAGE parameter if 732 present. 734 Use of the related parameter: This allows a location to define the 735 start and/or end timezone of the associated component. If a 736 location is specified with a RELATED parameter then the affected 737 DTSTART or DTEND properties MUST be specified as floating DATE- 738 TIME value. 740 If the RELATED parameter is present with a value of START, then 741 the "DTSTART" property MUST be present in the associated "VEVENT" 742 or "VTODO" calendar component. 744 For an event, if the RELATED parameter is present with a value of 745 END, then the "DTEND" property or the "DTSTART" and "DURATION " 746 properties MUST be present in the associated "VEVENT" calendar 747 component. 749 For a to-do with a RELATED value of END, then either the "DUE" 750 property or the "DTSTART" and "DURATION " properties MUST be 751 present in the associated "VTODO" calendar component. 753 If there is a location specified with RELATED=START and no 754 location is specified with RELATED=END then the event is assumed 755 to start and end in the same timezone. 757 Format Definition: 759 This property is defined by the following notation: 761 strucloc = "STRUCTURED-LOCATION" struclocparam ":" 762 struclocval CRLF 764 struclocparam = *( 765 ; The following is REQUIRED, 766 ; but MUST NOT occur more than once. 767 ; 768 (";" "VALUE" "=" ("URI" / "TEXT")) / 769 ; 770 ; the following are OPTIONAL 771 ; but MUST NOT occur more than once 772 ; 773 (";" fmttypeparam) / 774 (";" labelparam) / 775 (";" languageparam) / 776 (";" trigrelparam) / 777 (";" loctypeparam) / 778 ; 779 ; the following is OPTIONAL 780 ; and MAY occur more than once 781 ; 782 (";" other-param) 783 ) 785 struclocval = ( uri / text ) 786 ;Value MUST match value type 788 Example: 790 The following is an example of this property. It points to a venue. 792 STRUCTURED-LOCATION;LABEL="The venue"; 793 VALUE=URI: 794 http://dir.example.com/venues/big-hall.vcf 796 6.5. Structured-Resource 798 Property name: STRUCTURED-RESOURCE 800 Purpose: This property provides a typed reference to external 801 information about a resource or optionally a plain text typed 802 value. Typically a resource is anything that might be required or 803 used by a calendar entity and possibly has a directory entry. 805 Value type: There is no default value type for this property. The 806 value type can be set to URI or TEXT. 808 Property Parameters: IANA, non-standard, label, restype or format 809 type parameters can be specified on this property. 811 Conformance: The property can be specified multiple times in the 812 "VEVENT" or "VTODO" calendar components. 814 Description: When used in a component the value of this property 815 provides information about resources used for the event such as 816 rooms, projectors, conferencing capabilities. 818 Such resources may be a room or a projector. This RESTYPE value 819 registry provides a place in which resource types may be 820 registered for use by scheduling services. 822 When a LABEL parameter is supplied the language of the label must 823 match that of the content and of the LANGUAGE parameter if 824 present. 826 Format Definition: 828 This property is defined by the following notation: 830 strucres = "STRUCTURED-RESOURCE" strucresparam ":" 831 strucresval CRLF 833 strucresparam = *( 834 ; The following is REQUIRED, 835 ; but MUST NOT occur more than once. 836 ; 837 (";" "VALUE" "=" ("URI" / "TEXT")) / 838 ; 839 ; the following are OPTIONAL 840 ; but MUST NOT occur more than once 841 ; 842 (";" fmttypeparam) / 843 (";" labelparam) / 844 (";" languageparam) / 845 (";" restypeparam) / 846 ; 847 ; the following is OPTIONAL 848 ; and MAY occur more than once 849 ; 850 (";" other-param) 851 ) 853 strucewaval = ( uri / text ) 854 ;Value MUST match value type 856 Example: 858 The following is an example of this property. It refers to a 859 projector. 861 STRUCTURED-RESOURCE;value=uri;restype="projector": 862 http://dir.example.com/projectors/3d.vcf 864 6.6. Structured-Data 866 Property Name: STRUCTURED-DATA 868 Purpose: This property specifies ancillary data associated with the 869 calendar component. 871 Value Type: TEXT, BINARY or URI 873 Property Parameters: IANA, non-standard, inline encoding, and value 874 data type property parameters can be specified on this property. 876 The format type and schema parameters can be specified on this 877 property and are RECOMMENDED for text or inline binary encoded 878 content information. 880 Conformance: This property can be specified multiple times in an 881 iCalendar object. Typically it would be used in "VEVENT", 882 "VTODO", or "VJOURNAL" calendar components. 884 Description: The existing properties in iCalendar cover key elements 885 of events and tasks such as start time, end time, location, 886 summary, etc. However, different types of events often have other 887 specific "fields" that it is useful to include in the calendar 888 data. For example, an event representing an airline flight could 889 include the airline, flight number, departure and arrival airport 890 codes, check-in and gate-closing times etc. As another example, a 891 sporting event might contain information about the type of sport, 892 the home and away teams, the league the teams are in, information 893 about nearby parking, etc. 895 This property is used to specify ancillary data in some structured 896 format either directly (inline) as a "TEXT" or "BINARY" value, or 897 as a link via a "URI" value. 899 Rather than define new iCalendar properties for the variety of 900 event types that might occur, it would be better to leverage 901 existing schemas for such data. For example, schemas available at 902 https://schema.org include different event types. By using 903 standard schemas, interoperability can be improved between 904 calendar clients and non-calendaring systems that wish to generate 905 or process the data. 907 This property allows the direct inclusion of ancillary data whose 908 schema is defined elsewhere. This property also includes 909 parameters to clearly identify the type of the schema being used 910 so that clients can quickly and easily spot what is relevant 911 within the calendar data and present that to users or process it 912 within the calendaring system. 914 iCalendar does support an "ATTACH" property which can be used to 915 include documents or links to documents within the calendar data. 916 However, that property does not allow data to be included as a 917 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus 918 attachments are often treated as "opaque" data to be processed by 919 some other system rather than the calendar client. Thus the 920 existing "ATTACH" property is not sufficient to cover the specific 921 needs of inclusion of schema data. Extending the "ATTACH" 922 property to support a new value type would likely cause 923 interoperability problems. Additionally some implementations 924 manage attachments by stripping them out and replacing with a link 925 to the resource. Thus a new property to support inclusion of 926 schema data is warranted. 928 Format Definition: 930 This property is defined by the following notation: 932 sdataprop = "STRUCTURED-DATA" sdataparam 933 (":" text) / 934 ( 935 ";" "ENCODING" "=" "BASE64" 936 ";" "VALUE" "=" "BINARY" 937 ":" binary 938 ) / 939 ( 940 ";" "VALUE" "=" "URI" 941 ":" uri 942 ) 943 CRLF 945 sdataparam = *( 946 ; 947 ; The following is OPTIONAL for a URI value, 948 ; REQUIRED for a TEXT or BINARY value, 949 ; and MUST NOT occur more than once. 950 ; 951 (";" fmttypeparam) / 952 (";" schemaparam) / 953 ; 954 ; The following is OPTIONAL, 955 ; and MAY occur more than once. 956 ; 957 (";" other-param) 958 ; 959 ) 961 Example: The following is an example of this property: 963 STRUCTURED-DATA;FMTTYPE=application/ld+json; 964 SCHEMA="https://schema.org/SportsEvent"; 965 VALUE=TEXT:{\n 966 "@context": "http://schema.org"\,\n 967 "@type": "SportsEvent"\,\n 968 "homeTeam": "Pittsburgh Pirates"\,\n 969 "awayTeam": "San Francisco Giants"\n 970 }\n 972 7. New Components 974 7.1. Participant 976 Component name: PARTICIPANT 978 Purpose: This component provides information about a participant in 979 an event or task. 981 Conformance: This component can be specified multiple times in a 982 "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component. 984 Description: This component provides information about a participant 985 in an event, task or poll. A participant may be an attendee in a 986 scheduling sense and the ATTENDEE property may be specified in 987 addition. Participants in events can be individuals or 988 organizations, for example a soccer team, the spectators, or the 989 musicians. 991 STRUCTURED-DATA properties if present may refer to external 992 definitions of the participant - such as a vCard. 994 The CALENDAR-ADDRESS property if present will provide a cal- 995 address. If an ATTENDEE property has the same value the 996 participant is considered schedulable. The PARTICIPANT component 997 can be used to contain additional meta-data related to the 998 attendee. 1000 Format Definition: 1002 This component is defined by the following notation: 1004 participantc = "BEGIN" ":" "PARTICIPANT" CRLF 1005 partprop 1006 "END" ":" "PARTICIPANT" CRLF 1008 partprop = *( 1009 ; 1010 ; The following are REQUIRED, 1011 ; but MUST NOT occur more than once. 1012 ; 1013 dtstamp / participanttype / uid / 1014 ; 1015 ; The following are OPTIONAL, 1016 ; but MUST NOT occur more than once. 1017 ; 1018 created / description / geo / last-mod / priority / seq / 1019 status / calendaraddress / summary / url / 1020 ; 1021 ; The following are OPTIONAL, 1022 ; and MAY occur more than once. 1023 ; 1024 attach / categories / comment / 1025 contact / location / rstatus / related / 1026 resources / strucloc / strucres / styleddescription / 1027 sdataprop / iana-prop 1028 ; 1029 ) 1031 Note: When the PRIORITY is supplied it defines the ordering of 1032 PARTICIPANT components with the same value for the TYPE parameter. 1034 Privacy Issues: When a LOCATION is supplied it provides information 1035 about the location of a participant at a given time or times. 1036 This may represent an unacceptable privacy risk for some 1037 participants. User agents MUST NOT include this information 1038 without the participant's express permission.. 1040 Example: 1042 The following is an example of this component. It contains a 1043 STRUCTURED-DATA property which points to a vCard providing 1044 information about the event participant. 1046 BEGIN:PARTICIPANT 1047 PARTICIPANT-TYPE:PERFORMER 1048 STRUCTURED-DATA;VALUE=URI:http://dir.example.com/vcard/aviolinist.vcf 1049 END:PARTICIPANT 1051 Example: 1053 The following is an example for the primary contact. 1055 BEGIN: PARTICIPANT 1056 STRUCTURED-DATA;VALUE=URI; 1057 http://dir.example.com/vcard/contacts/contact1.vcf 1058 PARTICIPANT-TYPE:CONTACT 1059 DESCRIPTION:A contact: 1060 END:PARTICIPANT 1062 7.2. Schedulable Participant 1064 A PARTICIPANT component may represent someone or something that needs 1065 to be scheduled as defined for ATTENDEE in [RFC5545] and [RFC5546]. 1066 The PARTICIPANT component may also represent someone or something 1067 that is NOT to receive scheduling messages. 1069 A PARTICIPANT component is defined to be schedulable if 1071 o It contains a CALENDAR-ADDRESS property 1073 o That property value is the same as the value for an ATTENDEE 1074 property. 1076 If both of these conditions apply then the participant defined by the 1077 value of the URL property will take part in scheduling operations as 1078 defined in [RFC5546]. 1080 An appropriate use for the PARTICIPANT component in scheduling would 1081 be to store SEQUENCE and DTSTAMP properties associated with replies 1082 from each ATTENDEE. A LOCATION property within the PARTICIPANT 1083 component might allow better selection of meeting times when 1084 participants are in different timezones. 1086 8. Extended examples 1088 The following are some examples of the use of the properties defined 1089 in this specification. They include additional properties defined in 1090 [RFC7986] which includes IMAGE. 1092 8.1. Example 1 1094 The following is an example of a VEVENT describing a concert. It 1095 includes location information for the venue itself as well as 1096 references to parking and restaurants. 1098 BEGIN:VEVENT 1099 CREATED:20170216T145739Z 1100 DESCRIPTION: Piano Sonata No 3\n 1101 Piano Sonata No 30 1102 DTSTAMP:20171116T145739Z 1103 DTSTART;TZID=America/New_York:20170315T150000Z 1104 DTEND;TZID=America/New_York:20170315T163000Z 1105 LAST-MODIFIED:20170216T145739Z 1106 SUMMARY:Beethoven Piano Sonatas 1107 UID:123456 1108 STRUCTURED-LOCATION;LABEL="The venue";VALUE=URI: 1109 http://dir.example.com/venues/big-hall.vcf 1110 STRUCTURED-LOCATION;LABEL="Parking for the venue";VALUE=URI: 1111 http://dir.example.com/venues/parking.vcf 1112 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h 1113 ttp://example.com/images/concert.png 1114 BEGIN:PARTICIPANT 1115 PARTICIPANT-TYPE:SPONSOR 1116 STRUCTURED-DATA;VALUE=URI:http://example.com/sponsor.vcf 1117 END:PARTICIPANT 1118 BEGIN:PARTICIPANT 1119 PARTICIPANT-TYPE:PERFORMER: 1120 STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/johndoe.vcf 1121 END:PARTICIPANT 1122 END:VEVENT 1124 8.2. Example 2 1125 The following is an example of a VEVENT describing a meeting. One of 1126 the attendees is a remote participant. 1128 BEGIN:VEVENT 1129 CREATED:20170216T145739Z 1130 DTSTAMP:20101116T145739Z 1131 DTSTART;TZID=America/New_York:20170315T150000Z 1132 DTEND;TZID=America/New_York:20170315T163000Z 1133 LAST-MODIFIED:20170216T145739Z 1134 SUMMARY:Conference planning 1135 UID:123456 1136 ORGANIZER:mailto:a@example.com 1137 ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com 1138 ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com 1139 BEGIN:PARTICIPANT 1140 PARTICIPANT-TYPE:ACTIVE: 1141 STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/b.vcf 1142 LOCATION:At home 1143 END:PARTICIPANT 1144 END:VEVENT 1146 9. Security Considerations 1148 Applications using these properties need to be aware of the risks 1149 entailed in using the URIs provided as values. See [RFC3986] for a 1150 discussion of the security considerations relating to URIs. 1152 For the "STRUCTURED-DATA" property, servers need to be aware that a 1153 client could attack underlying storage by sending extremely large 1154 values and could attack processing time by uploading a recurring 1155 event with a large number of overrides and then repeatedly adding, 1156 updating, and deleting structured data. 1158 Malicious content could be introduced into the calendar server by way 1159 of the "STRUCTURED-DATA" property, and propagated to many end users 1160 via scheduling. Servers SHOULD check this property for malicious or 1161 inappropriate content. Upon detecting such content, servers SHOULD 1162 remove the property, 1164 When processing HTML content applications need to be aware of the 1165 many security and privacy issues as described in the IANA 1166 considerations section of [W3C.REC-html51-20171003] 1168 10. Privacy Considerations 1170 Properties with a "URI" value type can expose their users to privacy 1171 leaks as any network access of the URI data can be tracked. Clients 1172 SHOULD NOT automatically download data referenced by the URI without 1173 explicit instruction from users. 1175 The addition of location information to the new participant component 1176 provides information about the location of participants at a given 1177 time. 1179 11. IANA Considerations 1181 11.1. Additional iCalendar Registrations 1183 11.1.1. Properties 1185 This document defines the following new iCalendar properties to be 1186 added to the registry defined in Section 8.2.3 of [RFC5545]: 1188 +---------------------+---------+----------------------+ 1189 | Property | Status | Reference | 1190 +---------------------+---------+----------------------+ 1191 | CALENDAR-ADDRESS | Current | RFCXXXX, Section 6.2 | 1192 | PARTICIPANT-TYPE | Current | RFCXXXX, Section 6.1 | 1193 | STRUCTURED-DATA | Current | RFCXXXX, Section 6.6 | 1194 | STYLED-DESCRIPTION | Current | RFCXXXX, Section 6.3 | 1195 | STRUCTURED-LOCATION | Current | RFCXXXX, Section 6.4 | 1196 | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 6.5 | 1197 +---------------------+---------+----------------------+ 1199 11.1.2. Parameters 1201 This document defines the following new iCalendar property parameters 1202 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 1204 +--------------------+---------+----------------------+ 1205 | Property Parameter | Status | Reference | 1206 +--------------------+---------+----------------------+ 1207 | LOCTYPE | Current | RFCXXXX, Section 5.1 | 1208 | ORDER | Current | RFCXXXX, Section 5.3 | 1209 | RESTYPE | Current | RFCXXXX, Section 5.2 | 1210 | SCHEMA | Current | RFCXXXX, Section 5.4 | 1211 +--------------------+---------+----------------------+ 1213 11.1.3. Components 1215 This document defines the following new iCalendar components to be 1216 added to the registry defined in Section 8.3.1 of [RFC5545]: 1218 +-------------+---------+----------------------+ 1219 | Component | Status | Reference | 1220 +-------------+---------+----------------------+ 1221 | PARTICIPANT | Current | RFCXXXX, Section 7.1 | 1222 +-------------+---------+----------------------+ 1224 11.2. New Registration Tables 1226 This section defines new registration tables for PARTICIPANT-TYPE and 1227 RESTYPE values. These tables are updated using the same approaches 1228 laid down in Section 8.2.1 of [RFC5545] 1230 11.2.1. Participant Types 1232 The following table has been used to initialize the participant types 1233 registry. 1235 +-------------------+---------+----------------------+ 1236 | Participant Type | Status | Reference | 1237 +-------------------+---------+----------------------+ 1238 | ACTIVE | Current | RFCXXXX, Section 6.1 | 1239 | INACTIVE | Current | RFCXXXX, Section 6.1 | 1240 | SPONSOR | Current | RFCXXXX, Section 6.1 | 1241 | CONTACT | Current | RFCXXXX, Section 6.1 | 1242 | BOOKING-CONTACT | Current | RFCXXXX, Section 6.1 | 1243 | EMERGENCY-CONTACT | Current | RFCXXXX, Section 6.1 | 1244 | PUBLICITY-CONTACT | Current | RFCXXXX, Section 6.1 | 1245 | PLANNER-CONTACT | Current | RFCXXXX, Section 6.1 | 1246 | PERFORMER | Current | RFCXXXX, Section 6.1 | 1247 | SPEAKER | Current | RFCXXXX, Section 6.1 | 1248 +-------------------+---------+----------------------+ 1250 11.2.2. Resource Types 1252 The following table has been used to initialize the resource types 1253 registry. 1255 +-------------------------+---------+----------------------+ 1256 | Resource Type | Status | Reference | 1257 +-------------------------+---------+----------------------+ 1258 | PROJECTOR | Current | RFCXXXX, Section 5.2 | 1259 | ROOM | Current | RFCXXXX, Section 5.2 | 1260 | REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 5.2 | 1261 | REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 5.2 | 1262 +-------------------------+---------+----------------------+ 1264 12. Acknowledgements 1266 The author would like to thank Chuck Norris of eventful.com for his 1267 work which led to the development of this RFC. 1269 The author would also like to thank the members of CalConnect, The 1270 Calendaring and Scheduling Consortium, the Event Publication 1271 technical committee and the following individuals for contributing 1272 their ideas and support: 1274 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis. 1276 13. References 1278 13.1. Normative References 1280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1281 Requirement Levels", BCP 14, RFC 2119, 1282 DOI 10.17487/RFC2119, March 1997, 1283 . 1285 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 1286 RFC 2426, DOI 10.17487/RFC2426, September 1998, 1287 . 1289 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1290 Resource Identifier (URI): Generic Syntax", STD 66, 1291 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1292 . 1294 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1295 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 1296 . 1298 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1299 Scheduling Core Object Specification (iCalendar)", 1300 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1301 . 1303 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1304 Interoperability Protocol (iTIP)", RFC 5546, 1305 DOI 10.17487/RFC5546, December 2009, 1306 . 1308 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 1309 DOI 10.17487/RFC7986, October 2016, 1310 . 1312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1314 May 2017, . 1316 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1317 Interchange Format", STD 90, RFC 8259, 1318 DOI 10.17487/RFC8259, December 2017, 1319 . 1321 [W3C.REC-html51-20171003] 1322 Faulkner, S., Eicholz, A., Leithead, T., and A. Danilo, 1323 "HTML 5.1 2nd Edition", World Wide Web Consortium 1324 Recommendation REC-html51-20171003, October 2017, 1325 . 1327 [W3C.REC-xml-20081126] 1328 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1329 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1330 Edition)", World Wide Web Consortium Recommendation REC- 1331 xml-20081126, November 2008, 1332 . 1334 13.2. Informative References 1336 [iana-property-registry] 1337 "IANA iCalendar Element Registries", 1338 . 1341 Appendix A. Open issues 1343 None at the moment 1345 Appendix B. Change log 1347 To be deleted on publication 1349 calext-v14 2019-06-11 MD 1350 o Definition of event and social calendaring. 1352 o Remove redefinition of SOURCE - use STRUCTURED-DATA. 1354 calext-v13 2019-05-26 MD 1356 o Respond to various issues. 1358 calext-v12 2019-02-28 MD 1360 o Fix styled-description example. Respond to various AD issues. 1361 Some typos. 1363 calext-v11 2019-02-27 MD 1365 o Add DERIVED parameter for styled-description, RELATED parameter 1366 for structured-location 1368 calext-v09 2018-08-30 MD 1370 o Sorted out inconsistencies in refs to 5546 1372 calext-v08 2018-07-06 MD 1374 o Add some text for equal ORDER values 1376 o Switched scheduleaddress to calendaraddress in participant abnf. 1377 Also added more properties 1379 o Fixed PARTICIPANT abnf 1381 calext-v04 2017-10-11 MD 1383 o Change SCHEDULE-ADDRESS to CALENDAR-ADDRESS 1385 o Explicitly broaden scope of SOURCE 1387 o Add initial registry for RESTYPE and move new tables into separate 1388 section. 1390 o Fix PARTTYPE/PARTICIPANT-TYPE inconsistency 1392 calext-v03 2017-10-09 MD 1394 o Mostly typographical and other minor changes 1396 calext-v02 2017-04-20 MD 1397 o Add SCHEDULE-ADDRESS property 1399 o PARTICIPANT becomes a component rather than a property. Turn many 1400 of the former parameters into properties. 1402 o Use existing ATTENDEE property for scheduling. 1404 calext-v01 2017-02-18 MD 1406 o Change ASSOCIATE back to PARTICIPANT 1408 o PARTICIPANT becomes a component rather than a property. Turn many 1409 of the former parameters into properties. 1411 calext-v00 2016-08-?? MD 1413 o Name changed - taken up by calext working group 1415 v06 2016-06-26 MD 1417 o Fix up abnf 1419 o change ref to ietf from daboo 1421 o take out label spec - use Cyrus spec 1423 v05 2016-06-14 MD 1425 o Remove GROUP and HASH. they can be dealt with elsewhere if desired 1427 o Change ORDER to integer >= 1. 1429 o Incorporate Structured-Data into this specification. 1431 v04 2014-02-01 MD 1433 o Added updates attribute. 1435 o Minor typos. 1437 o Resubmitted mostly to refresh the draft. 1439 v03 2013-03-06 MD 1441 o Replace PARTICIPANT with ASSOCIATE plus related changes. 1443 o Added section showing modifications to components. 1445 o Replace ID with GROUP and modify HASH. 1447 o Replace TITLE param with LABEL. 1449 o Fixed STYLED-DESCRIPTION in various ways, correct example. 1451 v02 2012-11-02 MD 1453 o Collapse sections with description of properties and the use cases 1454 into a section with sub-sections. 1456 o New section to describe relating properties. 1458 o Remove idref and upgrade hash to have the reference 1460 o No default value types on properties.. 1462 v01 2012-10-18 MD Many changes. 1464 o SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT 1466 o Add a STRUCTURED-RESOURCE property 1468 o STYLED-DESCRIPTION to handle rich text 1470 o Much more... 1472 2011-01-07 1474 o Remove MEDIA - it's going in the Cyrus RFC 1476 o Rename EXTENDED-... to STRUCTURED-... 1478 o Add TYPE parameter to SPONSOR 1480 v00 2007-10-19 MD Initial version 1482 Author's Address 1484 Michael Douglass 1485 Spherical Cow Group 1486 226 3rd Street 1487 Troy, NY 12180 1488 USA 1490 Email: mdouglass@sphericalcowgroup.com 1491 URI: http://sphericalcowgroup.com