draft-ietf-calext-subscription-upgrade-02.txt   draft-ietf-calext-subscription-upgrade-03.txt 
Network Working Group M. Douglass Network Working Group M. Douglass
Internet-Draft 29 July 2020 Internet-Draft 1 February 2021
Updates: 5988 (if approved) Updates: 5988 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 30 January 2021 Expires: 5 August 2021
Calendar subscription upgrades Calendar subscription upgrades
draft-ietf-calext-subscription-upgrade-02 draft-ietf-calext-subscription-upgrade-03
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 30 January 2021. This Internet-Draft will expire on 5 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 15
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:
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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. CalDAV and DAV provides an easy upgrade path for those clients. Additionally an
subsets are specified here to allow lighter weight implementations. enhanced GET protocol is specified here to allow a light weight
implementation.
The use of subscription upgtafe may help reduce load on servers, but
perhaps more inportantly it allows mobile devices to use a more
efficient update mechanism reducing data tranferred and presumably
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.
Additionally, the rule for URI is included from [RFC3986]. Additionally, the rule for URI is included from [RFC3986].
skipping to change at page 4, line 5 skipping to change at page 4, line 10
or protocol subset. or protocol subset.
These LINK headers will be delivered when a client carries out a HEAD These LINK headers will be delivered when a client carries out a HEAD
request targeting the URL of the resource. request targeting the URL of the resource.
EXAMPLE EXAMPLE
This is an example of a HEAD request and the response from a server This is an example of a HEAD request and the response from a server
that supports the enhanced GET method. that supports the enhanced GET method.
>&gt; Request &lt;&lt; >> Request <&lt;
HEAD /caldata/events.ics HTTP/1.1 HEAD /caldata/events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
>&gt; Response &lt;&lt; >> Response <&lt;
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: xxxx Content-Length: xxxx
Link: <http://example.com/subscribe/events.ics&gt;; Link: <http://example.com/subscribe/events.ics&gt;;
rel="subscribe-enhanced-get" rel="subscribe-enhanced-get"
Figure 1 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
skipping to change at page 6, line 27 skipping to change at page 6, line 27
4.6. Examples 4.6. Examples
EXAMPLE 1 EXAMPLE 1
This is an example of the initial request and response from a server This is an example of the initial request and response from a server
that supports the enhanced GET method. Note the use of the Vary that supports the enhanced GET method. Note the use of the Vary
header so a caching proxy can key off the client's Sync-Token and header so a caching proxy can key off the client's Sync-Token and
preference. preference.
>&gt; Request &lt;&lt; >> Request <&lt;
GET /events.ics HTTP/1.1 GET /events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
Prefer: subscribe-enhanced-get Prefer: subscribe-enhanced-get
>&gt; Response &lt;&lt; >> Response <&lt;
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 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.
>&gt; Request &lt;&lt; >> Request <&lt;
GET /events.ics HTTP/1.1 GET /events.ics HTTP/1.1
Host: example.com Host: example.com
Accept: text/calendar Accept: text/calendar
Prefer: subscribe-enhanced-get Prefer: subscribe-enhanced-get
Sync-Token: "data:,1234567" Sync-Token: "data:,1234567"
>&gt; Response &lt;&lt; >> Response <&lt;
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 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.
>&gt; Request &lt;&lt; >> Request <&lt;
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
>&gt; Response &lt;&lt; >> Response <&lt;
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 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.
>&gt; Request &lt;&lt; >> Request <&lt;
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
>&gt; Response &lt;&lt; >> Response <&lt;
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
skipping to change at page 13, line 38 skipping to change at page 13, line 38
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| 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", IETF 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", IETF RFC 3864,
IETF RFC 3864, DOI 10.17487/RFC3864, September 2004, IETF RFC 3864, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
 End of changes. 19 change blocks. 
20 lines changed or deleted 26 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/