PEP Battle Plan

to move PEP forward on standards-track. 

There are several changes I have discussed privately with PEP reviewers
from several organizations. Many of them are presented herein. Other novel
questions have only been sketched out, and will require vigorous debate
here: how does PEP interact with caching? How can PEP be used to implement
other proposed features?
Proposed PEP changes
I will soon forward a revised drafting of PEP that simplifies the spec into
two components: an Extension Protocol and an Extension Negotiation Protocol
that builds on top of EP. 

EP has two components:
Protocol: indicates that this message has been extended
Protocol-Info: advertises that an extension is available for future use at
this extension
We hope to separately motivate Protocol-Request and Protocol-Query
machinery as an extension upon that base which says when to begin using an
extension, why, and what compatible extensions may be substituted. ENP,
tentatively, is a separate add-on draft that we at W3C, through long
experience with PEP application scenarios believe is required, but can be
safely split from the mandatory core HTTP requires.

We also hope to demonstrate that EP can be deployed without a version
number upgrade and perhaps without a new method, either – using Connection:
and Cache-Control:. It will cost one round-trip to be absolutely sure your
counterparty supports PEP. 

Other changes to the PEP draft include:
id # tagging of each Protocol-* directive. The id# allows us to 1) claim
all headers beginning with that id #, 2) use in Content-Encoding for
pipeline order, 3) pairing up related directives across request-response
pairs
modifying the *-matching rule for the URIs in a for list (essentially, *
anywhere in a URI)
use of headers to pass all extension-specific data (less religion about
bags)
Better explanation of error reporting
… and more
Of course, I need to forward the revised draft before any detailed
discussion can begin.

Progress on an extension mechanism is essential because it is the future of
1.x and binary encodings of it. Most of what we are discussing for 1.2 can
be accommodated over PEP. W3C has been gaining experience in a number of
domains which leverage such a facility. Experience gained today will port
over to more efficient encodings of 1.x. Caching and backwards
compatibility problems  can  be solved. 

That's the battle plan from this end.
Next Steps
create a PEP home page in the W3C Protocols area
submit new draft – by midweek
track libWWW5 implementation
investigate technical writing support for white papers, implementation
guides, perhaps the spec itself

Received on Friday, 18 October 1996 21:01:06 UTC