RE: New feature negotiation syntax
Yaron Goland (yarong@microsoft.com)
Fri, 6 Jun 1997 15:30:30 -0700
So spake Koen:
>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.
Actually ECMA is now standardizing the syntax for client side scripting
and the W3C is now standardizing the object model that scripting will
invoke.
Yaron
> -----Original Message-----
> From: koen@win.tue.nl [SMTP:koen@win.tue.nl]
> Sent: Wednesday, May 28, 1997 2:11 AM
> To: masinter@parc.xerox.com
> Cc: lawrence@agranat.com; Yaron Goland;
> http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject: 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.