Re: New feature negotiation syntax

There is some merit to acknowledging that the general notion
of 'tuning content to the user environment' can a real tarpit.
The problem is that there's no good way to characterize
the whole variability of content, and the feature expression
language isn't (and shouldn't be) turing complete; sometimes
the pages are 'almost' the same for two different environments,
and you'd like the adjustment to happen after receipt.

>  1) Requires common client-side script language support; this presents
>      problems both for very lightweight and very security-sensitive
>      clients.

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. 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. Soon, you'll have conditional expressions and...
hey, turing complete: it's a client-side script language.

>   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.

>   3) Requires an additional round trip (client requests resource,
>      server downloads script, script sends refined request).

Maybe the client-side scripting would generate the different
URLs for the embedded or linked content, rather than incur
this extra round trip. That's what happens in most of these cases,
isn't it?

>   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. In the meanwhile, it's useful
to know whether or not implementors are interested.

I'm not at all eager to scuttle work on TCN if there is activity
on it. I'm willing to try to put it back onto the "milestone" list
if there's a realistic schedule for completion of the work, but
we're already nearly a year after we finished Proposed HTTP/1.1.

So, what's the schedule? Who is committed to working on the
spec and implementations?

Larry
-- 
http://www.parc.xerox.com/masinter

Received on Tuesday, 27 May 1997 21:56:00 UTC