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/