Internet DRAFT - draft-douglass-subscription-upgrade

draft-douglass-subscription-upgrade







Network Working Group                                        M. Douglass
Internet-Draft                                       Spherical Cow Group
Updates: 5545 (if approved)                                  May 5, 2018
Intended status: Standards Track
Expires: November 6, 2018


                     Calendar subscription upgrades
                 draft-douglass-subscription-upgrade-03

Abstract

   This specification introduces an approach to allow subscribers to
   calendar feeds to upgrade to a more performant protocol.

   This specification updates [RFC5545] to add the value DELETED to the
   STATUS property.

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 November 6, 2018.

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 November 6, 2018                [Page 1]

Internet-Draft       Calendar subscription upgrades             May 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.  Enhanced GET  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Deletions . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Changes to the iCalendar specifications . . . . . . . . . . .   6
     3.1.  Redefined Status property . . . . . . . . . . . . . . . .   6
   4.  Discovering alternative access methods  . . . . . . . . . . .   8
   5.  Link relation subscribe-caldav  . . . . . . . . . . . . . . .   8
   6.  Link relation subscribe-caldav-auth . . . . . . . . . . . . .   8
   7.  Link relation subscribe-webdav-sync . . . . . . . . . . . . .   8
   8.  Link relation subscribe-enhanced-get  . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Link Relation Registrations  . . . . . . . . . . . . . .   9
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Open issues  . . . . . . . . . . . . . . . . . . . .  11
   Appendix B.  Change log . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Currently clients subscribe to calendar feeds as an ics file which is
   often published as a resource accessible using the unofficial
   'webcal' scheme.

   The only available option for updating that resource is the usual
   HTTP polling of cached resources using Etags.

   There is the usual tension between clients wishing to see a timely
   response to changes and servers not wishing to be overloaded by
   frequent requests for possibly large amounts of data.

   This specification introduces an approach whereby clients can
   discover a more performant access method.  Given the location of the
   resource as an ics file, the client can perfom an OPTIONS request on
   the resource and inspect the returned headers which will offer a
   number of alternative access methods.





Douglass                Expires November 6, 2018                [Page 2]

Internet-Draft       Calendar subscription upgrades             May 2018


   Given that many clients already support CalDAV this provides an easy
   upgrade path for those clients.  CalDAV and DAV subsets are specified
   here to allow lighter weight implementations.

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

2.1.  Introduction

   This is a lightweight protocol which allows simple clients to
   efficiently discover and download changes in the targeted resource.

   It has many similarities to WebDAV sync and for a server could be
   implemented as an extension of the specification.

   In this protocol the Etag is used as the sync change token.  By
   adding the If-None-Match header field to the vary header field we can
   ensure intermediate caching proxies will be able to cache different
   versions of the data.

   The resource is treated as a set of individual events each of which
   may be updated or deleted separately.  The client will first fetch
   the entire ics file.  On subsequent requests it uses the Prefer
   header with a value of "return=minimal" to indicate that it wants a
   set of changes since the last fetch.

2.2.  Deletions

   When an entity (VEVENT, VTODO or other valid top-level component) is
   deleted from the source data the server needs to be able to inform a
   client of the deletion.  This specification introduces a new value
   for the STATUS property of DELETED.

   On the first conditional GET after the entity has been deleted a
   skeleton, but valid, entity will be returned with STATUS: DELETED.
   The receiving client is free to remove the entity or update it's
   STATUS property.

   On subsequent conditional fetches the entity will not be returned.






Douglass                Expires November 6, 2018                [Page 3]

Internet-Draft       Calendar subscription upgrades             May 2018


2.3.  Examples

   This is an example of the initial request and response from a server
   that supports the extended GET protocol.

   >> Request <<

   GET /events.ics HTTP/1.1
   Host: example.com
   Accept: text/calendar

   >> Response <<

   HTTP/1.1 200 OK
   Content-Length: xxxx
   ETag: "1234"                    current ETag (for conditional GET)
   Vary: Prefer, If-None-Match            so caching proxy can key off of client?s ETag (sync token) and preference

    BEGIN:VCALENDAR:
    ?  /* full feed */
    END:VCALENDAR


   This is an example of the subsequent request and response when no
   changes have occurred.  The Accept header field indicates that a
   VPATCH format is most desirable but simple text/calendar is
   acceptable.

      >> Request <<

      GET /events.ics HTTP/1.1
      Host: example.com
      Accept: text/calendar; q=0.5, component=VPATCH, text/calendar;
      If-None-Match: ?1234?            conditional request
      Prefer: return=minimal

      >> Response <<

      HTTP/1.1 304 Not Modified
      Content-Length: 0
      ETag: ?1234?
      Vary: Prefer, If-None-Match


   This is an example of the subsequent request and response when no
   changes have occurred.  The Accept header field indicates that a
   VPATCH format is most desirable but simple text/calendar is
   acceptable.



Douglass                Expires November 6, 2018                [Page 4]

Internet-Draft       Calendar subscription upgrades             May 2018


      >> Request <<

      GET /events.ics HTTP/1.1
      Host: example.com
      Accept: text/calendar; q=0.5, component=VPATCH, text/calendar;
      If-None-Match: "1234"            conditional request
      Prefer: return=minimal

      >> Response <<

      HTTP/1.1 304 Not Modified
      Content-Length: 0
      ETag: "1234"
      Vary: Prefer, If-None-Match


   This is an example of the subsequent request and response when
   changes have occurred and the server can create the minimal format.

   >> Request <<

   GET /events.ics HTTP/1.1
   Host: example.com
   Accept: text/calendar; q=0.5, component=VPATCH, text/calendar;
   If-None-Match: "1234"            conditional request
   Prefer: return=minimal

   >> Response <<

   HTTP/1.1 200 OK
   Content-Type: text/calendar
   Content-Length: xxxx
   ETag: "5678"                    current ETag (for conditional GET)
   Preference-Applied: return=minimal    signals to client that stream is changes  only
   Vary: Prefer, If-None-Match            so caching proxy can key off of client?s  ETag (sync token) and preference

   BEGIN:VCALENDAR:
   ...  only new/changed events
   ...  when not returning VPATCH, deleted events have STATUS:DELETED
   END:VCALENDAR


   This is an example of the subsequent request and response when
   changes have occurred and the server cannot create the minimal format
   - perhaps because of an old or invalid token.  Note there is no
   Preference-Applied header field.





Douglass                Expires November 6, 2018                [Page 5]

Internet-Draft       Calendar subscription upgrades             May 2018


   >> Request <<

   GET /events.ics HTTP/1.1
   Host: example.com
   Accept: text/calendar; q=0.5, component=VPATCH, text/calendar;
   If-None-Match: "1234"            conditional request
   Prefer: return=minimal

   >> Response <<

   HTTP/1.1 200 OK
   Content-Type: text/calendar
   Content-Length: xxxx
   ETag: "5678"                    current ETag (for conditional GET)
   Vary: Prefer, If-None-Match            so caching proxy can key off of client?s  ETag (sync token) and preference

   BEGIN:VCALENDAR:
   ...  full set of data
   END:VCALENDAR


3.  Changes to the iCalendar specifications

   This specification updates [RFC5545] to add the value DELETED to the
   STATUS property.  It also introduces the use of some properties to
   provide more information about the resource, for example the time
   range it covers.

3.1.  Redefined Status property

   Property name:  STATUS

   Purpose:  This property defines the overall status or confirmation
      for the calendar component.

   Value Type:  TEXT

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property can be specified once in "VEVENT",
      "VTODO", or "VJOURNAL" calendar components.

   Description:  In a group-scheduled calendar component, the property
      is used by the "Organizer" to provide a confirmation of the event
      to the "Attendees".  For example in a "VEVENT" calendar component,
      the "Organizer" can indicate that a meeting is tentative,
      confirmed, or cancelled.  In a "VTODO" calendar component, the



Douglass                Expires November 6, 2018                [Page 6]

Internet-Draft       Calendar subscription upgrades             May 2018


      "Organizer" can indicate that an action item needs action, is
      completed, is in process or being worked on, or has been
      cancelled.  In a "VJOURNAL" calendar component, the "Organizer"
      can indicate that a journal entry is draft, final, or has been
      cancelled or removed.

   Format Definition:

   This property is defined by the following notation:

     status          = "STATUS" statparam ":" statvalue CRLF

     statparam       = *(";" other-param)

     statvalue       = (statvalue-event
                     /  statvalue-todo
                     /  statvalue-jour)

     statvalue-event = "TENTATIVE"    ;Indicates event is tentative.
                     / "CONFIRMED"    ;Indicates event is definite.
                     / "CANCELLED"    ;Indicates event was cancelled.
                     / "DELETED"      ;Indicates event was deleted.
     ;Status values for a "VEVENT"

     statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
                     / "COMPLETED"    ;Indicates to-do completed.
                     / "IN-PROCESS"   ;Indicates to-do in process of.
                     / "CANCELLED"    ;Indicates to-do was cancelled.
                     / "DELETED"      ;Indicates to-do was deleted.
     ;Status values for "VTODO".

     statvalue-jour  = "DRAFT"        ;Indicates journal is draft.
                     / "FINAL"        ;Indicates journal is final.
                     / "CANCELLED"    ;Indicates journal is removed.
                     / "DELETED"      ;Indicates journal was deleted.
     ;Status values for "VJOURNAL".

   Example:

   Example: The following is an example of this property for a "VEVENT"
   calendar component:

     STATUS:TENTATIVE

   The following is an example of this property for a "VTODO" calendar
   component:

     STATUS:NEEDS-ACTION



Douglass                Expires November 6, 2018                [Page 7]

Internet-Draft       Calendar subscription upgrades             May 2018


   The following is an example of this property for a "VJOURNAL"
   calendar component:

     STATUS:DRAFT

4.  Discovering alternative access methods

   The advertising of other access points is achieved through the use of
   the LINK header as defined in [RFC5988].  New link relation types are
   defined in this specification - each being associated with a protocol
   or protocol subset.

   These LINK headers will be delivered when a client carries out an
   OPTIONS request targeting the URL of the resource.

5.  Link relation subscribe-caldav

   This specifies an access point which is a full implementation of
   caldav but requires no authentication.  The end point allows the full
   range of reports as defined by the CalDAV specification.

   The client MUST follow the specification to determine exactly what
   operations are allowed on the access point - for example to determine
   if sync-report is supported.

   The URL MAY include some form of token to allow write access to the
   targeted collection.  The client must check it's permissions to
   determine whether or not it has been granted write access.

6.  Link relation subscribe-caldav-auth

   This specifies an access point which is a full implementation of
   caldav and requires authentication.  This may allow read-write access
   to the resource.

   The client MUST follow the specification to determine exactly what
   operations are allowed on the access point - for example to determine
   if sync-report is supported.

7.  Link relation subscribe-webdav-sync

   This specifies an access point which supports only webdav sync.

   This allows the client to issue a sync-report on the resource to
   obtain updates.

   NOTE: say something about initial startup - use ics to populate?
   Initial token?



Douglass                Expires November 6, 2018                [Page 8]

Internet-Draft       Calendar subscription upgrades             May 2018


   The client MUST follow that specification.

8.  Link relation subscribe-enhanced-get

   This specifies an access point which supports something new.

   The client MUST follow that specification.

9.  Security Considerations

   Applications using these properties need to be aware of the risks
   entailed in using the URIs provided as values.  See [RFC3986] for a
   discussion of the security considerations relating to URIs.

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

11.  IANA Considerations

11.1.  Link Relation Registrations

   This document defines the following new iCalendar properties to be
   added to the registry defined in Section 8.2.3 of [RFC5545]:

       +------------------------+-------------+--------------------+
       | Relation Name          | Description | Reference          |
       +------------------------+-------------+--------------------+
       | subscribe-caldav       | Current     | RFCXXXX, Section 5 |
       | subscribe-caldav_auth  | Current     | RFCXXXX, Section 6 |
       | subscribe-webdav-sync  | Current     | RFCXXXX, Section 7 |
       | subscribe-enhanced_get | Current     | RFCXXXX, Section 8 |
       +------------------------+-------------+--------------------+

12.  Acknowledgements

   The author would also like to thank the members of the CalConnect
   Calendar Sharing technical committee and the following individuals
   for contributing their ideas and support:

   Marten Gajda, Ken Murchison





Douglass                Expires November 6, 2018                [Page 9]

Internet-Draft       Calendar subscription upgrades             May 2018


   The authors would also like to thank CalConnect the Calendaring and
   Scheduling Consortium for advice with this specification.

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

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

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

   [RFC4589]  Schulzrinne, H. and H. Tschofenig, "Location Types
              Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,
              <https://www.rfc-editor.org/info/rfc4589>.

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






Douglass                Expires November 6, 2018               [Page 10]

Internet-Draft       Calendar subscription upgrades             May 2018


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

Appendix A.  Open issues

   restype values:  Need to determine what if any registry of resource
      types already exists and use that.

Appendix B.  Change log

   v01 2017-07-28 MD

   o  Examples

   o  More text for extended get.  Talk about deletions.

   v01 2017-02-17 MD

   o  Add text about OPTIONS

   o  Add text abut read/write CalDAV

   v00 2017-02-15 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 November 6, 2018               [Page 11]