VALARM Extensions for iCalendar
draft-ietf-calext-valarm-extensions-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9074.
|
|
---|---|---|---|
Authors | Cyrus Daboo , Kenneth Murchison | ||
Last updated | 2020-07-31 (Latest revision 2020-07-13) | ||
Replaces | draft-daboo-valarm-extensions | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-04)
by Roni Even
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | In WG Last Call | |
Document shepherd | Daniel Migault | ||
IESG | IESG state | Became RFC 9074 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | Bron Gondwana <brong@fastmailteam.com>, Daniel Migault <mglt.ietf@gmail.com> |
draft-ietf-calext-valarm-extensions-02
Daboo & Murchison Expires January 14, 2021 [Page 9] Internet-Draft VALARM Extensions July 2020 8.1. Proximity Property Property Name: PROXIMITY Purpose: This property indicates that a location based trigger is applied to an alarm. Value Type: TEXT Property Parameters: IANA and non-standard property parameters can be specified on this property. Conformance: This property can be specified within "VALARM" calendar components. Description: This property is used to indicate that an alarm has a location-based trigger. Its value identifies the direction of motion used to trigger the alarm. One or more location values are set using "STRUCTURED-LOCATION" properties. When the property value is set to "ARRIVE", the alarm is triggered when the calendar user agent arrives in the vicinity of any of the specified locations. When set to "DEPART", the alarm is triggered when the calendar user agent departs from the vicinity of any specified locations. When the property value is set to "CONNECT", the alarm is triggered when the calendar user agent connects to a Bluetooth(R) [BTcore]-enabled automobile. When set to "DISCONNECT", the alarm is triggered when the calendar user agent disconnects from a Bluetooth(R)-enabled automobile. Format Definition: This property is defined by the following notation: proximity = "PROXIMITY" proximityparam ":" proximityvalue CRLF proximityparam = *( ; the following is OPTIONAL, ; and MAY occur more than once (";" other-param) ) proximityvalue = "ARRIVE" / "DEPART" / "CONNECT" / "DISCONNECT" / iana-token / x-name Daboo & Murchison Expires January 14, 2021 [Page 10] Internet-Draft VALARM Extensions July 2020 Example: The following is an example of this property: PROXIMITY:ARRIVE 8.2. Example The following example shows a "VALARM" component with a proximity trigger set to trigger when the device running the calendar user agent leaves the vicinity defined by the structured location property. Note use of the "u=" parameter with the "geo" URI to define the precision of the location determination. BEGIN:VALARM UID:77D80D14-906B-4257-963F-85B1E734DBB6 TRIGGER;VALUE=DATE-TIME:19760401T005545Z ACTION:DISPLAY DESCRIPTION:Remember to buy milk TRIGGER;VALUE=DATE-TIME:19760401T005545Z PROXIMITY:DEPART STRUCTURED-LOCATION;VALUE=URI:geo:40.443,-79.945;u=10 END:VALARM 9. Security Considerations VALARMs, if not monitored properly, can be used to "spam" users and/ or leak personal information. For instance, an unwanted audio or display alert could be considered spam. Or an email alert could be used to leak a 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. via iTIP [RFC5546], a subscription feed, or a shared calendar) SHOULD remove all VALARMs from the data prior to storing in their calendar system. 10. Privacy Considerations Proximity VALARMs, if not used carefully, can leak a user's past, present, or future location. For instance, storing an iCalendar resource containing proxmity VALARMs to a shared calendar on CalDAV server can expose to anyone that has access to that calendar the 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 property when the alarm is triggered, 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 give users the option of storing and/or acknowledging the alarms on the local device only and not storing the alarm and/or acknowledgment on a remote server. Daboo & Murchison Expires January 14, 2021 [Page 11] Internet-Draft VALARM Extensions July 2020 11. IANA Considerations 11.1. Property Registrations This document defines the following new iCalendar properties to be added to the registry defined in Section 8.2.3 of [RFC5545]: +--------------+---------+----------------------+ | Property | Status | Reference | +--------------+---------+----------------------+ | ACKNOWLEDGED | Current | RFCXXXX, Section 6.1 | | PROXIMITY | Current | RFCXXXX, Section 8.1 | +--------------+---------+----------------------+ 11.2. Relationship Types Registry This document defines the following new iCalendar relationship type to be added to the registry defined in Section 8.3.8 of [RFC5545]: +-------------------+---------+----------------------+ | Relationship Type | Status | Reference | +-------------------+---------+----------------------+ | SNOOZE | Current | RFCXXXX, Section 7.1 | +-------------------+---------+----------------------+ 11.3. Proximity Value Registry This document creates a new iCalendar registry for values of the "PROXIMITY" property: +------------+---------+----------------------+ | Value | Status | Reference | +------------+---------+----------------------+ | ARRIVE | Current | RFCXXXX, Section 8.1 | | DEPART | Current | RFCXXXX, Section 8.1 | | CONNECT | Current | RFCXXXX, Section 8.1 | | DISCONNECT | Current | RFCXXXX, Section 8.1 | +------------+---------+----------------------+ 12. Acknowledgments 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, and Ciny Joy. Daboo & Murchison Expires January 14, 2021 [Page 12] Internet-Draft VALARM Extensions July 2020 13. References 13.1. Normative References [I-D.ietf-calext-eventpub-extensions] Douglass, M., "Event Publishing Extensions to iCalendar", draft-ietf-calext-eventpub-extensions-15 (work in progress), October 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.rfc-editor.org/info/rfc4791>. [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, <https://www.rfc-editor.org/info/rfc5545>. [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, <https://www.rfc-editor.org/info/rfc5870>. [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, DOI 10.17487/RFC7986, October 2016, <https://www.rfc-editor.org/info/rfc7986>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 13.2. Informative References [BTcore] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 5.0", December 2016, <https://www.bluetooth.com/specifications/bluetooth-core- specification>. [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009, <https://www.rfc-editor.org/info/rfc5546>. Daboo & Murchison Expires January 14, 2021 [Page 13] Internet-Draft VALARM Extensions July 2020 13.3. URIs [1] https://tools.ietf.org/html/bcp14 Appendix A. Change History (To be removed by RFC Editor before publication) Changes in ietf-02: 1. Addressed some WGLC comments from Daniel Migault. Changes in ietf-01: 1. Reintroduced the RELATED-TO property for VALARMs and the SNOOZE value for the RELTYPE property parameter. 2. Add Privacy Considerations section. Changes in ietf-00: 1. Submitted as CALEXT draft. Changes in daboo-05: 1. Added Murchison as editor. 2. Updated keywords boilerplate. 3. Added reference to UID security/privacy recommendations. 4. Removed default alarms. 5. Removed ALARM-AGENT property. 6. Added text about using TRIGGER value in the past in addition to ACTION:NONE to have a default alarm be ignored. 7. Removed text about related alarms. 8. Removed URL alarm action. 9. Added reference to draft-ietf-calext-eventpub-extensions for STRUCTURED-LOCATION. 10. Added CONNECT and DISCONNECT PROXIMITY property values. 11. Added Security Considerations. Daboo & Murchison Expires January 14, 2021 [Page 14] Internet-Draft VALARM Extensions July 2020 12. Editorial fixes. Changes in daboo-04: 1. Changed "ID" to "AGENT-ID". 2. Add more text on using "ACKNOWLEDGED" property. 3. Add "RELATED-TO" as a valid property for VALARMs. 4. Add "SNOOZE" relationship type for use with VALARMs. 5. State that "TRIGGER" is typically ignored in proximity alarms. 6. Added "PROXIMITY" value registry. 7. Added a lot more detail on default alarms including new action and property. Changes in daboo-03: none - resubmission of -02 Changes in daboo-02: 1. Updated to 5545 reference. 2. Clarified use of absolute trigger in UTC in snooze alarms 3. Snooze alarms should be removed when completed 4. Removed status and replaced last-triggered by acknowledged property 5. Added location-based trigger 6. IANA registry tables added Changes in daboo-01: 1. Removed DESCRIPTION as an allowed property in the URI alarm. 2. Added statement about what to do when ALARM-AGENT is not present. 3. Allow multiple ALARM-AGENT properties to be present. 4. Removed SNOOZE-UNTIL - snoozing now accomplished by creating a new VALARM. 5. Remove VALARM by reference section. Daboo & Murchison Expires January 14, 2021 [Page 15] Internet-Draft VALARM Extensions July 2020 6. Added more detail to CalDAV default alarms. Authors' Addresses Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Email: cyrus@daboo.name URI: http://www.apple.com/ Kenneth Murchison (editor) Fastmail US LLC 1429 Walnut St, Suite 1201 Philadephia, PA 19102 USA Email: murch@fastmailteam.com URI: http://www.fastmail.com/ Daboo & Murchison Expires January 14, 2021 [Page 16]