W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

RE: New feature negotiation syntax

From: Yaron Goland <yarong@microsoft.com>
Date: Fri, 6 Jun 1997 15:22:36 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F48502EE9BF5@RED-44-MSG.dns.microsoft.com>
To: 'Scott Lawrence' <lawrence@agranat.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3424
I do not oppose TCN. I am simply uninterested in it.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC