5Internet Engineering Task Force (IETF) M. Douglass
6Request for Comments: 9073 Bedework
7Updates: 5545 August 2021
8Category: Standards Track
12 Event Publishing Extensions to iCalendar
16 This specification updates RFC 5545 by introducing a number of new
17 iCalendar properties and components that are of particular use for
18 event publishers and in social networking.
20 This specification also defines a new "STRUCTURED-DATA" property for
21 iCalendar (RFC 5545) to allow for data that is directly pertinent to
22 an event or task to be included with the calendar data.
26 This is an Internet Standards Track document.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc9073.
40 Copyright (c) 2021 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.
56 1.1. Conventions Used in This Document
57 1.2. Terms Used in This Document
58 2. Components and Properties
61 3.1.1. Piano Concert Performance
63 3.1.2.1. Reserving Facilities
64 4. Modifications to Calendar Components
65 5. New Property Parameters
74 6.5. Styled-Description
78 7.1.1. Schedulable Participant
84 9. Security Considerations
86 9.2. Malicious Content
88 10. Privacy Considerations
90 10.2. Revealing Locations
91 11. IANA Considerations
92 11.1. Additional iCalendar Registrations
96 11.2. Participant Types and Resource Types Registries
97 11.2.1. Participant Types
98 11.2.2. Resource Types
99 12. Normative References
105 The currently existing iCalendar standard [RFC5545] lacks useful
106 methods for referencing additional, external information relating to
107 calendar components. Additionally, there is no standard way to
108 provide rich-text descriptions or metadata associated with the event.
110 Current practice is to embed this information as links in the
111 description or to add nonstandard properties, as defined in
112 Section 3.8.8.2 of [RFC5545].
114 This document updates [RFC5545] to define a number of properties and
115 components referencing such external information that can provide
116 additional information about an iCalendar component. The intent is
117 to allow the 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 [RFC6350], 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.
1231.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
128 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
129 capitals, as shown here.
131 The notation used in this memo is the ABNF notation of [RFC5234] as
132 used by iCalendar [RFC5545]. Any syntax elements shown below that
133 are not explicitly defined in this specification come from iCalendar
1361.2. Terms Used in This Document
138 Event: When the word 'event' (perhaps with a capitalized 'E') is
139 used, we are referring to gatherings, formal or informal (for
140 example, a sports event, a party, or a concert).
142 Social Calendaring: Historically, calendar data and scheduling has
143 been heavily biased towards meetings in a corporate environment.
144 Some of the features defined in this document are to support a
145 more informal, i.e., social, model. For example, we may want to
146 record who is participating in a public event.
1482. Components and Properties
150 Previous extensions to the calendaring standards have been largely
151 restricted to the addition of properties or parameters. This is
152 partly because iCalendar libraries had trouble handling components
153 nested deeper than those defined in [RFC5545].
155 In a break with this 'convention', this specification defines a
156 number of components rather than properties. This is a better match
157 for the way [W3C.REC-xml-20081126] and JSON [RFC8259] handle such
158 structures and allows richer definitions.
160 It also allows for the addition of extra properties inside the
161 components and resolves some of the problems of trying to add
162 detailed information as a parameter.
166 The properties and components defined here can all reference external
167 metadata, which may be used by applications to provide further
168 information to users. By providing type information, clients and
169 servers are able to discover interesting references and make use of
170 them, perhaps for indexing or presenting additional, related
171 information for the user.
173 As always, clients should exercise caution in following references to
176 The "LOCATION" property [RFC5545] provides only an unstructured
177 single text value for specifying the location where an event (or
178 task) will occur. This is inadequate for use cases where structured
179 location information (e.g., address, region, country, or postal code)
180 is required or preferred and limits widespread adoption of iCalendar
183 Using the "VLOCATION" component, rich information about multiple
184 locations can be communicated in a "STRUCTURED-DATA" property;
185 examples include address, region, country, postal code, parking
186 availability, nearby restaurants, and the venue, among others.
187 Servers and clients can retrieve the objects when storing the event
188 and use them to index by geographic location.
190 When a calendar client receives a calendar component, it can search
191 the set of locations looking for those of particular interest. The
192 "LOCATION-TYPE" property and "FMTTYPE" parameter applied to the
193 "STRUCTURED-DATA" property, if supplied, can be used to help the
196 The "PARTICIPANT" component is designed to handle common use cases in
197 event publication. It is generally important to provide information
198 about the organizers of such events. Sponsors wish to be referenced
199 in a prominent manner. In social calendaring, it is often important
200 to identify the active participants (e.g,, a school sports team) and
201 the inactive participants (e.g., the parents) in the event.
203 The "PARTICIPANT" component can be used to provide useful extra data
204 about an attendee. For example, a location inside the PARTICIPANT
205 gives the actual location of a remote attendee. (But see the note
208 Alternatively, the "PARTICIPANT" component can be used to provide a
209 reference -- perhaps the address for mailing lists.
213 The main motivation for these changes has been event publication, but
214 there are opportunities for use elsewhere. The following use cases
215 will describe some possible scenarios.
2173.1.1. Piano Concert Performance
219 In putting together a concert, there are many participants: piano
220 tuner, performer, stage hands, etc. In addition, there are sponsors
221 and various contacts to be provided. There will also be a number of
222 related locations. A number of events can be created, all of which
223 relate to the performance in different ways.
225 There may be an iCalendar Transport-independent Interoperability
226 Protocol (iTIP) [RFC5546] meeting request for the piano tuner, who
227 will arrive before the performance. Other members of staff may also
228 receive meeting requests.
230 An event can also be created for publication, which will have a
231 "PARTICIPANT" component for the pianist providing a reference to
232 vCard information ([RFC6350]) about the performer. This event would
233 also hold information about parking, local subway stations, and the
234 venue itself. In addition, there may be sponsorship information for
235 sponsors of the event and perhaps paid sponsorship properties,
236 essentially advertising local establishments.
240 These additions also provide opportunities for the travel industry.
241 When booking a flight, the "PARTICIPANT" component can be used to
242 provide references to businesses at the airports and to rental car
243 businesses at the destination.
245 The embedded location information can guide the traveler around the
246 airport itself or to their final destination. The contact
247 information can provide detailed information about the booking agent,
248 airlines, car hire companies, and hotel.
2503.1.2.1. Reserving Facilities
252 For a meeting, the size of a room and the equipment needed depends,
253 to some extent, on the number of attendees actually in the room.
255 A meeting may have many attendees, none of which are co-located. The
256 current "ATTENDEE" property does not allow for the addition of such
257 metadata. The "PARTICIPANT" component allows attendees to specify
2604. Modifications to Calendar Components
262 The following changes to the syntax defined in iCalendar [RFC5545]
263 are made here. New elements are defined in subsequent sections.
265 ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
266 ; as valid components
267 eventc = "BEGIN" ":" "VEVENT" CRLF
268 eventprop *alarmc *participantc *locationc *resourcec
269 "END" ":" "VEVENT" CRLF
271 ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
272 eventprop =/ *styleddescription
275 ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
276 ; as valid components
277 todoc = "BEGIN" ":" "VTODO" CRLF
278 todoprop *alarmc *participantc *locationc *resourcec
279 "END" ":" "VTODO" CRLF
281 ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
282 todoprop =/ *styleddescription
285 ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
286 ; as valid components
287 journalc = "BEGIN" ":" "VJOURNAL" CRLF
288 jourprop *participantc *locationc *resourcec
289 "END" ":" "VJOURNAL" CRLF
291 ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
292 jourprop =/ *styleddescription
295 ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
296 ; as valid components
297 freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
298 fbprop *participantc *locationc *resourcec
299 "END" ":" "VFREEBUSY" CRLF
301 ; Addition of property STYLED-DESCRIPTION
302 fbprop =/ *styleddescription
3045. New Property Parameters
308 Parameter name: ORDER
310 Purpose: This parameter defines ordering for the associated
313 Format Definition: This parameter is defined by the following
316 orderparam = "ORDER" "=" integer
317 ; Must be greater than or equal to 1
319 Description: The "ORDER" parameter is OPTIONAL and is used to
320 indicate the relative ordering of the corresponding instance of a
321 property. Its value MUST be an integer greater than or equal to 1
322 that specifies the order, with 1 being the first in the ordering.
324 When the parameter is absent, the default MUST be to interpret the
325 property instance as being ordered last, that is, the property
326 will appear after any other instances of the same property with
329 When any "ORDER" parameters have the same value, all the
330 associated properties appear as a group within which there is no
333 Note that the value of this parameter is to be interpreted only in
334 relation to values assigned to other corresponding instances of
335 the same property in the same entity.
337 This parameter MUST NOT be applied to a property that does not
338 allow multiple instances.
340 Example uses: The ORDER may be applied to the "PARTICIPANT-TYPE"
341 property to indicate the relative importance of the participant,
342 for example, as a sponsor or a performer. For example, ORDER=1
343 could define the principal performer or soloist.
347 Parameter Name: SCHEMA
349 Purpose: This parameter specifies the schema used for the content of
350 a "STRUCTURED-DATA" property value.
352 Format Definition: This parameter is defined by the following
355 schemaparam = "SCHEMA" "=" DQUOTE uri DQUOTE
357 Description: This property parameter SHOULD be specified on
358 "STRUCTURED-DATA" properties. When present, it provides
359 identifying information about the nature of the content of the
360 corresponding "STRUCTURED-DATA" property value. This can be used
361 to supplement the media type information provided by the "FMTTYPE"
362 parameter on the corresponding property.
365 STRUCTURED-DATA;FMTTYPE=application/ld+json;
366 SCHEMA="https://schema.org/FlightReservation";
367 ENCODING=BASE64;VALUE=BINARY:ICAgIDxzY3JpcHQgdHlwZT0iYXBwb
368 GljYXRpb24vbGQranNvbiI+CiAgICB7CiAgICAgICJAY29
369 udGV4dCI6ICJodHRwOi8vc2NoZW1hLm9yZyIsCiAgICAgICJAdHlwZSI
370 6ICJGbGlnaHRSZXNlcnZhdGlvbiIsCiAgICAgICJyZXNlcnZhdGlvbkl
371 kIjogIlJYSjM0UCIsCiAgICAgICJyZXNlcnZhdGlvblN0YXR1cyI6ICJ
372 odHRwOi8vc2NoZW1hLm9yZy9SZXNlcnZhdGlvbkNvbmZpcm1lZCIsCiA
373 gICAgICJwYXNzZW5nZXJQcmlvcml0eVN0YXR1cyI6ICJGYXN0IFRyYWN
374 rIiwKICAgICAgInBhc3NlbmdlclNlcXVlbmNlTnVtYmVyIjogIkFCQzE
375 yMyIsCiAgICAgICJzZWN1cml0eVNjcmVlbmluZyI6ICJUU0EgUHJlQ2h
376 lY2siLAogICAgICAidW5kZXJOYW1lIjogewogICAgICAgICJAdHlwZSI
377 6ICJQZXJzb24iLAogICAgICAgICJuYW1lIjogIkV2YSBHcmVlbiIKICA
378 gICAgfSwKICAgICAgInJlc2VydmF0aW9uRm9yIjogewogICAgICAgICJ
379 AdHlwZSI6ICJGbGlnaHQiLAogICAgICAgICJmbGlnaHROdW1iZXIiOiA
380 iVUExMTAiLAogICAgICAgICJwcm92aWRlciI6IHsKICAgICAgICAgICJ
381 AdHlwZSI6ICJBaXJsaW5lIiwKICAgICAgICAgICJuYW1lIjogIkNvbnR
382 pbmVudGFsIiwKICAgICAgICAgICJpYXRhQ29kZSI6ICJDTyIsCiAgICA
383 gICAgICAiYm9hcmRpbmdQb2xpY3kiOiAiaHR0cDovL3NjaGVtYS5vcmc
384 vWm9uZUJvYXJkaW5nUG9saWN5IgogICAgICAgIH0sCiAgICAgICAgInN
385 lbGxlciI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJsaW5lIiwKICA
386 gICAgICAgICJuYW1lIjogIlVuaXRlZCIsCiAgICAgICAgICAiaWF0YUN
387 vZGUiOiAiVUEiCiAgICAgICAgfSwKICAgICAgICAiZGVwYXJ0dXJlQWl
388 ycG9ydCI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJwb3J0IiwKICA
389 gICAgICAgICJuYW1lIjogIlNhbiBGcmFuY2lzY28gQWlycG9ydCIsCiA
390 gICAgICAgICAiaWF0YUNvZGUiOiAiU0ZPIgogICAgICAgIH0sCiAgICA
391 gICAgImRlcGFydHVyZVRpbWUiOiAiMjAxNy0wMy0wNFQyMDoxNTowMC0
392 wODowMCIsCiAgICAgICAgImFycml2YWxBaXJwb3J0IjogewogICAgICA
393 gICAgIkB0eXBlIjogIkFpcnBvcnQiLAogICAgICAgICAgIm5hbWUiOiA
394 iSm9obiBGLiBLZW5uZWR5IEludGVybmF0aW9uYWwgQWlycG9ydCIsCiA
395 gICAgICAgICAiaWF0YUNvZGUiOiAiSkZLIgogICAgICAgIH0sCiAgICA
396 gICAgImFycml2YWxUaW1lIjogIjIwMTctMDMtMDVUMDY6MzA6MDAtMDU
397 6MDAiCiAgICAgIH0KICAgIH0KICAgIDwvc2NyaXB0Pg==
401 Parameter Name: DERIVED
403 Purpose: This parameter specifies that the value of the associated
404 property is derived from some other property value or values.
406 Format Definition: This parameter is defined by the following
409 derivedparam = "DERIVED" "=" ("TRUE" / "FALSE")
412 Description: This property parameter MAY be specified on any
413 property when the value is derived from some other property or
414 properties. When present with a value of TRUE, clients MUST NOT
417 As an example, if a "STYLED-DESCRIPTION" property is present with
418 FMTTYPE="application/rtf", then there may be an additional
419 "STYLED-DESCRIPTION" property with FMTTYPE="text/html" and
420 DERIVED=TRUE, as well as a value created from the rtf value.
423 STYLED-DESCRIPTION;FMTTYPE=text/html;
424 DERIVED=TRUE:<html>...</html>
428 This specification makes use of the "NAME" property, which is defined
433 Property Name: LOCATION-TYPE
435 Purpose: This property specifies the type(s) of a location.
437 Value Type: The value type for this property is TEXT. The allowable
438 values are defined below.
440 Description: This property MAY be specified in "VLOCATION"
441 components and provides a way to differentiate multiple locations.
442 For example, it allows event producers to provide location
443 information for the venue and the parking.
445 Format Definition: This property is defined by the following
448 loctype = "LOCATION-TYPE" loctypeparam ":"
452 loctypeparam = *(";" other-param)
454 Multiple values may be used if the location has multiple purposes,
455 for example, a hotel and a restaurant.
457 Values for this parameter are taken from the values defined in
458 Section 3 of [RFC4589]. New location types SHOULD be registered
459 in the manner laid down in Section 5 of [RFC4589].
463 Property Name: PARTICIPANT-TYPE
465 Purpose: This property specifies the type of participant.
467 Value Type: The value type for this property is TEXT. The allowable
468 values are defined below.
470 Property Parameters: Nonstandard parameters can be specified on this
473 Conformance: This property MUST be specified once within a
474 "PARTICIPANT" component.
476 Description: This property defines the type of participation in
477 events or tasks. Participants can be individuals or
478 organizations, for example, a soccer team, the spectators, or the
481 Format Definition: This property is defined by the following
484 participanttype = "PARTICIPANT-TYPE" partvalueparam ":"
487 partvalue = ("ACTIVE"
492 / "EMERGENCY-CONTACT"
493 / "PUBLICITY-CONTACT"
497 / iana-token) ; Other IANA-registered
500 partvalueparam = *(";" other-param)
502 Example: The following is an example of this property.
504 PARTICIPANT-TYPE:SPEAKER
506 The registered values for the "PARTICIPANT-TYPE" property have the
507 meanings described here:
509 ACTIVE: A participant taking an active role -- for example, a team
512 INACTIVE: A participant taking an inactive role -- for example, an
515 SPONSOR: A sponsor of the event. The "ORDER" parameter may be used
516 with this participant type to define the relative order of
519 CONTACT: Contact information for the event. The "ORDER" parameter
520 may be used with this participant type to define the relative
521 order of multiple contacts.
523 BOOKING-CONTACT: Contact information for reservations or payment.
525 EMERGENCY-CONTACT: Contact in case of emergency.
527 PUBLICITY-CONTACT: Contact for publicity.
529 PLANNER-CONTACT: Contact for the event planner or organizer.
531 PERFORMER: A performer -- for example, the soloist or the
532 accompanist. The "ORDER" parameter may be used with this
533 participant type to define the relative order of multiple
534 performers. For example, ORDER=1 could define the principal
535 performer or soloist.
537 SPEAKER: Speaker at an event.
541 Property Name: RESOURCE-TYPE
543 Purpose: This property specifies the type of resource.
545 Value Type: The value type for this property is TEXT. The allowable
546 values are defined below.
548 Format Definition: This property is defined by the following
551 restypeprop = "RESOURCE-TYPE" restypeparam ":"
554 restypevalue = ("ROOM"
556 / "REMOTE-CONFERENCE-AUDIO"
557 / "REMOTE-CONFERENCE-VIDEO"
558 / iana-token) ; Other IANA-registered
561 restypeparam = *(";" other-param)
563 Description: This property MAY be specified in "VRESOURCE"
564 components and provides a way to differentiate multiple resources.
566 The registered values are described below. New resource types
567 SHOULD be registered in the manner laid down in this
570 ROOM: A room for the event/meeting.
572 PROJECTOR: Projection equipment.
574 REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities.
576 REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities.
580 Property Name: CALENDAR-ADDRESS
582 Purpose: This property specifies the calendar address for a
585 Value Type: CAL-ADDRESS
587 Property Parameters: IANA-registered or nonstandard property
588 parameters can be specified on this property.
590 Conformance: This property MAY be specified once within a
591 "PARTICIPANT" component.
593 Description: This property provides a calendar user address for the
594 participant. If there is an "ATTENDEE" property with the same
595 value, then the participant is schedulable.
597 Format Definition: This property is defined by the following
600 calendaraddress = "CALENDAR-ADDRESS" caladdressparam ":"
603 caladdressparam = *(";" other-param)
6056.5. Styled-Description
607 Property Name: STYLED-DESCRIPTION
609 Purpose: This property provides for one or more rich-text
610 descriptions to replace that provided by the "DESCRIPTION"
613 Value Type: There is no default value type for this property. The
614 value type can be set to URI or TEXT. Other text-based value
615 types can be used when defined in the future. Clients MUST ignore
616 any properties with value types they do not understand.
618 Property Parameters: IANA-registered, nonstandard, id, alternate
619 text representation, format type, derived, and language property
620 parameters can be specified on this property.
622 Conformance: The property can be specified multiple times in the
623 "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", "PARTICIPANT", or
624 "VALARM" calendar components.
626 If it does appear more than once, there MUST be exactly one
627 instance of the property with no "DERIVED" parameter or
628 DERIVED=FALSE. All others MUST have DERIVED=TRUE.
630 Additionally, if there is one or more "STYLED-DESCRIPTION"
631 property, then the "DESCRIPTION" property should either be absent
632 or have the parameter DERIVED=TRUE.
634 Description: This property supports rich-text descriptions, for
635 example, HTML. Event publishers typically wish to provide more
636 and better-formatted information about the event.
638 This property is used in the "VEVENT" and "VTODO" components to
639 capture lengthy textual descriptions associated with the activity.
640 This property is used in the "VJOURNAL" calendar component to
641 capture one or more textual journal entries. This property is
642 used in the "VALARM" calendar component to capture the display
643 text for a DISPLAY category of alarm and to capture the body text
644 for an EMAIL category of alarm. In the "PARTICIPANT" component,
645 it provides a detailed description of the participant.
647 VALUE=TEXT is used to provide rich text inline as the property
650 VALUE=URI is used to provide a link to rich-text content, which is
651 expected to be displayed inline as part of the event.
653 In either case, the "DESCRIPTION" property should be absent or
654 contain a plain-text rendering of the styled text.
656 Applications MAY attempt to guess the media type of the resource
657 via inspection of its content if and only if the media type of the
658 resource is not given by the "FMTTYPE" parameter. If the media
659 type remains unknown, calendar applications SHOULD treat it as
660 type "text/html" and process the content as defined in
661 [W3C.REC-html51-20171003].
663 Multiple "STYLED-DESCRIPTION" properties may be used to provide
664 different formats or different language variants. However, all
665 but one MUST have DERIVED=TRUE.
667 Format Definition: This property is defined by the following
670 styleddescription = "STYLED-DESCRIPTION" styleddescparam ":"
674 ; The following is REQUIRED
675 ; but MUST NOT occur more than once.
677 (";" "VALUE" "=" ("URI" / "TEXT")) /
679 ; The following are OPTIONAL
680 ; but MUST NOT occur more than once.
682 (";" altrepparam) / (";" languageparam) /
683 (";" fmttypeparam) / (";" derivedparam) /
685 ; The following is OPTIONAL
686 ; and MAY occur more than once.
691 styleddescval = ( uri / text )
692 ;Value MUST match value type
694 Example: The following is an example of this property. It points to
697 STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html
701 Property Name: STRUCTURED-DATA
703 Purpose: This property specifies ancillary data associated with the
706 Value Type: There is no default value type for this property. The
707 value type can be set to TEXT, BINARY, or URI.
709 Property Parameters: IANA-registered, nonstandard, inline encoding,
710 and value data type property parameters can be specified on this
711 property. The format type and schema parameters can be specified
712 on this property and MUST be present for text or inline binary
713 encoded content information.
715 Conformance: This property can be specified multiple times in an
716 iCalendar object. Typically, it would be used in the "VEVENT",
717 "VTODO", or "VJOURNAL" calendar components.
719 Description: The existing properties in iCalendar cover key elements
720 of events and tasks, such as start time, end time, location,
721 summary, etc. However, different types of events often have other
722 specific "fields" that are useful to include in the calendar data.
723 For example, an event representing an airline flight could include
724 the airline, flight number, departure and arrival airport codes,
725 check-in and gate-closing times, etc. As another example, a
726 sporting event might contain information about the type of sport,
727 the home and away teams, the league the teams are in, information
728 about nearby parking, etc.
730 This property is used to specify ancillary data in some structured
731 format, either directly (inline) as a "TEXT" or "BINARY" value or
732 as a link via a "URI" value.
734 Rather than define new iCalendar properties for the variety of
735 event types that might occur, it would be better to leverage
736 existing schemas for such data. For example, schemas available at
737 <https://schema.org> include different event types. By using
738 standard schemas, interoperability can be improved between
739 calendar clients and noncalendaring systems that wish to generate
742 This property allows the direct inclusion of ancillary data whose
743 schema is defined elsewhere. This property also includes
744 parameters to clearly identify the type of the schema being used
745 so that clients can quickly and easily spot what is relevant
746 within the calendar data and present that to users or process it
747 within the calendaring system.
749 iCalendar does support an "ATTACH" property, which can be used to
750 include documents or links to documents within the calendar data.
751 However, that property does not allow data to be included as a
752 "TEXT" value (a feature that "STRUCTURED-DATA" does allow), plus
753 attachments are often treated as "opaque" data to be processed by
754 some other system rather than the calendar client. Thus, the
755 existing "ATTACH" property is not sufficient to cover the specific
756 needs of inclusion of schema data. Extending the "ATTACH"
757 property to support a new value type would likely cause
758 interoperability problems. Additionally, some implementations
759 manage attachments by stripping them out and replacing with a link
760 to the resource. Thus, a new property to support inclusion of
761 schema data is warranted.
763 Format Definition: This property is defined by the following
766 sdataprop = "STRUCTURED-DATA" sdataparam
768 ";" "VALUE" "=" "TEXT"
772 ";" "ENCODING" "=" "BASE64"
773 ";" "VALUE" "=" "BINARY"
777 ";" "VALUE" "=" "URI"
784 ; The following is OPTIONAL for a URI value,
785 ; REQUIRED for a TEXT or BINARY value,
786 ; and MUST NOT occur more than once.
791 ; The following is OPTIONAL
792 ; and MAY occur more than once.
798 Example: The following is an example of this property.
800 STRUCTURED-DATA;FMTTYPE=application/ld+json;
801 SCHEMA="https://schema.org/SportsEvent";
803 "@context": "http://schema.org"\,\n
804 "@type": "SportsEvent"\,\n
805 "homeTeam": "Pittsburgh Pirates"\,\n
806 "awayTeam": "San Francisco Giants"\n
813 Component name: PARTICIPANT
815 Purpose: This component provides information about a participant in
818 Conformance: This component can be specified multiple times in a
819 "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.
821 Description: This component provides information about a participant
822 in a calendar component. A participant may be an attendee in a
823 scheduling sense, and the "ATTENDEE" property may be specified in
824 addition. Participants can be individuals or organizations, for
825 example, a soccer team, the spectators, or the musicians.
827 "STRUCTURED-DATA" properties, if present, may refer to definitions
828 of the participant -- such as a vCard.
830 The "CALENDAR-ADDRESS" property, if present, will provide a cal-
831 address. If an "ATTENDEE" property has the same value, the
832 participant is considered schedulable. The "PARTICIPANT"
833 component can be used to contain additional metadata related to
836 Format Definition: This component is defined by the following
839 participantc = "BEGIN" ":" "PARTICIPANT" CRLF
840 partprop *locationc *resourcec
841 "END" ":" "PARTICIPANT" CRLF
845 ; The following are REQUIRED
846 ; but MUST NOT occur more than once.
848 participanttype / uid /
850 ; The following are OPTIONAL
851 ; but MUST NOT occur more than once.
853 calendaraddress / created / description / dtstamp /
854 geo / last-mod / priority / seq /
855 status / summary / url /
857 ; The following are OPTIONAL
858 ; and MAY occur more than once.
860 attach / categories / comment
861 contact / location / rstatus / related /
862 resources / strucloc / strucres /
863 styleddescription / sdataprop / iana-prop
867 Note: When the "PRIORITY" property is supplied, it defines the
868 ordering of "PARTICIPANT" components with the same value for the
869 "PARTICIPANT-TYPE" property.
871 Privacy Issues: When a "LOCATION" property is supplied, it provides
872 information about the location of a participant at a given time or
873 times. This may represent an unacceptable privacy risk for some
874 participants. User agents MUST NOT broadcast this information
875 without the express permission of the participants whose location
876 would be exposed. For further comments, see Section 10.
878 Example: The following is an example of this component. It contains
879 a "STRUCTURED-DATA" property that points to a vCard providing
880 information about the event participant.
883 UID: em9lQGZvb2GFtcGxlLmNvbQ
884 PARTICIPANT-TYPE:PERFORMER
885 STRUCTURED-DATA;VALUE=URI:
886 http://dir.example.com/vcard/aviolinist.vcf
889 Example: The following is an example for the primary contact.
892 UID: em9lQGZvb2GFtcGxlLmNvbQ
893 STRUCTURED-DATA;VALUE=URI;
894 http://dir.example.com/vcard/contacts/contact1.vcf
895 PARTICIPANT-TYPE:CONTACT
896 DESCRIPTION:A contact
899 Example: The following is an example for a participant with contact
903 UID: em9lQGZvb2GFtcGxlLmNdrt
904 STRUCTURED-DATA;VALUE=URI;
905 http://dir.example.com/vcard/contacts/my-card.vcf
906 PARTICIPANT-TYPE:SPEAKER
907 DESCRIPTION:A participant
909 UID:123456-abcdef-98765432
910 NAME:My home location
911 STRUCTURED-DATA;VALUE=URI:
912 http://dir.example.com/addresses/my-home.vcf
9167.1.1. Schedulable Participant
918 A "PARTICIPANT" component may represent someone or something that
919 needs to be scheduled, as defined for ATTENDEE in [RFC5545] and
920 [RFC5546]. The "PARTICIPANT" component may also represent someone or
921 something that is NOT to receive scheduling messages.
923 For backwards compatibility with existing clients and servers when
924 used to schedule events and tasks, the "ATTENDEE" property MUST be
925 used to specify the scheduling parameters as defined for that
928 For other, future uses, the "CALENDAR-ADDRESS" property MUST be used
929 to specify those parameters.
931 A "PARTICIPANT" component is defined to be schedulable if:
933 * it contains a "CALENDAR-ADDRESS" property and
935 * that property value is the same as the value for an "ATTENDEE"
938 If both of these conditions apply, then the participant defined by
939 the value of the URL property will take part in scheduling
940 operations, as defined in [RFC5546].
942 An appropriate use for the "PARTICIPANT" component in scheduling
943 would be to store "SEQUENCE" and "DTSTAMP" properties associated with
944 replies from each "ATTENDEE" property. A "LOCATION" property within
945 the "PARTICIPANT" component might allow better selection of meeting
946 times when participants are in different time zones.
950 Component name: VLOCATION
952 Purpose: This component provides rich information about the location
953 of an event using the structured data property or, optionally, a
954 plain-text typed value.
956 Conformance: This component can be specified multiple times in a
957 "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", or "PARTICIPANT"
960 Description: There may be a number of locations associated with an
961 event. This component provides detailed information about a
964 When used in a component, the value of this property provides
965 information about the event venue or of related services, such as
966 parking, dining, stations, etc.
968 "STRUCTURED-DATA" properties, if present, may refer to
969 representations of the location -- such as a vCard.
971 Format Definition: This component is defined by the following
974 locationc = "BEGIN" ":" "VLOCATION" CRLF
976 "END" ":" "VLOCATION" CRLF
980 ; The following are REQUIRED
981 ; but MUST NOT occur more than once.
985 ; The following are OPTIONAL
986 ; but MUST NOT occur more than once.
988 description / geo / loctype / name
990 ; The following are OPTIONAL
991 ; and MAY occur more than once.
993 sdataprop / iana-prop
996 The "NAME" property is defined in [RFC7986].
998 Example: The following is an example of this component. It points
1002 UID:123456-abcdef-98765432
1004 STRUCTURED-DATA;VALUE=URI:
1005 http://dir.example.com/venues/big-hall.vcf
1010 Component name: VRESOURCE
1012 Purpose: This component provides a typed reference to external
1013 information about a resource or, optionally, a plain-text typed
1014 value. Typically, a resource is anything that might be required
1015 or used by a calendar entity and possibly has a directory entry.
1017 Conformance: This component can be specified multiple times in a
1018 "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", or "PARTICIPANT"
1021 Description: When used in a component, this component provides
1022 information about resources used for the event, such as rooms,
1023 projectors, and conferencing capabilities.
1025 The RESOURCE-TYPE value registry provides a place in which
1026 resource types may be registered.
1028 "STRUCTURED-DATA" properties, if present, may refer to
1029 representations of the resource -- such as a vCard.
1031 Format Definition: This component is defined by the following
1034 resourcec = "BEGIN" ":" "VRESOURCE" CRLF
1036 "END" ":" "VRESOURCE" CRLF
1040 ; The following are REQUIRED
1041 ; but MUST NOT occur more than once.
1045 ; The following are OPTIONAL
1046 ; but MUST NOT occur more than once.
1048 description / geo / name / restype /
1050 ; The following are OPTIONAL
1051 ; and MAY occur more than once.
1053 sdataprop / iana-prop
1056 The "NAME" property is defined in [RFC7986].
1058 Example: The following is an example of this component. It refers
1062 UID:456789-abcdef-98765432
1064 RESOURCE-TYPE:projector
1065 STRUCTURED-DATA;VALUE=URI:http://dir.example.com/projectors/3d.vcf
1070 The following are some examples of the use of the properties defined
1071 in this specification. They include additional properties defined in
1072 [RFC7986], which includes "IMAGE".
1076 The following is an example of a "VEVENT" describing a concert. It
1077 includes location information for the venue itself, as well as
1078 references to parking and restaurants.
1081 CREATED:20200215T145739Z
1082 DESCRIPTION: Piano Sonata No 3\n
1084 DTSTAMP:20200215T145739Z
1085 DTSTART;TZID=America/New_York:20200315T150000Z
1086 DTEND;TZID=America/New_York:20200315T163000Z
1087 LAST-MODIFIED:20200216T145739Z
1088 SUMMARY:Beethoven Piano Sonatas
1090 IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h
1091 ttp://example.com/images/concert.png
1093 PARTICIPANT-TYPE:SPONSOR
1094 UID:dG9tQGZvb2Jhci5xlLmNvbQ
1095 STRUCTURED-DATA;VALUE=URI:http://example.com/sponsor.vcf
1098 PARTICIPANT-TYPE:PERFORMER:
1099 UID:em9lQGZvb2GFtcGxlLmNvbQ
1100 STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/johndoe.vcf
1103 UID:123456-abcdef-98765432
1105 STRUCTURED-DATA;VALUE=URI:http://dir.example.com/venues/big-hall.vcf
1108 UID:123456-abcdef-87654321
1109 NAME:Parking for the venue
1110 STRUCTURED-DATA;VALUE=URI:http://dir.example.com/venues/parking.vcf
1116 The following is an example of a "VEVENT" describing a meeting. One
1117 of the attendees is a remote participant.
1120 CREATED:20200215T145739Z
1121 DTSTAMP:20200215T145739Z
1122 DTSTART;TZID=America/New_York:20200315T150000Z
1123 DTEND;TZID=America/New_York:20200315T163000Z
1124 LAST-MODIFIED:20200216T145739Z
1125 SUMMARY:Conference planning
1127 ORGANIZER:mailto:a@example.com
1128 ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
1129 ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com
1131 PARTICIPANT-TYPE:ACTIVE:
1132 UID:v39lQGZvb2GFtcGxlLmNvbQ
1133 STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/b.vcf
11389. Security Considerations
1140 This specification extends [RFC5545] and makes further use of
1141 possibly linked data. While calendar data is not unique in this
1142 regard, it is worth reminding implementors of some of the dangers and
1147 See [RFC3986] for a discussion of the security considerations
1148 relating to URIs. Because of the issues discussed there and below,
1149 clients SHOULD NOT follow URIs and fetch content automatically and
1150 should only do so at the explicit request of the user.
1152 Fetching remote resources carries inherent risks. Connections must
1153 only be allowed on well-known ports, using allowed protocols
1154 (generally just HTTP/HTTPS on their default ports). The URL must be
1155 resolved externally and not allowed to access internal resources.
1156 Connecting to an external source reveals IP (and therefore generally
1157 location) information.
1159 A maliciously constructed iCalendar object may contain a very large
1160 number of URIs. In the case of published calendars with a large
1161 number of subscribers, such objects could be widely distributed.
1162 Implementations should be careful to limit the automatic fetching of
1163 linked resources to reduce the risk of this being an amplification
1164 vector for a denial-of-service attack.
11669.2. Malicious Content
1168 For the "STRUCTURED-DATA" property, agents need to be aware that a
1169 client could attack underlying storage by sending extremely large
1170 values and could attack processing time by uploading a recurring
1171 event with a large number of overrides and then repeatedly adding,
1172 updating, and deleting structured data.
1174 Agents should set reasonable limits on storage size and number of
1175 instances and apply those constraints. Calendar protocols should
1176 ensure there is a way to report on such limits being exceeded.
1178 Malicious content could be introduced into the calendar server by way
1179 of the "STRUCTURED-DATA" property and propagated to many end users
1180 via scheduling. Servers SHOULD check this property for malicious or
1181 inappropriate content. Upon detecting such content, servers SHOULD
1182 remove the property.
1186 When processing HTML content, applications need to be aware of the
1187 many security and privacy issues, as described in the IANA
1188 Considerations section of [W3C.REC-html51-20171003].
119010. Privacy Considerations
1194 Properties with a "URI" value type can expose their users to privacy
1195 leaks, as any network access of the URI data can be tracked both by a
1196 network observer and by the entity hosting the remote resource.
1197 Clients SHOULD NOT automatically download data referenced by the URI
1198 without explicit instruction from users.
1200 To help alleviate some of the concerns, protocols and services could
1201 provide proxy services for downloading referenced data.
120310.2. Revealing Locations
1205 The addition of location information to the new participant component
1206 provides information about the location of participants at a given
1207 time. This information MUST NOT be distributed to other participants
1208 without those participant's express permission. Note that there may
1209 be a number of participants who may be unaware of their inclusion in
1212 Agents processing and distributing calendar data must be aware that
1213 it has the property of providing information about a future time when
1214 a given individual may be at a particular location, which could
1215 enable targeted attacks against that individual.
1217 The same may be true of other information contained in the
1218 participant component. In general, revealing only as much as is
1219 absolutely necessary should be the approach taken.
1221 For example, there may be some privacy considerations relating to the
1222 "ORDER" parameter, as it provides an indication of the organizer's
1223 perception of the relative importance of other participants.
122511. IANA Considerations
122711.1. Additional iCalendar Registrations
1231 This document defines the following iCalendar properties that have
1232 been added to the "Properties" registry defined in Section 8.2.3 of
1235 +====================+=========+=======================+
1236 | Property | Status | Reference |
1237 +====================+=========+=======================+
1238 | CALENDAR-ADDRESS | Current | RFC 9073, Section 6.4 |
1239 +--------------------+---------+-----------------------+
1240 | LOCATION-TYPE | Current | RFC 9073, Section 6.1 |
1241 +--------------------+---------+-----------------------+
1242 | PARTICIPANT-TYPE | Current | RFC 9073, Section 6.2 |
1243 +--------------------+---------+-----------------------+
1244 | RESOURCE-TYPE | Current | RFC 9073, Section 6.3 |
1245 +--------------------+---------+-----------------------+
1246 | STRUCTURED-DATA | Current | RFC 9073, Section 6.6 |
1247 +--------------------+---------+-----------------------+
1248 | STYLED-DESCRIPTION | Current | RFC 9073, Section 6.5 |
1249 +--------------------+---------+-----------------------+
1251 Table 1: Additions to the Properties Registry
1255 This document defines the following iCalendar property parameters
1256 that have been added to the "Parameters" registry defined in
1257 Section 8.2.4 of [RFC5545]:
1259 +===========+=========+=======================+
1260 | Parameter | Status | Reference |
1261 +===========+=========+=======================+
1262 | ORDER | Current | RFC 9073, Section 5.1 |
1263 +-----------+---------+-----------------------+
1264 | SCHEMA | Current | RFC 9073, Section 5.2 |
1265 +-----------+---------+-----------------------+
1266 | DERIVED | Current | RFC 9073, Section 5.3 |
1267 +-----------+---------+-----------------------+
1269 Table 2: Additions to the Parameters Registry
1273 This document defines the following iCalendar components that have
1274 been added to the "Components" registry defined in Section 8.3.1 of
1277 +=============+=========+=======================+
1278 | Component | Status | Reference |
1279 +=============+=========+=======================+
1280 | PARTICIPANT | Current | RFC 9073, Section 7.1 |
1281 +-------------+---------+-----------------------+
1282 | VLOCATION | Current | RFC 9073, Section 7.2 |
1283 +-------------+---------+-----------------------+
1284 | VRESOURCE | Current | RFC 9073, Section 7.3 |
1285 +-------------+---------+-----------------------+
1287 Table 3: Additions to the Components Registry
128911.2. Participant Types and Resource Types Registries
1291 This section defines new registration tables for PARTICIPANT-TYPE and
1292 RESOURCE-TYPE values. These tables are updated using the same
1293 approaches laid down in Section 8.2.1 of [RFC5545].
1295 This document creates new IANA registries for participant and
1296 resource types. IANA will maintain these registries and, following
1297 the policies outlined in [RFC8126], new tokens are assigned after
1298 Expert Review. The Expert Reviewer will generally consult the IETF
1299 GEOPRIV Working Group mailing list or its designated successor.
1300 Updates or deletions of tokens from the registration follow the same
1301 procedures. The Expert Review should be guided by a few common-sense
1302 considerations. For example, tokens should not be specific to a
1303 country, region, organization, or company; they should be well
1304 defined and widely recognized. The Expert's support of IANA will
1305 include providing IANA with the new token(s) when the update is
1306 provided only in the form of a schema and providing IANA with the new
1307 schema element(s) when the update is provided only in the form of a
1308 token. To ensure widespread usability across protocols, tokens MUST
1309 follow the character set restrictions for XML Names
1310 [W3C.REC-xml-20040204]. Each registration must include the name of
1311 the token and a brief description similar to the ones offered herein
1312 for the initial registrations contained this document.
131411.2.1. Participant Types
1316 +===================+=========+=======================+
1317 | Participant Type | Status | Reference |
1318 +===================+=========+=======================+
1319 | ACTIVE | Current | RFC 9073, Section 6.2 |
1320 +-------------------+---------+-----------------------+
1321 | INACTIVE | Current | RFC 9073, Section 6.2 |
1322 +-------------------+---------+-----------------------+
1323 | SPONSOR | Current | RFC 9073, Section 6.2 |
1324 +-------------------+---------+-----------------------+
1325 | CONTACT | Current | RFC 9073, Section 6.2 |
1326 +-------------------+---------+-----------------------+
1327 | BOOKING-CONTACT | Current | RFC 9073, Section 6.2 |
1328 +-------------------+---------+-----------------------+
1329 | EMERGENCY-CONTACT | Current | RFC 9073, Section 6.2 |
1330 +-------------------+---------+-----------------------+
1331 | PUBLICITY-CONTACT | Current | RFC 9073, Section 6.2 |
1332 +-------------------+---------+-----------------------+
1333 | PLANNER-CONTACT | Current | RFC 9073, Section 6.2 |
1334 +-------------------+---------+-----------------------+
1335 | PERFORMER | Current | RFC 9073, Section 6.2 |
1336 +-------------------+---------+-----------------------+
1337 | SPEAKER | Current | RFC 9073, Section 6.2 |
1338 +-------------------+---------+-----------------------+
1340 Table 4: Initial Contents of the Participant Types
134311.2.2. Resource Types
1345 +=========================+=========+=======================+
1346 | Resource Type | Status | Reference |
1347 +=========================+=========+=======================+
1348 | PROJECTOR | Current | RFC 9073, Section 6.3 |
1349 +-------------------------+---------+-----------------------+
1350 | ROOM | Current | RFC 9073, Section 6.3 |
1351 +-------------------------+---------+-----------------------+
1352 | REMOTE-CONFERENCE-AUDIO | Current | RFC 9073, Section 6.3 |
1353 +-------------------------+---------+-----------------------+
1354 | REMOTE-CONFERENCE-VIDEO | Current | RFC 9073, Section 6.3 |
1355 +-------------------------+---------+-----------------------+
1357 Table 5: Initial Contents of the Resource Types Registry
135912. Normative References
1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1362 Requirement Levels", BCP 14, RFC 2119,
1363 DOI 10.17487/RFC2119, March 1997,
1364 <https://www.rfc-editor.org/info/rfc2119>.
1366 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1367 Resource Identifier (URI): Generic Syntax", STD 66,
1368 RFC 3986, DOI 10.17487/RFC3986, January 2005,
1369 <https://www.rfc-editor.org/info/rfc3986>.
1371 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
1372 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,
1373 <https://www.rfc-editor.org/info/rfc4589>.
1375 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1376 Specifications: ABNF", STD 68, RFC 5234,
1377 DOI 10.17487/RFC5234, January 2008,
1378 <https://www.rfc-editor.org/info/rfc5234>.
1380 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
1381 Scheduling Core Object Specification (iCalendar)",
1382 RFC 5545, DOI 10.17487/RFC5545, September 2009,
1383 <https://www.rfc-editor.org/info/rfc5545>.
1385 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
1386 Interoperability Protocol (iTIP)", RFC 5546,
1387 DOI 10.17487/RFC5546, December 2009,
1388 <https://www.rfc-editor.org/info/rfc5546>.
1390 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
1391 DOI 10.17487/RFC6350, August 2011,
1392 <https://www.rfc-editor.org/info/rfc6350>.
1394 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,
1395 DOI 10.17487/RFC7986, October 2016,
1396 <https://www.rfc-editor.org/info/rfc7986>.
1398 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1399 Writing an IANA Considerations Section in RFCs", BCP 26,
1400 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1401 <https://www.rfc-editor.org/info/rfc8126>.
1403 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1404 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1405 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1407 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
1408 Interchange Format", STD 90, RFC 8259,
1409 DOI 10.17487/RFC8259, December 2017,
1410 <https://www.rfc-editor.org/info/rfc8259>.
1412 [W3C.REC-html51-20171003]
1413 Faulkner, S., Ed., Eicholz, A., Ed., Leithead, T., Ed.,
1414 and A. Danilo, Ed., "HTML 5.1 2nd Edition", World Wide Web
1415 Consortium Recommendation REC-html51-20171003, October
1416 2017, <https://www.w3.org/TR/2017/REC-html51-20171003>.
1418 [W3C.REC-xml-20040204]
1419 Sperberg-McQueen, M., Maler, E., Bray, T., Paoli, J., and
1420 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
1421 Edition)", World Wide Web Consortium Recommendation REC-
1422 xml-20040204, February 2004,
1423 <https://www.w3.org/TR/2004/REC-xml-20040204>.
1425 [W3C.REC-xml-20081126]
1426 Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, M., Ed.,
1427 Maler, E., Ed., and F. Yergeau, Ed., "Extensible Markup
1428 Language (XML) 1.0 (Fifth Edition)", World Wide Web
1429 Consortium Recommendation REC-xml-20081126, November 2008,
1430 <https://www.w3.org/TR/2008/REC-xml-20081126>.
1434 The author would like to thank Chuck Norris of eventful.com for his
1435 work, which led to the development of this RFC.
1437 The author would also like to thank the members of CalConnect: The
1438 Calendaring and Scheduling Consortium, the Event Publication
1439 technical committee, and the following individuals for contributing
1440 their ideas and support:
1442 Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, and Scott Otis.
1450 United States of America
1452 Email: mdouglass@bedework.com
1453 URI: http://bedework.com