RE: New feature negotiation syntax

I do not oppose TCN. I am simply uninterested in it.

		Yaron

> -----Original Message-----
> From:	Scott Lawrence [SMTP:lawrence@agranat.com]
> Sent:	Sunday, May 25, 1997 8:15 AM
> To:	Yaron Goland
> Cc:	http-wg@cuckoo.hpl.hp.com
> Subject:	Re: New feature negotiation syntax
> 
> 
> >>>>> "YG" == Yaron Goland <yarong@microsoft.com> writes:
> 
> YG> PEP is very useful in cases where I need to make sure the server
> will do
> YG> the right thing without first having to negotiate with the server.
> 
>   I'm afraid that I don't understand how it is easier or better to
>   use downloaded Java (or other script) to determine local
> capabilities
>   and preferences in selecting variant content than to express them as
>   a wire protocol.  Your comment on PEP is equally relevant to TCN.
> 
>   Yaron - you have opposed advancing the TCN framework in the current
>   working group drafts on the basis of an as-yet unspecified
>   alternative based on downloaded scripts.  While I agree that such an
>   approach might be more powerfull and flexible _if_ there were a
>   universal framework defined, I see no attempt to publish any such
>   definition.
> 
>   As I see it, there are at least three major problems with any
>   attempt to address variant content selection with a script-based
>   approach:
> 
>   1) Requires common client-side script language support; this
> presents
>      problems both for very lightweight and very security-sensitive
>      clients.
> 
>   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).
> 
>   3) Requires an additional round trip (client requests resource,
>      server downloads script, script sends refined request).
> 
>   I believe that variant content selection is an important feature,
>   and as I've said before we like the draft framework - while it may
>   need some minor changes and may not solve every possible problem, it
>   is a reasonably economical solution to a very large part of the
>   problem space.
> 
>   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.
> 
> --
> Scott Lawrence           EmWeb Embedded Server
> <lawrence@agranat.com>
> Agranat Systems, Inc.        Engineering
> http://www.agranat.com/

Received on Friday, 6 June 1997 15:25:09 UTC