W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: New feature negotiation syntax

From: Ted Hardie <hardie@thornhill.arc.nasa.gov>
Date: Wed, 4 Jun 1997 15:17:57 -0700
Message-Id: <9706041517.ZM13176@thornhill.arc.nasa.gov>
To: Koen Holtman <koen@win.tue.nl>, Larry Masinter <masinter@parc.xerox.com>, http-wg@cuckoo.hpl.hp.com
Cc: dwm@xpasc.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3405
On Jun 4, 11:39pm, Koen Holtman wrote:
> Subject: Re: New feature negotiation syntax
Koen writes:
> Here is the problem I think we were solving:
>   Problem: The HTTP/1.x negotiation infrastructure (Accept headers,
>   User-Agent header, Vary) is not good enough.
> At the core, it is really as simple as that.  Can we agree on this
> problem description?

I actually think that we identified the problem a bit differently:
we agreed that Accept headers, if widely and properly used
would solve all negotiation problems.  The unfortunate
downside is that they would also swallow all available bandwidth
in the process and that the processing of all the possible accept headers
would reduce response time past any conceivable usability threshold.

I think we started down the road toward
TCN with the idea that we could do as well or better using
negotiated content at several stages (origin server, proxies)
without having the bandwidth overhead.

That, I think gives us two things to test once TCN is made
experimental:  is it as good or better than accept headers?
is there a bandwidth reduction using TCN?

Of course, we would also need to know if real-world experience
demonstrates some awful, unknown side result.

I personally don't think that a full-blown requirements
document is needed for this; I believe a strong statement of scope
at the beginning and a description of what you plan to test
would be enough.  Something like:

"This document describes a method by which compliant
servers, proxies, and clients can negotiate about certain elements
of the content presented to a client.  The method aims to
do this without presenting exhaustive accept headers for each
HTTP transaction and, in so doing, hopes to reduce the
overall bandwidth required for transactions involving
resources with more than one possible presentation.   As this
implies, this method is only useful when applied to resources
with more than one representation.  We believe it will be most
useful in situations where active scripting languages are not
possible or should be avoided:  lightweight clients,  systems
which must avoid scripting for security reasons, etc.

If experience shows that the method does provide the expected savings
in bandwidth and otherwise performs at least as well as the current accept
header method,  the authors intend that the protocol be re-submitted
to the IESG for consideration as Proposed Standard.  Until that time,
however, changes in the design are possible, and implementors should
keep in mind that possiblity."

Just a quick shot at it,
			Ted Hardie
Received on Wednesday, 4 June 1997 15:21:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC