- From: Ken Murchison <murch@fastmail.com>
- Date: Wed, 9 Apr 2025 15:39:01 -0400
- To: Julian Reschke <julian.reschke@gmx.de>, calsify@ietf.org
- Cc: ietf-http-wg@w3.org
Hi Julian, I completely understand and follow your use of ETag and conditional requests in the examples below, however (and setting aside the fact that some CalDAV clients/servers typically don't use ETags correctly), the one thing that is missing from your simplified/standardized proposal is a mechanism for the client to opt-in to receiving "ONLY changes to the iCalendar stream since ETag" and a mechanism for the server to indicate to the client that its response "ONLY contains changes since ETag". Currently, the way that most, if not all, consumers of iCalendar feeds work is by downloading the ENTIRE iCalendar stream any time one or more of the events in the stream changes, possibly via a conditional request. When deploying this new "send me changes only" protocol, we have to assume that either the client and/or the server be legacy software. So the client can't assume that the server will sent it a patch and the server can't assume that the client will know what to do with a patch. Not to mention, the client needs to know whether it received the entire feed or just a patch. What would you propose to use as a client-opt-in and server indicator mechanism? I suppose we could use a variation of the text/calendar content-type as a signal, e.g. text/calendar+patch (certainly would have to be bikeshedded) in both the request and response. Just be be clear on what data is expected to be passed back and forth, here is a strawman example. Assume we have the following iCalendar stream as the starting resource having ETag:rev1 BEGIN:VCALENDAR BEGIN:VEVENT event A id & data END:VEVENT BEGIN:VEVENT event B id & data END:VEVENT BEGIN:VEVENT event C id &data END:VEVENT END:VCALENDAR Then, at some point event B is changed to B' (e.g. new time/location), event C is removed, and a new event D is added. A traditional (or "non-enhanced") client would do a conditional request (If-None-Match: rev1) and receive the following updated resource having ETag:rev2 BEGIN:VCALENDAR BEGIN:VEVENT event A id & data END:VEVENT BEGIN:VEVENT event B' id & data END:VEVENT BEGIN:VEVENT event D id &data END:VEVENT END:VCALENDAR Note that all 3 undeleted events are still in the response, even though event A did not change. An enhanced client that requests changes-only and a server that is capable would respond with the following: BEGIN:VCALENDAR BEGIN:VEVENT event B' id & data END:VEVENT BEGIN:VEVENT event C id STATUS:DELETED END:VEVENT BEGIN:VEVENT event D id &data END:VEVENT END:VCALENDAR Note that event A is NOT in the response since it was unchanged, and event C has a tombstone indicating that it was deleted. On 4/5/25 8:47 AM, Julian Reschke wrote: > Am 01.04.2025 um 00:36 schrieb The IESG: >> ... > > Hi there, > > I noticed this draft as the preference IANA registrations were sent to > me (as designated expert). > > Those seem to be related to "Enhanced GET" > (<https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-13.html#name-enhanced-get>). > > > From an HTTP point of view I'll say: don't. > > Looking at > <https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-13.html#name-examples>: > > >> EXAMPLE 1 >> >> This is an example of the initial request and response from a server >> that supports the enhanced GET method. Note the use of the Vary >> header so a caching proxy can key off the client's Sync-Token and >> preference. >> >> >> Request << >> >> GET /events.ics HTTP/1.1 >> Host: example.com >> Accept: text/calendar >> Prefer: subscribe-enhanced-get >> >> >> Response << >> >> HTTP/1.1 200 OK >> Content-Length: xxxx >> Sync-Token: "data:,1234567" > > Replace "Sync-Token" by "Etag". > >> Preference-Applied: subscribe-enhanced-get >> Vary: Prefer, Sync-Token > > Drop both. > >> BEGIN:VCALENDAR: >> ? /* full feed */ >> END:VCALENDAR > > >> EXAMPLE 2 >> >> This is an example of the subsequent request and response when no >> changes have occurred. >> >> >> Request << >> >> GET /events.ics HTTP/1.1 >> Host: example.com >> Accept: text/calendar >> Prefer: subscribe-enhanced-get > > Drop this. > >> Sync-Token: "data:,1234567" > > Make this: > > If-None-Match: "data:,1234567" > >> >> Response << >> >> HTTP/1.1 304 Not Modified >> Content-Length: 0 >> Sync-Token: "data:,1234567" > > Replace "Sync-Token" by "Etag". > >> Preference-Applied: subscribe-enhanced-get >> Vary: Prefer, Sync-Token > > Drop both. > >> EXAMPLE 3 >> >> This is an example of the subsequent request and response for an old >> or invalid token. >> >>>> Request << >> >> GET /events.ics HTTP/1.1 >> Host: example.com >> Accept: text/calendar >> Sync-Token: "data:,1234567" > > Make this: > > If-Match: "data:,1234567" > >> Prefer: subscribe-enhanced-get > > Drop this. > >> >> Response << >> >> HTTP/1.1 409 Conflict >> Content-Length: xxxx >> Preference-Applied: subscribe-enhanced-get > > That would be a 412 (Precondition Failed). > >> EXAMPLE 4 >> >> This is an example of the subsequent request and response when >> changes have occurred. >> >>>> Request << >> >> GET /events.ics HTTP/1.1 >> Host: example.com >> Accept: text/calendar >> Sync-Token: "data:,1234567" > > Make this: > > If-None-Match: "data:,1234567" > >> Prefer: subscribe-enhanced-get > > Drop this. > >> >> Response << >> >> HTTP/1.1 200 OK >> Content-Type: text/calendar >> Vary: Prefer, Sync-Token > > Vary: If-None-Match > >> Sync-Token: "data:,4567890" > > ...new Etag. > >> Preference-Applied: subscribe-enhanced-get >> BEGIN:VCALENDAR: >> ... only new/changed events >> ... deleted events have STATUS:DELETED >> END:VCALENDAR > > I believe with that, you don't need "Enhanced GET" at all, and thus > likely no new preference values. > > Best regards, Julian >
Received on Wednesday, 9 April 2025 19:39:06 UTC