idnits 2.17.1 draft-douglass-subscription-upgrade-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 44 characters in excess of 72. ** The abstract seems to contain references ([RFC5545]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 220 has weird spacing: '...minimal sig...' (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2018) is 2173 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-calext-extensions' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC4589' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC5546' is defined on line 460, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Douglass 3 Internet-Draft Spherical Cow Group 4 Updates: 5545 (if approved) May 5, 2018 5 Intended status: Standards Track 6 Expires: November 6, 2018 8 Calendar subscription upgrades 9 draft-douglass-subscription-upgrade-03 11 Abstract 13 This specification introduces an approach to allow subscribers to 14 calendar feeds to upgrade to a more performant protocol. 16 This specification updates [RFC5545] to add the value DELETED to the 17 STATUS property. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Enhanced GET . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Deletions . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Changes to the iCalendar specifications . . . . . . . . . . . 6 60 3.1. Redefined Status property . . . . . . . . . . . . . . . . 6 61 4. Discovering alternative access methods . . . . . . . . . . . 8 62 5. Link relation subscribe-caldav . . . . . . . . . . . . . . . 8 63 6. Link relation subscribe-caldav-auth . . . . . . . . . . . . . 8 64 7. Link relation subscribe-webdav-sync . . . . . . . . . . . . . 8 65 8. Link relation subscribe-enhanced-get . . . . . . . . . . . . 9 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 11.1. Link Relation Registrations . . . . . . . . . . . . . . 9 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 13. Normative References . . . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 11 73 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Currently clients subscribe to calendar feeds as an ics file which is 79 often published as a resource accessible using the unofficial 80 'webcal' scheme. 82 The only available option for updating that resource is the usual 83 HTTP polling of cached resources using Etags. 85 There is the usual tension between clients wishing to see a timely 86 response to changes and servers not wishing to be overloaded by 87 frequent requests for possibly large amounts of data. 89 This specification introduces an approach whereby clients can 90 discover a more performant access method. Given the location of the 91 resource as an ics file, the client can perfom an OPTIONS request on 92 the resource and inspect the returned headers which will offer a 93 number of alternative access methods. 95 Given that many clients already support CalDAV this provides an easy 96 upgrade path for those clients. CalDAV and DAV subsets are specified 97 here to allow lighter weight implementations. 99 1.1. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 2. Enhanced GET 108 2.1. Introduction 110 This is a lightweight protocol which allows simple clients to 111 efficiently discover and download changes in the targeted resource. 113 It has many similarities to WebDAV sync and for a server could be 114 implemented as an extension of the specification. 116 In this protocol the Etag is used as the sync change token. By 117 adding the If-None-Match header field to the vary header field we can 118 ensure intermediate caching proxies will be able to cache different 119 versions of the data. 121 The resource is treated as a set of individual events each of which 122 may be updated or deleted separately. The client will first fetch 123 the entire ics file. On subsequent requests it uses the Prefer 124 header with a value of "return=minimal" to indicate that it wants a 125 set of changes since the last fetch. 127 2.2. Deletions 129 When an entity (VEVENT, VTODO or other valid top-level component) is 130 deleted from the source data the server needs to be able to inform a 131 client of the deletion. This specification introduces a new value 132 for the STATUS property of DELETED. 134 On the first conditional GET after the entity has been deleted a 135 skeleton, but valid, entity will be returned with STATUS: DELETED. 136 The receiving client is free to remove the entity or update it's 137 STATUS property. 139 On subsequent conditional fetches the entity will not be returned. 141 2.3. Examples 143 This is an example of the initial request and response from a server 144 that supports the extended GET protocol. 146 >> Request << 148 GET /events.ics HTTP/1.1 149 Host: example.com 150 Accept: text/calendar 152 >> Response << 154 HTTP/1.1 200 OK 155 Content-Length: xxxx 156 ETag: "1234" current ETag (for conditional GET) 157 Vary: Prefer, If-None-Match so caching proxy can key off of client?s ETag (sync token) and preference 159 BEGIN:VCALENDAR: 160 ? /* full feed */ 161 END:VCALENDAR 163 This is an example of the subsequent request and response when no 164 changes have occurred. The Accept header field indicates that a 165 VPATCH format is most desirable but simple text/calendar is 166 acceptable. 168 >> Request << 170 GET /events.ics HTTP/1.1 171 Host: example.com 172 Accept: text/calendar; q=0.5, component=VPATCH, text/calendar; 173 If-None-Match: ?1234? conditional request 174 Prefer: return=minimal 176 >> Response << 178 HTTP/1.1 304 Not Modified 179 Content-Length: 0 180 ETag: ?1234? 181 Vary: Prefer, If-None-Match 183 This is an example of the subsequent request and response when no 184 changes have occurred. The Accept header field indicates that a 185 VPATCH format is most desirable but simple text/calendar is 186 acceptable. 188 >> Request << 190 GET /events.ics HTTP/1.1 191 Host: example.com 192 Accept: text/calendar; q=0.5, component=VPATCH, text/calendar; 193 If-None-Match: "1234" conditional request 194 Prefer: return=minimal 196 >> Response << 198 HTTP/1.1 304 Not Modified 199 Content-Length: 0 200 ETag: "1234" 201 Vary: Prefer, If-None-Match 203 This is an example of the subsequent request and response when 204 changes have occurred and the server can create the minimal format. 206 >> Request << 208 GET /events.ics HTTP/1.1 209 Host: example.com 210 Accept: text/calendar; q=0.5, component=VPATCH, text/calendar; 211 If-None-Match: "1234" conditional request 212 Prefer: return=minimal 214 >> Response << 216 HTTP/1.1 200 OK 217 Content-Type: text/calendar 218 Content-Length: xxxx 219 ETag: "5678" current ETag (for conditional GET) 220 Preference-Applied: return=minimal signals to client that stream is changes only 221 Vary: Prefer, If-None-Match so caching proxy can key off of client?s ETag (sync token) and preference 223 BEGIN:VCALENDAR: 224 ... only new/changed events 225 ... when not returning VPATCH, deleted events have STATUS:DELETED 226 END:VCALENDAR 228 This is an example of the subsequent request and response when 229 changes have occurred and the server cannot create the minimal format 230 - perhaps because of an old or invalid token. Note there is no 231 Preference-Applied header field. 233 >> Request << 235 GET /events.ics HTTP/1.1 236 Host: example.com 237 Accept: text/calendar; q=0.5, component=VPATCH, text/calendar; 238 If-None-Match: "1234" conditional request 239 Prefer: return=minimal 241 >> Response << 243 HTTP/1.1 200 OK 244 Content-Type: text/calendar 245 Content-Length: xxxx 246 ETag: "5678" current ETag (for conditional GET) 247 Vary: Prefer, If-None-Match so caching proxy can key off of client?s ETag (sync token) and preference 249 BEGIN:VCALENDAR: 250 ... full set of data 251 END:VCALENDAR 253 3. Changes to the iCalendar specifications 255 This specification updates [RFC5545] to add the value DELETED to the 256 STATUS property. It also introduces the use of some properties to 257 provide more information about the resource, for example the time 258 range it covers. 260 3.1. Redefined Status property 262 Property name: STATUS 264 Purpose: This property defines the overall status or confirmation 265 for the calendar component. 267 Value Type: TEXT 269 Property Parameters: IANA and non-standard property parameters can 270 be specified on this property. 272 Conformance: This property can be specified once in "VEVENT", 273 "VTODO", or "VJOURNAL" calendar components. 275 Description: In a group-scheduled calendar component, the property 276 is used by the "Organizer" to provide a confirmation of the event 277 to the "Attendees". For example in a "VEVENT" calendar component, 278 the "Organizer" can indicate that a meeting is tentative, 279 confirmed, or cancelled. In a "VTODO" calendar component, the 280 "Organizer" can indicate that an action item needs action, is 281 completed, is in process or being worked on, or has been 282 cancelled. In a "VJOURNAL" calendar component, the "Organizer" 283 can indicate that a journal entry is draft, final, or has been 284 cancelled or removed. 286 Format Definition: 288 This property is defined by the following notation: 290 status = "STATUS" statparam ":" statvalue CRLF 292 statparam = *(";" other-param) 294 statvalue = (statvalue-event 295 / statvalue-todo 296 / statvalue-jour) 298 statvalue-event = "TENTATIVE" ;Indicates event is tentative. 299 / "CONFIRMED" ;Indicates event is definite. 300 / "CANCELLED" ;Indicates event was cancelled. 301 / "DELETED" ;Indicates event was deleted. 302 ;Status values for a "VEVENT" 304 statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. 305 / "COMPLETED" ;Indicates to-do completed. 306 / "IN-PROCESS" ;Indicates to-do in process of. 307 / "CANCELLED" ;Indicates to-do was cancelled. 308 / "DELETED" ;Indicates to-do was deleted. 309 ;Status values for "VTODO". 311 statvalue-jour = "DRAFT" ;Indicates journal is draft. 312 / "FINAL" ;Indicates journal is final. 313 / "CANCELLED" ;Indicates journal is removed. 314 / "DELETED" ;Indicates journal was deleted. 315 ;Status values for "VJOURNAL". 317 Example: 319 Example: The following is an example of this property for a "VEVENT" 320 calendar component: 322 STATUS:TENTATIVE 324 The following is an example of this property for a "VTODO" calendar 325 component: 327 STATUS:NEEDS-ACTION 329 The following is an example of this property for a "VJOURNAL" 330 calendar component: 332 STATUS:DRAFT 334 4. Discovering alternative access methods 336 The advertising of other access points is achieved through the use of 337 the LINK header as defined in [RFC5988]. New link relation types are 338 defined in this specification - each being associated with a protocol 339 or protocol subset. 341 These LINK headers will be delivered when a client carries out an 342 OPTIONS request targeting the URL of the resource. 344 5. Link relation subscribe-caldav 346 This specifies an access point which is a full implementation of 347 caldav but requires no authentication. The end point allows the full 348 range of reports as defined by the CalDAV specification. 350 The client MUST follow the specification to determine exactly what 351 operations are allowed on the access point - for example to determine 352 if sync-report is supported. 354 The URL MAY include some form of token to allow write access to the 355 targeted collection. The client must check it's permissions to 356 determine whether or not it has been granted write access. 358 6. Link relation subscribe-caldav-auth 360 This specifies an access point which is a full implementation of 361 caldav and requires authentication. This may allow read-write access 362 to the resource. 364 The client MUST follow the specification to determine exactly what 365 operations are allowed on the access point - for example to determine 366 if sync-report is supported. 368 7. Link relation subscribe-webdav-sync 370 This specifies an access point which supports only webdav sync. 372 This allows the client to issue a sync-report on the resource to 373 obtain updates. 375 NOTE: say something about initial startup - use ics to populate? 376 Initial token? 377 The client MUST follow that specification. 379 8. Link relation subscribe-enhanced-get 381 This specifies an access point which supports something new. 383 The client MUST follow that specification. 385 9. Security Considerations 387 Applications using these properties need to be aware of the risks 388 entailed in using the URIs provided as values. See [RFC3986] for a 389 discussion of the security considerations relating to URIs. 391 10. Privacy Considerations 393 Properties with a "URI" value type can expose their users to privacy 394 leaks as any network access of the URI data can be tracked. Clients 395 SHOULD NOT automatically download data referenced by the URI without 396 explicit instruction from users. This specification does not 397 introduce any additional privacy concerns beyond those described in 398 [RFC5545]. 400 11. IANA Considerations 402 11.1. Link Relation Registrations 404 This document defines the following new iCalendar properties to be 405 added to the registry defined in Section 8.2.3 of [RFC5545]: 407 +------------------------+-------------+--------------------+ 408 | Relation Name | Description | Reference | 409 +------------------------+-------------+--------------------+ 410 | subscribe-caldav | Current | RFCXXXX, Section 5 | 411 | subscribe-caldav_auth | Current | RFCXXXX, Section 6 | 412 | subscribe-webdav-sync | Current | RFCXXXX, Section 7 | 413 | subscribe-enhanced_get | Current | RFCXXXX, Section 8 | 414 +------------------------+-------------+--------------------+ 416 12. Acknowledgements 418 The author would also like to thank the members of the CalConnect 419 Calendar Sharing technical committee and the following individuals 420 for contributing their ideas and support: 422 Marten Gajda, Ken Murchison 423 The authors would also like to thank CalConnect the Calendaring and 424 Scheduling Consortium for advice with this specification. 426 13. Normative References 428 [I-D.ietf-calext-extensions] 429 Daboo, C., "New Properties for iCalendar", draft-ietf- 430 calext-extensions-05 (work in progress), August 2016. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 438 IANA Considerations Section in RFCs", RFC 2434, 439 DOI 10.17487/RFC2434, October 1998, 440 . 442 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 443 DOI 10.17487/RFC3688, January 2004, 444 . 446 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 447 Resource Identifier (URI): Generic Syntax", STD 66, 448 RFC 3986, DOI 10.17487/RFC3986, January 2005, 449 . 451 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 452 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 453 . 455 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 456 Scheduling Core Object Specification (iCalendar)", 457 RFC 5545, DOI 10.17487/RFC5545, September 2009, 458 . 460 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 461 Interoperability Protocol (iTIP)", RFC 5546, 462 DOI 10.17487/RFC5546, December 2009, 463 . 465 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 466 DOI 10.17487/RFC5988, October 2010, 467 . 469 [W3C.REC-xml-20060816] 470 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 471 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 472 Edition)", World Wide Web Consortium Recommendation REC- 473 xml-20060816, August 2006, 474 . 476 Appendix A. Open issues 478 restype values: Need to determine what if any registry of resource 479 types already exists and use that. 481 Appendix B. Change log 483 v01 2017-07-28 MD 485 o Examples 487 o More text for extended get. Talk about deletions. 489 v01 2017-02-17 MD 491 o Add text about OPTIONS 493 o Add text abut read/write CalDAV 495 v00 2017-02-15 MD 497 o First pass 499 Author's Address 501 Michael Douglass 502 Spherical Cow Group 503 226 3rd Street 504 Troy, NY 12180 505 USA 507 Email: mdouglass@sphericalcowgroup.com 508 URI: http://sphericalcowgroup.com