Re: PEP Battle Plan [rexmit, garbled]

Keith Moore:
>
 [Rohit:]
>> Progress on an extension mechanism is essential because it is the future
of
>> 1.x and binary encodings of it.
>
>I realize this is heresy here, but I have to wonder if it's worth
>building the extension mechanism into HTTP.  An efficient URI
>resolution protocol would allow for a smooth transition away from
>HTTP 1.x and to 2.x or other protocols (smb? webnfs? multicast?), 
>without invalidating old clients and without the overhead of 
>establishing a TCP connection.

I don't see PEP primarily as a means to enable smooth transitions to
faster content transmission protocols.

PEP will (at least, I hope it will) enable the addition of new
_services_ on top of the HTTP content transmission service.  Examples
of such services are content rating and (micro)payments.

PEP will (at least, I hope it will) allow such services to have a very
low overhead, by piggy-backing them onto HTTP transactions which are
already happening.

This is the part of the PEP draft that makes me interested in PEP:

   In addition to reliably describing statically extended HTTP servers
   and clients, PEP will work with dynamically extended agents. Indeed,
   the authors expect that PEP will drive the deployment of a new
   generation of exensible agents (such as W3C's Jigsaw server and libWWW
   reference library).

Now, I also see some problems with PEP:

- Dynamic service extension is still somewhat of a research problem.
I don't know how much of this research problem has already been solved
behind the w3c member-only firewall.  I don't think this WG will want
to commit itself to solving huge research problems in the PEP area,
but it may want to commit itself to making the tradeoffs left when the
research problems are solved.

- The vision of intelligently cooperating clouds of
objects/components/applets/agents adding huge value to the internet
experience has been around for some time.  I have so far not been able
to determine how much of this vision the W3C wants to enable with PEP.
PEP will probably not be able to live up completely to this vision,
but how close do we want to get instead?  Should PEP just be a simple
header collision avoidance protocol, or should it define a powerful
framework for intelligent cooperation?

- PEP is not the only mechanism claiming to allow for the smooth
addition of services.  Java is another one.  (I know too little about
plugins to determine if they too claim something here.)  If some
powerful vendor starts trying to set ad-hoc standards in this area to
get a competitive advantage, PEP may go the way of HTML 3.0.

[...]
> selection of multiple variants of a resource (by 
>allowing the client, rather than the server, to make the selection),  

PEP negotiates on _services_.  Negotiation on _content_ is orthogonal
to PEP, and this WG is already working on a content negotiation
mechanism with the attributes you mention above.

>Keith

Koen.

Received on Sunday, 20 October 1996 06:43:39 UTC