idnits 2.17.1
draft-ietf-calext-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 3 instances of too long lines in the document, the longest one
being 29 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 (July 28, 2020) is 1367 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 394,
but no explicit reference was found in the text
== Unused Reference: 'RFC2434' is defined on line 403, but no explicit
reference was found in the text
== Unused Reference: 'RFC2518' is defined on line 408, but no explicit
reference was found in the text
== Unused Reference: 'RFC3688' is defined on line 417, but no explicit
reference was found in the text
== Unused Reference: 'RFC5546' is defined on line 436, but no explicit
reference was found in the text
== Unused Reference: 'RFC5988' is defined on line 441, but no explicit
reference was found in the text
== Unused Reference: 'RFC7240' is defined on line 445, 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 (~~), 8 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) July 28, 2020
5 Intended status: Standards Track
6 Expires: January 29, 2021
8 Serverside Subscriptions
9 draft-ietf-calext-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 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 January 29, 2021.
36 Copyright Notice
38 Copyright (c) 2020 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-interval . . . . . . . . . 6
63 4. DAV:subscription-suggested-refresh-interval . . . . . . . . . 6
64 5. Refreshing and Reenabling the subscription . . . . . . . . . 7
65 6. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 7
66 7. CalDAV service Considerations . . . . . . . . . . . . . . . . 8
67 7.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 8
68 7.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 8
69 7.3. Invitations in Subscriptions . . . . . . . . . . . . . . 8
70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
71 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
74 12. Normative References . . . . . . . . . . . . . . . . . . . . 9
75 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 10
76 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10
77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
79 1. Introduction
81 The motivation for this specification was initially to handle
82 external subscriptions to calendar data. However, any resource which
83 allows subscriptions might make use of this specification.
85 Currently subscriptions to calendar feeds are handled by calendar
86 clients. There are a number of disadvantages to this approach: users
87 have to subscribe from multiple devices and the subscription cannot
88 affect scheduling handled by the server.
90 This specification defines a mechanism whereby the server will
91 subscribe to the feed and make it visible in the user's home.
93 The advantages are popular feeds can be cached by the server and the
94 user only has to make a single subscription.
96 1.1. Conventions Used in This Document
98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
100 "OPTIONAL" in this document are to be interpreted as described in
101 [RFC2119].
103 2. CalDAV Subscriptions
105 2.1. Request
107 A client will subscribe to a URL by performing a MKCOL request with
108 resource type elements of at least DAV:collection and
109 DAV:subscription. For a calendar subscription there will also be a
110 caldav calendar element.
112 This is an example of the MKCOL request and response from a server
113 that supports extended MKCOL.
115 >> Request <<
117 POST /caldav/user/mike/calendars/parrots HTTP/1.1
118 Host: example.com
119 Content-Type: text/calendar; component=VEVENT; method=REQUEST
120 Content-Length: xxxx
122
123
125
126
127
128
129
130
131
132 Parrot Events
133 http://example.org/parrot-events.ics
134 true
135 PT1H
136
137
138
140 >> Response <<
142 HTTP/1.1 200 OK
144 3. New DAV and CALDAV properties
146 3.1. DAV:subscription
148 Name: subscription
150 Namespace: DAV
152 Purpose: To indicate that the resource is a subscription to an
153 external resource which is managed by the server.
155 Conformance: When this is specified the request MUST also contain at
156 least a DAV:subscription-href element as defined in this
157 specification.
159 Description: The DAV:specification resource type element is used to
160 indicate a collection that is a subscription. A subscription MUST
161 report the DAV:subscription XML element in the value of the DAV:
162 resourcetype property.
164 Definition:
166
168 3.2. DAV:subscription-href
170 Name: subscription-href
172 Namespace: DAV
174 Purpose: Provides the url for the external subscription.
176 Conformance: This property MUST be defined on any collection which
177 has a resource-type containing a DAV:subscription element.
179 Definition:
181
182 PCDATA value: a url
184 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:
213
215 3.4. DAV:subscription-disabled
217 Name: subscription-disabled
219 Namespace: DAV
221 Purpose: To indicate that subscription has been disabled.
223 Conformance: This property MUST be reported for any disabled
224 subscription.
226 Description: A server MAY choose to disable a subscription if there
227 is an excessive number of errors when attempting to synchronize
228 with the target This property indicates to the client that the
229 subscription has been disabled.
231 There is no explicit action that can be taken to reenable a
232 subscription. However, on subsequent requests a client may
233 indicate a refresh is desired which MAY have the effect of
234 reenabling the subscription.
236 Definition:
238
240 3.5. DAV:subscription-next-refresh-interval
242 Name: subscription-next-refresh-interval
244 Namespace: DAV
246 Purpose: To indicate the time interval till the next refresh of a
247 subscription.
249 Conformance: This property MUST be reported for any active
250 subscription.
252 Description: This provides a time period to the next refresh. It
253 uses the period format defined in [RFC3339].
255 Definition:
257
258 PCDATA value: a duration value
260 Example:
262 PT30M
265 4. DAV:subscription-suggested-refresh-interval
267 Name: subscription-suggested-refresh-interval
269 Namespace: DAV
271 Purpose: To indicate the desired time interval between refreshes of
272 a subscription.
274 Conformance: This property MUST be reported for any active
275 subscription.
277 Description: This provides a suggested time period between refresh.
278 It uses the period format defined in [RFC3339].
280 Definition:
282
283 PCDATA value: a duration value
285 Example:
287 PT30M
290 5. Refreshing and Reenabling the subscription
292 When creating the subscription the client may indicate to the server
293 a desired refresh interval using the a refresh of the data is desired
294 by using the PROPPATCH method to set the subscription-next-refresh-
295 interval to 0, e.g. "PT0S".
297 The client may indicate to the server that a refresh of the data is
298 desired by using the PROPPATCH method to set the subscription-next-
299 refresh-interval to 0, e.g. "PT0S".
301 A server MAY choose to always ignore the attempted refresh or to
302 ignore the patch if it appears too often.
304 If the server decides to initiate a refresh it MAY choose to respond
305 with a 102 HTTP status indicating that it is still waiting for the
306 data or a 202 HTTP status to indicate the request was accepted.
308 6. Response Delays
310 Implementations of this feature may have an outboard or background
311 process handling the actaul synchronization of the data. The target
312 may be hosted on a slow service or the data may be very large
314 All these factors may lead to a significant delay in having data
315 ready for delivery to the client.
317 The following approaches are more or less appropriate for handling
318 requests:
320 Return with available data: This is the normal behavior. The
321 subscription looks like a regular collection so the server can
322 respond to the normal requests with whatever data is available.
324 Wait for completion: If the synchronization process is active the
325 server may just choose to wait. This risks a request timeout if
326 the data synchronization takes a significant amount of time.
328 Return 102 status(es): The server may choose to wait but
329 periodically send a 102 response to keep the connection alive.
331 Return 202 status: This is probably the best response. There is no
332 need to indicate where the client should go to retrieve the data.
333 All it needs to do is retry the operation after an appropriate
334 delay.
336 7. CalDAV service Considerations
338 As mentioned above, this feature is particularly useful for CalDAV
339 servers and clients. There are some specific considerations.
341 7.1. Deleted events
343 If subscription-deletions-suppressed is specified then the server
344 SHOULD retain all events. However, the server MAY choose to remove
345 old events once they become older than the CALDAV:min-date-time
346 property as specified in [RFC4791] section 5.2.6.
348 7.2. CalDAV restrictions
350 A server SHOULD apply all appropriate restrictions on events obtained
351 from a subscription. In particular the CALDAV:min-date-time and
352 CALDAV:max-date-time properties as specified in [RFC4791] sections
353 5.2.6 and 5.2.7 SHOULD be applied.
355 Additionally the CALDAV:max-resource-size property restricts the size
356 of events and the CALDAV:max-instances property the number of
357 instances.
359 7.3. Invitations in Subscriptions
361 Any reason not to allow them?
363 8. Security Considerations
365 Servers implementing this feature need to be aware of the risks
366 entailed in using the URIs provided as values to subscription-href.
367 See [RFC3986] for a discussion of the security considerations
368 relating to URIs.
370 9. Privacy Considerations
372 Properties with a "URI" value type can expose their users to privacy
373 leaks as any network access of the URI data can be tracked. Clients
374 SHOULD NOT automatically download data referenced by the URI without
375 explicit instruction from users. This specification does not
376 introduce any additional privacy concerns beyond those described in
377 [RFC5545].
379 10. IANA Considerations
381 11. Acknowledgements
383 The author would also like to thank the members of the Calendaring
384 and Scheduling Consortium Calendar Sharing technical committee and
385 the following individuals for contributing their ideas and support:
387 ...
389 The authors would also like to thank the Calendaring and Scheduling
390 Consortium for advice with this specification.
392 12. Normative References
394 [I-D.ietf-calext-extensions]
395 Daboo, C., "New Properties for iCalendar", draft-ietf-
396 calext-extensions-05 (work in progress), August 2016.
398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
399 Requirement Levels", BCP 14, RFC 2119,
400 DOI 10.17487/RFC2119, March 1997,
401 .
403 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
404 IANA Considerations Section in RFCs", RFC 2434,
405 DOI 10.17487/RFC2434, October 1998,
406 .
408 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
409 Jensen, "HTTP Extensions for Distributed Authoring --
410 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
411 .
413 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
414 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
415 .
417 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
418 DOI 10.17487/RFC3688, January 2004,
419 .
421 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
422 Resource Identifier (URI): Generic Syntax", STD 66,
423 RFC 3986, DOI 10.17487/RFC3986, January 2005,
424 .
426 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
427 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
428 DOI 10.17487/RFC4791, March 2007,
429 .
431 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
432 Scheduling Core Object Specification (iCalendar)",
433 RFC 5545, DOI 10.17487/RFC5545, September 2009,
434 .
436 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
437 Interoperability Protocol (iTIP)", RFC 5546,
438 DOI 10.17487/RFC5546, December 2009,
439 .
441 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
442 DOI 10.17487/RFC5988, October 2010,
443 .
445 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
446 DOI 10.17487/RFC7240, June 2014,
447 .
449 [W3C.REC-xml-20060816]
450 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
451 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
452 Edition)", World Wide Web Consortium Recommendation REC-
453 xml-20060816, August 2006,
454 .
456 Appendix A. Open issues
458 invitations: Any reason not to allow them?
460 Appendix B. Change log
462 v00 2018-06-26 MD
464 o First pass
466 Author's Address
468 Michael Douglass
469 Bedework
470 226 3rd Street
471 Troy, NY 12180
472 USA
474 Email: mdouglass@bedework.com
475 URI: http://bedework.com