Re: Comments on draft-ietf-http-negotiation-00.txt

>>   1) There is no internal configuration error.  There is no reason
>>      why a server must be prevented from having multiple levels of
>>      negotiation, 
>
>You _can_ have multiple levels of negotiation under TCN, that is why the
>variant-vary header is there.  What you cannot have is a second level of
>_transparent_ negotiation.
>
>The reason why is simple: presenting a multiple-leveled list of variants to
>the user would be a nightmare for user interface authors.  Especially
>because the user agent would need to query all variant resources before you
>even _know_ that there are multiple levels, and you can't query them because
>of efficiency reasons.  Thus, multiple levels would kind of take the
>transparency out of transparent content negotiation.

No, you are trying to solve problems that don't exist.  The user agent
gets a response which contains Alternates, chooses one and gets a response
that contains Alternates, chooses one, etc.  If the proxy can't TCN that,
then no big deal -- just send the response to the user agent.

>As a result, the draft treats multiple-level variant lists as a
>configuration error, and does its best to report them.

Which, as I said, is a mistake.

>> aside from the fact it isn't in your conception of TCN.
>
>As opposed to your conception of TCN?  If you have a simple solution to the
>above presentation problem, by all means post the edits.  If they make sense
>to me I will gladly incorporate them.

I really don't care whether or not they are part of TCN -- what is important
is that TCN not screw-over other forms of negotiation (namely, agent-driven)
that also use the Alternates information, but without any need for
contortions due to transparency.  I personally would prefer that Alternates
and Content-Location be free from any TCN influence, because I personally
believe that TCN is less efficient for all parties (the user agent,
network, proxy, and origin server) than just providing Alternates and
letting the user agent decide what to do next, as was the original design
of agent-driven (a.k.a. reactive) negotiation.

TCN combines the worst of both forms of negotiation because it encourages
the user-agent to transmit preference-information on requests (increasing
latency and bandwidth consumption), sends Alternates information in
negotiable responses (increasing time-to-render and bandwidth consumption),
and then allows a proxy to make the best choice even though it has the
least information in which to make that decision and cannot possibly
guess the context of the request (i.e., the reason why the user agent
is requesting a particular resource -- to display, to print, to mail
to somebody else, etc) which is why we abandoned server-driven negotiation
in the first place.  The notion that a proxy should play games with
prior server responses simply doesn't work when you consider the primary
design contraints of a proxy: speed, speed, and more speed.

Any and all attempts to promote sending preference information with every
request, including the proposal for UA-* header fields, are the wrong
approach to the negotiation problem.  I am not going to stand in people's
way as they repeat the same mistakes that were made in early HTTP/1.0,
but I do insist that HTTP/1.1's capabilities not be reduced in the process.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 19 February 1997 12:14:23 UTC