draft-ietf-calext-valarm-extensions-00.txt		draft-ietf-calext-valarm-extensions-01.txt
	Network Working Group C. Daboo		Network Working Group C. Daboo
	Internet-Draft Apple		Internet-Draft Apple
	Updates: 5545 (if approved) K. Murchison, Ed.		Updates: 5545 (if approved) K. Murchison, Ed.
	Intended status: Standards Track FastMail		Intended status: Standards Track FastMail
	Expires: December 12, 2019 June 10, 2019		Expires: July 20, 2020 January 17, 2020
	VALARM Extensions for iCalendar		VALARM Extensions for iCalendar
	draft-ietf-calext-valarm-extensions-00		draft-ietf-calext-valarm-extensions-01
	Abstract		Abstract
	This document defines a set of extensions to the iCalendar VALARM		This document defines a set of extensions to the iCalendar VALARM
	component to enhance use of alarms and improve interoperability		component to enhance use of alarms and improve interoperability
	between clients and servers.		between clients and servers.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 12, 2019.		This Internet-Draft will expire on July 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Extensible syntax for VALARM . . . . . . . . . . . . . . . . 3		3. Extensible syntax for VALARM . . . . . . . . . . . . . . . . 3
	4. Alarm Unique Identifier . . . . . . . . . . . . . . . . . . . 5		4. Alarm Unique Identifier . . . . . . . . . . . . . . . . . . . 5
	5. Alarm Acknowledgement . . . . . . . . . . . . . . . . . . . . 5		5. Alarm Related To . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Acknowledged Property . . . . . . . . . . . . . . . . . . 6		6. Alarm Acknowledgement . . . . . . . . . . . . . . . . . . . . 6
	6. Snoozing Alarms . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Acknowledged Property . . . . . . . . . . . . . . . . . . 7
	7. Alarm Proximity Trigger . . . . . . . . . . . . . . . . . . . 8		7. Snoozing Alarms . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Proximity Property . . . . . . . . . . . . . . . . . . . 9		7.1. Relationship Type Property Parameter . . . . . . . . . . 8
	7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Alarm Proximity Trigger . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8.1. Proximity Property . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Property Registrations . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9.2. Proximity Value Registry . . . . . . . . . . . . . . . . 11		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11.1. Property Registrations . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.2. Relationship Types Registry . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11.3. Proximity Value Registry . . . . . . . . . . . . . . . . 12
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
			13.1. Normative References . . . . . . . . . . . . . . . . . . 13
			13.2. Informative References . . . . . . . . . . . . . . . . . 13
			13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Change History (To be removed by RFC Editor before		Appendix A. Change History (To be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 12		publication) . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The iCalendar [RFC5545] specification defines a set of components		The iCalendar [RFC5545] specification defines a set of components
	used to describe calendar data. One of those is the "VALARM"		used to describe calendar data. One of those is the "VALARM"
	component which appears as a sub-component of "VEVENT" and "VTODO"		component which appears as a sub-component of "VEVENT" and "VTODO"
	components. The "VALARM" component is used to specify a reminder for		components. The "VALARM" component is used to specify a reminder for
	an event or task. Different alarm actions are possible, as are		an event or task. Different alarm actions are possible, as are
	different ways to specify how the alarm is triggered.		different ways to specify how the alarm is triggered.
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 44 ¶
	alarmprop /= *(		alarmprop /= *(
	; the following is OPTIONAL,		; the following is OPTIONAL,
	; but MUST NOT occur more than once		; but MUST NOT occur more than once
	uid		uid
	)		)
	5. Alarm Acknowledgement		5. Alarm Related To
			It is often convenient to relate one or more "VALARM" components to
			other "VALARM" components (e.g., see Section 7). This can be
			accomplished if the "VALARM" components each have their own "UID"
			property (as per Section 4).
			This specification updates the usage of the "RELATED-TO" property
			defined in Section 3.8.4.5 of [RFC5545] 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
			[RFC5545].
			The "VALARM" component defined in Section 3 is extended here as:
			alarmprop /= *(
			; the following is OPTIONAL,
			; but MAY occur more than once
			related
			)
			6. Alarm Acknowledgement
	There is currently no way for a "VALARM" component to indicate		There is currently no way for a "VALARM" component to indicate
	whether it has been triggered and acknowledged. With the advent of a		whether it has been triggered and acknowledged. With the advent of a
	standard client/server protocol for calendaring and scheduling data		standard client/server protocol for calendaring and scheduling data
	([RFC4791]) it is quite possible for an event with an alarm to exist		([RFC4791]) 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		on multiple clients in addition to the server. If each of those is
	responsible for performing the action when an alarm triggers, then		responsible for performing the action when an alarm triggers, then
	multiple "alerts" are generated by different devices. In such a		multiple "alerts" are generated by different devices. In such a
	situation, a calendar user would like to be able to "dismiss" the		situation, a calendar user would like to be able to "dismiss" the
	alarm on one device and have it automatically dismissed on the others		alarm on one device and have it automatically dismissed on the others
	skipping to change at page 6, line 22 ¶		skipping to change at page 7, line 5 ¶
	alarmprop /= *(		alarmprop /= *(
	; the following is OPTIONAL,		; the following is OPTIONAL,
	; but MUST NOT occur more than once		; but MUST NOT occur more than once
	acknowledged		acknowledged
	)		)
	5.1. Acknowledged Property		6.1. Acknowledged Property
	Property Name: ACKNOWLEDGED		Property Name: ACKNOWLEDGED
	Purpose: This property specifies the UTC date and time at which the		Purpose: This property specifies the UTC date and time at which the
	corresponding alarm was last sent or acknowledged.		corresponding alarm was last sent or acknowledged.
	Value Type: DATE-TIME		Value Type: DATE-TIME
	Property Parameters: IANA and non-standard property parameters can		Property Parameters: IANA and non-standard property parameters can
	be specified on this property.		be specified on this property.
	skipping to change at page 7, line 35 ¶		skipping to change at page 8, line 20 ¶
	; and MAY occur more than once		; and MAY occur more than once
	(";" other-param)		(";" other-param)
	)		)
	Example: The following is an example of this property:		Example: The following is an example of this property:
	ACKNOWLEDGED:20090604T084500Z		ACKNOWLEDGED:20090604T084500Z
	6. Snoozing Alarms		7. Snoozing Alarms
	Users often want to "snooze" an alarm, and this specification defines		Users often want to "snooze" an alarm, and this specification defines
	a standard approach to accomplish that.		a standard approach to accomplish that.
	To "snooze" an alarm, clients create a new "VALARM" component within		To "snooze" an alarm, clients create a new "VALARM" component within
	the parent component of the "VALARM" that was triggered and is being		the parent component of the "VALARM" that was triggered and is being
	"snoozed" (i.e., as a "sibling" component of the "VALARM" being		"snoozed" (i.e., as a "sibling" component of the "VALARM" being
	snoozed). The new "VALARM" MUST be set to trigger at the user's		snoozed). The new "VALARM" MUST be set to trigger at the user's
	chosen "snooze" interval after the original alarm triggered. Clients		chosen "snooze" interval after the original alarm triggered. Clients
	SHOULD use an absolute "TRIGGER" property with a "DATE-TIME" value		SHOULD use an absolute "TRIGGER" property with a "DATE-TIME" value
	specified in UTC.		specified in UTC.
			Clients SHOULD add a "RELATED-TO" property to the new "VALARM"
			component with a value set to the "UID" property value of the
			"VALARM" component being snoozed. If the "VALARM" component being
			snoozed does not already have a "UID" property, the client SHOULD add
			one. The "RELATED-TO" property added to the new "VALARM" component
			SHOULD include a "RELTYPE" property parameter with a value set to
			"SNOOZE".
	When the "snooze" alarm is triggered and dismissed the client SHOULD		When the "snooze" alarm is triggered and dismissed the client SHOULD
	remove the corresponding "VALARM" component, or set the		remove the corresponding "VALARM" component, or set the
	"ACKNOWLEDGED" property (see Section 5.1). Alternatively, if the		"ACKNOWLEDGED" property (see Section 6.1). Alternatively, if the
	"snooze" alarm is itself "snoozed", the client SHOULD remove the		"snooze" alarm is itself "snoozed", the client SHOULD remove the
	original "snooze" alarm and create a new one, with the appropriate		original "snooze" alarm and create a new one, with the appropriate
	trigger time and relationship set.		trigger time and relationship set.
	7. Alarm Proximity Trigger		7.1. Relationship Type Property Parameter
			This specification adds the "SNOOZE" relationship type for use with
			the "RELTYPE" property defined in Section 3.2.15 of [RFC5545]. This
			is used to relate a "snoozed" "VALARM" component to the original
			alarm that the "snooze" was generated for.
			8. Alarm Proximity Trigger
	VALARMs are currently triggered when a specific date-time is reached.		VALARMs are currently triggered when a specific date-time is reached.
	It is also desirable to be able to trigger alarms based on location,		It is also desirable to be able to trigger alarms based on location,
	e.g. when arriving at or departing from a particular location.		e.g. when arriving at or departing from a particular location.
	This specification adds the following properties to "VALARM"		This specification adds the following properties to "VALARM"
	components to indicate when an alarm can be triggered based on		components to indicate when an alarm can be triggered based on
	location.		location.
	"PROXIMITY" - indicates that a location based trigger is to be		"PROXIMITY" - indicates that a location based trigger is to be
	skipping to change at page 9, line 5 ¶		skipping to change at page 10, line 5 ¶
	)		)
	Typically, when a "PROXIMITY" property is used there is no need to		Typically, when a "PROXIMITY" property is used there is no need to
	specify a time-based trigger using the "TRIGGER" property. However,		specify a time-based trigger using the "TRIGGER" property. However,
	since "TRIGGER" is defined as a required property for a "VALARM"		since "TRIGGER" is defined as a required property for a "VALARM"
	component, for backwards compatibility it has to be present, but		component, for backwards compatibility it has to be present, but
	ignored. To indicate a "TRIGGER" that is to be ignored, clients		ignored. To indicate a "TRIGGER" that is to be ignored, clients
	SHOULD use a value a long time in the past. A value of		SHOULD use a value a long time in the past. A value of
	"19760401T005545Z" has been commonly used for this purpose.		"19760401T005545Z" has been commonly used for this purpose.
	7.1. Proximity Property		8.1. Proximity Property
	Property Name: PROXIMITY		Property Name: PROXIMITY
	Purpose: This property indicates that a location based trigger is		Purpose: This property indicates that a location based trigger is
	applied to an alarm.		applied to an alarm.
	Value Type: TEXT		Value Type: TEXT
	Property Parameters: IANA and non-standard property parameters can		Property Parameters: IANA and non-standard property parameters can
	be specified on this property.		be specified on this property.
	skipping to change at page 10, line 9 ¶		skipping to change at page 11, line 9 ¶
	)		)
	proximityvalue = "ARRIVE" / "DEPART" /		proximityvalue = "ARRIVE" / "DEPART" /
	"CONNECT" / "DISCONNECT" / iana-token / x-name		"CONNECT" / "DISCONNECT" / iana-token / x-name
	Example: The following is an example of this property:		Example: The following is an example of this property:
	PROXIMITY:ARRIVE		PROXIMITY:ARRIVE
	7.2. Example		8.2. Example
	The following example shows a "VALARM" component with a proximity		The following example shows a "VALARM" component with a proximity
	trigger set to trigger when the device running the calendar user		trigger set to trigger when the device running the calendar user
	agent leaves the vicinity defined by the structured location		agent leaves the vicinity defined by the structured location
	property. Note use of the "u=" parameter with the "geo" URI to		property. Note use of the "u=" parameter with the "geo" URI to
	define the precision of the location determination.		define the precision of the location determination.
	BEGIN:VALARM		BEGIN:VALARM
	UID:77D80D14-906B-4257-963F-85B1E734DBB6		UID:77D80D14-906B-4257-963F-85B1E734DBB6
	TRIGGER;VALUE=DATE-TIME:19760401T005545Z		TRIGGER;VALUE=DATE-TIME:19760401T005545Z
	ACTION:DISPLAY		ACTION:DISPLAY
	DESCRIPTION:Remember to buy milk		DESCRIPTION:Remember to buy milk
	TRIGGER;VALUE=DATE-TIME:19760401T005545Z		TRIGGER;VALUE=DATE-TIME:19760401T005545Z
	PROXIMITY:DEPART		PROXIMITY:DEPART
	STRUCTURED-LOCATION;VALUE=URI:geo:40.443,-79.945;u=10		STRUCTURED-LOCATION;VALUE=URI:geo:40.443,-79.945;u=10
	END:VALARM		END:VALARM
	8. Security Considerations		9. Security Considerations
	VALARMs, if not monitored properly, can be used to "spam" users and/		VALARMs, if not monitored properly, can be used to "spam" users and/
	or leak personal information. For instance, an unwanted audio or		or leak personal information. For instance, an unwanted audio or
	display alert could be considered spam. Or an email alert could be		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		used to leak a user's location to a third party or to send
	unsolicited email to multiple users. Therefore, CalDAV clients and		unsolicited email to multiple users. Therefore, CalDAV clients and
	servers that accept iCalendar data from a third party (e.g. via iTIP		servers that accept iCalendar data from a third party (e.g. via iTIP
	[RFC5546], a subscription feed, or a shared calendar) SHOULD remove		[RFC5546], a subscription feed, or a shared calendar) SHOULD remove
	all VALARMs from the data prior to storing in their calendar system.		all VALARMs from the data prior to storing in their calendar system.
	9. IANA Considerations		10. Privacy Considerations
	9.1. Property Registrations		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.
			11. IANA Considerations
			11.1. Property Registrations
	This document defines the following new iCalendar properties to be		This document defines the following new iCalendar properties to be
	added to the registry defined in Section 8.2.3 of [RFC5545]:		added to the registry defined in Section 8.2.3 of [RFC5545]:
	+--------------+---------+----------------------+		+--------------+---------+----------------------+
	| Property | Status | Reference |		| Property | Status | Reference |
	+--------------+---------+----------------------+		+--------------+---------+----------------------+
	| ACKNOWLEDGED | Current | RFCXXXX, Section 5.1 |		| ACKNOWLEDGED | Current | RFCXXXX, Section 6.1 |
	| PROXIMITY | Current | RFCXXXX, Section 7.1 |		| PROXIMITY | Current | RFCXXXX, Section 8.1 |
	+--------------+---------+----------------------+		+--------------+---------+----------------------+
	9.2. Proximity Value Registry		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		This document creates a new iCalendar registry for values of the
	"PROXIMITY" property:		"PROXIMITY" property:
	+------------+---------+----------------------+		+------------+---------+----------------------+
	| Value | Status | Reference |		| Value | Status | Reference |
	+------------+---------+----------------------+		+------------+---------+----------------------+
	| ARRIVE | Current | RFCXXXX, Section 7.1 |		| ARRIVE | Current | RFCXXXX, Section 8.1 |
	| DEPART | Current | RFCXXXX, Section 7.1 |		| DEPART | Current | RFCXXXX, Section 8.1 |
	| CONNECT | Current | RFCXXXX, Section 7.1 |		| CONNECT | Current | RFCXXXX, Section 8.1 |
	| DISCONNECT | Current | RFCXXXX, Section 7.1 |		| DISCONNECT | Current | RFCXXXX, Section 8.1 |
	+------------+---------+----------------------+		+------------+---------+----------------------+
	10. Acknowledgments		12. Acknowledgments
	This specification came about via discussions at the Calendaring and		This specification came about via discussions at the Calendaring and
	Scheduling Consortium. Also, thanks to the following for providing		Scheduling Consortium. Also, thanks to the following for providing
	feedback: Bernard Desruisseaux, Mike Douglass, Jacob Farkas, Jeffrey		feedback: Bernard Desruisseaux, Mike Douglass, Jacob Farkas, Jeffrey
	Harris, and Ciny Joy.		Harris, and Ciny Joy.
	11. References		13. References
	11.1. Normative References		13.1. Normative References
	[I-D.ietf-calext-eventpub-extensions]		[I-D.ietf-calext-eventpub-extensions]
	Douglass, M., "Event Publishing Extensions to iCalendar",		Douglass, M., "Event Publishing Extensions to iCalendar",
	draft-ietf-calext-eventpub-extensions-13 (work in		draft-ietf-calext-eventpub-extensions-15 (work in
	progress), May 2019.		progress), October 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,		[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
	"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,		"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
	DOI 10.17487/RFC4791, March 2007,		DOI 10.17487/RFC4791, March 2007,
	<https://www.rfc-editor.org/info/rfc4791>.		<https://www.rfc-editor.org/info/rfc4791>.
	skipping to change at page 12, line 18 ¶		skipping to change at page 13, line 42 ¶
	<https://www.rfc-editor.org/info/rfc5870>.		<https://www.rfc-editor.org/info/rfc5870>.
	[RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,		[RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,
	DOI 10.17487/RFC7986, October 2016,		DOI 10.17487/RFC7986, October 2016,
	<https://www.rfc-editor.org/info/rfc7986>.		<https://www.rfc-editor.org/info/rfc7986>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		13.2. Informative References
	[BTcore] Bluetooth Special Interest Group, "Bluetooth Core		[BTcore] Bluetooth Special Interest Group, "Bluetooth Core
	Specification Version 5.0", December 2016,		Specification Version 5.0", December 2016,
	<https://www.bluetooth.com/specifications/		<https://www.bluetooth.com/specifications/bluetooth-core-
	bluetooth-core-specification>.		specification>.
	[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent		[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
	Interoperability Protocol (iTIP)", RFC 5546,		Interoperability Protocol (iTIP)", RFC 5546,
	DOI 10.17487/RFC5546, December 2009,		DOI 10.17487/RFC5546, December 2009,
	<https://www.rfc-editor.org/info/rfc5546>.		<https://www.rfc-editor.org/info/rfc5546>.
	11.3. URIs		13.3. URIs
	[1] https://tools.ietf.org/html/bcp14		[1] https://tools.ietf.org/html/bcp14
	Appendix A. Change History (To be removed by RFC Editor before		Appendix A. Change History (To be removed by RFC Editor before
	publication)		publication)
			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:		Changes in ietf-00:
	1. Submitted as CALEXT draft.		1. Submitted as CALEXT draft.
	Changes in daboo-05:		Changes in daboo-05:
	1. Added Murchison as editor.		1. Added Murchison as editor.
	2. Updated keywords boilerplate.		2. Updated keywords boilerplate.
End of changes. 28 change blocks.
	47 lines changed or deleted		124 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/