idnits 2.17.1
draft-ietf-calext-serverside-subscriptions-02.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 is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
-- 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 (7 March 2022) is 779 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: 'RFC2434' is defined on line 393, but no explicit
reference was found in the text
== Unused Reference: 'RFC2518' is defined on line 398, but no explicit
reference was found in the text
== Unused Reference: 'RFC3688' is defined on line 407, but no explicit
reference was found in the text
== Unused Reference: 'RFC5546' is defined on line 426, but no explicit
reference was found in the text
== Unused Reference: 'RFC5988' is defined on line 431, but no explicit
reference was found in the text
== Unused Reference: 'RFC7240' is defined on line 435, 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: 4 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 Bedework
4 Updates: 2518 (if approved) 7 March 2022
5 Intended status: Standards Track
6 Expires: 8 September 2022
8 Serverside Subscriptions
9 draft-ietf-calext-serverside-subscriptions-02
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 8 September 2022.
36 Copyright Notice
38 Copyright (c) 2022 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 (https://trustee.ietf.org/
43 license-info) in effect on the date of publication of this document.
44 Please review these documents carefully, as they describe your rights
45 and restrictions with respect to this document. Code Components
46 extracted from this document must include Revised BSD License text as
47 described in Section 4.e of the Trust Legal Provisions and are
48 provided without warranty as described in the Revised BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
54 2. CalDAV Subscriptions . . . . . . . . . . . . . . . . . . . . 3
55 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 3. New DAV and CALDAV properties . . . . . . . . . . . . . . . . 4
57 3.1. DAV:subscription . . . . . . . . . . . . . . . . . . . . 4
58 3.2. DAV:subscription-href . . . . . . . . . . . . . . . . . . 5
59 3.3. DAV:subscription-deletions-suppressed . . . . . . . . . . 5
60 3.4. DAV:subscription-disabled . . . . . . . . . . . . . . . . 6
61 3.5. DAV:subscription-next-refresh-interval . . . . . . . . . 6
62 4. DAV:subscription-suggested-refresh-interval . . . . . . . . . 7
63 5. Refreshing and Reenabling the subscription . . . . . . . . . 7
64 6. Response Delays . . . . . . . . . . . . . . . . . . . . . . . 8
65 7. CalDAV service Considerations . . . . . . . . . . . . . . . . 8
66 7.1. Deleted events . . . . . . . . . . . . . . . . . . . . . 8
67 7.2. CalDAV restrictions . . . . . . . . . . . . . . . . . . . 8
68 7.3. Invitations in Subscriptions . . . . . . . . . . . . . . 9
69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
70 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
73 12. Normative References . . . . . . . . . . . . . . . . . . . . 9
74 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 11
75 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11
76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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<
134 /D:subscription-href>
135 true
137 PT1H
139
140
141
143 >> Response <<
145 HTTP/1.1 200 OK
147 3. New DAV and CALDAV properties
149 3.1. DAV:subscription
151 Name: subscription
153 Namespace: DAV
155 Purpose: To indicate that the resource is a subscription to an
156 external resource which is managed by the server.
158 Conformance: When this is specified the request MUST also contain at
159 least a DAV:subscription-href element as defined in this
160 specification.
162 Description: The DAV:specification resource type element is used to
163 indicate a collection that is a subscription. A subscription MUST
164 report the DAV:subscription XML element in the value of the DAV:
165 resourcetype property.
167 Definition:
168
170 3.2. DAV:subscription-href
172 Name: subscription-href
174 Namespace: DAV
176 Purpose: Provides the url for the external subscription.
178 Conformance: This property MUST be defined on any collection which
179 has a resource-type containing a DAV:subscription element.
181 Definition:
182
183 PCDATA value: a url
185 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:
212
214 3.4. DAV:subscription-disabled
216 Name: subscription-disabled
218 Namespace: DAV
220 Purpose: To indicate that subscription has been disabled.
222 Conformance: This property MUST be reported for any disabled
223 subscription.
225 Description: A server MAY choose to disable a subscription if there
226 is an excessive number of errors when attempting to synchronize
227 with the target This property indicates to the client that the
228 subscription has been disabled.
230 There is no explicit action that can be taken to reenable a
231 subscription. However, on subsequent requests a client may
232 indicate a refresh is desired which MAY have the effect of
233 reenabling the subscription.
235 Definition:
236
238 3.5. DAV:subscription-next-refresh-interval
240 Name: subscription-next-refresh-interval
242 Namespace: DAV
244 Purpose: To indicate the time interval till the next refresh of a
245 subscription.
247 Conformance: This property MUST be reported for any active
248 subscription.
250 Description: This provides a time period to the next refresh. It
251 uses the period format defined in [RFC3339].
253 Definition:
254
255 PCDATA value: a duration value
257 Example:
258 PT30M
261 4. DAV:subscription-suggested-refresh-interval
263 Name: subscription-suggested-refresh-interval
265 Namespace: DAV
267 Purpose: To indicate the desired time interval between refreshes of
268 a subscription.
270 Conformance: This property MUST be reported for any active
271 subscription.
273 Description: This provides a suggested time period between refresh.
274 It uses the period format defined in [RFC3339].
276 Definition:
277
278 PCDATA value: a duration value
280 Example:
281 PT30M
284 5. Refreshing and Reenabling the subscription
286 When creating the subscription the client may indicate to the server
287 a desired refresh interval using the a refresh of the data is desired
288 by using the PROPPATCH method to set the subscription-next-refresh-
289 interval to 0, e.g. "PT0S".
291 The client may indicate to the server that a refresh of the data is
292 desired by using the PROPPATCH method to set the subscription-next-
293 refresh-interval to 0, e.g. "PT0S".
295 A server MAY choose to always ignore the attempted refresh or to
296 ignore the patch if it appears too often.
298 If the server decides to initiate a refresh it MAY choose to respond
299 with a 102 HTTP status indicating that it is still waiting for the
300 data or a 202 HTTP status to indicate the request was accepted.
302 6. Response Delays
304 Implementations of this feature may have an outboard or background
305 process handling the actaul synchronization of the data. The target
306 may be hosted on a slow service or the data may be very large
308 All these factors may lead to a significant delay in having data
309 ready for delivery to the client.
311 The following approaches are more or less appropriate for handling
312 requests:
314 Return with available data: This is the normal behavior. The
315 subscription looks like a regular collection so the server can
316 respond to the normal requests with whatever data is available.
318 Wait for completion: If the synchronization process is active the
319 server may just choose to wait. This risks a request timeout if
320 the data synchronization takes a significant amount of time.
322 Return 102 status(es): The server may choose to wait but
323 periodically send a 102 response to keep the connection alive.
325 Return 202 status: This is probably the best response. There is no
326 need to indicate where the client should go to retrieve the data.
327 All it needs to do is retry the operation after an appropriate
328 delay.
330 7. CalDAV service Considerations
332 As mentioned above, this feature is particularly useful for CalDAV
333 servers and clients. There are some specific considerations.
335 7.1. Deleted events
337 If subscription-deletions-suppressed is specified then the server
338 SHOULD retain all events. However, the server MAY choose to remove
339 old events once they become older than the CALDAV:min-date-time
340 property as specified in [RFC4791] section 5.2.6.
342 7.2. CalDAV restrictions
344 A server SHOULD apply all appropriate restrictions on events obtained
345 from a subscription. In particular the CALDAV:min-date-time and
346 CALDAV:max-date-time properties as specified in [RFC4791] sections
347 5.2.6 and 5.2.7 SHOULD be applied.
349 Additionally the CALDAV:max-resource-size property restricts the size
350 of events and the CALDAV:max-instances property the number of
351 instances.
353 7.3. Invitations in Subscriptions
355 Any reason not to allow them?
357 8. Security Considerations
359 Servers implementing this feature need to be aware of the risks
360 entailed in using the URIs provided as values to subscription-href.
361 See [RFC3986] for a discussion of the security considerations
362 relating to URIs.
364 9. Privacy Considerations
366 Properties with a "URI" value type can expose their users to privacy
367 leaks as any network access of the URI data can be tracked. Clients
368 SHOULD NOT automatically download data referenced by the URI without
369 explicit instruction from users. This specification does not
370 introduce any additional privacy concerns beyond those described in
371 [RFC5545].
373 10. IANA Considerations
375 11. Acknowledgements
377 The author would also like to thank the members of the Calendaring
378 and Scheduling Consortium Calendar Sharing technical committee and
379 the following individuals for contributing their ideas and support:
381 ...
383 The authors would also like to thank CalConnect, the Calendaring and
384 Scheduling Consortium, for advice with this specification.
386 12. Normative References
388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
389 Requirement Levels", BCP 14, RFC 2119,
390 DOI 10.17487/RFC2119, March 1997,
391 .
393 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
394 IANA Considerations Section in RFCs", RFC 2434,
395 DOI 10.17487/RFC2434, October 1998,
396 .
398 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
399 Jensen, "HTTP Extensions for Distributed Authoring --
400 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
401 .
403 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
404 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
405 .
407 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
408 DOI 10.17487/RFC3688, January 2004,
409 .
411 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
412 Resource Identifier (URI): Generic Syntax", STD 66,
413 RFC 3986, DOI 10.17487/RFC3986, January 2005,
414 .
416 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
417 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
418 DOI 10.17487/RFC4791, March 2007,
419 .
421 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
422 Scheduling Core Object Specification (iCalendar)",
423 RFC 5545, DOI 10.17487/RFC5545, September 2009,
424 .
426 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
427 Interoperability Protocol (iTIP)", RFC 5546,
428 DOI 10.17487/RFC5546, December 2009,
429 .
431 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
432 DOI 10.17487/RFC5988, October 2010,
433 .
435 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
436 DOI 10.17487/RFC7240, June 2014,
437 .
439 [W3C.REC-xml-20060816]
440 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
441 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
442 Edition)", World Wide Web Consortium Recommendation REC-
443 xml-20060816, 16 August 2006,
444 .
446 Appendix A. Open issues
448 invitations: Any reason not to allow them?
450 Appendix B. Change log
452 v00 2018-06-26 MD
454 * First pass
456 Author's Address
458 Michael Douglass
459 Bedework
460 226 3rd Street
461 Troy, NY 12180
462 United States of America
463 Email: mdouglass@bedework.com
464 URI: http://bedework.com