W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

PEP draft delayed -- diffs so far attached

From: Dan Connolly <connolly@w3.org>
Date: Tue, 11 Mar 1997 00:32:03 -0600
Message-Id: <3324FC63.6488A9AC@w3.org>
To: http-wg@cuckoo.hpl.hp.com
Cc: khare@w3.org
Larry and folks,

Henrik and I expected to have a new draft late last week,
but I'm afraid I have to call it a night tonight before
I have a draft with no FIXME's in it.

What I have so far is at:
http://www.w3.org/pub/WWW/Protocols/PEP/WD-pep
$Id: pep-spec.html,v 1.13 1997/03/11 06:04:21 connolly Exp $

Diffs from the Jan 31 internet draft are attached.

Summary of technical changes:
	- extension header field section axed
	- BINDING- methods and {str req} added
	- C-Protocol-Info added

And we did significant editorial work in the introduction again.
There's also a new table that enumerates a number
of required/optional, end-to-end/hop-by-hop, origin/proxy
combinations.

After I get some sleep and a chance to attack the last
couple of FIXME's, I'll submit a revised draft.

Henrik has also updated and enhanced the background material,
including some work on a scenarios document (whence came
the table above). See:

	http://www.w3.org/pub/WWW/Protocols/PEP/

-- 
Dan Connolly, W3C Architecture Domain Lead
<connolly@w3.org> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

--- /home/connolly/ext/pub/WWW/Protocols/PEP/draft-ietf-http-pep-01.txt	Tue Feb  4 11:21:52 1997
+++ pep-rfc.txt	Tue Mar 11 02:16:11 1997
@@ -5,45 +5,41 @@
 
 
 Network Working Group                                        D. Connolly
-Internet Draft                                             W3 Consortium
-Category: Informational                                     January 1997
+Internet Draft                                                       W3C
+Category: Informational                                       March 1997
 
 
                   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.
+   This is the author's intermedate draft, for review by HTML WG members
+   and the community in general.
 
-   The contribution of W3C staff time to the HTTP workin group is part
+   Please do not distribute copies of this document but rather refer to
+   the released internet drafts and W3C working drafts in stead.
+
+   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 contribution of W3C staff time to the HTTP working group is part
    of the W3C HTTP Activity.
 
+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 PEP 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.
 
+   PEP relies on some HTTP 1.1 features, but is intended to be
+   compatible with all versions of HTTP from 1.1 on.
 
 
 
@@ -55,64 +51,68 @@
 
 
 
-Connolly                     Internet Draft                     [Page 1]
 
 
 
 
+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.
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
 
 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.1. Operational Overview ...................................... 3
+   3. The Protocol Header Field ...................................... 4
+   4. Hop-by-hop Extensions .......................................... 5
+   5. Extension Policy Information ................................... 5
+      5.1. Strength .................................................. 6
+      5.2. Hop-by-hop Policies ....................................... 6
+      5.3. 420: Bad Extensions ....................................... 7
+   6. Extension Encodings ............................................ 7
+   7. Binding Extensions Request ..................................... 8
+   9. Security Considerations ....................................... 10
+   11. Normative References ......................................... 11
+   12. Bibliography: Informative References ......................... 11
 
 2. Introduction
 
+   HTTP is a generic request-response protocol, designed to accomodate a
+   variety of applications, from network information retrieval and
+   searching to file transfer and repository access to query and forms
+   processing.
+
+   HTTP is increasingly used 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:
+
+       * 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 as extended should still be able to work
+         through
+              proxies - especially caching proxies;
+       * That negotiation of matching capabilities should
+              be possible.
+
    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.
+   and extension mechanisms, and the motivation behind them.
 
 
 
@@ -124,228 +124,160 @@
 
 
 
-$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 <a
-      href="#future">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 <a href="#HTML2">[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
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
-         New method names can be added. (@@Cite BROWSE, MKDIR in
-         aolserver)
 
-      header fields
+   2.1. Operational Overview
 
-         New headers may be introduced: entity headers, request headers,
-         or response headers. For example, [STATE]
+      PEP is intended to be used as follows:
 
-      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).
+          * Some party designs and specifies an extension to HTTP; this
+            extension is assigned an identifier which is a URL, and the
+            party makes the specification of the protocol available at
+            that URL.
+          * Extended clients and servers are implemented per the HTTP
+            specification as extended by the extension specification.
+          * Requests and responses declare the use of the extension by
+            reference to its URL.
+          * 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 in stead of the
+            extension.
+
+      Note that, at the cost of some extra bytes to spell out the URL in
+      full, the use of a central registry of extension names is avoided.
+
+      See Considerations for Defining Extensions for full details.
+
+      The PEP mechanism is designed to accomodate extension of clients,
+      servers, and proxies by software components as follows:
+
+          * Clients and servers are implemented with software component
+            interfaces that allow dynamic installation of extension
+            facilities.
+          * An extension is assigned a URL; in addition to a human-
+            readable specification of an extension, a machine-readable
+            implementation or description of the extension is published
+            at that address.
+          * If a message that refers to an extension is received by a
+            party that has no awareness of the extension, the receiver
+            can dereference the extension's identifier and dynamically
+            load support for the extended facility.
 
-3. Extension Identifiers
+   2.2. Strength, Scope and Semantics of Extended Transaction
 
    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.
+      send HTTP messages to each other, with intermediaries between them
+      in some cases. 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
+      The publishing party is basically the one responsible for the
+      service provided at any particular URL, for example, 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.
+      refers.  Exactly who takes this role is beyond the scope this
+      document, but for example, it may be the writer of a document, the
+      server administrator, the organization running the server, or a
 
-   See Considerations for Defining Extensions for details.
+
+
+Connolly                     Internet Draft                     [Page 3]
 
 
 
-Connolly                     Internet Draft                     [Page 4]
 
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
 
+      combination of these.
 
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+      PEP extensions may be used to extend the end-to-end transaction
+      semantics, or, using the Connection header field (see [HTTP]
+      section 14.10 Connection), they may be used to extend the hop-by-
+      hop transaction semantics. See The Protocol Header Field and Hop-
+      by-hop Extensions for details.
 
+      PEP extensions often define inessential, non-binding facilities;
+      that is, the transaction can still succeed even if some parties do
+      not participate in the extension. The distinction between binding
+      and non-binding uses of extensions is syntactically evident in
+      requests and responses. See The Protocol Header Field and Binding
+      Extensions Request for details.
 
-   3.1. The Protocol Header Field
+3. 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.
+   The extensions used in a message are declared using the Protocol
+   request/response header field.  Each protocol extension has an
+   extension identifier, which is a URL[URL].
 
       Along with the extension identifier, an extension may define any
-      number of parameters. See also, Extension Header Fields and
-      Extension Encodings.
+   number of parameters. See also Extension Encodings.
+
+   @@define/explain str
 
       The syntax is:
 
                 Protocol         = "Protocol" ":" 1#extension-decl
                 extension-decl   = "{" extension-id *ext-info "}"
-                ext-info         = params | headers | enc
+             extension-id     = URI
+             ext-info         = str | params | enc
                 params           = "{" "params" *bagitem "}"
-                headers          = "{" "headers" 1*token "}"
+             str              = "{" "str" ("req" | "ref" | "opt" ) "}"
                 enc              = "{" "enc" 1*token "}"
 
                 bag              = "{" bagname 1*LWS *bagitem "}"
                 bagname          = token | URI
                 bagitem          = bag | token | quoted-string
+             URI              = 1*<any char except CTLs or space>
 
-      For example:
+   Note that, since URIs may contain { and } characters, a space is
+   required after the bagname.
 
-         GET /a-document HTTP/1.1
-         Protocol: {http://some.org/an-extension}
+   For example:
 
-         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 (<a href="#HTTP">[HTTP}, section @@).
 
-      The syntax is essentially the same as the Protocol header field.
 
-                C-Protocol       = "C-Protocol" ":" 1#extension-decl
 
 
 
+Connolly                     Internet Draft                     [Page 4]
 
 
 
-Connolly                     Internet Draft                     [Page 5]
 
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
 
+      GET /a-document HTTP/1.1
+      Host: a.host
+      Protocol: {http://some.org/an-extension }
 
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+      HTTP/1.1 200 OK
+      Protocol: {http://some.org/an-extension }
+      Vary: Protocol
+      Content-Type: text/plain
 
+      Glad you're using an-extension!
 
-   3.2. Considerations for Defining Extensions
+   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.
 
-      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.
+4. Hop-by-hop Extensions
 
-   Bootstrapping and Dynamic Loading
+   Extensions declared with the Protocol header field are end-to-end
+   extensions.  Hop-by-hop extensions are declared with the C-Protocol
+   header field, in conjunction with the Connection header (<a
+   href="#HTTP">[HTTP}, section 13.5.1 and 14.10).
 
-      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 syntax is essentially the same as the Protocol header field.
 
-      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.
+             C-Protocol       = "C-Protocol" ":" 1#extension-decl
 
    Caching and Connections
 
@@ -356,7 +288,7 @@
       consideration.  See [HTTP] sections 13.5.1.  (@@more references
       were lost in an editing disaster)
 
-4. Notification
+5. Extension Policy Information
 
    Some extensions are used spontaneously by participating clients; for
    example, a client may be configured to use and extension, or a user
@@ -367,31 +299,34 @@
    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
+   accessed using one or more extensions with the <a href="info-
+   syntax">Protocol-Info entity header 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.
 
 
 
-Connolly                     Internet Draft                     [Page 6]
+
+Connolly                     Internet Draft                     [Page 5]
 
 
 
 
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+$Date: 1997/03/11 06:04:21 $       PEP                        March 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.
+   5.1. Strength
 
-   The strength of the policy for an extension for the resources is one
-   of req, ref, or opt.
+      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.
+         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.
@@ -400,28 +335,27 @@
 
              Protocol-Info    = "Protocol-Info" ":" 1#policy-decl
              policy-decl      = "{" extension-id *policy-info "}"
-             policy-info      = str | params | headers | scope | for
+                policy-info      = str | params | 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:
+      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 <a
+      href="#HTTP">[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
@@ -430,19 +364,48 @@
       <form action="/cgi-bin/buy">
       ...
 
+   5.2. Hop-by-hop Policies
 
+      The C-Protocol-Info header field provides hop-by-hop policies;
+      that is, it allows a server to express policy(ies) to an agent at
 
 
 
-Connolly                     Internet Draft                     [Page 7]
+Connolly                     Internet Draft                     [Page 6]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
 
+      the other end of an HTTP connection, rather than to all parties in
+      an HTTP transaction. Other than scope, its semantics are the same
+      as the Protocol-Info header field; the name is distinct so that
+      the Connection header field can distinguish between hop-by-hop and
+      end-to-end protocol information notifications.
+
+      For example, consider a server whos policy is to access cache
+      usage statistics from clients that connect to it.  In response
+      from a client, it might advertise its policy as follows:
 
+         HTTP/1.1 200 OK
+         C-Protocol-Info: {http://some.org/provide-stats {for / * }}
+         Connection: C-Protocol-Info
+         Content-Type: text/plain
 
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+         some content
 
+      The next time that client makes a request to this server, it may
+      provide statistics as follows:
+
+         GET /some-resource HTTP/1.1
+         Host: some.org
+         C-Protocol: {http://some.org/provide-stats {params {hits 10}}}
+         Connection: C-Protocol
+         Content-Type: text/plain
 
-   4.1. 420: Bad Extensions
+   5.3. 420: Bad Extensions
 
       A server policy may require (or refuse) the use of some extensions
       in some circumstances. If a request fails to fulfill the policy,
@@ -453,89 +416,6 @@
       Implementors may note the similarity to the way authentication
       challenges are issued with the 401 (Unauthorized) status code.
 
-5. Extension Header Fields
-
-   Each HTTP extension that uses the PEP mechanism may define one or
-   more extension header fields.
-
-   Note that params in extension declarations provide the same facility
-   with less complexity, and provide a syntactic structure that closely
-   resembles the semantic structure. This mechanism is redundant, but
-   provided for the case where the use of header fields is essential.
-
-   Each extension header field present in a message is associated with
-   exactly one protocol extension identifier in a Protocol or C-Protocol
-   header field.
-
-   It is an error (400 Bad Request) to include the same header field
-   name in two different extension-decls in the same message, and it is
-   an error if a header field name matches wildcard prefixes in more
-   than one extension-decl.
-
-   Wildcard matching is as follows: A header field name N matches a
-   prefix P-* iff N is the concatenation of Q- and any string S, where P
-   and Q are the same except for differences in the case of letters.
-
-   For example:
-
-      GET /newsletter.html HTTP/1.1
-      Protocol: {http//www.someschool.edu/HTTP/MicroPay {headers micropay} }
-      Micropay: USD $0.003 creds:lw3jlkwj3lkw3ljk
-
-   or using a wildcard prefix:
-
-      GET /newsletter.html HTTP/1.1
-      Protocol: {http//www.someschool.edu/HTTP/MicroPay {headers M-*} }
-      M-micropay: USD $0.003 creds:lw3jlkwj3lkw3ljk
-
-   Header Field Name Collisions
-
-      It is possible that two extensions specify the use of the same
-      header field name. If two such extensions are used in the same
-      message, the name collision must be resolved, either by prefixing
-      or replacing the header names.
-
-
-
-Connolly                     Internet Draft                     [Page 8]
-
-
-
-
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
-
-
-      The header field names in the message can be replaced with
-      arbitrary names; the header fields must be given a distinguished
-      order in the protocol extension definition. This order can be used
-      to associate the replacement names with the original semantics.
-
-      For example, consider extensions E1 and E2. E1 involves headers
-      Tax and Price, and E2 involves Price and Color.
-
-      These might be combined in the same message as:
-
-         Protocol: {E1 {headers price tax}}
-         Price: $2.99
-         Tax: 8.25%
-         Protocol: {E2 {headers AB12-price color }}
-         AB12-Price: $2.99
-         Color: red
-
-      Since the first extension header specified in E2 is Price, the
-      semantics of the AB12-price header are clear.
-
-      Header prefixing is similar; if the name in the protocol extension
-      specification is N, and the distinguishing prefix is P-, then the
-      name used in the message is P-N. For example:
-
-         Protocol: {E1 {headers price tax}}
-         Price: $2.99
-         Tax: 8.25%
-         Protocol: {E2 {headers AB12-*}}
-         AB12-Price: $2.99
-         AB12-Color: red
-
 6. Extension Encodings
 
    Each HTTP extension that uses the PEP mechanism may define one or
@@ -554,21 +434,16 @@
 
 
 
+Connolly                     Internet Draft                     [Page 7]
 
 
 
 
-
-
-Connolly                     Internet Draft                     [Page 9]
-
-
-
-
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
 
       GET /sparse-document HTTP/1.1
+      Host: a.host
       Protocol: {http://some.org/special-encoding {enc special}}
 
       HTTP/1.1 200 OK
@@ -578,37 +453,32 @@
 
       ... sparse data encoded with "special" encoding ...
 
-7. Security Considerations
-
-   The for 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 there is no reasonable way for clients to
-   distinguish between the parties responsible for different resources
-   at the same server, 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.
-
-Future Work
+7. Binding Extensions Request
 
-   Further design and implementation work is necessary to completely
-   meet the requirements for PEP.
+   A request with {str req} in any of its Protocol header fields is a
+   binding extension request -- the request cannot be successfully
+   completed without consulting and adhering to the relavent extension
+   specification(s).
+
+   Because HTTP agents may ignore all protocol header fields, the {str
+   req} is not sufficient to evoke the correct behaviour from HTTP
+   agents.
+
+   The method name of all binding extension request must be prefixed by
+   BINDING-. Legacy HTTP agents (i.e. agents implemented without
+   consulting this specification) should respond with 501 (Not
+   Implemented) (see [HTTP] section 5.1.1, Method).  Other agents must
+   process the request resulting from removing the BINDING- from the
+   method name and leaving the rest of the request (request URI,
+   version, header fields, body) as is.
 
-   Binding Extensions
+   NOTE: All method names beginning with BINDING- are reserved for this
+   use.
 
-      This design does not completely meet the requirement that one
-      party can require another party to participate in an extension. An
-      earlier draft specified a new version number and the use of {str
-      req} in extension-declarations. But this will have no impact on
-      HTTP 1.1 clients and servers, and hence does not meet the
-      requirement.
-
-      One possibility is a change to the syntax of methods in HTTP
-      request for the purpose of expressing binding extensions. For
-      example:
+   For example, a client might express the binding rights-management
+   constraints on its request as follows:
 
-         BINDING PUT /a-resource HTTP/1.2
+      BINDING-PUT /a-resource HTTP/1.2
          Protocol: {http://some.org/rights-management {str req}
             {params {copyright-remains-with-client}
                      {nonexclusive-right-to-redistribute} }
@@ -616,20 +486,116 @@
 
          <!doctype html ...
 
-      Unfortunately, this does not accomodate the case of a binding end-
-      to-end extension that passes through a proxy.
+     Summary Table
 
+      @@explain
 
+            Strength / Scope PEP Summary &nbsp; Hop-by-hop End-to-end
+      Optional Required Optional Required Proxy PEP not spoken
+              HTTP/1.1: strip
+              HTTP/1.0: pass
 
 
 
-Connolly                     Internet Draft                    [Page 10]
+Connolly                     Internet Draft                     [Page 8]
+
+
 
 
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
 
 
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
+              fail
+              pass
+              fail Extension not understood or not invoked
+              strip
+              fail
+              pass
+              pass Extension understood and invoked
+              invoke
+              invoke
+              invoke
+              invoke Origin Server PEP not spoken
+              ignore
+              fail
+              ignore
+              fail Extension not understood or not invoked
+              ignore
+              fail
+              ignore
+              fail Extension understood and invoked
+              invoke
+              invoke
+              invoke
+              invoke
 
+8. 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
+
+
+
+Connolly                     Internet Draft                     [Page 9]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
+
+      clients and servers to be dynamically extended.
+
+9. Security Considerations
+
+       * The for 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 there is no reasonable way
+         for clients to distinguish between the parties responsible for
+         different resources at the same server, 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.
+
+       * 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,
+         section 7.4.2 of <a href="ftp://ftp.isi.edu/in-
+         notes/rfc1521.txt">RFC1521 for a discussion of these risks
+
+Future Work
+
+   The design of some aspects of earlier drafts of this specification
+   are still pending implementation experience.
 
    Mult-Transaction Negotiation
 
@@ -646,13 +612,32 @@
       management "cookies" to disambiguate clients, or the use of an
       analagous PEP-specific mechanism.
 
-8. Appendix: Considerations for the Design of a PEP Software Component
+
+
+
+
+
+
+
+
+
+
+
+Connolly                     Internet Draft                    [Page 10]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
+
+10. Appendix: Considerations for the Design of a PEP Software Component
    Interface
 
    This section got blown away in an editing disaster. The editor will
    attempt to include it in a future draft.
 
-9. Normative References
+11. Normative References
 
    [URL]
 
@@ -664,7 +649,7 @@
       Hypertext Transfer Protocol -- HTTP/1.1. RFC 2068 UC Irvine, DEC,
       DEC, W3C/MIT, W3C/MIT, January 1997
 
-10. Bibliography: Informative References
+12. Bibliography: Informative References
 
    [CGI]
 
@@ -681,19 +666,6 @@
       HREF="http://home.netscape.com/newsref/std/server_api.html">Netscape
       server API documentation, 1995
 
-
-
-
-
-
-Connolly                     Internet Draft                    [Page 11]
-
-
-
-
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
-
-
    [ISAPI]
 
       ISAPI documentation, Microsoft Corporation, in ActiveX Alpha SDK,
@@ -712,6 +684,16 @@
       HREF="http://www.openmarket.com/library/WhitePapers/Server/index.html">OpenMarket
       server technical overview sometime in 1996.
 
+
+
+Connolly                     Internet Draft                    [Page 11]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
+
    [Spy95]
 
       <A
@@ -744,19 +726,6 @@
    [UPP] D. Eastlake, &quot;Universal Payment Preamble&quot;, Internet
       Draft CyberCash,  March 1996 (Work in Progress).
 
-
-
-
-
-
-Connolly                     Internet Draft                    [Page 12]
-
-
-
-
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
-
-
    [JEPI]
       JEPI, &quot;Selecting Payment Mechanisms Over HTTP&quot;, Internet
       Draft,  August 1996 (Work in Progress). [Also available as
@@ -769,8 +738,8 @@
       Brandenburg Consulting, November 1995.
 
    [PICS] J. Miller.  PICS Label Syntax and Communication Protocols
-      (Version 1.1).;  W3C Proposed Recommendation PR-PICS-services , W3
-      Consortium/MIT, August 1996.
+      (Version 1.1).;  W3C Proposed Recommendation PR-PICS-services ,
+      W3C/MIT, August 1996.
 
    [SpyClient]
 
@@ -778,6 +747,16 @@
       HREF="http://www.spyglass.com/techspec/wpapers/sdkintro.html">Spyglass
       Client Software Development Kit
 
+
+
+Connolly                     Internet Draft                    [Page 12]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
+
    [SpyEcom]
 
       <A
@@ -804,49 +783,70 @@
    drafts.
 
    This draft is a direct reflection of some implementation work: a
-   client implementation Henrik Frystyk Nielson et. al. (see the <a
+   client implementation Henrik Frystyk Nielsen et. al. (see the <a
    href="http://www.w3.org/pub/WWW/Library/src/HTPEP.html">HTPEP module
    in libwww) and a server implementation by Eui Suk Chung and Anit
    Chakraborty for the JEPI project.
 
-
-
-
-Connolly                     Internet Draft                    [Page 13]
-
-
-
-
-$Date: 1997/01/31 23:05:32 $       PEP                      January 1997
-
-
    Tim Berners-Lee contributed significantly to the requirements
    section, and Daniel Dardailler provided extensive review ocmments.
 
 Author's Addresses
 
    Dan Connolly
-   Architecture Domain Lead, W3 Consortium
+   Architecture Domain Lead, W3C
    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
+   Technical Staff, W3C
    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 Nielson
-   Technical Staff, W3 Consortium
+   Henrik Frystyk Nielsen
+
+
+
+Connolly                     Internet Draft                    [Page 13]
+
+
+
+
+$Date: 1997/03/11 06:04:21 $       PEP                        March 1997
+
+
+   Technical Staff, W3C
    MIT Laboratory for Computer Science
    545 Technology Square
    Cambridge, MA 02139, U.S.A.
    Tel: +1 (617) 253 8143
    Fax: +1 (617) 258 5999 Email: frystyk@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
Received on Monday, 10 March 1997 22:33:23 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:30 EDT