PEP draft delayed -- diffs so far attached
Dan Connolly (connolly@w3.org)
Tue, 11 Mar 1997 00:32:03 -0600
This is a multi-part message in MIME format.
--------------3A27BB412A731B744F7E0A5B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
--------------3A27BB412A731B744F7E0A5B
Content-Type: text/plain; charset=iso-8859-1; name=",xxx"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename=",xxx"
--- /home/connolly/ext/pub/WWW/Protocols/PEP/draft-ietf-http-pep-01.txt T=
ue 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]=
=0C
=
=
=
+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=3D"#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=3D"#HTML2">[HTML2.0] for example. Since then=
,
- it has been combined with software component technology (such
-
-
-
-Connolly Internet Draft [Page 3]=
-=0C
-
-
-
-$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]=
=0C
+$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 =3D "Protocol" ":" 1#extension-decl
extension-decl =3D "{" extension-id *ext-info "}"
- ext-info =3D params | headers | enc
+ extension-id =3D URI
+ ext-info =3D str | params | enc
params =3D "{" "params" *bagitem "}"
- headers =3D "{" "headers" 1*token "}"
+ str =3D "{" "str" ("req" | "ref" | "opt" ) "}"=
enc =3D "{" "enc" 1*token "}"
=
bag =3D "{" bagname 1*LWS *bagitem "}"
bagname =3D token | URI
bagitem =3D bag | token | quoted-string
+ URI =3D 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=3D"#HTTP">[HTTP}, section @@).
=
- The syntax is essentially the same as the Protocol header field.
=
- C-Protocol =3D "C-Protocol" ":" 1#extension-decl
=
=
=
+Connolly Internet Draft [Page 4]=
=
=
=
-Connolly Internet Draft [Page 5]=
=0C
+$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=3D"#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 =3D "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=3D"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]=
=0C
=
=
=
-$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 =3D "Protocol-Info" ":" 1#policy-decl
policy-decl =3D "{" extension-id *policy-info "}"
- policy-info =3D str | params | headers | scope | for
+ policy-info =3D str | params | for
str =3D "{" "str" ("req" | "ref" | "opt" ) "}"=
- scope =3D "{" "scope" ( "conn" | "origin" ) "}"
for =3D "{" "for" URI [ wildcard ] "}"
wildcard =3D "*"
=
- 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=3D"#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=3D"/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]=
+=0C
+
+
+
+$Date: 1997/03/11 06:04:21 $ PEP March 1997=
=0C
=
+ 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 micropa=
y} }
- 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]=
-=0C
-
-
-
-$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]=
-=0C
-
-
-
-$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 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]=
+=0C
+
=0C
=
+$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]=
+=0C
+
+
+
+$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=3D"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]=
+=0C
+
+
+
+$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=3D"http://home.netscape.com/newsref/std/server_api.html">Nets=
cape
server API documentation, 1995
=
-
-
-
-
-
-Connolly Internet Draft [Page 11]=
-=0C
-
-
-
-$Date: 1997/01/31 23:05:32 $ PEP January 1997=
-
-
[ISAPI]
=
ISAPI documentation, Microsoft Corporation, in ActiveX Alpha SDK,
@@ -712,6 +684,16 @@
HREF=3D"http://www.openmarket.com/library/WhitePapers/Server/index=
=2Ehtml">OpenMarket
server technical overview sometime in 1996.
=
+
+
+Connolly Internet Draft [Page 11]=
+=0C
+
+
+
+$Date: 1997/03/11 06:04:21 $ PEP March 1997=
+
+
[Spy95]
=
<A
@@ -744,19 +726,6 @@
[UPP] D. Eastlake, "Universal Payment Preamble", Internet
Draft CyberCash, March 1996 (Work in Progress).
=
-
-
-
-
-
-Connolly Internet Draft [Page 12]=
-=0C
-
-
-
-$Date: 1997/01/31 23:05:32 $ PEP January 1997=
-
-
[JEPI]
JEPI, "Selecting Payment Mechanisms Over HTTP", 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=3D"http://www.spyglass.com/techspec/wpapers/sdkintro.html">Sp=
yglass
Client Software Development Kit
=
+
+
+Connolly Internet Draft [Page 12]=
+=0C
+
+
+
+$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=3D"http://www.w3.org/pub/WWW/Library/src/HTPEP.html">HTPEP modul=
e
in libwww) and a server implementation by Eui Suk Chung and Anit
Chakraborty for the JEPI project.
=
-
-
-
-Connolly Internet Draft [Page 13]=
-=0C
-
-
-
-$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]=
+=0C
+
+
+
+$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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
=
=
=
--------------3A27BB412A731B744F7E0A5B--