ietf-corpus

rfc-9074

"VALARM" Extensions for iCalendar

C. Daboo, K. Murchison (Editor)
date2021-08 streamIETF areaart wgcalext statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc9074 doi10.17487/RFC9074 errataview
This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers. This document updates RFC 5545.

updates

Extracted elements (25)

design-rationale §7

Snooze alarms are implemented as sibling VALARM components (rather than modifying the original alarm) so that the original VALARM remains unchanged except for its ACKNOWLEDGED property. This preserves the original alarm definition while allowing snooze state to be tracked independently.

design-rationale §3

The VALARM syntax is redefined with a more extensible form (alarmcext) because the original RFC 5545 syntax was difficult to extend with properties common to all alarm types and did not support nested subcomponents needed by proximity alarm triggers (VLOCATION).

interoperability-note §1

Prior to this specification, alarm acknowledgement and snooze behavior were implemented using custom X- properties specific to each client, leading to poor interoperability. This document standardizes these behaviors to enable cross-client and client-server interoperability in CalDAV environments.

interoperability-note §8

PROXIMITY alarms require TRIGGER to be present for backwards compatibility with RFC 5545 even though the time-based trigger is irrelevant; the recommended dummy value '19760401T005545Z' has been commonly used in existing implementations.

normative-requirement §6.1 SHOULD

Clients SHOULD set the ACKNOWLEDGED property to the current UTC date-time when a calendar user acknowledges a pending alarm. For alarms like email alerts where acknowledgement feedback is unavailable, the client SHOULD set it when the alarm is triggered and the action is successfully carried out.

normative-requirement §4 MUST

The UID property in a VALARM component MUST be a globally unique identifier that does not contain any security- or privacy-sensitive information.

privacy, security

normative-requirement §7 MUST

To snooze an alarm, clients MUST set the ACKNOWLEDGED property on the triggered alarm and create a new sibling VALARM component set to trigger at the user's chosen snooze interval. The snooze alarm MUST use an absolute TRIGGER with UTC DATE-TIME (SHOULD) and MUST include a RELATED-TO property with RELTYPE=SNOOZE referencing the original alarm's UID.

normative-requirement §8 SHOULD

When a PROXIMITY property is used, a TRIGGER property is still required for backwards compatibility but SHOULD be ignored. Clients SHOULD use a value far in the past (e.g., '19760401T005545Z') to indicate a TRIGGER that is to be ignored.

normative-requirement §7 MUST

When a snooze alarm is triggered, the client MUST update the ACKNOWLEDGED property on the original related alarm. If the snooze alarm is itself snoozed, the client MUST remove the snooze alarm component and repeat the snooze procedure.

normative-requirement §6.1 SHOULD NOT

When an alarm is triggered and an ACKNOWLEDGED property is present with a value greater than or equal to the computed trigger time, the client SHOULD NOT trigger the alarm. If an alert has already been presented, clients SHOULD dismiss or cancel it when the ACKNOWLEDGED value becomes greater than or equal to the trigger time.

normative-requirement §8.1 MUST

When the PROXIMITY property value is ARRIVE or DEPART, each target location MUST be specified with a VLOCATION component containing a URL with a 'geo' URI.

privacy-consideration §10

A proximity VALARM stored on a shared CalDAV calendar can expose a user's intended future location to anyone with calendar access. If the client updates the shared resource with an ACKNOWLEDGED property upon triggering, it also leaks the exact date and time of arrival or departure. CalDAV clients implementing proximity alarms SHOULD give users the option to store and/or acknowledge alarms on the local device only.

privacy

protocol-element §4

A UID property may be added to VALARM components to provide a globally unique identifier, enabling cross-referencing between alarm components (e.g., for snooze relationships). It follows the definition from RFC 5545 Section 3.8.4.7 with privacy/security updates from RFC 7986 Section 5.3.

protocol-element §6.1

The ACKNOWLEDGED property specifies the UTC date-time at which a VALARM was last sent or acknowledged. Its value type is DATE-TIME and it is optional but must not occur more than once within a VALARM component.

protocol-element §8.1

The PROXIMITY property indicates a location-based trigger for a VALARM. Its value is TEXT with defined values ARRIVE, DEPART, CONNECT, and DISCONNECT; it is optional but must not occur more than once in a VALARM component.

protocol-element §5

The RELATED-TO property usage is extended to apply to VALARM components (in addition to its existing uses), enabling alarm-to-alarm relationships. New RELTYPE values can be registered to identify specific relationship types between VALARMs.

protocol-element §7.1

The SNOOZE relationship type is added for use with the RELTYPE property parameter to relate a snoozed VALARM component back to the original alarm that triggered the snooze.

protocol-element §8

VLOCATION subcomponents (from RFC 9073) are used within VALARM to specify geographic trigger locations using a URL property containing a 'geo' URI, which supports two or three coordinate values with optional uncertainty.

registry §11.3

A new iCalendar 'Proximity Values' registry is created with initial values ARRIVE, DEPART, CONNECT, and DISCONNECT. Additional values may be registered using the process in RFC 5545 Section 8.2.1.

registry

registry §11.2

A new SNOOZE value is registered in the iCalendar 'Relationship Types' registry (RFC 5545 Section 8.3.8) to identify the relationship between a snooze VALARM and its original alarm.

registry

registry §11.1

Two new iCalendar properties are registered: ACKNOWLEDGED (Section 6.1) and PROXIMITY (Section 8.1), added to the 'Properties' registry defined in RFC 5545 Section 8.2.3.

registry

security-consideration §9

An improperly monitored VALARM can be used to disturb users or leak personal information (e.g., audio alerts causing embarrassment, display alerts as annoyances, or email alerts leaking location or sending unsolicited email). CalDAV clients and servers accepting iCalendar data from third parties SHOULD remove each VALARM before storing it in their calendar system.

security, privacy

wire-format §6.1

The ACKNOWLEDGED property is defined by the notation: 'acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF', where datetime is a UTC DATE-TIME value.

wire-format §3

The extensible VALARM syntax (alarmcext) allows zero or more alarmprop and zero or more alarm-subcomp entries; alarm-subcomp may include x-comp or iana-comp elements, enabling nested subcomponents such as VLOCATION.

wire-format §8.1

The PROXIMITY property is defined by the notation: 'proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF', where proximityvalue is one of ARRIVE, DEPART, CONNECT, DISCONNECT, iana-token, or x-name.