The CC/PP framework is a mechanism for describing the capabilities and preferences associated with users and user agents accessing the World Wide Web. Information about user agents includes the hardware platform, system software, applications, and user pref- erences (P3P). The user agent capabilities and preferences can be thought of as metadata, or properties and descriptions of the user agent’s hardware and software. The CC/PP descriptions are intended to provide information necessary to adapt the content and the content delivery mechanisms to best fit the capabilities and preferences of the user and its agents.
Instead of enumerating each set of attributes, a reference can be used to name a collection of attributes such as the hardware platform defaults. This has the advantage of enabling the separate fetching and caching of functional subsets.
Another problem is to propagate changes to the current CC/PP descriptions to an origin server, a gateway, or a proxy. One solution is to transmit the entire CC/PP descriptions with each change. This is not ideal for slow networks. An alternative is to send only the changes.
The CC/PP exchange protocol does not depend on the profile format that it conveys. Therefore, another profile format besides the CC/PP description format can be applied to the CC/PP exchange protocol.
The basic requirements for the CC/PP exchange protocol are as follows: 1. The transmissions of the CC/PP descriptions should be HTTP/1.1-compatible. 2. The CC/PP exchange protocol should support an indirect addressing scheme based on
RFC2396 for referencing profile information.
3. Components used to construct CC/PP descriptions, such as vendor default descriptions, should be independently cacheable.
4. The CC/PP exchange protocol should provide a lightweight exchange mechanism that permits the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted.
For example, a user agent issues a request with URIs that address the profile infor- mation, and if the user agent changes the value of an attribute, such as turning sound off, only that change is sent together with the URIs. When an origin server receives the request, the origin server inquires of CC/PP repositories the CC/PP descriptions using the
list of URIs. Then the origin server creates a tailored content using the fully enumerated CC/PP descriptions.
The origin server might not obtain the fully enumerated CC/PP descriptions when any one of the CC/PP repositories is not available. In this case, it depends on the implemen- tation whether the origin server should respond to the request with a tailored content, a nontailored content, or an error. In any case, the origin server should inform the user agent of the fact. A warning mechanism is introduced for this purpose.
It is likely that an origin server, a gateway, or a proxy will be concerned with different device capabilities or user preferences. For example, the origin server may have respon- sibility to select content according to the user-preferred language, while the proxy may have responsibility to transform the encoding format of the content. Therefore, gateways or proxies might not forward all profile information to an origin server.
The CC/PP exchange protocol is based on the HTTP Extension Framework. The HTTP Extension Framework is a generic extension mechanism for HTTP/1.1, which is designed to interoperate with existing HTTP applications.
An extension declaration is used to indicate that an extension has been applied to a message and possibly to reserve a part of the header name space identified by a header field prefix. The HTTP Extension Framework introduces two types of extension declaration strength: mandatory and optional, and two types of extension declaration scope: hop-by- hop and end-to-end.
Which type of the extension declaration strengths and/or which type of the extension declaration scopes should be used depends on what the user agent needs to do.
The strength of the extension declaration should be mandatory if the user agent needs to obtain an error response when a server (an origin server, a gateway, or a proxy) does not comply with the CC/PP exchange protocol. The strength of the extension declaration should be optional if the user agent needs to obtain the nontailored content when a server does not comply with the CC/PP exchange protocol.
The scope of the extension declaration should be hop-by-hop if the user agent has an
a priori knowledge that the first-hop proxy complies with the CC/PP exchange protocol.
The scope of the extension declaration should be end-to-end if the user agent has an
a priori knowledge that the first-hop proxy does not comply with the CC/PP exchange
protocol or the user agent does not use a proxy.
The absoluteURI in the Profile header field addresses an entity of a CC/PP description, which exists in the World Wide Web. CC/PP descriptions may originate from multiple sources (e.g., hardware vendors, software vendors, etc). A CC/PP description that is pro- vided by a hardware vendor or a software vendor should be addressed by an absoluteURI. A user agent issues a request with these absoluteURIs in the Profile header instead of send- ing whole CC/PP descriptions, which contributes to reducing the amount of transaction. The syntax of the absoluteURI must conform to RFC2396.
The scenario of mandatory and end-to-end using the CC/PP exchange protocol is as follows:
1. The user agent issues a mandatory extension request.
2. The origin server examines the extension declaration header and determines if it is supported for this message, if not, it responds with not extended status code.
CC/PP EXCHANGE PROTOCOL BASED ON THE HTTP EXTENSION FRAMEWORK 131
3. Otherwise, the origin server gets the list of the references in the Profile header field. 4. The origin server generates the tailored content according to the enumerated CC/PP
descriptions and sends back the tailored content with the mandatory extension response header.
In this example, the content is not cacheable so that the origin server indicates no-cache directives in the Cache-control header field.
The scenario of the optional and end-to-end using the CC/PP exchange protocol is as follows:
1. The user agent issues an optional extension request.
2. The origin server examines the extension declaration header and determines if it is supported for this message. If not, the origin server ignores the extension headers and sends back the nontailored content.
3. Otherwise, the origin server gets the list of the absoluteURIs in the Profile header field. After that, the origin server issues requests to the CC/PP repositories to get the CC/PP descriptions using these absoluteURIs.
4. The origin server generates the tailored content according to the enumerated CC/PP descriptions and sends back the tailored content.
The scenario of the mandatory and hop-by-hop using CC/PP exchange protocol is as follows:
1. The user agent issues a mandatory extension request.
2. The first-hop proxy examines the extension declaration header and determines if it is supported for this message. If not, it responds with a not extended status code. 3. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the
CC/PP descriptions using the absoluteURIs.
4. The first-hop proxy generates the request with the Accept, Accept-Charset, Accept- Encoding, and Accept-Language, using the enumerated CC/PP descriptions, and issues the request to the origin server.
5. The origin server responds to the first-hop proxy with the content.
6. The first-hop proxy transforms the content into the tailored content using the enumer- ated CC/PP descriptions. After that, the first-hop proxy sends back the tailored content with the mandatory hop-by-hop extension response header.
The scenario of the optional and hop-by-hop by using CC/PP exchange protocol is as follows:
1. The user agent issues an optional extension request.
2. The first-hop proxy examines the extension declaration header and determines if it is supported for this message. If not, the first-hop proxy forwards requests to the origin server after the first-hop proxy removes the headers that are listed in the Connec- tion header.
3. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs.
5. The origin server responds to the first-hop proxy with the content.
6. The first-hop proxy transforms the content into the tailored content using the enumer- ated CC/PP descriptions. After that, the first-hop proxy sends back the tailored content to the user agent.
The scenario of the response with warning using the CC/PP exchange protocol is as follows:
1. The user agent issues a request.
2. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 3. The CC/PP description is obtained successfully from or the CC/PP description could
not be obtained.
4. The origin server generates the tailored content using only the CC/PP description obtained successfully and sends back the tailored content with the Profile-Warning response header. (When the origin server did not obtain the fully enumerated CC/PP descriptions, it depends on the implementation whether the origin server should respond to the request with a tailored content, a nontailored content, or an error.)
The scenario how to enable the HTTP cache expiration model (end-to-end) using CC/PP exchange protocol is as follows:
1. The user agent issues a request.
2. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 3. The origin server generates and sends back the tailored content.
The scenario how to enable the HTTP cache expiration model (hop-by-hop) using the CC/PP exchange protocol is as follows:
1. The user agent issues a request.
2. The first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions.
3. The first-hop proxy generates and issues a request to the origin server. 4. The origin server responds to the first-hop proxy with the content.
5. The first-hop proxy transforms and sends back a tailored content with the Cache-control header, the Vary header, and the Expires header. Therefore the response might be used by the user agent without revalidation.