Mark, here we again have to set the right goal.
On my mind such goal should be not the ultimate judgment
if particular implementation is right or wrong, but to provide the
information how this implementation will interoperate with the rest
of the world - now and in the foreseeable future. Especially
if we go with the proposed format when results are not
published and used for marketing.
There should be a series of tests and multiple levels of
compatibility. Compliance with the letter of 2616 is also
of some interest, this helps to predict interoperation with the
future implementations. And you are right when you talk about
looking for agreement on the common interpretation of the
spec - this may be most probable direction of future developments
one should take into account. Kind of problem is that such discussions
will inevitably push us into the HTTP development area. Is this
good or bad? I'm not sure.
- Oskar
>-----Original Message-----
>From: Mark C Nottingham [mailto:mnot@akamai.com]
>Sent: Monday, June 05, 2000 2:06 PM
>To: Vernon Schryver
>Cc: wrec@cs.utk.edu
>Subject: Re: HTTP compliance
>
>
>
>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