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 1 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]. 2 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]. 3 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. 4 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. 5 References [1] J. Elson, A. Cerpa (Ed.): ICAP - the Internet Content Adaptation Protocol, Internet Draft draft-elson-icap-00.txt, Work in Progress, October 2001. [2] Crocker, D., "Standard for the format of ARPA Internet text messages", Request for Comments 822, August 1982. [3] 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]