Internet DRAFT - draft-beck-opes-icap-subid
draft-beck-opes-icap-subid
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]
