PEP Battle Plan [rexmit, garbled]

PEP Battle Plan

The PEP extension strategy has been on the shelf for a while now. I have
been working in this space for a year now, and like a killer mountain, I
have learned to respect this problem. It is easy to fall down ratholes, or
to ascend along the wrong path. Only two months ago did I learn this
fundamental lesson about the PEP drafts that have passed so far:

	Extension and Negotiation are separate problems.

There has been a lot of resistance to PEP because even if it was well
specified on paper, the operational model has never been clear because
these two problems were intertwingled – lots of black boxes that said "and
the HTTP agent will satisfice all of the counterparty's requests".

Historically, we at W3C have been pushing a PEP-like strategy since our
inception. Many of the problems we/I tackled were inherently
negotiation-centric: the SHTTP-like Security Extension Architecture, the
JEPI payments negotiation project, the PICS label request protocol… so for
us, to make HTTP extension natural for legions of 4th party developers, it
is absolutely critical to build upon both of these concepts. On the other
hand, it is clear that to the smaller community of HTTP designers,
correctness, compactness, and simplicity are more important. The complexity
of selecting an extension, initiating it, and coordinating it with other
extensions is like toothpaste in a tube: it can be squeezed back and forth
from the HTTP agent to the plug-in extension.

The August PEP draft was designed to be the bedrock of the JEPI project: on
the basis of that draft, the JEPI project is going forward, leaving change
control now firmly in the hands of this IETF HTTP-WG as long as it wishes
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 Saturday, 19 October 1996 09:53:00 UTC