Re: [calsify] Re: Last Call: <draft-ietf-calext-subscription-upgrade-13.txt> (Calendar subscription upgrades) to Proposed Standard

Am 09.04.2025 um 21:39 schrieb Ken Murchison:
> Hi Julian,

Hi Ken,

thanks for the feedback (and sorry for cross-posting).

To start with, let's summarize the goals:

- have a way to avoid downloading the whole resource representation
(calendar data) when only an incremental diff is needed
- do not break existing clients/servers
- do not break HTTP caching, and try to make responses cacheable
- minimize the "new" things being added

> I completely understand and follow your use of ETag and conditional

FWIW; I did not invent that. It was/is used in RSS/Atom clients for the
same use case. The difference over there is that feed readers are
expected to keep the existing feed data anyway (with the client throwing
away old entries when it feels like).

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

*That* we could create a generic Prefer preference for.

Or maybe even use
<https://www.rfc-editor.org/rfc/rfc7240.html#section-4.2>?
("return=minimal"?)

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

That would be an alternative, but using Prefer (see above) might be
simpler to define and re-use.

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

Understood.

Afterthought: theoretically, you also could use QUERY with a custom
media type.

Best regards, Julian

Received on Thursday, 10 April 2025 07:23:54 UTC