Internet DRAFT - draft-douglass-serverside-subscriptions

draft-douglass-serverside-subscriptions







Network Working Group                                        M. Douglass
Internet-Draft                                       Spherical Cow Group
Updates: 2518 (if approved)                            September 4, 2018
Intended status: Standards Track
Expires: March 8, 2019


                        Serverside Subscriptions
               draft-douglass-serverside-subscriptions-00

Abstract

   This specification provides a mechanism whereby subscriptions to
   external resources can be handled by the server.

   This specification updates [RFC4791] to add new properies 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 March 8, 2019.

Copyright Notice

   Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of




Douglass                  Expires March 8, 2019                 [Page 1]

Internet-Draft          Serverside Subscriptions          September 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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 . . . . . . . . . . . . . . . . . .   4
     3.3.  DAV:subscription-deletions-suppressed . . . . . . . . . .   5
     3.4.  DAV:subscription-disabled . . . . . . . . . . . . . . . .   5
     3.5.  DAV:subscription-next-refresh . . . . . . . . . . . . . .   6
   4.  Refreshing and Reenabling the subscription  . . . . . . . . .   6
   5.  Response Delays . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  CalDAV service Considerations . . . . . . . . . . . . . . . .   7
     6.1.  Deleted events  . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  CalDAV restrictions . . . . . . . . . . . . . . . . . . .   7
     6.3.  Invitations in Subscriptions  . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Open issues  . . . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Change log . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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 March 8, 2019                 [Page 2]

Internet-Draft          Serverside Subscriptions          September 2018


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.

    >> Request <<

    POST /caldav/user/mike/calendars/parrots HTTP/1.1
    Host: example.com
    Content-Type: text/calendar; component=VEVENT; method=REQUEST
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:mkcol xmlns:D="DAV:"
             xmlns:C="urn:ietf:params:xml:ns:caldav">
      <D:set>
        <D:prop>
          <D:resourcetype>
            <D:collection/>
            <C:calendar/>
            <D:subscription/>
          </D:resourcetype>
          <D:displayname>Parrot Events</D:displayname>
          <D:subscription-href>http://example.org/parrot-events.ics</D:subscription-href>
          <D:subscription-deletions-suppressed>true</D:subscription-deletions-suppressed>
        </D:prop>
      </D:set>
    </D:mkcol>

    >> Response <<

    HTTP/1.1 200 OK





Douglass                  Expires March 8, 2019                 [Page 3]

Internet-Draft          Serverside Subscriptions          September 2018


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.

   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:

            <!ELEMENT subscription empty>

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:

            <!ELEMENT vpoll-max-items (#PCDATA)>
            PCDATA value: a url


   Example:

            <D:subscription-href xmlns:D="DAV"
            >https://example.com/events.ics</D:subscription-href>






Douglass                  Expires March 8, 2019                 [Page 4]

Internet-Draft          Serverside Subscriptions          September 2018


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.

   Definition:

            <!ELEMENT subscription-deletions-suppressed empty>

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:



Douglass                  Expires March 8, 2019                 [Page 5]

Internet-Draft          Serverside Subscriptions          September 2018


            <!ELEMENT subscription-enabled empty>

3.5.  DAV:subscription-next-refresh

   Name:  subscription-next-refresh

   Namespace:  DAV

   Purpose:  To indicate the next refresh time for a subscription.

   Conformance:  This property MUST be reported for any active
      subscription.

   Description:  This provides the date and time of the next refresh.
      It uses the format defined in [RFC3986] appendix 2, that is date
      parts are separated by "-" and time parts by ":".

   Definition:

            <!ELEMENT subscription-next-refresh (#PCDATA)>
            PCDATA value: a UTC date-time value


   Example:

            <D:subscription-next-refresh xmlns:D="DAV"
            >2019-03-15T11:00:23Z</D:subscription-next-refresh>


4.  Refreshing and Reenabling the subscription

   The client may make use of the "Prefer" header field defined in
   [RFC7240] with a preference of "subscription-refresh" to indicate to
   the server that a refresh of th data as desired.

   A server MAY choose to always ignore the header or to ignore the
   header 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.

5.  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




Douglass                  Expires March 8, 2019                 [Page 6]

Internet-Draft          Serverside Subscriptions          September 2018


   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 asignificant amount of time.

   Return 102 status(es):  The server may choose to wait but
      periodically send a 102 response to keep the connection alive.
      (Is this how it's supposed to work - the spec is unclear).  Only
      one 102 response would still cause a timeout - so every 20 secs?

   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.

   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

6.  CalDAV service Considerations

   As mentioned above, this feature is particularly useful for CalDAV
   servers and clients.  There are some specific considerations.

6.1.  Deleted events

   If subscription-deletions-suppressed is specified then the server
   SHOULD retain all events.  However, they 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.

6.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 March 8, 2019                 [Page 7]

Internet-Draft          Serverside Subscriptions          September 2018


   Additionally the CALDAV:max-resource-size property restrics the size
   of events and the CALDAV:max-instances property the number of
   instances.

6.3.  Invitations in Subscriptions

   Any reason not to allow them?

7.  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.

8.  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].

9.  IANA Considerations

10.  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 the Calendaring and Scheduling
   Consortium for advice with this specification.

11.  Normative References

   [I-D.ietf-calext-extensions]
              Daboo, C., "New Properties for iCalendar", draft-ietf-
              calext-extensions-05 (work in progress), August 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Douglass                  Expires March 8, 2019                 [Page 8]

Internet-Draft          Serverside Subscriptions          September 2018


   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 2434,
              DOI 10.17487/RFC2434, October 1998,
              <https://www.rfc-editor.org/info/rfc2434>.

   [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,
              <https://www.rfc-editor.org/info/rfc2518>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
              DOI 10.17487/RFC4791, March 2007,
              <https://www.rfc-editor.org/info/rfc4791>.

   [RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
              Scheduling Core Object Specification (iCalendar)",
              RFC 5545, DOI 10.17487/RFC5545, September 2009,
              <https://www.rfc-editor.org/info/rfc5545>.

   [RFC5546]  Daboo, C., Ed., "iCalendar Transport-Independent
              Interoperability Protocol (iTIP)", RFC 5546,
              DOI 10.17487/RFC5546, December 2009,
              <https://www.rfc-editor.org/info/rfc5546>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <https://www.rfc-editor.org/info/rfc5988>.

   [RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
              DOI 10.17487/RFC7240, June 2014,
              <https://www.rfc-editor.org/info/rfc7240>.

   [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, August 2006,
              <http://www.w3.org/TR/2006/REC-xml-20060816>.



Douglass                  Expires March 8, 2019                 [Page 9]

Internet-Draft          Serverside Subscriptions          September 2018


Appendix A.  Open issues

   invitations:  Any reason not to allow them?

Appendix B.  Change log

   v00 2018-06-26 MD

   o  First pass

Author's Address

   Michael Douglass
   Spherical Cow Group
   226 3rd Street
   Troy, NY  12180
   USA

   Email: mdouglass@sphericalcowgroup.com
   URI:   http://sphericalcowgroup.com































Douglass                  Expires March 8, 2019                [Page 10]