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

Re: New feature negotiation syntax

From: Scott Lawrence <lawrence@agranat.com>
Date: Sun, 25 May 1997 11:15:17 -0400
Message-Id: <199705251515.LAA06575@devnix.agranat.com>
To: Yaron Goland <yarong@microsoft.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3333

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

  As I see it, there are at least three major problems with any
  attempt to address variant content selection with a script-based

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

  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 Sunday, 25 May 1997 08:16:50 UTC

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