draft-ietf-calext-subscription-upgrade-03.txt   draft-ietf-calext-subscription-upgrade-04.txt 
Network Working Group M. Douglass Network Working Group M. Douglass
Internet-Draft 1 February 2021 Internet-Draft 26 July 2021
Updates: 5988 (if approved) Updates: 5988 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 5 August 2021 Expires: 27 January 2022
Calendar subscription upgrades Calendar subscription upgrades
draft-ietf-calext-subscription-upgrade-03 draft-ietf-calext-subscription-upgrade-04
Abstract Abstract
This specification updates [RFC5545] to add the value DELETED to the This specification updates [RFC5545] to add the value DELETED to the
STATUS property. STATUS property.
This specification also updates [RFC7240] to add the subscribe- This specification also updates [RFC7240] to add the subscribe-
enhanced-get and limit preferences. enhanced-get and limit preferences.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 5 August 2021. This Internet-Draft will expire on 27 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4.2. Deletions . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Deletions . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Handling of invalid sync tokens . . . . . . . . . . . . . 5 4.3. Handling of invalid sync tokens . . . . . . . . . . . . . 5
4.4. Paging the response . . . . . . . . . . . . . . . . . . . 5 4.4. Paging the response . . . . . . . . . . . . . . . . . . . 5
4.5. Caching of responses . . . . . . . . . . . . . . . . . . 6 4.5. Caching of responses . . . . . . . . . . . . . . . . . . 6
4.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Changes to the iCalendar specifications . . . . . . . . . . . 8 5. Changes to the iCalendar specifications . . . . . . . . . . . 8
5.1. Redefined Status property . . . . . . . . . . . . . . . . 8 5.1. Redefined Status property . . . . . . . . . . . . . . . . 8
6. Header Field: Sync-Token . . . . . . . . . . . . . . . . . . 10 6. Header Field: Sync-Token . . . . . . . . . . . . . . . . . . 10
7. New Prefer header field preferences . . . . . . . . . . . . . 10 7. New Prefer header field preferences . . . . . . . . . . . . . 10
7.1. Preference subscribe-enhanced-get . . . . . . . . . . . . 10 7.1. Preference subscribe-enhanced-get . . . . . . . . . . . . 10
7.2. Preference limit . . . . . . . . . . . . . . . . . . . . 11 7.2. Preference limit . . . . . . . . . . . . . . . . . . . . 10
8. Link relations . . . . . . . . . . . . . . . . . . . . . . . 11 8. Link relations . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. subscribe-caldav . . . . . . . . . . . . . . . . . . . . 11 8.2. subscribe-caldav . . . . . . . . . . . . . . . . . . . . 11
8.3. subscribe-caldav-auth . . . . . . . . . . . . . . . . . . 11 8.3. subscribe-caldav-auth . . . . . . . . . . . . . . . . . . 11
8.4. subscribe-webdav-sync . . . . . . . . . . . . . . . . . . 11 8.4. subscribe-webdav-sync . . . . . . . . . . . . . . . . . . 11
8.5. subscribe-enhanced-get . . . . . . . . . . . . . . . . . 12 8.5. subscribe-enhanced-get . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. Sync-Token HTTP Header Field Registration . . . . . . . 12 10.1. Sync-Token HTTP Header Field Registration . . . . . . . 12
10.2. Preference Registrations . . . . . . . . . . . . . . . . 12 10.2. Preference Registrations . . . . . . . . . . . . . . . . 12
10.3. Link Relation Registrations . . . . . . . . . . . . . . 13 10.3. Link Relation Registrations . . . . . . . . . . . . . . 12
11. Normative references . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Acknowledgements 1. Acknowledgements
The author would also like to thank the members of the CalConnect The author would also like to thank the members of the CalConnect
Calendar Sharing technical committee and the following individuals Calendar Sharing technical committee and the following individuals
for contributing their ideas and support: for contributing their ideas and support:
Marten Gajda, Ken Murchison, Garry Shutler Marten Gajda, Ken Murchison, Garry Shutler
The authors would also like to thank CalConnect, the Calendaring and The authors would also like to thank CalConnect, the Calendaring and
Scheduling Consortium, for advice with this specification. Scheduling Consortium, for advice with this specification.
2. Introduction 2. Introduction
Currently clients subscribe to calendar feeds as an iCalendar file Currently clients subscribe to calendar feeds as an iCalendar file
which is often published as a resource accessible using the which is often published as a resource accessible using the
unofficial 'webcal' scheme. unofficial 'webcal' scheme.
The only available option for updating that resource is the usual The only available option for updating that resource is the usual
HTTP polling of cached resources using Etags. HTTP polling of cached resources using Etags or Last-Modified.
There is the usual tension between clients wishing to see a timely There is the usual tension between clients wishing to see a timely
response to changes and servers not wishing to be overloaded by response to changes and servers not wishing to be overloaded by
frequent requests for possibly large amounts of data. frequent requests for possibly large amounts of data.
This specification introduces an approach whereby clients can This specification introduces an approach whereby clients can
discover a more performant access method. Given the location of the discover a more performant access method. Given the location of the
resource as an iCalendar file, the client can perfom a HEAD request resource as an iCalendar file, the client can perfom a HEAD request
on the resource and inspect the returned headers which will offer a on the resource and inspect the returned headers which will offer a
number of alternative access methods. number of alternative access methods.
Given that many clients and servers already support CalDAV this Given that many clients and servers already support CalDAV this
provides an easy upgrade path for those clients. Additionally an provides an easy upgrade path for those clients. Additionally an
enhanced GET protocol is specified here to allow a light weight enhanced GET protocol is specified here to allow a light weight
implementation. implementation.
The use of subscription upgtafe may help reduce load on servers, but The use of subscription upgrade may help reduce load on servers, but
perhaps more inportantly it allows mobile devices to use a more perhaps more importantly it allows mobile devices to use a more
efficient update mechanism reducing data tranferred and presumably efficient update mechanism reducing data transferred and presumably
improving battery life. improving battery life.
2.1. Terms and Definitions 2.1. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
>> Response << >> Response <<
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: xxxx Content-Length: xxxx
Link: <http://example.com/subscribe/events.ics>; Link: <http://example.com/subscribe/events.ics>;
rel="subscribe-enhanced-get" rel="subscribe-enhanced-get"
Figure 1
Note that the target for an upgraded service may be the same as for Note that the target for an upgraded service may be the same as for
the initial resource. the initial resource.
4. Enhanced GET 4. Enhanced GET
4.1. General 4.1. General
This is a lightweight protocol which allows simple clients to This is a lightweight protocol which allows simple clients to
efficiently discover and download changes in the targeted resource. efficiently discover and download changes in the targeted resource.
skipping to change at page 5, line 17 skipping to change at page 5, line 14
4.2. Deletions 4.2. Deletions
When an entity (VEVENT, VTODO or other valid top-level component) is When an entity (VEVENT, VTODO or other valid top-level component) is
deleted from the source data the server needs to be able to inform a deleted from the source data the server needs to be able to inform a
client of the deletion. This specification introduces a new value client of the deletion. This specification introduces a new value
for the STATUS property of DELETED. for the STATUS property of DELETED.
On the first enhanced GET after the entity has been deleted a On the first enhanced GET after the entity has been deleted a
skeleton, but valid, entity will be returned with STATUS: DELETED. skeleton, but valid, entity will be returned with STATUS: DELETED.
The receiving client is free to remove the entity or update it's The receiving client is free to remove the entity or update its
STATUS property. STATUS property.
On subsequent fetches the entity will not be returned. On subsequent fetches the entity will not be returned.
4.3. Handling of invalid sync tokens 4.3. Handling of invalid sync tokens
When a server receives an invalid token it MUST return a 409 status When a server receives an invalid token it MUST return a 409 status
(Conflict). The server MAY choose to return an error message in the (Conflict). The server MAY choose to return an error message in the
body. body.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: xxxx Content-Length: xxxx
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
Preference-Applied: subscribe-enhanced-get Preference-Applied: subscribe-enhanced-get
Vary: Prefer, Sync-Token Vary: Prefer, Sync-Token
BEGIN:VCALENDAR: BEGIN:VCALENDAR:
? /* full feed */ ? /* full feed */
END:VCALENDAR END:VCALENDAR
Figure 2
EXAMPLE 2 EXAMPLE 2
This is an example of the subsequent request and response when no This is an example of the subsequent request and response when no
changes have occurred. changes have occurred.
>> Request << >> Request <<
GET /events.ics HTTP/1.1 GET /events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
>> Response << >> Response <<
HTTP/1.1 304 Not Modified HTTP/1.1 304 Not Modified
Content-Length: 0 Content-Length: 0
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
Preference-Applied: subscribe-enhanced-get Preference-Applied: subscribe-enhanced-get
Vary: Prefer, Sync-Token Vary: Prefer, Sync-Token
Figure 3
EXAMPLE 3 EXAMPLE 3
This is an example of the subsequent request and response for an old This is an example of the subsequent request and response for an old
or invalid token. or invalid token.
>> Request << >> Request <<
GET /events.ics HTTP/1.1 GET /events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
Prefer: subscribe-enhanced-get Prefer: subscribe-enhanced-get
>> Response << >> Response <<
HTTP/1.1 409 Conflict HTTP/1.1 409 Conflict
Content-Length: xxxx Content-Length: xxxx
Preference-Applied: subscribe-enhanced-get Preference-Applied: subscribe-enhanced-get
Figure 4
EXAMPLE 4 EXAMPLE 4
This is an example of the subsequent request and response when This is an example of the subsequent request and response when
changes have occurred. changes have occurred.
>> Request << >> Request <<
GET /events.ics HTTP/1.1 GET /events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
skipping to change at page 8, line 22 skipping to change at page 8, line 22
>> Response << >> Response <<
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/calendar Content-Type: text/calendar
Vary: Prefer, Sync-Token Vary: Prefer, Sync-Token
Sync-Token: "data:,4567890" Sync-Token: "data:,4567890"
Preference-Applied: subscribe-enhanced-get Preference-Applied: subscribe-enhanced-get
BEGIN:VCALENDAR: BEGIN:VCALENDAR:
... only new/changed events ... only new/changed events
... deleted events have STATUS:DELETED ... deleted events have STATUS:DELETED
END:VCALENDAR END:VCALENDAR
Figure 5
5. Changes to the iCalendar specifications 5. Changes to the iCalendar specifications
This specification updates [RFC5545] to add the value DELETED to the This specification updates [RFC5545] to add the value DELETED to the
STATUS property. STATUS property.
5.1. Redefined Status property 5.1. Redefined Status property
Property name STATUS Property name STATUS
Purpose This property defines the overall status or confirmation for Purpose This property defines the overall status or confirmation for
skipping to change at page 9, line 41 skipping to change at page 9, line 39
/ "CANCELLED" ;Indicates to-do was cancelled. / "CANCELLED" ;Indicates to-do was cancelled.
/ "DELETED" ;Indicates to-do was deleted. / "DELETED" ;Indicates to-do was deleted.
;Status values for "VTODO". ;Status values for "VTODO".
statvalue-jour = "DRAFT" ;Indicates journal is draft. statvalue-jour = "DRAFT" ;Indicates journal is draft.
/ "FINAL" ;Indicates journal is final. / "FINAL" ;Indicates journal is final.
/ "CANCELLED" ;Indicates journal is removed. / "CANCELLED" ;Indicates journal is removed.
/ "DELETED" ;Indicates journal was deleted. / "DELETED" ;Indicates journal was deleted.
;Status values for "VJOURNAL". ;Status values for "VJOURNAL".
Figure 6
Example Example
EXAMPLE 1 EXAMPLE 1
The following is an example of this property for a "VEVENT" calendar The following is an example of this property for a "VEVENT" calendar
component: component:
STATUS:TENTATIVE STATUS:TENTATIVE
Figure 7
EXAMPLE 2 EXAMPLE 2
The following is an example of this property for a "VTODO" calendar The following is an example of this property for a "VTODO" calendar
component: component:
STATUS:NEEDS-ACTION STATUS:NEEDS-ACTION
Figure 8
EXAMPLE 3 EXAMPLE 3
The following is an example of this property for a "VJOURNAL" The following is an example of this property for a "VJOURNAL"
calendar component: calendar component:
STATUS:DRAFT STATUS:DRAFT
Figure 9
6. Header Field: Sync-Token 6. Header Field: Sync-Token
This specification defines a new header field Sync-Token for use by This specification defines a new header field Sync-Token for use by
the enhanced GET method. the enhanced GET method.
Accept = DQUOTE URI DQUOTE Accept = DQUOTE URI DQUOTE
Figure 10
The value MUST be a URI. This will generally be a data URI The value MUST be a URI. This will generally be a data URI
representing an opaque token. Client MUST not attempt to interpret representing an opaque token. Client MUST not attempt to interpret
the data URI value. the data URI value.
EXAMPLE EXAMPLE
This is an example of the Sync-Token header field: This is an example of the Sync-Token header field:
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
Figure 11
7. New Prefer header field preferences 7. New Prefer header field preferences
7.1. Preference subscribe-enhanced-get 7.1. Preference subscribe-enhanced-get
This indicates that the client expects the server to handle the GET This indicates that the client expects the server to handle the GET
method according to the specifications for enhanced get. method according to the specifications for enhanced get.
pref-subscribe-enhanced-get = "subscribe-enhanced-get" pref-subscribe-enhanced-get = "subscribe-enhanced-get"
Figure 12
7.2. Preference limit 7.2. Preference limit
This preference parameter provides a limit on the number of This preference parameter provides a limit on the number of
components returned for enhanced get. components returned for enhanced get.
pref-limit = "limit" BWS "=" BWS 1*DIGIT pref-limit = "limit" BWS "=" BWS 1*DIGIT
Figure 13
8. Link relations 8. Link relations
8.1. General 8.1. General
This clause defines a number of new link relations required to This clause defines a number of new link relations required to
facilitate subscription upgrades. facilitate subscription upgrades.
8.2. subscribe-caldav 8.2. subscribe-caldav
This specifies an access point which is a full implementation of This specifies an access point which is a full implementation of
caldav but requires no authentication. The end point allows the full caldav but requires no authentication. The end point allows the full
range of reports as defined by the CalDAV specification. range of reports as defined by the CalDAV specification.
The client MUST follow the specification to determine exactly what The client MUST follow the specification to determine exactly what
operations are allowed on the access point - for example to determine operations are allowed on the access point - for example to determine
if sync-report is supported. if DAV:sync-collection is supported.
The URL MAY include some form of token to allow write access to the The URL MAY include some form of token to allow write access to the
targeted collection. The client must check it's permissions to targeted collection. The client must check its permissions to
determine whether or not it has been granted write access. determine whether or not it has been granted write access.
8.3. subscribe-caldav-auth 8.3. subscribe-caldav-auth
This specifies an access point which is a full implementation of This specifies an access point which is a full implementation of
caldav and requires authentication. This may allow read-write access caldav and requires authentication. This may allow read-write access
to the resource. to the resource.
The client MUST follow the specification to determine exactly what The client MUST follow the specification to determine exactly what
operations are allowed on the access point - for example to determine operations are allowed on the access point - for example to determine
if sync-report is supported. if DAV:sync-collection is supported.
8.4. subscribe-webdav-sync 8.4. subscribe-webdav-sync
This specifies an access point which supports only webdav sync. This specifies an access point which supports only webdav sync.
This allows the client to issue a sync-report on the resource to This allows the client to issue a DAV:sync-collection report on the
obtain updates. resource to obtain updates.
The client MUST follow that specification. The client MUST follow that specification.
8.5. subscribe-enhanced-get 8.5. subscribe-enhanced-get
This specifies an access point which supports something new. This specifies an access point which supports something new.
The client MUST follow that specification. The client MUST follow that specification.
9. Security Considerations 9. Security Considerations
skipping to change at page 12, line 42 skipping to change at page 12, line 23
10.1. Sync-Token HTTP Header Field Registration 10.1. Sync-Token HTTP Header Field Registration
This specification updates the "Message Headers" registry entry for This specification updates the "Message Headers" registry entry for
"Sync-Token" in [RFC3864] to refer to this document. "Sync-Token" in [RFC3864] to refer to this document.
Header Field Name: Sync-Token Header Field Name: Sync-Token
Protocol: http Protocol: http
Status: standard Status: standard
Reference: <this-document> Reference: <this-document>
Figure 14 Figure 1
10.2. Preference Registrations 10.2. Preference Registrations
The following preferences have been added to the HTTP Preferences The following preferences have been added to the HTTP Preferences
Registry defined in [RFC7240] Registry defined in [RFC7240]
Preference subscribe-enhanced-get Preference subscribe-enhanced-get
Value None. Value None.
skipping to change at page 13, line 38 skipping to change at page 13, line 19
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| subscribe-caldav_auth | Current | Section 8.3 | | subscribe-caldav_auth | Current | Section 8.3 |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| subscribe-webdav-sync | Current | Section 8.4 | | subscribe-webdav-sync | Current | Section 8.4 |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| subscribe-enhanced_get | Current | Section 8.5 | | subscribe-enhanced_get | Current | Section 8.5 |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
Table 1 Table 1
11. Normative references 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", IETF RFC 2119, IETF RFC 2119, Requirement Levels", RFC 2119, IETF 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>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", IETF RFC 3864, Procedures for Message Header Fields", RFC 3864, IETF RFC
IETF RFC 3864, DOI 10.17487/RFC3864, September 2004, 3864, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", IETF RFC 3986, Resource Identifier (URI): Generic Syntax", RFC 3986,
IETF RFC 3986, DOI 10.17487/RFC3986, January 2005, IETF RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", IETF Scheduling Core Object Specification (iCalendar)", RFC
RFC 5545, IETF RFC 5545, DOI 10.17487/RFC5545, September 5545, IETF RFC 5545, DOI 10.17487/RFC5545, September 2009,
2009, <https://www.rfc-editor.org/info/rfc5545>. <https://www.rfc-editor.org/info/rfc5545>.
[RFC5988] Nottingham, M., "Web Linking", IETF RFC 5988, IETF RFC [RFC5988] Nottingham, M., "Web Linking", RFC 5988, IETF RFC 5988,
5988, DOI 10.17487/RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>. <https://www.rfc-editor.org/info/rfc5988>.
[RFC7240] Snell, J., "Prefer Header for HTTP", IETF RFC 7240, [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, IETF RFC
IETF RFC 7240, DOI 10.17487/RFC7240, June 2014, 7240, DOI 10.17487/RFC7240, June 2014,
<https://www.rfc-editor.org/info/rfc7240>. <https://www.rfc-editor.org/info/rfc7240>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", IETF RFC 8174, IETF RFC 8174, 2119 Key Words", RFC 8174, IETF RFC 8174,
DOI 10.17487/RFC8174, May 2017, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Open issues Appendix A. Open issues
Vary Ensure we get that right. Vary Ensure we get that right.
Appendix B. Change log Appendix B. Change log
calext00 2019-06-05 MD calext00 2019-06-05 MD
 End of changes. 38 change blocks. 
63 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/