Subject: Re: HTTP compliance

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 Jun 2000 11:49:08 -0600 (MDT)

> From: Mark C Nottingham <[email-masked]>

> ...
> 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    [email-masked]

---

From: Mark C Nottingham <[email-masked]>
Date: Mon, 5 Jun 2000 11:05:38 -0700

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. 

-- 
Mark Nottingham, Senior Developer
Akamai Technologies (San Mateo, CA)

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 5 Jun 2000 15:48:32 -0400

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:[email-masked]]
>Sent: Monday, June 05, 2000 2:06 PM
>To: Vernon Schryver
>Cc: [email-masked]
>Subject: Re: HTTP compliance
>
>
>

---

From: Mark C Nottingham <[email-masked]>
Date: Mon, 5 Jun 2000 14:15:11 -0700

> published and used for marketing.

Well said. Interesting points of contact are:
* other intermediates (proxies, caches)
* client software (user-agents)
* server software (origin servers)
* content providers' expectations
* end user expectations (?)

It's obviously the last two that I'm focused on, but the others are just as
worthy. However, they may be a somewhat more ambitious undertaking.

> good or bad? I'm not sure. 

One way to find out! Seriously, there's a lot of ground to be covered there.
As Jeff mentioned, if there are ambiguities or conflicts in the spec, now is
the appropriate time to raise them with the wg.

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Jun 2000 15:45:46 -0700

> or the NECP document?  The silence about them is deafening.

My understanding is that there is interest in incorporating
the proxy hazards issues into a current document, namely
"known problems". Some of the issues are already raised there,
and the sum of issues I am aware of is available on the website
summary I posted earlier. 

I don't know how to best integrate it with that document, though.
I've given the framework, I'm not sure free-running text would
be more useful at this point.

Joe

---

From: Jeremy Elson <[email-masked]>
Date: Mon, 05 Jun 2000 16:06:57 -0700

>or the NECP document?  The silence about them is deafening.

We're working on a new draft of NECP that focuses exclusively on its
use in server-farm load-balancing.  We do not mention its potential
[mis]use in a redirection/interception proxy (or whatever the current
term is for those things).  Instead, we assume that the topic will be
discussed fully, and in context, in either the redirection proxy
hazards or "known problems" document.

Currently, the actual protocol definition is unchanged with respect to
previous versions of the draft.  (We did replace all mentions of the
word "standard" with "protocol", though, in recognition of the fact
that this is to be an Informational RFC and is not currently on the
Standards track).

-Jeremy