Network Working Group M. Douglass Internet-Draft Bedework Updates: 2518 (if approved) 7 March 2022 Intended status: Standards Track Expires: 8 September 2022 Serverside Subscriptions draft-ietf-calext-serverside-subscriptions-02 Abstract This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates RFC4791 to add new properties for the MKCOL request. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Douglass Expires 8 September 2022 [Page 1] Internet-Draft Serverside Subscriptions March 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. CalDAV Subscriptions . . . . . . . . . . . . . . . . . . . . 3 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. New DAV and CALDAV properties . . . . . . . . . . . . . . . . 4 3.1. DAV:subscription . . . . . . . . . . . . . . . . . . . . 4 3.2. DAV:subscription-href . . . . . . . . . . . . . . . . . . 5 3.3. DAV:subscription-deletions-suppressed . . . . . . . . . . 5 3.4. DAV:subscription-disabled . . . . . . . . . . . . . . . . 6 3.5. DAV:subscription-next-refresh-interval . . . . . . . . . 6 4. DAV:subscription-suggested-refresh-interval . . . . . . . . . 7 5. Refreshing and Reenabling the subscription . . . . . . . . . 7 6. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 8 7. CalDAV service Considerations . . . . . . . . . . . . . . . . 8 7.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 8 7.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 8 7.3. Invitations in Subscriptions . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The motivation for this specification was initially to handle external subscriptions to calendar data. However, any resource which allows subscriptions might make use of this specification. Currently subscriptions to calendar feeds are handled by calendar clients. There are a number of disadvantages to this approach: users have to subscribe from multiple devices and the subscription cannot affect scheduling handled by the server. This specification defines a mechanism whereby the server will subscribe to the feed and make it visible in the user's home. The advantages are popular feeds can be cached by the server and the user only has to make a single subscription. Douglass Expires 8 September 2022 [Page 2] Internet-Draft Serverside Subscriptions March 2022 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. CalDAV Subscriptions 2.1. Request A client will subscribe to a URL by performing a MKCOL request with resource type elements of at least DAV:collection and DAV:subscription. For a calendar subscription there will also be a caldav calendar element. This is an example of the MKCOL request and response from a server that supports extended MKCOL. Douglass Expires 8 September 2022 [Page 3] Internet-Draft Serverside Subscriptions March 2022 >> Request << POST /caldav/user/mike/calendars/parrots HTTP/1.1 Host: example.com Content-Type: text/calendar; component=VEVENT; method=REQUEST Content-Length: xxxx Parrot Events http://example.org/parrot-events.ics< /D:subscription-href> true PT1H >> Response << HTTP/1.1 200 OK 3. New DAV and CALDAV properties 3.1. DAV:subscription Name: subscription Namespace: DAV Purpose: To indicate that the resource is a subscription to an external resource which is managed by the server. Conformance: When this is specified the request MUST also contain at least a DAV:subscription-href element as defined in this specification. Douglass Expires 8 September 2022 [Page 4] Internet-Draft Serverside Subscriptions March 2022 Description: The DAV:specification resource type element is used to indicate a collection that is a subscription. A subscription MUST report the DAV:subscription XML element in the value of the DAV: resourcetype property. Definition: 3.2. DAV:subscription-href Name: subscription-href Namespace: DAV Purpose: Provides the url for the external subscription. Conformance: This property MUST be defined on any collection which has a resource-type containing a DAV:subscription element. Definition: PCDATA value: a url Example: https://example.com/events.ics 3.3. DAV:subscription-deletions-suppressed Name: subscription-deletions-suppressed Namespace: DAV Purpose: To indicate that resources that no longer appear in the feed should be retained by the server. Conformance: This property MAY be defined on any subscription. Description: Many feeds provide only the current active set of resources. For example, a calendar feed may only contain events from the current date onwards - while many subscribers would like to retain a copy of all events received over time. This property indicates that the server SHOULD retain resources that disappear from the feed. Services MAY define some mechanism to indicate that a particular resource SHOULD be removed. For example this specification suggests setting a status of DELETED on a calendar event. Douglass Expires 8 September 2022 [Page 5] Internet-Draft Serverside Subscriptions March 2022 Definition: 3.4. DAV:subscription-disabled Name: subscription-disabled Namespace: DAV Purpose: To indicate that subscription has been disabled. Conformance: This property MUST be reported for any disabled subscription. Description: A server MAY choose to disable a subscription if there is an excessive number of errors when attempting to synchronize with the target This property indicates to the client that the subscription has been disabled. There is no explicit action that can be taken to reenable a subscription. However, on subsequent requests a client may indicate a refresh is desired which MAY have the effect of reenabling the subscription. Definition: 3.5. DAV:subscription-next-refresh-interval Name: subscription-next-refresh-interval Namespace: DAV Purpose: To indicate the time interval till the next refresh of a subscription. Conformance: This property MUST be reported for any active subscription. Description: This provides a time period to the next refresh. It uses the period format defined in [RFC3339]. Definition: PCDATA value: a duration value Douglass Expires 8 September 2022 [Page 6] Internet-Draft Serverside Subscriptions March 2022 Example: PT30M 4. DAV:subscription-suggested-refresh-interval Name: subscription-suggested-refresh-interval Namespace: DAV Purpose: To indicate the desired time interval between refreshes of a subscription. Conformance: This property MUST be reported for any active subscription. Description: This provides a suggested time period between refresh. It uses the period format defined in [RFC3339]. Definition: PCDATA value: a duration value Example: PT30M 5. Refreshing and Reenabling the subscription When creating the subscription the client may indicate to the server a desired refresh interval using the a refresh of the data is desired by using the PROPPATCH method to set the subscription-next-refresh- interval to 0, e.g. "PT0S". The client may indicate to the server that a refresh of the data is desired by using the PROPPATCH method to set the subscription-next- refresh-interval to 0, e.g. "PT0S". A server MAY choose to always ignore the attempted refresh or to ignore the patch if it appears too often. If the server decides to initiate a refresh it MAY choose to respond with a 102 HTTP status indicating that it is still waiting for the data or a 202 HTTP status to indicate the request was accepted. Douglass Expires 8 September 2022 [Page 7] Internet-Draft Serverside Subscriptions March 2022 6. Response Delays Implementations of this feature may have an outboard or background process handling the actaul synchronization of the data. The target may be hosted on a slow service or the data may be very large All these factors may lead to a significant delay in having data ready for delivery to the client. The following approaches are more or less appropriate for handling requests: Return with available data: This is the normal behavior. The subscription looks like a regular collection so the server can respond to the normal requests with whatever data is available. Wait for completion: If the synchronization process is active the server may just choose to wait. This risks a request timeout if the data synchronization takes a significant amount of time. Return 102 status(es): The server may choose to wait but periodically send a 102 response to keep the connection alive. Return 202 status: This is probably the best response. There is no need to indicate where the client should go to retrieve the data. All it needs to do is retry the operation after an appropriate delay. 7. CalDAV service Considerations As mentioned above, this feature is particularly useful for CalDAV servers and clients. There are some specific considerations. 7.1. Deleted events If subscription-deletions-suppressed is specified then the server SHOULD retain all events. However, the server MAY choose to remove old events once they become older than the CALDAV:min-date-time property as specified in [RFC4791] section 5.2.6. 7.2. CalDAV restrictions A server SHOULD apply all appropriate restrictions on events obtained from a subscription. In particular the CALDAV:min-date-time and CALDAV:max-date-time properties as specified in [RFC4791] sections 5.2.6 and 5.2.7 SHOULD be applied. Douglass Expires 8 September 2022 [Page 8] Internet-Draft Serverside Subscriptions March 2022 Additionally the CALDAV:max-resource-size property restricts the size of events and the CALDAV:max-instances property the number of instances. 7.3. Invitations in Subscriptions Any reason not to allow them? 8. Security Considerations Servers implementing this feature need to be aware of the risks entailed in using the URIs provided as values to subscription-href. See [RFC3986] for a discussion of the security considerations relating to URIs. 9. Privacy Considerations Properties with a "URI" value type can expose their users to privacy leaks as any network access of the URI data can be tracked. Clients SHOULD NOT automatically download data referenced by the URI without explicit instruction from users. This specification does not introduce any additional privacy concerns beyond those described in [RFC5545]. 10. IANA Considerations 11. Acknowledgements The author would also like to thank the members of the Calendaring and Scheduling Consortium Calendar Sharing technical committee and the following individuals for contributing their ideas and support: ... The authors would also like to thank CalConnect, the Calendaring and Scheduling Consortium, for advice with this specification. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, DOI 10.17487/RFC2434, October 1998, . Douglass Expires 8 September 2022 [Page 9] Internet-Draft Serverside Subscriptions March 2022 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, . [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, . [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014, . [W3C.REC-xml-20060816] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC- xml-20060816, 16 August 2006, . Douglass Expires 8 September 2022 [Page 10] Internet-Draft Serverside Subscriptions March 2022 Appendix A. Open issues invitations: Any reason not to allow them? Appendix B. Change log v00 2018-06-26 MD * First pass Author's Address Michael Douglass Bedework 226 3rd Street Troy, NY 12180 United States of America Email: mdouglass@bedework.com URI: http://bedework.com Douglass Expires 8 September 2022 [Page 11]