idnits 2.17.1 draft-ietf-calext-valarm-extensions-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2021) is 1147 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-calext-eventpub-extensions-18 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple 4 Updates: 5545 (if approved) K. Murchison, Ed. 5 Intended status: Standards Track Fastmail 6 Expires: September 4, 2021 March 3, 2021 8 VALARM Extensions for iCalendar 9 draft-ietf-calext-valarm-extensions-07 11 Abstract 13 This document defines a set of extensions to the iCalendar VALARM 14 component to enhance use of alarms and improve interoperability 15 between clients and servers. 17 This document updates RFC5545. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 4, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Extensible syntax for VALARM . . . . . . . . . . . . . . . . 3 56 4. Alarm Unique Identifier . . . . . . . . . . . . . . . . . . . 5 57 5. Alarm Related To . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Alarm Acknowledgement . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Acknowledged Property . . . . . . . . . . . . . . . . . . 7 60 7. Snoozing Alarms . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Relationship Type Property Parameter . . . . . . . . . . 9 62 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Alarm Proximity Trigger . . . . . . . . . . . . . . . . . . . 13 64 8.1. Proximity Property . . . . . . . . . . . . . . . . . . . 14 65 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 11.1. Property Registrations . . . . . . . . . . . . . . . . . 17 70 11.2. Relationship Types Registry . . . . . . . . . . . . . . 17 71 11.3. Proximity Value Registry . . . . . . . . . . . . . . . . 17 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 13.2. Informative References . . . . . . . . . . . . . . . . . 19 76 Appendix A. Change History (To be removed by RFC Editor before 77 publication) . . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 The iCalendar [RFC5545] specification defines a set of components 83 used to describe calendar data. One of those is the "VALARM" 84 component which appears as a sub-component of "VEVENT" and "VTODO" 85 components. The "VALARM" component is used to specify a reminder for 86 an event or task. Different alarm actions are possible, as are 87 different ways to specify how the alarm is triggered. 89 As iCalendar has become more widely used and as client-server 90 protocols such as CalDAV [RFC4791] have become more prevalent, 91 several issues with "VALARM" components have arisen. Most of these 92 relate to the need to extend the existing "VALARM" component with new 93 properties and behaviors to allow clients and servers to accomplish 94 specific tasks in an interoperable manner. For example, clients 95 typically need a way to specify that an alarm has been dismissed by a 96 calendar user, or has been "snoozed" by a set amount of time. To 97 date, this has been done through the use of custom "X-" properties 98 specific to each client implementation, leading to poor 99 interoperability. 101 This specification defines a set of extensions to "VALARM" components 102 to cover common requirements for alarms not currently addressed in 103 iCalendar. Each extension is defined in a separate section below. 104 For the most part, each extension can be supported independently of 105 the others, though in some cases one extension will require another. 106 In addition, this specification describes mechanisms by which clients 107 can interoperably implement common features such as "snoozing". 109 2. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 When XML element types in the namespaces "DAV:" and 118 "urn:ietf:params:xml:ns:caldav" are referenced in this document 119 outside of the context of an XML fragment, the string "DAV:" and 120 "CALDAV:" will be prefixed to the element type names respectively. 122 3. Extensible syntax for VALARM 124 Section 3.6.6 of [RFC5545] defines the syntax for "VALARM" components 125 and properties within them. However, as written, it is hard to 126 extend this by adding, e.g., a new property common to all types of 127 alarm. Since many of the extensions defined in this document need to 128 extend the base syntax, an alternative form for the base syntax is 129 defined here, with the goal of simplifying specification of the 130 extensions while augmenting the existing functionality defined in 131 [RFC5545] to allow for nested sub-components (as required by 132 proximity alarm triggers (Section 8)). 134 A "VALARM" calendar component is re-defined by the following 135 notation: 137 alarmcext = "BEGIN" ":" "VALARM" CRLF 138 *alarmprop *alarm-subcomp 139 "END" ":" "VALARM" CRLF 141 alarmprop = ( 143 ; the following are REQUIRED, 144 ; but MUST NOT occur more than once 146 action / trigger / 148 ; one set of action properties MUST be 149 ; present and MUST match the action specified 150 ; in the ACTION property 152 actionprops / 154 ; the following are OPTIONAL, 155 ; and MAY occur more than once 157 x-prop / iana-prop 159 ) 161 actionprops = *audiopropext / *disppropext / *emailpropext 163 audiopropext = ( 165 ; 'duration' and 'repeat' are both OPTIONAL, 166 ; and MUST NOT occur more than once each, 167 ; but if one occurs, so MUST the other 169 duration / repeat / 171 ; the following is OPTIONAL, 172 ; but MUST NOT occur more than once 174 attach 176 ) 178 disppropext = ( 180 ; the following are REQUIRED, 181 ; but MUST NOT occur more than once 183 description / 185 ; 'duration' and 'repeat' are both OPTIONAL, 186 ; and MUST NOT occur more than once each, 187 ; but if one occurs, so MUST the other 189 duration / repeat 191 ) 193 emailpropext = ( 195 ; the following are all REQUIRED, 196 ; but MUST NOT occur more than once 198 description / summary / 200 ; the following is REQUIRED, 201 ; and MAY occur more than once 203 attendee / 205 ; 'duration' and 'repeat' are both OPTIONAL, 206 ; and MUST NOT occur more than once each, 207 ; but if one occurs, so MUST the other 209 duration / repeat 211 ; the following is OPTIONAL, 212 ; and MAY occur more than once 214 attach 216 ) 218 alarm-subcomp = ( 220 ; the following are OPTIONAL, 221 ; and MAY occur more than once 223 x-comp / iana-comp 225 ) 227 4. Alarm Unique Identifier 229 This extension adds a "UID" property to "VALARM" components to allow 230 a unique identifier to be specified. The value of this property can 231 then be used to refer uniquely to the "VALARM" component. 233 The "UID" property defined here follows the definition in 234 Section 3.8.4.7 of [RFC5545] with the security and privacy updates in 235 Section 5.3 of [RFC7986]. In particular it MUST be a globally unique 236 identifier that does not contain any security- or privacy-sensitive 237 information. 239 The "VALARM" component defined in Section 3 is extended here as: 241 alarmprop =/ ( 243 ; the following is OPTIONAL, 244 ; but MUST NOT occur more than once 246 uid 248 ) 250 5. Alarm Related To 252 It is often convenient to relate one or more "VALARM" components to 253 other "VALARM" components (e.g., see Section 7). This can be 254 accomplished if the "VALARM" components each have their own "UID" 255 property (as per Section 4). 257 This specification updates the usage of the "RELATED-TO" property 258 defined in Section 3.8.4.5 of [RFC5545] to enable its use with 259 "VALARM" components. Specific types of relationships between 260 "VALARM" components can be identified by registering new values for 261 the "RELTYPE" property parameter defined in Section 3.2.15 of 262 [RFC5545]. 264 The "VALARM" component defined in Section 3 is extended here as: 266 alarmprop =/ ( 268 ; the following is OPTIONAL, 269 ; and MAY occur more than once 271 related 273 ) 275 6. Alarm Acknowledgement 277 There is currently no way for a "VALARM" component to indicate 278 whether it has been triggered and acknowledged. With the advent of a 279 standard client/server protocol for calendaring and scheduling data 280 ([RFC4791]) it is quite possible for an event with an alarm to exist 281 on multiple clients in addition to the server. If each of those is 282 responsible for performing the action when an alarm triggers, then 283 multiple "alerts" are generated by different devices. In such a 284 situation, a calendar user would like to be able to "dismiss" the 285 alarm on one device and have it automatically dismissed on the others 286 too. 288 Also, with recurring events that have alarms, it is important to know 289 when the last alarm in the recurring set was acknowledged, so that 290 the client can determine whether past alarms have been missed. 292 To address these needs, this specification adds an "ACKNOWLEDGED" 293 property to "VALARM" components to indicate when the alarm was last 294 acknowledged (or sent, if acknowledgement is not possible). This is 295 defined by the syntax below. 297 alarmprop =/ ( 299 ; the following is OPTIONAL, 300 ; but MUST NOT occur more than once 302 acknowledged 304 ) 306 6.1. Acknowledged Property 308 Property Name: ACKNOWLEDGED 310 Purpose: This property specifies the UTC date and time at which the 311 corresponding alarm was last sent or acknowledged. 313 Value Type: DATE-TIME 315 Property Parameters: IANA and non-standard property parameters can 316 be specified on this property. 318 Conformance: This property can be specified within "VALARM" calendar 319 components. 321 Description: This property is used to specify when an alarm was last 322 sent or acknowledged. This allows clients to determine when a 323 pending alarm has been acknowledged by a calendar user so that any 324 alerts can be dismissed across multiple devices. It also allows 325 clients to track repeating alarms or alarms on recurring events or 326 to-dos to ensure that the right number of missed alarms can be 327 tracked. 329 Clients SHOULD set this property to the current date-time value in 330 UTC when a calendar user acknowledges a pending alarm. Certain 331 kinds of alarms, such as email-based alerts, might not provide 332 feedback as to when the calendar user sees them. For those kinds 333 of alarms, the client SHOULD set this property when the alarm is 334 triggered and the action successfully carried out. 336 When an alarm is triggered on a client, clients can check to see 337 if an "ACKNOWLEDGED" property is present. If it is, and the value 338 of that property is greater than or equal to the computed trigger 339 time for the alarm, then the client SHOULD NOT trigger the alarm. 340 Similarly, if an alarm has been triggered and an "alert" presented 341 to a calendar user, clients can monitor the iCalendar data to 342 determine whether an "ACKNOWLEDGED" property is added or changed 343 in the alarm component. If the value of any "ACKNOWLEDGED" 344 property in the alarm changes and is greater than or equal to the 345 trigger time of the alarm, then clients SHOULD dismiss or cancel 346 any "alert" presented to the calendar user. 348 Format Definition: This property is defined by the following 349 notation: 351 acknowledged = "ACKNOWLEDGED" *acknowledgedparam ":" datetime CRLF 353 acknowledgedparam = ( 355 ; the following is OPTIONAL, 356 ; and MAY occur more than once 358 (";" other-param) 360 ) 362 Example: The following is an example of this property: 364 ACKNOWLEDGED:20090604T084500Z 366 7. Snoozing Alarms 368 Users often want to "snooze" an alarm, and this specification defines 369 a standard approach to accomplish that. 371 To "snooze" an alarm that has been triggered, clients MUST do the 372 following: 374 1. Set the "ACKNOWLEDGED" property (see Section 6.1) on the 375 triggered alarm. 377 2. Create a new "VALARM" component (the "snooze" alarm) within the 378 parent component of the triggered alarm (i.e., as a "sibling" 379 component of the triggered alarm). 381 A. The new "snooze" alarm MUST be set to trigger at the user's 382 chosen "snooze" interval after the original alarm triggered. 383 Clients SHOULD use an absolute "TRIGGER" property with a 384 "DATE-TIME" value specified in UTC. 386 B. The new "snooze" alarm MUST have a "RELATED-TO" property (see 387 Section 5) with a value set to the "UID" property value of 388 the original "VALARM" component that was triggered. If the 389 triggered "VALARM" component does not already have a "UID" 390 property, the client MUST add one. The "RELATED-TO" property 391 added to the new "snooze" alarm MUST include a "RELTYPE" 392 property parameter with a value set to "SNOOZE" (see 393 Section 7.1). 395 3. When the "snooze" alarm is triggered, the client MUST do the 396 following: 398 A. Update the "ACKNOWLEDGED" property on the original related 399 alarm. 401 B. If the "snooze" alarm is itself "snoozed", the client MUST 402 remove the "snooze" alarm component, and return to step 2. 404 Otherwise, if the "snooze" alarm is dismissed, the client 405 MUST do one of the following: 407 + Set the "ACKNOWLEDGED" property on the "snooze" alarm. 409 + Remove the "snooze" alarm component. 411 Note that regardless of the final disposition of the "snooze" alarm 412 when triggered, the original "VALARM" component is left unchanged 413 other than updating its "ACKNOWLEDGED" property. 415 7.1. Relationship Type Property Parameter 417 This specification adds the "SNOOZE" relationship type for use with 418 the "RELTYPE" property defined in Section 3.2.15 of [RFC5545]. This 419 is used when relating a "snoozed" "VALARM" component to the original 420 alarm that the "snooze" was generated for. 422 7.2. Example 424 The following example shows the snoozing, re-snoozing, and dismissal 425 of an alarm. Note that the encompassing VCALENDAR component has been 426 omitted for brevity and that the line-breaks surrounding the VALARM 427 components are for clarity only and would not be present in the 428 actual iCalendar data. 430 Assume that we have the following event with an alarm set to trigger 431 15 minutes before the meeting: 433 BEGIN:VEVENT 434 CREATED:20210302T151004Z 435 UID:AC67C078-CED3-4BF5-9726-832C3749F627 436 DTSTAMP:20210302T151004Z 437 DTSTART;TZID=America/New_York:20210302T103000 438 DTEND;TZID=America/New_York:20210302T113000 439 SUMMARY:Meeting 441 BEGIN:VALARM 442 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 443 TRIGGER:-PT15M 444 DESCRIPTION:Event reminder 445 ACTION:DISPLAY 446 END:VALARM 448 END:VEVENT 450 When the alarm is triggered, the user decides to snooze it for 5 451 minutes. The client acknowledges the original alarm and creates a 452 new "snooze" alarm as a sibling of, and relates it to, the original 453 alarm (note that both VALARMs reside within the same "parent" 454 VEVENT): 456 BEGIN:VEVENT 457 CREATED:20210302T151004Z 458 UID:AC67C078-CED3-4BF5-9726-832C3749F627 459 DTSTAMP:20210302T151516Z 460 DTSTART;TZID=America/New_York:20210302T103000 461 DTEND;TZID=America/New_York:20210302T113000 462 SUMMARY:Meeting 464 BEGIN:VALARM 465 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 466 TRIGGER:-PT15M 467 DESCRIPTION:Event reminder 468 ACTION:DISPLAY 469 ACKNOWLEDGED:20210302T151514Z 470 END:VALARM 472 BEGIN:VALARM 473 UID:DE7B5C34-83FF-47FE-BE9E-FF41AE6DD097 474 TRIGGER;VALUE=DATE-TIME:20210302T152000Z 475 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 476 DESCRIPTION:Event reminder 477 ACTION:DISPLAY 478 END:VALARM 480 END:VEVENT 482 When the "snooze" alarm is triggered, the user decides to snooze it 483 again for an additional 5 minutes. The client once again 484 acknowledges the original alarm, removes the triggered "snooze" 485 alarm, and creates another new "snooze" alarm as a sibling of, and 486 relates it to, the original alarm (note the different UID for the new 487 snooze alarm): 489 BEGIN:VEVENT 490 CREATED:20210302T151004Z 491 UID:AC67C078-CED3-4BF5-9726-832C3749F627 492 DTSTAMP:20210302T152026Z 493 DTSTART;TZID=America/New_York:20210302T103000 494 DTEND;TZID=America/New_York:20210302T113000 495 SUMMARY:Meeting 497 BEGIN:VALARM 498 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 499 TRIGGER:-PT15M 500 DESCRIPTION:Event reminder 501 ACTION:DISPLAY 502 ACKNOWLEDGED:20210302T152024Z 503 END:VALARM 505 BEGIN:VALARM 506 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394 507 TRIGGER;VALUE=DATE-TIME:20210302T152500Z 508 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 509 DESCRIPTION:Event reminder 510 ACTION:DISPLAY 511 END:VALARM 513 END:VEVENT 515 When the second "snooze" alarm is triggered, the user decides to 516 dismiss it. The client acknowledges both the original alarm and the 517 second "snooze" alarm: 519 BEGIN:VEVENT 520 CREATED:20210302T151004Z 521 UID:AC67C078-CED3-4BF5-9726-832C3749F627 522 DTSTAMP:20210302T152508Z 523 DTSTART;TZID=America/New_York:20210302T103000 524 DTEND;TZID=America/New_York:20210302T113000 525 SUMMARY:Meeting 527 BEGIN:VALARM 528 UID:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 529 TRIGGER:-PT15M 530 DESCRIPTION:Event reminder 531 ACTION:DISPLAY 532 ACKNOWLEDGED:20210302T152507Z 533 END:VALARM 535 BEGIN:VALARM 536 UID:87D690A7-B5E8-4EB4-8500-491F50AFE394 537 TRIGGER;VALUE=DATE-TIME:20210302T152500Z 538 RELATED-TO;RELTYPE=SNOOZE:8297C37D-BA2D-4476-91AE-C1EAA364F8E1 539 DESCRIPTION:Event reminder 540 ACTION:DISPLAY 541 ACKNOWLEDGED:20210302T152507Z 542 END:VALARM 544 END:VEVENT 546 8. Alarm Proximity Trigger 548 VALARMs are currently triggered when a specific date-time is reached. 549 It is also desirable to be able to trigger alarms based on location, 550 e.g. when arriving at or departing from a particular location. 552 This specification adds the following elements to "VALARM" components 553 to indicate when an alarm can be triggered based on location. 555 "PROXIMITY" property - indicates that a location based trigger is 556 to be used and which action is used for the trigger 558 "VLOCATION" component(s) [I-D.ietf-calext-eventpub-extensions] - 559 used to indicate the actual location(s) to trigger off of, 560 specified with a URL property containing a geo: URI [RFC5870] 561 which allows for two or three coordinate values with an optional 562 uncertainty 564 alarmprop =/ ( 566 ; the following is OPTIONAL, 567 ; but MUST NOT occur more than once 569 proximity / 571 ) 573 alarm-subcomp =/ ( 575 ; the following is OPTIONAL, 576 ; and MAY occur more than once, but only 577 ; when a PROXIMITY property is also present 579 locationc 581 ) 583 Typically, when a "PROXIMITY" property is used there is no need to 584 specify a time-based trigger using the "TRIGGER" property. However, 585 since "TRIGGER" is defined as a required property for a "VALARM" 586 component, for backwards compatibility it has to be present, but 587 ignored. To indicate a "TRIGGER" that is to be ignored, clients 588 SHOULD use a value a long time in the past. A value of 589 "19760401T005545Z" has been commonly used for this purpose. 591 8.1. Proximity Property 593 Property Name: PROXIMITY 595 Purpose: This property indicates that a location based trigger is 596 applied to an alarm. 598 Value Type: TEXT 600 Property Parameters: IANA and non-standard property parameters can 601 be specified on this property. 603 Conformance: This property can be specified within "VALARM" calendar 604 components. 606 Description: This property is used to indicate that an alarm has a 607 location-based trigger. Its value identifies the action that will 608 trigger the alarm. 610 When the property value is set to "ARRIVE", the alarm is triggered 611 when the calendar user agent arrives in the vicinity of one or 612 more locations. When set to "DEPART", the alarm is triggered when 613 the calendar user agent departs from the vicinity of one or more 614 locations. Each location which MUST be specified with a 615 "VLOCATION" component. Note that the meaning of "vicinity" in 616 this context is implementation defined. 618 When the property value is set to "CONNECT", the alarm is 619 triggered when the calendar user agent connects to a automobile to 620 which is has been paired via Bluetooth(R) [BTcore]. When set to 621 "DISCONNECT", the alarm is triggered when the calendar user agent 622 disconnects from a automobile to which it has been paired via 623 Bluetooth(R). Note that neither current implementations of 624 proximty alarms nor this document have a mechanism to target a 625 particular automobile. Such a mechanism may be specified in a 626 future extension. 628 Format Definition: This property is defined by the following 629 notation: 631 proximity = "PROXIMITY" *proximityparam ":" proximityvalue CRLF 633 proximityparam = ( 635 ; the following is OPTIONAL, 636 ; and MAY occur more than once 638 (";" other-param) 640 ) 642 proximityvalue = "ARRIVE" / "DEPART" / 643 "CONNECT" / "DISCONNECT" / iana-token / x-name 645 8.2. Example 647 The following example shows a VALARM component with a proximity 648 trigger set to trigger when the device running the calendar user 649 agent leaves the vicinity defined by the URL property in the 650 VLOCATION component. Note use of the "u=" parameter with the "geo" 651 URI to define the uncertainty of the location determination. 653 BEGIN:VALARM 654 UID:77D80D14-906B-4257-963F-85B1E734DBB6 655 ACTION:DISPLAY 656 TRIGGER;VALUE=DATE-TIME:19760401T005545Z 657 DESCRIPTION:Remember to buy milk 658 PROXIMITY:DEPART 659 BEGIN:VLOCATION 660 UID:123456-abcdef-98765432 661 NAME:Office 662 URL:geo:40.443,-79.945;u=10 663 END:VLOCATION 664 END:VALARM 666 9. Security Considerations 668 In addition to the security properties of iCalendar (see Section 7 of 669 [RFC5545]), VALARMs, if not monitored properly, can be used to 670 disturb users and/or leak personal information. For instance, an 671 undesirable audio alert could cause embarassment. An unwanted 672 display alert could be considered an annoyance. Or an email alert 673 could be used to leak a user's location to a third party or to send 674 unsolicited email to multiple users. Therefore, CalDAV clients and 675 servers that accept iCalendar data from a third party (e.g. via iTIP 676 [RFC5546], a subscription feed, or a shared calendar) SHOULD remove 677 all VALARMs from the data prior to storing in their calendar system. 679 Security considerations related to unique identifiers for VALARMs are 680 discussed in Section 4. 682 10. Privacy Considerations 684 Proximity VALARMs, if not used carefully, can leak a user's past, 685 present, or future location. For instance, storing an iCalendar 686 resource containing proxmity VALARMs to a shared calendar on CalDAV 687 server can expose to anyone that has access to that calendar the 688 user's intent to leave from or arrive at a particular location at 689 some future time. Furthermore, if a CalDAV client updates the shared 690 iCalendar resource with an ACKNOWLEDGED property when the alarm is 691 triggered, will leak the exact date and time that the user left from 692 or arrived at the location. Therefore, CalDAV clients that implement 693 proximity alarms SHOULD give users the option of storing and/or 694 acknowledging the alarms on the local device only and not storing the 695 alarm and/or acknowledgment on a remote server. 697 Privacy considerations related to unique identifiers for VALARMs are 698 discussed in Section 4. 700 11. IANA Considerations 702 11.1. Property Registrations 704 This document defines the following new iCalendar properties to be 705 added to the registry defined in Section 8.2.3 of [RFC5545] and 706 located here: 708 +--------------+---------+----------------------+ 709 | Property | Status | Reference | 710 +--------------+---------+----------------------+ 711 | ACKNOWLEDGED | Current | RFCXXXX, Section 6.1 | 712 | PROXIMITY | Current | RFCXXXX, Section 8.1 | 713 +--------------+---------+----------------------+ 715 11.2. Relationship Types Registry 717 This document defines the following new iCalendar relationship type 718 to be added to the registry defined in Section 8.3.8 of [RFC5545] and 719 located here: 722 +-------------------+---------+----------------------+ 723 | Relationship Type | Status | Reference | 724 +-------------------+---------+----------------------+ 725 | SNOOZE | Current | RFCXXXX, Section 7.1 | 726 +-------------------+---------+----------------------+ 728 11.3. Proximity Value Registry 730 This document creates a new iCalendar registry for values of the 731 "PROXIMITY" property located here: 734 Additional values MAY be used, provided the process described in 735 Section 8.2.1 of [RFC5545] is used to register them, using the 736 template in Section 8.2.6 of [RFC5545]. 738 The following table has been used to initialize the Proximity Value 739 Registry. 741 +------------+---------+----------------------+ 742 | Value | Status | Reference | 743 +------------+---------+----------------------+ 744 | ARRIVE | Current | RFCXXXX, Section 8.1 | 745 | DEPART | Current | RFCXXXX, Section 8.1 | 746 | CONNECT | Current | RFCXXXX, Section 8.1 | 747 | DISCONNECT | Current | RFCXXXX, Section 8.1 | 748 +------------+---------+----------------------+ 750 12. Acknowledgments 752 This specification came about via discussions at the Calendaring and 753 Scheduling Consortium. Also, thanks to the following for providing 754 feedback: Bernard Desruisseaux, Mike Douglass, Jacob Farkas, Jeffrey 755 Harris, Ciny Joy, Barry Leiba, and Daniel Migault. 757 13. References 759 13.1. Normative References 761 [I-D.ietf-calext-eventpub-extensions] 762 Douglass, M., "Event Publishing Extensions to iCalendar", 763 draft-ietf-calext-eventpub-extensions-18 (work in 764 progress), January 2021. 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, 768 DOI 10.17487/RFC2119, March 1997, 769 . 771 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 772 Scheduling Core Object Specification (iCalendar)", 773 RFC 5545, DOI 10.17487/RFC5545, September 2009, 774 . 776 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 777 Identifier for Geographic Locations ('geo' URI)", 778 RFC 5870, DOI 10.17487/RFC5870, June 2010, 779 . 781 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 782 DOI 10.17487/RFC7986, October 2016, 783 . 785 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 786 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 787 May 2017, . 789 13.2. Informative References 791 [BTcore] Bluetooth Special Interest Group, "Bluetooth Core 792 Specification Version 5.0", December 2016, 793 . 796 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 797 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 798 DOI 10.17487/RFC4791, March 2007, 799 . 801 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 802 Interoperability Protocol (iTIP)", RFC 5546, 803 DOI 10.17487/RFC5546, December 2009, 804 . 806 Appendix A. Change History (To be removed by RFC Editor before 807 publication) 809 Changes in ietf-06: 811 1. Corrected timestamps in snooze example. 813 2. Editorial changes from Benjamim Kaduk. 815 Changes in ietf-05: 817 1. Updated to use VLOCATION components rather than (deprecated) 818 STRUCTURED-LOCATION properties for proximity alarms. 820 2. Reorganized and clarified the process of snoozing an alarm and 821 added an example. 823 3. Noted that there is currently no mechanism for specifying a 824 particular automobile for CONNECT/DISCONNECT proximity alarms. 826 4. Replaced the term "spam" with new wording in Security 827 Considerations. 829 5. Addressed IESG comments from Benjamim Kaduk. 831 6. Addressed IESG comments from Robert Wilton. 833 7. Addressed IESG comments Alissa Cooper. 835 Changes in ietf-04: 837 1. Addressed security review comments from Valery Smyslov. 839 2. Addressed Genart review comments from Roni Even. 841 3. Added text addressing management of Proximity Value Registry. 843 Changes in ietf-03: 845 1. Fixed ABNF to be properly extended. 847 2. Addressed AD review comments from Barry Leiba. 849 Changes in ietf-02: 851 1. Addressed some WGLC comments from Daniel Migault. 853 Changes in ietf-01: 855 1. Reintroduced the RELATED-TO property for VALARMs and the SNOOZE 856 value for the RELTYPE property parameter. 858 2. Add Privacy Considerations section. 860 Changes in ietf-00: 862 1. Submitted as CALEXT draft. 864 Changes in daboo-05: 866 1. Added Murchison as editor. 868 2. Updated keywords boilerplate. 870 3. Added reference to UID security/privacy recommendations. 872 4. Removed default alarms. 874 5. Removed ALARM-AGENT property. 876 6. Added text about using TRIGGER value in the past in addition to 877 ACTION:NONE to have a default alarm be ignored. 879 7. Removed text about related alarms. 881 8. Removed URL alarm action. 883 9. Added reference to draft-ietf-calext-eventpub-extensions for 884 STRUCTURED-LOCATION. 886 10. Added CONNECT and DISCONNECT PROXIMITY property values. 888 11. Added Security Considerations. 890 12. Editorial fixes. 892 Changes in daboo-04: 894 1. Changed "ID" to "AGENT-ID". 896 2. Add more text on using "ACKNOWLEDGED" property. 898 3. Add "RELATED-TO" as a valid property for VALARMs. 900 4. Add "SNOOZE" relationship type for use with VALARMs. 902 5. State that "TRIGGER" is typically ignored in proximity alarms. 904 6. Added "PROXIMITY" value registry. 906 7. Added a lot more detail on default alarms including new action 907 and property. 909 Changes in daboo-03: none - resubmission of -02 911 Changes in daboo-02: 913 1. Updated to 5545 reference. 915 2. Clarified use of absolute trigger in UTC in snooze alarms 917 3. Snooze alarms should be removed when completed 919 4. Removed status and replaced last-triggered by acknowledged 920 property 922 5. Added location-based trigger 924 6. IANA registry tables added 926 Changes in daboo-01: 928 1. Removed DESCRIPTION as an allowed property in the URI alarm. 930 2. Added statement about what to do when ALARM-AGENT is not present. 932 3. Allow multiple ALARM-AGENT properties to be present. 934 4. Removed SNOOZE-UNTIL - snoozing now accomplished by creating a 935 new VALARM. 937 5. Remove VALARM by reference section. 939 6. Added more detail to CalDAV default alarms. 941 Authors' Addresses 943 Cyrus Daboo 944 Apple Inc. 945 1 Infinite Loop 946 Cupertino, CA 95014 947 USA 949 Email: cyrus@daboo.name 950 URI: http://www.apple.com/ 952 Kenneth Murchison (editor) 953 Fastmail US LLC 954 1429 Walnut St, Suite 1201 955 Philadephia, PA 19102 956 USA 958 Email: murch@fastmailteam.com 959 URI: http://www.fastmail.com/