Re: New feature negotiation syntax

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,
		regards,
			Ted Hardie
			NASA NIC

Received on Wednesday, 4 June 1997 15:21:22 UTC