idnits 2.17.1 draft-beck-opes-icap-subid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2001) is 8204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-elson-icap-00 ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Beck 3 M. Hofmann 4 Expires: May 2002 Lucent Technologies 5 Document: draft-beck-opes-icap-subid-00.txt 7 Category: Informational November 2, 2001 9 Transmitting Subscriber Identification in iCAP 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Internet Content Adaptation Protocol (iCAP) [1] provides simple, 34 object-based content vectoring for HTTP services. For some services, 35 the iCAP server needs to identify the source of the encapsulated 36 HTTP message. This document specifies user-defined header extensions 37 of iCAP, which allow the iCAP client to include the IP address and 38 possibly a subscriber ID of the source of the encapsulated HTTP 39 message. 41 Table of Contents 43 1 Terminology....................................................2 44 2 Problem Description and Goals..................................2 45 3 iCAP Extension Headers.........................................2 46 3.1 iCAP Client Obligations......................................3 47 3.1.1 iCAP Request Modification Mode..............................3 48 3.1.2 iCAP Response Modification Mode.............................4 49 3.2 iCAP Server Obligations......................................4 50 4 Security Considerations........................................4 51 5 References.....................................................5 52 Author's Addresses................................................5 53 Full Copyright Statement..........................................5 55 1 Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [1]. 61 Other terminology used in this document is consistent with that 62 defined and used in [1]. 64 2 Problem Description and Goals 66 The Internet Content Adaptation Protocol (iCAP) [1] provides simple, 67 object-based content vectoring for HTTP services. It allows iCAP 68 clients to pass HTTP messages to iCAP servers for some sort of 69 transformation or other processing ("adaptation"), which in general 70 is referred to as content services. The iCAP server executes its 71 content service on messages and sends back responses to the client, 72 usually with modified HTTP messages. Typically, the adapted messages 73 are either HTTP requests or HTTP responses. 75 For some services, the iCAP server needs to identify the source of 76 the encapsulated HTTP message. For example, knowledge of the source 77 of an HTTP request might be useful for the provisioning of 78 personalized web pages. Other examples include content filtering and 79 all types of subscription-based services. 81 As the iCAP server typically communicates with the iCAP client 82 rather than the source of encapsulated HTTP messages, it cannot 83 extract the identity of the source of the HTTP messages from the 84 underlying transport session. Furthermore, iCAP itself does not 85 define a mechanism for the exchange of such information between iCAP 86 client and iCAP server. 88 For these reasons, this document specifies user-defined header 89 extensions of iCAP, which allow the iCAP client to include the IP 90 address and possibly a subscriber ID of the source of the 91 encapsulated HTTP message. For more information on user-defined 92 header extensions in iCAP, please read Section 4.3 of [1]. 94 3 iCAP Extension Headers 96 This section describes the format and the usage of two specific 97 user-defined iCAP header extensions, namely 98 X-Client-IP 99 X-Subscriber-ID 101 In compliance with the precedent established by the Internet mail 102 format [2] and later adopted by HTTP [3], these user-defined headers 103 follow the "X-" naming convention. iCAP implementations MAY ignore 104 these "X-" headers without loss of compliance with the protocol as 105 defined in [1]. 107 Each header field consists of a name followed by a colon (":") and 108 the field value. Field names are case-insensitive. iCAP follows 109 the rules describe in section 4.2 of [3]. 111 3.1 iCAP Client Obligations 113 This section describes how an iCAP client SHOULD use the user- 114 defined header extensions. The usage depends on the iCAP operation 115 mode. 117 3.1.1 iCAP Request Modification Mode 119 For iCAP messages in request modification mode (REQMOD), the iCAP 120 client SHOULD always include the IP source address of the 121 encapsulated HTTP request in the X-Client-IP header field of the 122 iCAP message. The IP address MUST be in dotted decimal format. 124 If the iCAP client is aware of the subscriber ID for the client 125 issuing the HTTP request, the iCAP client SHOULD also include this 126 subscriber ID in the X-Subscriber-ID field of the iCAP message. If 127 the iCAP client is not aware of the subscriber ID for the client 128 issuing the HTTP request, the iCAP client MUST NOT include an X- 129 Subscriber-ID header in the outgoing iCAP message. 131 The following example illustrates the usage of the two user-defined 132 header extensions. 134 REQMOD icap://content-networking.com/server?arg=87 ICAP/1.0 135 Host: content-networking.com 136 X-Client-IP: 129.13.42.100 137 X-Subscriber-ID: hofmann@bell-labs.com 138 Encapsulated: req-hdr=0, null-body=170 140 GET / HTTP/1.1 141 Host: www.origin-server.com 142 Accept: text/html, text/plain 143 Accept-Encoding: compress 144 Cookie: ff39fk3jur@4ii0e02i 145 If-None-Match: "xyzzy", "r2d2xxxx" 146 In this example, the iCAP client has received the encapsulated HTTP 147 request from a machine with the IP address "129.13.42.100", as 148 indicated in the X-Client-IP header field. The identification of the 149 requestor - in form of his email address - has been included in the 150 X-Subscriber-ID field. Note, however, that the format of the 151 subscriber ID depends on the specific service and/or deployment 152 environment and is not defined by iCAP or this document. 154 3.1.2 iCAP Response Modification Mode 156 For iCAP messages in response modification mode (RESPMOD), the iCAP 157 client SHOULD always include the IP source address of the client 158 issuing the HTTP request (that resulted in the encapsulated HTTP 159 response) in the X-Client-IP header field of the iCAP message. Note 160 that it is the IP source address of the corresponding HTTP request, 161 which is included in the user-defined iCAP header extension, and not 162 the IP source address of the encapsulated HTTP response. (Note, 163 however, that the HTTP request that resulted in the encapsulated 164 HTTP response might also be encapsulated in the iCAP message.) 166 If the iCAP client is aware of the subscriber ID for the client 167 issuing the HTTP request that resulted in the encapsulated HTTP 168 response, the iCAP client SHOULD also include this subscriber ID in 169 the X-Subscriber-ID field of the iCAP message. If the iCAP client is 170 not aware of the subscriber ID for the client issuing the 171 corresponding HTTP request, the iCAP client MUST NOT include an X- 172 Subscriber-ID header in the outgoing iCAP message. 174 3.2 iCAP Server Obligations 176 This section describes how an iCAP server SHOULD use the user- 177 defined header extensions. The usage is independent from the iCAP 178 operation mode. 180 The iCAP server SHOULD pass the information included in the user- 181 defined header extensions to the requested iCAP service via its 182 local interface. Details on how to pass these parameters are 183 specific to the interface implementation and not part of this 184 document. 186 An iCAP server SHOULD NOT include the X-Client-IP or the X- 187 Subscriber-ID header extension in the iCAP response. 189 4 Security Considerations 191 Users of iCAP should note well that iCAP messages (including the 192 user-defined extension headers proposed in this document) are not 193 encrypted for transit by default. In the absence of some other form 194 of encryption at the link or network layers, eavesdroppers may be 195 able to record the unencrypted transactions between iCAP clients and 196 iCAP servers, including the subscriber identification information as 197 contained in the user-defined header extensions proposed in this 198 document. 200 5 References 202 [1] J. Elson, A. Cerpa (Ed.): ICAP - the Internet Content 203 Adaptation Protocol, Internet Draft draft-elson-icap-00.txt, 204 Work in Progress, October 2001. 206 [2] Crocker, D., "Standard for the format of ARPA Internet text 207 messages", Request for Comments 822, August 1982. 209 [3] Fielding, R., et al., "Hypertext Transfer Protocol -- 210 HTTP/1.1", Request for Comments 2616, June 1999. 212 Author's Addresses 214 Andre Beck 215 Markus Hofmann 216 Bell Labs Research 217 Lucent Technologies 218 101 Crawfords Corner Rd. 219 Holmdel, NJ 07733 220 Phone: (732) 332-5983 221 Email: {abeck, hofmann}@bell-labs.com 223 Full Copyright Statement 225 Copyright (C) The Internet Society (2000). All Rights Reserved. 227 This document and translations of it may be copied and furnished to 228 others, and derivative works that comment on or otherwise explain it 229 or assist in its implementation may be prepared, copied, published 230 and distributed, in whole or in part, without restriction of any 231 kind, provided that the above copyright notice and this paragraph 232 are included on all such copies and derivative works. However, this 233 document itself may not be modified in any way, such as by removing 234 the copyright notice or references to the Internet Society or other 235 Internet organizations, except as needed for the purpose of 236 developing Internet standards in which case the procedures for 237 copyrights defined in the Internet Standards process must be 238 followed, or as required to translate it into languages other than 239 English. 241 The limited permissions granted above are perpetual and will not be 242 revoked by the Internet Society or its successors or assigns. 244 This document and the information contained herein is provided on an 245 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 246 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 247 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 248 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 249 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.