Network Working Group D. Connolly
Internet Draft W3 Consortium
Category: Informational January 1997
Expire in six months
PEP: an Extension Mechanism for HTTP
1. Status of this Document
This document is [not yet] 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).
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/.
This document is also available as W3 Consortium Working Draft WD-
http-pep-970131. The most up-to-date current version is available at
http://www.w3.org/pub/WWW/TR/WD-http-pep.
The contribution of W3C staff time to the HTTP workin group is part
of the W3C HTTP Activity.
Connolly Internet Draft [Page 1]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
Abstract
HTTP is an extensible protocol. PEP is an extension mechanism
designed to address the tension between private agreement and public
specification and to accomodate extension of HTTP clients and servers
by software components.
The mechanism is to associate each extension with a URL, and use a
few new header fields to carry the extension identifier and related
information from HTTP clients, thru proxies and intermediaries, to
servers, and back again.
Contents
1. Status of this Document ........................................ 1
2. Introduction ................................................... 2
2.1. Requirements .............................................. 3
3. Extension Identifiers .......................................... 4
3.1. The Protocol Header Field ................................. 5
4. Notification ................................................... 6
4.1. 420: Bad Extensions ....................................... 8
5. Extension Header Fields ........................................ 8
6. Extension Encodings ............................................ 9
7. Security Considerations ....................................... 10
9. Normative References .......................................... 11
10. Bibliography: Informative References ......................... 11
2. Introduction
This document presents PEP, and extension mechanism for HTTP. The
PEP design is the result of analyzing a variety of HTTP extensions
and extension mechanisms, and the motivation behind them. This is
discussed in requirements section (Section 2.1).
The section on extension identifiers discusses the mechanism itself,
which is to associate each extension with a URL, and use a new header
field, Protocol: to carry the extension identifier and related
information from HTTP clients, thru proxies and intermediaries, to
servers, and back again.
The next section, Notification, provides information providers with a
mechanism to inform clients of extension policies, that is, which
extensions should or should not be used to access resources.
The Extension Header Fields section addresses the use of new HTTP
headers in extensions.
After Security Considerations, and a Syntax Reference, appendices
discuss Considerations for Defining Extensions and the use of PEP in
and with software components.
Connolly Internet Draft [Page 2]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
2.1. Requirements
HTTP is being used for an increasing number of applications
involving distributed authoring, collaboration, printing, and
various RPC like protocols. Often these extensions are deployed
dynamically, extending existing applications. They motivate the
need to independently introduce extensions and new features to
HTTP in such a way that 1) They are orthogonal to other
extensions. 2) They can be deployed automatically and
dynamically.
This requires:
*
That conforming HTTP peers supporting a particular
protocol extension or
feature should be able to employ this in real time with
no prior agreement;
*
That it should be possible for one party having a
capability for a new protocol
to require that the the other party either understand
and abide by the new
protocol or abort the operation;
*
That the HTTP protocol should still be able to work
through proxies - especially
caching proxies;
*
That, either directly using PEP or using a new protocol
introduced using
PEP, negotiation of matching capabilities should be
possible, as required
for the JEPI project and similar applications.
This form for extensibility is not supported by HTTP/1.1. PEP is a
framework to satisfy these requirements.
The current design does not meet all the requirements. See Future Work for details.
Related Work
HTTP is an extensible protocol; applications have exploited its
extensibility along a number of degrees of freedom:
URL path
The URL path allows different functionality in different parts
of the URL space[URL]. This has been exploited in [CGI], and
HTML forms [HTML2.0] for example. Since then,
it has been combined with software component technology (such
Connolly Internet Draft [Page 3]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
as shared libraries, DLLs, etc.) for use in [NSAPI], [ISAPI],
[Apache], [OM], [Spy95].
media type
The request and response payload data is typed; new internet
media types can be introduced. A host of web extensions are
based on the extenion of user agents to handle internet media
types [MAILCAP].
method names
New method names can be added. (@@Cite BROWSE, MKDIR in
aolserver)
header fields
New headers may be introduced: entity headers, request headers,
or response headers. For example, [STATE]
Using the media type and/or URL to extend the web is an extension
within, rather than beyond, the HTTP protocol. On the other hand,
using new request header fields is a change to the HTTP protocol
itself ([HTTP] section 5.3 Request Header Fields).
3. Extension Identifiers
The agents in an HTTP transaction are a client and a server, which
send HTTP messages to each other However, semantically, an HTTP
trasacion is between a client party (for example, the referent of the
From: header field) and a the principle responsible for the
publication of a given resource.
The publishing party is basically the one responsible for the mapping
between the URI and any representation of the resource to which it
refers. Exactly who takes this role is out of the scope discusion of
this document; but for example, it may be the writer of a document or
the server administrator or the organization running the server.
The HTTP specification, which codifies the agreement between these
parties, is subject to thorough community review. While any extension
can be defined and used by private agreement, the web provides a
medium to deploy extensions to the global community without
centralized control.
PEP exploits this aspect of the web, and uses URLs to identify
extensions. This allows parties to learn about extensions and decide
which ones to participate in by dereferncing their URL. This learning
may be done by humans, or it may be done my machines aquiring
software components.
See Considerations for Defining Extensions for details.
Connolly Internet Draft [Page 4]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
3.1. The Protocol Header Field
Each protocol extension has an extension identifier, which is a
URL[URL]. The extensions used in a message are declared using the
Protocol request/response header field.
Along with the extension identifier, an extension may define any
number of parameters. See also, Extension Header Fields and
Extension Encodings.
The syntax is:
Protocol = "Protocol" ":" 1#extension-decl
extension-decl = "{" extension-id *ext-info "}"
ext-info = params | headers | enc
params = "{" "params" *bagitem "}"
headers = "{" "headers" 1*token "}"
enc = "{" "enc" 1*token "}"
bag = "{" bagname 1*LWS *bagitem "}"
bagname = token | URI
bagitem = bag | token | quoted-string
For example:
GET /a-document HTTP/1.1
Protocol: {http://some.org/an-extension}
HTTP/1.1 200 OK
Protocol: {http://some.org/an-extension}
Vary: Protocol
Content-Type: text/plain
Glad you're using an-extension!
Note the use of the Vary header to notify proxies that responses
to GET /a-document depend on the Protocol header fields used in
the request.
Hop-by-hop Extensions
Extensions declared with the Protocol header field are end-to-end
extensions, transparent to intermediaries. Hop-by-hop extensions
are declared with the C-Protocol header field, in conjunction with
the Connection header ([HTTP}, section @@).
The syntax is essentially the same as the Protocol header field.
C-Protocol = "C-Protocol" ":" 1#extension-decl
Connolly Internet Draft [Page 5]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
3.2. Considerations for Defining Extensions
While the protocol extension definition should be published at the
address of the extension identifier, this is not strictly
necessary. The only absolute requirement is that distinct names be
used for distinct semantics.
For example, one way to achive this is to use an mid:, cid:, or
uuid: URL. The association between the extension identifier and
the specification might be made by distributing a specification
which references the extension identifier. Care must be taken not
to distribute conflicting specifications which reference the same
name.
Even when the web 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.
Bootstrapping and Dynamic Loading
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 negotation).
The human-readable representation serves to document the extension
and encourage deployment, while the software component to allows
clients and servers to be dynamically extended.
Caching and Connections
For each aspect of an extension, the interaction with other
aspects of HTTP/1.1 must be fully specified, and the issues of
compatibility should be discussed. For example, any extension
headers which are not strictly entity headers require careful
consideration. See [HTTP] sections 13.5.1. (@@more references
were lost in an editing disaster)
4. Notification
Some extensions are used spontaneously by participating clients; for
example, a client may be configured to use and extension, or a user
interface option may trigger the use of an extension.
But in many cases, the origin server dictates the use of one or more
extensions. In this case, it is useful for the server to communicate
its policies to the client.
The server may notify the client that some resources should be
accessed using one or more extensions with the Protocol-Info header
Connolly Internet Draft [Page 6]
$Date: 1997/01/31 23:05:32 $ PEP January 1997
field. The resources are specified by a relative or absolute URI,
with an optional wildcard flag indicating that the notification
applies to all URIs containing the specified URI as a prefix.
The strength of the policy for an extension for the resources is one
of req, ref, or opt.
req
Required. The resource must be accessed using the extension.
opt
Optional. The resource may be accessed using the extension or not
using the extension.
ref
Refused. The resource may not be accessed using the extension.
The syntax is:
Protocol-Info = "Protocol-Info" ":" 1#policy-decl
policy-decl = "{" extension-id *policy-info "}"
policy-info = str | params | headers | scope | for
str = "{" "str" ("req" | "ref" | "opt" ) "}"
scope = "{" "scope" ( "conn" | "origin" ) "}"
for = "{" "for" URI [ wildcard ] "}"
wildcard = "*"
Note that a Protocol-Info with a for parameter may give information
about a different resource from the resource described by the other
header fields in the same message. Nonetheless, the freshness of the
information in the Protocol-Info header field is the same as the rest
of the header fields (which see [HTTP] section 13.2, "Expiration
Model").
The notice is strictly advisory. The client should heed the notice on
its next request to the relavent server, unless the delay between
receiving the notice and that next request far exceeds the freshness
of the reply containing the Protocol-Info header.
For example, consider the case of an HTML form, where the associated
ACTION resource requires a payment extension. In the response that
provides the form, the server may notify the client about the ACTION
resource:
HTTP/1.1 200 OK
Content-Type: text/html
Protocol-Info: {http://some.org/payment-thingy {for /cgi-bin/buy *} {str req}}