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

I pulled the document back into the CALEXT working group while we work on this.

Not ideal to be dragged back from IESG a second time, but better to build the right thing.  Thanks everyone.

Bron.

On Fri, Apr 11, 2025, at 04:26, Martin Thomson wrote:
> Not speaking about the specific recommendations that Julian makes (which seem broadly good), but this seems to be a case where a generic HTTP capability is warranted.  This is not something specific to CalDAV, but one that comes up often.  We have a version of that for requests in the upload resumption work we are currently undertaking, which might hold some lessons.
> 
> It seems like this should not be a calsify effort, but an HTTP one.  I realize that this is very late in the process, and likely an unwelcome surprise, but we can maybe take this opportunity to build something that works for all applications, considering all the factors that Julian describes.
> 
> On Thu, Apr 10, 2025, at 09:23, Julian Reschke wrote:
> > 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
> 
> _______________________________________________
> calsify mailing list -- calsify@ietf.org
> To unsubscribe send an email to calsify-leave@ietf.org
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com