Mobile Computing

CC/PP (Chap-2)
Overview

The goal of the CC/PP framework is to specify how client devices express their capabilities and
preferences (the user agent profile) to the server that originates content (the origin server). The
origin server uses the "user agent profile" to produce and deliver content appropriate to the client
device. In addition to computer-based client devices, particular attention is being paid to other
kinds of devices such as mobile phones.

Architecture

The basic problem that the CC/PP framework addresses is to create a structured and universal
format for how a client device tells an origin server about its user agent profile. This work aims
to present a container that can be used to convey the profile, and is independent on the protocols
used to transport it. It does not present mechanisms or protocols to facilitate the transmission of
the profile.

The framework describes a standardized set of CC/PP attributes - a vocabulary - that can be used
to express a user agent profile in terms of capabilities, and the users preferences for the use of
these capabilities. This is implemented using the XML [XML] application RDF [RDF]. This
enables the framework to be flexible, extensible, and decentralized, thus fulfilling the
requirements.

RDF is used to express the client device's user agent profile. The client device may be a
workstation, personal computer, mobile terminal, or set-top box.

When used in a request-response protocol like HTTP, the user agent profile is sent to the origin
server which, subsequently, produces content that satisfies the constraints and preferences
expressed in the user agent profile. The CC/PP framework may be used to convey to the client
device what variations in the requested content are available from the origin server.

Fundamentally, the CC/PP framework starts with RDF and then overlays a CC/PP-defined set of
semantics that describe profiles.

The CC/PP framework does not specify whether the client device or the origin server initiates
this exchange of profiles. What the CC/PP framework does specify is the RDF usage and
associated semantics that should be applied to all profiles that are being exchanged.

(1) Background

Using the World Wide Web with content negotiation as it is designed today enables the selection
of a variant of a document. Using an extended capabilities description, an optimized presentation
can be produced. This can take place by selecting a style sheet that is transmitted to the client, or
by selecting a style sheet that is used for transformations. It can also take place through the
generation of content, or transformation, e.g. using XSLT [XSLT].
Prepared By: Chintan Bhatt. Page 1
Mobile Computing

The CC/PP Exchange Protocol [CCPPex] extends this model by allowing for the transmission
and caching of profiles, and the handling of profile differences.

This use case in itself consists of two different use cases: The origin server receives the CC/PP
profile directly from the client; the origin server retrieves the CC/PP profile from an intermediate
repository.

(2) Profile is communicated directly to origin server

This use case describes a case where the profile is used by an origin server on the web to adapt
the information returned in the request.

The CC/PP Exchange Protocol [HTTPex] creates a modified HTTP GET which carries the
profile or the profile difference. The extended content negotiation with the CC/PP Exchange
Protocol uses the CC/PP format to describe the device. In this context, no vocabulary has been
defined. The existence of the CC/PP Exchange protocol is assumed.

(2.1) Protocol interactions

Figure 1: The HTTP use case

When the interaction passes directly between a client and a server, the process is relatively
simple: The user agent sends the profile information with the request, and the server returns
adapted information. The interaction takes place over an extended HTTP method, as described in
the CC/PP Exchange framework.

(3) CC/PP profile is retrieved from repository

When the profile is composed by resolving inline references from a repository for the profile
information, the process is slightly more complicated, but in principle the same.

Prepared By: Chintan Bhatt. Page 2

Mobile Computing

Figure 2: The HTTP use case with repository for the profile information

The interactions take place in more steps, but is basically the same:

1: Request from client with profile information.

2: Server resolves and retrieves profile (from CC/PP repository on the network), and uses it to
adapt the content.

4: Server returns adapted content.

5: Proxy forwards response to client.

Note that the notion of a proxy resolving the information and retrieving it from a repository
might assume the use of an XML processor and encoding of the profile in XML.

(4) The document profile use case

In case the document contains a profile, the above could still apply. However, there will be some
interactions inside the server, as the client profile information needs to be matched with the

Prepared By: Chintan Bhatt. Page 3

Mobile Computing

document profile. The interactions in the server are not defined. This group will not standardize
the matching algorithm. We will standardize the profile system, which is the interface to it.

Figure 3: The document profile usecase

1. Request (extended method) with profile information.

2. Document profile is matched against device profile to derive optimum representation.
3. Document is adapted.
4. Response to client with adapted content.

Prepared By: Chintan Bhatt. Page 4