Internet DRAFT - draft-barbir-opes-fsp
draft-barbir-opes-fsp
OPES Working Group A. Barbir
Internet Draft N. Bennett
Document: draft-barbir-opes-fsp-03.txt R. Penno
Nortel Networks
H. T. Pham R. Menon
Alcatel Intel
J. Mysore S. Sengodan
Motorola Nokia
March 2003
A Framework for Service Personalization
Status of this Memo
This document is an Internet-Draft and is subject to 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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document discusses a Framework for Service Personalization
(FSP) defined within the bounds of the Open Pluggable Edge Services
(OPES) Framework. The work described here aims to provide a
Framework and Protocols for the delivery of the optimal content
variant for a given requestor based on subscriber profile and
policies, content profile and its associated policies. This document
provides a general outline of FSP that could be used as a vehicle
for performing personalization services in edge and intermediary
devices or at Content origins.
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003
A Framework for Service Personalization
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................3
1. Introduction....................................................3
2. Definitions and Terminology.....................................4
3. What is Service Personalization?...............................10
3.1 Service Personalization at the Content Source.................12
3.2 Service Personalization at the User Agent.....................13
3.3 Service Personalization at the Network Edge...................14
3.4 Service Personalization at Intermediaries.....................15
3.4.1 Service Personalization at Caching Proxies..................16
3.4.2 Service Personalization at Surrogates.......................17
3.5 Hybrid approaches to Service Personalization..................18
3.6 Goals of FSP..................................................19
3.7 Subscriber and Content Profiles...............................19
3.8 Content Selection.............................................20
3.9 Quality of Delivery (Origin Server Selection ?)...............21
3.10 Privacy and Security.........................................22
4. Security Considerations - Security Threats and Mechanisms......23
4.1 Threat Analysis...............................................23
4.1.1 Malicious entity accesses subscriber profile................23
4.1.2 Malicious entity modifies subscriber profile................23
4.1.3 Eavesdropping on a subscriber profile in transit............24
4.1.4 Malicious entity accesses content profile...................24
4.1.5 Malicious entity modifies content profile...................24
4.1.6 Eavesdropping on a content profile in transit...............24
4.1.7 Authorized entity later repudiates a request................24
4.2 Security Mechanisms...........................................25
4.2.1 Application layer security designed for FSP.................25
4.2.2 S/MIME and PGP..............................................25
4.2.3 TLS.........................................................25
4.2.4 IPSec.......................................................25
5. Related Personalization Developments...........................25
5.1 The Liberty Alliance and Microsoft Passport...................26
6. Acknowledgments................................................26
7. References.....................................................27
8. Authors' Addresses.............................................27
9. Full Copyright Statement.......................................29
Barbir, et al. Expires September 2003 [Page 2]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Conventions used in this document
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. Introduction
In the Internet today, personalization and profiling services are
provided to subscribers by portals. Portals usually require
subscribers to log on to their sites, which helps to identify the
subscriber. Portals usually perform subscriber profiling by tracking
their habits and preferences. In order to be able to create accurate
subscriber profiles, the portals must rely on co-located subscriber
identification and profiling from participating web sites.
Current schemes for providing personalization services rely on
piecemeal subscriber identification and profiling. The schemes
require the subscriber to repeatedly log on to various portals or
web sites, since each portal has a finite number of web sites with
which it has arrangements to share subscriber information. As a
consequence, subscriber information gets duplicated in various
locations across the Internet, in a number of different formats.
At least two major initiatives are addressing some aspects of
personalization services, primarily focusing on various aspects of
purchasing goods and services over the Internet. The Liberty
Alliance and Microsoft Corporation's Passport service appear to be
the two most widely recognized of these initiatives. Section 5.1
discusses this in more detail.
A major drawback of current personalization schemes is their
reliance on content origin web servers to perform the
personalization tasks. As a consequence content providers need to
store and manage different content for different subscribers, or
alternately, there is no storage of content on a per-user basis, but
rather a large collection of content to choose from based on
personal profiles and other criteria. This approach leads to
scalability and optimality issues. This is because the
personalization task is done based on incomplete information about
the subscriber. The content provider may not be aware of many types
of information about the subscriber, including geographic location,
QoS policy, device type, and access rate, which could dramatically
increase the efficiency of any personalization task undertaken on
their behalf. A potential solution to this problem is to shift
responsibility for personalizing content to an intermediary device.
This has many advantages over current solutions, and represents an
important value-added service that could be provided by network edge
caching proxies or other intermediary devices.
Barbir, et al. Expires September 2003 [Page 3]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Network edge caching proxies are currently deployed in the Internet
in order to accelerate web content delivery, reduce the load on
origin servers, and reduce the bandwidth requirements between the
caching proxy and the content origin. Since these intermediaries
function as gateways between subscribers and content providers, it
is possible to use them for intelligent services beyond simple
caching. Examples of such services include among others [ESFNEP]
virus scanning, ad insertion, caching of personalized web pages,
limited client bandwidth adaptation, request filtering, and creation
of uniform subscriber profiles. In the IETF, OPES [ESFNEP] is
defining the scope of caching proxies to perform extended services
at the edge of the network.
This document and its companion document [CALLOUT] discuss a
Framework for Service Personalization (FSP) defined within the
bounds of the Open Pluggable Edge Services (OPES) Framework [O-
MODEL]. While FSP is defined within the scope of OPES, some effort
is made within this document to provide insight into general and
abstract requirements for such a framework. Detailed discussion of
the implementation of this framework, including analysis of the
integration of the proposed framework into the larger OPES scope is
covered in the companion document [CALLOUT]. It should be noted that
at this stage, these documents are not intended to completely define
an abstract, implementation-independent FSP, but rather one which
builds on and functions within the scope of the OPES.
This document defines the scope of personalization and introduces
the concept of a Framework for Service Personalization (FSP). This
framework defines the essential components and mechanisms that are
needed in order to provide consistent personalization services to
subscribers, delivering high quality personalized content to
subscribers in a secure and reliable manner. This document also
establishes a framework and requirements for developing an OPES FSP
call-out server. The document is organized as follows: section 2
defines the terms used throughout the document, section 3 provides
an overview of FSP, while section 4 discusses security threats and
mechanisms.
2. Definitions and Terminology
This section consists of the definitions of a number of terms used
to refer to the roles, participants, and objects potentially
involved in FSP implementations. Although the following uses many
terms employed in [RFC-2616] and [RFC-3040], there is no necessary
connection to HTTP or web caching technology. FSP and this
vocabulary are applicable to other protocols and content networks.
Words enclosed within 'single quotes' are defined terms within this
document.
ACTION
A form of a policy action [RFC-3040] that results in the execution
of a 'service module' when 'conditions' of a 'rule' are met.
Barbir, et al. Expires September 2003 [Page 4]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
AUTHORITATIVE DOMAIN
A logical domain in which the network elements have rights, either
delegated or inherited, to act authoritatively on behalf of a party
(typically the content owner or the subscriber). This logical domain
may be wholly contained within the administrative domain [ESFNEP] of
the party, or it may be a collection of administrative domains to
which the party rights have been delegated.
CACHE (REFERENCE DEFINITION [RFC-2616])
A program's local store of response messages and the subsystem that
controls its message storage, retrieval, and deletion. A cache
stores cacheable responses in order to reduce the response time and
network bandwidth consumption on future, equivalent requests. Any
client or server may include a cache, though a cache cannot be used
by a server that is acting as a tunnel.
CACHING PROXY (REFERENCE DEFINITION [RFC-3040])
A proxy with a cache, acting as a server to clients, and a client to
servers. Caching proxies are often referred to as "proxy caches" or
simply "caches". The term "proxy" is also frequently misused when
referring to caching proxies.
CLIENT (REFERENCE DEFINITION [RFC-2616])
A program that establishes connections for the purpose of sending
requests.
CONDITION
A form of a policy condition [POLICY] that is an expression, which
is used to determine whether a 'rule' 'action' should be executed.
CONTENT CONSUMER
The 'client' that is the final destination of content delivery.
CONTENT PATH
The content path describes the path that content requests and
responses take through the network. Typically, content requests and
responses flow between a client, and/or an 'intermediary', and a
'content server'. Note that the paths of the requests and responses
may not always be symmetric.
CONTENT PROFILE
A content profile consists of a set of elements that describe
available variants for given content. The profile also includes
policy information about allowable transformations, adaptations, and
Digital Rights Management that are applicable for that content. The
profile can be applicable to a specific piece of content, a set or
class of content, or an aggregation of content from several
locations.
Barbir, et al. Expires September 2003 [Page 5]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
CONTENT SERVER
The server from which content is delivered. It may be an 'origin
server', replica server, 'surrogate' or parent proxy.
CONTENT SERVICE
A service operating on and providing a value-add to content.
DELEGATE
A 'caching proxy' located near or at the network access point of the
'user agent', delegated the authority to operate on behalf of, and
typically working in close co-operation with a group of 'user
agents'.
IN-PATH
In-Path Content Services are within the normal message path of the
application they are associated with. This may be an Application
proxy, gateway, or (in the extreme case) one of the end-hosts that
is party to the application [C-MODEL].
INTERMEDIARY
Intermediaries are application gateway devices located in the
'content path' between 'client' and 'origin server'. 'Caching
proxies' and 'surrogates' are probably the most commonly known and
used intermediaries today.
OPES ADMINISTRATIVE SERVER
An OPES administrative (or "admin") server performs authentication,
authorization and accounting (AAA) functions for an OPES 'edge
services network'. These functions include, but are not limited to,
downloading of 'proxylets' and 'rule modules' from trusted parties,
authorization and authentication of 'OPES services', the collection
of accounting and log data, and other administrative tasks. It must
be a member of the 'authoritative domain' of the parties for which
it is authorizing 'content services'. It must also be a member of
the 'authoritative domain' of the parties on whose behalf it is
provisioning 'content services'.
OPES ENGINE
An OPES engine allows new services to be defined and executed on
'OPES intermediaries' according to the policies set up by an 'OPES
admin server'. An OPES engine contains a message parser, and a rule
processor that reside in the flow of content passing through the
'OPES intermediary'. Collectively these form a 'PEP'. The 'OPES
engine' calls 'actions', which reside in either the 'proxylet run-
time system' or as 'remote call-out stubs'.
OPES INTERMEDIARY
An "intermediary" device integrating a compliant 'OPES engine'. OPES
intermediaries are typically hosted on 'delegates' or 'surrogates'.
OPES SERVICE
Barbir, et al. Expires September 2003 [Page 6]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
An OPES service is an authorized 'content service' performed on a
message flowing through the 'content path' by a 'OPES service
module'.
OPES SERVICE MODULE
OPES service modules are executable code modules that are executed
either on the local 'proxylet run-time system' or on the 'remote
call-out server'.
ORIGIN SERVER (REFERENCE DEFINITION [RFC-2616])
The server on which a given resource resides or is to be created.
OUT-OF-PATH
Out-of-Path Content Services are not natively in the transport path
of an application. In other words, they are not necessarily resident
(or co-resident) on entities that are natively in the path of
application flows.
PCS - PERSONALIZATION CALL-OUT SERVER
A 'remote call-out server' that performs the task of generating
dynamic 'rule modules' that are either encoded or could be extracted
from a 'subscriber profile', and which represent a 'subscriber's
personalization preferences and subsequently loading them onto the
appropriate 'OPES admin servers' or 'OPES Engines'.
PDP See 'policy decision point'.
PEP See 'policy enforcement point'.
POLICY DECISION POINT (REFERENCE DEFINITION [POLICY])
A logical entity that makes policy decisions for itself or for other
network elements that request such decisions.
POLICY ENFORCEMENT POINT (REFERENCE DEFINITION [POLICY])
A logical entity that enforces policy decisions.
PROXYLET
A proxylet is 'OPES service module' that runs on the 'OPES
intermediary' within the 'proxylet run-time system' and provides a
service on 'content path' requests or responses.
PROXYLET LIBRARY
A proxylet library is a library provided to support runtime services
in the 'proxylet runtime system'.
PROXYLET META-DATA
Proxylet meta-data describes the characteristics, features and
requirements associated with a proxylet. Examples for such meta-data
are the name of the 'proxylet', its functionality, its version
number, where to get it, license related information, execution
environments, etc. The meta-data can physically be separated from
Barbir, et al. Expires September 2003 [Page 7]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
the 'proxylet' code, but it must be possible to uniquely associate
meta-data with 'proxylets' and vice versa.
PROXYLET PROVIDER
A proxylet provider is the party that provides the 'proxylet' 'OPES
service module' to the 'OPES admin server'.
PROXYLET RUN-TIME SYSTEM
The local execution environment on an 'OPES intermediary'.
'Proxylets' execute as local (as opposed to 'remote call-out')
'actions' within this environment.
REMOTE CALL-OUT
A remote procedure call made via a 'remote call-out protocol" to a
'remote call-out server' that is invoked as the result of an
'action'.
REMOTE CALL-OUT PROTOCOL
The network protocol that encapsulates and transports a 'remote
call-out' between an 'OPES intermediary' and a 'remote call-out
server'.
REMOTE CALL-OUT STUB
A remote procedure call stub running on the 'OPES intermediary' that
binds a 'remote call-out' to the 'OPES engine' as 'actions'. The
stub marshals the 'action' to/from the 'remote call-out protocol'.
REMOTE CALL-OUT SERVER
A cooperating server that runs 'OPES service modules' as the result
of a 'remote call-out'.
RESOURCE
A network data object or service that can be identified by a URI.
Resources may be available in multiple representations ('variants')
(e.g. multiple languages, data formats, size, resolutions) or vary
in other ways.
ROLE (REFERENCE DEFINITION [POLICY])
An administratively specified characteristic of a managed element
(for example, an interface). It is a selector for policy rules and
'rule modules', to determine the applicability of the rule/'rule
module' to a particular managed element.
Note: The term "Provisioning Class" has been replaced by 'rule
module' in the context of this document, as 'rule modules' are
instances of Provisioning Classes within the OPES application
domain.
RULE
Rules are forms of policy rules [POLICY] that contain 'conditions'
and 'actions' that are to be executed if the 'conditions' are met.
Barbir, et al. Expires September 2003 [Page 8]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
RULE AUTHOR
The rule author is the party that authors and provides a 'rule
module' to the 'OPES admin server'.
RULE MODULE
A rule module is a form of a policy Provisioning Class [POLICY] that
contains a set of 'rules' and information about the rule module
owner. A rule module is either encoded or extracted from a
'subscriber profile', and represent a 'subscriber's personalization
preferences.
SUBSCRIBER
A human being, or user, using a 'client' or 'user agent' to connect
to a network in order to make requests for personalized content or
services.
SUBSCRIBER PROFILE
A subscriber profile consists of a set of elements that define a
'subscriber's personalization preferences. This includes, but is not
limited to a description of the device capabilities, Quality of
Service (QOS), access rate, accounting information, content type
preferences, and policies regarding allowable content. A 'subscriber
profile' may also include 'rule modules' that allow an OPES engine
to perform personalization.
SURROGATE (REFERENCE DEFINITION [RFC-3040])
A gateway co-located with an origin server, or at a different point
in the network, delegated the authority to operate on behalf of, and
typically working in close co-operation with, one or more origin
servers. Responses are typically delivered from an internal cache.
Surrogates may derive cache entries from the origin server or from
another of the origin server's delegates. In some cases a surrogate
may tunnel such requests. Where close co-operation between origin
servers and surrogates exists, this enables modifications of some
protocol requirements, including the Cache-Control directives in
[RFC-2616]. Such modifications have yet to be fully specified.
Devices commonly known as "reverse proxies" and "(origin) server
accelerators" are both more properly defined as surrogates.
TRIGGER
See 'condition'.
USER AGENT [RFC-2616]
The client that initiates a request. These are often browsers,
editors, spiders (web-traversing software "robots"), or other end
user tools.
VARIANT (ALSO: CONTENT VARIANT)
A specific representation of a network data object or service
(resource) identifiable by a URI. A 'variant' is differentiable from
other representations of a resource due to language, data format,
size, resolution or other distinguishing characteristics.
Barbir, et al. Expires September 2003 [Page 9]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Editor's note: does each variant have a different URI? The request
for content (one URI), in combination with the subscriber profile,
allows the OPES engine to perform personalization, and help select
the best variant, but the variant may not have an externally visible
separate URI. Does it matter?
3. What is Service Personalization?
The end goal of any personalization effort is to enable content
services on network traffic in a personalized manner. (i.e. "end
user content that is delivered to clients") Content services can be
further categorized as being in-path services and out-of-path
services. Examples of such services include: virus scanning, content
translation, packet filtering, content adaptation, and others. What
is desired is some means of allowing subscribers to specify
explicitly or implicitly which services should be applied to their
traffic stream, and under what circumstances. The goal of this draft
is to define an open, extensible means of encoding these subscriber
preferences, as well as similar preferences on behalf of the content
owner, and provide a generalized architecture for the application of
these preferences to subscriber content streams. If necessary, one
or more languages will be specified or supplied to express these
preferences. In this regard, such options are already considered
within OPES.
Traditionally, in dial-up and other narrowband applications, the
process of user identification and authentication is closely tied
with the process of machine identification and participation in a
network. As a result, many current content services are designed in
such a way as to perpetuate this link. In the general case (and
certainly in the broadband case), these two functions are separate
and distinct, and represent differing characteristics of a user
session.
There are, in fact, four different categories of information upon
which content services are based. These are:
1) Subscriber Profile Information - Here a subscriber refers to the
human being in the interaction making use of content services.
2) Device Information - This includes access device capabilities,
machine identification, and other factors.
3) Network Topology/Identification Information - This can include
information regarding the network path from Subscriber to Content.
Editor Note: Can this info be considered as the "dynamic" piece of
"device information"?
4) Content Profile Information - This includes content metadata and
other content-related information.
Barbir, et al. Expires September 2003 [Page 10]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
There are several levels of differentiated experience that can be
defined in which the customization of content or content services is
performed based on knowledge of information or influence in some
subset of these categories. These levels can be represented in the
following matrix format:
ED. NOTE: This is preliminary and needs more work! These
categorizations are merely an example and need to be hashed out more
rigorously.
Subscriber Device Network Content
Basic X
Moderate X X
Advanced X X X
Total X X X X
It should be noted that not all forms of differentiated content or
content services constitute personalization. Service Personalization
MUST involve differentiation of content and/or services based on
user or subscriber information. That is, in order for a given form
of differentiation of content or content services to be called
personalized, the differentiation must be performed based at least
on subscriber information.
The precise level of service personalization that can be achieved
depends on where in the network these personalization functions are
deployed, how much access to information those functions have and
the scope of influence these functions have over various aspects of
these information categories.
Editor Note 1: Check for consistency in terminology - should we say
"personalization of content" or "service personalization"? Or is it
truly just "personalization" as it may apply to "services" and
"content"?
Editor Note 2: More here on how different places in the content path
& placement of personalization functions will limit or allow certain
functions in terms of the level of personalization achieved.
In general, service personalization can occur at any point in the
network that has access to the request, the content, the content
profile, and the subscriber profile (content and subscriber profiles
are discussed in a subsequent section). Essentially, any point in
the content path is a potential point at which personalization
decisions could be made. Logically, the points in the content path
reduce to the following scenarios for implementing a personalization
service:
1) service personalization at the content source
2) service personalization at the user agent
3) service personalization at the network edge
4) service personalization at intermediaries such as caching proxies
and surrogates
Barbir, et al. Expires September 2003 [Page 11]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
5) hybrid service personalization approaches.
Each of these is discussed in detail in the sections below.
3.1 Service Personalization at the Content Source
The first option is to perform service personalization at the
content source. This is akin to the current technique of using
portal sites to personalize content. A subscriber logs in to the
portal site, which allows the content source to retrieve the
subscriber's personal profile and preferences. Content is then
dynamically constructed at the content source and delivered to the
subscriber based on those preferences. For relatively small sets of
content, with a reasonably low number of subscribers, this is a
cost-effective solution. There are, however several major drawbacks
to this approach:
1. This solution does not scale well. As the number of concurrent
subscribers increases, performance and reliability degrade
rapidly. This is because the same computing resources that are
used to generate the content are also being used to deliver the
content. Determining which data is required for a given dynamic
content variant, accessing and aggregating the required data,
invoking any application-specific computing required, and
appropriately formatting the content for delivery to a subscriber
is highly compute- and I/O- intensive. In effect, the content
source becomes the bottleneck in the content path.
2. Personalized content can only be delivered from sites that have a
working agreement with the portal. Since explicit registration of
content sources with the portal is required, the applicability of
the subscriber profile is severely limited.
3. Since many such portals exist in the Internet today, subscribers
are required to authenticate themselves with multiple portals,
duplicating and maintaining personal preferences in diverse
locations, which are stored in largely incompatible, un-
standardized formats, with little or no data sharing between
portals. As discussed in section 5.1, the Liberty Alliance and
Microsoft Passport address aspects of this issue.
4. Because subscriber profiles are stored on the portal, subscribers
have little or no real control over where information relating to
their preferences is kept, what information is gathered about
their usage habits, or what parties have access to that
information and what they choose to do with it. This raises some
rather serious privacy concerns.
5. Since content is personalized at the content source, the
applicability of delivered content is severely restricted to at
best a tiny fraction of the overall subscriber audience. This
restriction is due to the fact that compromises are made in
Barbir, et al. Expires September 2003 [Page 12]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
representing a relatively huge subscriber base with a small number
of parameters that represent each subscriber. This means that the
increase in performance nominally provided by caching proxies and
other intermediaries is largely negated.
6. As usage increases, the incremental cost in infrastructure at the
content source to maintain acceptable levels of performance and
reliability increases rapidly. Such infrastructure includes
replication of servers and content storage bolstered with load
balancers and other "data center"/networking equipment to cater to
increased capacity requirements needed to meet the performance and
reliability criteria.
Editor Note: We need to bring out one very critical factor here -
the extra demands put on content creators/authors to be creative
enough to ensure that the content that is delivered in various
personalized forms will actually contain relevant content
components. The authoring process becomes essentially more complex
and time consuming.
3.2 Service Personalization at the User Agent
On the other end of the spectrum (and the content path), one could
consider personalizing content strictly at the user agent. This has
some advantages over the first option. Subscriber preferences and
other information are stored at the user agent, addressing some of
the more serious privacy concerns of the first option. Also,
delivered content will be generic in nature, allowing for more
efficient use of cache technologies. However, these advantages are
offset by several critical drawbacks:
1. Little or no subscriber information is available at the content
source. This precludes virtually any subscriber-specific
application layer functionality from being used on delivered
content at the content source. This is potentially crippling for
the content owners, as it prevents them from providing even the
most basic level of subscriber awareness to the back-end
application layer. This restriction alone makes this a trivially
valuable and unrealistic option.
2. The content services available to the subscriber are entirely
determined by the available functionality and capabilities of
their access device. In many cases (e.g. mobile phones and
handheld PDAs being prime examples), this restriction is
prohibitive. Not only do such devices have extremely limited
computing and display capabilities, but also they are often unable
to make use of large parts of delivered content. A mobile phone,
for example, may not even be able to display straightforward HTML,
let alone high quality images, streaming media, or active content
technologies. This means that the subscriber is left with
virtually useless content. Since the rest of the content path is
completely oblivious to the limitations of such access devices,
Barbir, et al. Expires September 2003 [Page 13]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
very large quantities of useless data will be transferred across
the network, increasing congestion, and adversely affecting the
performance and reliability of the network as a whole.
3. Should the personalization solution be restricted to those access
devices that are capable of providing meaningful content services,
a large segment of potential subscribers will be unable to take
advantage of the added value that personalization delivers.
Consequently, such a solution would be of marginal value.
EDITOR'S NOTE: Perhaps some commentary about benefits of this
scenario should be added.
Example on benefits: In the case of a certain subset of the
subscriber class - user agents on powerful desktops/laptops with
enough compute, storage and network connectivity _ bandwidth etc _
resources, personalization at the access device may not be a bad
option. In fact, many of the personalization functions can be
"offloaded" to these user agents from the content portals; think of
these user agents as running extensions/"avatars" of the
portal/content source. Then, these user agents can transmit relevant
subscriber information back to the portals/sources providing them
with subscriber information.
3.3 Service Personalization at the Network Edge
The network edge, where the subscriber access network meets the rest
of the Internet, presents a somewhat more promising potential
location for the implementation of personalization services. Several
clear advantages exist over the scenarios previously discussed.
1. A trust relationship already exists between the subscriber and
their ISP. The ISP is already responsible for authenticating the
user, authorizing their access to the Internet, and gathering
accounting data related to their service usage. Furthermore, by
necessity, the ISP has pre-existing facilities for storing and
securing subscriber-specific data, and for guaranteeing an agreed-
upon level of privacy.
2. Since content is personalized at the network edge, subscribers
will benefit from the increased performance provided by caching
proxies and other acceleration technologies. This will
significantly reduce network traffic and congestion.
3. The applicability of cached content when servicing requests from
multiple subscribers is increased because personalization occurs
after content is retrieved from source.
4. Content sources will be able to provide higher levels of
throughput at reduced costs because the computations required to
personalize content have been off-loaded, and content output
required from the content source may be greatly diminished as
Barbir, et al. Expires September 2003 [Page 14]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
there are fewer clients (network edge devices) that need to be
served than the typically large numbers of end user devices.
5. Because personalization services are being provided on network
devices located at the network edge, better control over Quality
of Service (QoS) can be achieved.
NOTE: In scenarios where the access network is invariably the
bottleneck link (e.g. wireless telecom networks where a combination
of mechanisms such as DiffServ and overprovisioning are used to
provide service assurances in the wired part of the end-to-end
path), if the edge device is located one network hop away from the
wireless client, it will enable the device to learn the status of
the network and take appropriate actions in a timely manner.
Editor Note: we need to be consistent on the use of "intermediary"
vs. "edge device"; the section 3.4 below defines intermediaries as
different from edge devices; however, are there usages of these
terms which are interchangeable elsewhere in the document?
Editor Note 1: Satisfying the QoS requirements of a user requires
network-wide mechanisms as the bottlenecked link can be anywhere on
the content path. Therefore, in general, we need a feedback loop
running between a client and server of a flow. However, it is
possible in some engineered scenarios, especially in networks with
wireless links that the bottlenecked link is in the last hop. In
such cases alone, the above point may be valid. One interesting
deployment would be to install two intermediaries, one near the
client and one near the server, in effect establishing an edge-to-
edge feedback system providing a range of services that impact the
perceived QoS by the client. (Note: There are multiple "edges" in
the network and every content "hop" is potentially an edge location.
As such, there are opportunities to position intermediaries at these
multiple edges along the way). This idea deserves more careful
examination.
Editor Note 2: It could be argued that QoS assurance or guarantees
is a content service and as such is not a part of core
personalization functionality.
3.4 Service Personalization at Intermediaries
Editor Note: This is where we need to draw attention to the
existing/proposed work and drafts in OPES, centered around proxy
caches etc.)
Network devices on the content path between the client and the
content source are known as intermediaries. Network edge devices,
while technically intermediaries are covered separately in the
previous section. The remaining intermediaries include two types of
commonly used devices that are of particular interest as potential
personalization service platforms. These are caching proxies, and
surrogates. Both of these types of intermediaries have certain
Barbir, et al. Expires September 2003 [Page 15]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
advantages over previously discussed alternatives. However, they
also present added complications, most noticeably in the areas of
privacy and security.
3.4.1 Service Personalization at Caching Proxies
Caching proxies, due to their role and placement in the network,
have some added advantages over network edge devices as platforms
for personalization services. Specifically:
1. Because caching proxies reside at various points in the "core" of
the Internet, but close to the network edge, they are ideally
placed to provide personalization services which are not tied to a
specific service provider, while still minimizing network traffic
to content sources.
2. Caching proxies, by their very nature, already have built-in
functionality for examining network traffic and making decisions
based on the nature of that traffic (i.e. deciding whether or not
to cache a given piece of content).
3. Standardized, well-defined interfaces exist for controlling the
lifecycle of cached content, including deletion, replacement, and
expiry of cached content.
4. Because caching proxies potentially service subscribers from many
ISPs, their audience is much larger. This means that algorithms
for selectively caching certain personalized variants of content
can be contemplated since a larger audience increases the
probability that multiple subscribers will express similar or
identical preferences. For example, if a caching proxy is located
in France, the likelihood that multiple subscribers will request
content translation into French is quite high. This fact has the
potential to allow for significant increases in performance and
overall quality of the subscriber experience.
Editor Note: Contrast these with the statements made in Sec 3.1,
item 5.
5. Well-understood network engineering techniques and technologies
exist to scale the capacity of caching proxies to handle very
large numbers of concurrent subscriber requests efficiently. The
return on investment in such equipment is significantly higher
than for either content sources or network edge devices, and the
incremental improvements in performance and reliability are
effective for a larger audience of subscribers.
These added advantages are offset by some complications and
considerations that must be addressed:
1. Caches are meant to speed up delivery of content to the devices
and any additional processing at these devices impact in the
content delivery process. Since personalization is performed per
Barbir, et al. Expires September 2003 [Page 16]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
subscriber, the performance impact is potentially large enough to
raise concerns on the very purpose caches are meant for _ web
acceleration.
2. There is no pre-existing trust relationship between subscribers
and caching proxies. Because caching proxies do not necessarily
fall under the administrative domain of the ISP or access network,
the facilities provided by the network edge for authentication and
authorization do not cover these devices. Because personalization
services require subscriber-specific information as to their
preferences and policies, there is an increased risk of tampering
and/or invasion of subscriber privacy in transferring such
information to a caching proxy.
3. This means that a mechanism must exist for authenticating a
caching proxy's identity and authorizing its access to subscriber
profile information.
4. No matter what the type of connectivity between the access
network and the caches, steps must be taken to ensure that any
transfer of subscriber profile information is secure.
5. Caching proxies, by design, are intended to operate transparently
to the end user. Since personalization involves the potential
modification, filtering, or other adaptation/alteration of content
received in response to a subscriber request, any personalization
service that resides on a caching proxy must have a mechanism
whereby the subscriber's explicit authorization is required to
enable content adaptation.
6. Since caching proxies' primary function is to cache data,
subscribers must have some means of controlling what (if any)
information contained in the subscriber profile persists on the
device at any time during or after a subscriber session.
7. Once the caching proxy has retrieved subscriber information, a
mechanism must exist to ensure that no access to that information
is allowed by any entity save by the explicit authorization of the
subscriber.
3.4.2 Service Personalization at Surrogates
Surrogates exhibit many of the same characteristics as caching
proxies, and present similar opportunities for optimization of
personalization services as caching proxies. They also pose
comparable challenges. Because of their placement near the content
source, however, the specific advantages and complications are
different enough to warrant closer examination. The placement of
surrogates in the content path presents some unique characteristics
that make them well suited to the implementation of certain kinds of
personalization services:
Barbir, et al. Expires September 2003 [Page 17]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
1. Because surrogates are delegated to operate on behalf of, and
often in close co-operation with one or more content sources, they
provide an ideal platform for the aggregation of related content
from a select set of origins. Personalization services at this
point in the content path can take advantage of more efficient and
practical access to back-end application layer functionality,
allowing for the creation of more dynamic aggregated content,
while allowing for balancing incurred load that such dynamic
content incurs.
2. While the benefits that personalization services enjoy when co-
located with caching proxies with respect to decreased network
traffic are less significant in this scenario, surrogates do
provide the widest possible audience of subscribers for a given
set of content. This means that the odds of certain types
personalized content variants having applicability beyond a single
subscriber request or session are maximized.
3. One very common form of surrogate is the reverse proxy.
Implementation of personalization services on such devices will
allow for potentially large numbers of related content sources to
take advantage of personalization while also leveraging existing
load-balancing and scalability solutions for content sources.
Because reverse proxy network topologies are themselves scalable,
personalization service capacity can be scaled appropriately to
meet subscriber demand for even very high traffic content sources.
As with all other potential platforms for personalization services,
surrogates present their own challenges and issues to be addressed.
Among these are:
1. Because surrogates are closely tied to content sources,
subscriber information will have to be transmitted across a
significant portion of the content path over the public Internet.
This makes the requirement for a secure mechanism for subscriber
profile transfer, and other security and privacy considerations
discussed in Section 3.4.1 even more important.
2. Because surrogates tend to be deployed very near the content
source, the incremental cost in network traffic and bandwidth
significantly offsets the benefits of this approach.
3.5 Hybrid approaches to Service Personalization
It is possible to envision personalization services that are
distributed. That is, ones which reside on more than one of the
previously discussed points in the content path. Such hybrid systems
might allow for more sophisticated decision-
making algorithms to be implemented.
For example: If one were to install personalization services on both
the network edge devices (or even the caching proxies) and the
Barbir, et al. Expires September 2003 [Page 18]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
surrogates, one could establish a feedback loop, or edge-to-edge
system, providing a variety of services that could affect the
perceived QoS of subscriber sessions.
There are many other possible combinations and benefits which could
arise from such hybrid systems. Further investigation of the
possibilities is recommended.
3.6 Goals of FSP
FSP aims to provide a Framework and Protocols for the delivery of
the optimal content variant for a given request to the requestor
based on the subscriber profile and policies, and the content
profile and its associated policies. The next sub-sections discuss
the basic components of FSP.
3.7 Subscriber and Content Profiles
Editor Note: CPExchange and its applicability to FSP.
In order for FSP to be able to deliver to the subscriber the optimal
content variant for their request based on the subscriber profile
and policies, these profiles and policies must be able to completely
describe a subscriber's personalization preferences. To this end, a
precise definition must be developed that allows for the creation of
a subscriber profile that also includes associated policies. The
subscriber profile must also be able to be stored either in a
centralized location, or be distributed across multiple locations in
the Internet, including the user agent.
The Composite Capabilities/Personal Preferences [CC/PP] work
establishes a framework for defining how subscribers may codify
their device capabilities and their preferences about the use of
these capabilities. CC/PP defines a Resource Description Framework
(RDF) schema and associated vocabularies for describing device
capabilities and user preferences. However, a subscriber's profile
may also include other components such as the QoS expected by the
user and the capabilities of the access network through which the
device is connected to the rest of the Internet. In addition, mobile
users may have an elaborate description of how they would like their
service to be adapted as resource levels change during the course of
a long-running network session. A subscriber's profile must
completely encapsulate all of the information about a subscriber
that is needed to make any of the personalization decisions required
for a given content request. This implies that there is the need to
develop a vocabulary for encoding policies within a subscriber's
profile, as well as additional preference information unrelated to
device capabilities. This vocabulary forms a superset of that
defined in the existing CC/PP work.
The set of elements that comprise a subscriber's profile includes
among others a description of the device capabilities, Quality of
Barbir, et al. Expires September 2003 [Page 19]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Service (QoS), access rate, accounting information, and content type
preferences. A subscriber profile also includes policies that define
what constitutes acceptable content (e.g. topic, explicit content,
linked content origin, acceptable manipulations, filtering policies)
that the subscriber is willing to receive. It may also contain
information related to the level of service that a subscriber
considers adequate; for example, trading off cost of service vs.
response time, accuracy etc. (Subscriber A may want to get language
translation free of cost while accepting poor quality, accuracy,
response time; subscriber B may be willing to pay for better
accuracy, response time etc. for translation)
Content profiles and policies, on the other hand, encapsulate
information about the content. This includes information such as
available variants at the content source, encoding method,
dimensions (for graphics), etc. Content profiles and policies also
include information about what is and is not allowed in terms of use
or manipulation of that content (e.g. do not allow legal documents
to be translated into another language, do not perform "down
sampling" of higher quality multimedia/streaming content). A content
provider may provide hints to a personalization intermediary in
choosing the most suitable transformations to apply in some form
(e.g. INFOPYRAMID provides one such representation).
Content policies are an integral part of the content profile for a
given piece of content. A content profile must encapsulate all of
the information about the content which is needed to make any of the
personalization decisions required for that content, including
whether or not a given personalization transformation is allowed.
[RFC-2295] provides the means for automatically and efficiently
retrieving the best content variant from a content source in HTTP.
This specification defines transparent content negotiation as an
extension on top of the HTTP/1.1 protocol [RFC-2616]. This work,
combined with a schema and vocabulary for defining a content profile
that is similar to, and consistent with the subscriber profile,
could provide a sound basis for defining a more generalized,
protocol-independent process for retrieving the appropriate content
variant from the content source. More work will be needed to
incorporate content policy enforcement into this process.
3.8 Content Selection
Content selection involves choosing the most appropriate or optimal
available content variant from a content source for transmission
back to the subscriber. The choice of optimal content source in this
context is restricted to the task of identifying the best content
variant that could be adapted to suit the subscriber. This task is
separate and distinct from the process of choosing the content
source that is optimal from a network perspective, based on network
delay, server load, or other such metrics.
Barbir, et al. Expires September 2003 [Page 20]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
There are various criteria that can be used to determine the most
appropriate content variant to retrieve from the content source. The
simplest of these is choosing a variant that completely or most
closely fits the subscriber's preferences. This is, however, only
one possible form of content selection.
In the event that there is no content variant that completely fits
the subscriber's preferences, alternate content selection criteria
may apply. The task of selecting the most appropriate content
variant may be performed as a function of the ease of translation of
the content into the appropriate format provided that the content
policy allows for the needed adaptation. Here, it is important to
note the distinction between "most appropriate" content to retrieve
from the content source and the "optimal content" to deliver to the
subscriber.
In HTTP Web sites, authors are allowed to store multiple versions of
the same information under a single URL. In [RFC-2295], Transparent
Content Negotiation (TCN) is proposed as a mechanism to select the
best appropriate variant of the content. The TCN mechanism is
layered on top of HTTP, and provides a mechanism for automatically
selecting the best content variant when the URL is accessed.
However, as is discussed in section 3.7 above, further work will be
needed to enhance and generalize the existing TCN architecture to
leverage the capabilities enabled by the content profile.
Some complementary technologies are aimed at enabling the
aggregation of distributed content fragments into a customized whole
at the network edge through the specification of inclusion
mechanisms. Edge Side Includes [ESI] represents one such technology.
ESI provides a means to embed inclusion instructions into content
for execution at the network edge. It also provides mechanisms for
specifying conditions under which such inclusions should be made,
and for invalidating content fragments that are cached at network
intermediaries. This work could be enhanced to allow the
specification of conditions and policies for inclusion within a
subscriber profile, maximizing the effectiveness of ESI for
personalization purposes. Further investigation into this area is
required.
3.9 Quality of Delivery (Origin Server Selection ?)
This criterion only applies in the case where there are multiple
sources from which content can be obtained, and the personalization
framework has some influence over the content source selection. In
this case, it makes some sense to define a quality of delivery
(QoD). In the case where there is only one content source from which
content can be obtained, or where the personalization framework has
no influence over which site gets chosen, quality of delivery
reduces to whatever quality the chosen content source can deliver.
Barbir, et al. Expires September 2003 [Page 21]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Within the scope of an OPES implementation of this framework, there
have been discussions on "late binding" of Rules to Actions and the
Policy framework to allow essentially to select from a variety of
content sources. The selection will be influenced by policies/rules
stipulated on behalf of the end user/subscriber. At this point this
topic will be left unexplored in the interests of clarity of
discussion within OPES.
3.10 Privacy and Security
Privacy issues are an important component of personalization. In
this regard, the issues of privacy that are related to shopping
habits, the willingness to accept or refuse certain type of
advertisement, and subscriber profiling are already addressed by the
Platform for Privacy Preferences [P3P] at W3C. It is important to
note that while P3P provides a technical mechanism to ensure that
the subscriber is informed of the privacy policy of a content
source, it does not specify any mechanism for policy enforcement.
This is an area in which FSP may play a role in strengthening the
enforcement of privacy policies.
Editor Note: Through request anonymization, we may be able to
prevent the content source from gathering metrics that are
undesirable to the subscriber. We have to be careful here, however,
because this will not make some content providers happy.
Additionally, anonymization is really more of a content service than
it is core personalization. Maybe what we have is a selective
anonymization based on privacy policy enforcement during
personalization. We may wish to investigate the technical
feasibility of this idea.
Editor Note: The above should not be a major issue as (1) P3P will
be a fact of life. (2) Personalization can be denied for anonymous
requests?
In performing personalization, there should be a mechanism that
ensures that the transition of a subscriber profile across the
Internet is done in a secure and reliable manner. Furthermore, there
should be a mechanism that authorizes any entity that is interested
in accessing a subscriber profile.
In general, security considerations for personalization must address
the following issues:
1) Subscriber Profile Integrity - FSP must ensure that a subscriber
profile is unadulterated in whole or in part when it reaches a
decision point.
2) Content Profile Integrity - FSP must ensure that a content
profile is unadulterated in whole or in part when it reaches a
decision point.
3) Trust Relationships - There must be a proper mechanism that
decides the entity that is authorized to configure, update,
Barbir, et al. Expires September 2003 [Page 22]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
change, and delete a subscriber profile. There must be a proper
mechanism that authorizes any entity that will perform
personalization across the content adaptation chain. This includes
trusted third parties and repositories.
4) Non-repudiation of request - Non-repudiation of any subscriber
profile configuration/update/change/deletion may be required.
5) Data Confidentiality - Preventing eavesdroppers from gaining
access to a subscriber profile is important. Note that this
requirement is different from subscriber privacy.
4. Security Considerations - Security Threats and Mechanisms
Section 3.10 described several security requirements for FSP. In
this section, we provide a threat analysis for FSP, and discuss
trade-offs between different security mechanisms/solutions.
4.1 Threat Analysis
In this section, we describe a set of threats, their effect on the
system, and the corresponding requirement in order to combat the
threat.
4.1.1 Malicious entity accesses subscriber profile
Threat: A malicious entity is able to access a subscriber profile.
Effect: A subscriber's privacy is compromised.
Requirement: Any access to subscriber profile has to be authorized.
4.1.2 Malicious entity modifies subscriber profile
Threat: A malicious entity is able to configure/modify/delete a
subscriber profile.
Effect: The stored subscriber profile is different from that which
the subscriber desires.
Requirement: There are two scenarios by which a malicious entity may
modify a subscriber profile - one in which the
configuration/modification/deletion request is originated by the
malicious entity, and the other in which an authorized entity issues
the configuration/modification/deletion request which gets modified
by the malicious entity in transit. In order to tackle the first
scenario, any configuration/modification/deletion of subscriber
profile has to be authorized. To tackle the latter case,
additionally, integrity protection of such requests also needs to be
provided.
Barbir, et al. Expires September 2003 [Page 23]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
4.1.3 Eavesdropping on a subscriber profile in transit
Threat: An unauthorized entity eavesdrops on a request to
configure/update/modify a subscriber profile
Effect: The subscriber's privacy is compromised.
Requirement: Data confidentiality of such requests is needed.
4.1.4 Malicious entity accesses content profile
Threat: A malicious entity is able to access a content profile.
Effect: Certain content meta-data that the content owner does not
wish to divulge to unauthorized entities may be divulged. Potential
attackers may also be able to exploit such information to launch
more sophisticated attacks.
Requirement: Any access to content profile has to be authorized.
4.1.5 Malicious entity modifies content profile
Threat: A malicious entity is able to configure/modify/delete a
content profile.
Effect: The stored content profile is different from that which the
content owner desires.
Requirement: There are two scenarios by which a malicious entity may
modify a content profile - one in which the
configuration/modification/deletion request is originated by the
malicious entity, and the other in which an authorized entity issues
the configuration/modification/deletion request which gets modified
by the malicious entity in transit. In order to tackle the first
scenario, any configuration/modification/deletion of content profile
has to be authorized. To tackle the latter case, additionally,
integrity protection of such requests also needs to be provided.
4.1.6 Eavesdropping on a content profile in transit
Threat: An unauthorized entity eavesdrops on a request to
configure/update/modify a content profile
Effect: Certain content meta-data that the content owner does not
wish to divulge to unauthorized entities may be divulged. Potential
attackers may also be able to exploit such information to launch
more sophisticated attacks.
Requirement: Data confidentiality of such requests is needed.
4.1.7 Authorized entity later repudiates a request
Barbir, et al. Expires September 2003 [Page 24]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Threat: An entity that is authorized to make a certain request
claims at a later time that it did not make that request.
Effect: The maintainer of the database of subscriber profiles may be
held liable for unauthorized changes to a subscriber profile.
Similarly, the maintainer of the database of content profiles may be
held liable for unauthorized changes to a content profile.
Requirement: Non-repudiation of requests for
configuring/modification/deletion of subscriber and content profile
needs to be provided.
4.2 Security Mechanisms
One or more appropriate security mechanisms need to be employed in
order to combat the various threats to a FSP system, and to meet the
requirements described earlier. Below, we give a comparison of some
of these mechanisms:
4.2.1 Application layer security designed for FSP
Application layer mechanisms have the advantage of being tailor-made
for the purpose, and hence can be more efficient than other general-
purpose mechanisms. However, care needs to be taken to ensure that
the mechanisms devised are indeed secure.
4.2.2 S/MIME and PGP
Mechanisms such as S/MIME and PGP could be used for providing
security services to the application. These mechanisms provide a
wide range of security services - authentication, integrity,
confidentiality and non-repudiation.
4.2.3 TLS
The Transport Layer Security (TLS) may be used when the underlying
transport is a reliable one. Hence, TLS can be used with TCP but not
with UDP.
4.2.4 IPSec
IPSec provides two headers - Authentication Header (AH) and
Encapsulating Security Payload (ESP) - in order to provide several
security services at the IP layer. Since these security services are
provided at the IP layer, the transport protocol or the application
itself is immaterial to IPSec.
5. Related Personalization Developments
This section will contain information on the Liberty Alliance,
Microsoft Passport, the W3C ([CC/PP], P3P, and Device Independence)
Barbir, et al. Expires September 2003 [Page 25]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
and other developments that are likely to affect the direction of
services offered within the Framework for Service Personalization.
5.1 The Liberty Alliance and Microsoft Passport
The Liberty Alliance and Microsoft Passport are somewhat similar
initiatives. This generic discussion is intended only to address
their relationship with the OPES FSP, and does not differentiate
between them, although there are differences.
These initiatives define specifications for online identification
that can allow individuals to carry their identity from site to
site. They propose a kind of "single sign-on" technology that can
enable an end user to log on at one web site and then allow some
elements of that log-in to be transferred to other participating web
sites.
These initiatives appear to be primarily focused on facilitating
business-to-consumer transactions over the Internet, by simplifying
the process of establishing an identity on the Internet. At this
point, it is not clear whether they address the problem of defining
and maintaining current information on the capabilities of the
user's access device. This is a required part of personalization of
content services within the OPES FSP.
Editor's note: Need to place these initiatives more clearly in the
framework taxonomy, and identify interfaces, etc.
6. Acknowledgments
The majority of the definitions contained in this document have been
obtained from the document entitled: "A Model for Open Pluggable
Edge Services", by G. Tomlinson, et al. [O-MODEL]. This contribution
is gratefully acknowledged.
The authors wish to acknowledge the comments and suggestions
contributed by the members of the FSP mailing list. These people
include: Raffi Uddin, Wil Walkoe, Ram Dantu.
Barbir, et al. Expires September 2003 [Page 26]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
7. References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CALLOUT] Barbir et al, "Requirements for an OPES Service
Personalization Callout Server, draft-barbir-opes-spcs-03.txt
(work in progress) March, 2003.
[O-MODEL] Tomlinson, G., Chen, R. and M. Hofmann, "A Model for Open
Pluggable Edge Services", draft-tomlinson-opes-model-02.txt (work
in progress), July 2001.
[RFC-2616] Fielding, R., et al., "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[RFC-3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[ESFNEP] A. Beck et al, "Example Services for Network Edge
Proxies", draft-beck-opes-esfnep-01.txt (work in progress), June
2001.
[POLICY] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and
S. Waldbusser, "Policy Terminology", RFC 3198, November 2001.
[C-MODEL] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model
for Content Internetworking", draft-ietf-cdi-model-02.txt (work
in progress), May 2002.
[CC/PP] G. Klyne, F. Raynolds, C. Woodrow, H. Ohto, "Composite
Capabilities/Preferences Profiles (CC/PP): Structure and
Vocabularies", March 15, 2001. http://www.w3.org/Mobile/CCPP/.
[RFC-2295] K. Holtman and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, March 1998.
[ESI] Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI Language
Specification 1.0", (M. Nottingham, ed.), 2001,
http://www.esi.org/language_spec_1-0.htm.
[P3P] Platform for Privacy Preferences (P3P1.0) Specification,
http://www.w3.org/TR/2000/CR-P3P-20001215.
8. Authors' Addresses
Abbie Barbir, Ph.D.
Nortel Networks
3500 Carling Avenue
Nepean Ontario K2H 8E9 Canada
Email: Abbieb@nortelnetworks.com
Nicholas Bennett
Nortel Networks
3500 Carling Avenue
Nepean Ontario K2H 8E9 Canada
Email: nbennett@nortelnetworks.com
Barbir, et al. Expires September 2003 [Page 27]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
Reinaldo Penno
Nortel Networks, Inc.
600 Technology Park Drive
Billerica, MA 01821
Email: rpenno@nortelnetworks.com
Rama R. Menon
Intel Corporation
2111 NE 25th Avenue, M/S JF3-206
Hillsboro, OR 97124
Email: rama.r.menon@intel.com
Hien-Thong Pham
Alcatel Bell
Francis Wellesplein 1
B-2018 Antwerp
BELGIUM
Phone: 3-2408630
Email: hien-thong.pham@alcatel.be
Senthil Sengodan, Ph.D.
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: 781-993-3789
Fax: 781-993-1907
Email: senthil.sengodan@nokia.com
Jayanth P. Mysore
Network and Infrastructure Research Laboratory
Motorola Labs
1301 E. Algonquin Road
Schaumburg, IL 60196
Email: jayanth@labs.mot.com
Editor: (Please send comments to Editor)
Paul Knight
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: +1-978-288-6414
Email: paul.knight-at-nortelnetworks.com
Barbir, et al. Expires September 2003 [Page 28]
Internet-Draft draft-barbir-opes-fsp-03.txt March 2003 A Framework for Service Personalization
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Barbir, et al. Expires September 2003 [Page 29]
