idnits 2.17.1 draft-ietf-calext-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 3 instances of too long lines in the document, the longest one being 29 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 (July 28, 2020) is 1367 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 394, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC2518' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC5546' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC5988' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC7240' is defined on line 445, 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 (~~), 8 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 Bedework 4 Updates: 2518 (if approved) July 28, 2020 5 Intended status: Standards Track 6 Expires: January 29, 2021 8 Serverside Subscriptions 9 draft-ietf-calext-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 properties 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 January 29, 2021. 36 Copyright Notice 38 Copyright (c) 2020 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-interval . . . . . . . . . 6 63 4. DAV:subscription-suggested-refresh-interval . . . . . . . . . 6 64 5. Refreshing and Reenabling the subscription . . . . . . . . . 7 65 6. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 7 66 7. CalDAV service Considerations . . . . . . . . . . . . . . . . 8 67 7.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 8 68 7.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 8 69 7.3. Invitations in Subscriptions . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 10 76 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The motivation for this specification was initially to handle 82 external subscriptions to calendar data. However, any resource which 83 allows subscriptions might make use of this specification. 85 Currently subscriptions to calendar feeds are handled by calendar 86 clients. There are a number of disadvantages to this approach: users 87 have to subscribe from multiple devices and the subscription cannot 88 affect scheduling handled by the server. 90 This specification defines a mechanism whereby the server will 91 subscribe to the feed and make it visible in the user's home. 93 The advantages are popular feeds can be cached by the server and the 94 user only has to make a single subscription. 96 1.1. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in 101 [RFC2119]. 103 2. CalDAV Subscriptions 105 2.1. Request 107 A client will subscribe to a URL by performing a MKCOL request with 108 resource type elements of at least DAV:collection and 109 DAV:subscription. For a calendar subscription there will also be a 110 caldav calendar element. 112 This is an example of the MKCOL request and response from a server 113 that supports extended MKCOL. 115 >> Request << 117 POST /caldav/user/mike/calendars/parrots HTTP/1.1 118 Host: example.com 119 Content-Type: text/calendar; component=VEVENT; method=REQUEST 120 Content-Length: xxxx 122 123 125 126 127 128 129 130 131 132 Parrot Events 133 http://example.org/parrot-events.ics 134 true 135 PT1H 136 137 138 140 >> Response << 142 HTTP/1.1 200 OK 144 3. New DAV and CALDAV properties 146 3.1. DAV:subscription 148 Name: subscription 150 Namespace: DAV 152 Purpose: To indicate that the resource is a subscription to an 153 external resource which is managed by the server. 155 Conformance: When this is specified the request MUST also contain at 156 least a DAV:subscription-href element as defined in this 157 specification. 159 Description: The DAV:specification resource type element is used to 160 indicate a collection that is a subscription. A subscription MUST 161 report the DAV:subscription XML element in the value of the DAV: 162 resourcetype property. 164 Definition: 166 168 3.2. DAV:subscription-href 170 Name: subscription-href 172 Namespace: DAV 174 Purpose: Provides the url for the external subscription. 176 Conformance: This property MUST be defined on any collection which 177 has a resource-type containing a DAV:subscription element. 179 Definition: 181 182 PCDATA value: a url 184 Example: 186 https://example.com/events.ics 189 3.3. DAV:subscription-deletions-suppressed 191 Name: subscription-deletions-suppressed 193 Namespace: DAV 195 Purpose: To indicate that resources that no longer appear in the 196 feed should be retained by the server. 198 Conformance: This property MAY be defined on any subscription. 200 Description: Many feeds provide only the current active set of 201 resources. For example, a calendar feed may only contain events 202 from the current date onwards - while many subscribers would like 203 to retain a copy of all events received over time. 205 This property indicates that the server SHOULD retain resources 206 that disappear from the feed. Services MAY define some mechanism 207 to indicate that a particular resource SHOULD be removed. For 208 example this specification suggests setting a status of DELETED on 209 a calendar event. 211 Definition: 213 215 3.4. DAV:subscription-disabled 217 Name: subscription-disabled 219 Namespace: DAV 221 Purpose: To indicate that subscription has been disabled. 223 Conformance: This property MUST be reported for any disabled 224 subscription. 226 Description: A server MAY choose to disable a subscription if there 227 is an excessive number of errors when attempting to synchronize 228 with the target This property indicates to the client that the 229 subscription has been disabled. 231 There is no explicit action that can be taken to reenable a 232 subscription. However, on subsequent requests a client may 233 indicate a refresh is desired which MAY have the effect of 234 reenabling the subscription. 236 Definition: 238 240 3.5. DAV:subscription-next-refresh-interval 242 Name: subscription-next-refresh-interval 244 Namespace: DAV 246 Purpose: To indicate the time interval till the next refresh of a 247 subscription. 249 Conformance: This property MUST be reported for any active 250 subscription. 252 Description: This provides a time period to the next refresh. It 253 uses the period format defined in [RFC3339]. 255 Definition: 257 258 PCDATA value: a duration value 260 Example: 262 PT30M 265 4. DAV:subscription-suggested-refresh-interval 267 Name: subscription-suggested-refresh-interval 269 Namespace: DAV 271 Purpose: To indicate the desired time interval between refreshes of 272 a subscription. 274 Conformance: This property MUST be reported for any active 275 subscription. 277 Description: This provides a suggested time period between refresh. 278 It uses the period format defined in [RFC3339]. 280 Definition: 282 283 PCDATA value: a duration value 285 Example: 287 PT30M 290 5. Refreshing and Reenabling the subscription 292 When creating the subscription the client may indicate to the server 293 a desired refresh interval using the a refresh of the data is desired 294 by using the PROPPATCH method to set the subscription-next-refresh- 295 interval to 0, e.g. "PT0S". 297 The client may indicate to the server that a refresh of the data is 298 desired by using the PROPPATCH method to set the subscription-next- 299 refresh-interval to 0, e.g. "PT0S". 301 A server MAY choose to always ignore the attempted refresh or to 302 ignore the patch if it appears too often. 304 If the server decides to initiate a refresh it MAY choose to respond 305 with a 102 HTTP status indicating that it is still waiting for the 306 data or a 202 HTTP status to indicate the request was accepted. 308 6. Response Delays 310 Implementations of this feature may have an outboard or background 311 process handling the actaul synchronization of the data. The target 312 may be hosted on a slow service or the data may be very large 314 All these factors may lead to a significant delay in having data 315 ready for delivery to the client. 317 The following approaches are more or less appropriate for handling 318 requests: 320 Return with available data: This is the normal behavior. The 321 subscription looks like a regular collection so the server can 322 respond to the normal requests with whatever data is available. 324 Wait for completion: If the synchronization process is active the 325 server may just choose to wait. This risks a request timeout if 326 the data synchronization takes a significant amount of time. 328 Return 102 status(es): The server may choose to wait but 329 periodically send a 102 response to keep the connection alive. 331 Return 202 status: This is probably the best response. There is no 332 need to indicate where the client should go to retrieve the data. 333 All it needs to do is retry the operation after an appropriate 334 delay. 336 7. CalDAV service Considerations 338 As mentioned above, this feature is particularly useful for CalDAV 339 servers and clients. There are some specific considerations. 341 7.1. Deleted events 343 If subscription-deletions-suppressed is specified then the server 344 SHOULD retain all events. However, the server MAY choose to remove 345 old events once they become older than the CALDAV:min-date-time 346 property as specified in [RFC4791] section 5.2.6. 348 7.2. CalDAV restrictions 350 A server SHOULD apply all appropriate restrictions on events obtained 351 from a subscription. In particular the CALDAV:min-date-time and 352 CALDAV:max-date-time properties as specified in [RFC4791] sections 353 5.2.6 and 5.2.7 SHOULD be applied. 355 Additionally the CALDAV:max-resource-size property restricts the size 356 of events and the CALDAV:max-instances property the number of 357 instances. 359 7.3. Invitations in Subscriptions 361 Any reason not to allow them? 363 8. Security Considerations 365 Servers implementing this feature need to be aware of the risks 366 entailed in using the URIs provided as values to subscription-href. 367 See [RFC3986] for a discussion of the security considerations 368 relating to URIs. 370 9. Privacy Considerations 372 Properties with a "URI" value type can expose their users to privacy 373 leaks as any network access of the URI data can be tracked. Clients 374 SHOULD NOT automatically download data referenced by the URI without 375 explicit instruction from users. This specification does not 376 introduce any additional privacy concerns beyond those described in 377 [RFC5545]. 379 10. IANA Considerations 381 11. Acknowledgements 383 The author would also like to thank the members of the Calendaring 384 and Scheduling Consortium Calendar Sharing technical committee and 385 the following individuals for contributing their ideas and support: 387 ... 389 The authors would also like to thank the Calendaring and Scheduling 390 Consortium for advice with this specification. 392 12. Normative References 394 [I-D.ietf-calext-extensions] 395 Daboo, C., "New Properties for iCalendar", draft-ietf- 396 calext-extensions-05 (work in progress), August 2016. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 404 IANA Considerations Section in RFCs", RFC 2434, 405 DOI 10.17487/RFC2434, October 1998, 406 . 408 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 409 Jensen, "HTTP Extensions for Distributed Authoring -- 410 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 411 . 413 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 414 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 415 . 417 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 418 DOI 10.17487/RFC3688, January 2004, 419 . 421 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 422 Resource Identifier (URI): Generic Syntax", STD 66, 423 RFC 3986, DOI 10.17487/RFC3986, January 2005, 424 . 426 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 427 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 428 DOI 10.17487/RFC4791, March 2007, 429 . 431 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 432 Scheduling Core Object Specification (iCalendar)", 433 RFC 5545, DOI 10.17487/RFC5545, September 2009, 434 . 436 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 437 Interoperability Protocol (iTIP)", RFC 5546, 438 DOI 10.17487/RFC5546, December 2009, 439 . 441 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 442 DOI 10.17487/RFC5988, October 2010, 443 . 445 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 446 DOI 10.17487/RFC7240, June 2014, 447 . 449 [W3C.REC-xml-20060816] 450 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 451 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 452 Edition)", World Wide Web Consortium Recommendation REC- 453 xml-20060816, August 2006, 454 . 456 Appendix A. Open issues 458 invitations: Any reason not to allow them? 460 Appendix B. Change log 462 v00 2018-06-26 MD 464 o First pass 466 Author's Address 468 Michael Douglass 469 Bedework 470 226 3rd Street 471 Troy, NY 12180 472 USA 474 Email: mdouglass@bedework.com 475 URI: http://bedework.com