Cache vendors have taken a remarkably long time to start correctly
implementing HTTP cacheability measures (Cache-Control, ageing, cacheability
rules, etc). Current practice is a mush of different (mis-)interpretations
of the specification. It would be of no benefit to gather consensus on these
issues; they don't work because of misimplementation, rather than poor
specification.
In other words, allowing current practice to supercede standards presupposes
that current practice has solved problems unforseen by the authors.
As far as complete compliance testing goes, we'd need to get interest and
participation from both server and client vendors before we can determine
that we represent true current practice.
On Mon, Jun 05, 2000 at 11:49:08AM -0600, Vernon Schryver wrote:
> > From: Mark C Nottingham <mnot@akamai.com>
>
> > ...
> > from the specification. i.e., it would be good to test for optimal
> > operation, etc., but to declare that common practice supercedes an explicit
> > requirement in the specification is IMHO folly.
>
> Some people figure that going out of business is a greater folly.
> Others giggle about the OSI style of protocol development.
>
> In other words, the IETF slogans "rough consensus and running code"
> and "be conservative in what you send and generous in what you accept"
> are supposed to supersede all explicit requirements.
>
> ....
>
> Is anything happening with the redirection proxy hazards document
> or the NECP document? The silence about them is deafening.
>
>
> Vernon Schryver vjs@rhyolite.com
-- Mark Nottingham, Senior Developer Akamai Technologies (San Mateo, CA)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST