RE: New feature negotiation syntax

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.

Received on Friday, 6 June 1997 15:32:36 UTC