Re: New feature negotiation syntax

Jim Gettys:
>
>I've been watching the situation on content negotiation now for 18 months.

Thanks for speaking up now.  Your dicussion of requirements clears up
some things which I did not understand when Larry tried to explain
them to me.

[...]
>For example, I have a (personal) belief that only the client can
>have enough information to make an informed choice, and that having
>a proxy try to short circuit the first round trip will ultimately be futile.
[...]
>Note that if you don't believe
>in a requirement to avoid this latency, you get a fundamental split in
>possible solutions.  Until you do have a shared understanding of requirements,
>any discussion of solutions will likely end up a futile exercise.

I do not see `avoid this latency' as a requirement, it is a wish, as
in `it would be nice if the protocol could eliminate round trips
whenever possible'. 

TCN , or rather the RVSA draft which was split off some time ago
contains a mechanism (the remote variant selection algorithm) which
could eliminate round trips, and it is a fairly powerful mechanism.
But *I do not know how often RVSAs would save a round-trip in
practice*, because this depends on the nature of the negotiated
content, and nobody knows what average negotiated content will look
like after negotiation is deployed.

RVSAs can save round-trips if the variant list is not yet in a cache
near the browser (and given the 40% cache efficiency figure, this will
occur often), and if the negotiation is on a single `small' dimension
like language, or if multiple negotiated resources on the same server,
which all negotiate on the same things, are accessed.  I do not know
how often this will be the case.

Coming back to your statement:

>Note that if you don't believe
>in a requirement to avoid this latency, you get a fundamental split in
>possible solutions.  Until you do have a shared understanding of requirements,
>any discussion of solutions will likely end up a futile exercise.

I claim that there is _no_ fundamental split in possible solutions,
depending on whether you believe in RVSAs.

If we would decide to forget all about RVSAs, this would have no big
consequences for the main TCN draft.  It would not make minimal
conformant implementations significantly smaller, and would not clear
the way to important design alternatives which were previously blocked.

The draft would only get a bit simpler if we throw out choice
responses too.  But choice responses are not just there for supporting
RVSAs, they are also very important for cache-friendly compatibility
with agents not capable of TCN.

The only requirement I have with respect to RVSAs is that I want the
main TCN draft to _allow for_ the deployment of RVSAs, and allowing
for this is cheap.  If we would not allow for RVSAs, and statistics
would later prove that this was a mistake, we would have a hard time
correcting this mistake.

>Until there is shared belief on the requirements (or at least some subset
>of total requirements), I'm pessimistic about making progress...

I don't think we need to have a shared belief on whether RVSAs will
work, we only need to agree on whether we want to risk a small amount
of extra complexity on the chance that they will work.

Maybe you just chose a bad example, but it could be that you are
thinking of TCN as a much more closed framework than it actually is.
The TCN design does not contain final rulings on that many topics.

I don't think that by making the main TCN draft an experimental RFC, we
would require things from implementers without knowing whether these
things could or should be done.

>				- Jim Gettys

Koen.

Received on Tuesday, 10 June 1997 13:38:11 UTC