idnits 2.17.1
draft-douglass-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 2 instances of too long lines in the document, the longest one
being 17 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 (September 4, 2018) is 2062 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 367,
but no explicit reference was found in the text
== Unused Reference: 'RFC2434' is defined on line 376, but no explicit
reference was found in the text
== Unused Reference: 'RFC2518' is defined on line 381, but no explicit
reference was found in the text
== Unused Reference: 'RFC3688' is defined on line 386, but no explicit
reference was found in the text
== Unused Reference: 'RFC5546' is defined on line 405, but no explicit
reference was found in the text
== Unused Reference: 'RFC5988' is defined on line 410, 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 (~~), 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 Spherical Cow Group
4 Updates: 2518 (if approved) September 4, 2018
5 Intended status: Standards Track
6 Expires: March 8, 2019
8 Serverside Subscriptions
9 draft-douglass-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 properies 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 March 8, 2019.
36 Copyright Notice
38 Copyright (c) 2018 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 . . . . . . . . . . . . . . 6
63 4. Refreshing and Reenabling the subscription . . . . . . . . . 6
64 5. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 6
65 6. CalDAV service Considerations . . . . . . . . . . . . . . . . 7
66 6.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 7
67 6.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 7
68 6.3. Invitations in Subscriptions . . . . . . . . . . . . . . 8
69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
70 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
73 11. Normative References . . . . . . . . . . . . . . . . . . . . 8
74 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 10
75 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10
76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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
133 true
134
135
136
138 >> Response <<
140 HTTP/1.1 200 OK
142 3. New DAV and CALDAV properties
144 3.1. DAV:subscription
146 Name: subscription
148 Namespace: DAV
150 Purpose: To indicate that the resource is a subscription to an
151 external resource which is managed by the server.
153 Conformance: When this is specified the request MUST also contain at
154 least a DAV:subscription-href element as defined in this
155 specification.
157 Description: The DAV:specification resource type element is used to
158 indicate a collection that is a subscription. A subscription MUST
159 report the DAV:subscription XML element in the value of the DAV:
160 resourcetype property.
162 Definition:
164
166 3.2. DAV:subscription-href
168 Name: subscription-href
170 Namespace: DAV
172 Purpose: Provides the url for the external subscription.
174 Conformance: This property MUST be defined on any collection which
175 has a resource-type containing a DAV:subscription element.
177 Definition:
179
180 PCDATA value: a url
182 Example:
184 https://example.com/events.ics
187 3.3. DAV:subscription-deletions-suppressed
189 Name: subscription-deletions-suppressed
191 Namespace: DAV
193 Purpose: To indicate that resources that no longer appear in the
194 feed should be retained by the server.
196 Conformance: This property MAY be defined on any subscription.
198 Description: Many feeds provide only the current active set of
199 resources. For example, a calendar feed may only contain events
200 from the current date onwards - while many subscribers would like
201 to retain a copy of all events received over time.
203 This property indicates that the server SHOULD retain resources
204 that disappear from the feed. Services MAY define some mechanism
205 to indicate that a particular resource SHOULD be removed. For
206 example this specification suggests setting a status of DELETED on
207 a calendar event.
209 Definition:
211
213 3.4. DAV:subscription-disabled
215 Name: subscription-disabled
217 Namespace: DAV
219 Purpose: To indicate that subscription has been disabled.
221 Conformance: This property MUST be reported for any disabled
222 subscription.
224 Description: A server MAY choose to disable a subscription if there
225 is an excessive number of errors when attempting to synchronize
226 with the target This property indicates to the client that the
227 subscription has been disabled.
229 There is no explicit action that can be taken to reenable a
230 subscription. However, on subsequent requests a client may
231 indicate a refresh is desired which MAY have the effect of
232 reenabling the subscription.
234 Definition:
236
238 3.5. DAV:subscription-next-refresh
240 Name: subscription-next-refresh
242 Namespace: DAV
244 Purpose: To indicate the next refresh time for a subscription.
246 Conformance: This property MUST be reported for any active
247 subscription.
249 Description: This provides the date and time of the next refresh.
250 It uses the format defined in [RFC3986] appendix 2, that is date
251 parts are separated by "-" and time parts by ":".
253 Definition:
255
256 PCDATA value: a UTC date-time value
258 Example:
260 2019-03-15T11:00:23Z
263 4. Refreshing and Reenabling the subscription
265 The client may make use of the "Prefer" header field defined in
266 [RFC7240] with a preference of "subscription-refresh" to indicate to
267 the server that a refresh of th data as desired.
269 A server MAY choose to always ignore the header or to ignore the
270 header if it appears too often.
272 If the server decides to initiate a refresh it MAY choose to respond
273 with a 102 HTTP status indicating that it is still waiting for the
274 data or a 202 HTTP status to indicate the request was accepted.
276 5. Response Delays
278 Implementations of this feature may have an outboard or background
279 process handling the actaul synchronization of the data. The target
280 may be hosted on a slow service or the data may be very large
281 All these factors may lead to a significant delay in having data
282 ready for delivery to the client.
284 The following approaches are more or less appropriate for handling
285 requests:
287 Return with available data: This is the normal behavior. The
288 subscription looks like a regular collection so the server can
289 respond to the normal requests with whatever data is available.
291 Wait for completion: If the synchronization process is active the
292 server may just choose to wait. This risks a request timeout if
293 the data synchronization takes asignificant amount of time.
295 Return 102 status(es): The server may choose to wait but
296 periodically send a 102 response to keep the connection alive.
297 (Is this how it's supposed to work - the spec is unclear). Only
298 one 102 response would still cause a timeout - so every 20 secs?
300 Return 202 status: This is probably the best response. There is no
301 need to indicate where the client should go to retrieve the data.
302 All it needs to do is retry the operation after an appropriate
303 delay.
305 If the server decides to initiate a refresh it MAY choose to respond
306 with a 102 HTTP status indicating that it is still waiting for the
307 data or a 202 HTTP status to indicate the request was accepted
309 6. CalDAV service Considerations
311 As mentioned above, this feature is particularly useful for CalDAV
312 servers and clients. There are some specific considerations.
314 6.1. Deleted events
316 If subscription-deletions-suppressed is specified then the server
317 SHOULD retain all events. However, they server MAY choose to remove
318 old events once they become older than the CALDAV:min-date-time
319 property as specified in [RFC4791] section 5.2.6.
321 6.2. CalDAV restrictions
323 A server SHOULD apply all appropriate restrictions on events obtained
324 from a subscription. In particular the CALDAV:min-date-time and
325 CALDAV:max-date-time properties as specified in [RFC4791] sections
326 5.2.6 and 5.2.7 SHOULD be applied.
328 Additionally the CALDAV:max-resource-size property restrics the size
329 of events and the CALDAV:max-instances property the number of
330 instances.
332 6.3. Invitations in Subscriptions
334 Any reason not to allow them?
336 7. Security Considerations
338 Servers implementing this feature need to be aware of the risks
339 entailed in using the URIs provided as values to subscription-href.
340 See [RFC3986] for a discussion of the security considerations
341 relating to URIs.
343 8. Privacy Considerations
345 Properties with a "URI" value type can expose their users to privacy
346 leaks as any network access of the URI data can be tracked. Clients
347 SHOULD NOT automatically download data referenced by the URI without
348 explicit instruction from users. This specification does not
349 introduce any additional privacy concerns beyond those described in
350 [RFC5545].
352 9. IANA Considerations
354 10. Acknowledgements
356 The author would also like to thank the members of the Calendaring
357 and Scheduling Consortium Calendar Sharing technical committee and
358 the following individuals for contributing their ideas and support:
360 ...
362 The authors would also like to thank the Calendaring and Scheduling
363 Consortium for advice with this specification.
365 11. Normative References
367 [I-D.ietf-calext-extensions]
368 Daboo, C., "New Properties for iCalendar", draft-ietf-
369 calext-extensions-05 (work in progress), August 2016.
371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
372 Requirement Levels", BCP 14, RFC 2119,
373 DOI 10.17487/RFC2119, March 1997,
374 .
376 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
377 IANA Considerations Section in RFCs", RFC 2434,
378 DOI 10.17487/RFC2434, October 1998,
379 .
381 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
382 Jensen, "HTTP Extensions for Distributed Authoring --
383 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
384 .
386 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
387 DOI 10.17487/RFC3688, January 2004,
388 .
390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
391 Resource Identifier (URI): Generic Syntax", STD 66,
392 RFC 3986, DOI 10.17487/RFC3986, January 2005,
393 .
395 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
396 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
397 DOI 10.17487/RFC4791, March 2007,
398 .
400 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
401 Scheduling Core Object Specification (iCalendar)",
402 RFC 5545, DOI 10.17487/RFC5545, September 2009,
403 .
405 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
406 Interoperability Protocol (iTIP)", RFC 5546,
407 DOI 10.17487/RFC5546, December 2009,
408 .
410 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
411 DOI 10.17487/RFC5988, October 2010,
412 .
414 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
415 DOI 10.17487/RFC7240, June 2014,
416 .
418 [W3C.REC-xml-20060816]
419 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
420 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
421 Edition)", World Wide Web Consortium Recommendation REC-
422 xml-20060816, August 2006,
423 .
425 Appendix A. Open issues
427 invitations: Any reason not to allow them?
429 Appendix B. Change log
431 v00 2018-06-26 MD
433 o First pass
435 Author's Address
437 Michael Douglass
438 Spherical Cow Group
439 226 3rd Street
440 Troy, NY 12180
441 USA
443 Email: mdouglass@sphericalcowgroup.com
444 URI: http://sphericalcowgroup.com