1. Introduction

   As the Internet grows, so does the need for scalable Internet
   services.  Popular web servers are asked to deliver content to
   hundreds of 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.

   To keep up 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 myriad of servers.  Content
   providers have also begun to deploy geographically diverse content
   distribution networks that bring origin-servers closer to the "edge"
   of the network where clients are attached.  These networks of
   distributed origin-servers or "surrogates" allow the content provider
   to distribute their content whilst retaining control over the
   integrity of that content.  The distributed nature of this type of
   deployment and the proximity of a given surrogate to the end-user
   enables the content provider to offer additional services to a user
   which might be based, for example, on geography where this would have
   been difficult with a single, centralized service.

   ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
   providing simple object-based content vectoring for HTTP services.
   ICAP is, in essence, a lightweight protocol for executing a "remote
   procedure call" on HTTP messages.  It allows ICAP clients to pass
   HTTP messages to ICAP servers for some sort of transformation or
   other processing ("adaptation").  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.  Though transformations may
   be possible on other non-HTTP content, they are beyond the scope of
   this document.

   This type of Remote Procedure Call (RPC) is useful in a number of
   ways.  For example:

   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 and tracking
      user cookies.  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 surrogate).  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  Surrogates 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,
      consider a user attempting to download an executable program via a
      surrogate (e.g., a caching proxy).  The surrogate, acting as an
      ICAP client, can ask an external server to check the executable
      for viruses before accepting it into its cache.

   o  Firewalls or surrogates 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 or distribute the
   load on origin servers, surrogates, or the network itself.  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 surrogates 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 surrogates.

   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, this 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 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.

   IMPORTANT:
      Note that at this time, in the absence of a policy-framework, it
      is strongly RECOMMENDED that transformations SHOULD only be
      performed on messages with the explicit consent of either the
      content-provider or the user (or both).  Deployment of
      transformation services without the consent of either leads to, at
      best, unpredictable results.  For more discussion of these issues,
      see Section 7.

   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 may allow a standard policy
   definition interface complementary to the ICAP transaction interface
   defined here.