RFC 9074

"VALARM" Extensions for iCalendar

📅 published August 2021, from ietf

📋 RFC 9074: "VALARM" Extensions for iCalendar 🎀

okay bestie, settle in, because this one is about alarms ⏰✨ and how we make them actually behave across devices. Here's the title block tea ☕:

  • Author: C. Daboo from Apple 🍎
  • Editor: K. Murchison, Ed., from Fastmail 💌
  • Category: Standards Track, so it's a real, official protocol doc 👑
  • Date: August 2021 🌸
  • Updates: RFC 5545 (iCalendar) 🦋
  • ISSN: 2070-1721 🧚

The whole vibe is: iCalendar already has VALARM for reminders, but clients kept inventing their own X- properties for stuff like "dismissed" and "snoozed," and it was giving interoperability chaos 💀. This doc fixes that. It's "extensions," so the big picture is a bunch of new properties that work on their own, with a few needing others. Iconic 💅.

Abstract 💖

Okay so the abstract is basically the elevator pitch: this document defines a set of extensions to the iCalendar VALARM component to level up how alarms work and make clients and servers way more interoperable 🫶.

It also updates RFC 5545 💜, which is the iCalendar spec itself. So this doc is literally editing the rules of its parent spec, which is giving main character energy 🎀.

Status of This Memo ✨

This is an Internet Standards Track document 🏆. It's a product of the IETF, it reflects the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Ngl that's the highest honor a spec can get 😭🔥.

For more on what Internet Standards are, check Section 2 of RFC 7841. To get the current status, errata, or to leave feedback, head to https://www.rfc-editor.org/info/rfc9074 🦋.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they're your rights and restrictions for this doc 📜. Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as that license says 🙈.

Table of Contents 🍓

  • 1. Introduction 🧁
  • 2. Conventions Used in This Document 📖
  • 3. Extensible Syntax for VALARM 🧩
  • 4. Alarm Unique Identifier 🆔
    • 4.1 (not present)
  • 5. Alarm Related To 🔗
  • 6. Alarm Acknowledgement 👀
    • 6.1. Acknowledged Property
  • 7. Snoozing Alarms 😴
    • 7.1. Relationship Type Property Parameter
    • 7.2. Example
  • 8. Alarm Proximity Trigger 📍
    • 8.1. Proximity Property
    • 8.2. Example
  • 9. Security Considerations 🔐
  • 10. Privacy Considerations 🕵️‍♀️
  • 11. IANA Considerations 🗂️
    • 11.1. Property Registrations
    • 11.2. Relationship Types Registry
    • 11.3. Proximity Values Registry
  • 12. References 📚
    • 12.1. Normative References
    • 12.2. Informative References
  • Acknowledgements 🫶
  • Authors' Addresses 💌

1. Introduction 🧁

Okay so iCalendar, which is defined in [RFC5545], has this thing called the VALARM component. It lives inside VEVENT and VTODO components, and its whole job is to set a reminder for an event or a task ⏰. There are different alarm actions and different ways to say when the alarm goes off, so it's already pretty versatile 💅.

But here's the tea: iCalendar has gotten way more popular, and client-server protocols like CalDAV [RFC4791] are everywhere now 🌍. That exposed a bunch of issues with VALARM. Most of them boil down to needing new properties and behaviors so clients and servers can do specific things in an interoperable way 🤝. For example, clients need a way to say an alarm was dismissed by the calendar user, or "snoozed" for some amount of time 😭. Right now people do that with custom X- properties that are unique to each client, and honestly that's why interop is such a mess 💀.

So this spec defines a set of extensions to VALARM for common alarm needs that iCalendar doesn't cover yet 💖. Each extension gets its own section. Mostly each one works on its own, though sometimes one needs another to work 🧚. This doc also describes ways clients can implement common features, like snoozing, in a way that actually interoperates 🦋.

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in ALL CAPS like here 🎀.

The notation used in this memo to (re-)define iCalendar elements is the ABNF notation of [RFC5234] as used by [RFC5545]. Any syntax element shown below that isn't explicitly defined here comes from iCalendar [RFC5545] 📐.

When XML element types in the namespaces DAV: and urn:ietf:params:xml:ns:caldav get referenced outside an XML fragment, the strings DAV: and CALDAV: get prefixed to the element type names, respectively 🧾.

3. Extensible Syntax for VALARM 🧩

Section 3.6.6 of [RFC5545] defines the syntax for VALARM components and their properties. The catch is, as written it's really hard to extend, like adding a new property that every alarm type can use 😤. Since a lot of these extensions need to extend the base syntax, this doc defines an alternative form for it. The goal is to make extensions simpler to specify while still adding to what [RFC5545] already does, including allowing nested subcomponents (which proximity alarm triggers in Section 8 need) 🔥.

A VALARM calendar component gets redefined with this notation:

alarmcext  = "BEGIN" ":" "VALARM" CRLF
             *alarmprop *alarm-subcomp
             "END" ":" "VALARM" CRLF

alarmprop  = (
             ;
             ; the following are REQUIRED
             ; but MUST NOT occur more than once
             ;
             action / trigger /
             ;
             ; one set of action properties MUST be
             ; present and MUST match the action specified
             ; in the ACTION property
             ;
             actionprops /
             ;
             ; the following are OPTIONAL
             ; and MAY occur more than once
             ;
             x-prop / iana-prop
             ;
             )

actionprops = *audiopropext / *disppropext / *emailpropext

audiopropext  = (
                ;
                ; 'duration' and 'repeat' are both OPTIONAL
                ; and MUST NOT occur more than once each,
                ; but if one occurs, so MUST the other
                ;
                duration / repeat /
                ;
                ; the following is OPTIONAL
                ; but MUST NOT occur more than once
                ;
                attach
                ;
                )

disppropext = (
              ;
              ; the following are REQUIRED
              ; but MUST NOT occur more than once
              ;
              description /
              ;
              ; 'duration' and 'repeat' are both OPTIONAL
              ; and MUST NOT occur more than once each,
              ; but if one occurs, so MUST the other
              ;
              duration / repeat
              ;
              )

emailpropext = (
               ;
               ; the following are all REQUIRED
               ; but MUST NOT occur more than once
               ;
               description / summary /
               ;
               ; the following is REQUIRED
               ; and MAY occur more than once
               ;
               attendee /
               ;
               ; 'duration' and 'repeat' are both OPTIONAL
               ; and MUST NOT occur more than once each,
               ; but if one occurs, so MUST the other
               ;
               duration / repeat
               ;
               ; the following is OPTIONAL
               ; and MAY occur more than once
               ;
               attach
               ;
               )

alarm-subcomp = (
                ;
                ; the following are OPTIONAL
                ; and MAY occur more than once
                ;
                x-comp / iana-comp
                ;
                )

4. Alarm Unique Identifier 🆔

This extension adds a UID property to VALARM components so you can give each alarm a unique identifier 🔖. Once it has one, you can point back at that exact VALARM using the value 🎯.

The UID property defined here follows the definition in Section 3.8.4.7 of [RFC5545], with the security and privacy updates from Section 5.3 of [RFC7986] 🔐. Specifically, it MUST be a globally unique identifier that does not contain any security- or privacy-sensitive information. Super important, bestie 🙈.

The VALARM component defined in Section 3 gets extended like this:

alarmprop  =/ (
              ;
              ; the following is OPTIONAL
              ; but MUST NOT occur more than once
              ;
              uid
              ;
              )

Relating VALARM components to other VALARM components is super handy, like in Section 7 🧵. You can do it when each VALARM has its own UID property, which is from Section 4 💖.

This spec updates how the RELATED-TO property from Section 3.8.4.5 of [RFC5545] gets used, so it works with VALARM components 🦋. Specific relationship types between VALARM components can be identified by registering new values for the RELTYPE property parameter from Section 3.2.15 of [RFC5545] 🌈.

The VALARM component defined in Section 3 gets extended like this:

alarmprop  =/ (
              ;
              ; the following is OPTIONAL
              ; and MAY occur more than once
              ;
              related
              ;
              )

6. Alarm Acknowledgement 👀

Right now there's no way for a VALARM to show whether it was triggered and acknowledged 😤. With a standard client/server protocol for calendaring and scheduling data ([RFC4791]), an event with an alarm can easily exist on multiple clients plus the server 📱💻. If each of those devices fires the alarm, you get multiple "alerts" going off at once 🔔🔔🔔. In that situation, a calendar user would obviously want to "dismiss" it on one device and have it auto-dismissed everywhere else too 🙌.

Recurring events with alarms have their own problem. The client needs to know when the last alarm in the recurring set was acknowledged, so it can tell whether any past alarms got missed 🕰️.

So this spec adds an ACKNOWLEDGED property to VALARM components, to show when the alarm was last acknowledged (or sent, if acknowledgement isn't possible) ✅. It's defined by the syntax below 💅:

alarmprop       =/ (
                   ;
                   ; the following is OPTIONAL
                   ; but MUST NOT occur more than once
                   ;
                   acknowledged
                   ;
                   )

🫶 That's part 1, bestie! Sections 6.1 through 12 and the references are coming in the next parts, so stay tuned 💜✨

6.1. Acknowledged Property ✨

okay bestie, meet the ACKNOWLEDGED property 💅 it's basically the alarm's little "seen" receipt 🧾

  • Property Name: ACKNOWLEDGED
  • Purpose: it tells you the UTC date and time when the matching alarm was last sent or acknowledged 🕰️
  • Value Type: DATE-TIME
  • Property Parameters: IANA and nonstandard property parameters can be specified on this property 🎀
  • Conformance: this property can be specified within VALARM calendar components 🦋

Description: okay so this property is how clients figure out when a pending alarm has been acknowledged by a calendar user 👀 which means alerts can get dismissed on all of their devices at once 📱💻 it's giving seamless. It also helps clients keep track of repeating alarms, or alarms on recurring events or to-dos, so the right number of missed alarms can be counted 🔁

Clients SHOULD set this property to the current date-time value in UTC when a calendar user acknowledges a pending alarm ✨ Certain kinds of alarms, like email-based alerts, might not give any feedback about when the calendar user actually sees them 📧 For those alarms, the client SHOULD set this property when the alarm is triggered and the action is successfully carried out 💌

When an alarm gets triggered on a client, clients can peek at whether an "ACKNOWLEDGED" property is present 👀 If it is, and its value is greater than or equal to the computed trigger time for the alarm, then the client SHOULD NOT trigger the alarm 🙅‍♀️ Similarly, if an alarm has already been triggered and an "alert" was shown to a calendar user, clients can keep an eye on the iCalendar data to see whether an "ACKNOWLEDGED" property gets added or changed in the alarm component 🔍 If the value of any "ACKNOWLEDGED" property in the alarm changes and is greater than or equal to the trigger time of the alarm, then clients SHOULD dismiss or cancel any "alert" shown to the calendar user 🧹 ate that for them.

Format Definition: this property is defined by the following notation:

acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF

acknowledgedparam  = (
                     ;
                     ; the following is OPTIONAL
                     ; and MAY occur more than once
                     ;
                     (";" other-param)
                     ;
                     )

Example: here's what it looks like in action 🌸

ACKNOWLEDGED:20090604T084500Z

7. Snoozing Alarms ⏰

okay the snooze button is iconic and everyone wants one 😴 so this section gives us one standard way to do it 🫶

To "snooze" an alarm that has been triggered, clients MUST do the following:

  1. Set the ACKNOWLEDGED property (see Section 6.1) on the triggered alarm 💅
  2. Create a new VALARM component (the "snooze" alarm) within the parent component of the triggered alarm (i.e., as a "sibling" component of the triggered alarm) 👯
    • a. The new "snooze" alarm MUST be set to trigger at the user's chosen "snooze" interval after the original alarm is triggered. Clients SHOULD use an absolute TRIGGER property with a DATE-TIME value specified in UTC ⏳
    • b. The new "snooze" alarm MUST have a RELATED-TO property (see Section 5) with a value set to the UID property value of the original VALARM component that was triggered. If the triggered VALARM component does not already have a UID property, the client MUST add one. The RELATED-TO property added to the new "snooze" alarm MUST include a RELTYPE property parameter with a value set to "SNOOZE" (see Section 7.1) 🔗
  3. When the "snooze" alarm is triggered, the client MUST do the following: 🔔
    • a. Update the ACKNOWLEDGED property on the original related alarm 💖
    • b. If the "snooze" alarm is itself "snoozed", the client MUST remove the "snooze" alarm component and return to step 2. Otherwise, if the "snooze" alarm is dismissed, the client MUST do one of the following:
      • Set the ACKNOWLEDGED property on the "snooze" alarm.
      • Remove the "snooze" alarm component.

Note that regardless of the final disposition of the "snooze" alarm when triggered, the original "VALARM" component is left unchanged other than updating its "ACKNOWLEDGED" property 🧘‍♀️ very clean, very intentional.

7.1. Relationship Type Property Parameter 🎀

This spec adds the "SNOOZE" relationship type for use with the RELTYPE property defined in Section 3.2.15 of [RFC5545] 📚 It's used when relating a "snoozed" VALARM component back to the original alarm that the "snooze" was generated for 🔁

7.2. Example 🍓

Here's a lowkey iconic walkthrough of snoozing, re-snoozing, and then dismissing an alarm 😭 The encompassing VCALENDAR component has been left out to keep things short, and the line breaks around the VALARM components are just there so you can read them 🙈 they won't be in the real iCalendar data.

Say we have this event, with an alarm set to go off 15 minutes before the meeting ⏰

BEGIN:VEVENT
CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T151004Z
DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting

BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
TRIGGER:-PT15M
DESCRIPTION:Event reminder
ACTION:DISPLAY
END:VALARM

END:VEVENT

When the alarm goes off, the user decides to "snooze" it for 5 minutes 💤 The client acknowledges the original alarm and makes a new "snooze" alarm as a sibling of the original, relating it back to that alarm too. Both VALARM components live in the same parent VEVENT, so yes, they're besties 👯

BEGIN:VEVENT
CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T151516Z
DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting

BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
TRIGGER:-PT15M
DESCRIPTION:Event reminder
ACTION:DISPLAY
ACKNOWLEDGED:20210302T151514Z
END:VALARM

BEGIN:VALARM
UID:DE7B5C34-83FF-47FE-BE9E-FF41AE6DD097
TRIGGER;VALUE=DATE-TIME:20210302T152000Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder
ACTION:DISPLAY
END:VALARM

END:VEVENT

When that "snooze" alarm goes off, the user wants another 5 minutes 😤 The client acknowledges the original alarm again, removes the triggered "snooze" alarm, and makes another new "snooze" alarm as a sibling of the original, related to it. Notice the different UID on this one 👀

BEGIN:VEVENT
CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T152026Z
DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting

BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
TRIGGER:-PT15M
DESCRIPTION:Event reminder
ACTION:DISPLAY
ACKNOWLEDGED:20210302T152024Z
END:VALARM

BEGIN:VALARM
UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
TRIGGER;VALUE=DATE-TIME:20210302T152500Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder
ACTION:DISPLAY
END:VALARM

END:VEVENT

When the second "snooze" alarm goes off, the user finally decides to dismiss it 🛑 The client acknowledges both the original alarm and the second "snooze" alarm, and that's a wrap 💅

BEGIN:VEVENT
CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T152508Z
DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting

BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
TRIGGER:-PT15M
DESCRIPTION:Event reminder
ACTION:DISPLAY
ACKNOWLEDGED:20210302T152507Z
END:VALARM

BEGIN:VALARM
UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
TRIGGER;VALUE=DATE-TIME:20210302T152500Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder
ACTION:DISPLAY
ACKNOWLEDGED:20210302T152507Z
END:VALARM

END:VEVENT

8. Alarm Proximity Trigger 📍

Right now, a VALARM gets triggered when a specific date-time value is reached ⏱️ But it would be so cute to trigger alarms based on location too, like when you arrive at or leave a particular place 🗺️🚗

This spec adds the following elements to VALARM components so an alarm can be triggered based on location 💖

  • "PROXIMITY" property: indicates that a location-based trigger is to be used and which action is used for the trigger 📌
  • "VLOCATION" component(s) [RFC9073]: used to indicate the actual location(s) to trigger off of, specified with a URL property containing a 'geo' URI [RFC5870], which allows for two or three coordinate values with an optional uncertainty 🌍

Here's the grammar for the new bits 🧚

alarmprop       =/ (
                   ;
                   ; the following is OPTIONAL
                   ; but MUST NOT occur more than once
                   ;
                   proximity
                   ;
                   )

alarm-subcomp   =/ (
                   ;
                   ; the following is OPTIONAL
                   ; and MAY occur more than once but only
                   ; when a PROXIMITY property is also present
                   ;
                   locationc
                   ;
                   )

Typically, when a "PROXIMITY" property is used, there's no need for a time-based trigger using the "TRIGGER" property 🙃 However, since "TRIGGER" is a required property for a VALARM component, it has to stay present for backwards compatibility, even though it gets ignored. To indicate a "TRIGGER" that should be ignored, clients SHOULD use a value a long time in the past 🕰️ A value of 19760401T005545Z has been commonly used for this purpose 💜

8.1. Proximity Property 📍

okay so this is the PROXIMITY property, and it's giving location-based alarms 🦋 Its job is to say that a location-based trigger is applied to an alarm.

Property Name: PROXIMITY

Purpose: it marks the alarm as location-based 📍

Value Type: TEXT

Property Parameters: IANA and nonstandard property parameters can be specified on this property ✨

Conformance: you can put this property inside VALARM calendar components 💖

So the value tells the alarm what action sets it off. If the value is ARRIVE, the alarm goes off when the calendar user agent shows up near one or more locations. If it's DEPART, the alarm goes off when the calendar user agent leaves the vicinity of one or more locations. Each location MUST be specified with a VLOCATION component, no exceptions bestie 🙅‍♀️ And "vicinity" is implementation defined, so each app gets to decide what "near" means for them 🌸

Then there's the Bluetooth stuff 🚗🎀 If the value is CONNECT, the alarm triggers when the calendar user agent connects to an automobile it's been paired with over Bluetooth [BTcore]. DISCONNECT is the opposite, so it triggers when the calendar user agent disconnects from that paired automobile. Real talk though, current proximity alarm implementations and this document don't have a way to target one specific automobile. A future extension might add that 🔮

Format Definition: this property is defined by the following notation:

proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF

proximityparam  = (
                  ;
                  ; the following is OPTIONAL
                  ; and MAY occur more than once
                  ;
                  (";" other-param)
                  ;
                  )

proximityvalue  = "ARRIVE" / "DEPART" /
                  "CONNECT" / "DISCONNECT" / iana-token / x-name

8.2. Example 🎀

This example is a VALARM with a proximity trigger that fires when the device running the calendar user agent leaves the vicinity defined by the URL property in the VLOCATION component. Peep the u= parameter on the geo URI, which sets the uncertainty of the location determination 🧚

BEGIN:VALARM
UID:77D80D14-906B-4257-963F-85B1E734DBB6
ACTION:DISPLAY
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
DESCRIPTION:Remember to buy milk
PROXIMITY:DEPART
BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:Office
URL:geo:40.443,-79.945;u=10
END:VLOCATION
END:VALARM

9. Security Considerations 🔒

okay bestie, this section is SERIOUS 😭 Besides the security properties of iCalendar (see Section 7 of [RFC5545]), a VALARM that isn't monitored properly can be used to disturb users and/or leak personal information 💀 An undesirable audio alert could be super embarrassing, an unwanted display alert is just annoying, and an email alert could leak a user's location to a third party or send unsolicited email to a bunch of users. Not it 🙅‍♀️

So CalDAV clients and servers that accept iCalendar data from a third party (for example, via iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], a subscription feed, or a shared calendar) SHOULD remove each VALARM from the data before storing it in their calendar system 🛡️ Protect your calendar, fr fr.

Security considerations related to unique identifiers for VALARM are discussed in Section 4 💅

10. Privacy Considerations 🫣

A proximity VALARM that isn't used carefully can leak a user's past, present, or future location 👀 Like, if you store an iCalendar resource with proximity VALARMs on a shared calendar on a CalDAV server, anyone with access to that calendar can see the user's plan to leave from or arrive at a certain place at some future time. Furthermore, if a CalDAV client updates the shared iCalendar resource with an ACKNOWLEDGED property when the alarm fires, that leaks the exact date and time the user left or arrived 😱 So CalDAV clients that implement proximity alarms SHOULD give users the option of storing and/or acknowledging the alarms on the local device only, and not storing the alarm and/or acknowledgement on a remote server. Your location is your business, babe 💜

Privacy considerations related to unique identifiers for VALARM are discussed in Section 4 🦋

11. IANA Considerations 📋

11.1. Property Registrations

This document defines the following new iCalendar properties, which have been added to the "Properties" registry defined in Section 8.2.3 of [RFC5545]. You can find it here: https://www.iana.org/assignments/icalendar 🌈

+==============+=========+=======================+
| Property     | Status  | Reference             |
+==============+=========+=======================+
| ACKNOWLEDGED | Current | RFC 9074, Section 6.1 |
+--------------+---------+-----------------------+
| PROXIMITY    | Current | RFC 9074, Section 8.1 |
+--------------+---------+-----------------------+

  Table 1: Additions to the Properties Registry

11.2. Relationship Types Registry

This document defines one new iCalendar relationship type, which has been added to the "Relationship Types" registry defined in Section 8.3.8 of [RFC5545]. Find it here: https://www.iana.org/assignments/icalendar ✨

+===================+=========+=======================+
| Relationship Type | Status  | Reference             |
+===================+=========+=======================+
| SNOOZE            | Current | RFC 9074, Section 7.1 |
+-------------------+---------+-----------------------+

  Table 2: Addition to the Relationship Types Registry

11.3. Proximity Values Registry 📍

A brand new iCalendar registry for values of the PROXIMITY property has been created, and it lives here: https://www.iana.org/assignments/icalendar 🎀

Additional values MAY be used, as long as the process described in Section 8.2.1 of [RFC5545] is followed to register them, using the template in Section 8.2.6 of [RFC5545] 💅

The following table was used to initialize the Proximity Value Registry:

+============+=========+=======================+
| Value      | Status  | Reference             |
+============+=========+=======================+
| ARRIVE     | Current | RFC 9074, Section 8.1 |
+------------+---------+-----------------------+
| DEPART     | Current | RFC 9074, Section 8.1 |
+------------+---------+-----------------------+
| CONNECT    | Current | RFC 9074, Section 8.1 |
+------------+---------+-----------------------+
| DISCONNECT | Current | RFC 9074, Section 8.1 |
+------------+---------+-----------------------+

   Table 3: Initial Contents of the Proximity
                Values Registry

12. References 📚

12.1. Normative References

12.2. Informative References

Acknowledgements 🫶

This specification came about through discussions at The Calendaring and Scheduling Consortium 🎉 Also, a huge thank you to the following people for giving feedback: Bernard Desruisseaux, Mike Douglass, Jacob Farkas, Jeffrey Harris, Ciny Joy, Barry Leiba, and Daniel Migault. You're all iconic 👑

Authors' Addresses 💌

Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America

Email: cyrus@daboo.name URI: http://www.apple.com/

Kenneth Murchison (editor) Fastmail US LLC Suite 1201 1429 Walnut St Philadelphia, PA 19102 United States of America

Email: murch@fastmailteam.com URI: http://www.fastmail.com/

📦 where this page comes from