<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'
[
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!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-extensions.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"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="5545" ipr="trust200902" docName="draft-ietf-calext-valarm-extensions-07" number="9074" obsoletes="" submissionType="IETF" category="std" updates='5545'
     ipr='trust200902' docName='draft-ietf-calext-valarm-extensions-07'> consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
tocDepth="2" version="3">

  <front>
    <title abbrev="VALARM Extensions">VALARM Extensions">&quot;VALARM&quot; Extensions for iCalendar</title>
    <seriesInfo name="RFC" value="9074"/>
    <author initials="C." surname="Daboo" fullname="Cyrus Daboo">
      <organization abbrev="Apple">Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino</city>
          <region>CA</region>
          <code>95014</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>cyrus@daboo.name</email>
        <uri>http://www.apple.com/</uri>
      </address>
    </author>
    <author role="editor" initials="K." surname="Murchison" fullname="Kenneth Murchison">
      <organization abbrev="Fastmail">Fastmail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut St, Suite 1201</street>
          <city>Philadephia</city> St</street>
	  <extaddr>Suite 1201</extaddr>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19102</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>murch@fastmailteam.com</email>
        <uri>http://www.fastmail.com/</uri>
      </address>
    </author>
    <date year="2021" month="August" />
    <area>Applications</area>
    <keyword>alarms</keyword>
    <keyword>calendaring</keyword>
    <keyword>iCalendar</keyword>
    <keyword>CalDAV</keyword>
    <abstract>
      <t>This document defines a set of extensions to the iCalendar
      VALARM
      "VALARM" component to enhance the use of alarms and improve
      interoperability between clients and servers.</t>
      <t>This document updates RFC5545.</t> RFC 5545.</t>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The <xref target="RFC5545">iCalendar</xref> specification target="RFC5545" format="default">iCalendar specification</xref>
      defines a set of components used to describe calendar data. One
      of those is the "VALARM" component component, which appears as a
      sub-component
      subcomponent of the "VEVENT" and "VTODO" components. The "VALARM"
      component is used to specify a reminder for an event or
      task. Different alarm actions are possible, as are different
      ways to specify how the alarm is triggered.</t>
      <t>As iCalendar has become more widely used and as client-server
      protocols
      protocols, such as <xref target="RFC4791">CalDAV</xref> target="RFC4791" format="default">Calendaring Extensions to WebDAV
      (CalDAV)</xref>, have
      become more prevalent, several issues with "VALARM" components
      have arisen. Most of these relate to the need to extend the
      existing "VALARM" component with new properties and behaviors to
      allow clients and servers to accomplish specific tasks in an
      interoperable manner. For example, clients typically need a way
      to specify that an alarm has been dismissed by a calendar user, user
      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
      each client implementation, leading to poor
      interoperability.</t>
      <t>This specification defines a set of extensions to "VALARM"
      components to cover common requirements for alarms not currently
      addressed in iCalendar. Each extension is defined in a separate
      section below. For the most part, each extension can be
      supported independently of the others, though others; though, in some cases cases, one
      extension will require another. In addition, this specification
      describes mechanisms by which clients can interoperably
      implement common features features, such as "snoozing".</t>
    </section>
    <section title='Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document'>
      <t>The Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target='RFC2119' /> target="RFC2119"/> <xref target='RFC8174' /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

	<t>The notation used in this memo to (re-)define iCalendar elements is the ABNF notation of <xref target="RFC5234"/> as used by <xref target="RFC5545"/>.
   Any syntax elements shown below that are not explicitly defined in this specification come from iCalendar <xref target="RFC5545"/>.</t>

      <t>When XML element types in the namespaces "DAV:" and
      "urn:ietf:params:xml:ns:caldav" are referenced in this document
      outside of the context of an XML fragment, the string "DAV:" and
      "CALDAV:" will be prefixed to the element type names names,
      respectively.</t>
    </section>
    <section title="Extensible syntax anchor="syntax" numbered="true" toc="default">
      <name>Extensible Syntax for VALARM" anchor="syntax">
      <t>Section 3.6.6 of <xref VALARM</name>
      <t><xref target="RFC5545" /> sectionFormat="of" section="3.6.6"/> defines the syntax
      for "VALARM" components and properties within them. However, as
      written, it is hard to extend this by adding, this, e.g., by adding a new
      property common to all types of alarm. alarms. Since many of the
      extensions defined in this document need to extend the base
      syntax, an alternative form for the base syntax is defined here,
      with the goal of simplifying specification of the extensions
      while augmenting the existing functionality defined in
      <xref target="RFC5545"/> target="RFC5545" format="default"/> to allow for nested sub-components subcomponents
      (as required by
      <xref target="proximity">proximity target="proximity" format="default">proximity alarm triggers</xref>).</t>
      <t>A "VALARM" calendar component is re-defined redefined by the following notation:
      <figure>
        <artwork name="abnf"><![CDATA[
      </t>

<sourcecode type="abnf"><![CDATA[
alarmcext  = "BEGIN" ":" "VALARM" CRLF
             *alarmprop *alarm-subcomp
             "END" ":" "VALARM" CRLF

alarmprop  = (

             ; the following are REQUIRED, 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, OPTIONAL
             ; and MAY occur more than once

             x-prop / iana-prop

             )

actionprops = *audiopropext / *disppropext / *emailpropext

audiopropext  = (

                ; 'duration' and 'repeat' are both OPTIONAL, OPTIONAL
                ; and MUST NOT occur more than once each,
                ; but if one occurs, so MUST the other

                duration / repeat /

                ; the following is OPTIONAL, OPTIONAL
                ; but MUST NOT occur more than once

                attach

                )

disppropext = (

              ; the following are REQUIRED, REQUIRED
              ; but MUST NOT occur more than once

              description /

              ; 'duration' and 'repeat' are both OPTIONAL, 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, REQUIRED
               ; but MUST NOT occur more than once

               description / summary /

               ; the following is REQUIRED, REQUIRED
               ; and MAY occur more than once

               attendee /

               ; 'duration' and 'repeat' are both OPTIONAL, OPTIONAL
               ; and MUST NOT occur more than once each,
               ; but if one occurs, so MUST the other

               duration / repeat

               ; the following is OPTIONAL, OPTIONAL
               ; and MAY occur more than once

               attach

               )

alarm-subcomp = (

                ; the following are OPTIONAL, OPTIONAL
                ; and MAY occur more than once

                x-comp / iana-comp

                )
]]></artwork>
      </figure></t>
]]></sourcecode>
    </section>
    <section title="Alarm anchor="uid" numbered="true" toc="default">
      <name>Alarm Unique Identifier" anchor="uid"> Identifier</name>
      <t>This extension adds a "UID"
      property to "VALARM" components to allow a unique identifier to
      be specified. The value of this property can then be used to refer
      uniquely to the "VALARM" component.</t>
      <t>The "UID" property defined here follows the definition in
      Section 3.8.4.7 of
      <xref target="RFC5545" /> sectionFormat="of" section="3.8.4.7"/> with the security
      and privacy updates in Section 5.3 of <xref target="RFC7986" />. sectionFormat="of" section="5.3"/>.
      In particular particular, it MUST <bcp14>MUST</bcp14> be a globally unique identifier that does
      not contain any security- or privacy-sensitive information.</t>
      <t>The "VALARM" component defined in <xref target="syntax" /> format="default"/> is
      extended here as:
      <figure>
        <artwork name="abnf"><![CDATA[
      </t>
<sourcecode type="abnf"><![CDATA[
alarmprop  =/ (

              ; the following is OPTIONAL, OPTIONAL
              ; but MUST NOT occur more than once

              uid

              )
]]></artwork>
      </figure></t>
]]></sourcecode>
    </section>
    <section title="Alarm anchor="RELATED" numbered="true" toc="default">
      <name>Alarm Related To" anchor="RELATED"> To</name>
      <t>It is often convenient to relate one or more "VALARM"
      components to other "VALARM" components (e.g., see <xref
      target="snooze"/>). target="snooze" format="default"/>). This can be accomplished if the "VALARM"
      components each have their own "UID" property (as per <xref target="uid" />).</t> format="default"/>).</t>
      <t>This specification updates the usage of the "RELATED-TO"
      property defined in Section 3.8.4.5 of <xref target="RFC5545" /> sectionFormat="of" section="3.8.4.5"/>
      to enable its use with "VALARM" components. Specific types of
      relationships between "VALARM" components can be identified by
      registering new values for the "RELTYPE" property parameter
      defined in Section 3.2.15 of <xref target="RFC5545" />.</t> sectionFormat="of" section="3.2.15"/>.</t>
      <t>The "VALARM" component defined in <xref target="syntax" /> format="default"/> is
      extended here as:
      <figure>
        <artwork name="abnf"><![CDATA[
      </t>
<sourcecode type="abnf"><![CDATA[
alarmprop  =/ (

              ; the following is OPTIONAL, OPTIONAL
              ; and MAY occur more than once

              related

              )
]]></artwork>
      </figure></t>
]]></sourcecode>
    </section>
    <section title="Alarm Acknowledgement"> numbered="true" toc="default">
      <name>Alarm Acknowledgement</name>
      <t>There is currently no way for a "VALARM" component to
      indicate whether it has been triggered and acknowledged. With
      the advent of a standard client/server protocol for calendaring
      and scheduling data (<xref target="RFC4791" />) format="default"/>), it is quite
      possible for an event with an alarm to exist on multiple clients
      in addition to the server. If each of those is responsible for
      performing the action when an alarm triggers, then multiple
      "alerts" are generated by different devices. In such a
      situation, a calendar user would like to be able to "dismiss"
      the alarm on one device and have it automatically dismissed on
      the others others, too.</t>
      <t>Also, with recurring events that have alarms, it is important
      to know when the last alarm in the recurring set was
      acknowledged,
      acknowledged so that the client can determine whether past
      alarms have been missed.</t>
      <t>To address these needs, this specification adds an
      "ACKNOWLEDGED" property to "VALARM" components to indicate when
      the alarm was last acknowledged (or sent, if acknowledgement is
      not possible).
      This is defined by the
      syntax below.
      <figure>
        <artwork name="abnf"><![CDATA[
      </t>
<sourcecode type="abnf"><![CDATA[
alarmprop       =/ (

                   ; the following is OPTIONAL, OPTIONAL
                   ; but MUST NOT occur more than once

                   acknowledged

                   )
]]></artwork>
      </figure></t>
]]></sourcecode>
      <section title="Acknowledged Property" anchor="ACKNOWLEDGED">
        <t>
          <list style="hanging">
            <t hangText="Property Name:">ACKNOWLEDGED</t>
            <t hangText="Purpose:">This anchor="ACKNOWLEDGED" numbered="true" toc="default">
        <name>Acknowledged Property</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>ACKNOWLEDGED</dd>
          <dt>Purpose:</dt>
          <dd>This property specifies the UTC
            date and time at which the corresponding alarm was last
            sent or acknowledged.</t>
            <t hangText="Value Type:">DATE-TIME</t>
            <t hangText="Property Parameters:">IANA acknowledged.</dd>
          <dt>Value Type:</dt>
          <dd>DATE-TIME</dd>
          <dt>Property Parameters:</dt>
          <dd>IANA and non-standard nonstandard
            property parameters can be specified on this property.</t>
            <t hangText="Conformance:">This property.</dd>
          <dt>Conformance:</dt>
          <dd>This property can be specified
            within "VALARM" calendar components.</t>
            <t hangText="Description:">This components.</dd>
          <dt>Description:</dt>
          <dd><t>This property is used to
            specify when an alarm was last sent or acknowledged. This
            allows clients to determine when a pending alarm has been
            acknowledged by a calendar user so that any alerts can be
            dismissed across multiple devices. It also allows clients
            to track repeating alarms or alarms on recurring events or
            to-dos to ensure that the right number of missed alarms
            can be tracked.</t>
            <t>Clients SHOULD <bcp14>SHOULD</bcp14> set this property to the current
            date-time value in UTC when a calendar user acknowledges a
            pending alarm.
            Certain kinds of alarms, such as email-based alerts, might
            not provide feedback as to when the calendar user sees them.
            For those kinds of alarms, the
            client SHOULD <bcp14>SHOULD</bcp14> set this property when the alarm is
            triggered and the action is successfully carried out.
            <vspace blankLines="1" />When
            </t>
            <t>When an alarm is triggered on a
            client, clients can check to see if an "ACKNOWLEDGED"
            property is present. If it is, and the value of that
            property is greater than or equal to the computed trigger
            time for the alarm, then the client SHOULD NOT <bcp14>SHOULD NOT</bcp14> trigger the
            alarm. Similarly, if an alarm has been triggered and an
            "alert" has been presented to a calendar user, clients can monitor
            the iCalendar data to determine whether an "ACKNOWLEDGED" property
            is 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 <bcp14>SHOULD</bcp14> dismiss or cancel any "alert" presented to
            the calendar user.</t>
            <t hangText="Format Definition:">This
          </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t>This property is defined
            by the following notation:
            <figure>
              <artwork name="abnf"><![CDATA[
            </t>
<sourcecode type="abnf"><![CDATA[
acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF

acknowledgedparam  = (

                     ; the following is OPTIONAL, OPTIONAL
                     ; and MAY occur more than once

                     (";" other-param)

                     )
]]></artwork>
            </figure></t>
            <t hangText="Example:">The
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t>The following is an example of this property:
            <figure>
              <artwork><![CDATA[
ACKNOWLEDGED:20090604T084500Z
]]></artwork>
            </figure></t>
          </list>
            </t>
<sourcecode type=""><![CDATA[
ACKNOWLEDGED:20090604T084500Z
]]></sourcecode>
          </dd>
        </dl>
      </section>
    </section>
    <section title="Snoozing Alarms" anchor="snooze"> anchor="snooze" numbered="true" toc="default">
      <name>Snoozing Alarms</name>
      <t>Users often want to "snooze" an alarm, and this specification
      defines a standard approach to accomplish that.</t>
      <t>To "snooze" an alarm that has been triggered, clients MUST <bcp14>MUST</bcp14> do
      the following:

      <list style='numbers'>

      </t>
      <ol spacing="normal" type="1">
	<li>
          <t>Set the "ACKNOWLEDGED" property
        (see <xref target="ACKNOWLEDGED"/>) target="ACKNOWLEDGED" format="default"/>) on the triggered alarm.
        <vspace blankLines="1"/>
          </t>
        </li>
        <li>
          <t>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).

        <list style='letters'>
          <t>The
          </t>
          <ol spacing="normal" type="a">
	    <li>The new "snooze" alarm MUST <bcp14>MUST</bcp14> be set to trigger
          at the user's chosen "snooze" interval after the original alarm is
          triggered. Clients SHOULD <bcp14>SHOULD</bcp14> use an absolute "TRIGGER" property
          with a "DATE-TIME" value specified in UTC.</t>

          <t>The UTC.</li>
            <li>The new "snooze" alarm MUST <bcp14>MUST</bcp14> have a "RELATED-TO" property
          (see <xref target="RELATED"/>) target="RELATED" format="default"/>)
          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 <bcp14>MUST</bcp14> add one. The
          "RELATED-TO" property added to the new "snooze" alarm MUST <bcp14>MUST</bcp14>
          include a "RELTYPE" property parameter with a value set to
          "SNOOZE" (see <xref target='SNOOZE-PARAM'/>).</t>
        </list>
        </t> target="SNOOZE-PARAM" format="default"/>).</li>
          </ol>
        </li>
        <li>
          <t>When the "snooze" alarm is triggered, the client MUST <bcp14>MUST</bcp14> do the
        following:

        <list style='letters'>
          <t>Update
          </t>
          <ol spacing="normal" type="a">
	    <li>Update the "ACKNOWLEDGED" property on the original related
          alarm.</t>
          alarm.</li>
            <li>
              <t>If the "snooze" alarm is itself "snoozed", the client MUST <bcp14>MUST</bcp14>
          remove the "snooze" alarm component, component and return to step 2.
          <vspace blankLines="1"/>
              </t>
              <t>
          Otherwise, if the "snooze" alarm is dismissed, the client
          MUST
          <bcp14>MUST</bcp14> do one of the following:
          <list style="symbols">
            <t>Set
              </t>
              <ul spacing="normal">
                <li>Set the "ACKNOWLEDGED" property on the "snooze" alarm.</t>
            <t>Remove alarm.</li>
                <li>Remove the "snooze" alarm component.</t>
          </list>
          </t>
        </list>
        </t>

      </list>
      </t>
<!--
      <t>To "snooze" an alarm, clients create a new "VALARM" component
      within the parent component of the "VALARM" component.</li>
              </ul>
            </li>
          </ol>
        </li>
      </ol>

      <t>Note that was triggered
      and is being "snoozed" (i.e., as a "sibling" component regardless of the
      "VALARM" being snoozed). The new "VALARM" MUST be set to trigger
      at final disposition of the user's chosen "snooze" interval after
      alarm when triggered, the original alarm
      triggered. Clients SHOULD "VALARM" component is left
      unchanged other than updating its "ACKNOWLEDGED" property.</t>
      <section anchor="SNOOZE-PARAM" numbered="true" toc="default">
        <name>Relationship Type Property Parameter</name>
        <t>
            This specification adds the "SNOOZE" relationship type for
            use an absolute "TRIGGER" property with a "DATE-TIME" value specified the "RELTYPE" property defined in UTC.</t>

      <t>Clients MUST add
            <xref target="RFC5545" sectionFormat="of" section="3.2.15"/>. This is used when relating a
      "RELATED-TO" property to the new
            "snoozed" "VALARM" component with a value
      set to the "UID" property value original alarm that
            the "snooze" was generated for.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Example</name>
        <t>The following example shows the "snoozing", "re-snoozing", and
        dismissal of an alarm.  Note that the "VALARM" component being
      snoozed. If the "VALARM" component being snoozed does not
      already have a "UID" property, the client MUST add one. The
      "RELATED-TO" property added to the new "VALARM" component MUST
      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"
      alarm when triggered, the original "VALARM" component is left
      unchanged other than updating its "ACKNOWLEDGED" property.</t>

      <section title="Relationship Type Property Parameter" anchor="SNOOZE-PARAM">
        <t>
            This specification adds the "SNOOZE" relationship type for
            use with the "RELTYPE" property defined in Section 3.2.15
            of <xref target="RFC5545" />. This is used when relating a
            "snoozed" "VALARM" component to the original alarm that
            the "snooze" was generated for.
        </t>
      </section>

      <section title="Example">
        <t>The following example shows the snoozing, re-snoozing, and
        dismissal of an alarm.  Note that the encompassing
        VCALENDAR encompassing
        "VCALENDAR" component has been omitted for brevity and that the
        line-breaks
        line breaks surrounding the VALARM "VALARM" components are for clarity
        only and would not be present in the actual iCalendar data.</t>
        <t>Assume that we have the following event with an alarm set
        to trigger 15 minutes before the meeting:
        <figure>
          <artwork><![CDATA[
        </t>
<sourcecode type=""><![CDATA[
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
]]></artwork>
        </figure>
        </t>
]]></sourcecode>
        <t>When the alarm is triggered, the user decides to snooze "snooze" it
        for 5 minutes.  The client acknowledges the original alarm and
        creates a new "snooze" alarm as a sibling of, and relates it
        to, the original alarm (note that both VALARMs occurrences of "VALARM" reside within the
        same "parent" VEVENT):
        <figure>
          <artwork><![CDATA[
        </t>
<sourcecode type=""><![CDATA[
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
]]></artwork>
        </figure>
        </t>
]]></sourcecode>
        <t>When the "snooze" alarm is triggered, the user decides to
        snooze
        "snooze" it again for an additional 5 minutes.  The client
        once again acknowledges the original alarm, removes the triggered
        "snooze" alarm, and creates another new "snooze" alarm as a
        sibling of, and relates it to, the original alarm (note the
        different UID for the new snooze "snooze" alarm):
        <figure>
          <artwork><![CDATA[
        </t>
<sourcecode type=""><![CDATA[
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
]]></artwork>
        </figure>
        </t>
]]></sourcecode>
        <t>When the second "snooze" alarm is triggered, the user
        decides to dismiss it.  The client acknowledges both the
        original alarm and the second "snooze" alarm:
        <figure>
          <artwork><![CDATA[
        </t>
<sourcecode type=""><![CDATA[
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
]]></artwork>
        </figure>
        </t>
]]></sourcecode>
      </section>
    </section>
    <section title="Alarm anchor="proximity" numbered="true" toc="default">
      <name>Alarm Proximity Trigger" anchor="proximity">
      <t>VALARMs are currently Trigger</name>
      <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
      on location, e.g. e.g., when arriving at or departing from a
      particular location.</t>
      <t>This specification adds the following elements to "VALARM"
      components to indicate when an alarm can be triggered based on
      location.
      <list>
        <t>"PROXIMITY" property - indicates
      </t>
      <dl newline="false" spacing="normal">
        <dt>"PROXIMITY" property:</dt>
	<dd>indicates that a location based location-based trigger is to
        be used and which action is used for the trigger</t>
        <t><xref target="I-D.ietf-calext-eventpub-extensions"> trigger</dd>
          <dt><xref target="RFC9073" format="default">
        "VLOCATION" component(s)</xref> - used component(s)</xref>:</dt>
	<dd>used to indicate the actual
        location(s) to trigger off of, specified with a URL property containing a
        <xref target="RFC5870">geo: URI</xref> target="RFC5870" format="default">'geo' URI</xref>, which allows for two or three
        coordinate values with an optional uncertainty</t>
      </list>
      <figure>
        <artwork name="abnf"><![CDATA[ uncertainty</dd>
      </dl>
<sourcecode type="abnf"><![CDATA[
alarmprop       =/ (

                   ; the following is OPTIONAL, OPTIONAL
                   ; but MUST NOT occur more than once

                   proximity /

                   )

alarm-subcomp   =/ (

                   ; the following is OPTIONAL, OPTIONAL
                   ; and MAY occur more than once, once but only
                   ; when a PROXIMITY property is also present

                   locationc

                   )
]]></artwork>
      </figure></t>
]]></sourcecode>
      <t>
        Typically, when a "PROXIMITY" property is used used, there is no
        need to specify a time-based trigger using the "TRIGGER"
        property. However, since "TRIGGER" is defined as a required
        property for a "VALARM" component, for backwards compatibility compatibility,
        it has to be present, present but ignored. To indicate a "TRIGGER"
        that is to be ignored, clients SHOULD <bcp14>SHOULD</bcp14> use a value a long time
        in the past. A value of "19760401T005545Z" has been commonly
        used for this purpose.
      </t>
      <section title="Proximity Property" anchor="PROXIMITY">
        <t>
          <list style="hanging">
            <t hangText="Property Name:">PROXIMITY</t>
            <t hangText="Purpose:">This anchor="PROXIMITY" numbered="true" toc="default">
        <name>Proximity Property</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>PROXIMITY</dd>
          <dt>Purpose:</dt>
          <dd>This property indicates that a
            location based
            location-based trigger is applied to an alarm.</t>
            <t hangText="Value Type:">TEXT</t>
            <t hangText="Property Parameters:">IANA alarm.</dd>
          <dt>Value Type:</dt>
          <dd>TEXT</dd>
          <dt>Property Parameters:</dt>
          <dd>IANA and non-standard nonstandard
            property parameters can be specified on this property.</t>
            <t hangText="Conformance:">This property.</dd>
          <dt>Conformance:</dt>
          <dd>This property can be specified
            within "VALARM" calendar components.</t>
            <t hangText="Description:">This components.</dd>
          <dt>Description:</dt>
          <dd><t>This property is used to
            indicate that an alarm has a location-based trigger.
            Its value identifies the action that will trigger the alarm.</t>
	    <t>When the property value is set to "ARRIVE", the alarm
            is triggered when the calendar user agent arrives in the
            vicinity of one or more locations.  When set to
            "DEPART", the alarm is triggered when the calendar user
            agent departs from the vicinity of one or more locations.
            Each location which MUST <bcp14>MUST</bcp14> be specified with a "VLOCATION"
            component.
            Note that the meaning of "vicinity" in this
            context is implementation defined.</t>
	    <t>When the property value is set to "CONNECT", the alarm
            is triggered when the calendar user agent connects to a an
            automobile to which is it has been paired via
            <xref target="BTcore">Bluetooth(R)</xref>. target="BTcore" format="default">Bluetooth</xref>.
            When set to "DISCONNECT", the alarm is
            triggered when the calendar user agent disconnects from a an
            automobile to which it has been paired via Bluetooth(R). Bluetooth.
            Note that neither current implementations of proximty proximity
            alarms nor this document have a mechanism to target a
            particular automobile.
            Such a mechanism may be specified in a future extension.</t>

            <t hangText="Format Definition:">This extension.</t></dd>
          <dt>Format Definition:</dt>
          <dd>
            <t>This property is defined
            by the following notation:
            <figure>
              <artwork name="abnf"><![CDATA[
            </t>
<sourcecode type="abnf"><![CDATA[
proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF

proximityparam  = (

                  ; the following is OPTIONAL, OPTIONAL
                  ; and MAY occur more than once

                  (";" other-param)

                  )

proximityvalue  = "ARRIVE" / "DEPART" /
                  "CONNECT" / "DISCONNECT" / iana-token / x-name
]]></artwork>
            </figure></t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
      <section title="Example"> numbered="true" toc="default">
        <name>Example</name>
        <t>The following example shows a VALARM "VALARM" component with a
        proximity trigger set to trigger when the device running the
        calendar user agent leaves the vicinity defined by the
        URL property in the VLOCATION "VLOCATION" component. Note use of the "u=" parameter
        with the "geo" 'geo' URI to define the uncertainty of the location
        determination.
            <figure>
              <artwork name="abnf"><![CDATA[
        </t>
<sourcecode type=""><![CDATA[
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
]]></artwork>
            </figure></t>
]]></sourcecode>
      </section>
    </section>
    <section title='Security Considerations'> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>In addition to the security properties of iCalendar
      (see Section 7 of <xref target="RFC5545"/>),
      VALARMs, target="RFC5545" sectionFormat="of" section="7"/>),
      a "VALARM", if not monitored properly, can be used to disturb
      users and/or leak personal information.  For instance, an
      undesirable audio alert could cause embarassment.  An embarrassment; an
      unwanted display alert could be considered an annoyance.  Or annoyance; or an
      email alert could be used to leak a user&apos;s user's location to a third
      party or to send unsolicited email to multiple users.
      Therefore, CalDAV clients and servers that accept iCalendar data
      from a third party (e.g. (e.g., via iCalendar Transport-Independent Interoperability Protocol (iTIP) <xref target="RFC5546">iTIP</xref>, target="RFC5546" format="default"/>,
      a subscription feed, or a shared calendar) SHOULD <bcp14>SHOULD</bcp14> remove all
      VALARMs each
      "VALARM" from the data prior to storing in their calendar system.</t>
      <t>Security considerations related to unique identifiers for VALARMs "VALARM"
      are discussed in <xref target='uid'/>.</t> target="uid" format="default"/>.</t>
    </section>
    <section title='Privacy Considerations'>
      <t>Proximity VALARMs, numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>A proximity "VALARM", if not used carefully, can leak a
      user&apos;s
      user's past, present, or future location.  For instance,
      storing an iCalendar resource containing proxmity VALARMs proximity "VALARM"s to a
      shared calendar on CalDAV server can expose to anyone that has
      access to that calendar the user&apos;s user's intent to leave
      from or arrive at a particular location at some future time.
      Furthermore, if a CalDAV client updates the shared iCalendar
      resource with an ACKNOWLEDGED "ACKNOWLEDGED" property when the alarm is
      triggered, this will leak the exact date and time that the user left
      from or arrived at the location.

      Therefore, CalDAV clients that implement proximity alarms
      SHOULD
      <bcp14>SHOULD</bcp14> give users the option of storing and/or acknowledging the
      alarms on the local device only and not storing the alarm and/or
      acknowledgment
      acknowledgement on a remote server.</t>
      <t>Privacy considerations related to unique identifiers for VALARMs "VALARM"
      are discussed in <xref target='uid'/>.</t> target="uid" format="default"/>.</t>
    </section>
    <section title='IANA Considerations'>
      <section title='Property Registrations'> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>Property Registrations</name>
        <t>This document defines the following new iCalendar
        properties to be that have been added to the "Properties" registry defined in Section
        8.2.3 of
        <xref target="RFC5545" /> sectionFormat="of" section="8.2.3"/> and located here:
        <eref target="https://www.iana.org/assignments/icalendar#properties"/> target="https://www.iana.org/assignments/icalendar" brackets="angle"/>.
        </t>
        <texttable>
          <ttcol>Property</ttcol>
          <ttcol>Status</ttcol>
          <ttcol>Reference</ttcol>
          <c>ACKNOWLEDGED</c>
          <c>Current</c>
          <c>RFCXXXX,
        <table align="center">
	  <name>Additions to the Properties Registry</name>
          <thead>
            <tr>
              <th align="left">Property</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ACKNOWLEDGED</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="ACKNOWLEDGED" /></c>
          <c>PROXIMITY</c>
          <c>Current</c>
          <c>RFCXXXX, format="default"/></td>
            </tr>
            <tr>
              <td align="left">PROXIMITY</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="PROXIMITY" /></c>
        </texttable> format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title='Relationship numbered="true" toc="default">
        <name>Relationship Types Registry'> Registry</name>
        <t>This document defines the following new iCalendar
        relationship type to be that has been added to the "Relationship Types" registry defined in
        Section 8.3.8 of
        <xref target="RFC5545" /> sectionFormat="of" section="8.3.8"/> and located here:
        <eref target="https://www.iana.org/assignments/icalendar#relationship-types"/> target="https://www.iana.org/assignments/icalendar" brackets="angle"/>.
        </t>
        <texttable>
          <ttcol>Relationship Type</ttcol>
          <ttcol>Status</ttcol>
          <ttcol>Reference</ttcol>
          <c>SNOOZE</c>
          <c>Current</c>
          <c>RFCXXXX,
        <table align="center">
	  <name>Addition to the Relationship Types Registry</name>
          <thead>
            <tr>
              <th align="left">Relationship Type</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">SNOOZE</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="SNOOZE-PARAM" /></c>
        </texttable> format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Proximity Value Registry">
          <t>This document creates a numbered="true" toc="default">
        <name>Proximity Values Registry</name>

        <t>A new iCalendar registry for values
          of the "PROXIMITY" property has been created and is located here:
          <eref target="https://www.iana.org/assignments/icalendar#proximity-values"/></t> target="https://www.iana.org/assignments/icalendar" brackets="angle"/>.</t>
        <t>Additional values MAY <bcp14>MAY</bcp14> be used, provided the process described in
          Section 8.2.1 of
          <xref target="RFC5545"/> target="RFC5545" sectionFormat="of" section="8.2.1"/> is used to
          register them, using the template in Section 8.2.6 of
          <xref target="RFC5545"/>. target="RFC5545" sectionFormat="of" section="8.2.6"/>.
        </t>
        <t>The following table has been used to initialize the
          Proximity Value Registry.</t>
        <texttable>
          <ttcol>Value</ttcol>
          <ttcol>Status</ttcol>
          <ttcol>Reference</ttcol>
          <c>ARRIVE</c>
          <c>Current</c>
          <c>RFCXXXX,
          <table align="center">
	     <name>Initial Contents of the Proximity Values Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ARRIVE</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="PROXIMITY" /></c>
          <c>DEPART</c>
          <c>Current</c>
          <c>RFCXXXX, format="default"/></td>
            </tr>
            <tr>
              <td align="left">DEPART</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="PROXIMITY" /></c>
          <c>CONNECT</c>
          <c>Current</c>
          <c>RFCXXXX, format="default"/></td>
            </tr>
            <tr>
              <td align="left">CONNECT</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="PROXIMITY" /></c>
          <c>DISCONNECT</c>
          <c>Current</c>
          <c>RFCXXXX, format="default"/></td>
            </tr>
            <tr>
              <td align="left">DISCONNECT</td>
              <td align="left">Current</td>
              <td align="left">RFC 9074, <xref target="PROXIMITY" /></c>
        </texttable> format="default"/></td>
            </tr>
          </tbody>
        </table>
      </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>
  <back>

    <references title='Normative References'>
      &rfc2119;
      &rfc5545;
      &rfc5870;
      &rfc7986;
      &rfc8174;
      &idEventPub;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5870.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor='RFC9073' target="https://www.rfc-editor.org/info/rfc9073">
<front>
<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>

      </references>

    <references title='Informative References'>
      &rfc4791;
      &rfc5546;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4791.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5546.xml"/>

        <reference anchor="BTcore"
		 target="https://www.bluetooth.com/specifications/bluetooth-core-specification"> target="https://www.bluetooth.com/bluetooth-resources/bluetooth-5-
	      go-faster-go-further/">
          <front>
            <title>Bluetooth Core Specification Version 5.0</title> 5.0 Feature Overview</title>
            <author>
              <organization>Bluetooth Special Interest Group</organization>
            </author>
            <date month="December" year="2016"/>
          </front>
	<format type="HTML"
	        target="https://www.bluetooth.com/specifications/bluetooth-core-specification"/>
        </reference>
      </references>
    </references>
    <section title="Change History (To be removed by RFC Editor before
                    publication)">
      <t>Changes in ietf-06:
      <list style='numbers'>
        <t>Corrected timestamps in snooze example.</t>
        <t>Editorial changes from Benjamim Kaduk.</t>
      </list></t>
      <t>Changes in ietf-05:
      <list style='numbers'>
        <t>Updated to use VLOCATION components rather than
        (deprecated) STRUCTURED-LOCATION properties for proximity
        alarms.</t>
        <t>Reorganized and clarified the process of snoozing an alarm
        and added an example.</t>
        <t>Noted that there is currently no mechanism for specifying
        a particular automobile for CONNECT/DISCONNECT proximity alarms.</t>
        <t>Replaced the term "spam" with new wording in Security
        Considerations.</t>
        <t>Addressed IESG comments from Benjamim Kaduk.</t>
        <t>Addressed IESG comments from Robert Wilton.</t>
        <t>Addressed IESG comments Alissa Cooper.</t>
      </list></t>
      <t>Changes in ietf-04:
      <list style='numbers'>
        <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 numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>This specification came 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 via discussions at The
      Calendaring 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" Scheduling Consortium. Also, thanks 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>
      following for providing feedback: <contact fullname="Bernard Desruisseaux"/>, <contact fullname="Mike
      Douglass"/>, <contact fullname="Jacob Farkas"/>, <contact fullname="Jeffrey Harris"/>, <contact
      fullname="Ciny Joy"/>, <contact fullname="Barry Leiba"/>,
      and <contact fullname="Daniel Migault"/>.</t>
    </section>

  </back>
</rfc>