5Internet Engineering Task Force (IETF) C. Daboo
6Request for Comments: 9074 Apple
7Updates: 5545 K. Murchison, Ed.
8Category: Standards Track Fastmail
9ISSN: 2070-1721 August 2021
12 "VALARM" Extensions for iCalendar
16 This document defines a set of extensions to the iCalendar "VALARM"
17 component to enhance the use of alarms and improve interoperability
18 between clients and servers.
20 This document updates RFC 5545.
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 7841.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc9074.
38 Copyright (c) 2021 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
54 2. Conventions Used in This Document
55 3. Extensible Syntax for VALARM
56 4. Alarm Unique Identifier
58 6. Alarm Acknowledgement
59 6.1. Acknowledged Property
61 7.1. Relationship Type Property Parameter
63 8. Alarm Proximity Trigger
64 8.1. Proximity Property
66 9. Security Considerations
67 10. Privacy Considerations
68 11. IANA Considerations
69 11.1. Property Registrations
70 11.2. Relationship Types Registry
71 11.3. Proximity Values Registry
73 12.1. Normative References
74 12.2. Informative References
80 The iCalendar specification [RFC5545] defines a set of components
81 used to describe calendar data. One of those is the "VALARM"
82 component, which appears as a subcomponent of the "VEVENT" and
83 "VTODO" components. The "VALARM" component is used to specify a
84 reminder for an event or task. Different alarm actions are possible,
85 as are different ways to specify how the alarm is triggered.
87 As iCalendar has become more widely used and as client-server
88 protocols, such as Calendaring Extensions to WebDAV (CalDAV)
89 [RFC4791], have become more prevalent, several issues with "VALARM"
90 components have arisen. Most of these relate to the need to extend
91 the existing "VALARM" component with new properties and behaviors to
92 allow clients and servers to accomplish specific tasks in an
93 interoperable manner. For example, clients typically need a way to
94 specify that an alarm has been dismissed by a calendar user or has
95 been "snoozed" by a set amount of time. To date, this has been done
96 through the use of custom "X-" properties specific to each client
97 implementation, leading to poor interoperability.
99 This specification defines a set of extensions to "VALARM" components
100 to cover common requirements for alarms not currently addressed in
101 iCalendar. Each extension is defined in a separate section below.
102 For the most part, each extension can be supported independently of
103 the others; though, in some cases, one extension will require
104 another. In addition, this specification describes mechanisms by
105 which clients can interoperably implement common features, such as
1082. Conventions Used in This Document
110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
112 "OPTIONAL" in this document are to be interpreted as described in
113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
114 capitals, as shown here.
116 The notation used in this memo to (re-)define iCalendar elements is
117 the ABNF notation of [RFC5234] as used by [RFC5545]. Any syntax
118 elements shown below that are not explicitly defined in this
119 specification come from iCalendar [RFC5545].
121 When XML element types in the namespaces "DAV:" and
122 "urn:ietf:params:xml:ns:caldav" are referenced in this document
123 outside of the context of an XML fragment, the string "DAV:" and
124 "CALDAV:" will be prefixed to the element type names, respectively.
1263. Extensible Syntax for VALARM
128 Section 3.6.6 of [RFC5545] defines the syntax for "VALARM" components
129 and properties within them. However, as written, it is hard to
130 extend this, e.g., by adding a new property common to all types of
131 alarms. Since many of the extensions defined in this document need
132 to extend the base syntax, an alternative form for the base syntax is
133 defined here, with the goal of simplifying specification of the
134 extensions while augmenting the existing functionality defined in
135 [RFC5545] to allow for nested subcomponents (as required by proximity
136 alarm triggers (Section 8)).
138 A "VALARM" calendar component is redefined by the following notation:
140 alarmcext = "BEGIN" ":" "VALARM" CRLF
141 *alarmprop *alarm-subcomp
142 "END" ":" "VALARM" CRLF
146 ; the following are REQUIRED
147 ; but MUST NOT occur more than once
151 ; one set of action properties MUST be
152 ; present and MUST match the action specified
153 ; in the ACTION property
157 ; the following are OPTIONAL
158 ; and MAY occur more than once
164 actionprops = *audiopropext / *disppropext / *emailpropext
168 ; 'duration' and 'repeat' are both OPTIONAL
169 ; and MUST NOT occur more than once each,
170 ; but if one occurs, so MUST the other
174 ; the following is OPTIONAL
175 ; but MUST NOT occur more than once
183 ; the following are REQUIRED
184 ; but MUST NOT occur more than once
188 ; 'duration' and 'repeat' are both OPTIONAL
189 ; and MUST NOT occur more than once each,
190 ; but if one occurs, so MUST the other
198 ; the following are all REQUIRED
199 ; but MUST NOT occur more than once
201 description / summary /
203 ; the following is REQUIRED
204 ; and MAY occur more than once
208 ; 'duration' and 'repeat' are both OPTIONAL
209 ; and MUST NOT occur more than once each,
210 ; but if one occurs, so MUST the other
214 ; the following is OPTIONAL
215 ; and MAY occur more than once
223 ; the following are OPTIONAL
224 ; and MAY occur more than once
2304. Alarm Unique Identifier
232 This extension adds a "UID" property to "VALARM" components to allow
233 a unique identifier to be specified. The value of this property can
234 then be used to refer uniquely to the "VALARM" component.
236 The "UID" property defined here follows the definition in
237 Section 3.8.4.7 of [RFC5545] with the security and privacy updates in
238 Section 5.3 of [RFC7986]. In particular, it MUST be a globally
239 unique identifier that does not contain any security- or privacy-
240 sensitive information.
242 The "VALARM" component defined in Section 3 is extended here as:
246 ; the following is OPTIONAL
247 ; but MUST NOT occur more than once
255 It is often convenient to relate one or more "VALARM" components to
256 other "VALARM" components (e.g., see Section 7). This can be
257 accomplished if the "VALARM" components each have their own "UID"
258 property (as per Section 4).
260 This specification updates the usage of the "RELATED-TO" property
261 defined in Section 3.8.4.5 of [RFC5545] to enable its use with
262 "VALARM" components. Specific types of relationships between
263 "VALARM" components can be identified by registering new values for
264 the "RELTYPE" property parameter defined in Section 3.2.15 of
267 The "VALARM" component defined in Section 3 is extended here as:
271 ; the following is OPTIONAL
272 ; and MAY occur more than once
2786. Alarm Acknowledgement
280 There is currently no way for a "VALARM" component to indicate
281 whether it has been triggered and acknowledged. With the advent of a
282 standard client/server protocol for calendaring and scheduling data
283 ([RFC4791]), it is quite possible for an event with an alarm to exist
284 on multiple clients in addition to the server. If each of those is
285 responsible for performing the action when an alarm triggers, then
286 multiple "alerts" are generated by different devices. In such a
287 situation, a calendar user would like to be able to "dismiss" the
288 alarm on one device and have it automatically dismissed on the
291 Also, with recurring events that have alarms, it is important to know
292 when the last alarm in the recurring set was acknowledged so that the
293 client can determine whether past alarms have been missed.
295 To address these needs, this specification adds an "ACKNOWLEDGED"
296 property to "VALARM" components to indicate when the alarm was last
297 acknowledged (or sent, if acknowledgement is not possible). This is
298 defined by the syntax below.
302 ; the following is OPTIONAL
303 ; but MUST NOT occur more than once
3096.1. Acknowledged Property
311 Property Name: ACKNOWLEDGED
313 Purpose: This property specifies the UTC date and time at which the
314 corresponding alarm was last sent or acknowledged.
316 Value Type: DATE-TIME
318 Property Parameters: IANA and nonstandard property parameters can be
319 specified on this property.
321 Conformance: This property can be specified within "VALARM" calendar
324 Description: This property is used to specify when an alarm was last
325 sent or acknowledged. This allows clients to determine when a
326 pending alarm has been acknowledged by a calendar user so that any
327 alerts can be dismissed across multiple devices. It also allows
328 clients to track repeating alarms or alarms on recurring events or
329 to-dos to ensure that the right number of missed alarms can be
332 Clients SHOULD set this property to the current date-time value in
333 UTC when a calendar user acknowledges a pending alarm. Certain
334 kinds of alarms, such as email-based alerts, might not provide
335 feedback as to when the calendar user sees them. For those kinds
336 of alarms, the client SHOULD set this property when the alarm is
337 triggered and the action is successfully carried out.
339 When an alarm is triggered on a client, clients can check to see
340 if an "ACKNOWLEDGED" property is present. If it is, and the value
341 of that property is greater than or equal to the computed trigger
342 time for the alarm, then the client SHOULD NOT trigger the alarm.
343 Similarly, if an alarm has been triggered and an "alert" has been
344 presented to a calendar user, clients can monitor the iCalendar
345 data to determine whether an "ACKNOWLEDGED" property is added or
346 changed in the alarm component. If the value of any
347 "ACKNOWLEDGED" property in the alarm changes and is greater than
348 or equal to the trigger time of the alarm, then clients SHOULD
349 dismiss or cancel any "alert" presented to the calendar user.
351 Format Definition: This property is defined by the following
354 acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF
356 acknowledgedparam = (
358 ; the following is OPTIONAL
359 ; and MAY occur more than once
365 Example: The following is an example of this property:
367 ACKNOWLEDGED:20090604T084500Z
371 Users often want to "snooze" an alarm, and this specification defines
372 a standard approach to accomplish that.
374 To "snooze" an alarm that has been triggered, clients MUST do the
377 1. Set the "ACKNOWLEDGED" property (see Section 6.1) on the
380 2. Create a new "VALARM" component (the "snooze" alarm) within the
381 parent component of the triggered alarm (i.e., as a "sibling"
382 component of the triggered alarm).
384 a. The new "snooze" alarm MUST be set to trigger at the user's
385 chosen "snooze" interval after the original alarm is
386 triggered. Clients SHOULD use an absolute "TRIGGER" property
387 with a "DATE-TIME" value specified in UTC.
389 b. The new "snooze" alarm MUST have a "RELATED-TO" property (see
390 Section 5) with a value set to the "UID" property value of
391 the original "VALARM" component that was triggered. If the
392 triggered "VALARM" component does not already have a "UID"
393 property, the client MUST add one. The "RELATED-TO" property
394 added to the new "snooze" alarm MUST include a "RELTYPE"
395 property parameter with a value set to "SNOOZE" (see
398 3. When the "snooze" alarm is triggered, the client MUST do the
401 a. Update the "ACKNOWLEDGED" property on the original related
404 b. If the "snooze" alarm is itself "snoozed", the client MUST
405 remove the "snooze" alarm component and return to step 2.
407 Otherwise, if the "snooze" alarm is dismissed, the client
408 MUST do one of the following:
410 * Set the "ACKNOWLEDGED" property on the "snooze" alarm.
412 * Remove the "snooze" alarm component.
414 Note that regardless of the final disposition of the "snooze" alarm
415 when triggered, the original "VALARM" component is left unchanged
416 other than updating its "ACKNOWLEDGED" property.
4187.1. Relationship Type Property Parameter
420 This specification adds the "SNOOZE" relationship type for use with
421 the "RELTYPE" property defined in Section 3.2.15 of [RFC5545]. This
422 is used when relating a "snoozed" "VALARM" component to the original
423 alarm that the "snooze" was generated for.
427 The following example shows the "snoozing", "re-snoozing", and
428 dismissal of an alarm. Note that the encompassing "VCALENDAR"
429 component has been omitted for brevity and that the line breaks
430 surrounding the "VALARM" components are for clarity only and would
431 not be present in the actual iCalendar data.
433 Assume that we have the following event with an alarm set to trigger
434 15 minutes before the meeting:
437 CREATED:20210302T151004Z
438 UID:AC67C078-CED3-4BF5-9726-832C3749F627
439 DTSTAMP:20210302T151004Z
440 DTSTART;TZID=America/New_York:20210302T103000
441 DTEND;TZID=America/New_York:20210302T113000
445 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
447 DESCRIPTION:Event reminder
453 When the alarm is triggered, the user decides to "snooze" it for 5
454 minutes. The client acknowledges the original alarm and creates a
455 new "snooze" alarm as a sibling of, and relates it to, the original
456 alarm (note that both occurrences of "VALARM" reside within the same
460 CREATED:20210302T151004Z
461 UID:AC67C078-CED3-4BF5-9726-832C3749F627
462 DTSTAMP:20210302T151516Z
463 DTSTART;TZID=America/New_York:20210302T103000
464 DTEND;TZID=America/New_York:20210302T113000
468 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
470 DESCRIPTION:Event reminder
472 ACKNOWLEDGED:20210302T151514Z
476 UID:DE7B5C34-83FF-47FE-BE9E-FF41AE6DD097
477 TRIGGER;VALUE=DATE-TIME:20210302T152000Z
478 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
479 DESCRIPTION:Event reminder
485 When the "snooze" alarm is triggered, the user decides to "snooze" it
486 again for an additional 5 minutes. The client once again
487 acknowledges the original alarm, removes the triggered "snooze"
488 alarm, and creates another new "snooze" alarm as a sibling of, and
489 relates it to, the original alarm (note the different UID for the new
493 CREATED:20210302T151004Z
494 UID:AC67C078-CED3-4BF5-9726-832C3749F627
495 DTSTAMP:20210302T152026Z
496 DTSTART;TZID=America/New_York:20210302T103000
497 DTEND;TZID=America/New_York:20210302T113000
501 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
503 DESCRIPTION:Event reminder
505 ACKNOWLEDGED:20210302T152024Z
509 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
510 TRIGGER;VALUE=DATE-TIME:20210302T152500Z
511 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
512 DESCRIPTION:Event reminder
518 When the second "snooze" alarm is triggered, the user decides to
519 dismiss it. The client acknowledges both the original alarm and the
520 second "snooze" alarm:
523 CREATED:20210302T151004Z
524 UID:AC67C078-CED3-4BF5-9726-832C3749F627
525 DTSTAMP:20210302T152508Z
526 DTSTART;TZID=America/New_York:20210302T103000
527 DTEND;TZID=America/New_York:20210302T113000
531 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
533 DESCRIPTION:Event reminder
535 ACKNOWLEDGED:20210302T152507Z
539 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
540 TRIGGER;VALUE=DATE-TIME:20210302T152500Z
541 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
542 DESCRIPTION:Event reminder
544 ACKNOWLEDGED:20210302T152507Z
5498. Alarm Proximity Trigger
551 Currently, a "VALARM" is triggered when a specific date-time value is
552 reached. It is also desirable to be able to trigger alarms based on
553 location, e.g., when arriving at or departing from a particular
556 This specification adds the following elements to "VALARM" components
557 to indicate when an alarm can be triggered based on location.
559 "PROXIMITY" property: indicates that a location-based trigger is to
560 be used and which action is used for the trigger
562 "VLOCATION" component(s) [RFC9073]: used to indicate the actual
563 location(s) to trigger off of, specified with a URL property
564 containing a 'geo' URI [RFC5870], which allows for two or three
565 coordinate values with an optional uncertainty
569 ; the following is OPTIONAL
570 ; but MUST NOT occur more than once
578 ; the following is OPTIONAL
579 ; and MAY occur more than once but only
580 ; when a PROXIMITY property is also present
586 Typically, when a "PROXIMITY" property is used, there is no need to
587 specify a time-based trigger using the "TRIGGER" property. However,
588 since "TRIGGER" is defined as a required property for a "VALARM"
589 component, for backwards compatibility, it has to be present but
590 ignored. To indicate a "TRIGGER" that is to be ignored, clients
591 SHOULD use a value a long time in the past. A value of
592 "19760401T005545Z" has been commonly used for this purpose.
5948.1. Proximity Property
596 Property Name: PROXIMITY
598 Purpose: This property indicates that a location-based trigger is
603 Property Parameters: IANA and nonstandard property parameters can be
604 specified on this property.
606 Conformance: This property can be specified within "VALARM" calendar
609 Description: This property is used to indicate that an alarm has a
610 location-based trigger. Its value identifies the action that will
613 When the property value is set to "ARRIVE", the alarm is triggered
614 when the calendar user agent arrives in the vicinity of one or
615 more locations. When set to "DEPART", the alarm is triggered when
616 the calendar user agent departs from the vicinity of one or more
617 locations. Each location MUST be specified with a "VLOCATION"
618 component. Note that the meaning of "vicinity" in this context is
619 implementation defined.
621 When the property value is set to "CONNECT", the alarm is
622 triggered when the calendar user agent connects to an automobile
623 to which it has been paired via Bluetooth [BTcore]. When set to
624 "DISCONNECT", the alarm is triggered when the calendar user agent
625 disconnects from an automobile to which it has been paired via
626 Bluetooth. Note that neither current implementations of proximity
627 alarms nor this document have a mechanism to target a particular
628 automobile. Such a mechanism may be specified in a future
631 Format Definition: This property is defined by the following
634 proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF
638 ; the following is OPTIONAL
639 ; and MAY occur more than once
645 proximityvalue = "ARRIVE" / "DEPART" /
646 "CONNECT" / "DISCONNECT" / iana-token / x-name
650 The following example shows a "VALARM" component with a proximity
651 trigger set to trigger when the device running the calendar user
652 agent leaves the vicinity defined by the URL property in the
653 "VLOCATION" component. Note use of the "u=" parameter with the 'geo'
654 URI to define the uncertainty of the location determination.
657 UID:77D80D14-906B-4257-963F-85B1E734DBB6
659 TRIGGER;VALUE=DATE-TIME:19760401T005545Z
660 DESCRIPTION:Remember to buy milk
663 UID:123456-abcdef-98765432
665 URL:geo:40.443,-79.945;u=10
6699. Security Considerations
671 In addition to the security properties of iCalendar (see Section 7 of
672 [RFC5545]), a "VALARM", if not monitored properly, can be used to
673 disturb users and/or leak personal information. For instance, an
674 undesirable audio alert could cause embarrassment; an unwanted
675 display alert could be considered an annoyance; or an email alert
676 could be used to leak a user's location to a third party or to send
677 unsolicited email to multiple users. Therefore, CalDAV clients and
678 servers that accept iCalendar data from a third party (e.g., via
679 iCalendar Transport-Independent Interoperability Protocol (iTIP)
680 [RFC5546], a subscription feed, or a shared calendar) SHOULD remove
681 each "VALARM" from the data prior to storing in their calendar
684 Security considerations related to unique identifiers for "VALARM"
685 are discussed in Section 4.
68710. Privacy Considerations
689 A proximity "VALARM", if not used carefully, can leak a user's past,
690 present, or future location. For instance, storing an iCalendar
691 resource containing proximity "VALARM"s to a shared calendar on
692 CalDAV server can expose to anyone that has access to that calendar
693 the user's intent to leave from or arrive at a particular location at
694 some future time. Furthermore, if a CalDAV client updates the shared
695 iCalendar resource with an "ACKNOWLEDGED" property when the alarm is
696 triggered, this will leak the exact date and time that the user left
697 from or arrived at the location. Therefore, CalDAV clients that
698 implement proximity alarms SHOULD give users the option of storing
699 and/or acknowledging the alarms on the local device only and not
700 storing the alarm and/or acknowledgement on a remote server.
702 Privacy considerations related to unique identifiers for "VALARM" are
703 discussed in Section 4.
70511. IANA Considerations
70711.1. Property Registrations
709 This document defines the following new iCalendar properties that
710 have been added to the "Properties" registry defined in Section 8.2.3
711 of [RFC5545] and located here: <https://www.iana.org/assignments/
714 +==============+=========+=======================+
715 | Property | Status | Reference |
716 +==============+=========+=======================+
717 | ACKNOWLEDGED | Current | RFC 9074, Section 6.1 |
718 +--------------+---------+-----------------------+
719 | PROXIMITY | Current | RFC 9074, Section 8.1 |
720 +--------------+---------+-----------------------+
722 Table 1: Additions to the Properties Registry
72411.2. Relationship Types Registry
726 This document defines the following new iCalendar relationship type
727 that has been added to the "Relationship Types" registry defined in
728 Section 8.3.8 of [RFC5545] and located here:
729 <https://www.iana.org/assignments/icalendar>.
731 +===================+=========+=======================+
732 | Relationship Type | Status | Reference |
733 +===================+=========+=======================+
734 | SNOOZE | Current | RFC 9074, Section 7.1 |
735 +-------------------+---------+-----------------------+
737 Table 2: Addition to the Relationship Types Registry
73911.3. Proximity Values Registry
741 A new iCalendar registry for values of the "PROXIMITY" property has
742 been created and is located here: <https://www.iana.org/assignments/
745 Additional values MAY be used, provided the process described in
746 Section 8.2.1 of [RFC5545] is used to register them, using the
747 template in Section 8.2.6 of [RFC5545].
749 The following table has been used to initialize the Proximity Value
752 +============+=========+=======================+
753 | Value | Status | Reference |
754 +============+=========+=======================+
755 | ARRIVE | Current | RFC 9074, Section 8.1 |
756 +------------+---------+-----------------------+
757 | DEPART | Current | RFC 9074, Section 8.1 |
758 +------------+---------+-----------------------+
759 | CONNECT | Current | RFC 9074, Section 8.1 |
760 +------------+---------+-----------------------+
761 | DISCONNECT | Current | RFC 9074, Section 8.1 |
762 +------------+---------+-----------------------+
764 Table 3: Initial Contents of the Proximity
76912.1. Normative References
771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
772 Requirement Levels", BCP 14, RFC 2119,
773 DOI 10.17487/RFC2119, March 1997,
774 <https://www.rfc-editor.org/info/rfc2119>.
776 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
777 Specifications: ABNF", STD 68, RFC 5234,
778 DOI 10.17487/RFC5234, January 2008,
779 <https://www.rfc-editor.org/info/rfc5234>.
781 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
782 Scheduling Core Object Specification (iCalendar)",
783 RFC 5545, DOI 10.17487/RFC5545, September 2009,
784 <https://www.rfc-editor.org/info/rfc5545>.
786 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
787 Identifier for Geographic Locations ('geo' URI)",
788 RFC 5870, DOI 10.17487/RFC5870, June 2010,
789 <https://www.rfc-editor.org/info/rfc5870>.
791 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,
792 DOI 10.17487/RFC7986, October 2016,
793 <https://www.rfc-editor.org/info/rfc7986>.
795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
797 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
799 [RFC9073] Douglass, M., "Event Publishing Extensions to iCalendar",
800 RFC 9073, DOI 10.17487/RFC9073, August 2021,
801 <https://www.rfc-editor.org/info/rfc9073>.
80312.2. Informative References
805 [BTcore] Bluetooth Special Interest Group, "Bluetooth Core
806 Specification Version 5.0 Feature Overview", December
807 2016, <https://www.bluetooth.com/bluetooth-resources/
808 bluetooth-5- go-faster-go-further/>.
810 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
811 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
812 DOI 10.17487/RFC4791, March 2007,
813 <https://www.rfc-editor.org/info/rfc4791>.
815 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
816 Interoperability Protocol (iTIP)", RFC 5546,
817 DOI 10.17487/RFC5546, December 2009,
818 <https://www.rfc-editor.org/info/rfc5546>.
822 This specification came about via discussions at The Calendaring and
823 Scheduling Consortium. Also, thanks to the following for providing
824 feedback: Bernard Desruisseaux, Mike Douglass, Jacob Farkas, Jeffrey
825 Harris, Ciny Joy, Barry Leiba, and Daniel Migault.
833 United States of America
835 Email: cyrus@daboo.name
836 URI: http://www.apple.com/
839 Kenneth Murchison (editor)
843 Philadelphia, PA 19102
844 United States of America
846 Email: murch@fastmailteam.com
847 URI: http://www.fastmail.com/