WD-http-pep-971121 69.6 KB

Raw Blame History Permalink

<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
  <TITLE>PEP - an Extension Mechanism for HTTP</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000" LINK="#0000ff" VLINK="#7f007f">
<P ALIGN="right">
<A HREF="http://www.w3.org"><IMG SRC="http://www.w3.org/Icons/WWW/w3c_home"
    WIDTH="72" HEIGHT="48" ALIGN="Left" ALT="W3C" BORDER="0"></A><STRONG>WD-http-pep-971121</STRONG>
<P>
<BR>
<H1 ALIGN="CENTER">
  PEP - an Extension Mechanism for HTTP
</H1>
<H2 ALIGN="CENTER">
  W3C Working Draft 21 November 1997
</H2>
<DL>
  <DT>
    Authors
  <DD>
    <A HREF="#frystyk">Henrik Frystyk Nielsen</A>,
    <A HREF="#connolly">Dan Connolly</A>,
    <A HREF="#khare">Rohit Khare</A>,
    <A HREF="#prudhommeaux ">Eric Prud'hommeaux</A>
  <DT>
    This version:
  <DD>
    <A HREF="http://www.w3.org/TR/WD-http-pep-970526">http://www.w3.org/TR/WD-http-pep-971121</A>
  <DD>
    $Id: WD-http-pep-971121.html,v 1.2 1998/04/07 21:31:46 fillault Exp $
  <DT>
    Latest Released Version:
  <DD>
    <A HREF="http://www.w3.org/TR/WD-http-pep">http://www.w3.org/TR/WD-http-pep</A>
  <DT>
    Previous Versions:
  <DD>
    <A HREF="http://www.w3.org/TR/WD-http-pep-970428">http://www.w3.org/TR/WD-http-pep-970714</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-970428">http://www.w3.org/TR/WD-http-pep-970428</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-970321">http://www.w3.org/TR/WD-http-pep-970321</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-970131">http://www.w3.org/TR/WD-http-pep-970131</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-960820">http://www.w3.org/TR/WD-http-pep-960820</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-960819">http://www.w3.org/TR/WD-http-pep-960819</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-960222">http://www.w3.org/TR/WD-http-pep-960222</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-951122">http://www.w3.org/TR/WD-http-pep-951122</A>
    <BR>
    <A HREF="http://www.w3.org/TR/WD-http-pep-960220">http://www.w3.org/TR/WD-http-pep-960220</A>
</DL>
<H1>
  Status of this Document
</H1>
<P>
This is a W3C Working Draft for review by W3C members and other interested
parties. It is a draft document and may be updated, replaced or made obsolete
by other documents at any time. It is inappropriate to use W3C Working Drafts
as reference material or to cite them as other than "work in progress." A
list of current W3C working drafts can be found at "http://www.w3.org/TR".
This WD has also been submitted as IETF ID
&lt;draft-ietf-http-pep-05.txt&gt;.
<P>
The PEP specification has gone through a thorough design phase and entered
a steady state where the authors do not intend to modify the document any
further. At the same time we have developed practical experience with the
PEP demo code (available from "http://www.w3.org/Protocols/PEP") which
demonstrates both client, server, and proxy interactions using dynamic loaded
PEP extensions. However, we believe that it is essential for a specification
to be tested in real world applications before being deployed at large, which
is the reason for the status as Experimental.
<H1>
  Abstract
</H1>
<P>
HTTP is used increasingly in applications that need more facilities than
the standard version of the protocol provides, ranging 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 applications such as HTTP clients,
servers, and proxies. The PEP mechanism is designed to associate each extension
with a URI[2], and use a few new RFC 822[1] derived header fields to carry
the extension identifier and related information between the parties involved
in an extended transaction.
<P>
This document defines PEP and describes the interactions between PEP and
HTTP/1.1[7]. PEP is intended to be compatible with HTTP/1.0[5] inasmuch as
HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7). It is proposed
that the PEP extension mechanism be included in future versions of HTTP.
<P>
The PEP extension mechanism may be applicable to other information exchange
not mentioned in this document. It is recommended that readers get acquainted
with section 1.4 for a suggested reading of this specification and a list
of sections specific for HTTP based applications.
<H1>
  Table of Contents
</H1>
<OL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743936">Introduction</A>
    <DL compact>
      <DT>
	1.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743937">Requirements</A>
      <DT>
	1.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743938">Purpose</A>
      <DT>
	1.3
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743939">Operational Overview</A>
      <DT>
	1.4
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743940">Guide to this Specification</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743941">The PEP Extension Space in
    HTTP</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743942">Notational Conventions</A>
    <DL compact>
      <DT>
	3.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743943">Bag Syntax</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743944">Extension Declarations</A>
    <DL compact>
      <DT>
	4.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743945">Mapping Header Fields</A>
      <DT>
	4.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743946">The Strength of a
	Declaration</A>
      <DT>
	4.3
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743947">End-to-End Extension
	Declarations</A>
      <DT>
	4.4
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743948">Hop-by-Hop Extension
	Declarations</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743949">Extension Policy
    Information</A>
    <DL compact>
      <DT>
	5.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743950">The Realm of a Policy</A>
      <DT>
	5.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743951">Policy Expirations</A>
      <DT>
	5.3
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743952">Extra Parameters</A>
      <DT>
	5.4
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743953">End-to-End Policies</A>
      <DT>
	5.5
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743954">Hop-by-Hop Policies</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743955">Publishing an Extension</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743956">Binding HTTP Requests</A>
    <DL compact>
      <DT>
	7.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743957">Extending Existing HTTP
	Methods</A>
      <DT>
	7.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743958">Adding New HTTP Methods</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743959">HTTP Status Codes</A>
    <DL compact>
      <DT>
	8.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743960">420 Policy Not Fulfilled</A>
      <DT>
	8.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743961">421 Bad Mapping</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743962">HTTP Proxy Servers</A>
    <DL compact>
      <DT>
	9.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743963">Proxy Servers as End-to-End
	Recipients</A>
	<DL compact>
	  <DT>
	    9.1.1
	  <DD>
	    <A HREF="WD-http-pep-971121.html#_Toc404743964">Proxy Servers Acting on Behalf
	    of User Agents</A>
	  <DT>
	    9.1.2
	  <DD>
	    <A HREF="WD-http-pep-971121.html#_Toc404743965">Proxy Servers Acting on Behalf
	    of Origin Servers</A>
	</DL>
      <DT>
	9.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743966">Proxy Servers and Repeated
	Hop-by-Hop Extensions</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743967">Practical Considerations
    for HTTP</A>
    <DL compact>
      <DT>
	10.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743968">Interaction with Existing
	HTTP/1.1 Methods</A>
      <DT>
	10.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743969">Interaction with Existing
	HTTP/1.1 Headers</A>
      <DT>
	10.3
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743970">Server Initiated Extension
	Declarations</A>
    </DL>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743971">Security Considerations</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743972">Normative References</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743973">Bibliography: Informative
    References</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743974">Acknowledgements</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#Authors">Authors Addresses</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743976">Summary of PEP Interactions</A>
  <LI>
    <A HREF="WD-http-pep-971121.html#_Toc404743977">Examples</A>
    <DL compact>
      <DT>
	17.1
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743978">Client Queries Server for
	DAV</A>
      <DT>
	17.2
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743979">Client Informs Server about
	ZipFlate Compression Extension</A>
      <DT>
	17.3
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743980">Server Uses Content-Digest
	Extension</A>
      <DT>
	17.4
      <DD>
	<A HREF="WD-http-pep-971121.html#_Toc404743981">Server Requires Client to
	use Payment Extension</A>
    </DL>
</OL>
<H1>
  1. <A NAME="_Toc404743936">Introduction</A>
</H1>
<H2>
  1.1 <A NAME="_Toc404743937">Requirements</A>
</H2>
<P>
HTTP is a generic request-response protocol, designed to accommodate a variety
of applications, from network information exchange and searching to file
transfer and repository access to query and forms processing.
<P>
Most HTTP transactions are initiated by a user agent issuing a request to
be applied to a resource on some origin server, with intermediaries between
them in some cases. The origin server replies with a response indicating
the result of the transaction.
<P>
Semantically, however, an HTTP transaction is between the principal accessing
a resource (end user) and the principal responsible for the publication of
a given resource (publisher). The publisher is 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. The end user accesses
information provided by a publisher. Exactly who takes the role as end user
or publisher is beyond the scope of this document.
<P>
HTTP, as is the case for most transaction based information exchange protocols,
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.
<P>
Many extended applications do not require agreement across the whole Internet
about the extended facilities; rather, it suffices:
<UL>
  <LI>
    That conforming peers supporting a particular protocol extension or feature
    can employ it dynamically with no prior agreement;
  <LI>
    That it is possible for one party having a capability for a new protocol
    to require that the other party either understand and abide by the new protocol
    or abort the operation;
  <LI>
    That negotiation of matching capabilities is possible.
</UL>
<P>
The need for extensibility creates a tension between dynamically extensible
applications and public, static specifications.
<H2>
  1.2 <A NAME="_Toc404743938">Purpose</A>
</H2>
<P>
The Protocol Extension Protocol (PEP) is an extension mechanism designed
to accommodate dynamic extension of HTTP applications by software components;
and to address the tension between private agreement and public specification.
The kind of extensions capable of being introduced by PEP range from:
<UL>
  <LI>
    extending a single protocol message;
  <LI>
    introducing new encodings;
  <LI>
    initiating HTTP-derived protocols for new applications; to...
  <LI>
    switching to protocols which, once initiated, run independent of the original
    protocol stack.
</UL>
<P>
This document defines the protocol extension mechanism referred to as "PEP".
The PEP design is the result of analyzing a variety of extensions and extension
mechanisms in HTTP and HTTP-like protocols, and the motivation behind them.
<P>
The specification also describes the interactions between PEP and HTTP/1.1[7]
including scoping rules and cache semantics. PEP is intended to be compatible
with HTTP/1.0[5] inasmuch as HTTP/1.1 is compatible with HTTP/1.0 (see section
1.4 and 10) and it is proposed that the PEP extension mechanism be included
in future versions of HTTP.
<H2>
  1.3<A NAME="_Toc404743939"> Operational Overview</A>
</H2>
<P>
PEP is intended to be used as follows:
<UL>
  <LI>
    Some party designs and specifies an extension; the party assigns the extension
    an identifier, which is a URI, and makes one or more representations of the
    extension available at that address (see section 6).
  <LI>
    A party using a PEP compliant agent with an implementation of the extension
    wishes to use it; the agent declares the use of the extension by referencing
    its URI in a PEP extension declaration (see section 4).
  <LI>
    Information about extensions can be passed between agents including information
    of where they can be used and under what conditions (see section 5).
</UL>
<P>
If an extension becomes ubiquitous, it may be incorporated into a new version
of the base protocol, hence transitioning from dynamic extension to static
specification. In this case, applications can refer to the new version of
the base protocol instead of the PEP extension (see section 6).
<P>
PEP extension declarations are characterized by the following properties:
<UL>
  <LI>
    They link features introduced by the extension to the URI identifying the
    extension, potentially allowing a recipient to interpret the message correctly
    with no prior agreement.
  <LI>
    They contain a <I>strength</I> and a <I>scope</I> allowing the sender to
    define the appropriate action to be taken by the recipient even if it does
    not understand the semantics of the extension.
  <LI>
    Any agent can generate declarations independent of other agents
</UL>
<P>
The advantage of including the extension identifier is that, at the cost
of some extra bytes to spell out the URI, the use of a central registry of
extension names is avoided. PEP can also be used to extend applications to
support centrally registered extensions, assuming a URI is published as part
of the registration (see section 6).
<P>
The PEP mechanism is designed to accommodate but does not require dynamic
extension of clients, servers, and proxies by software components as follows:
<UL>
  <LI>
    Clients and servers could be implemented with software component interfaces
    that allow dynamic installation of extension facilities.
  <LI>
    An implementation compatible with a software component interface supported
    by the agent could be made available at the URI identifying the extension.
  <LI>
    An agent receiving a message referring to an extension not known by the agent
    could dereference the extension's identifier and dynamically load support
    for the extended facility.
</UL>
<P>
The representation and implementation of dynamic extensible software component
interfaces is outside the scope of this specification.
<H2>
  1.4 <A NAME="_Toc404743940">Guide to this Specification</A>
</H2>
<P>
This specification is organized as follows: Section 2 describes how PEP fits
into HTTP. This is not required reading but may further the understanding
of the specification. Section 3 is an overview of the notational conventions
used throughout the specification.
<P>
Section 4, 5, and 6 is the core part of the specification describing the
generic PEP extension mechanism. Section 7, 8, 9, and 10 describe the
interactions between PEP and HTTP/1.1[7].
<P>
The generic PEP extension mechanism may be applicable to other information
exchange protocols. Such mappings, however, are outside the scope of this
specification.
<H1>
  2. <A NAME="_Toc404743941">The PEP Extension Space in HTTP</A>
</H1>
<P>
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:
<DL>
  <DT>
    Methods
  <DD>
    The method token in an HTTP request indicates the method to be performed
    on the resource identified by the <TT>Request-URI</TT>. 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 [7] 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.
  <DT>
    Status Codes
  <DD>
    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 cod-e of that class (see [7] section 6.1.1). For example, a new
    status code, 223 (My New Code) would default to 200 (OK).
  <DT>
    Headers
  <DD>
    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 [7] section 7.1).
</DL>
<P>
In order to achieve the desired flexibility, PEP is designed to use the header
space for describing extensions and not directly HTTP methods or 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:
<UL>
  <LI>
    a special <TT>PEP</TT> method and a <TT>PEP-</TT> method prefix which indicates
    that a request contains one or more PEP extensions that must be adhered to
    or the transaction aborted (see section 7);
  <LI>
    a special status code 420 (Policy Not Fulfilled) that indicates that the
    policy for accessing the resource was not met and that further information
    can be found in the response for diagnosing the problem (see section 8.1).
</UL>
<P>
These two placeholders allow for multiple PEP extensions to be deployed
simultaneously without overloading the method space or the status code space.
<H1>
  3. <A NAME="_Toc404743942">Notational Conventions</A>
</H1>
<P>
This specification uses the same notational conventions and basic parsing
constructs as RFC 2068[7]. In particular the BNF constructs "<TT>token</TT>",
"<TT>quoted-string</TT>", "<TT>field-name</TT>", "<TT>URI</TT>", and
"<TT>delta-seconds</TT>" in this document are to be interpreted as described
in RFC 2068[7].
<P>
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[9].
<P>
PEP does not rely on particular features defined in URLs [3] that cannot
potentially be expressed using URNs (see section 6). Therefore, the more
generic term URI[2] is used throughout the specification.
<H2>
  3.1 <A NAME="_Toc404743943">Bag Syntax</A>
</H2>
<P>
The bag element is a recursive structure that uses braces ("{" and "}") to
delimit attribute-value pairs that may consist of tokens, quoted-strings,
URIs and recursively defined bags. The BNF for the bag syntax is as follows:
<PRE>    bag             = "{" bagname *bagitem "}"
    bagname         = token
    bagitem         = bag
                    | token
                    | quoted-string
</PRE>
<P>
The bag semantics are defined by its context and the bag name. The value
of a quoted string may be a URI in some cases. Unless explicitly defined
otherwise, all tokens within a bag are case-insensitive. Comments as defined
by RFC 822[1] indicated by surrounding the comment text with parentheses
MUST NOT be used within a bag construct.
<H1>
  4. <A NAME="_Toc404743944">Extension Declarations</A>
</H1>
<P>
Extension declaration bags are used to indicate the PEP extensions that have
been applied to a message. The grammar for an extension declaration is as
follows:
<PRE>    ext-decl        = "{" req-ext-attr *opt-ext-attr "}"
    req-ext-attr    = map

    opt-ext-attr    = strength
                    | attribute-ext
    map             = "{" "map" &lt;"&gt; URI &lt;"&gt; #(header-prefix) "}"
    strength        = "{" "strength" ( "must" | "may" ) "}"

    attribute-ext   = bag
    header-prefix   = 1*DIGIT "-"
</PRE>
<P>
The <TT>map</TT> attribute bag contains the URI identifying the extension
and a list of any header field names introduced by the extension (see section
4.1 and 6). If the extension identifier is relative, it is interpreted relative
to the base URI of the message as defined by RFC 1808[4].
<P>
The <TT>strength</TT> attribute bag indicates whether the recipient MUST
or MAY obey the semantics given by the extension or report an error (see
section 4.2).
<P>
An extension declaration bag (<TT>ext-decl</TT>) can be extended through
the use of one or more <TT>attribute-ext</TT> bags. Unrecognized
<TT>attribute-ext</TT> bags SHOULD be ignored and MUST NOT be removed by
proxies when forwarding the extension declaration (see section 9).
<P>
Extension declarations can either be hop-by-hop or end-to-end (see [7], section
13.5.1) depending on the scope of the declaration (see section 4.3 and 4.4).
End-to-end declarations MUST be transmitted to the ultimate recipient of
the extension declaration. Hop-by-hop declarations are meaningful only for
a single transport-level connection.
<H2>
  4.1 <A NAME="_Toc404743945">Mapping Header Fields</A>
</H2>
<P>
The <TT>header-prefix</TT> in a <TT>map</TT> attribute bag can be used to
indicate that all header fields in the message matching the
<TT>header-prefix</TT> value using string prefix-matching are introduced
by this extension declaration instance. This allows an extension instance
to dynamically reserve a part of the header space in the message for introducing
new header fields without risking header name conflicts with other extension
instances.
<P>
Examples of <TT>header-prefix</TT> values are
<PRE>    1-, 435-
    546-
    2343543645653-
</PRE>
<P>
Agents 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.
<P>
Agents SHOULD NOT reuse already mapped header fields in the same message.
If a header field is mapped by multiple extension declarations in the same
message, the recipient SHOULD report an error (see section 8.2).
<P>
Proxies adding extension declarations to a message MUST make sure that any
header fields introduced do not conflict with already mapped header fields
in that protocol message (see section 8.2).
<H2>
  4.2 <A NAME="_Toc404743946">The Strength of a Declaration</A>
</H2>
<P>
The <TT>strength</TT> attribute bag can be used to specify the actions to
be taken by the ultimate recipient of the extension declaration. The
<TT>strength</TT> value can indicate that
<OL>
  <LI>
    the recipient MUST obey the extension declaration or report an error; or
  <LI>
    the recipient MAY obey the extension declaration or ignore it altogether.
</OL>
<P>
If the strength is "<TT>must</TT>", the ultimate recipient MUST consult and
adhere to the rules given by the extension when processing the message or
report an error (see section 7 and 8.1).
<P>
If the strength is "<TT>may</TT>" the ultimate recipient of the extension
MAY consult and adhere to the rules given by the extension when processing
the message, or ignore the extension declaration completely. An agent may
not be able to distinguish whether the ultimate recipient does not understand
an extension referred to by an extension declaration of strength
"<TT>may</TT>" or simply ignores the extension declaration.
<P>
If no strength attribute is present, the default strength is "<TT>may</TT>".
<P>
Not accepting or ignoring an extension declaration is different from not
accepting a mapping of header <TT>field-name</TT>s introduced by the
<TT>map</TT> attribute bag. If the ultimate recipient cannot accept a mapping,
for example if a <TT>field-name</TT> is already mapped by another extension
declaration in that protocol message, it SHOULD report an error (see section
8.2).
<H2>
  4.3 <A NAME="_Toc404743947">End-to-End Extension Declarations</A>
</H2>
<P>
End-to-end declarations MUST be transmitted to the ultimate recipient of
the declaration. The <TT>PEP</TT> header field is an end-to-end header field
and is defined as follows:
<PRE>    pep             = "PEP" ":" 1#ext-decl
</PRE>
<P>
For example
<PRE>    GET / HTTP/1.1
    Host: some.host
    PEP: {{map "http://www.w3.org/PEP/DAV"}}
</PRE>
<P>
If multiple end-to-end extensions are declared in the same message, the
declarations MUST be listed in the order in which they were applied to the
message.
<P>
Proxies MAY under certain conditions act as the ultimate recipient of
declarations on behalf of user agents and origin servers (see section 9.1).
<H2>
  4.4 <A NAME="_Toc404743948">Hop-by-Hop Extension Declarations</A>
</H2>
<P>
Hop-by-hop extension declarations are meaningful only for a single
transport-level connection. The <TT>C-PEP</TT> header field is a hop-by-hop
header field and MUST NOT be communicated by proxies over further connections.
The <TT>C-PEP</TT> header has the following grammar:
<PRE>    c-pep           = "C-PEP" ":" 1#ext-decl
</PRE>
<P>
For example
<PRE>    GET / HTTP/1.1
    Host: some.host
    C-PEP: {{map "http://www.w3.org/PEP/ProxyAuth" 43-}}
    43-Credentials: "fsdgfag"
    Connection: C-PEP, Credentials
</PRE>
<P>
In HTTP, the <TT>C-PEP</TT> header field MUST be protected by a
<TT>Connection</TT> header by including <TT>C-PEP</TT> as a
<TT>Connection</TT> header directive. The directive MUST be handled according
to the HTTP/1.1 specification of the <TT>Connection</TT> header (see section
10.2 and [7], section 14.10).
<P>
An agent MUST NOT send the <TT>C-PEP</TT> header field to an HTTP/1.0 proxy
as it does not obey the HTTP/1.1 rules for parsing the <TT>Connection</TT>
header field (see [7], section 19.7.1).
<P>
If multiple hop-by-hop extensions are declared in the same message, the extension
declarations MUST be listed in the order in which they were applied. Hop-by-hop
<TT>C-PEP</TT> declarations MUST be processed before any end-to-end
<TT>PEP</TT> declarations.
<H1>
  5. <A NAME="_Toc404743949">Extension Policy Information</A>
</H1>
<P>
Extension Policy bags are used to indicate the extensions that may be applied
to a message. Extension policies differ from extension declarations in that
the latter is information about which extensions <I>have been</I> applied
to a message. An extension policy is defined as follows:
<PRE>    policy-decl     = "{" req-pol-attr *opt-pol-attr "}"
    req-pol-attr    = id

    opt-pol-attr    = for
                    | max-age
                    | parameters
                    | strength
                    | attribute-ext
</PRE>
<PRE>    id              = "{" "id" &lt;"&gt; URI &lt;"&gt; "}"
    for             = "{" "for" #URI-wildcard "}"
    max-age         = "{" "max-age" delta-seconds "}"

    parameters      = "{" "params" *bagitem "}"
    URI-wildcard    = &lt;"&gt; URI &lt;"&gt; [ wildcard ]
    wildcard        = "*"
</PRE>
<P>
The <TT>id</TT> attribute specifies the URI identifying the extension (see
section 6). If the extension identifier is relative, it is interpreted relative
to the base URI of the message as defined by RFC 1808[4].
<P>
The <TT>for</TT> attribute bag specifies which resources, the policy is intended
for (see section 5.1) and the <TT>max-age</TT> attribute bag when the information
should be considered stale (see section 5.2). The <TT>params</TT> attribute
bag can be used to pass additional information about the extension policy
(see section 5.3).
<P>
The <TT>strength</TT> attribute indicates whether the policy is a requirement
or optional for the resource(s) for which it applies (see section 4.2).
<P>
An extension policy bag (<TT>policy-decl</TT>) can be extended through the
use of one or more <TT>attribute-ext</TT> bags. Unrecognized
<TT>attribute-ext</TT> bags SHOULD be ignored and MUST NOT be removed by
proxies when forwarding the extension policy (see section 9).
<P>
Extension policies can either be hop-by-hop or end-to-end policies (see [7],
section 13.5.1) depending on the scope (see section 5.4 and 5.5). End-to-end
policies MUST be transmitted to the ultimate recipient of the extension policy.
Hop-by-hop policies are meaningful only for a single transport-level connection.
<P>
<EM>Note: It is expected that extension policies will be integrated with
other metadata initiatives like the RDF initiative [11], for example.</EM>
<H2>
  5.1 <A NAME="_Toc404743950">The Realm of a Policy</A>
</H2>
<P>
The <TT>for</TT> attribute bag can be used to specify the resource(s) identified
by URI(s) to which the policy applies. This allows extension policies to
be deployed to third party sites and to be distributed by other means than
directly between the involved parties. A URI followed by a LWS and a wildcard
("*") represents the set of URIs that contains the given URI using prefix
matching. A URI with no wildcard means that URI only.
<P>
Examples of <TT>URI-wildcards</TT> are
<PRE>    {for "/" *}
    {for "http://www.w3.org/pub/" *}
    {for "secret/Overview.html"}
</PRE>
<P>
An empty <TT>for</TT> attribute bag (no <TT>bagitem</TT>s included) indicates
that the policy is not applied to any resource. If no <TT>for</TT> attribute
bag is present, the default value is the <TT>Request-URI</TT>.
<P>
A realm can include any number of resources but note that a single wildcard
"*" is not a valid <TT>URI-wildcard</TT> value.
<H2>
  5.2 <A NAME="_Toc404743951">Policy Expirations</A>
</H2>
<P>
The <TT>max-age</TT> attribute bag can be used to specify a date/time after
which the recipient SHOULD consider the policy stale. The <TT>max-age</TT>
attribute bag value indicates that the information should no longer be used
if the age is greater than the specified time in seconds (see [7] section
13.2.3 for how to calculate the age). A <TT>max-age</TT> attribute bag cannot
be used to force the recipient to discard the policy information; its semantics
apply only to the caching mechanism of policy information.
<H2>
  5.3 <A NAME="_Toc404743952">Extra Parameters</A>
</H2>
<P>
The params attribute bag can be used to include additional information about
the extension or modifiers on the use of the extension. The <TT>params</TT>
values may or may not be case-sensitive, depending on the semantics of the
parameter name. The params attribute bag is defined as a generic bag structure,
which may be nested. No default parameters are defined.
<P>
<EM>Note: PEP implementations should pass any parameters to the module or
modules handling the particular extension as this may have impact the use
of the extension.</EM>
<H2>
  5.4 <A NAME="_Toc404743953">End-to-End Policies</A>
</H2>
<P>
End-to-end policies MUST be transmitted to the ultimate recipient of a message.
The <TT>PEP-Info</TT> header field is an end-to-end header and is defines
as follows:
<PRE>    pep-info         = "PEP-Info" ":" 1#policy-decl
</PRE>
<P>
For example
<PRE>    HTTP/1.1 200 OK
    Content-Type: text/html
    Content-Length: 412
    PEP-Info: {{id "http://some.org/payment-extension"}
              {for "/cgi-bin/buy" *}
              {strength must}}

    &lt;!doctype html public "-//W3C//DTD HTML 3.2//EN" &gt;
    &lt;html&gt; ...
</PRE>
<P>
Proxies MAY under certain conditions act as the ultimate recipients of extension
policies on behalf of user agents and origin servers (see section 9.1).
<H2>
  5.5 <A NAME="_Toc404743954">Hop-by-Hop Policies</A>
</H2>
<P>
Hop-by-hop policies are meaningful only for a single transport-level connection.
The <TT>C-PEP-Info</TT> header field is a hop-by-hop header field and MUST
NOT be communicated by proxies over further connections. The
<TT>C-PEP-Info</TT> header has the following grammar:
<PRE>    c-pep-info       = "C-PEP-Info" ":" 1#policy-decl
</PRE>
<P>
For example
<PRE>    HTTP/1.1 420 Policy Not Fulfilled
    C-PEP-Info: {{id "http://some.org/provide-stats"}
                 {for "/" *}}
    Connection: C-PEP-Info
    ...
</PRE>
<P>
In HTTP, the <TT>C-PEP-Info</TT> header field MUST be protected by a
<TT>Connection</TT> header by including <TT>C-PEP-Info</TT> as a
<TT>Connection</TT> header directive. The directive MUST be handled according
to the HTTP/1.1 specification of the <TT>Connection</TT> header (see section
10.2 and [7], section 14.10).
<P>
An agent MUST NOT send the <TT>C-PEP-Info</TT> header field to an HTTP/1.0
proxy as it does not obey the HTTP/1.1 rules for parsing the
<TT>Connection</TT> header field (see [7], section 19.7.1).
<H1>
  6. <A NAME="_Toc404743955">Publishing an Extension</A>
</H1>
<P>
While the protocol extension definition should be published at the address
of the extension identifier, this is not a requirement of this specification.
The only absolute requirement is that distinct names be used for distinct
semantics. For example, one way to achieve this is to use a <I>mid</I>,
<I>cid</I>, or <I>uuid</I> URI. The association between the extension identifier
and the specification might be made by distributing a specification, which
references the extension identifier.
<P>
It is strongly recommended that the integrity and persistence of the extension
identifier is maintained and kept unquestioned throughout the lifetime of
the extension. 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.
<P>
The extension definition may be made available in different representations
ranging from
<UL>
  <LI>
    a human-readable specification defining the extension semantics,
  <LI>
    downloadable code which implements the semantics defined by the extension,
  <LI>
    a formal interface description provided by the extension, to
  <LI>
    a machine-readable specification defining the extension semantics.
</UL>
<P>
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.
<H1>
  7. <A NAME="_Toc404743956">Binding HTTP Requests</A>
</H1>
<P>
An HTTP request is called a "binding" request if it includes at least one
PEP extension declaration of strength "<TT>must</TT>". An HTTP server MUST
NOT return a 2xx <TT>status-code</TT> without obeying all extension
declaration(s) of strength "<TT>must</TT>" in a binding request. This section
describes how the binding request mechanism in PEP interacts with existing
HTTP applications.
<P>
In [7], section 7.1, it is stated that "Unrecognized header fields SHOULD
be ignored by the recipient and MUST be forwarded by proxies." Hence, using
a <TT>PEP</TT> or a <TT>C-PEP</TT> extension declaration is not sufficient
to evoke the correct behavior from existing HTTP agents in a binding request.
However, in [7], section 5.1.1, Method, it is said that "Servers SHOULD return
501 (Not Implemented) if the method is unrecognized or not implemented by
the server." A similar statement is made in [5], section 9.5. It is therefore
safe to assume that using the method name will produce the correct result
from existing HTTP servers and proxies.
<P>
PEP uses the HTTP request method name to extend existing HTTP/1.1 methods
and to introduce new methods (see section 1.3). In both cases, a binding
HTTP request invalidates cached entries as described in [7], section 13.10.
Responses to binding requests are not cachable.
<H2>
  7.1 <A NAME="_Toc404743957">Extending Existing HTTP Methods</A>
</H2>
<P>
The method name of all HTTP/1.1 requests containing a PEP extension declaration
of strength "<TT>must</TT>" that semantically extends that method MUST be
prefixed by "<TT>PEP-</TT>" (see section 10.1). For example, a client might
express the binding rights-management constraints in an HTTP PUT request
as follows:
<PRE>    PEP-PUT /a-resource HTTP/1.1
    PEP: {{map "http://www.w3.org/PEP/rights-management" 8-}
          {strength must}}
    8-copyright: http://www.w3.org/COPYRIGHT.html
    8-contributions: http://www.w3.org/PATCHES.html
    Host: www.w3.org
    Content-Length: 1203
    Content-Type: text/html

    &lt;!doctype html ...
</PRE>
<P>
The ultimate recipient of a binding HTTP request with the "<TT>PEP-</TT>"
prefix on the method name MUST process the request by performing the following
actions in the order they occur:
<OL>
  <LI>
    Identify all extension declarations (both hop-by-hop and end-to-end) of strength
    "<TT>must</TT>"; the server MAY ignore declarations of strength
    "<TT>may</TT>" without affecting the result of the transaction;
  <LI>
    Evaluate and process the extensions identified in 1) in the order they were
    declared (see section 4.3 and 4.4) or if the extension declarations do not
    match the policy for accessing the resource then respond with a 420 (Policy
    Not Fulfilled) <TT>status-code</TT> (see section 8.1);
  <LI>
    Strip the "<TT>PEP-</TT>" prefix from the method name and process the reminder
    of the request according to the semantics of the existing HTTP/1.1 method
    name as defined in [7].
</OL>
<P>
The "<TT>PEP-</TT>" prefix is reserved by PEP and MUST NOT be used by other
HTTP extensions.
<H2>
  7.2 <A NAME="_Toc404743958">Adding New HTTP Methods</A>
</H2>
<P>
The PEP method can be used for all PEP extension declarations of strength
"<TT>must</TT>" that do not naturally extend existing HTTP/1.1 methods. Such
methods can be address space manipulation extensions like MOVE and COPY,
for example:
<PRE>    PEP /source.html HTTP/1.1
    PEP: {{map "http"//www.w3.org/DAV/MOVE" 4-}
         {strength must}}
    4-Destination: destination.html
    Host: some.host
</PRE>
<P>
The <TT>PEP</TT> method indicates that the semantics of this request are
defined by one or more PEP extension declarations of strength "<TT>must</TT>"
included in the request. The PEP method does not have any HTTP message semantics
besides being a placeholder for PEP extension declarations and hence all
other semantics MUST be defined by the declaration(s) included in the request.
<P>
The ultimate recipient of a <TT>PEP</TT> request MUST process the request
by doing the following:
<OL>
  <LI>
    Identify all extension declarations (both hop-by-hop and end-to-end) of strength
    "must"; the server MAY ignore declarations of strength "<TT>may</TT>" without
    affecting the result of the transaction;
  <LI>
    Evaluate and process the extensions identified in 1) in the order they were
    declared (see section 4.3 and 4.4) or if the extension declarations do not
    match the policy for accessing the resource then respond with a 420 (Policy
    Not Fulfilled) <TT>status-code</TT> (see section 8.1);
</OL>
<P>
A successful response SHOULD be 200 (OK) if the response includes an entity,
202 (Accepted) if the action has not yet been enacted, or 204 (No Content)
if the response is OK but does not include an entity. If no extension
declarations have strength "<TT>must</TT>", the response SHOULD be 400 (Bad
Request).
<P>
The <TT>PEP</TT> method is reserved by PEP and MUST NOT be used by other
HTTP extensions.
<H1>
  8. <A NAME="_Toc404743959">HTTP Status Codes</A>
</H1>
<P>
PEP introduces two new status codes in addition to the ones already defined
by HTTP/1.1[7]. Each <TT>Status-Code</TT> is described below, including a
description the metainformation required in the response.
<H2>
  8.1 <A NAME="_Toc404743960">420 Policy Not Fulfilled</A>
</H2>
<P>
The policy for accessing the resource has not been met in the request. The
response MUST include a <TT>PEP-Info</TT> or a <TT>C-PEP-Info</TT> header
field specifying the extensions required by the publishing party for accessing
the resource. The server MAY use the <TT>for</TT> attribute bag to indicate
whether the policy applies to other resources.
<P>
The client MAY repeat the request using the appropriate extension(s). If
the initial request already included the extensions requested in the 420
response, then the response indicates that access has been refused for those
extension declarations.
<P>
If the 420 response contains the same set of extension policies as the prior
response, then the client MAY present any entity included in the response
to the user, since that entity may include relevant diagnostic information.
<P>
Implementers may note the similarity to the way authentication challenges
are issued with the 401 (Unauthorized) <TT>status-code</TT> (see [7], section
10.4.2)
<H2>
  8.2 <A NAME="_Toc404743961">421 Bad Mapping</A>
</H2>
<P>
The mappings indicated by one or more <TT>map</TT> attribute bags in the
request were not unique and mapped the same header field more than once.
The client MAY repeat the request using a new set of mappings if it believes
that it can find a unique set of header fields for which the transaction
will succeed.
<H1>
  9. <A NAME="_Toc404743962">HTTP Proxy Servers</A>
</H1>
<P>
This section describes the role of caching and non-caching proxies and how
they interact with PEP extensions. Normally, the ultimate recipient of an
end-to-end extension declaration or an end-to-end extension policy is an
origin server or a user agent.
<P>
In this case, a proxy MUST forward all components of the extension, including
declarations, policies, headers, and any methods and status codes defined
by this specification.
<P>
In other cases, however, intermediate caching and non-caching proxies MAY
be authorized to act on behalf of origin servers and/or user agents. How
such an agreement is reached between a party representing the proxy and the
party on which behalf it can act, is outside the scope of PEP, but for example,
the parties may be within the same trust domain.
<H2>
  9.1 <A NAME="_Toc404743963">Proxy Servers as End-to-End Recipients</A>
</H2>
<H3>
  9.1.1 <A NAME="_Toc404743964">Proxy Servers Acting on Behalf of User Agents</A>
</H3>
<P>
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:
<UL>
  <LI>
    The proxy SHOULD remove the extension declaration(s) and any header fields
    that are part of these declaration(s) on which it can act authoritatively
    before forwarding the response to the proxy client;
  <LI>
    it SHOULD issue extension policies for the extensions on which it can act
    authoritatively as if it was a user agent;
  <LI>
    if an extension declaration added by an HTTP proxy is of strength
    "<TT>must</TT>", the proxy MUST either prepend the "<TT>PEP-</TT>" method
    name prefix or use the <TT>PEP</TT> method instead of the method name used
    in the proxy client request, before forwarding the response to the origin
    server (see section 7.1).
</UL>
<P>
An example of a proxy acting on behalf of one or more user agents is an
elementary school wishing to enforce a certain policy for accessing information
on the Internet. The local school proxy can act authoritatively as a retrieval
filter on behalf of the pupils instead of having distributed filtering enabled
on each of the user agents using the client.
<H3>
  9.1.2 <A NAME="_Toc404743965">Proxy Servers Acting on Behalf of Origin
  Servers</A>
</H3>
<P>
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:
<P>
The proxy SHOULD remove the extension declaration(s) and any header fields
that are part of these declaration(s) on which it can act authoritatively
before forwarding the request to the origin server;
<UL>
  <LI>
    it SHOULD issue extension policies for the extensions on which it can act
    authoritatively as if it was an origin server;
  <LI>
    if an extension declaration added by an HTTP proxy is of strength
    "<TT>must</TT>" and there are no other extension declarations of strength
    "<TT>must</TT>" in the request, the proxy MUST remove any "<TT>PEP-</TT>"
    method name prefix before forwarding the request to the origin server (see
    section 7.1);
  <LI>
    if a request uses the <TT>PEP</TT> method, the proxy MUST NOT forward the
    request to the origin server unless the communication between the proxy and
    the origin server can be completed using an existing HTTP/1.1 method.
</UL>
<P>
An example of a proxy acting on behalf of an origin server 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 authoritatively on behalf of the origin server
registering usage of the journal.
<H2>
  9.2 <A NAME="_Toc404743966">Proxy Servers and Repeated Hop-by-Hop
  Extensions</A>
</H2>
<P>
If a PEP extension is to be used on parts of a message path, including user
agents, origin servers, and proxies, not covered by end-to-end or hop-by-hop
extension declarations, it can be defined as a repeated hop-by-hop extension.
This can for example be the case for a proxy extension applied to a subset
of proxies in a message path.
<P>
It is for the designer of the extension to decide whether it can repeat itself
on a hop-by-hop basis. In other words, any scope more complex than a hop-by-hop
or an end-to-end scope is a property of the extension and is transparent
to PEP.
<H1>
  10. <A NAME="_Toc404743967">Practical Considerations for HTTP</A>
</H1>
<P>
This section describes some practical considerations intended for PEP extended
HTTP applications. The issues described may not apply to other information
retrieval protocols.
<H2>
  10.1 <A NAME="_Toc404743968">Interaction with Existing HTTP/1.1 Methods</A>
</H2>
<P>
Extension designers should consider whether an extension is to work with
existing HTTP/1.1 methods using the "<TT>PEP-</TT>" method token prefix or
with the <TT>PEP</TT> method (see section 7.1 and 7.2). This specification
does not provide an absolute rule for when to use the <TT>PEP</TT> method
compared to the "<TT>PEP-</TT>" method token prefix except that the
"<TT>PEP-</TT>" method token prefix is required in situations where intermediate
proxies may act authoritatively on behalf of origin servers or user agents
(see section 9.1.1 and 9.1.2). In case the extension can be used with existing
methods then it should be considered whether the extension can be used with
any of the existing HTTP/1.1 methods or only a subset of them.
<P>
Some HTTP/1.1 methods follow the convention of being "safe" to the requester
meaning that they should never have the significance of taking an action
other than retrieval (see [7], section 9.1). This is for example the case
of the <TT>GET</TT> and the <TT>HEAD</TT> method. As PEP extension declarations
of strength "<TT>must</TT>" explicitly modify or replace the method name,
existing HTTP applications will never be able to mistake a PEP enabled message
for any of the existing HTTP messages indicated as being safe.
<P>
Some extensions may have the property of "idempotence" in that (aside from
error or expiration issues) the side effects of N &gt; 0 identical extended
requests is the same as for a single extended request. If this is <I>not</I>
the case for a PEP extension then it should consider whether it wants to
1) disable itself on repeated requests, and/or 2) inform a user about the
behavior of repeating identical requests with this extension.
<H2>
  10.2 <A NAME="_Toc404743969">Interaction with Existing HTTP/1.1 Headers</A>
</H2>
<P>
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[5] inasmuch
as HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7).
<P>
The <TT>Connection</TT> header as described in [7], section 14.10, allows
the sender to specify options that are desired for that particular transport
connection only. All PEP hop-by-hop extension declarations and policies along
with any header fields introduced by extension declarations MUST be included
as <TT>Connection</TT> header directives. PEP applications MUST NOT send
any hop-by-hop extension declarations or policies to HTTP/1.0 proxies as
they do not obey the rules of HTTP/1.1 for parsing the <TT>Connection</TT>
header field (see also [7], section 19.7.1).
<P>
The <TT>Upgrade</TT> header, [7], 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 provides the
same functionality but without the need for a central registry of protocol
names. PEP compliant agents MAY use the 101 (Switching Protocols) status
code to switch to HTTP-based protocols and protocols, which once initiated,
run completely independently of HTTP.
<P>
The content coding values in the <TT>Content-Encoding</TT> header as described
in [7], section 14.12, indicate an encoding transformation that has been
applied to an entity. PEP provides the same functionality but without the
need for a central registry of content codings. As both content codings and
PEP extension declarations are ordered, using both may lead to ambiguous
situations. Simultaneous use of both mechanisms is therefore strongly
discouraged.
<P>
An origin server can explicitly prevent intermediaries from applying a
<TT>Content-Encoding</TT> to a resource by using the <TT>no-transform
Cache-Control</TT> directive (see [7], section 14.9.4).
<H2>
  10.3 <A NAME="_Toc404743970">Server Initiated Extension Declarations</A>
</H2>
<P>
PEP extension declarations can be generated by servers as well as clients.
If a PEP compliant server sends a response with an extension declaration
referring to an extension that modifies the message in such a way that the
message can not be decoded without using the extension, and the corresponding
request was either
<OL>
  <LI>
    received from a client whose version is lower than HTTP/1.1, or
  <LI>
    received with a <TT>Via</TT> header field indicating that it was forwarded
    by a proxy whose version is lower than HTTP/1.1,
</OL>
<P>
and the response does not already include an <TT>Expires</TT> header, then
the sender SHOULD include an <TT>Expires</TT> header field whose
<TT>field-value</TT> is identical to the <TT>field-value</TT> of its
<TT>Date</TT> header field(see [7], section 14.12). If all agents in the
message path are HTTP/1.1, then the sender SHOULD use the
<TT>Cache-Control</TT> header field instead of the <TT>Expires</TT> header
field to mark the entity uncachable.
<H1>
  11. <A NAME="_Toc404743971">Security Considerations</A>
</H1>
<UL>
  <LI>
    The <TT>for</TT> parameter allows one party to give information about the
    extensions used by another party's resources. The parties may provide resources
    on different servers, or at different addresses on the same server. While
    distinguishing between the parties responsible for different resources at
    the same server may be infeasible, clients SHOULD ignore information given
    by one server about another unless they have reason to trust it, or reason
    to believe that trusting it will have no significant negative consequences.
  <LI>
    Dynamic installation of extension facilities as described in the introduction
    involves software written by one party (the provider of the implementation)
    to be executed under the authority of another (the party operating the host
    software). This opens the host party to a variety of "Trojan horse" attacks
    by the provider, or a malicious third party that forges implementations under
    a provider's name. See, for example RFC2046[6], section 4.5.2 for a discussion
    of these risks.
</UL>
<H1>
  12. <A NAME="_Toc404743972">Normative References</A>
</H1>
<DL compact>
  <DT>
    [1]
  <DD>
    D. H. Crocker. <I>"Standard for the Format of ARPA Internet Text Messages"</I>,
    STD 11, <A NAME="RFC822">RFC 822</A>, UDEL, August 1982
  <DT>
    [2]
  <DD>
    T. Berners-Lee, <I>"Universal Resource Identifiers in WWW. A Unifying Syntax
    for the Expression of Names and Addresses of Objects on the Network as used
    in the World-Wide Web"</I>, <A NAME="RFC1630">RFC 1630</A>, CERN, June 1994.
  <DT>
    [3]
  <DD>
    T. Berners-Lee, L. Masinter, M. McCahill. <I>"Uniform Resource Locators
    (URL)"</I> <A NAME="RFC1738">RFC 1738</A>, CERN, Xerox PARC, University of
    Minnesota, December 1994.
  <DT>
    [4]
  <DD>
    R. Fielding, <I>"Relative Uniform Resource Locators"</I>,<A NAME="RFC1808">
    RFC 1808</A>, UC Irvine, June 1995.
  <DT>
    [5]
  <DD>
    T. Berners-Lee, R. Fielding, H. Frystyk, <I>"Hypertext Transfer Protocol
    -- HTTP/1.0"</I>, <A NAME="RFC1945">RFC 1945</A>, W3C/MIT, UC Irvine, W3C/MIT,
    May 1996.
  <DT>
    [6]
  <DD>
    N. Freed, N. Borenstein, <I>"Multipurpose Internet Mail Extensions (MIME)
    Part Two: Media Types"</I>, <A NAME="RFC2046">RFC 2046</A>, Innosoft, First
    Virtual, November 1996.
  <DT>
    [7]
  <DD>
    R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, <I>"Hypertext
    Transfer Protocol -- HTTP/1.1"</I>, <A NAME="RFC2068">RFC 2068</A>, U.C.
    Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
  <DT>
    [8]
  <DD>
    D. Kristol, L. Montulli, <I>"HTTP State Management Mechanism"</I>,
    <A NAME="RFC2109">RFC 2109</A>, Bell Laboratories Lucent Technologies, Netscape
    Communications, February 1997
  <DT>
    [9]
  <DD>
    S. Bradner, <I>"Key words for use in RFCs to Indicate Requirement Levels"</I>,
    <A NAME="RFC2119">RFC 2119</A>, Harvard University, March 1997
  <DT>
    [10]
  <DD>
    J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk, <I>"Use and interpretation
    of HTTP version numbers"</I>, Internet Draft <A NAME="RFC2145">RFC 2145</A>,
    DEC, U.C. Irvine, DEC W3C/MIT, W3C/MIT, HTTP Working Group, May, 1997.
  <DT>
    [11]
  <DD>
    O. Lassila, R. Swick, <I>"</I><A NAME="PICSNG">Resource Description Framework
    (RDF) - Model and Syntax</A>", W3C/Nokia, W3C, W3C Working draft, October
    1997. This is work in progress
  <DT>
    [12]
  <DD>
    H. Schulzrinne, A. Rao, R. Lanphier, <I>"</I><A NAME="RTSP">Real Time Streaming
    Protocol (RTSP)</A>", Internet Draft draft-ietf-mmusic-rtsp-05, Columbia
    U./Netscape/Progressive Networks, March 1997. This is work in progress
  <DT>
    [13]
  <DD>
    T. Berners-Lee, R. Fielding, L. Masinter, <I>"<A NAME="URL">Uniform Resource
    Locators (URL)</A>"</I>, Internet Draft draft-fielding-url-syntax-09, W3C/MIT,
    U.C. Irvine, Xerox Corporation, May 1997. This is work in progress
</DL>
<H1>
  13. <A NAME="_Toc404743973">Bibliography: Informative References</A>
</H1>
<DL compact>
  <DT>
    [14]
  <DD>
    D. Eastlake, <I>"Universal Payment Preamble"</I>, Internet Draft
    draft-eastlake-universal-payment-03, CyberCash, March 1996. This is work
    in progress.
  <DT>
    [15]
  <DD>
    D. M. Kristol, <I>"</I><A NAME="Kristol">A Proposed Extension Mechanism for
    HTTP</A>", Internet Draft draft-kristokl-http-extensions-00, January 1995.
    Document expired.
  <DT>
    [16]
  <DD>
    JEPI, <I>"Selecting Payment Mechanisms Over HTTP"</I>, Internet Draft
    draft-khare-jepi-uppflow-00, W3C, August 1996. Document expired.
  <DT>
    [17]
  <DD>
    J. Miller et al, <I>"PICS Label Syntax and Communication Protocols (Version
    1.1)"</I>, W3C Recommendation REC-PICS-labels, W3C, 31 October 1996
  <DT>
    [18]
  <DD>
    Y. Goland et al, <I>"</I><A NAME="DAV">Extensions for Distributed Authoring
    and Versioning</A>", Internet Draft, draft-jensen-webdav-ext-01, 26 March
    1997. This is work in progress.
  <DT>
    [19]
  <DD>
    N. Borenstein, <I>"A User Agent Configuration Mechanism For Multimedia Mail
    Format Information"</I>, RFC 1524 pp. 12, Bellcore, September 1993.
  <DT>
    [20]
  <DD>
    J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker. <I>"SMTP Service
    Extensions"</I>, RFC 1869, MCI, Innosoft, Dover Beach Consulting, Network
    Management Associates, Brandenburg Consulting, November 1995.
  <DT>
    [21]
  <DD>
    D. Robinson, <I>"The WWW Common Gateway Interface Version 1.1"</I>, Internet
    Draft draft-robinson-www-interface-01, February 1996. Document expired.
  <DT>
    [22]
  <DD>
    A. Baird-Smith, <I>"Jigsaw: An object oriented server"</I>, W3C Note, June
    1996
  <DT>
    [23]
  <DD>
    H. Frystyk, <I>"</I><A NAME="_Ref392578504">Libwww Architecture</A>", December
    1996
  <DT>
    [24]
  <DD>
    R. Thau, <I>"Design considerations for the Apache Server API"</I>, Fifth
    International World Wide Web Conference, May 6-10, 1996, Paris, France
  <DT>
    [25]
  <DD>
    Netscape Corporation, <I>"The Netscape Server API"</I>
  <DT>
    [26]
  <DD>
    Microsoft Corporation, <I>"Internet Server API Documentation"</I>
  <DT>
    [27]
  <DD>
    Open Market, Inc, <I>"FastCGI - Restoring All CGI's Good Properties -- and
    Then Some"</I>
  <DT>
    [28]
  <DD>
    Spyglass, <I>"Spyglass MicroServer Application Development Interface"</I>
  <DT>
    [29]
  <DD>
    J. Franks, <I>"WN - a Server for the HTTP"</I>
  <DT>
    [30]
  <DD>
    Roxen, <I>"Introduction to Roxen Challenger"</I>
</DL>
<H1>
  14. <A NAME="_Toc404743974">Acknowledgements</A>
</H1>
<P>
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[15]. Jim Miller and Dave Raggett sketched out an initial design,
which Rohit Khare wrote up in a number of drafts. Tim Berners-Lee, Anselm
Baird-Smith, Paul Leach and Daniel Dardailler deserve special recognition
for their efforts in commenting in the design phase of the protocol. Also
thanks to Henning Schulzrinne, Anup Rao and Robert Lanphier for pointing
out the generalities of PEP and providing support for integration with RTSP[12].
<P>
This specification is a direct reflection of some implementation work: a
client implementation in [23] (see the HTPEP module) and a server implementation
by Eui-Suk Chung and Anit Chakraborty for the JEPI project.
<P>
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:
<UL>
  <LI>
    Eui-Suk Chung,
  <LI>
    Don Eastlake,
  <LI>
    Roy Fielding,
  <LI>
    Jim Gettys,
  <LI>
    Yaron Goland,
  <LI>
    Phill Hallam-Baker,
  <LI>
    Paul Hoffman,
  <LI>
    Koen Holtman,
  <LI>
    Ora Lassila,
  <LI>
    Larry Masinter, and
  <LI>
    Jim Whitehead
</UL>
<H1>
  15. <A NAME="Authors">Authors Addresses</A>
</H1>
<P>
<A NAME="connolly">Dan Connolly</A><BR>
Architecture Domain Lead, World Wide Web Consortium <BR>
MIT Laboratory for Computer Science <BR>
545 Technology Square <BR>
Cambridge, MA 02139, U.S.A. <BR>
Email: connolly@w3.org
<P>
<A NAME="khare">Rohit Khare</A><BR>
Technical Staff, World Wide Web Consortium <BR>
MIT Laboratory for Computer Science <BR>
545 Technology Square <BR>
Cambridge, MA 02139, U.S.A. <BR>
Email: khare@w3.org
<P>
<A NAME="frystyk">Henrik Frystyk Nielsen</A><BR>
Technical Staff, World Wide Web Consortium <BR>
MIT Laboratory for Computer Science <BR>
545 Technology Square <BR>
Cambridge, MA 02139, U.S.A. <BR>
Email: frystyk@w3.org
<P>
<A NAME="prudhommeaux">Eric Prud'hommeaux </A><BR>
Contractor, World Wide Web Consortium <BR>
MIT Laboratory for Computer Science <BR>
545 Technology Square <BR>
Cambridge, MA 02139, U.S.A. <BR>
Email: eric@w3.org
<H1 align="center">
  Appendices
</H1>
<H1>
  16. <A NAME="_Toc404743976">Summary of PEP Interactions</A>
</H1>
<P>
The following tables summarize the outcome of strength and scope rules in
PEP transactions involving PEP compliant and non-PEP compliant HTTP proxies
and origin servers. The summary is intended as a guide and index to the text,
but is necessarily cryptic and incomplete. This summary should never be used
or referenced separately from the complete PEP specification. The tables
should be read as follows
<DL>
  <DT>
    Standard processing
  <DD>
    The action taken by an ultimate recipient not understanding or ignoring the
    extension (see section 4.2)
  <DT>
    Extended processing
  <DD>
    The action taken by an ultimate recipient understanding and obeying the extension
    (see section 4.2)
  <DT>
    Forward extension
  <DD>
    The action taken by an intermediate party which is not an ultimate recipient
    (see section 9)
  <DT>
    Strip extension
  <DD>
    The action taken by an intermediate party which is the ultimate recipient
    (see section 9)
  <DT>
    420 (Policy Not Fulfilled)
  <DD>
    The response from an ultimate recipient not understanding or not wishing
    to obey the extension (see section 8.1)
  <DT>
    501 (Not Implemented)
  <DD>
    The response from an ultimate recipient not understanding the "<TT>PEP</TT>"
    method or "<TT>PEP-</TT>" method token prefix (see section 6)
</DL>
<P>
<B></B>
<P ALIGN="CENTER">
Table 1: Origin Server
<DIV align="center">
  <CENTER>
    <TABLE BORDER CELLSPACING="0" WIDTH="625">
      <TR>
	<TH WIDTH="21%" VALIGN="TOP">Scope</TH>
	<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">Hop-by-hop</TH>
	<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">End-to-end</TH>
      </TR>
      <TR>
	<TH WIDTH="21%" VALIGN="TOP">Strength</TH>
	<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">PEP not supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
	<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">Extension not supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
	<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">Extension supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
      </TR>
    </TABLE>
  </CENTER>
</DIV>
<P>
<B></B>
<P ALIGN="CENTER">
Table 2: Proxy Server
<DIV align="center">
  <CENTER>
    <TABLE BORDER CELLSPACING="0" WIDTH="626">
      <TR>
	<TH WIDTH="21%" VALIGN="TOP">Scope</TH>
	<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">Hop-by-hop</TH>
	<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">End-to-end</TH>
      </TR>
      <TR>
	<TH WIDTH="21%" VALIGN="TOP">Strength</TH>
	<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
	<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">PEP not supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Strip extension</TD>
	<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
	<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
	<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">Extension not supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Strip extension</TD>
	<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
	<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
	<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
      </TR>
      <TR>
	<TD WIDTH="21%" VALIGN="TOP">Extension supported</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
	<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
      </TR>
    </TABLE>
  </CENTER>
</DIV>
<P>
&nbsp;
<H1>
  17. <A NAME="_Toc404743977">Examples</A>
</H1>
<P>
The following examples show various scenarios using PEP in HTTP/1.1 requests
and responses. Information not essential for illustrating the examples is
left out (referred to as "&#133;")
<H2>
  17.1 <A NAME="_Toc404743978">Client Queries Server for DAV</A>
</H2>
<P>
In this example, the purpose of using PEP in the request is to determine
whether a server understands and supports the Distributed Authoring and
Versioning (DAV) protocol extension [18]. By making the request binding (see
section 7), the client forces the server to process the extension declaration
and obey the extension or report an error.
<PRE>    PEP-GET /some.url HTTP/1.1
    Host: some.host
    PEP: {{map "http://www.w3.org/PEP/DAV"}}

    HTTP/1.1 200 OK
    PEP-Info: {{id "http://www.w3.org/PEP/DAV"} {for "/Henrik" *}}
    ...
</PRE>
<P>
The response shows that the server does understand DAV and that the client
can use it on all resources matching the prefix "<TT>/Henrik</TT>" on that
server. The policy is informational and other factors like access control
may prevent the client from actually using DAV on any of these resources.
<P>
PEP does not distinguish between querying about or using an extension &#150;
the PEP declaration is identical. Whether it in fact is a query may depend
on the request method name and request modifiers.
<H2>
  17.2 <A NAME="_Toc404743979">Client Informs Server about ZipFlate Compression
  Extension</A>
</H2>
<P>
This example shows a client informing a server that it is capable of handling
the zipflate compression extension in a response. By issuing an extension
policy instead of an extension declaration, the client indicates that the
extension is not used in the request.
<PRE>    GET /Index HTTP/1.1
    Host: some.host
    PEP-Info: {{id "http://www.w3.org/PEP/Encoding"}}

    HTTP/1.1 200 OK
    PEP: {{map "http://www.w3.org/PEP/Encoding"}}
    Cache-Control: no-transform
    Vary: *
    ...
</PRE>
<P>
The response shows that the server knows the extension and decides to use
it in the response. It furthermore includes the <TT>no-transform</TT>
<TT>cache-control</TT> directive in order to avoid that proxies add their
own <TT>content-coding</TT> to the message (see section 10.2) and a
<TT>Vary</TT> header field indicating that a cache may not use the response
to reply to a subsequent request without revalidation.
<P>
In this example, the client could have used an extension declaration of strength
"may" instead of an extension policy to achieve the same effect. The request
would not have been affected as the compression applies to message bodies
and not headers. If the request were to include a message body, however,
the difference would be whether the zipflate extension was applied to that
body or not.
<H2>
  17.3 <A NAME="_Toc404743980">Server Uses Content-Digest Extension</A>
</H2>
<P>
This example shows a server applying the Content-Digest extension to a response
message indicating that the client may ignore it. The client has not indicated
whether it supports the extension or even if it supports PEP.
<PRE>    GET /Index HTTP/1.1
    Host: some.host

    HTTP/1.1 200 OK
    PEP: {{map "http://www.w3.org/PEP/Digest" 4-}}
    4-Content-Digest: "a0b1c2d3e4f5g6h7i8j9"
    Cache-Control: max-age=3600
    ...
</PRE>
<P>
The response is fully cachable and does not require revalidation when replying
to subsequent requests.
<H2>
  17.4 <A NAME="_Toc404743981">Server Requires Client to use Payment
  Extension</A>
</H2>
<P>
The last example shows how a server requires a client to use a micro-payment
extension in order to access a resource causing an additional roundtrip using
the 420 (Policy Not Fulfilled) status code (see section 8.1). The first request
does not contain any PEP constructs leading to the error message. A non-PEP
compliant client will treat this as a 400 (Bad Request) status code and will
not be able to fulfill the server's requirement in a second request (see
[7], section 10.4.1)
<PRE>    GET /Index HTTP/1.1
    Host: some.host

    420 Policy Not Fulfilled
    PEP-Info: {{id "http://www.w3.org/PEP/MiniPayment"}
              {params {Price 0.02USD}} {strength must}}

    PEP-GET /Index HTTP/1.1
    Host: some.host
    PEP: {{map "http://www.w3.org/PEP/MiniPayment" 12-}
          {strength must}}
    12-Price: 0.02USD

    HTTP/1.1 200 OK
    ...
</PRE>
<P>
The actual price is passed as an extra parameter in the extension policy.
The client agrees to the price and issues a new request containing the proper
extension declaration. If it did not agree with the price, it could have
tried a lower price and depending on the policy of that resource, the server
may have responded positively.
<P>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">
Copyright</A> &nbsp;&copy;&nbsp; 1998 <A href="http://www.w3.org">W3C</A>
(<A href="http://www.lcs.mit.edu">MIT</A>,
<A href="http://www.inria.fr/">INRIA</A>,
<A href="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer">liability,</A>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks">trademark</A>,
<A href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use </A>and
<A href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing </A>rules apply.
</BODY></HTML>