Re: New feature negotiation syntax

Larry Masinter:
>
  [Koen Holtman:]
>> Larry, it seems that you want me to write a requirements document
>> which proves that Yaron's approach is wrong.  But I cannot write
such
>> a document, because I think Yaron's approach is right.
>
>Not at all. I just think we need a requirements document that says
>why we need more than what's already in HTTP/1.1.

I consider it to be a well-established fact that we need more than
what is in 1.1.  We have known for years that Accept headers do not
scale and that User-Agent based negotiation is cache-unfriendly and
error-prone.  This is all over the mailing list archives, and you can
read it in sections 1.1 and 4.2 of draft-ietf-http-negotiation too.

> If there is no
>single solution that meets the requirements, then we can evaluate
>them independently for what sub-problem they're solving, and whether
>we've covered the entire requirement space.

We won't know the entire requirement space until we have had more
experience with deployed negotiation.  I don't think we are able right
now to develop a set of protocols which together `cover the entire
requirements space'.  We do know some parts of the requirements space,
and I feel safe in saying that TCN covers large sections of known
space, but that is about it.

>> As I said at www6, it will
>> be up to the service author do decide which negotiation mechanism,
or
>> which combination of negotiation mechanisms, is appropriate for the
>> content at hand.
>
>An unbounded list of possible negotiation *mechanisms* is completely
>unacceptable, and it may not be acceptable to have more than one!

We cannot have one negotiation mechanism.  There are two main reasons
why we will have more than one:

 - we do not know enough about requirements to be able to make a
   final, unified mechanism

 - the big browser implementers are not interested in having a
   unified scripting API

We are now at a point where several small vendors want to deploy a
negotiation mechanism.  If we don't freeze TCN in time, they will
invent their own, mutually incompatible, mechanisms, and deploy those
mechanisms.  The result of not freezing TCN would thus be an
_increase_ not a decrease, in the number of negotiation mechanisms out
there.

TCN has a timing advantage in that it offers a complete spec _now_,
while a lot of other groups who have identified the need for
negotiation and metadata are still very much in a `three examples of
when this would be neat' phase.  By just being good enough and
available early, TCN could prevent the emergence of lots of
non-interoperable protocols and metadata formats (both on the web and
off it, for example in internet printing.)

But this timing advantage would be lost if we wait with freezing TCN
much longer, so I want to freeze it now.

>If service providers can decide on different mechanisms, then it would
>mean that a client that wanted to interoperate with all service
>providers would have to implement ALL of the negotiation mechanisms.

This is wrong, there will be no such pressure on clients to implement
every negotiation mechanism.  A large part of TCN is devoted to
interoperating with clients which do not implement TCN.  The same will
be true for any serious negotiation mechanism.  Service authors will
not use a negotiation mechanism if it breaks some clients: the whole
point of negotiation is breaking less clients.

>Perhaps this is another of those "it should go without saying",
>but interworking of clients with all servers should be a
>requirement of any extension to HTTP.

It should also go without saying that TCN is fully compatible with
clients not capable of TCN.

If you are really saying here that we should not extend HTTP at all,
unless the extension will be totally pervasive, I wonder why we are
working on PEP.

Koen.

Received on Wednesday, 4 June 1997 14:18:17 UTC