Composite Capabilities/Preference Profiles for Content Adaptation

Dr. W.U.Khan Kalyan Bemalkhedkar

Computer Engineering Department
Shri G.S.Institute of Technology and Science
Indore

Abstract
A CC/PP profile is a description of device capabilities and user preferences that can be
used to guide the adaptation of content presented to that device. The Resource
Description Framework (RDF) is used to create profiles that describe user agent and
proxy capabilities and preferences. The structure of a profile in CC/PP includes structure
of client capability and preference descriptions, structure of proxy behavior description,
as this modifies the set of capabilities and preferences to which an origin server may
respond and use of RDF classes to distinguish different elements of a profile, so that a
schema-aware RDF processor can handle CC/PP profiles embedded in other xml
document types. CC/PP vocabulary is identifiers (URIs) used to refer to specific
capabilities and preferences, including the types of values to which CC/PP attributes
may refer, a description of how to introduce new vocabularies, a small client vocabulary
covering print and display capabilities, and a survey of existing work from which new
vocabularies may be derived. This paper attempts to study and analyze CC/PP
(Composite Capabilities/Preference Profiles) structure and vocabularies.

1. Introduction
A CC/PP profile is a description of device capabilities and user preferences that can be
used to guide the adaptation of content presented to that device. As the number and
variety of devices connected to the Internet grows, there is a corresponding increase in
the need to deliver content that is tailored to the capabilities of different devices. Some
limited techniques, such as HTTP 'accept' headers and HTML <alt> tags, already
exist. As part of a framework for content adaptation and contextualization, a general
purpose profile format is required that can describe the capabilities of a user agent and
preferences of its user. CC/PP is designed to be such a format.
CC/PP is based on RDF, the Resource Description Framework, which was designed by
the W3C as a general purpose metadata description language. RDF provides the
framework with the basic tools for both vocabulary extensibility, via XML namespaces,
and interoperability. There is a specification that describes how to encode RDF using
XML, and another that defines an RDF schema description language using RDF. RDF
was designed to describe the metadata or machine understandable properties of the Web.
RDF is a natural choice for the CC/PP framework since user agent profiles are metadata
intended primarily for communication between user agents and resource data providers.
A CC/PP profile contains a number of attribute names and associated values that are
used by a server to determine the most appropriate form of a resource to deliver to a
client. It is structured to allow a client and/or proxy to describe their capabilities by
reference to a standard profile, accessible to an origin server or other sender of resource
data, and a smaller set of features that are in addition to or different than the standard
profile. A set of CC/PP attribute names, permissible values and associated meanings
constitute a CC/PP vocabulary. It is anticipated that different applications will use
different vocabularies; indeed this is needed if application-specific properties are to be
represented within the CC/PP framework.

2. CC/PP architecture
The architecture of the CC/PP is concerned with components and attributes. This has
been explained as follows.

2.1 CC/PP profile structure

A CC/PP profile is broadly constructed as a 2-level hierarchy:
• a profile having a number of components, and
• each component having a number of attributes.

2.1.1 Profile components

The initial branches of the CC/PP profile tree describe major components of the client.
Examples of major components are:
• The hardware platform upon which software is executing,
• The software platform upon which all applications are hosted, or
• An individual application, such as a browser.

Figure 1: Complete CC/PP profile example

[MyProfile]

|
+--ccpp:component-->[TerminalHardware]
| |
| +--rdf:type---> [HardwarePlatform]
| +--display----> "320x200"
|
+--ccpp:component-->[TerminalSoftware]
| |
| +--rdf:type---> [SoftwarePlatform]
| +--name-------> "EPOC"
| +--version----> "2.0"
| +--vendor-----> "Symbian"
|
+--ccpp:component-->[TerminalBrowser]
|
+--rdf:type---> [BrowserUA]
+--name-------> "Mozilla"
+--version----> "5.0"
+--vendor-----> "Symbian"
+--htmlVersionsSupported--> [ ]
 |
-------------------------
|
+--rdf:type---> [rdf:Bag]
+--rdf:_1-----> "3.0"
+--rdf:_2-----> "4.0"

2.1.2 Component attributes

A CC/PP profile describes client capabilities and preferences in terms of a number of
"CC/PP attributes" for each component.The description of each component is a sub-tree
whose branches are the capabilities or preferences associated with that component.
Though RDF makes modeling a wide range of data structures possible, including
arbitrary graphs, complex data models are usually best avoided for profile attribute
values. A capability can often be described using a small number of CC/PP attributes,
each having a simple, atomic value. Where more complex values are needed, these can
be constructed as RDF subgraphs

2.1.3 Defaults
The attributes of a component can be included directly, as in the previous case, or may
be specified by reference to a default profile, which may be stored separately and
accessed using its specified URI. This use of an externally defined default properties is
somewhat similar to the idea of dynamic inheritance. It makes possible some important
optimizations. As a separate document, it can reside at a separate location and it can be
separately cached. This is particularly useful in wireless environments such as cellular
networks, where the profiles may be large and the client link slow and expensive. Using
default values, only a small part of the overall profile is sent over the wireless network.

2.1.4 Proxies and content handling intermediaries

It may be that an intervening network element, such as a transcoding proxy, has
additional capabilities it wishes to advertise on the behalf of its clients. For instance, a
transcoding proxy may be able to convert HTML to WML. The means to provision such
a proxy (meaning to provide or not provide the service for some client) is beyond the
scope of this work. But assuming such a proxy based capability is provided, CC/PP
provides means for a proxy to describe its own capabilities as part of the CC/PP profile
communicated to an origin server.

3. Proxy behavior
The proxy vocabulary is not a mandatory part of the CC/PP specification, but is defined
for use by CC/PP aware applications that may need to deal with proxies or other
intermediaries that play an active role in content handling. Designers of CC/PP
applications that need to deal with mediating behaviors should use this vocabulary rather
than define new structures. A proxy is a component that sits on the network path
between a content consumer and a content provider, and modifies or filters the content
passed toward the consumer. This in turn affects what the provider may send to a given
client, so the consumer's CC/PP information needs to be augmented with information
corresponding to the proxy's behavior. (For typical web access, the origin server is the
provider, and the client is the consumer.)This approach to describing proxy behaviors
does not force a proxy to analyze and rewrite a client profile. Rather, the applicability,
proxyAllow and proxyBlock properties allow a proxy describe its behavior in a way that
takes account of a client's capabilities. As a result, the structure is very easy for a proxy
to create, though it does place some additional responsibility on an origin server to
analyze and combine the various parts appropriately.

4. Capability chaining
A proxy's role as a content modifying component between client and server is
represented by chaining a description of the proxy's behavior to the profile supplied by
the outbound client or proxy. For any given request containing a CC/PP profile, the
proxy creates a new profile that refers to a CC/PP description of itself, and to the CC/PP
capability in the request it received. This new profile is passed on towards the origin
server.

Figure 2: Graph for client and single proxy

[<Request-profile>]
+--proxyProfile--> [<Proxy-profile>]
+--nextProfile---> [<Client-profile>]

5. Request processing in HTTP

CC/PP is envisaged to be used with HTTP in the following fashion:
 +------+ (5) (4) +-------+ +------+
|Client| <==response== | Proxy | <==response== |Origin| <====>
(Resource)
| UA | ===request==> | | ===request==> |server| (3) (
data )
+------+ (1)| +-------+ (2) | +------+
| |
v v
(Client ) <--- (Client profile) <----- (Request profile)
(defaults) + local values |
v
(Proxy ) <--- (Proxy profile)
(defaults) + local values
Figure F-1: HTTP request processing

(i) The client sends an HTTP request, with an accompanying CC/PP client profile.
The client profile may contain references to default profiles describing a range of
common capabilities for the client concerned), and values that are variations from the
default profile.
(ii) The HTTP request may pass through a firewall/proxy that (a) imposes
constraints on the kinds of content that can be accessed, or (b) can adapt other forms of
content to the capabilities of the requesting client. This proxy extends the CC/PP profile
with a description of these constraints and adaptations, and sends this with the HTTP
request on to the origin server. The request may pass through several such proxies.
(iii) The origin server receives the request and interprets the CC/PP profile. It
selects and/or generates content that matches the combined proxy and client capabilities
described in the profile. This is sent to last proxy in request chain in HTTP response.
(iv) If required, the proxy applies any content adaptations, and any other functions it
is designed to perform. The resulting response and content is passed back toward the
requesting client. The client receives the HTTP response and presents the content it
contains.

6. Conclusion
Content Adaptation is becoming very important aspect for development of web based
applications. CC/PP provides a flexible and generic approach for content adaptation on
the internet. The main advantage of CC/PP is that it provides a very convenient way to
describe device capabilities and user preferences that can be used to guide the adaptation
of content presented to that device. This paper has explained the CC/PP architecture,
proxy behavior, capability chaining and request processing in HTTP. These things are
useful for implementing CC/PP based web applications.

References
[1] Conceptual Structures: Information Processing in Mind and Machine; John F. Sowa;
[2] Extensible Markup Language (XML) 1.0; Tim Bray, Jean Paoli, C. M. Sperberg-
McQueen
[3] Resource Description Framework Model and Syntax Specification;Ora Lassila,
Ralph Swick
[4] RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A. Mutz, T.
Hardie;
[5] Composite Capabilities/Preference Profiles: Requirements and Architecture; Mikael
Nilsson,
Johan Hjelm, Hidetaka Ohto;