RE: New feature negotiation syntax

So Spake Koen:
>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

I believe your first point misses the mark. The issue is not an
ignorance of requirements, rather it is that in having examined the
requirements we have come to understand that the requirement set is so
large that it can not be reasonably defined in any constrained fashion.
As such, rather than trying to force content providers to contort
themselves within whatever limits we arbitrarily set, it would seem more
reasonable to provide them with a mechanism by which they can express
their full range of negotiation while still producing completely
cacheable content.

As for your second point, might I respectfully suggest that it is
inappropriate to make such bold statements when you are not in full
possession of the facts.

		Yaron

> -----Original Message-----
> From:	koen@win.tue.nl [SMTP:koen@win.tue.nl]
> Sent:	Wednesday, June 04, 1997 2:14 PM
> To:	masinter@parc.xerox.com
> Cc:	koen@win.tue.nl; http-wg@cuckoo.hpl.hp.com
> Subject:	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 Friday, 6 June 1997 15:54:10 UTC