This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This document is also available as a W3C Working Draft. The most recent release is available at http://www.w3.org/pub/WWW/TR/WD-http-pep.
Distribution of this document is unlimited. Please send comments to the HTTP working group at http-wg@cuckoo.hpl.hp.com. Discussions of the working group are archived at http://www.ics.uci.edu/pub/ietf/http/. The editor maintains background information about PEP at http://www.w3.org/pub/WWW/Protocols/PEP/
The contribution of World Wide Web Consortium staff time to the HTTP working group is part of the W3C HTTP Activity.
HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, from distributed authoring, collaboration and printing, to various remote procedure call mechanisms.
The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of HTTP clients and servers by software components. The PEP mechanism is to associate each extension with a URI, and use a few new header fields to carry the extension identifier and related information from HTTP clients, through proxies and intermediaries, to servers, and back again. The kind of extensions capable of being introduced by PEP are envisioned as ranging from:
PEP interacts with specific features of HTTP/1.1 [RFC2068] including scoping rules and cache semantics. PEP is intended to be compatible with HTTP/1.0 [RFC1945] inasmuch as HTTP/1.1 is compatible with HTTP/1.0, see [RFC2068], Section 19.7. It is proposed that the PEP extension mechanism is included in future versions of HTTP.
HTTP is a generic request-response protocol, designed to accommodate a variety of applications, from network information retrieval and searching to file transfer and repository access to query and forms processing.
The agents in an HTTP transaction are a client and a server, which send HTTP messages to each other, with intermediaries between them in some cases. However, semantically, an HTTP transaction is between a client party (for example, the referent of the From: header field) and a principal responsible for the publication of a given resource.
The publishing party is the one responsible for the service provided at any particular URI, for example, the mapping between the URI and any representation of the resource to which it refers. Exactly who takes this role is beyond the scope of this document, but for example, it may be the writer of a document, the server administrator, the organization running the server, or a combination of these.
HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, from distributed authoring, collaboration and printing, to various remote procedure call mechanisms. Many of these applications do not require agreement across the whole Internet about the extended facilities; rather, it suffices:
The need for extensibility creates a tension between dynamically extensible applications and public, static specification.
The Protocol Extension Protocol (PEP) is an extension mechanism for HTTP/1.1 designed to accommodate dynamic extensions of HTTP clients and servers by software components and to address the tension between private agreement and public specification. The kind of extension s capable of being introduced by PEP are envisioned as ranging from:
This document defines the HTTP extension mechanism referred to as "PEP". The PEP design is the result of analyzing a variety of HTTP extensions and extension mechanisms, and the motivation behind them.
PEP interacts with specific parts of HTTP/1.1 including scoping rules and cache semantics and is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0 (see section "Considerations for Defining Extensions"). It is proposed that the PEP extension mechanism is included in future versions of HTTP.
PEP allows applications to employ extensions dynamically by providing a mechanism for mapping the global definition of an extension to its local representation in a particular transaction. The local representation does not have to be globally unique and can be defined on the fly by the parties involved.
The mapping is furthermore assigned a strength and a scope describing the requirements for interacting with the extension. This allows an application to require that another party either obeys the rules given by the extension or aborts the transaction.
PEP is intended to be used as follows:
If the extension becomes ubiquitous, a new version of the HTTP specification can include the extension, and messages can declare use of the new HTTP version instead of the extension.
The PEP mechanism is designed to accommodate dynamic extension of clients, servers, and proxies by software components as follows:
The advantage of the self-describing data model used by PEP is that at the cost of some extra bytes to spell out the URI in full, the use of a central registry of extension names is avoided. PEP can also be used to extend applications to support centrally registered extensions as long as a URI is published as part of the registration. The representation and implementation of dynamic extensible software component interfaces is outside the scope of this specification (see section "Publishing an Extension (Section 11.1)").
This specification uses the same notational conventions and basic parsing constructs as RFC 2068 [RFC2068]. In particular the BFN constructs "token", "quoted-string", "URI", and "delta-seconds" in this document are to be interpreted as described in RFC 2068 [RFC2068].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
PEP does not rely on particular features defined in URLs that cannot potentially be expressed using URNs, see section "Publishing an Extension (Section 11.1)". Therefore, the more generic term "URI" is used throughout this specification.
The bag syntax uses braces to delimit an attribute-value bag, which may consist of a set, list, or recursively defined tokens and quoted strings. The bag semantics are defined by its context and the bag name, which may be a URI in some fields. The BNF for the bag syntax is as follows:
bag = "{" bagname *bagitem "}"
bagname = token
bagitem = bag |
token |
quoted-string |
<"> URI <">
Unless explicitly stated otherwise, all tokens within a bag are case-insensitive. Comments as defined by RFC 822 [RFC822] indicated by surrounding the comment text with parentheses MUST NOT be used within a bag construct.
Clients and proxies can initiate a new instance or terminate an existing instance of an extension by issuing an extension declaration as part of a request. The declaration can be intended for one or more other agents depending on the scope of the declaration, see section "End-to-End Extensions (Section 6.5)" and "Hop-by-Hop Extensions (Section 6.6)", and either may or must be accepted depending on the strength, see section "Strength (Section 6.4)". The grammar for an extension declaration is as follows:
ext-decl = "{" required-decl *optional-decl "}"
required-decl = ( map [ strength ] ) | unmap
optional-decl = parameters | attribute-ext
map = "{" "map" <"> absoluteURI <">
1#(header-wildcard) "}"
unmap = "{" "unmap" 1#(header-wildcard) "}"
strength = "{" "strength" ( "must" | "may" "}"
parameters = "{" "params" *bagitem "}"
attribute-ext = bag
header-wildcard = field-name [ wildcard ]
wildcard = "*"
In many ways, an extension declaration is equivalent to calling either the
constructor or destructor of the class representing the extension. The
map attribute is equivalent to the constructor and the
unmap attribute is equivalent to the destructor. Additional
information can be passed using either of the following three mechanisms:
parameters attribute, see section
"Extra Parameters" (Section 6.3);
header-wildcard) mapped by the map attribute,
see section "Header Field Mappings" (Section 6.1);
attribute-ext attribute.
Unrecognized extension declaration attributes (attribute-ext)
MUST be ignored; it is assumed that any unrecognized attributes will be combined
with standard attributes such that the application behavior will remain minimally
correct even if it does not understand the extension attribute(s). If neither
a map nor an unmap attribute is present in an extension
declaration, the server SHOULD respond with 400 (Bad Request).
The map attribute can be used to declare a new instance of an
extension. The map attribute defines a mapping between a resource describing
the syntax and semantics of the extension and a set of header fields representing
this instance of the extension. The resource is identified by a URI which
MAY be resolved dynamically by either of the parties using the extension,
see section "Bootstrapping and Dynamic Loading".
A header-wildcard can either be a single header field or a header
field prefix. A header field prefix is indicated using a terminating
wildcard and can be used to describe that all header fields
with this prefix are part of this instance of the extension. Linear white
space (LWS) MUST NOT be used between the field-name and the
wildcard (if any) and all header-wildcard values
are case-insensitive.
Clients SHOULD NOT overload well-known or widely deployed header fields with new semantics unless the new semantics are a superset of the existing semantics so that the header fields still can be interpreted according to the old semantics. Clients MUST not reuse already mapped header fields in new extension declarations. If the server finds that a header field is already mapped by another extension instance initiated by the same client, it MUST respond with a 421 (Bad Mapping) status code.
Proxies initiating new extension instances MUST make sure that the header
fields introduced by the map attribute does not conflict with
header fields already mapped by user-agents or previous proxies taking part
in a proxy chain.
When a mapping has been declared, the mapped header fields can be used to convey information according to the syntax and semantics of the extension described by the URI. A mapping can be valid for zero, one, or more transactions depending on the extension and the agreement between the involved parties. Specifically, a mapping is valid until one of the following events occur:
unmap attribute, or
This rule allows PEP aware applications to maintain long-lived mappings without relying on global, persistent state, see section "PEP - an Extension Mechanism for HTTP (Section 11.3)". At the cost of one additional transaction, PEP aware applications can always jump to a single well-known state describing which extension instances are currently mapped, see section "Binding Requests" for how this rule interacts with existing HTTP applications.
The unmap attribute can be used to indicate that the mapping
between a URI and one or more header-wildcards has terminated
and the semantics described by the URI no longer are valid for these header
fields. Unmapped header fields SHOULD be treated as unknown headers and ignored
by the recipient and forwarded by proxies. Applications MAY reuse unmapped
header fields in future mappings if they have been redeclared using the
map attribute.
There does not have to be a 1:1 relationship between a set of header fields
used by the map attribute and the set used by the
unmap attribute. This allows the unmap attribute
to unmap subparts of an extension instance or potentially multiple extension
instances. A client SHOULD only attempt to unmap header fields that it has
initiated itself. Unmapping extension instances initiated by others may cause
an extra transaction to happen in order to reach a shared state.
A server MUST always accept a client's request for unmapping a set of header fields. If a client in a request unmaps header fields in use by extensions required for accessing that resource, the server MUST respond with 420 (Bad Extensions).
The parameters attribute can be used to pass additional parameters
to the construction or destruction of the extension instance. The
params values may or may not be case-sensitive, depending on
the semantics of the parameter name. No default parameters are defined.
Note: Server implementations should pass any extra parameters to the module or modules handling a particular extension as this may have significant impact on the success of the transaction.
The strength attribute can be used to specify how the ultimate
recipient MUST handle the extension instance declared using the
map attribute. The strength indicates whether this instance
is required (must) or optional (may) for the
transaction to succeed. If the strength is "must", the ultimate
recipient of the extension declaration MUST consult and adhere to the relevant
extension specification(s) before executing the transaction or respond with
420 (Bad Extensions), see section "Binding
Requests" for how to interact with existing HTTP applications.
Not accepting an extension instance is different from not accepting a mapping
proposed by the map attribute. If the server cannot accept a
mapping, for example if a header field is already mapped by another extension
instance, it MUST respond with a 421 (Bad Mapping) status code, see section
"421 Bad Mapping (Section 9.2)".
If the strength is "may" the ultimate recipient of the extension
MAY consult and adhere to the relevant extension specification(s) before
executing the transaction or ignore the extension completely. If no strength
attribute is present, the default strength is "may". A client
cannot distinguish whether a server does not understand an extension or does
not want to initiate an extension instance of strength "may".
For the purpose of defining the behavior of caches and non-caching proxies, PEP extensions are divided into two categories: End-to-end extensions and hop-by-hop extensions. The PEP header is an end-to-end request-header and is defined as follows:
pep = "PEP" ":" 1#ext-decl
For example
GET / HTTP/1.1
Host: some.host
PEP: {{map "http://www.w3.org/ext/end-to-end" Ext-1}
{params x y z}}
End-to-end extensions MUST be transmitted to the ultimate recipient of a request, see section "Proxy Servers as End to End Recipients".
If multiple end-to-end extensions have been declared for a transaction, the extensions MUST be listed in the order in which they were applied.
Hop-by-hop extensions are meaningful only for a single transport-level
connection. The C-PEP header allows the sender to specify hop-by-hop
extensions and MUST NOT be communicated by proxies over further connections.
The C-PEP header has the following grammar:
c-pep = "C-PEP" ":" 1#ext-decl
The C-PEP header uses the Connection header so
that existing HTTP/1.1 applications can filter the information out appropriately.
For example
GET / HTTP/1.1
Host: some.host
Ext-1: bar
C-PEP: {{map "http://www.w3.org/ext/my-extension" Ext-1}
{params x y z}}
Connection: C-PEP, Ext-1
If multiple hop-by-hop extensions been declared for a transaction, the extensions
MUST be listed in the order in which they were applied. C-PEP
extensions MUST be executed before any end-to-end extensions.
The C-PEP header MUST always be protected by a
Connection header in a request by including C-PEP
as a Connection header directive. The directive MUST be handled
according to the HTTP/1.1 specification of the Connection header.
A client MUST NOT send the C-PEP header field to an HTTP/1.0
proxy as it does not obey the rules of HTTP/1.1 for parsing the
Connection header field, see also [RFC2068], section 19.7.1.
If any extension in an HTTP request is of strength "must", the
transaction MUST NOT succeed without consulting and adhering to the relevant
extension specification(s). We call such a request for "binding". In
[RFC2068], Section 7.1 it is stated that "Unrecognized
header fields SHOULD be ignored by the recipient and forwarded by proxies."
Hence, using a PEP or a C-PEP extension declaration
is not sufficient to evoke the correct behavior from existing HTTP agents.
However, in [RFC2068], Section 5.1.1, Method, it is indicated that "Servers SHOULD return the status code 405 (Method Not Allowed) if the method is known by the server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server." A similar statement is made in [RFC1945], Section 9.5. Therefore, PEP uses the request method to provide a binding mechanism for handling a binding HTTP request.
The method name of all HTTP requests containing a PEP extension of strength
"must" MUST be prefixed by "PEP-". The
"PEP-" prefix is reserved by PEP and MUST NOT be used by other
HTTP extensions. PEP-aware applications MUST prior to processing a binding
HTTP request remove the "PEP-" prefix from the method name leaving
the rest of the HTTP request as is.
For example, a client might express the binding rights-management constraints in an HTTP request as follows:
PEP-PUT /a-resource HTTP/1.1
PEP: {{map "http://some.org/rights-management" my-rights-*}
{strength must}
{params {copyright-remains-with-client}
{nonexclusive-right-to-redistribute}}
Host: some.host
Content-Length: 1203
Content-Type: text/html
<!doctype html ...
Servers can announce the policy for zero, one or more resources by issuing a policy declaration. A policy declaration is a piece of metainformation expressing which extensions SHOULD be deployed when accessing zero, one, or more resources. Extension policy information differs from extension declarations in that the former is metainformation about a set of resources whereas the latter is transaction information for a particular transaction. There is no guarantee that the policy information provided is neither adequate nor sufficient for accessing the resource(s). A policy declaration is defined as follows:
policy-decl = "{" required-policy *optional-policy "}"
required-policy = id
optional-policy = for | strength | max-age |
parameters | attribute-ext
id = "{" "id" <"> absoluteURI <"> "}"
for = "{" "for" #URI-wildcard "}"
max-age = "{" "max-age" delta-seconds "}"
URI-wildcard = <"> URI <"> [ wildcard ]
The id attribute specifies the URI identifying the extension.
The URI MAY be resolved dynamically by either of the parties using the extension
(see section "Bootstrapping and Dynamic Loading").
The id attribute differs from the map attribute
in that no header fields are associated with the URI. If no id
attribute is present in an extension policy, the client SHOULD ignore it.
The for attribute specifies the URI (or set of URIs) to which the
policy declaration applies. A URI followed by a wildcard represents the set
of URIs that contains the given URI as a prefix. A linear white space (LWS)
MUST be used between the URI and the wildcard (if any). In case
a for attribute does not appear, the default value is the Request-URI
of the transaction. An empty for value indicates that the extension
is not used by any resource. Policy declarations are unordered and can contain
information about any number of resources.
Servers MAY specify an explicit expiration time for a policy declaration
using the max-age attribute. The max-age attribute
indicates that the information SHOULD no longer be used if the age is greater
than the specified time in seconds, see HTTP/1.1, Section 13.2.3 for how
to calculate the age. An expiration time cannot be used to force a client
to discard the information or reload a resource; its semantics apply only
to caching of policy information.
If the URI is a relative URI, the URI is interpreted relative to any Content-Base URI provided in the response. If no Content-Base is provided, the relative URI is interpreted relative to the Request-URI. Examples of URI-wildcards are
{for "http://www.w3.org" *}
{for "http://www.w3.org/pub/" *}
{for "secret/Overview.html"}
Unrecognized extension policy attributes MUST be ignored; it is assumed that any unrecognized attributes will be combined with standard attributes such that the application behavior will remain minimally correct even if it does not understand the attribute(s).
As for extension declarations, extension policies are divided into two categories: End-to-end policies and hop-by-hop policies. The PEP-Info header expresses the end-to-end policies and is defined as follows:
pep-info = "PEP-Info" ":" 1#policy-decl
For example
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 250
PEP-Info: {{id "http://some.org/payment-extension"}
{for "/cgi-bin/buy" *}
{strength must}}
<form action="/cgi-bin/buy">
...
End-to-end policies MUST be transmitted to the ultimate recipient of a response, see section "Proxy Servers as End to End Recipients".
Hop-by-hop policies are meaningful only for a single transport-level connection.
The C-PEP-Info header allows the sender to specify hop-by-hop
policies and MUST NOT be communicated by proxies over further connections.
The C-PEP-Info header has the following grammar:
c-pep-info = "C-PEP-Info" ":" 1#policy-decl
For example
HTTP/1.1 420 Bad Extensions
C-PEP-Info: {{id "http://some.org/provide-stats"}
{for "/" *}}
Connection: C-PEP-Info
...
The C-PEP-Info header MUST always be protected by a
Connection header in a response by including
C-PEP-Info as a Connection header directive. The
directive MUST be handled according to the HTTP/1.1 specification of the
Connection header.
A server MUST NOT send the C-PEP-Info header field to an HTTP/1.0
proxy as it does not obey the rules of HTTP/1.1 for parsing the
Connection header field, see also
[RFC2068], section 19.7.1.
PEP adds two new status codes to be added to the set already defined by HTTP/1.1 [RFC2068]. Each Status-Code is described below, including a description the metainformation required in the response.
The policy for accessing the resource has not been met in the request. The
response MUST include a PEP-Info header field specifying the
extensions required by the publishing party for accessing the resource. The
server MAY also include policy information for other resources using the
for attribute and optional extensions specified having a strength
of "may". The client MAY repeat the request using the appropriate
extension(s) if it believes that it can fulfill the policy.
If the initial request already included all the extensions requested in the 420 response with the appropriate set of extra parameters (if any), then the 420 response indicates that access has been refused for any additional extension(s) requested by the client. If no extension(s) have been requested by the client, then the user MAY be presented the entity that was given in the response (if any), since that entity may include relevant diagnostic information.
Implementers may note the similarity to the way authentication challenges are issued with the 401 (Unauthorized) status code.
The mappings indicated by the map attribute in the request were
refused. If the initial request contained a change to the current set of
mappings using the "map" attribute then this change was refused
but other mappings are still valid. The client MAY repeat the request using
a new set of header fields if it believes that it can find a unique set of
header fields for the mapping to succeed. If the initial request did not
indicate any changes to the current set of mappings, then all mappings currently
held by the client MUST be discarded.
Normally, the ultimate recipients of an end-to-end extension declaration and extension policies are the origin server and the user agent participating in the extension. In some cases, however, intermediate caching and non-caching proxies MAY act authoritatively on behalf of user agents and origin servers. Note, that regardless of the role of the proxy, it MUST always obey the cache directives indicated by the cache-control directive, see also section "Interaction with Existing HTTP/1.1 Headers (Section 11.2)".
In case a proxy is authorized to act as the ultimate recipient on behalf of its proxy clients on end-to-end extensions, it MUST obey the following rules:
must" it MUST prepend the "PEP-" method name prefix,
before forwarding the response to the origin server, see section
"Binding Requests".
This can for example be the case if an elementary school wishes to enforce a certain policy for accessing information on the Internet. The local school proxy can then act authoritatively on behalf of the pupils using the proxy.
In case a proxy is authorized to act as the ultimate recipient on behalf of an origin server on end-to-end extensions, it MUST obey the following rules:
must" and there are no other extensions of strength
"must" in the request, it MUST remove any "PEP-"
method name prefix before forwarding the request to the origin server, see
section "Binding Requests".
An example of this is a corporation having a subscription on an on-line journal. All access to the origin server goes through the corporate firewall that runs a caching proxy server. The organization reports to the publisher of the journal on a monthly basis at which point the subscription is re-evaluated. In the day-to-day access, the proxy has the authority to act on behalf of the origin server registering usage of the journal.
While the protocol extension definition should be published at the address of the extension identifier, this is not a requirement of the PEP protocol. The only absolute requirement is that distinct names be used for distinct semantics.
For example, one way to achieve this is to use a mid, cid, or uuid URI. The association between the extension identifier and the specification might be made by distributing a specification, which references the extension identifier. Care should be taken not to distribute conflicting specifications that reference the same name.
Even when a URI is used to publish extension specifications, care must be taken that the specification made available at that address does not change significantly over time. One agent may associate the identifier with the old semantics, and another might associate it with the new semantics.
The extension definition may be made available in different representations. For example, a software component that implements the specification may reside at the same address as a human-readable specification (distinguished by content negotiation). The human-readable representation serves to document the extension and encourage deployment, while the software component allows clients and servers to be dynamically extended.
Designers of extensions to be used within the HTTP messaging model should consider the interaction with existing HTTP/1.1 headers. Especially, it should be noted that PEP is designed to be compatible with HTTP/1.0 [RFC1945] inasmuch as HTTP/1.1 is compatible with HTTP/1.0, see [RFC2068], Section 19.7. There are two specific categories of HTTP/1.1 headers that are of special importance to PEP extensions: The HTTP/1.1 caching headers and headers used by existing extension mechanisms provided by HTTP/1.1. This section discusses some of the issues regarding these two categories.
The Cache-Control header as described in
[RFC2068], Section 14.9, allows a client or server
to transmit a variety of directives in either requests or responses with
the purpose of overriding the default caching algorithms performed by HTTP/1.1
caches. Regardless of whether any PEP headers are used as cache-control
directives, PEP-aware proxies MUST always obey the cache-control directives.
The Vary header, described in [RFC2068],
Section 14.43, is used by a server to signal that the response entity was
selected from the available representations of the response using server-driven
negotiation. If either a PEP extension or any header fields used by an extension
instance is taking part in a server-driven negotiation, then the server MUST
include an appropriate Vary header field with any cachable response
that is subject to server-driven negotiation.
The Connection header as described in
[RFC2068], Section 14.10, allows the sender to specify
options that are desired for that particular transport connection only. All
PEP hop-by-hop extension and policy declarations along with any header fields
used by hop-by-hop extension instances MUST be included as
Connection header directives. PEP applications MUST NOT send
any hop-by-hop extension or policy declarations to an HTTP/1.0 proxy as it
does not obey the rules of HTTP/1.1 for parsing the Connection
header field, see also [RFC2068], section 19.7.1.
The Upgrade header, [RFC2068], Section
14.41, allows the client to specify what additional communication protocols
it supports and would like to use if the server finds it appropriate to switch
protocols. PEP supersedes the Upgrade header in that it allows
the same functionality but without the need for a central registry. PEP
extensions MAY use the 101 (Switching Protocols) status code to switch to
HTTP-based protocols and protocols, which once initiated by a PEP transaction,
run completely independently of HTTP.
The content coding values in the Content-Encoding header as
described in [RFC2068], Section 14.12, indicate an
encoding transformation that has been or can be applied to an entity. As
for the Upgrade header, PEP supersedes the
Content-Encoding header in that it allows the same functionality
but without the need for a central registry. As both the content encoding
mechanism and the PEP mechanism is ordered, using both MAY lead to ambiguous
situations. Simultaneous use of both mechanism is therefore strongly discouraged.
A mapping declared by the map attribute can be valid for zero,
one, or more transactions depending on the extension and the agreement between
the involved parties. In case a server wishes to maintain a mapping initiated
by a client for more than a single transaction, it must be able to link the
mapping to the client so that it can use the mapping in future requests initiated
by that client. In other words, the server must maintain some sort of state,
which uniquely links a mapping to the client initiating that mapping. This
requires that the server uniquely can identify a client over the span of
multiple, possibly unrelated transactions.
A server can identify a client initiating a mapping using one of the following mechanisms (in order of precedence):
If none of the above applies then the server MAY look for a From
header field in the request. This MUST NOT be considered a reliable mechanism
and explicit care SHOULD be taken by the server not to rely on this.
The PEP protocol is the product of a substantial amount of investigation and collaboration. Dave Kristol did some of the first writing on HTTP extension mechanisms. [Kristol95]. Jim Miller and Dave Raggett sketched out an initial design, which Rohit Khare wrote up in a number of drafts. Tim Berners-Lee, Paul Leach and Daniel Dardailler deserve special recognition for their efforts in commenting in the design phase of the protocol.
This specification is a direct reflection of some implementation work: a client implementation in Libwww (see the HTPEP module) and a server implementation by Eui-Suk Chung and Anit Chakraborty for the JEPI project.
This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already mentioned, the following individuals have contributed to this specification:
Dan
Connolly
Architecture Domain Lead, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1 (512) 310 2971
Email: connolly@w3.org
Rohit Khare
Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1 (617) 253 5884
Fax: +1 (617) 258 5999
Email: khare@w3.org
Henrik Frystyk
Nielsen
Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1 (617) 258 8143
Fax: +1 (617) 258 5999
Email: frystyk@w3.org
The following table summarizes the outcome of how PEP-aware servers and proxies
MUST handle PEP extension declarations. The table also summarized how existing
HTTP servers and proxies interact with PEP extension declarations. Note,
that applications MUST NOT send hop-by-hop header fields to an HTTP/1.0 proxy
as it does not obey the rules of HTTP/1.1 for parsing the
Connection header field, see also
[RFC2068], section 19.7.1. See also section
"Interaction with Existing HTTP/1.1 Headers (Section 11.2)".
| Hop-by-hop *) | End-to-end | ||||
|---|---|---|---|---|---|
| Optional (may) | Required (must) | Optional (may) | Required (must) | ||
| Proxy | PEP not supported | Strip |
501 (Not Implemented) |
Pass |
501 (Not Implemented) |
| Extension not supported | Strip |
420 (Bad Extensions) |
Pass |
Pass |
|
| Extension supported | Extended processing |
Extended processing |
Extended processing |
Extended processing |
|
| Origin Server | PEP not supported | Standard processing |
501 (Not Implemented) |
Standard processing |
501 (Not Implemented) |
| Extension not supported | Standard processing |
420 (Bad Extensions) |
Standard processing |
420 (Bad Extensions) |
|
| Extension supported | Extended processing |
extended processing |
Extended processing |
Extended processing |
|
*) Applications MUST NOT send hop-by-hop header fields
to an HTTP/1.0 proxy as it does not obey the rules of HTTP/1.1 for parsing
the Connection header field, see also
[RFC2068], section 19.7.1.
Some of the things we have to consider
If we take the limited case of having the server sending async notifications on an already established TCP connection then I believe that this is something that PEP needs to be able to support.
I will have to check that further - look at the JEPI requirements. I have done so and believe there are no problems!
How does this fit with TNC and how can we use a single proposal?
Note, that this proposal has removed the "strength refused" as I can't find an example where this has to be part of the basic extension mechanism. An extension may not be allowed because of some of the parameters but not the extension itself - this can be an issue with extensions using public keys, for example. Or a certain combination of extensions may not be allowed but not necessarily each of the individual extensions.
Another change is that the for list is now a linked list which make it possible to assign metainformation to large set of resources.
There is no reason to make the "enc" parameter/flag distinction in the Protocol header. After we removed the interaction with the content-encoding header, there is nowhere in the protocol message any encoding token may show up. It was only needed while we used the content-encoding header for ordering purposes. The protocol id defines the encoding.
It would be nice if we could use some generic meta data mechanism for handling this instead of the PI header.
Roy mentioned whether it make sense to have an extension bound not only to a particular URL but also to a particular method. It could be that an extension only is valid for PUT, say, and not GET. I think that we can push this of into the extension itself and don't have to be concerned about it in PEP directly.
Should a proxy acting on behalf of either an origin server or a user agent issue a warning header?