Re: New feature negotiation syntax

Larry Masinter:
>
[...about feature negotiation...]
>
>Right now, we have a proposal for very simple 'script language',
>but it's gotten more complex over the few months we've been
>talking about it.

Larry, I think your account here is a very skewed representation of
history:

> First features were just binary (present,
>not present), just for dealing with things like 'tables'.
>Then we added numeric values for features (width, height), as
>well as enumerated values (envelope, transparency, paper),
>with equality and inequality, and then we started adding
>comparisons. 

Tags, numeric values, and (in)equality were all introduced _at the
same time_ in section 4 of draft-holtman-http-negotiation-01.txt (June
13,1996).  draft-holtman-http-negotiation-03.txt (September 6, 1996)
added enumerated values.  Since then, the only changes have been in
syntax and in numeric ranges.

>Soon, you'll have conditional expressions and...
>hey, turing complete: it's a client-side script language.

I don't see this progression to a turing complete language.

Anyway, if this WG (or anyone else) would try to standardise a single
interoperable turing-complete scripting language for negotiation, this
attempt would fail completely. The only way to get real
interoperability is to keep away from full scripting languages.
Stripting languages are now like HTML was two years ago: the major
vendors think it is in their commercial interest to keep scripting
languages subtly incompatible (usually in the API).

If Microsoft decides that they want to do negotiation only with
scripting languages, this implies that they want to provide an
infrastructure for content `best negotiated with MSIE'.  And I don't
care what their press releases say about standardising languages and
APIs.

>> 2) Requires a common API for script to read client/user preferences
>>      (I assume here that we are not just talking about a script that
>>      displays a user dialog - that is no improvement over serving a
>>      page of HTML that presents the alternative versions).
>
>The 'common API' would be just 'get registered features of
>this environment'. That is, the feature tag registration 
>could still be used! It's just that you'd use it in a script
>rather than in the protocol.

Yes, the same point is made in section 4.9 of the new draft.

    [Scott Lawrence:]
>>   I think it only fair to ask that if you are going to present an
>>   alternative that you get on with presenting it, and if not either
>> make suggestions to improve the current proposal or just state that
>>   you won't implement it and let those of us who are implementing it
>>   get on with agreeing on an interoperable solution.
>
>I encourage you to demonstrate "running code"; I think it will
>dispell a lot of the issues when we have some actual practice
>to consider, rather than speculation. 

We already had running TCN code (conneg-uax interoperating with an
Apache mod_negotiation) in the fall of 1996.  I reported on more
implementation work at the last IETF.  We cannot make progress if you
keep forgetting this.

>Larry

Koen.

Received on Wednesday, 28 May 1997 02:13:09 UTC