IETF Last Call Review of draft-ietf-calext-subscription-upgrade-13
review-ietf-calext-subscription-upgrade-13-httpdir-lc-fielding-2025-04-13-00

draft-ietf-calext-subscription-upgrade-13 talks about extending the ical media
type to support retrieval of calendar updates, and then proceeds to go off the
deep end with an ill-conceived and application-specific extension to HTTP's GET
method. That is neither an appropriate scope for the calext working group nor
an Internet-safe idea given the effect of Vary on cache behavior. Caching is
important for internet-based calendars.

This draft faces a common problem (retrieving only the updates) and attempts to
create a unique solution via HTTP. I cannot count the number of times that same
kind of proposal has been brought to the IETF as a transfer protocol change,
when in fact the transfer protocol isn't what needs to change. [Yes, I am aware
that many other groups have failed to implement the exact same thing using
their own application-specific protocol changes; please do not follow their
failed examples.]

A stream of updates of a resource is, by definition, a different resource. Like
all such resources, provision of a different URI (by link or link template)
could enable that feature without any changes to HTTP and its implementations.
Such an extension can be defined by the ical-specific processing engine (i.e.,
the media type specification or an extension to it) just like HTML specifies
its own processing model. IOW, define how calendars provide a link (template)
to a different resource for delta-retrieval, place the "opaque token" inside
that linked URI, and then perform a normal information retrieval action on that
resource to retrieve the delta (using the same or different calendar
application-specific data format). No change to HTTP.

It's the Web; just use it. We don't need an enhanced retrieval protocol. We
only need a representation for the updates and a media type. IOW, a
specification of the processing model for interpreting the "entries updated
since token" in relation to the original calendar representation. Such a
solution is not specific to HTTP, and thus usable wherever calext data might be
found.