From: email@example.com (Koen Holtman) Message-Id: <199902181028.LAA29385@wsooti08.win.tue.nl> To: firstname.lastname@example.org (Roy T. Fielding) Date: Thu, 18 Feb 1999 11:28:24 +0100 (MET) Cc: Koen.Holtman@cern.ch, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: Last Call: HTTP Extension Framework to Proposed Standard Roy T. Fielding: > >Koen, > >The extension framework must not automatically prevent caching. >There is nothing in Henrik's draft that prevents an extended request >or response from including the EXISTING cache control mechanisms of >HTTP/1.1. It is not necessary, nor is it desired, for the draft to >assume that an extended message is not cachable just because some >particular extension might not be cachable. Therefore, your suggested >changes are contrary to the design of HTTP. Roy, My main concern about caching in the current draft is that some of the MUST/MAY/SHOULD rules in there (see my comments sent to the IESG) will sometimes cause the caching directives of upstream servers, which generated the content, to be violated by downstream caches. This is unacceptable to me. Caching is like security: you should either provide a protocol which is correct in all cases or you should not provide it alltogether. This is separate from the issue that some extensions could _want_ to violate upstream caching directives. I see no reasons to disallow this but this use case cannot be used as an excuse for the broken MUST/MAY/SHOULD rules which apply to all extensions. The MUST/MAY/SHOULD text in the draft can be fixed, and I am trying to work on this with Henrik, but I have no idea whether we will converge. I do feel that Henrik is not treating the issue with the care it deserves. I have other concerns in that the draft is very sketchy and sometimes misleading in caching advice to implementers, but these are of a lower order than the glitches in the MUST/MAY/SHOULD discipline. Koen.