idnits 2.17.1 draft-ietf-calext-serverside-subscriptions-02.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- 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 (7 March 2022) is 779 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: 'RFC2434' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC2518' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC5546' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC5988' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC7240' is defined on line 435, 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: 4 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 Bedework 4 Updates: 2518 (if approved) 7 March 2022 5 Intended status: Standards Track 6 Expires: 8 September 2022 8 Serverside Subscriptions 9 draft-ietf-calext-serverside-subscriptions-02 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 8 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 54 2. CalDAV Subscriptions . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New DAV and CALDAV properties . . . . . . . . . . . . . . . . 4 57 3.1. DAV:subscription . . . . . . . . . . . . . . . . . . . . 4 58 3.2. DAV:subscription-href . . . . . . . . . . . . . . . . . . 5 59 3.3. DAV:subscription-deletions-suppressed . . . . . . . . . . 5 60 3.4. DAV:subscription-disabled . . . . . . . . . . . . . . . . 6 61 3.5. DAV:subscription-next-refresh-interval . . . . . . . . . 6 62 4. DAV:subscription-suggested-refresh-interval . . . . . . . . . 7 63 5. Refreshing and Reenabling the subscription . . . . . . . . . 7 64 6. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. CalDAV service Considerations . . . . . . . . . . . . . . . . 8 66 7.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 8 67 7.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 8 68 7.3. Invitations in Subscriptions . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 11 75 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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< 134 /D:subscription-href> 135 true 137 PT1H 139 140 141 143 >> Response << 145 HTTP/1.1 200 OK 147 3. New DAV and CALDAV properties 149 3.1. DAV:subscription 151 Name: subscription 153 Namespace: DAV 155 Purpose: To indicate that the resource is a subscription to an 156 external resource which is managed by the server. 158 Conformance: When this is specified the request MUST also contain at 159 least a DAV:subscription-href element as defined in this 160 specification. 162 Description: The DAV:specification resource type element is used to 163 indicate a collection that is a subscription. A subscription MUST 164 report the DAV:subscription XML element in the value of the DAV: 165 resourcetype property. 167 Definition: 168 170 3.2. DAV:subscription-href 172 Name: subscription-href 174 Namespace: DAV 176 Purpose: Provides the url for the external subscription. 178 Conformance: This property MUST be defined on any collection which 179 has a resource-type containing a DAV:subscription element. 181 Definition: 182 183 PCDATA value: a url 185 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: 212 214 3.4. DAV:subscription-disabled 216 Name: subscription-disabled 218 Namespace: DAV 220 Purpose: To indicate that subscription has been disabled. 222 Conformance: This property MUST be reported for any disabled 223 subscription. 225 Description: A server MAY choose to disable a subscription if there 226 is an excessive number of errors when attempting to synchronize 227 with the target This property indicates to the client that the 228 subscription has been disabled. 230 There is no explicit action that can be taken to reenable a 231 subscription. However, on subsequent requests a client may 232 indicate a refresh is desired which MAY have the effect of 233 reenabling the subscription. 235 Definition: 236 238 3.5. DAV:subscription-next-refresh-interval 240 Name: subscription-next-refresh-interval 242 Namespace: DAV 244 Purpose: To indicate the time interval till the next refresh of a 245 subscription. 247 Conformance: This property MUST be reported for any active 248 subscription. 250 Description: This provides a time period to the next refresh. It 251 uses the period format defined in [RFC3339]. 253 Definition: 254 255 PCDATA value: a duration value 257 Example: 258 PT30M 261 4. DAV:subscription-suggested-refresh-interval 263 Name: subscription-suggested-refresh-interval 265 Namespace: DAV 267 Purpose: To indicate the desired time interval between refreshes of 268 a subscription. 270 Conformance: This property MUST be reported for any active 271 subscription. 273 Description: This provides a suggested time period between refresh. 274 It uses the period format defined in [RFC3339]. 276 Definition: 277 278 PCDATA value: a duration value 280 Example: 281 PT30M 284 5. Refreshing and Reenabling the subscription 286 When creating the subscription the client may indicate to the server 287 a desired refresh interval using the a refresh of the data is desired 288 by using the PROPPATCH method to set the subscription-next-refresh- 289 interval to 0, e.g. "PT0S". 291 The client may indicate to the server that a refresh of the data is 292 desired by using the PROPPATCH method to set the subscription-next- 293 refresh-interval to 0, e.g. "PT0S". 295 A server MAY choose to always ignore the attempted refresh or to 296 ignore the patch if it appears too often. 298 If the server decides to initiate a refresh it MAY choose to respond 299 with a 102 HTTP status indicating that it is still waiting for the 300 data or a 202 HTTP status to indicate the request was accepted. 302 6. Response Delays 304 Implementations of this feature may have an outboard or background 305 process handling the actaul synchronization of the data. The target 306 may be hosted on a slow service or the data may be very large 308 All these factors may lead to a significant delay in having data 309 ready for delivery to the client. 311 The following approaches are more or less appropriate for handling 312 requests: 314 Return with available data: This is the normal behavior. The 315 subscription looks like a regular collection so the server can 316 respond to the normal requests with whatever data is available. 318 Wait for completion: If the synchronization process is active the 319 server may just choose to wait. This risks a request timeout if 320 the data synchronization takes a significant amount of time. 322 Return 102 status(es): The server may choose to wait but 323 periodically send a 102 response to keep the connection alive. 325 Return 202 status: This is probably the best response. There is no 326 need to indicate where the client should go to retrieve the data. 327 All it needs to do is retry the operation after an appropriate 328 delay. 330 7. CalDAV service Considerations 332 As mentioned above, this feature is particularly useful for CalDAV 333 servers and clients. There are some specific considerations. 335 7.1. Deleted events 337 If subscription-deletions-suppressed is specified then the server 338 SHOULD retain all events. However, the server MAY choose to remove 339 old events once they become older than the CALDAV:min-date-time 340 property as specified in [RFC4791] section 5.2.6. 342 7.2. CalDAV restrictions 344 A server SHOULD apply all appropriate restrictions on events obtained 345 from a subscription. In particular the CALDAV:min-date-time and 346 CALDAV:max-date-time properties as specified in [RFC4791] sections 347 5.2.6 and 5.2.7 SHOULD be applied. 349 Additionally the CALDAV:max-resource-size property restricts the size 350 of events and the CALDAV:max-instances property the number of 351 instances. 353 7.3. Invitations in Subscriptions 355 Any reason not to allow them? 357 8. Security Considerations 359 Servers implementing this feature need to be aware of the risks 360 entailed in using the URIs provided as values to subscription-href. 361 See [RFC3986] for a discussion of the security considerations 362 relating to URIs. 364 9. Privacy Considerations 366 Properties with a "URI" value type can expose their users to privacy 367 leaks as any network access of the URI data can be tracked. Clients 368 SHOULD NOT automatically download data referenced by the URI without 369 explicit instruction from users. This specification does not 370 introduce any additional privacy concerns beyond those described in 371 [RFC5545]. 373 10. IANA Considerations 375 11. Acknowledgements 377 The author would also like to thank the members of the Calendaring 378 and Scheduling Consortium Calendar Sharing technical committee and 379 the following individuals for contributing their ideas and support: 381 ... 383 The authors would also like to thank CalConnect, the Calendaring and 384 Scheduling Consortium, for advice with this specification. 386 12. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 394 IANA Considerations Section in RFCs", RFC 2434, 395 DOI 10.17487/RFC2434, October 1998, 396 . 398 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 399 Jensen, "HTTP Extensions for Distributed Authoring -- 400 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 401 . 403 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 404 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 405 . 407 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 408 DOI 10.17487/RFC3688, January 2004, 409 . 411 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 412 Resource Identifier (URI): Generic Syntax", STD 66, 413 RFC 3986, DOI 10.17487/RFC3986, January 2005, 414 . 416 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 417 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 418 DOI 10.17487/RFC4791, March 2007, 419 . 421 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 422 Scheduling Core Object Specification (iCalendar)", 423 RFC 5545, DOI 10.17487/RFC5545, September 2009, 424 . 426 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 427 Interoperability Protocol (iTIP)", RFC 5546, 428 DOI 10.17487/RFC5546, December 2009, 429 . 431 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 432 DOI 10.17487/RFC5988, October 2010, 433 . 435 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 436 DOI 10.17487/RFC7240, June 2014, 437 . 439 [W3C.REC-xml-20060816] 440 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 441 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 442 Edition)", World Wide Web Consortium Recommendation REC- 443 xml-20060816, 16 August 2006, 444 . 446 Appendix A. Open issues 448 invitations: Any reason not to allow them? 450 Appendix B. Change log 452 v00 2018-06-26 MD 454 * First pass 456 Author's Address 458 Michael Douglass 459 Bedework 460 226 3rd Street 461 Troy, NY 12180 462 United States of America 463 Email: mdouglass@bedework.com 464 URI: http://bedework.com