The PEP Model

This section is a description of the model behind PEP. It is not an actual specification of the PEP protocol but intended as an overview of how PEP is designed and how this model maps onto HTTP. Other mappings are possible which potentially can integrate PEP into other HTTP-like protocols.

Meta Information and Transaction Information

In the PEP model, there are two distinct types of information: meta information and transaction information:

Meta information

Meta information is information about a resource. In our case, meta information is information about resources identified by URIs. Meta information is often quasi stationary and for periods of time can be considered constant and hence cachable by proxy caches. Meta information can be shared between resources and any party with access to a chunk of the URI space can provide meta information about any other resource. Meta information can never affect the outcome of an HTTP transaction.

Transaction information

Transaction information is information about parties exchanging information and the exchange itself. Transaction information is valid for zero, one, or more transactions depending on whether it has state or not. In HTTP, transaction information is only valid for a single transaction and can in general not be considered cachable or be shared between resources. Only the parties involved in the transaction can generate transaction information. Unavailable or unacceptable transaction information can cause the transaction to fail and an error to be generated.

At an abstract level, PEP can be thought of as a virtual protocol with a specific mapping onto HTTP/1.1. The rest of this section describes how this mapping provides a sufficiently powerful framework to fulfill the requirements mentioned in the introduction.

Extending HTTP

The HTTP mapping of PEP uses RFC822 derived headers for encoding both meta information and transaction information. PEP separates meta information from transaction information by using two different types of headers:

PEP-Info

Meta information is expressed using the PEP-Info header. PEP-Info header information can be parsed as part of any HTTP message - clients can send meta information along with a request and servers can pass information along with a response. By itself meta information can not affect the outcome of the transaction.

PEP

HTTP transaction information is expressed using the PEP header. In order to have a complete transaction, PEP headers must be initialized by the client and responded to by the server. This is the only way both parties explicitly in the protocol can know the willingness of the other party to accept the transaction or not. Transaction information can potentially be verified by mechanisms outside PEP. An example is an encrypted document which can only be decrypted is the client gets the public key from the server. However, to PEP, this information is to be considered meta information about the resource and not transaction information for that particular transaction. It merely informs the client where it can get the key to decrypt the document.

The summary of this is that

• Clients only can generate PEP headers
• Both clients and servers can generate PEP-Info headers

The PEP Extension Space

PEP is designed to support dynamic extensibility of HTTP methods, headers, and status codes. Before describing in detail how PEP does this, it is constructive to have a look at how methods, headers, and status codes behave in HTTP:

Methods

The method token in an HTTP request indicates the method to be performed on the resource identified by the Request-URI. Methods need a priori agreement of semantics and can not be extended dynamically. If an HTTP server does not know a method, it must report an error message, see [RFC2068] section 5.1.1. A limitation of the method space is that a request can only contain a single method. Hence, it is not possible to support multiple, simultaneous extensions unless having a multiplicity of methods.

Status Codes

The status code element is a 3-digit integer result code of the attempt to understand and satisfy the request. Status codes are like method tokens in that there can only be a single status code in a response. However, status codes are somewhat easier to extend, as unknown status codes must be treated as the x00 code of that class, see [RFC2068] section 6.1.1. For example, a new status code, 223 (My New Code) would default to 200 (OK).

Headers

Header fields can be used to pass information about any of the parties involved in the transaction, the transaction itself, or the resource identified by the Request-URI. The advantage of headers is that the header space is relatively open compared to that of methods and status codes. New headers can be introduced and must be ignored if the recipient does not recognize the header without affecting the outcome of the transaction, see [RFC2068] section 7.1

As a result of this, PEP is designed to use the header space for describing extensions and not directly use HTTP methods or the status codes. Instead, PEP introduces a placeholder in the method space and status code space respectively guaranteeing that all interactions with existing HTTP applications perform according to the PEP specification. The two placeholders are:

• a special PEP method and a PEP method prefix which indicates that a request contains one or more PEP extensions which must be adhered to or the transaction aborted, see section "Binding HTTP Requests";
• a special status code 420 (Bad Extensions) which indicates that the policy for accessing the resource was not met and that further information can be found in the request for diagnosing the problem, see section "420 Bad Extensions".

These two placeholders allow for multiple PEP extensions to be deployed simultaneously without overloading the method space or the status code space.

Interacting With Other HTTP Headers

Transaction information introduced by the PEP header may contain parameters which interact with existing HTTP headers, for example the connection header or the Cache-Control header. PEP supports this by defining a map attribute for the PEP header, which defines a header mapping valid for that HTTP message only. The mapping binds a parameter defined by a PEP extension with an arbitrary HTTP header which can then be used in the cache-control header, for example. The recipient of the mapping can always do a reverse lookup on the mapping determining the semantics of the header.

HTTP messages unfortunately mixes up meta information and transaction information. As an example, all content-* headers are in principle indistinguishable from a transaction header, say the Server header. Also, meta information may interact with existing HTTP headers like the vary header describing alternative representations of the resource to a cache. Meta information may also interact different with a cache than with a user agent. Therefore, the map attribute can also be used in the PEP-Info header allowing PEP extensions to interact with the vary header and cache-control header.

The summary of this is that in order to allow both meta information and transaction information to interact with HTTP semantics, the map attribute is defined for both the PEP and the PEP-Info header.

Please check out the new PEP examples illustrating this.