rfc9074xml2.original.xml   rfc9074.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'
[ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="5545" ipr="trust200902"
<!ENTITY rfc2119 PUBLIC '' docName="draft-ietf-calext-valarm-extensions-07" number="9074" obsoletes="" sub
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'> missionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="tru
<!ENTITY rfc3261 PUBLIC '' e" symRefs="true" sortRefs="true"
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml'> tocDepth="2" version="3">
<!ENTITY rfc3860 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3860.xml'>
<!ENTITY rfc3966 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3966.xml'>
<!ENTITY rfc4791 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4791.xml'>
<!ENTITY rfc5545 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml'>
<!ENTITY rfc5546 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5546.xml'>
<!ENTITY rfc5724 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5724.xml'>
<!ENTITY rfc5870 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5870.xml'>
<!ENTITY rfc7986 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7986.xml'>
<!ENTITY rfc8174 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'>
<!ENTITY idEventPub PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-calext-eventpub-e
xtensions.xml'>
]>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc strict="yes"?>
<rfc category="std" updates='5545'
ipr='trust200902' docName='draft-ietf-calext-valarm-extensions-07'>
<front> <front>
<title abbrev="VALARM Extensions">VALARM Extensions for iCalendar</title> <title abbrev="VALARM Extensions">&quot;VALARM&quot; Extensions for iCalenda
r</title>
<seriesInfo name="RFC" value="9074"/>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo"> <author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization abbrev="Apple">Apple Inc.</organization> <organization abbrev="Apple">Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>1 Infinite Loop</street> <street>1 Infinite Loop</street>
<city>Cupertino</city> <city>Cupertino</city>
<region>CA</region> <region>CA</region>
<code>95014</code> <code>95014</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>cyrus@daboo.name</email> <email>cyrus@daboo.name</email>
<uri>http://www.apple.com/</uri> <uri>http://www.apple.com/</uri>
</address> </address>
</author> </author>
<author role="editor" initials="K." surname="Murchison" <author role="editor" initials="K." surname="Murchison" fullname="Kenneth Mu
fullname="Kenneth Murchison"> rchison">
<organization abbrev="Fastmail">Fastmail US LLC</organization> <organization abbrev="Fastmail">Fastmail US LLC</organization>
<address> <address>
<postal> <postal>
<street>1429 Walnut St, Suite 1201</street> <street>1429 Walnut St</street>
<city>Philadephia</city> <extaddr>Suite 1201</extaddr>
<city>Philadelphia</city>
<region>PA</region> <region>PA</region>
<code>19102</code> <code>19102</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>murch@fastmailteam.com</email> <email>murch@fastmailteam.com</email>
<uri>http://www.fastmail.com/</uri> <uri>http://www.fastmail.com/</uri>
</address> </address>
</author> </author>
<date /> <date year="2021" month="August" />
<area>Applications</area> <area>Applications</area>
<keyword>alarms</keyword> <keyword>alarms</keyword>
<keyword>calendaring</keyword> <keyword>calendaring</keyword>
<keyword>iCalendar</keyword> <keyword>iCalendar</keyword>
<keyword>CalDAV</keyword> <keyword>CalDAV</keyword>
<abstract> <abstract>
<t>This document defines a set of extensions to the iCalendar <t>This document defines a set of extensions to the iCalendar
VALARM component to enhance use of alarms and improve "VALARM" component to enhance the use of alarms and improve
interoperability between clients and servers.</t> interoperability between clients and servers.</t>
<t>This document updates RFC 5545.</t>
<t>This document updates RFC5545.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title='Introduction'> <section numbered="true" toc="default">
<t>The <xref target="RFC5545">iCalendar</xref> specification <name>Introduction</name>
<t>The <xref target="RFC5545" format="default">iCalendar specification</xr
ef>
defines a set of components used to describe calendar data. One defines a set of components used to describe calendar data. One
of those is the "VALARM" component which appears as a of those is the "VALARM" component, which appears as a
sub-component of "VEVENT" and "VTODO" components. The "VALARM" subcomponent of the "VEVENT" and "VTODO" components. The "VALARM"
component is used to specify a reminder for an event or component is used to specify a reminder for an event or
task. Different alarm actions are possible, as are different task. Different alarm actions are possible, as are different
ways to specify how the alarm is triggered.</t> ways to specify how the alarm is triggered.</t>
<t>As iCalendar has become more widely used and as client-server <t>As iCalendar has become more widely used and as client-server
protocols such as <xref target="RFC4791">CalDAV</xref> have protocols, such as <xref target="RFC4791" format="default">Calendaring Ext
ensions to WebDAV
(CalDAV)</xref>, have
become more prevalent, several issues with "VALARM" components become more prevalent, several issues with "VALARM" components
have arisen. Most of these relate to the need to extend the have arisen. Most of these relate to the need to extend the
existing "VALARM" component with new properties and behaviors to existing "VALARM" component with new properties and behaviors to
allow clients and servers to accomplish specific tasks in an allow clients and servers to accomplish specific tasks in an
interoperable manner. For example, clients typically need a way interoperable manner. For example, clients typically need a way
to specify that an alarm has been dismissed by a calendar user, to specify that an alarm has been dismissed by a calendar user
or has been "snoozed" by a set amount of time. To date, this has or has been "snoozed" by a set amount of time. To date, this has
been done through the use of custom "X-" properties specific to been done through the use of custom "X-" properties specific to
each client implementation, leading to poor each client implementation, leading to poor
interoperability.</t> interoperability.</t>
<t>This specification defines a set of extensions to "VALARM" <t>This specification defines a set of extensions to "VALARM"
components to cover common requirements for alarms not currently components to cover common requirements for alarms not currently
addressed in iCalendar. Each extension is defined in a separate addressed in iCalendar. Each extension is defined in a separate
section below. For the most part, each extension can be section below. For the most part, each extension can be
supported independently of the others, though in some cases one supported independently of the others; though, in some cases, one
extension will require another. In addition, this specification extension will require another. In addition, this specification
describes mechanisms by which clients can interoperably describes mechanisms by which clients can interoperably
implement common features such as "snoozing".</t> implement common features, such as "snoozing".</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title='Conventions Used in This Document'> <t>The notation used in this memo to (re-)define iCalendar elements is th
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL e ABNF notation of <xref target="RFC5234"/> as used by <xref target="RFC5545"/>.
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", Any syntax elements shown below that are not explicitly defined in this speci
"MAY", and "OPTIONAL" in this document are to be interpreted as fication come from iCalendar <xref target="RFC5545"/>.</t>
described in BCP&nbsp;14
<xref target='RFC2119' /> <xref target='RFC8174' />
when, and only when, they appear in all capitals, as shown here.</t>
<t>When XML element types in the namespaces "DAV:" and <t>When XML element types in the namespaces "DAV:" and
"urn:ietf:params:xml:ns:caldav" are referenced in this document "urn:ietf:params:xml:ns:caldav" are referenced in this document
outside of the context of an XML fragment, the string "DAV:" and outside of the context of an XML fragment, the string "DAV:" and
"CALDAV:" will be prefixed to the element type names "CALDAV:" will be prefixed to the element type names,
respectively.</t> respectively.</t>
</section> </section>
<section anchor="syntax" numbered="true" toc="default">
<section title="Extensible syntax for VALARM" anchor="syntax"> <name>Extensible Syntax for VALARM</name>
<t>Section 3.6.6 of <xref target="RFC5545" /> defines the syntax <t><xref target="RFC5545" sectionFormat="of" section="3.6.6"/> defines the
syntax
for "VALARM" components and properties within them. However, as for "VALARM" components and properties within them. However, as
written, it is hard to extend this by adding, e.g., a new written, it is hard to extend this, e.g., by adding a new
property common to all types of alarm. Since many of the property common to all types of alarms. Since many of the
extensions defined in this document need to extend the base extensions defined in this document need to extend the base
syntax, an alternative form for the base syntax is defined here, syntax, an alternative form for the base syntax is defined here,
with the goal of simplifying specification of the extensions with the goal of simplifying specification of the extensions
while augmenting the existing functionality defined in while augmenting the existing functionality defined in
<xref target="RFC5545"/> to allow for nested sub-components <xref target="RFC5545" format="default"/> to allow for nested subcomponent s
(as required by (as required by
<xref target="proximity">proximity alarm triggers</xref>).</t> <xref target="proximity" format="default">proximity alarm triggers</xref>)
.</t>
<t>A "VALARM" calendar component is redefined by the following notation:
</t>
<t>A "VALARM" calendar component is re-defined by the following notation: <sourcecode type="abnf"><![CDATA[
<figure>
<artwork name="abnf"><![CDATA[
alarmcext = "BEGIN" ":" "VALARM" CRLF alarmcext = "BEGIN" ":" "VALARM" CRLF
*alarmprop *alarm-subcomp *alarmprop *alarm-subcomp
"END" ":" "VALARM" CRLF "END" ":" "VALARM" CRLF
alarmprop = ( alarmprop = (
; the following are REQUIRED, ; the following are REQUIRED
; but MUST NOT occur more than once ; but MUST NOT occur more than once
action / trigger / action / trigger /
; one set of action properties MUST be ; one set of action properties MUST be
; present and MUST match the action specified ; present and MUST match the action specified
; in the ACTION property ; in the ACTION property
actionprops / actionprops /
; the following are OPTIONAL, ; the following are OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
x-prop / iana-prop x-prop / iana-prop
) )
actionprops = *audiopropext / *disppropext / *emailpropext actionprops = *audiopropext / *disppropext / *emailpropext
audiopropext = ( audiopropext = (
; 'duration' and 'repeat' are both OPTIONAL, ; 'duration' and 'repeat' are both OPTIONAL
; and MUST NOT occur more than once each, ; and MUST NOT occur more than once each,
; but if one occurs, so MUST the other ; but if one occurs, so MUST the other
duration / repeat / duration / repeat /
; the following is OPTIONAL, ; the following is OPTIONAL
; but MUST NOT occur more than once ; but MUST NOT occur more than once
attach attach
) )
disppropext = ( disppropext = (
; the following are REQUIRED, ; the following are REQUIRED
; but MUST NOT occur more than once ; but MUST NOT occur more than once
description / description /
; 'duration' and 'repeat' are both OPTIONAL, ; 'duration' and 'repeat' are both OPTIONAL
; and MUST NOT occur more than once each, ; and MUST NOT occur more than once each,
; but if one occurs, so MUST the other ; but if one occurs, so MUST the other
duration / repeat duration / repeat
) )
emailpropext = ( emailpropext = (
; the following are all REQUIRED, ; the following are all REQUIRED
; but MUST NOT occur more than once ; but MUST NOT occur more than once
description / summary / description / summary /
; the following is REQUIRED, ; the following is REQUIRED
; and MAY occur more than once ; and MAY occur more than once
attendee / attendee /
; 'duration' and 'repeat' are both OPTIONAL, ; 'duration' and 'repeat' are both OPTIONAL
; and MUST NOT occur more than once each, ; and MUST NOT occur more than once each,
; but if one occurs, so MUST the other ; but if one occurs, so MUST the other
duration / repeat duration / repeat
; the following is OPTIONAL, ; the following is OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
attach attach
) )
alarm-subcomp = ( alarm-subcomp = (
; the following are OPTIONAL, ; the following are OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
x-comp / iana-comp x-comp / iana-comp
) )
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section anchor="uid" numbered="true" toc="default">
<section title="Alarm Unique Identifier" anchor="uid"> <name>Alarm Unique Identifier</name>
<t>This extension adds a "UID" <t>This extension adds a "UID"
property to "VALARM" components to allow a unique identifier to property to "VALARM" components to allow a unique identifier to
be specified. The value of this property can then be used to refer be specified. The value of this property can then be used to refer
uniquely to the "VALARM" component.</t> uniquely to the "VALARM" component.</t>
<t>The "UID" property defined here follows the definition in <t>The "UID" property defined here follows the definition in
Section 3.8.4.7 of <xref target="RFC5545" /> with the security <xref target="RFC5545" sectionFormat="of" section="3.8.4.7"/> with the sec
and privacy updates in Section 5.3 of <xref target="RFC7986" />. urity
In particular it MUST be a globally unique identifier that does and privacy updates in <xref target="RFC7986" sectionFormat="of" section="
5.3"/>.
In particular, it <bcp14>MUST</bcp14> be a globally unique identifier that
does
not contain any security- or privacy-sensitive information.</t> not contain any security- or privacy-sensitive information.</t>
<t>The "VALARM" component defined in <xref target="syntax" format="default
<t>The "VALARM" component defined in <xref target="syntax" /> is "/> is
extended here as: extended here as:
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
alarmprop =/ ( alarmprop =/ (
; the following is OPTIONAL, ; the following is OPTIONAL
; but MUST NOT occur more than once ; but MUST NOT occur more than once
uid uid
) )
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section anchor="RELATED" numbered="true" toc="default">
<section title="Alarm Related To" anchor="RELATED"> <name>Alarm Related To</name>
<t>It is often convenient to relate one or more "VALARM" <t>It is often convenient to relate one or more "VALARM"
components to other "VALARM" components (e.g., see <xref components to other "VALARM" components (e.g., see <xref target="snooze" f
target="snooze"/>). This can be accomplished if the "VALARM" ormat="default"/>). This can be accomplished if the "VALARM"
components each have their own "UID" property (as per <xref components each have their own "UID" property (as per <xref target="uid" f
target="uid" />).</t> ormat="default"/>).</t>
<t>This specification updates the usage of the "RELATED-TO" <t>This specification updates the usage of the "RELATED-TO"
property defined in Section 3.8.4.5 of <xref target="RFC5545" /> property defined in <xref target="RFC5545" sectionFormat="of" section="3.8 .4.5"/>
to enable its use with "VALARM" components. Specific types of to enable its use with "VALARM" components. Specific types of
relationships between "VALARM" components can be identified by relationships between "VALARM" components can be identified by
registering new values for the "RELTYPE" property parameter registering new values for the "RELTYPE" property parameter
defined in Section 3.2.15 of <xref target="RFC5545" />.</t> defined in <xref target="RFC5545" sectionFormat="of" section="3.2.15"/>.</
t>
<t>The "VALARM" component defined in <xref target="syntax" /> is <t>The "VALARM" component defined in <xref target="syntax" format="default
"/> is
extended here as: extended here as:
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
alarmprop =/ ( alarmprop =/ (
; the following is OPTIONAL, ; the following is OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
related related
) )
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Alarm Acknowledgement"> <name>Alarm Acknowledgement</name>
<t>There is currently no way for a "VALARM" component to <t>There is currently no way for a "VALARM" component to
indicate whether it has been triggered and acknowledged. With indicate whether it has been triggered and acknowledged. With
the advent of a standard client/server protocol for calendaring the advent of a standard client/server protocol for calendaring
and scheduling data (<xref target="RFC4791" />) it is quite and scheduling data (<xref target="RFC4791" format="default"/>), it is qui te
possible for an event with an alarm to exist on multiple clients possible for an event with an alarm to exist on multiple clients
in addition to the server. If each of those is responsible for in addition to the server. If each of those is responsible for
performing the action when an alarm triggers, then multiple performing the action when an alarm triggers, then multiple
"alerts" are generated by different devices. In such a "alerts" are generated by different devices. In such a
situation, a calendar user would like to be able to "dismiss" situation, a calendar user would like to be able to "dismiss"
the alarm on one device and have it automatically dismissed on the alarm on one device and have it automatically dismissed on
the others too.</t> the others, too.</t>
<t>Also, with recurring events that have alarms, it is important <t>Also, with recurring events that have alarms, it is important
to know when the last alarm in the recurring set was to know when the last alarm in the recurring set was
acknowledged, so that the client can determine whether past acknowledged so that the client can determine whether past
alarms have been missed.</t> alarms have been missed.</t>
<t>To address these needs, this specification adds an <t>To address these needs, this specification adds an
"ACKNOWLEDGED" property to "VALARM" components to indicate when "ACKNOWLEDGED" property to "VALARM" components to indicate when
the alarm was last acknowledged (or sent, if acknowledgement is the alarm was last acknowledged (or sent, if acknowledgement is
not possible). not possible).
This is defined by the This is defined by the
syntax below. syntax below.
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
alarmprop =/ ( alarmprop =/ (
; the following is OPTIONAL, ; the following is OPTIONAL
; but MUST NOT occur more than once ; but MUST NOT occur more than once
acknowledged acknowledged
) )
]]></artwork> ]]></sourcecode>
</figure></t> <section anchor="ACKNOWLEDGED" numbered="true" toc="default">
<section title="Acknowledged Property" anchor="ACKNOWLEDGED"> <name>Acknowledged Property</name>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt>Property Name:</dt>
<t hangText="Property Name:">ACKNOWLEDGED</t> <dd>ACKNOWLEDGED</dd>
<t hangText="Purpose:">This property specifies the UTC <dt>Purpose:</dt>
<dd>This property specifies the UTC
date and time at which the corresponding alarm was last date and time at which the corresponding alarm was last
sent or acknowledged.</t> sent or acknowledged.</dd>
<t hangText="Value Type:">DATE-TIME</t> <dt>Value Type:</dt>
<t hangText="Property Parameters:">IANA and non-standard <dd>DATE-TIME</dd>
property parameters can be specified on this property.</t> <dt>Property Parameters:</dt>
<t hangText="Conformance:">This property can be specified <dd>IANA and nonstandard
within "VALARM" calendar components.</t> property parameters can be specified on this property.</dd>
<t hangText="Description:">This property is used to <dt>Conformance:</dt>
<dd>This property can be specified
within "VALARM" calendar components.</dd>
<dt>Description:</dt>
<dd><t>This property is used to
specify when an alarm was last sent or acknowledged. This specify when an alarm was last sent or acknowledged. This
allows clients to determine when a pending alarm has been allows clients to determine when a pending alarm has been
acknowledged by a calendar user so that any alerts can be acknowledged by a calendar user so that any alerts can be
dismissed across multiple devices. It also allows clients dismissed across multiple devices. It also allows clients
to track repeating alarms or alarms on recurring events or to track repeating alarms or alarms on recurring events or
to-dos to ensure that the right number of missed alarms to-dos to ensure that the right number of missed alarms
can be tracked.</t> can be tracked.</t>
<t>Clients SHOULD set this property to the current <t>Clients <bcp14>SHOULD</bcp14> set this property to the current
date-time value in UTC when a calendar user acknowledges a date-time value in UTC when a calendar user acknowledges a
pending alarm. pending alarm.
Certain kinds of alarms, such as email-based alerts, might Certain kinds of alarms, such as email-based alerts, might
not provide feedback as to when the calendar user sees them. not provide feedback as to when the calendar user sees them.
For those kinds of alarms, the For those kinds of alarms, the
client SHOULD set this property when the alarm is client <bcp14>SHOULD</bcp14> set this property when the alarm is
triggered and the action successfully carried out. triggered and the action is successfully carried out.
<vspace blankLines="1" />When an alarm is triggered on a </t>
<t>When an alarm is triggered on a
client, clients can check to see if an "ACKNOWLEDGED" client, clients can check to see if an "ACKNOWLEDGED"
property is present. If it is, and the value of that property is present. If it is, and the value of that
property is greater than or equal to the computed trigger property is greater than or equal to the computed trigger
time for the alarm, then the client SHOULD NOT trigger the time for the alarm, then the client <bcp14>SHOULD NOT</bcp14> trigge r the
alarm. Similarly, if an alarm has been triggered and an alarm. Similarly, if an alarm has been triggered and an
"alert" presented to a calendar user, clients can monitor "alert" has been presented to a calendar user, clients can monitor
the iCalendar data to determine whether an "ACKNOWLEDGED" property the iCalendar data to determine whether an "ACKNOWLEDGED" property
is added or changed in the alarm component. If the value is added or changed in the alarm component. If the value
of any "ACKNOWLEDGED" property in the alarm changes and is greater of any "ACKNOWLEDGED" property in the alarm changes and is greater
than or equal to the trigger time of the alarm, then than or equal to the trigger time of the alarm, then
clients SHOULD dismiss or cancel any "alert" presented to clients <bcp14>SHOULD</bcp14> dismiss or cancel any "alert" presente d to
the calendar user.</t> the calendar user.</t>
<t hangText="Format Definition:">This property is defined </dd>
<dt>Format Definition:</dt>
<dd>
<t>This property is defined
by the following notation: by the following notation:
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF
acknowledgedparam = ( acknowledgedparam = (
; the following is OPTIONAL, ; the following is OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
(";" other-param) (";" other-param)
) )
]]></artwork> ]]></sourcecode>
</figure></t> </dd>
<t hangText="Example:">The following is an example of this property: <dt>Example:</dt>
<figure> <dd>
<artwork><![CDATA[ <t>The following is an example of this property:
</t>
<sourcecode type=""><![CDATA[
ACKNOWLEDGED:20090604T084500Z ACKNOWLEDGED:20090604T084500Z
]]></artwork> ]]></sourcecode>
</figure></t> </dd>
</list> </dl>
</t>
</section> </section>
</section> </section>
<section title="Snoozing Alarms" anchor="snooze"> <section anchor="snooze" numbered="true" toc="default">
<name>Snoozing Alarms</name>
<t>Users often want to "snooze" an alarm, and this specification <t>Users often want to "snooze" an alarm, and this specification
defines a standard approach to accomplish that.</t> defines a standard approach to accomplish that.</t>
<t>To "snooze" an alarm that has been triggered, clients <bcp14>MUST</bcp1
<t>To "snooze" an alarm that has been triggered, clients MUST do 4> do
the following: the following:
<list style='numbers'> </t>
<t>Set the "ACKNOWLEDGED" property <ol spacing="normal" type="1">
(see <xref target="ACKNOWLEDGED"/>) on the triggered alarm. <li>
<vspace blankLines="1"/> <t>Set the "ACKNOWLEDGED" property
</t> (see <xref target="ACKNOWLEDGED" format="default"/>) on the triggered al
arm.
<t>Create a new "VALARM" component (the "snooze" alarm) within </t>
</li>
<li>
<t>Create a new "VALARM" component (the "snooze" alarm) within
the parent component of the triggered alarm the parent component of the triggered alarm
(i.e., as a "sibling" component of the triggered alarm). (i.e., as a "sibling" component of the triggered alarm).
</t>
<list style='letters'> <ol spacing="normal" type="a">
<t>The new "snooze" alarm MUST be set to trigger <li>The new "snooze" alarm <bcp14>MUST</bcp14> be set to trigger
at the user's chosen "snooze" interval after the original alarm at the user's chosen "snooze" interval after the original alarm is
triggered. Clients SHOULD use an absolute "TRIGGER" property triggered. Clients <bcp14>SHOULD</bcp14> use an absolute "TRIGGER" pro
with a "DATE-TIME" value specified in UTC.</t> perty
with a "DATE-TIME" value specified in UTC.</li>
<t>The new "snooze" alarm MUST have a "RELATED-TO" property <li>The new "snooze" alarm <bcp14>MUST</bcp14> have a "RELATED-TO" p
(see <xref target="RELATED"/>) roperty
(see <xref target="RELATED" format="default"/>)
with a value set to the "UID" property value of the original with a value set to the "UID" property value of the original
"VALARM" component that was triggered. "VALARM" component that was triggered.
If the triggered "VALARM" component does not If the triggered "VALARM" component does not
already have a "UID" property, the client MUST add one. The already have a "UID" property, the client <bcp14>MUST</bcp14> add one.
"RELATED-TO" property added to the new "snooze" alarm MUST The
"RELATED-TO" property added to the new "snooze" alarm <bcp14>MUST</bcp
14>
include a "RELTYPE" property parameter with a value set to include a "RELTYPE" property parameter with a value set to
"SNOOZE" (see <xref target='SNOOZE-PARAM'/>).</t> "SNOOZE" (see <xref target="SNOOZE-PARAM" format="default"/>).</li>
</list> </ol>
</t> </li>
<li>
<t>When the "snooze" alarm is triggered, the client MUST do the <t>When the "snooze" alarm is triggered, the client <bcp14>MUST</bcp14
> do the
following: following:
<list style='letters'>
<t>Update the "ACKNOWLEDGED" property on the original related
alarm.</t>
<t>If the "snooze" alarm is itself "snoozed", the client MUST
remove the "snooze" alarm component, and return to step 2.
<vspace blankLines="1"/>
Otherwise, if the "snooze" alarm is dismissed, the client
MUST do one of the following:
<list style="symbols">
<t>Set the "ACKNOWLEDGED" property on the "snooze" alarm.</t>
<t>Remove the "snooze" alarm component.</t>
</list>
</t> </t>
</list> <ol spacing="normal" type="a">
</t> <li>Update the "ACKNOWLEDGED" property on the original related
alarm.</li>
</list> <li>
</t> <t>If the "snooze" alarm is itself "snoozed", the client <bcp14>MU
<!-- ST</bcp14>
<t>To "snooze" an alarm, clients create a new "VALARM" component remove the "snooze" alarm component and return to step 2.
within the parent component of the "VALARM" that was triggered </t>
and is being "snoozed" (i.e., as a "sibling" component of the <t>
"VALARM" being snoozed). The new "VALARM" MUST be set to trigger Otherwise, if the "snooze" alarm is dismissed, the client
at the user's chosen "snooze" interval after the original alarm <bcp14>MUST</bcp14> do one of the following:
triggered. Clients SHOULD use an absolute "TRIGGER" property </t>
with a "DATE-TIME" value specified in UTC.</t> <ul spacing="normal">
<li>Set the "ACKNOWLEDGED" property on the "snooze" alarm.</li>
<t>Clients MUST add a <li>Remove the "snooze" alarm component.</li>
"RELATED-TO" property to the new "VALARM" component with a value </ul>
set to the "UID" property value of the "VALARM" component being </li>
snoozed. If the "VALARM" component being snoozed does not </ol>
already have a "UID" property, the client MUST add one. The </li>
"RELATED-TO" property added to the new "VALARM" component MUST </ol>
include a "RELTYPE" property parameter with a value set to
"SNOOZE".</t>
<t>When the "snooze" alarm is triggered and dismissed the client
MUST do one of the following with the corresponding "VALARM" component:
<list style="symbols">
<t>Set the "ACKNOWLEDGED" property
(see <xref target="ACKNOWLEDGED"/>)</t>
<t>Remove the component</t>
</list>
Alternatively, if the "snooze" alarm
is itself "snoozed", the client MUST remove the original
"snooze" alarm and create a new one, with the appropriate
trigger time and relationship set.</t>
<t>Note that regardless of the final disposition of the "snooze" <t>Note that regardless of the final disposition of the "snooze"
alarm when triggered, the original "VALARM" component is left alarm when triggered, the original "VALARM" component is left
unchanged other than updating its "ACKNOWLEDGED" property.</t> unchanged other than updating its "ACKNOWLEDGED" property.</t>
<section anchor="SNOOZE-PARAM" numbered="true" toc="default">
<section title="Relationship Type Property Parameter" anchor="SNOOZE-PARAM <name>Relationship Type Property Parameter</name>
">
<t> <t>
This specification adds the "SNOOZE" relationship type for This specification adds the "SNOOZE" relationship type for
use with the "RELTYPE" property defined in Section 3.2.15 use with the "RELTYPE" property defined in
of <xref target="RFC5545" />. This is used when relating a <xref target="RFC5545" sectionFormat="of" section="3.2.15"/>. This i
s used when relating a
"snoozed" "VALARM" component to the original alarm that "snoozed" "VALARM" component to the original alarm that
the "snooze" was generated for. the "snooze" was generated for.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Example"> <name>Example</name>
<t>The following example shows the snoozing, re-snoozing, and <t>The following example shows the "snoozing", "re-snoozing", and
dismissal of an alarm. Note that the encompassing dismissal of an alarm. Note that the encompassing
VCALENDAR component has been omitted for brevity and that the "VCALENDAR" component has been omitted for brevity and that the
line-breaks surrounding the VALARM components are for clarity line breaks surrounding the "VALARM" components are for clarity
only and would not be present in the actual iCalendar data.</t> only and would not be present in the actual iCalendar data.</t>
<t>Assume that we have the following event with an alarm set <t>Assume that we have the following event with an alarm set
to trigger 15 minutes before the meeting: to trigger 15 minutes before the meeting:
<figure> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20210302T151004Z CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627 UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T151004Z DTSTAMP:20210302T151004Z
DTSTART;TZID=America/New_York:20210302T103000 DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000 DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting SUMMARY:Meeting
BEGIN:VALARM BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
TRIGGER:-PT15M TRIGGER:-PT15M
DESCRIPTION:Event reminder DESCRIPTION:Event reminder
ACTION:DISPLAY ACTION:DISPLAY
END:VALARM END:VALARM
END:VEVENT END:VEVENT
]]></artwork> ]]></sourcecode>
</figure> <t>When the alarm is triggered, the user decides to "snooze" it
</t>
<t>When the alarm is triggered, the user decides to snooze it
for 5 minutes. The client acknowledges the original alarm and for 5 minutes. The client acknowledges the original alarm and
creates a new "snooze" alarm as a sibling of, and relates it creates a new "snooze" alarm as a sibling of, and relates it
to, the original alarm (note that both VALARMs reside within the to, the original alarm (note that both occurrences of "VALARM" reside wi thin the
same "parent" VEVENT): same "parent" VEVENT):
<figure> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20210302T151004Z CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627 UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T151516Z DTSTAMP:20210302T151516Z
DTSTART;TZID=America/New_York:20210302T103000 DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000 DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting SUMMARY:Meeting
BEGIN:VALARM BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
skipping to change at line 570 skipping to change at line 505
BEGIN:VALARM BEGIN:VALARM
UID:DE7B5C34-83FF-47FE-BE9E-FF41AE6DD097 UID:DE7B5C34-83FF-47FE-BE9E-FF41AE6DD097
TRIGGER;VALUE=DATE-TIME:20210302T152000Z TRIGGER;VALUE=DATE-TIME:20210302T152000Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder DESCRIPTION:Event reminder
ACTION:DISPLAY ACTION:DISPLAY
END:VALARM END:VALARM
END:VEVENT END:VEVENT
]]></artwork> ]]></sourcecode>
</figure>
</t>
<t>When the "snooze" alarm is triggered, the user decides to <t>When the "snooze" alarm is triggered, the user decides to
snooze it again for an additional 5 minutes. The client "snooze" it again for an additional 5 minutes. The client
once again acknowledges the original alarm, removes the triggered once again acknowledges the original alarm, removes the triggered
"snooze" alarm, and creates another new "snooze" alarm as a "snooze" alarm, and creates another new "snooze" alarm as a
sibling of, and relates it to, the original alarm (note the sibling of, and relates it to, the original alarm (note the
different UID for the new snooze alarm): different UID for the new "snooze" alarm):
<figure> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20210302T151004Z CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627 UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T152026Z DTSTAMP:20210302T152026Z
DTSTART;TZID=America/New_York:20210302T103000 DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000 DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting SUMMARY:Meeting
BEGIN:VALARM BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
skipping to change at line 607 skipping to change at line 539
BEGIN:VALARM BEGIN:VALARM
UID:87D690A7-B5E8-4EB4-8500-491F50AFE394 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
TRIGGER;VALUE=DATE-TIME:20210302T152500Z TRIGGER;VALUE=DATE-TIME:20210302T152500Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder DESCRIPTION:Event reminder
ACTION:DISPLAY ACTION:DISPLAY
END:VALARM END:VALARM
END:VEVENT END:VEVENT
]]></artwork> ]]></sourcecode>
</figure>
</t>
<t>When the second "snooze" alarm is triggered, the user <t>When the second "snooze" alarm is triggered, the user
decides to dismiss it. The client acknowledges both the decides to dismiss it. The client acknowledges both the
original alarm and the second "snooze" alarm: original alarm and the second "snooze" alarm:
<figure> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20210302T151004Z CREATED:20210302T151004Z
UID:AC67C078-CED3-4BF5-9726-832C3749F627 UID:AC67C078-CED3-4BF5-9726-832C3749F627
DTSTAMP:20210302T152508Z DTSTAMP:20210302T152508Z
DTSTART;TZID=America/New_York:20210302T103000 DTSTART;TZID=America/New_York:20210302T103000
DTEND;TZID=America/New_York:20210302T113000 DTEND;TZID=America/New_York:20210302T113000
SUMMARY:Meeting SUMMARY:Meeting
BEGIN:VALARM BEGIN:VALARM
UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
skipping to change at line 642 skipping to change at line 571
BEGIN:VALARM BEGIN:VALARM
UID:87D690A7-B5E8-4EB4-8500-491F50AFE394 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394
TRIGGER;VALUE=DATE-TIME:20210302T152500Z TRIGGER;VALUE=DATE-TIME:20210302T152500Z
RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1
DESCRIPTION:Event reminder DESCRIPTION:Event reminder
ACTION:DISPLAY ACTION:DISPLAY
ACKNOWLEDGED:20210302T152507Z ACKNOWLEDGED:20210302T152507Z
END:VALARM END:VALARM
END:VEVENT END:VEVENT
]]></artwork> ]]></sourcecode>
</figure>
</t>
</section> </section>
</section> </section>
<section anchor="proximity" numbered="true" toc="default">
<section title="Alarm Proximity Trigger" anchor="proximity"> <name>Alarm Proximity Trigger</name>
<t>VALARMs are currently triggered when a specific date-time is <t>Currently, a "VALARM" is triggered when a specific date-time value is
reached. It is also desirable to be able to trigger alarms based reached. It is also desirable to be able to trigger alarms based
on location, e.g. when arriving at or departing from a on location, e.g., when arriving at or departing from a
particular location.</t> particular location.</t>
<t>This specification adds the following elements to "VALARM" <t>This specification adds the following elements to "VALARM"
components to indicate when an alarm can be triggered based on components to indicate when an alarm can be triggered based on
location. location.
<list> </t>
<t>"PROXIMITY" property - indicates that a location based trigger is to <dl newline="false" spacing="normal">
be used and which action is used for the trigger</t> <dt>"PROXIMITY" property:</dt>
<t><xref target="I-D.ietf-calext-eventpub-extensions"> <dd>indicates that a location-based trigger is to
"VLOCATION" component(s)</xref> - used to indicate the actual be used and which action is used for the trigger</dd>
<dt><xref target="RFC9073" format="default">
"VLOCATION" component(s)</xref>:</dt>
<dd>used to indicate the actual
location(s) to trigger off of, specified with a URL property containing a location(s) to trigger off of, specified with a URL property containing a
<xref target="RFC5870">geo: URI</xref> which allows for two or three <xref target="RFC5870" format="default">'geo' URI</xref>, which allows f
coordinate values with an optional uncertainty</t> or two or three
</list> coordinate values with an optional uncertainty</dd>
<figure> </dl>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
alarmprop =/ ( alarmprop =/ (
; the following is OPTIONAL, ; the following is OPTIONAL
; but MUST NOT occur more than once ; but MUST NOT occur more than once
proximity / proximity /
) )
alarm-subcomp =/ ( alarm-subcomp =/ (
; the following is OPTIONAL, ; the following is OPTIONAL
; and MAY occur more than once, but only ; and MAY occur more than once but only
; when a PROXIMITY property is also present ; when a PROXIMITY property is also present
locationc locationc
) )
]]></artwork> ]]></sourcecode>
</figure></t>
<t> <t>
Typically, when a "PROXIMITY" property is used there is no Typically, when a "PROXIMITY" property is used, there is no
need to specify a time-based trigger using the "TRIGGER" need to specify a time-based trigger using the "TRIGGER"
property. However, since "TRIGGER" is defined as a required property. However, since "TRIGGER" is defined as a required
property for a "VALARM" component, for backwards compatibility property for a "VALARM" component, for backwards compatibility,
it has to be present, but ignored. To indicate a "TRIGGER" it has to be present but ignored. To indicate a "TRIGGER"
that is to be ignored, clients SHOULD use a value a long time that is to be ignored, clients <bcp14>SHOULD</bcp14> use a value a long
time
in the past. A value of "19760401T005545Z" has been commonly in the past. A value of "19760401T005545Z" has been commonly
used for this purpose. used for this purpose.
</t> </t>
<section title="Proximity Property" anchor="PROXIMITY"> <section anchor="PROXIMITY" numbered="true" toc="default">
<t> <name>Proximity Property</name>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Property Name:">PROXIMITY</t> <dt>Property Name:</dt>
<t hangText="Purpose:">This property indicates that a <dd>PROXIMITY</dd>
location based trigger is applied to an alarm.</t> <dt>Purpose:</dt>
<t hangText="Value Type:">TEXT</t> <dd>This property indicates that a
<t hangText="Property Parameters:">IANA and non-standard location-based trigger is applied to an alarm.</dd>
property parameters can be specified on this property.</t> <dt>Value Type:</dt>
<t hangText="Conformance:">This property can be specified <dd>TEXT</dd>
within "VALARM" calendar components.</t> <dt>Property Parameters:</dt>
<t hangText="Description:">This property is used to <dd>IANA and nonstandard
property parameters can be specified on this property.</dd>
<dt>Conformance:</dt>
<dd>This property can be specified
within "VALARM" calendar components.</dd>
<dt>Description:</dt>
<dd><t>This property is used to
indicate that an alarm has a location-based trigger. indicate that an alarm has a location-based trigger.
Its value identifies the action that will trigger the alarm.</t> Its value identifies the action that will trigger the alarm.</t>
<t>When the property value is set to "ARRIVE", the alarm
<t>When the property value is set to "ARRIVE", the alarm
is triggered when the calendar user agent arrives in the is triggered when the calendar user agent arrives in the
vicinity of one or more locations. When set to vicinity of one or more locations. When set to
"DEPART", the alarm is triggered when the calendar user "DEPART", the alarm is triggered when the calendar user
agent departs from the vicinity of one or more locations. agent departs from the vicinity of one or more locations.
Each location which MUST be specified with a "VLOCATION" Each location <bcp14>MUST</bcp14> be specified with a "VLOCATION"
component. component.
Note that the meaning of "vicinity" in this Note that the meaning of "vicinity" in this
context is implementation defined.</t> context is implementation defined.</t>
<t>When the property value is set to "CONNECT", the alarm
<t>When the property value is set to "CONNECT", the alarm is triggered when the calendar user agent connects to an
is triggered when the calendar user agent connects to a automobile to which it has been paired via
automobile to which is has been paired via <xref target="BTcore" format="default">Bluetooth</xref>.
<xref target="BTcore">Bluetooth(R)</xref>.
When set to "DISCONNECT", the alarm is When set to "DISCONNECT", the alarm is
triggered when the calendar user agent disconnects from a triggered when the calendar user agent disconnects from an
automobile to which it has been paired via Bluetooth(R). automobile to which it has been paired via Bluetooth.
Note that neither current implementations of proximty Note that neither current implementations of proximity
alarms nor this document have a mechanism to target a alarms nor this document have a mechanism to target a
particular automobile. particular automobile.
Such a mechanism may be specified in a future extension.</t> Such a mechanism may be specified in a future extension.</t></dd>
<dt>Format Definition:</dt>
<t hangText="Format Definition:">This property is defined <dd>
<t>This property is defined
by the following notation: by the following notation:
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF
proximityparam = ( proximityparam = (
; the following is OPTIONAL, ; the following is OPTIONAL
; and MAY occur more than once ; and MAY occur more than once
(";" other-param) (";" other-param)
) )
proximityvalue = "ARRIVE" / "DEPART" / proximityvalue = "ARRIVE" / "DEPART" /
"CONNECT" / "DISCONNECT" / iana-token / x-name "CONNECT" / "DISCONNECT" / iana-token / x-name
]]></artwork> ]]></sourcecode>
</figure></t> </dd>
</list> </dl>
</t>
</section> </section>
<section title="Example"> <section numbered="true" toc="default">
<t>The following example shows a VALARM component with a <name>Example</name>
<t>The following example shows a "VALARM" component with a
proximity trigger set to trigger when the device running the proximity trigger set to trigger when the device running the
calendar user agent leaves the vicinity defined by the calendar user agent leaves the vicinity defined by the
URL property in the VLOCATION component. Note use of the "u=" parameter URL property in the "VLOCATION" component. Note use of the "u=" paramete
with the "geo" URI to define the uncertainty of the location r
with the 'geo' URI to define the uncertainty of the location
determination. determination.
<figure> </t>
<artwork name="abnf"><![CDATA[ <sourcecode type=""><![CDATA[
BEGIN:VALARM BEGIN:VALARM
UID:77D80D14-906B-4257-963F-85B1E734DBB6 UID:77D80D14-906B-4257-963F-85B1E734DBB6
ACTION:DISPLAY ACTION:DISPLAY
TRIGGER;VALUE=DATE-TIME:19760401T005545Z TRIGGER;VALUE=DATE-TIME:19760401T005545Z
DESCRIPTION:Remember to buy milk DESCRIPTION:Remember to buy milk
PROXIMITY:DEPART PROXIMITY:DEPART
BEGIN:VLOCATION BEGIN:VLOCATION
UID:123456-abcdef-98765432 UID:123456-abcdef-98765432
NAME:Office NAME:Office
URL:geo:40.443,-79.945;u=10 URL:geo:40.443,-79.945;u=10
END:VLOCATION END:VLOCATION
END:VALARM END:VALARM
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title='Security Considerations'> <name>Security Considerations</name>
<t>In addition to the security properties of iCalendar <t>In addition to the security properties of iCalendar
(see Section 7 of <xref target="RFC5545"/>), (see <xref target="RFC5545" sectionFormat="of" section="7"/>),
VALARMs, if not monitored properly, can be used to disturb a "VALARM", if not monitored properly, can be used to disturb
users and/or leak personal information. For instance, an users and/or leak personal information. For instance, an
undesirable audio alert could cause embarassment. An undesirable audio alert could cause embarrassment; an
unwanted display alert could be considered an annoyance. Or an unwanted display alert could be considered an annoyance; or an
email alert could be used to leak a user&apos;s location to a third email alert could be used to leak a user's location to a third
party or to send unsolicited email to multiple users. party or to send unsolicited email to multiple users.
Therefore, CalDAV clients and servers that accept iCalendar data Therefore, CalDAV clients and servers that accept iCalendar data
from a third party (e.g. via <xref target="RFC5546">iTIP</xref>, from a third party (e.g., via iCalendar Transport-Independent Interoperabi
a subscription feed, or a shared calendar) SHOULD remove all lity Protocol (iTIP) <xref target="RFC5546" format="default"/>,
VALARMs from the data prior to storing in their calendar system.</t> a subscription feed, or a shared calendar) <bcp14>SHOULD</bcp14> remove ea
ch
<t>Security considerations related to unique identifiers for VALARMs "VALARM" from the data prior to storing in their calendar system.</t>
are discussed in <xref target='uid'/>.</t> <t>Security considerations related to unique identifiers for "VALARM"
are discussed in <xref target="uid" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Privacy Considerations'> <name>Privacy Considerations</name>
<t>Proximity VALARMs, if not used carefully, can leak a <t>A proximity "VALARM", if not used carefully, can leak a
user&apos;s past, present, or future location. For instance, user's past, present, or future location. For instance,
storing an iCalendar resource containing proxmity VALARMs to a storing an iCalendar resource containing proximity "VALARM"s to a
shared calendar on CalDAV server can expose to anyone that has shared calendar on CalDAV server can expose to anyone that has
access to that calendar the user&apos;s intent to leave access to that calendar the user's intent to leave
from or arrive at a particular location at some future time. from or arrive at a particular location at some future time.
Furthermore, if a CalDAV client updates the shared iCalendar Furthermore, if a CalDAV client updates the shared iCalendar
resource with an ACKNOWLEDGED property when the alarm is resource with an "ACKNOWLEDGED" property when the alarm is
triggered, will leak the exact date and time that the user left triggered, this will leak the exact date and time that the user left
from or arrived at the location. from or arrived at the location.
Therefore, CalDAV clients that implement proximity alarms Therefore, CalDAV clients that implement proximity alarms
SHOULD give users the option of storing and/or acknowledging the <bcp14>SHOULD</bcp14> give users the option of storing and/or acknowledgin g the
alarms on the local device only and not storing the alarm and/or alarms on the local device only and not storing the alarm and/or
acknowledgment on a remote server.</t> acknowledgement on a remote server.</t>
<t>Privacy considerations related to unique identifiers for "VALARM"
<t>Privacy considerations related to unique identifiers for VALARMs are discussed in <xref target="uid" format="default"/>.</t>
are discussed in <xref target='uid'/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='IANA Considerations'> <name>IANA Considerations</name>
<section title='Property Registrations'> <section numbered="true" toc="default">
<name>Property Registrations</name>
<t>This document defines the following new iCalendar <t>This document defines the following new iCalendar
properties to be added to the registry defined in Section properties that have been added to the "Properties" registry defined in
8.2.3 of <xref target="RFC5545" /> and located here: <xref target="RFC5545" sectionFormat="of" section="8.2.3"/> and located
<eref target="https://www.iana.org/assignments/icalendar#properties"/> here:
<eref target="https://www.iana.org/assignments/icalendar" brackets="angl
e"/>.
</t> </t>
<texttable> <table align="center">
<ttcol>Property</ttcol> <name>Additions to the Properties Registry</name>
<ttcol>Status</ttcol> <thead>
<ttcol>Reference</ttcol> <tr>
<c>ACKNOWLEDGED</c> <th align="left">Property</th>
<c>Current</c> <th align="left">Status</th>
<c>RFCXXXX, <xref target="ACKNOWLEDGED" /></c> <th align="left">Reference</th>
<c>PROXIMITY</c> </tr>
<c>Current</c> </thead>
<c>RFCXXXX, <xref target="PROXIMITY" /></c> <tbody>
</texttable> <tr>
<td align="left">ACKNOWLEDGED</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="ACKNOWLEDGED" format="def
ault"/></td>
</tr>
<tr>
<td align="left">PROXIMITY</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="PROXIMITY" format="defaul
t"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title='Relationship Types Registry'> <name>Relationship Types Registry</name>
<t>This document defines the following new iCalendar <t>This document defines the following new iCalendar
relationship type to be added to the registry defined in relationship type that has been added to the "Relationship Types" regist
Section 8.3.8 of <xref target="RFC5545" /> and located here: ry defined in
<eref target="https://www.iana.org/assignments/icalendar#relationship-ty <xref target="RFC5545" sectionFormat="of" section="8.3.8"/> and located
pes"/> here:
<eref target="https://www.iana.org/assignments/icalendar" brackets="angl
e"/>.
</t> </t>
<texttable> <table align="center">
<ttcol>Relationship Type</ttcol> <name>Addition to the Relationship Types Registry</name>
<ttcol>Status</ttcol> <thead>
<ttcol>Reference</ttcol> <tr>
<c>SNOOZE</c> <th align="left">Relationship Type</th>
<c>Current</c> <th align="left">Status</th>
<c>RFCXXXX, <xref target="SNOOZE-PARAM" /></c> <th align="left">Reference</th>
</texttable> </tr>
</section> </thead>
<tbody>
<tr>
<td align="left">SNOOZE</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="SNOOZE-PARAM" format="def
ault"/></td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Proximity Values Registry</name>
<section title="Proximity Value Registry"> <t>A new iCalendar registry for values
<t>This document creates a new iCalendar registry for values of the "PROXIMITY" property has been created and is located here:
of the "PROXIMITY" property located here: <eref target="https://www.iana.org/assignments/icalendar" brackets="an
<eref target="https://www.iana.org/assignments/icalendar#proximity-val gle"/>.</t>
ues"/></t> <t>Additional values <bcp14>MAY</bcp14> be used, provided the process de
<t>Additional values MAY be used, provided the process described in scribed in
Section 8.2.1 of <xref target="RFC5545"/> is used to <xref target="RFC5545" sectionFormat="of" section="8.2.1"/> is used to
register them, using the template in Section 8.2.6 of register them, using the template in
<xref target="RFC5545"/>. <xref target="RFC5545" sectionFormat="of" section="8.2.6"/>.
</t> </t>
<t>The following table has been used to initialize the <t>The following table has been used to initialize the
Proximity Value Registry.</t> Proximity Value Registry.</t>
<texttable> <table align="center">
<ttcol>Value</ttcol> <name>Initial Contents of the Proximity Values Registry</name>
<ttcol>Status</ttcol> <thead>
<ttcol>Reference</ttcol> <tr>
<c>ARRIVE</c> <th align="left">Value</th>
<c>Current</c> <th align="left">Status</th>
<c>RFCXXXX, <xref target="PROXIMITY" /></c> <th align="left">Reference</th>
<c>DEPART</c> </tr>
<c>Current</c> </thead>
<c>RFCXXXX, <xref target="PROXIMITY" /></c> <tbody>
<c>CONNECT</c> <tr>
<c>Current</c> <td align="left">ARRIVE</td>
<c>RFCXXXX, <xref target="PROXIMITY" /></c> <td align="left">Current</td>
<c>DISCONNECT</c> <td align="left">RFC 9074, <xref target="PROXIMITY" format="defaul
<c>Current</c> t"/></td>
<c>RFCXXXX, <xref target="PROXIMITY" /></c> </tr>
</texttable> <tr>
<td align="left">DEPART</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="PROXIMITY" format="defaul
t"/></td>
</tr>
<tr>
<td align="left">CONNECT</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="PROXIMITY" format="defaul
t"/></td>
</tr>
<tr>
<td align="left">DISCONNECT</td>
<td align="left">Current</td>
<td align="left">RFC 9074, <xref target="PROXIMITY" format="defaul
t"/></td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section title='Acknowledgments'>
<t>This specification came about via discussions at the
Calendaring and Scheduling Consortium. Also, thanks to the
following for providing feedback: Bernard Desruisseaux, Mike
Douglass, Jacob Farkas, Jeffrey Harris, Ciny Joy, Barry Leiba,
and Daniel Migault.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
xml"/>
<references title='Normative References'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc2119; FC.5545.xml"/>
&rfc5545; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc5870; FC.5870.xml"/>
&rfc7986; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&rfc8174; FC.7986.xml"/>
&idEventPub; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.8174.xml"/>
<references title='Informative References'> <reference anchor='RFC9073' target="https://www.rfc-editor.org/info/rfc9073">
&rfc4791; <front>
&rfc5546; <title>Event Publishing Extensions to iCalendar</title>
<author initials='M' surname='Douglass' fullname='Michael Douglass'>
<organization />
</author>
<date month='August' year='2021' />
</front>
<seriesInfo name="RFC" value="9073"/>
<seriesInfo name="DOI" value="10.17487/RFC9073"/>
</reference>
<reference anchor="BTcore" </references>
target="https://www.bluetooth.com/specifications/bluetooth-core- <references>
specification"> <name>Informative References</name>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Bluetooth Core Specification Version 5.0</title> FC.4791.xml"/>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>Bluetooth Special Interest Group</organization> FC.5546.xml"/>
</author>
<date month="December" year="2016"/>
</front>
<format type="HTML"
target="https://www.bluetooth.com/specifications/bluetooth-core-s
pecification"/>
</reference>
</references>
<section title="Change History (To be removed by RFC Editor before <reference anchor="BTcore" target="https://www.bluetooth.com/bluetooth-r
publication)"> esources/bluetooth-5-
<t>Changes in ietf-06: go-faster-go-further/">
<list style='numbers'> <front>
<t>Corrected timestamps in snooze example.</t> <title>Bluetooth Core Specification Version 5.0 Feature Overview</ti
<t>Editorial changes from Benjamim Kaduk.</t> tle>
</list></t> <author>
<t>Changes in ietf-05: <organization>Bluetooth Special Interest Group</organization>
<list style='numbers'> </author>
<t>Updated to use VLOCATION components rather than <date month="December" year="2016"/>
(deprecated) STRUCTURED-LOCATION properties for proximity </front>
alarms.</t> </reference>
<t>Reorganized and clarified the process of snoozing an alarm </references>
and added an example.</t> </references>
<t>Noted that there is currently no mechanism for specifying <section numbered="false" toc="default">
a particular automobile for CONNECT/DISCONNECT proximity alarms.</t> <name>Acknowledgements</name>
<t>Replaced the term "spam" with new wording in Security <t>This specification came about via discussions at The
Considerations.</t> Calendaring and Scheduling Consortium. Also, thanks to the
<t>Addressed IESG comments from Benjamim Kaduk.</t> following for providing feedback: <contact fullname="Bernard Desruisseaux"
<t>Addressed IESG comments from Robert Wilton.</t> />, <contact fullname="Mike
<t>Addressed IESG comments Alissa Cooper.</t> Douglass"/>, <contact fullname="Jacob Farkas"/>, <contact fullname="Jeffre
</list></t> y Harris"/>, <contact
<t>Changes in ietf-04: fullname="Ciny Joy"/>, <contact fullname="Barry Leiba"/>,
<list style='numbers'> and <contact fullname="Daniel Migault"/>.</t>
<t>Addressed security review comments from Valery Smyslov.</t>
<t>Addressed Genart review comments from Roni Even.</t>
<t>Added text addressing management of Proximity Value Registry.</t>
</list></t>
<t>Changes in ietf-03:
<list style='numbers'>
<t>Fixed ABNF to be properly extended.</t>
<t>Addressed AD review comments from Barry Leiba.</t>
</list></t>
<t>Changes in ietf-02:
<list style='numbers'>
<t>Addressed some WGLC comments from Daniel Migault.</t>
</list></t>
<t>Changes in ietf-01:
<list style='numbers'>
<t>Reintroduced the RELATED-TO property for VALARMs
and the SNOOZE value for the RELTYPE property parameter.</t>
<t>Add Privacy Considerations section.</t>
</list></t>
<t>Changes in ietf-00:
<list style='numbers'>
<t>Submitted as CALEXT draft.</t>
</list></t>
<t>Changes in daboo-05:
<list style='numbers'>
<t>Added Murchison as editor.</t>
<t>Updated keywords boilerplate.</t>
<t>Added reference to UID security/privacy recommendations.</t>
<t>Removed default alarms.</t>
<t>Removed ALARM-AGENT property.</t>
<t>Added text about using TRIGGER value in the past in
addition to ACTION:NONE to have a default alarm be
ignored.</t>
<t>Removed text about related alarms.</t>
<t>Removed URL alarm action.</t>
<t>Added reference to draft-ietf-calext-eventpub-extensions
for STRUCTURED-LOCATION.</t>
<t>Added CONNECT and DISCONNECT PROXIMITY property values.</t>
<t>Added Security Considerations.</t>
<t>Editorial fixes.</t>
</list></t>
<t>Changes in daboo-04:
<list style='numbers'>
<t>Changed "ID" to "AGENT-ID".</t>
<t>Add more text on using "ACKNOWLEDGED" property.</t>
<t>Add "RELATED-TO" as a valid property for VALARMs.</t>
<t>Add "SNOOZE" relationship type for use with VALARMs.</t>
<t>State that "TRIGGER" is typically ignored in proximity alarms.</t>
<t>Added "PROXIMITY" value registry.</t>
<t>Added a lot more detail on default alarms including new
action and property.</t>
</list></t>
<t>Changes in daboo-03: none - resubmission of -02</t>
<t>Changes in daboo-02:
<list style='numbers'>
<t>Updated to 5545 reference.</t>
<t>Clarified use of absolute trigger in UTC in snooze alarms</t>
<t>Snooze alarms should be removed when completed</t>
<t>Removed status and replaced last-triggered by acknowledged
property</t>
<t>Added location-based trigger</t>
<t>IANA registry tables added</t>
</list></t>
<t>Changes in daboo-01:
<list style='numbers'>
<t>Removed DESCRIPTION as an allowed property in the URI alarm.</t>
<t>Added statement about what to do when ALARM-AGENT is not present.</t>
<t>Allow multiple ALARM-AGENT properties to be present.</t>
<t>Removed SNOOZE-UNTIL - snoozing now accomplished by
creating a new VALARM.</t>
<t>Remove VALARM by reference section.</t>
<t>Added more detail to CalDAV default alarms.</t>
</list></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 142 change blocks. 
560 lines changed or deleted 501 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/