PEP Scenarios

These scenarios show various examples of PEP. The idea of the scenarios is to illustrate different uses of PEP.

1) Client Queries a Server for a Feature

Some extensions are simply based on their availability of the extension and does not require any other interaction. In PEP, a client can ask a server whether an extension is available and a server can inform a client whether it understands an extension or not.

	GET /some.url HTTP/1.1
 	Host: some.host
 	PEP: {{map "http://www.w3.org/PEP/DAV"}}
 
 	HTTP/1.1 200 OK
 	PEP-Info: {{map "http://www.w3.org/PEP/DAV"} {for "/" *}}
 

If the server did not send anything back in the response, this would indicate that the server did not understand the extension or did not wish to use it.

2) Server Informs a Client about a Feature

The server may also query the client about a feature by sending a PEP-Info header back in the response.

	GET /some.url HTTP/1.1
 	Host: some.host
 
 	HTTP/1.1 200 OK
 	PEP-Info: {{map "http://www.w3.org/PEP/DAV"} {for "/" *}}
 

3) Server Requires Payment Extension

In this example, a server will only allow access to a set of resources if the client uses a specific extension, in this example a mini-payment extension with a specific price for this particular resource. The extension does not use any external headers as all the values are passed in the params attribute.

	GET /Index HTTP/1.1
 	Host: some.host
 
 	420 Bad Extensions
 	PEP-Info: {{map "http://www.w3.org/PEP/MiniPayment" Price} {strength must}}
 	Price: 0.02$
 
 	PEP-GET /Index HTTP/1.1
 	Host: some.host
 	PEP: {{map "http://www.w3.org/PEP/MiniPayment" Price} {strength must}}
 	Price: 0.02$
 
 	HTTP/1.1 200 OK
 	...
 

4) Server Informs about Optional Content-Digest Extension

In this example, the server informs the client that it wishes to use the content-digest extension but that the client may ignore it if not supported. The extension has gone through a standard process and have the Content-Digest header defined. In the example, the client decides on using the extension, but again using strength "optional". In the example, the client decides on paying the amount but it could as well have ignored the extension. The reason for using PEP in this scenario at all is that the Content-Digest extension may have been defined independently of HTTP and hence may not be supported by existing HTTP applications. PEP allows the client to dynamically look up a module supporting the extension which can then be dynamically downloaded.

	GET /Index HTTP/1.1
 	Host: some.host
 
 	HTTP/1.1 200 OK
 	PEP-Info: {{map "http://www.w3.org/PEP/Digest" Content-Digest} {for "/" *}}
 	Content-Digest: "abcdefghij"
 

5) Client Requires Message-Signature Extension

In this example, the client requires that the server uses a message signature extension or abort the extension. The extension does not interact with any existing headers.

	PEP-GET /Index HTTP/1.1
 	Host: some.host
 	PEP: {{map "http://www.w3.org/PEP/Signature" Key-Length Key} {strength must}}
         Key-Length: 1024
 
 	HTTP/1.1 200 OK
 	Key: 1234567890...
 	Cache-Control: no-cache
 	...
 

6) Client informs about Compress-Encoding Extension

This example shows the use of an optional extension indicating that the client is capable of handling a special encoding of the message. The extension does not use any external headers as all the values are passed in the params attribute. The server decides to use the encoding and informs the client about the choice.

	GET /Index HTTP/1.1
 	Host: some.host
 	PEP: {{map "http://www.w3.org/PEP/Encoding"} {strength may}}
 
 	HTTP/1.1 200 OK
 	PEP-Info: {{map "http://www.w3.org/PEP/Encoding"} {for "/" *}}}
 

7) A Repeated Hop-by-Hop Example

MORE

8) Changing to a New Protocol

MORE