idnits 2.17.1 draft-douglass-serverside-subscriptions-00.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 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([RFC4791]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2518, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC4791, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2518, updated by this document, for RFC5378 checks: 1997-07-21) -- 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 (September 4, 2018) is 2062 days in the past. Is this intentional? 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 367, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC2518' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC5546' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC5988' is defined on line 410, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: 2518 (if approved) September 4, 2018 5 Intended status: Standards Track 6 Expires: March 8, 2019 8 Serverside Subscriptions 9 draft-douglass-serverside-subscriptions-00 11 Abstract 13 This specification provides a mechanism whereby subscriptions to 14 external resources can be handled by the server. 16 This specification updates [RFC4791] to add new properies for the 17 MKCOL request. 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 March 8, 2019. 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. CalDAV Subscriptions . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. New DAV and CALDAV properties . . . . . . . . . . . . . . . . 4 58 3.1. DAV:subscription . . . . . . . . . . . . . . . . . . . . 4 59 3.2. DAV:subscription-href . . . . . . . . . . . . . . . . . . 4 60 3.3. DAV:subscription-deletions-suppressed . . . . . . . . . . 5 61 3.4. DAV:subscription-disabled . . . . . . . . . . . . . . . . 5 62 3.5. DAV:subscription-next-refresh . . . . . . . . . . . . . . 6 63 4. Refreshing and Reenabling the subscription . . . . . . . . . 6 64 5. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. CalDAV service Considerations . . . . . . . . . . . . . . . . 7 66 6.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 7 67 6.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 7 68 6.3. Invitations in Subscriptions . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 10 75 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The motivation for this specification was initially to handle 81 external subscriptions to calendar data. However, any resource which 82 allows subscriptions might make use of this specification. 84 Currently subscriptions to calendar feeds are handled by calendar 85 clients. There are a number of disadvantages to this approach: users 86 have to subscribe from multiple devices and the subscription cannot 87 affect scheduling handled by the server. 89 This specification defines a mechanism whereby the server will 90 subscribe to the feed and make it visible in the user's home. 92 The advantages are popular feeds can be cached by the server and the 93 user only has to make a single subscription. 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 [RFC2119]. 102 2. CalDAV Subscriptions 104 2.1. Request 106 A client will subscribe to a URL by performing a MKCOL request with 107 resource type elements of at least DAV:collection and 108 DAV:subscription. For a calendar subscription there will also be a 109 caldav calendar element. 111 This is an example of the MKCOL request and response from a server 112 that supports extended MKCOL. 114 >> Request << 116 POST /caldav/user/mike/calendars/parrots HTTP/1.1 117 Host: example.com 118 Content-Type: text/calendar; component=VEVENT; method=REQUEST 119 Content-Length: xxxx 121 122 124 125 126 127 128 129 130 131 Parrot Events 132 http://example.org/parrot-events.ics 133 true 134 135 136 138 >> Response << 140 HTTP/1.1 200 OK 142 3. New DAV and CALDAV properties 144 3.1. DAV:subscription 146 Name: subscription 148 Namespace: DAV 150 Purpose: To indicate that the resource is a subscription to an 151 external resource which is managed by the server. 153 Conformance: When this is specified the request MUST also contain at 154 least a DAV:subscription-href element as defined in this 155 specification. 157 Description: The DAV:specification resource type element is used to 158 indicate a collection that is a subscription. A subscription MUST 159 report the DAV:subscription XML element in the value of the DAV: 160 resourcetype property. 162 Definition: 164 166 3.2. DAV:subscription-href 168 Name: subscription-href 170 Namespace: DAV 172 Purpose: Provides the url for the external subscription. 174 Conformance: This property MUST be defined on any collection which 175 has a resource-type containing a DAV:subscription element. 177 Definition: 179 180 PCDATA value: a url 182 Example: 184 https://example.com/events.ics 187 3.3. DAV:subscription-deletions-suppressed 189 Name: subscription-deletions-suppressed 191 Namespace: DAV 193 Purpose: To indicate that resources that no longer appear in the 194 feed should be retained by the server. 196 Conformance: This property MAY be defined on any subscription. 198 Description: Many feeds provide only the current active set of 199 resources. For example, a calendar feed may only contain events 200 from the current date onwards - while many subscribers would like 201 to retain a copy of all events received over time. 203 This property indicates that the server SHOULD retain resources 204 that disappear from the feed. Services MAY define some mechanism 205 to indicate that a particular resource SHOULD be removed. For 206 example this specification suggests setting a status of DELETED on 207 a calendar event. 209 Definition: 211 213 3.4. DAV:subscription-disabled 215 Name: subscription-disabled 217 Namespace: DAV 219 Purpose: To indicate that subscription has been disabled. 221 Conformance: This property MUST be reported for any disabled 222 subscription. 224 Description: A server MAY choose to disable a subscription if there 225 is an excessive number of errors when attempting to synchronize 226 with the target This property indicates to the client that the 227 subscription has been disabled. 229 There is no explicit action that can be taken to reenable a 230 subscription. However, on subsequent requests a client may 231 indicate a refresh is desired which MAY have the effect of 232 reenabling the subscription. 234 Definition: 236 238 3.5. DAV:subscription-next-refresh 240 Name: subscription-next-refresh 242 Namespace: DAV 244 Purpose: To indicate the next refresh time for a subscription. 246 Conformance: This property MUST be reported for any active 247 subscription. 249 Description: This provides the date and time of the next refresh. 250 It uses the format defined in [RFC3986] appendix 2, that is date 251 parts are separated by "-" and time parts by ":". 253 Definition: 255 256 PCDATA value: a UTC date-time value 258 Example: 260 2019-03-15T11:00:23Z 263 4. Refreshing and Reenabling the subscription 265 The client may make use of the "Prefer" header field defined in 266 [RFC7240] with a preference of "subscription-refresh" to indicate to 267 the server that a refresh of th data as desired. 269 A server MAY choose to always ignore the header or to ignore the 270 header if it appears too often. 272 If the server decides to initiate a refresh it MAY choose to respond 273 with a 102 HTTP status indicating that it is still waiting for the 274 data or a 202 HTTP status to indicate the request was accepted. 276 5. Response Delays 278 Implementations of this feature may have an outboard or background 279 process handling the actaul synchronization of the data. The target 280 may be hosted on a slow service or the data may be very large 281 All these factors may lead to a significant delay in having data 282 ready for delivery to the client. 284 The following approaches are more or less appropriate for handling 285 requests: 287 Return with available data: This is the normal behavior. The 288 subscription looks like a regular collection so the server can 289 respond to the normal requests with whatever data is available. 291 Wait for completion: If the synchronization process is active the 292 server may just choose to wait. This risks a request timeout if 293 the data synchronization takes asignificant amount of time. 295 Return 102 status(es): The server may choose to wait but 296 periodically send a 102 response to keep the connection alive. 297 (Is this how it's supposed to work - the spec is unclear). Only 298 one 102 response would still cause a timeout - so every 20 secs? 300 Return 202 status: This is probably the best response. There is no 301 need to indicate where the client should go to retrieve the data. 302 All it needs to do is retry the operation after an appropriate 303 delay. 305 If the server decides to initiate a refresh it MAY choose to respond 306 with a 102 HTTP status indicating that it is still waiting for the 307 data or a 202 HTTP status to indicate the request was accepted 309 6. CalDAV service Considerations 311 As mentioned above, this feature is particularly useful for CalDAV 312 servers and clients. There are some specific considerations. 314 6.1. Deleted events 316 If subscription-deletions-suppressed is specified then the server 317 SHOULD retain all events. However, they server MAY choose to remove 318 old events once they become older than the CALDAV:min-date-time 319 property as specified in [RFC4791] section 5.2.6. 321 6.2. CalDAV restrictions 323 A server SHOULD apply all appropriate restrictions on events obtained 324 from a subscription. In particular the CALDAV:min-date-time and 325 CALDAV:max-date-time properties as specified in [RFC4791] sections 326 5.2.6 and 5.2.7 SHOULD be applied. 328 Additionally the CALDAV:max-resource-size property restrics the size 329 of events and the CALDAV:max-instances property the number of 330 instances. 332 6.3. Invitations in Subscriptions 334 Any reason not to allow them? 336 7. Security Considerations 338 Servers implementing this feature need to be aware of the risks 339 entailed in using the URIs provided as values to subscription-href. 340 See [RFC3986] for a discussion of the security considerations 341 relating to URIs. 343 8. Privacy Considerations 345 Properties with a "URI" value type can expose their users to privacy 346 leaks as any network access of the URI data can be tracked. Clients 347 SHOULD NOT automatically download data referenced by the URI without 348 explicit instruction from users. This specification does not 349 introduce any additional privacy concerns beyond those described in 350 [RFC5545]. 352 9. IANA Considerations 354 10. Acknowledgements 356 The author would also like to thank the members of the Calendaring 357 and Scheduling Consortium Calendar Sharing technical committee and 358 the following individuals for contributing their ideas and support: 360 ... 362 The authors would also like to thank the Calendaring and Scheduling 363 Consortium for advice with this specification. 365 11. Normative References 367 [I-D.ietf-calext-extensions] 368 Daboo, C., "New Properties for iCalendar", draft-ietf- 369 calext-extensions-05 (work in progress), August 2016. 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 377 IANA Considerations Section in RFCs", RFC 2434, 378 DOI 10.17487/RFC2434, October 1998, 379 . 381 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 382 Jensen, "HTTP Extensions for Distributed Authoring -- 383 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 384 . 386 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 387 DOI 10.17487/RFC3688, January 2004, 388 . 390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 391 Resource Identifier (URI): Generic Syntax", STD 66, 392 RFC 3986, DOI 10.17487/RFC3986, January 2005, 393 . 395 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 396 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 397 DOI 10.17487/RFC4791, March 2007, 398 . 400 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 401 Scheduling Core Object Specification (iCalendar)", 402 RFC 5545, DOI 10.17487/RFC5545, September 2009, 403 . 405 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 406 Interoperability Protocol (iTIP)", RFC 5546, 407 DOI 10.17487/RFC5546, December 2009, 408 . 410 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 411 DOI 10.17487/RFC5988, October 2010, 412 . 414 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 415 DOI 10.17487/RFC7240, June 2014, 416 . 418 [W3C.REC-xml-20060816] 419 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 420 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 421 Edition)", World Wide Web Consortium Recommendation REC- 422 xml-20060816, August 2006, 423 . 425 Appendix A. Open issues 427 invitations: Any reason not to allow them? 429 Appendix B. Change log 431 v00 2018-06-26 MD 433 o First pass 435 Author's Address 437 Michael Douglass 438 Spherical Cow Group 439 226 3rd Street 440 Troy, NY 12180 441 USA 443 Email: mdouglass@sphericalcowgroup.com 444 URI: http://sphericalcowgroup.com