Internet Draft                                               A. Beck
                                                             M. Hofmann
   Expires: May 2002                                Lucent Technologies
   Document: draft-beck-opes-icap-subid-00.txt

   Category: Informational                             November 2, 2001



              Transmitting Subscriber Identification in iCAP


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.


Abstract

   The Internet Content Adaptation Protocol (iCAP) [1] provides simple,
   object-based content vectoring for HTTP services. For some services,
   the iCAP server needs to identify the source of the encapsulated
   HTTP message. This document specifies user-defined header extensions
   of iCAP, which allow the iCAP client to include the IP address and
   possibly a subscriber ID of the source of the encapsulated HTTP
   message.


Table of Contents

   1  Terminology....................................................2
   2  Problem Description and Goals..................................2
   3  iCAP Extension Headers.........................................2
   3.1  iCAP Client Obligations......................................3
   3.1.1 iCAP Request Modification Mode..............................3
   3.1.2 iCAP Response Modification Mode.............................4

   Beck, Hofmann           Expires May 2002                   [Page 1]

   Internet Draft                IRML                    November 2001

   3.2  iCAP Server Obligations......................................4
   4  Security Considerations........................................4
   5  References.....................................................5
   Author's Addresses................................................5
   Full Copyright Statement..........................................5


  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 [1].

   Other terminology used in this document is consistent with that
   defined and used in [1].


  Problem Description and Goals

   The Internet Content Adaptation Protocol (iCAP) [1] provides simple,
   object-based content vectoring for HTTP services.  It allows iCAP
   clients to pass HTTP messages to iCAP servers for some sort of
   transformation or other processing ("adaptation"), which in general
   is referred to as content services.  The iCAP server executes its
   content service on messages and sends back responses to the client,
   usually with modified HTTP messages. Typically, the adapted messages
   are either HTTP requests or HTTP responses.

   For some services, the iCAP server needs to identify the source of
   the encapsulated HTTP message. For example, knowledge of the source
   of an HTTP request might be useful for the provisioning of
   personalized web pages. Other examples include content filtering and
   all types of subscription-based services.

   As the iCAP server typically communicates with the iCAP client
   rather than the source of encapsulated HTTP messages, it cannot
   extract the identity of the source of the HTTP messages from the
   underlying transport session. Furthermore, iCAP itself does not
   define a mechanism for the exchange of such information between iCAP
   client and iCAP server.

   For these reasons, this document specifies user-defined header
   extensions of iCAP, which allow the iCAP client to include the IP
   address and possibly a subscriber ID of the source of the
   encapsulated HTTP message. For more information on user-defined
   header extensions in iCAP, please read Section 4.3 of [1].

  iCAP Extension Headers

   This section describes the format and the usage of two specific
   user-defined iCAP header extensions, namely


   Beck, Hofmann           Expires May 2002                   [Page 2]

   Internet Draft                IRML                    November 2001

        X-Client-IP
        X-Subscriber-ID

   In compliance with the precedent established by the Internet mail
   format [2] and later adopted by HTTP [3], these user-defined headers
   follow the "X-" naming convention. iCAP implementations MAY ignore
   these "X-" headers without loss of compliance with the protocol as
   defined in [1].

   Each header field consists of a name followed by a colon (":") and
   the field value.  Field names are case-insensitive.  iCAP follows
   the rules describe in section 4.2 of [3].

3.1 iCAP Client Obligations

   This section describes how an iCAP client SHOULD use the user-
   defined header extensions. The usage depends on the iCAP operation
   mode.

3.1.1   iCAP Request Modification Mode

   For iCAP messages in request modification mode (REQMOD), the iCAP
   client SHOULD always include the IP source address of the
   encapsulated HTTP request in the X-Client-IP header field of the
   iCAP message. The IP address MUST be in dotted decimal format.

   If the iCAP client is aware of the subscriber ID for the client
   issuing the HTTP request, the iCAP client SHOULD also include this
   subscriber ID in the X-Subscriber-ID field of the iCAP message. If
   the iCAP client is not aware of the subscriber ID for the client
   issuing the HTTP request, the iCAP client MUST NOT include an X-
   Subscriber-ID header in the outgoing iCAP message.

   The following example illustrates the usage of the two user-defined
   header extensions.


    REQMOD icap://content-networking.com/server?arg=87 ICAP/1.0
    Host: content-networking.com
    X-Client-IP: 129.13.42.100
    X-Subscriber-ID: hofmann@bell-labs.com
    Encapsulated: req-hdr=0, null-body=170

    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"





   Beck, Hofmann           Expires May 2002                   [Page 3]

   Internet Draft                IRML                    November 2001

   In this example, the iCAP client has received the encapsulated HTTP
   request from a machine with the IP address "129.13.42.100", as
   indicated in the X-Client-IP header field. The identification of the
   requestor - in form of his email address - has been included in the
   X-Subscriber-ID field. Note, however, that the format of the
   subscriber ID depends on the specific service and/or deployment
   environment and is not defined by iCAP or this document.

3.1.2   iCAP Response Modification Mode

   For iCAP messages in response modification mode (RESPMOD), the iCAP
   client SHOULD always include the IP source address of the client
   issuing the HTTP request (that resulted in the encapsulated HTTP
   response) in the X-Client-IP header field of the iCAP message. Note
   that it is the IP source address of the corresponding HTTP request,
   which is included in the user-defined iCAP header extension, and not
   the IP source address of the encapsulated HTTP response. (Note,
   however, that the HTTP request that resulted in the encapsulated
   HTTP response might also be encapsulated in the iCAP message.)

   If the iCAP client is aware of the subscriber ID for the client
   issuing the HTTP request that resulted in the encapsulated HTTP
   response, the iCAP client SHOULD also include this subscriber ID in
   the X-Subscriber-ID field of the iCAP message. If the iCAP client is
   not aware of the subscriber ID for the client issuing the
   corresponding HTTP request, the iCAP client MUST NOT include an X-
   Subscriber-ID header in the outgoing iCAP message.

3.2 iCAP Server Obligations

   This section describes how an iCAP server SHOULD use the user-
   defined header extensions. The usage is independent from the iCAP
   operation mode.

   The iCAP server SHOULD pass the information included in the user-
   defined header extensions to the requested iCAP service via its
   local interface. Details on how to pass these parameters are
   specific to the interface implementation and not part of this
   document.

   An iCAP server SHOULD NOT include the X-Client-IP or the X-
   Subscriber-ID header extension in the iCAP response.


  Security Considerations

   Users of iCAP should note well that iCAP messages (including the
   user-defined extension headers proposed in this document) 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
   iCAP servers, including the subscriber identification information as


   Beck, Hofmann           Expires May 2002                   [Page 4]

   Internet Draft                IRML                    November 2001

   contained in the user-defined header extensions proposed in this
   document.


  References


   []  J. Elson, A. Cerpa (Ed.): ICAP - the Internet Content
        Adaptation Protocol, Internet Draft draft-elson-icap-00.txt,
        Work in Progress, October 2001.

   []  Crocker, D., "Standard for the format of ARPA Internet text
        messages", Request for Comments 822, August 1982.

   []  Fielding, R., et al., "Hypertext Transfer Protocol --
        HTTP/1.1", Request for Comments 2616, June 1999.

Author's Addresses


   Andre Beck
   Markus Hofmann
   Bell Labs Research
   Lucent Technologies
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Phone: (732) 332-5983
   Email: {abeck, hofmann}@bell-labs.com


Full Copyright Statement


   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.



   Beck, Hofmann           Expires May 2002                   [Page 5]

   Internet Draft                IRML                    November 2001

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















































   Beck, Hofmann           Expires May 2002                   [Page 6]