edited by Rohit Khare
Preface: this is, even now, a very early document. I expect substantial editing of form and examples. So far, the document is only sufficient for explaining and debating the principles behind the PEP spec.
This specification lays out a plan for extending HTTP to support new web-based messaging protocols. With a clear extension mechanism in place, HTTP will be able to support new kinds of content processing and richer negotiation. In a nutshell:
The Protocol: header indicates that an HTTP agent is acting in accordance with the named protocol in constructing the message, and the receiver (according to the strength and scope of the header), is bound to follow the same protocol, or abort.
This extension system envisions a correspondingly modular software architecture, where specific features (such as synchronous tunneling or digital-signature verification) are implemented by features in the HTTP agent that are invoked directly from the parameters passed within a message compliant with a given protocol.
This system has been motivated by the need to support a multitude of proposed HTTP features in a systematic fashion. The current practice is for a new feature to use a corresponding new header in the HTTP message (as with ``keep-alive'' and Connection:). With the Protocol Extension Protocol, HTTP agents will be able to reuse a standard facility for negotiating which features are available and for encoding the parameters and scope of any protocols that are employed.
Scenario planning indicated the following requirements:
A "legally binding" upgrade to the HTTP specification (HTTP/1.2) will ensure that "required" and "refused" mechanisms are obeyed by all parties.
There are several key definitions we will be using to specify the semantics: protocol-type, protocol-spec, negotiable-block, scope, and strength [See Glossary].
To completely specify how a protocol has been employed in a given message, we need to specify:
We will separate the specification of an instance of an applied protocol-type from the ordering by collecting the ordering information in a header that specifies the exact order, indicating which protocols produce output that has been ignored and which are strictly ordered.
To completely specify how a protocol can been employed in future interactions:
There are several syntactic elements PEP adds to HTTP/1.2:
HTTP 1.2 will include a new method for working with protocol extensions. In particular, the need for WRAPPED is highlighted by the need to encrypt GET requests.
Alternative definition (stricter): WRAPPED takes an entity-body of type application/http. After any protocol-extension processing (``unwrapping''), the wrapped HTTP message is presented to the server in place of the original request.
ASIDE: Without ``unwrapping'', how can a particular HTTP server realize that it is the origin server? Should * become a hostname?
This is the mechanism for specifying precisely what protocols a particular message was prepared in compliance with. This requires a syntax for specifying each particular protocol and a sequencing syntax, for which we propose Protocol: and Content-Encoding:, respectively.
Protocol = "Protocol" ":" word <AVTree>
<AVTree> = *(token ['=' [word ¦ '{' <AVTree> '}']])
Content-Encoding = "Content-Encoding" ":" *(token [','])
Protocol: protocol-type scope=__ str=__ id=__ headers={} parameters={}
These are some of the required entries at the top-level of the AVTree structure in Protocol:.
ASIDE: There is an open question about scope, uniqueness, and longevity of ids: can they be unique in a message, a session, or even predefined in the specs?
ASIDE: Problem: field-name is defined in section 4.2 as any character except CTLs or SP, which is not compatible with token, from section 2.2. Is there some reason name-value pairs must begin with token instead of word?
Multiple Protocol: lines can be concatenated by ',', per RFC 822.
ASIDE: Did we forget to say something about C-E? only one occurrence of each id allowed.
This is the mechanism for specifying what protocols a particular HTTP agent supports for processing requests and replies. In each direction, an agent can identify a protocol and its degree of preference (optional, required, or refused). Counterparties within scope are bound to take note of refused and required protocols in preparing subsequent communications (replies, or follow-up requests)
Accept-Protocol = "Accept-Protocol" ":" word <AVTree>
<AVTree> = *(token ['=' [word ¦ '{' <AVTree> '}']])
Protocol-Compatible= "Protocol-Compatible" ":" '{' word word ("rx" ¦ "tx") '}'
ASIDE: [If there were some sort of token= that should be used, P-C'd be an AVTree. rx= and tx= aren't , and words can't be LHSes]
Accept-Protocol:
header required parameters
Accept-Protocol: protocol-type scope=__ rx-str=__ tx-str=__ negotiable={}
These are some of the required entries at the top-level of the AVTree structure in Accept-Protocol:.
An Agent can assert, that to the best of its knowledge, protocol A is substitutable for protocol B in a particular direction by asserting Protocol-Compatibility: {A B (rx ¦ tx)}. This statement can also be used to justify why an Agent has decided to satisfy an obligation for B with an instance of A.
As described in the Implementation section, there are several new error types associated with PEP.
451 Extension Protocol Unknown
452 Extension Refused
453 Bad Extension Protocol Parameters
551 Extension Protocol Not Available (à la None Acceptable)
552 Extension Protocol Parameters Not Acceptable
The actual binding between syntax and semantics is presented through the interpretation and implementation rules in this section.
To strip a Protocol: or Accept-Protocol: header, an agent must remove the particular instance and any HTTP message headers listed in the headers field.
When parsing a Protocol: or Accept-Protocol: line in an HTTP request:
When evaluating a Content-Encoding: line in an HTTP reply or request:
When evaluating a Protocol: line in an HTTP reply or request:
When relaying an HTTP message (e.g. as a proxy):
Negotiation using PEP is considerably richer than with the other Accept: mechanism in HTTP/1.x.
Each message that is exchanged between two HTTP agents is part of a negotiation context. When an Accept-Protocol: header is parsed, the corresponding fact is added to that context. It may not be clear at parse-time, though, that there are conflicting or insufficient negotiation goals in the context, and the contradiction (overlapping key-length reject & accept ranges, e.g.) may only appear when the module is executed (453 vs 552).
ASIDE: After checking in on the plans for HTTP/1.1+ proxy syntax, we will have problems pinning down ``negotiation context'' until such time as HTTP/1.x supports voluntary, client-generated session-IDs. It is currently impossible to disambiguate the Accept-Protocol: requests of an AOL proxy from the policy decisions of a particular end-user going through AOL, for example.
Until there is reliable session identification, facts are kept in the context only for up to one previous transaction, so it is still possible to issue changed negotiation parameters, and so on.
This is the least-specified part of the PEP proposal, since many aspects of negotiation have been pushed out into specific protocol-specs. Nevertheless, there are going to be common mechanisms for well-known negotiable properties. Numeric ranges can be checked and flagged, as can multivalue sets.
There is one other kind of state-maintenance that may emerge as a client-side issue: realm contexts (security domains). It will be essential for an authentication module to retrieve a key and then say ``apply my protocol to any requests in domain X''. In the existing Spyglass proposal, the answer is polling on each request, which may become cumbersome.
To ``interpret a message compliant with a given protocol'' will often mean reprocessing a message (decipher, signature-check, etc), and the processing routine will essentially set up a pipe, according to the Content-Encoding: line. First, remove any ids that are out of scope, or are optional and skipped. Then setup a pipeline with the original message being copied into each module until a ','; the module before the comma produces the output that subsequent stages expect to see.
There may be a preprocessing stage as a compatibility layer. If a set of security protocols can define encryption, signature, and compression operations, a parser can be written that accepts PKCS-7 messages from an SHTTP message and produces an HTTP message with an equivalent pipeline.
A few remarks about the execution environment of a module: A protocol spec defines a message and an (invertible) function on that message. It says nothing about the corresponding software architecture, which may be operating on preparsed data structures, may or may not have access to keyrings and network interfaces, and so on. There is, however, a clear bias to inband transmission of information. Since processing yields a new output message and control signals, it is most flexible to pass information between independent modules in the message than through platform- and protocol-specfic control signals.
We have scenarios for content-labeling negotiation using PICS. We have a prototype library of protocol specs for security applications. There will be an entire, separate document about these samples and negotiation practices.
We started with input from several sources:
Key Contributors:
Addressing secure transactions smaller than an HTTP transaction. HTML support. Boolean combination vs. inheritance-by-aggregation. Highlight rationale for symmetric protocol, not server-only.
pro*to*col \'pro¯t-e-,ko—l, -,ko¯l, -,ka¨l, -kel\ n
2a: a preliminary memorandum often formulated and signed by diplomatic negotiators as a basis for a final convention or treaty