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

Roy T. Fielding:
>
>>>   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 interfacing problem surely exists.  It is not a byte-on-the-wire
problem, but if we ignore it, there won't be many user agents supporting
transparent negotiation.  If an easy user interface can't be built op top of
it, it is not an interesting protocol for the mainstream web.

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

Ah, so *that* is your problem.  Well, I see Alternates as intimately
connected to TCN, while the concept of a variant list is more general.  In
the TCN spec, the Alternates header acts as a flag to proxies that this
response is transparently negotiated.  If you want to use variant lists
outside of TCN, you should put them in another header.

If you think that the 1.1 spec reserves Alternates for all forms of
agent-driven negotiation, and that TCN should use some other kind of flag if
it needs one, then say so.

>  I personally would prefer that Alternates
>and Content-Location be free from any TCN influence,

Well, you told me in early 1996 that I should use Content-Location to give
the location of the variant under TCN.  The 1.1 draft also implies I
should.  I can't renegotiate on Content-Location.

> 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 will be greatly more efficient than agent-driven negotiation in some
cases.  Consider getting lots of small icons which can be either gif or png,
for a start.

Agent-driven negotiation covers only one end of the spectrum.  Look at the
big picture.  There are lots of small images around.

>TCN combines the worst of both forms of negotiation

On the contary, it allows the user agent to dynamically pick the best of the
two forms (agent-driven or server-driven).

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

Speed, speed, and more speed is exactly why TCN allows the proxy to go
through so many contortions.  You can't argue with the diagrams in section
4.3.


>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.

True.  But TCN hardly takes this naive approach.  You are right in saying
that server-driven negotiation can't work efficiently by iself, but neither
can agent-driven negotiation.  This is why TCN combines them.  Simple,
really.

[...]

> ...Roy T. Fielding

Koen.

Received on Wednesday, 19 February 1997 14:40:20 UTC