Document: draft-ietf-calext-subscription-upgrade Title: Calendar subscription upgrades Reviewer: Roy Fielding Review result: Not Ready 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
