INTERNET-DRAFT The ICAP Protocol Group Expires: Aug 2001 ICAP the Internet Content Adaptation Protocol draft-elson-opes-icap-01.txt Elson Jeremy STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Abstract ICAP, the Internet Content Adaptation Protocol, is part of an evolving architecture that facilitates better distribution and caching for the web. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. That is, it allows ICAP clients to pass HTTP messages to ICAP servers for "adaptation" -- some sort of transformation or other processing. The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. The adapted messages may be either HTTP requests or HTTP responses. ICAP is often used in a situation where either a separate HTTP proxy server or a programmable network device could serve as an alternative solution. Therefore, ICAP should evolve in a direction of simplicity, allowing pipelined transfers and reduced communications costs, compared to a proxy server. ICAP should also evolve in an open, scalable direction, so that ICAP services can be invoked from many types of proxied protocols, such as HTTP, FTP, NNTP, and SMTP. ICAP Protocol Group Expiration: Aug 2001 [Page 1] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 TABLE OF CONTENTS 1 Introduction 2 Terminology 3 Architecture Overview and Future Work 4 ICAP Overall Operation 4.1 Request Modification 4.2 Response Modification 5 Protocol Semantics 5.1 General Operation 5.2 ICAP URIs 5.3 ICAP Headers 5.3.1 Headers Common to Requests and Responses 5.3.2 Request Headers 5.3.3 Response Headers 5.4 ICAP Bodies: Encapsulation of HTTP Messages 5.4.1 Expected Encapsulated Sections 5.4.2 Encapsulated HTTP Headers 5.5 Message Preview 5.6 "204 No Content" Responses outside of Previews 5.7 Request Modification Mode 5.7.1 Request 5.7.2 Response 5.7.3 Examples 5.8 Response Modification Mode 5.8.1 Request 5.8.2 Response 5.8.3 Examples 5.9 OPTIONS Method 6 Caching 7 Implementation Notes 7.1 Vectoring Points 7.2 Application Level Errors 7.3 Use of Chunked Transfer-Encoding 7.4 Distinct URIs for Distinct Services 8 Security Considerations 8.1 Authentication 8.2 Encryption 8.3 Service Validation 9 References 10 Contact Information and Authors' Addresses ICAP Protocol Group Expiration: Aug 2001 [Page 2] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 1 Introduction As the Internet has grown larger, so has the need for scalable Internet services. Popular web servers are asked to deliver content to millions of users connected at ever-increasing bandwidths. The model of centralized, monolithic servers that are responsible for all aspects of every client's request seems to be reaching the end of its useful life. The old school has become a victim of its own overwhelming success. To keep pace with the growth in the number of clients, there has been a move towards architectures that scale better through the use of replication, distribution, and caching. On the content provider side, replication and load-balancing techniques allow the burden of client requests to be spread out over a farm of servers. Content providers have also begun to employ geographically diverse content distribution networks that bring servers closer to the "edge" of the network where clients are attached. On the other side of the coin, client network providers often employ caches so that local copies of popular objects can be served instead of repeatedly making the same request of an origin server. ICAP, the Internet Content Adaptation Protocol, is part of an evolving architecture that facilitates better distribution and caching for the web. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. That is, it allows ICAP clients to pass HTTP messages to ICAP servers for "adaptation" -- some sort of transformation or other processing. The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. The adapted messages may be either HTTP requests or HTTP responses. 2 Terminology 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 [2]. The special terminology used in this document is defined below. The majority of these terms are taken as-is from HTTP/1.1 [4] and are reproduced here for reference. A thorough understanding of HTTP/1.1 is assumed on the part of the reader. connection: A transport layer virtual circuit established between two programs for the purpose of communication. message: The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 of HTTP/1.1 [4] and transmitted via the connection. request: An HTTP request message, as defined in section 5 of HTTP/1.1 [4]. ICAP Protocol Group Expiration: Aug 2001 [Page 3] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 response: An HTTP response message, as defined in section 6 of HTTP/1.1 [4]. resource: A network data object or service that can be identified by a URI, as defined in section 3.2 of HTTP/1.1 [4]. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. client: A program that establishes connections for the purpose of sending requests. server: An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. origin server: The server on which a given resource resides or is to be created. proxy: An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. cache: A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. cachable: A response is cachable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cachability of HTTP responses are defined in section 13 of [4]. Even if a resource is cachable, there may be additional constraints on whether a cache can use the cached copy for a particular request. New definitions: ICAP resource: Similar to an HTTP resource as described above, but the URI refers to an ICAP service that performs adaptations of HTTP messages. ICAP Protocol Group Expiration: Aug 2001 [Page 4] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP server: Similar to an HTTP server as described above, except that the application services ICAP requests. ICAP client: A program that establishes connections to ICAP servers for the purpose of sending requests. An ICAP client is often, but not always, a proxy-cache acting on behalf of a user. 3 Architecture Overview and Future Work This protocol is one piece of a larger architecture we envision that will enhance scalability of web services by facilitating better distribution and caching. The key to this architecture is a lightweight "remote procedure call" that operates on HTTP messages. That is, we define a method for ICAP clients to pass HTTP messages to ICAP servers for transformation or other processing. The adapted messages may be HTTP requests or HTTP responses. This type of RPC is useful in a number of ways. For example, it might be used to help scale Internet services, as described below. Second, it creates a standard interface for adaptation of HTTP messages, allowing interoperability. The examples we will describe are representative, but by no means comprehensive. o Simple transformations of content can be performed near the edge of the network instead of requiring an updated copy of an object from an origin server. For example, a content provider might want to provide a popular web page with a different advertisement every time the page is viewed. Currently, content providers implement this policy by marking such pages as non-cachable. This imposes additional load on the origin server and the network. In our architecture, the page could be cached once near the edges of the network. These edge caches can then use an ICAP call to a nearby ad-insertion server every time the page is served to a client. Other such transformations by edge servers are possible, either with cooperation from the content provider (as in a content distribution network), or as a value-added service provided by a client's network provider (as in a proxy cache). Examples of these kinds of transformations are translation of web pages to different human languages or to different formats that are appropriate for special physical devices (e.g., PDA-based or cell-phone-based browsers). o Proxy caches or origin servers can avoid performing expensive operations by shipping the work off to other servers instead. This helps distribute load across multiple machines. For example, if a user attempts to download an executable program, a proxy cache, acting as an ICAP client, can ask an external server to check it for viruses before accepting the object into its cache. ICAP Protocol Group Expiration: Aug 2001 [Page 5] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 o Firewalls or proxy caches can act as ICAP clients and send outgoing requests to a service that checks to make sure the URI in the request is allowed (for example, in a system that allows parental control of web content viewed by children). In this case, it is a *request* that is being adapted, not an object returned by a response. In all of these examples, ICAP is helping to reduce the load on the network, origin servers, or both. In some cases, ICAP facilitates transformations near the edge of the network, allowing greater cachability of the underlying content. In other examples, devices such as origin servers or proxy caches are able to reduce their load by distributing expensive operations onto other machines. In all cases, ICAP has also created a standard interface for content adaptation to allow greater flexibility in content distribution or the addition of value added services in proxy caches. There are two major components in our architecture: 1. Transaction semantics -- "How do I ask for adaptation?" 2. Control of policy -- "When am I supposed to ask for adaptation, what kind of adaptation do I ask for, and from where?" Currently, ICAP defines only the transaction semantics. For example, this document specifies how to send an HTTP message from an ICAP client to an ICAP server, specify the URI of the ICAP resource requested along with other resource-specific parameters, and receive the adapted message. Although a necessary building-block, the wire-protocol defined by ICAP is of limited use without the second part: an accompanying application framework in which it operates. The more difficult policy issue is beyond the scope of the current ICAP protocol, but is planned in future work. In initial implementations, we expect that implementation-specific manual configuration will be used to define policy. This includes the trust relationships between ICAP clients and servers, rules for recognizing messages that require adaptation, the URIs of available adaptation resources, and so on. For ICAP clients and servers to interoperate, the exact method used to define policy need not be consistent across implementations, as long as the policy itself is consistent. Once the full extent of the typical policy decisions are more fully understood through experience with these initial implementations, later follow-ons to this architecture may define an additional policy control protocol. This future protocol will allow a standard policy definition interface complementary to the ICAP transaction interface defined here. 4 ICAP Overall Operation ICAP Protocol Group Expiration: Aug 2001 [Page 6] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP facilitates adaptation of HTTP messages. An adapted message may either be an HTTP request or an HTTP response. These two methods will be described below. 4.1 Request Modification In "request modification" (reqmod) method, an ICAP client sends an HTTP request to an ICAP server. In general, the ICAP server may either: 1) Send back a modified version of the request. (The ICAP client may then pipeline the modified request to another ICAP server for further modification, or perform the modified request by contacting an origin server.) 2) If there is an error, the ICAP server may choose to send back an HTTP response to this request. This is often information useful to the user (i.e. "you are not allowed to view that page"). ICAP clients MUST be able to handle both types of responses. In case (2), no further processing should be done on the request; e.g., if a chain of reqmod servers is being used to perform successive modifications on the request, the request MUST NOT not be further propagated after an error response is received. We will illustrate this method with a example: content filtering. A proxy cache receives a request from a client for a web page from an origin server. The proxy cache, acting as an ICAP client, sends the client's request to an ICAP server that performs URI-based content filtering. If access to the requested URI is allowed, the request is returned to the ICAP client unmodified. However, if the ICAP server chooses to disallow access to the requested resources, it may either 1) Modify the request so that it points to a page containing an error message instead of the original URI. 2) Return an encapsulated HTTP response that indicates an HTTP error. This method can be used for a variety of other applications; for example, anonymization, modification of the Accept: headers to handle special device requirements, and so forth. ICAP Protocol Group Expiration: Aug 2001 [Page 7] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 Typical data flow: origin-server | /|\ | | 5 | | 4 | | \|/ | 2 ICAP-client --------------> ICAP-resource (proxy-cache) <-------------- on ICAP-server | /|\ 3 | | 6 | | 1 | | \|/ | client 1. A client makes a request to a ICAP-capable proxy cache (ICAP client) for an object on an origin server. 2. The proxy cache sends the request to the ICAP server. 3. The ICAP server executes the ICAP resource's service on the request and sends the possibly modified request, or a response to the request back to the ICAP client. If Step 3 returned a request: 4. The Proxy cache sends the request, possibly different from original client request, to the origin server. 5. The origin server responds to request. 6. The proxy cache sends the reply (from either the ICAP server or the origin server) to the client. 4.2 Response Modification Using the "response modification" method, an ICAP client sends an HTTP response to an ICAP server. The ICAP server modifies this response and sends it back to the ICAP client. Note that unlike in the previous method, which sends HTTP requests, this method sends an HTTP *response* for modification. That response often comes from an origin server. Response modification method is intended for post-processing performed on an HTTP response before it is delivered to a client. Examples include formatting HTML for display on special devices, human language translation, virus checking, and so forth. ICAP Protocol Group Expiration: Aug 2001 [Page 8] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 Typical data flow: origin-server | /|\ | | 3 | | 2 | | \|/ | 4 ICAP-client --------------> ICAP-resource (proxy-cache) <-------------- on ICAP-server | /|\ 5 | | 6 | | 1 | | \|/ | client 1. A client makes a request to a ICAP-capable proxy cache (ICAP client) for an object on an origin server. 2. The proxy cache sends the request to the origin server. 3. The origin server responds to request. 4. The ICAP-capable proxy cache sends the origin server's reply to the ICAP server. 5. The ICAP server executes the ICAP resource's service on the origin server's reply and sends the possibly modified reply back to the ICAP client. 6. The proxy cache sends the reply, possibly modified from the original origin server's reply, to the client. 5 Protocol Semantics 5.1 General Operation ICAP is a request/response protocol similar in semantics and usage to HTTP/1.1 [4]. Despite the similarity, ICAP is not HTTP, nor is it an application protocol that runs over HTTP. This means, for example, that ICAP messages can not be forwarded by HTTP proxies. ICAP communication usually takes place over TCP/IP connections. The default port is 1344, but other ports may be used. The TCP flow is initiated by the ICAP client to a passively listening ICAP server. ICAP messages consist of requests from client to server and responses from server to client. Requests and responses use the generic message format of RFC 822 [3] -- that is, a start-line (either a request line or a status line), a number of header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and a message-body. ICAP Protocol Group Expiration: Aug 2001 [Page 9] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 The header lines of an ICAP message specify the ICAP resource being requested as well as other meta-data such as cache control information. The message body of an ICAP request contains the (encapsulated) HTTP messages that are being modified. All ICAP messages MUST be transmitted using the "chunked" transfer-coding described in Section 3.6.1 of [4]. The "Transfer-encoding: chunked" header MUST NOT appear in ICAP headers; it is assumed. Chunking is mandatory for three reasons. First, efficiency is important, and the chunked encoding allows both the client and server to keep the transport-layer connection open for later reuse. Second, developers of ICAP servers should be rewarded for producing "incremental" responses, because low latency is critical to the success of ICAP. Chunked encoding is the only way to support this type of efficient implementation. And thirdly, by standardizing on a single encapsulation mechanism, we avoid the complexity that would be required in client and server software to support multiple mechanisms. This simplifies ICAP, and it especially simplifies the "body preview" feature that is described in Section 5.5 5.2 ICAP URIs All ICAP requests specify the ICAP resource being requested from the server using an ICAP URI. This MUST be an absolute URI that specifies both the complete hostname and the path of the resource being requested. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [1], Section 3. The URI structure defined by ICAP is roughly: icap_URI = scheme ":" net_path [ "?" query ] scheme = "icap" net_path = "//" authority [ abs_path ] authority = [ userinfo @ ] [ ":" ] ICAP adds the new scheme "icap" to the ones defined in RFC 2396. If the port is empty or not given, port 1344 is assumed. There is no such thing as an "abs_path" in an ICAP URI. An example ICAP URI line might look like this: icap://icap.example.net:2000/services/icap-service-1 An ICAP server MUST be able to recognize all of its server names, including any aliases, local variations, and numeric IP addresses of its interfaces. Any arguments that an ICAP client wishes to pass to an ICAP service to modify the nature of the service MAY be passed as part of the ICAP-URI, ICAP Protocol Group Expiration: Aug 2001 [Page 10] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 using the standard "?"-encoding of attribute-value pairs used in HTTP. For example: icap://icap.net/service?mode=translate&lang=french 5.3 ICAP Headers 5.3.1 Headers Common to Requests and Responses The headers of all ICAP messages MAY include the following directives, defined in ICAP the same as they are in HTTP: Cache-Control Connection Date Pragma Trailer Upgrade Via Note in particular that the "Transfer-Encoding" option is not allowed. All ICAP messages MUST use the "chunked" transfer-encoding. The Via header MUST be treated the same as in standard HTTP. ICAP clients and servers should modify Via as an HTTP proxy would, with respect to the HTTP message being encapsulated. The Via header added by an ICAP server should specify protocol as ICAP/1.0. The Upgrade header MAY be used to negotiate Transport-Layer Security on an ICAP connection, exactly as described for HTTP/1.1 in [4]. The ICAP-specific headers defined are: Encapsulated (See Section 5.4) Note that, in most applications, it is useful for ICAP clients acting in their HTTP client roles to add ICAP headers to HTTP requests. This notifies the HTTP origin server that it is speaking with a client that is ICAP-enabled. Origin servers can use this header to determine that the client is ICAP-enabled, and modify its response accordingly. For example, an origin server may choose not to insert an advertisement into a page if it knows that a downstream ICAP server can insert the ad instead. The additional headers in an HTTP (not ICAP) connection to an origin server that are needed to support this type of decision are application specific and beyond the scope of this document. However, such headers (if used) SHOULD start with "X-ICAP". Applications SHOULD include an "X-ICAP-Version: 1.0" header along with their application-specific headers. ICAP Protocol Group Expiration: Aug 2001 [Page 11] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 5.3.2 Request Headers Similar to HTTP, ICAP requests MUST start with a request line that contains a method, the complete URI of the ICAP resource being requested, and an ICAP version string. This version of ICAP defines three methods: REQMOD - for Request Modification (Section 5.7) RESPMOD - for Response Modification (Section 5.8) OPTIONS - to learn about configuration (Section 5.9) The current version number of ICAP is 1.0. A well-formed ICAP request line therefore will look similar to the following example: REQMOD icap://icap.example.net/icap?mode=foo ICAP/1.0 A number of request-specific headers are allowed in ICAP requests, following the same semantics as the corresponding HTTP request headers (Section 5.3 of [4]). These are: Authorization Allow (see Section 5.6) From (see Section 14.22 of [4]) Host (REQUIRED in ICAP as it is in HTTP/1.1) Referer (see Section 14.36 of [4]) User-Agent In addition to HTTP-like headers, there are also request headers unique to ICAP defined: Preview (see Section 5.5) 5.3.3 Response Headers ICAP responses MUST start with an ICAP status line, similar in form to that used by HTTP, including the ICAP version and a status code. For example: ICAP/1.0 200 OK Semantics of ICAP status codes in ICAP match the status codes defined by HTTP (Section 6.1.1 and 10 of [4]), except where otherwise indicated in this document; n.b. 100 (Section 5.5) and 204 (Section 5.6). ICAP error codes that differ from their HTTP counterparts are: 100 - Continue after ICAP Preview (Section 5.5). 204 - No modifications needed (Section 5.6). 400 - Bad request; malformed REQMOD, or RESPMOD or OPTIONS. ICAP Protocol Group Expiration: Aug 2001 [Page 12] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 404 - ICAP Service not found. 405 - Method not allowed for service (e.g. RESPMOD requested for service that supports only REQMOD). 408 - Request timeout; if server detects a dead ICAP client. 500 - Server error. Error on the ICAP server, such as "out of disk space". 501 - Not implemented. REQMOD, or RESPMOD or OPTIONS is not implemented. 502 - Bad Gateway. This is an ICAP proxy and proxying produced an error. 503 - Service overloaded. The ICAP server has exceeded a maximum Connection limit associated with this service; the ICAP client should not exceed this limit in the future. 505 - ICAP version not supported by server. 550 - Configuration stale; client should refetch OPTIONS. As in HTTP, the 4xx class of error codes indicate client errors, and the 5xx class indicate server errors. 5.4 ICAP Bodies: Encapsulation of HTTP Messages The ICAP encapsulation model is a lightweight means of packaging any number of HTTP message sections into an encapsulating ICAP message-body, in order to allow the vectoring of requests, responses, and request/response pairs to an ICAP server. This is accomplished by concatenating interesting message parts (encapsulated sections) into a single ICAP message-body (the encapsulating message), and noting the offset of each section's start (relative to the start of the encapsulating message's body) in the encapsulating message's headers. The Encapsulated header takes the following form: reqmod_encapsulated = "Encapsulated" ":" [ "req-hdr" = (integer)] [ "req-body" = (integer)] respmod_encapsulated = "Encapsulated" ":" [ "req-hdr" = (integer)] [ "res-hdr" = (integer) ] [ "res-body" = (integer)] If an encapsulated section is not included, it is simply omitted from the Encapsulated header. The order in which the encapsulated parts appear in the message MUST be the same as the order in which the parts are named in the Encapsulated ICAP Protocol Group Expiration: Aug 2001 [Page 13] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 header. In other words, the offsets listed in the Encapsulated line MUST be monotonically increasing. The grammar ensures that all encapsulated headers will come before the encapsulated body. It also explicitly defines a certain ordering for the different components of the message and allows for just one body in the message. Encapsulated MUST be included in every encapsulating message. For example, Encapsulated: req-hdr=0 res-hdr=45 res-body=100 indicates that this message encapsulates a group of request headers, a group of response headers, and then a response body. Each of these is included at the byte-offsets listed. The encapsulated headers MUST be terminated by a blank line, in order to make them human readable, and in order to terminate line-by-line HTTP parsers. 5.4.1 Expected Encapsulated Sections The chart below summarizes the Encapsulated header formats which SHOULD be used with each ICAP method's request and response encapsulating messages. Request Modification request: req-hdr=n req-body=n response: req-hdr=n req-body=n [ For modifying the request ] response: res-hdr=n res-body=n [ For returning an error ] Response Modification request: req-hdr=n res-hdr=n res-body=n response: res-hdr=n res-body=n 5.4.2 Encapsulated HTTP Headers By default, ICAP messages may encapsulate HTTP message headers and entity bodies. HTTP headers MUST start with the request-line or status-line for requests and responses, respectively, followed by interesting HTTP headers. HTTP/1.1 makes a distinction between end-to-end headers and hop-by-hop headers (see Section 13.5.1 of [4]). End-to-end headers are meaningful to the ultimate recipient of a message, whereas hop-by-hop headers are meaningful only for a single transport-layer connection. Hop-by-hop headers include Connection, Keep-Alive, and so forth. All end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop headers MUST NOT be encapsulated. Despite the above restrictions on encapsulation, the hop-by-hop Proxy-Authenticate and Proxy-Authorization headers that MUST be forwarded to the ICAP server in the ICAP header section (not the encapsulated message). This allows propagation of client credentials ICAP Protocol Group Expiration: Aug 2001 [Page 14] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 that might have been sent to the ICAP client in cases where the ICAP client is also an HTTP proxy. Note that this does not contradict HTTP/1.1, which explicitly states "A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." (Section 14.34). 5.5 Message Preview ICAP requests may include a "preview", allowing the ICAP server to opt-out of a transaction early, before the entire request has been transmitted. This general mechanism can be used to build complex filters, as described in the following examples. - When a file is checked for viruses, a large fraction of all files can be certified as "clean" just by looking at the file type, file name extension, and the first 2K bytes of the file. - In a content filtering system, it is not enough to just look at the HTTP file type in order to determine if a text file should be filtered. The magic numbers (at the front of the file) MUST also be inspected, to determine if the text is actually a JPEG or GIF file. - If an ICAP server wanted to transcode all GIF87 files into GIF89 files, then the GIF87 files could quickly be detected by looking at the first few body bytes of the file. - If an ICAP server wanted to force all cacheable files to expire in 24 hours or less, then this could be implemented by selecting HTTP messages with expiries more than 24 hours in the future. An ICAP client MAY choose to send the beginning of its request, then stop and wait for an intermediate response from the ICAP server before continuing. (This mechanism is similar to the "100-Continue" feature found in HTTP, except that the stop-and-wait point can be within the message body. In HTTP, that point must be the boundary between the headers and body.) To effect a message preview, the ICAP client MUST add a "Preview:" header to its request headers indicating the length of the preview. For example: Preview: 0 This indicates that the ICAP client will send only the header sections to the ICAP server, then it will send a zero-length chunk and stop and wait for a "go ahead" to send more body bytes to the ICAP server. Similarly, the ICAP header: Preview: 4096 Indicates that the ICAP client will attempt to send 4096 bytes of origin server data, but the actual transfer may be less, because the ICAP client is acting like a proxy and is not looking ahead to find the total ICAP Protocol Group Expiration: Aug 2001 [Page 15] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 length of the origin server response. The entire ICAP header section will be sent, followed by up to 4096 bytes of encapsulated HTTP body. The chunk terminator "0\r\n" is always included in these transactions. After sending the preview, the ICAP client will wait for a response from the ICAP server. The response MUST be one of: - 100 Continue. The ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview. Note that, even if the entire message is sent across during the preview phase, the ICAP server MUST still send "100 Continue" before it responds with a modified result. - 204 No Content. The ICAP server does not want to (or can not) modify the ICAP client's request. The ICAP client MUST treat this the same as if it had sent the entire message to the ICAP server and an identical message was returned. A design goal of ICAP preview is to allow an "EOF" indication to "stick" to the N previewed bytes, and for the EOF to be known by the ICAP server. Thus, if an origin server responds with zero bytes, an "EOF" indicator will appear at the ICAP server during preview. If the preview is 1024 bytes, and exactly 1024 bytes are available, then an EOF indication will also be sent. It is especially important for EOF to appear in a zero-length preview, because then only a single round trip is needed to modify header-only HTTP responses. In general, this problem is solved by always "marking" the terminal chunk as containing "EOF". We define an HTTP "chunk-extension" of "ieof" to indicate that an icap chunk is the last chunk (see rfc2616). The ICAP server MUST strip this chunk extension before passing the chunk data to an ICAP application process. Thus, a zero-byte preview for a zero-byte origin response would appear as follows: \r\n 0; ieof\r\n If the ICAP server sees this preview, then it can respond with "100 Continue" and the modified response right away. The ICAP client will not send any more chunk data, because the eof has been sent. If the origin response is 1 byte or larger the "ieof" would not appear. If the preview is 1024 bytes and the origin response is 1024 bytes in two chunks, then the encapsulation would appear as follows: 100\r\n <512 bytes of data>\r\n 100\r\n <512 bytes of data>\r\n 0; ieof\r\n If the preview is 1024 bytes and the origin response is 1025 bytes (and the ICAP server responds with 100-continue), then these chunks would appear on the wire. ICAP Protocol Group Expiration: Aug 2001 [Page 16] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 100\r\n <512 bytes of data>\r\n 100\r\n <512 bytes of data>\r\n 0\r\n 100 Continue 1\r\n <1 byte of data>\r\n 0; ieof\r\n Once the ICAP server receives the eof indicator, it finishes reading the current chunk stream, and both sides send no more data after a 100 Continue response. For preview to be useful, all ICAP clients MUST implement a minimum level of preview. Therefore, each ICAP client MUST support a preview of at least 4096 bytes. The size of a preview is a configurable item associated with a particular ICAP application. When offering a Preview, the ICAP client is committed to cache the portion of the message that was previewed so that it can honor a "204 No Content" response. (The remainder of the message is not necessarily cached; it might be pipelined from another source.) 5.6 "204 No Content" Responses outside of Previews An ICAP client MAY choose to honor "204 No Content" responses for an entire message. This is the decision of the client because it imposes a burden on the client of buffering the entire message. An ICAP client MAY include "Allow: 204" in its request headers, indicating that the server MAY reply to the message with a "204 No Content" response if the object does not need modification. If an ICAP server receives a request that does not have "Allow: 204", it MUST NOT reply with a 204 (except in the case of a message preview, as described in the previous section.) In this case an ICAP server MUST return the entire message back to the client, even though it is identical to the message it received. 5.7 Request Modification Mode In this method, described in Section 4.1, an ICAP client sends an HTTP request to an ICAP server. The ICAP server either sends a modified version of the request back to the ICAP client, a valid HTTP response, or (if the client indicates it supports 204 responses) an indication that no modification is required. ICAP Protocol Group Expiration: Aug 2001 [Page 17] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 5.7.1 Request For Request Modification, the ICAP request encapsulates an HTTP request that MUST be identical to the HTTP request for which the ICAP client is requesting modification, except that hop-by-hop headers are not encapsulated. 5.7.2 Response The response from the ICAP server back to the ICAP client may take one of four forms: -- An error indication, -- A 204 indicating that the ICAP client's request requires no adaptation (if and only if the client indicates that it supports 204 responses as described in Section 5.6). -- An encapsulated, adapted version of the ICAP client's request -- An encapsulated HTTP error response. Note that Request Modification requests may only be satisfied with HTTP responses in cases when the HTTP response is an error (e.g. 403 Forbidden). The first line of the response message MUST be a status line as described in Section 5.3.3. If the return code is a 2XX, the ICAP client SHOULD continue its normal execution of the request. If the ICAP client is a proxy cache, this may include serving an object from its cache or forwarding the modified request to an origin server. For other return codes that indicate an error, the proxy SHOULD return these directly to downstream client. The modified request headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 5.4. 5.7.3 Examples Consider the following example, in which a proxy cache receives a simple GET request from a client. The proxy cache, acting as an ICAP client, then forwards this request to an ICAP server for modification. The ICAP server modifies the request headers and sends them back to the ICAP client. Our hypothetical ICAP server will modify several headers and strip the cookie from the original request. In all of our examples, we include the extra meta-data added to the message due to chunking. We assume that each line is terminated by a single control-character. Note that chunking MUST NOT break header sets into multiple chunks. ICAP Protocol Group Expiration: Aug 2001 [Page 18] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP Request Modification Example 1 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0 GET / HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain Accept-Encoding: compress Cookie: ff39fk3jur@4ii0e02i If-None-Match: "xyzzy", "r2d2xxxx" ---------------------------------------------------------------- ICAP Request Modification Example 1 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close Encapsulated: req-hdr=0 GET /modified-path HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress" If-None-Match: "xyzzy", r2d2xxxx" ---------------------------------------------------------------- The second example is similar to the first, except that the request being modified in this case is a POST instead of a GET. Note that the encapsulated Content-Length argument has been modified to reflect the modified body of the POST message. The outer ICAP message does not need a Content-Length header because it uses chunking (not shown). In this second example, the Encapsulated header shows the division between the forwarded header and forwarded body, for both the request and the response. ICAP Protocol Group Expiration: Aug 2001 [Page 19] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP Request Modification Example 2 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0, req-body=138 POST /origin-resource/form.pl HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain Accept-Encoding: compress Pragma: no-cache 1f I am posting this information. 0 ---------------------------------------------------------------- ICAP Request Modification Example 2 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close Encapsulated: req-hdr=0, req-body=173 POST /origin-resource/form.pl HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress Pragma: no-cache Content-Length: 45 2e I am posting this information. ICAP powered! 0 ---------------------------------------------------------------- Finally, this third example shows an ICAP server returning an error response when it receives a Request Modification request. ICAP Protocol Group Expiration: Aug 2001 [Page 20] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP Request Modification Example 3 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/content-filter ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0 GET /naughty-content HTTP/1.1 Host: www.naughty-site.com Accept: text/html, text/plain Accept-Encoding: compress ---------------------------------------------------------------- ICAP Request Modification Example 3 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close Encapsulated: res-hdr=0, res-body=200 HTTP/1.1 403 Forbidden Date: Wed, 08 Nov 2000 16:02:10 GMT Server: Apache/1.3.12 (Unix) Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT ETag: "63600-1989-3a017169" Content-Length: 62 Content-Type: text/html 3b Sorry, you are not allowed to access that naughty content. 0 ---------------------------------------------------------------- 5.8 Response Modification Mode In this method, described in Section 4.3, an ICAP client sends an origin server's HTTP response to an ICAP server, and (if available) the original client request that caused that response. Similar to Request Modification method, the response from the ICAP server can be an adapted HTTP response, an error, or a 204 response code indicating that no adaptation is required. The adapted message or error indication returned by the ICAP server SHOULD be forwarded to the client or otherwise passed to the next downstream entity (e.g. another ICAP server). 5.8.1 Request Using encapsulation described in Section 5.4, the header and body of the HTTP response to be modified MUST be included in the ICAP body. If available, the header and body of the original client request SHOULD ICAP Protocol Group Expiration: Aug 2001 [Page 21] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 also be included. As with the other method, the hop-by-hop headers of the encapsulated messages MUST NOT be forwarded. The Encapsulated header MUST indicate the byte-offsets of the beginning of each of these four parts. 5.8.2 Response The response from the ICAP server looks just like a reply in the Request Modification method (Section 5.7); that is, -- An error indication, -- An encapsulated and potentially modified HTTP response header and response body, or -- An HTTP response 204 indicating that the ICAP client's request requires no adaptation. The ICAP client MAY re-examine the headers in the response's message headers in order to make further decisions about the response (e.g. its cachability). 5.8.3 Examples In Example 4, an ICAP client is requesting modification of an entity that was returned as a result of a client GET. The original client GET was to an origin server at "www.origin-server.com"; the ICAP server is at "icap.example.org". Note that chunking MUST NOT break header sets into multiple chunks. ICAP Protocol Group Expiration: Aug 2001 [Page 22] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 ICAP Response Modification Example 4 - ICAP Request ---------------------------------------------------------------- RESPMOD icap://icap.example.org/satisf ICAP/1.0 Host: icap.example.org Encapsulated: req-hdr=0, res-hdr=128, res-body=276 GET /origin-resource HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress HTTP/1.1 200 OK Date: Mon, 10 Jan 2000 09:52:22 GMT Server: Apache/1.3.6 (Unix) ETag: "63840-1ab7-378d415b" Content-Type: text/html Content-Length: 52 34 This is data that was returned by an origin server. 0 ---------------------------------------------------------------- ICAP Response Modification Example 4 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close Encapsulated: res-hdr=0, res-body=149 HTTP/1.1 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: Apache/1.3.6 (Unix) ETag: "63840-1ab7-378d415b" Content-Type: text/html Content-Length: 91 5c This is data that was returned by an origin server, but with value added by an ICAP server. 0 ---------------------------------------------------------------- ICAP Protocol Group Expiration: Aug 2001 [Page 23] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 5.9 OPTIONS Method The ICAP "OPTIONS" method may be used to retrieve configuration information from the ICAP server. The exact semantics and syntax of this information are beyond the scope of this document and will be filled in by later specifications. Applications may define their own uses for this method until such use is standardized. An OPTIONS request for any other URI MUST return options that are specific to the service named by the URI. All OPTIONS request MAY also return options that are global to the server (i.e., apply to all services). In this example, the root URI of the ICAP server has been configured to return an OPTIONS response that describes the services that are available on the server: [request] OPTIONS icap://icap.server.net/ ICAP/1.0 [response] ICAP-Version-Supported: 1.0 Server: ICAP-BazookaServer Server-Revision: 4.1 Server-Maintainer: admin@icap.server.net Service-URIs-available: sample-service, another-service Expires: Mon, 23 Nov 2000 08:29:50 GMT A different service-specific OPTIONS field might, for example, describe what content-types a modification service is willing to accept: [request] OPTIONS icap://icap.server.net/sample-service ICAP/1.0 [response] ICAP-Version-Supported: 1.0 Server: ICAP-BazookaServer Server-Revision: 4.1 Service-URI: icap://icap.server.net/sample-service Date: Mon, 13 Nov 2000 08:30:32 GMT Feature: RESPMOD Service-Name: French translator Service-Info: http://www.server.net/our-french-translator Desired-Preview-Length: 1500 Desired-Content-Types: text/plain, text/html Expires: Mon, 13 Nov 2000 08:29:50 GMT The problem of defining a policy language is a difficult one and was not specified by this document. The examples above are just that -- examples. ICAP Protocol Group Expiration: Aug 2001 [Page 24] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 6 Caching ICAP server replies MAY be cached by ICAP clients, just as any other proxy might cache HTTP responses. Unlike HTTP, ICAP mandates the use of the caching directives described in HTTP/1.1 [4] by ICAP servers to explicitly define the cachability of objects to ICAP clients. In cases where an ICAP server returns a modified version of an object created by an origin server, the expiration of the ICAP-modified object MUST NOT be longer than that of the origin object. In other words, ICAP servers MUST NOT extend the lifetime of origin server objects, but MAY shorten it. In cases where the ICAP server is the authoritative source of an ICAP response, such as in Request Modification mode, the ICAP server is not restricted in its expiration policy. 7 Implementation Notes 7.1 Vectoring Points The definition of the ICAP protocol itself only describes two different adaptation channels: modification (and satisfaction) of requests, and modifications of replies. However, an ICAP client implementation is likely to actually distinguish among four different classes of adaptation: 1. Adaptation of client requests. This is adaptation done every time a request arrives from a client. This is adaptation done when a request is "on its way into the cache". Factors such as the state of the objects currently cached will determine whether or not this request actually gets forwarded to an origin server (instead of, say, getting served off the cache's disk). An example of this type of adaptation would be special access control or authentication services that MUST be performed on a per-client basis. 2. Adaptation of requests on their way to an origin server. Although this type of adaptation is also an adaptation of requests similar to (1), it describes requests that are "on their way out of the cache"; i.e., if a request actually requires that an origin server be contacted. These adaptation requests are not necessarily specific to particular clients. An example would be addition of "Accept:" headers for special devices; these adaptations can potentially apply to many clients. 3. Adaptations of responses coming from an origin server. This is the adaptation of an object "on its way into the cache". In other words, this is adaptation that a proxy might want to perform on an object before caching it. The adapted object may subsequently served to many clients. An example of this type of adaptation is virus checking: a proxy will want to check an incoming origin reply for viruses once, before allowing it into the cache -- not every time the cached object is served to a client. ICAP Protocol Group Expiration: Aug 2001 [Page 25] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 4. Adaptation of responses coming from the proxy, heading back to the client. Although this type of adaptation, like (3), is the adaptation of a response, it is client-specific. Client reply adaptation is adaptation that is required every time an object is served to a client, even if all the replies come from the same cached object off of disk. Ad insertion is a common form of this kind of adaptation; i.e., if a popular (cached) object that rarely changes needs a different ad inserted into it every time it is served off disk to a client. Note that the relationship between adaptations of type (3) and (4) is analogous to the relationship between types (2) and (1). Although the distinction among these four adaptation points is critical for ICAP client implementations, the distinction is not significant for the ICAP protocol itself. From the point of view of an ICAP server, a request is a request -- the ICAP server doesn't care what policy led the ICAP client to generate the request. We therefore did not make these four channels explicit in ICAP for simplicity. 7.2 Application Level Errors Section 5 described "on the wire" protocol errors that MUST be standardized across implementations to ensure interoperability. In this section, we describe errors that are communicated between ICAP software and the clients and servers on which they are implemented. Although such errors are implementation dependent and do not necessarily need to be standardized because they are "within the box", they are presented here as advice to future implementors based on past implementation experience. Error name Value ==================================================== ICAP_CANT_CONNECT 1000 ICAP_SERVER_RESPONSE_CLOSE 1001 ICAP_SERVER_RESPONSE_RESET 1002 ICAP_SERVER_UNKNOWN_CODE 1003 ICAP_SERVER_UNEXPECTED_CLOSE_204 1004 ICAP_SERVER_UNEXPECTED_CLOSE 1005 1000 ICAP_CANT_CONNECT: "Cannot connect to ICAP server". The ICAP server is not connected on the socket. Maybe the ICAP server is dead or it is not connected on the socket. 1001 ICAP_SERVER_RESPONSE_CLOSE: "ICAP Server closed connection while reading response". The ICAP server TCP-shutdowns the connection before the ICAP client can send all the body data. ICAP Protocol Group Expiration: Aug 2001 [Page 26] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 1002 ICAP_SERVER_RESPONSE_RESET: "ICAP Server reset connection while reading response". The ICAP server TCP-reset the connection before the ICAP client can send all the body data. 1003 ICAP_SERVER_UNKNOWN_CODE: "ICAP Server sent unknown response code". An unknown ICAP response code (see section 5.x) was received by the ICAP client. 1004 ICAP_SERVER_UNEXPECTED_CLOSE_204: "ICAP Server closed connection on 204 without 'Connection: close' header". An ICAP server MUST send the "Connection: close" header if intends to close after the current transaction. 1005 ICAP_SERVER_UNEXPECTED_CLOSE: "ICAP Server closed connection as ICAP client wrote body preview". 7.3 Use of Chunked Transfer-Encoding For simplicity, ICAP messages MUST use the "chunked" transfer-encoding defined in HTTP/1.1 [4]. This requires that ICAP client implementations convert incoming objects "on the fly" to chunked from whatever transfer-encoding on which they arrive. However, the transformation is simple: -- For objects arriving using "Content-Length" headers, one big chunk can be created of the same size as indicated in the Content-Length header. -- For objects arriving using a TCP close to signal the end of the object, each incoming group of bytes read from the OS can be converted into a chunk (by writing the length of the bytes read, followed by the bytes themselves) -- For objects arriving using chunked encoding, they can be retransmitted as is (without re-chunking). 7.4 Distinct URIs for Distinct Services ICAP servers should assign unique URIs to each service they provide, even if such services might theoretically be differentiated based on their method. In other words, a REQMOD and RESPMOD service should never have the same URI, even if they do something that is conceptually the same. This situation in ICAP is similar to that found in HTTP where it might, in theory, be possible to perform a GET or a POST to the same URI and expect two different results. This kind of overloading of URIs only ICAP Protocol Group Expiration: Aug 2001 [Page 27] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 causes confusion and should be avoided. 8 Security Considerations 8.1 Authentication Authentication in ICAP is very similar to proxy authentication in HTTP as specified in RFC 2617. Specifically, the following rules apply: -- WWW-Authenticate challenges and responses are for end-to-end authentication between a client (user) and an origin server. As any proxy, ICAP clients and ICAP servers MUST forward these headers without modification. -- If authentication is required between an ICAP client and ICAP server, hop-by-hop Proxy Authentication as described in RFC 2617 MUST be used. There are potential applications where a user (as opposed to ICAP client) might have rights to access an ICAP service. In this version of the protocol, we assume that ICAP clients and ICAP servers are under the same administrative domain, and contained in a single trust domain. Therefore, in these cases, we assume that it is sufficient for users to authenticate themselves to the ICAP client (which is a proxy from the point of view from the user). This type of authentication will also be Proxy Authentication as described in RFC 2617. This standard explicitly excludes any method for a user authenticate directly to an ICAP server; the ICAP client MUST be involved as described above. 8.2 Encryption Users of ICAP should note well that ICAP messages are not encrypted for transit by default. In the absence of some other form of encryption at the link or network layers, eavesdroppers may be able to record the unencrypted transactions between ICAP clients and servers. As described in Section 5.3.1, the Upgrade header MAY be used to negotiate transport-layer security for an ICAP connection. Note also that end-to-end encryption between a a client and origin server is likely to preclude the use of value-added services by intermediaries such as proxy caches. An ICAP server that is unable to decrypt a client's messages will, of course, be unable to perform any transformations on it. 8.3 Service Validation Normal HTTP proxies, when operating correctly, should not affect the end-to-end semantics of messages that pass through them. This forms a well-defined criterion to validate that a proxy is working correctly: a message should look the same before the proxy as it does after the proxy. ICAP Protocol Group Expiration: Aug 2001 [Page 28] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 In contrast, ICAP is meant to cause changes in the semantics of messages on their way from origin servers to users. The criteria for a correctly operating proxy are no longer as easy to define. This will make validation of ICAP services significantly more difficult. Incorrect adaptations may lead to security vulnerabilities that were not present in the unadapted content. ICAP Protocol Group Expiration: Aug 2001 [Page 29] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 9 References [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", Request for Comments 2396, August 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments 2119, Harvard University, March 1997. [3] Crocker, D., "Standard for the format of ARPA Internet text messages", Request for Comments 822, August 1982. [4] Fielding, R., et. al., "Hypertext Transfer Protocol -- HTTP/1.1", Request for Comments 2616, June 1999. [5] Khare, R., et. al., "Upgrading to TLS Within HTTP/1.1", Request for Comments 2817, May 2000. ICAP Protocol Group Expiration: Aug 2001 [Page 30] INTERNET-DRAFT Internet Content Adaptation Protocol February 2000 10 Contact Information and Authors' Addresses ICAP discussion currently takes place on the IETF Open Proxies mailing list at ietf-openproxy@imc.org. ICAP is a product of the ICAP Protocol Group, an informal partnership of interested parties that includes the following participants (past and present): Lee Duggs lee.duggs@netapp.com Jeremy Elson jelson@isi.edu Debbie Futcher deborah.futcher@netapp.com Don Gillies gillies@netapp.com John Martin jmartin@netapp.com Jeff Merrick jeffrey.merrick@netapp.com John Schuster john.schuster@netapp.com Edward Sharp edward.sharp@netapp.com Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA Phone: (408) 822-6000 Alberto Cerpa cerpa@isi.edu Peter Danzig danzig@akamai.com Mark Nottingham mnot@akamai.com Nitin Sharma nitin@akamai.com Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA Phone: (650) 372-5757 Craig Blitz cblitz@novell.com Hilarie Orman horman@novell.com Gary Tomlinson garyt@novell.com Novell, Inc. 122 East 1700 South Provo, UT 84606 USA Phone: (801) 861-7021 Andre Beck abeck@bell-labs.com Markus Hofmann hofmann@bell-labs.com Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030 Phone: (732) 332-5983 David Bryant david.bryant@cacheflow.com CacheFlow, Inc. 650 Almanor Avenue Sunnyvale, California 94086 Phone: (888) 462-3568 ICAP Protocol Group Expiration: Aug 2001 [Page 31]