Re: New feature negotiation syntax

Larry Masinter:
>
>> Larry, I think your account here is a very skewed representation of
>> history:
>
>I'm sorry, my hasty note wasn't meant to be a representation
>of history, but a representation of the line of reasoning
>that would lead one to believe that 'dynamic content' might
>actually be the 'right' way to do what TCN is trying to do.

Oh, OK.  I can see why one would want to make such an argument.

>Perhaps it is a specious argument, but you should consider
>seriously whether the real world cases for actual content
>negotiation can actually be satisfied by the simplified
>conditionals available in TCN; we have at least one vendor
>who says "no, it's not adequate, dynamic content is better."

Limited TCN conditionals cannot compete, as far as power is concerned,
with a turing-complete scripting language with a good API.  On the
other hand, I think they can compete as far as short-term
interoperability is concerned.

Yaron did not really say that TCN was deficient for what he wanted to
do: he said that they would have no need for it under the MS scripting
language strategy.

And as Scott Lawrence pointed out, turing-complete scripting is no
good solution for very lightweight and very security-sensitive
clients.

>The point of 'running code' is not merely to demonstrate
>'can this be implemented?' but also 'is it effective, when
>implemented, in satisfying the requirements?'

We have some vendors who do think that TCN variant descriptions are
adequate for at least their short-term requirements.  These vendors
want to deploy Real Soon Now.  I'm interested in making these vendors
happy.

I do not see the need to demonstrate that TCN will be good enough for
_all_ vendors and _all_ situations.  TCN won't shine your shoes
either.  It is not supposed to.

Anyway, TCN is very extensible, and can co-exist with other means of
negotiation.  Deploying TCN and then improving it a few years later,
based on actual experience in using negotiated content, is a good
route to take.

>Unfortunately, we don't have a separate document laying out
>what the requirements ARE, 

The first few chapters of the TCN spec tell what it is supposed to do.
If you want to measure the protocol against some requirements, measure
it against the first few chapters.

Here is my take on where we are with TCN:

It looks like TCN will start out as a protocol used by niche
applications, not as a protocol for the Big Browsers.  (Though one Big
Server will probably support it.)  That is fine with me: niche
applications need interoperable protocols too, and given the size of
the web a niche application is still a fairly large thing, large
enough for this WG to care about.  And it is very well possible that
TCN will grow into the main stream later (e.g. if someone implements
TCN in uploadable Java or as a Plugin for the Big Browsers).

If you want, we can put some statements on the limited applicability
of TCN in the introduction.  I would do that rather than iterate until
it shines your shoes.

>Larry

Koen.

Received on Friday, 30 May 1997 03:05:58 UTC