W3C

CC/PP exchange protocol based on HTTP Extension Framework

W3C Note 24 June 1999

This version:
http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624
Latest version:
http://www.w3.org/TR/NOTE-CCPPexchange
Previous version:
http://www.w3.org/1999/04/23-CCPPexchange
Authors:
Hidetaka Ohto <ohto@w3.org>, W3C/Panasonic
Johan Hjelm <hjelm@w3.org>, W3C/Ericsson

The authors wish to acknowledge the contributions of WAP Forum/UAPROF WG members, Franklin Reynolds, Henrik Frystyk Nielsen and staff members of the W3C.


Status of this document

This document is a NOTE made available by the World Wide Web Consortium (W3C) for discussion only. This indicates no endorsement of its content. It is a contribution of selected W3C technical staff to the W3C Mobile Access Activity. This is work in progress, and future updates and changes are likely. Please send comments and feedback to www-mobile@w3.org.

Table of Contents

Abstract

1. Introduction

2. Basic requirements for CC/PP exchange protocol

3. Terminology 

4. Protocol considerations

5. CC/PP exchange protocol

6. Examples

7. Security considerations

References


Abstract

In this document we describe the CC/PP exchange protocol based on the HTTP Extension Framework [HTTPext]. CC/PP [CC/PP], "Composite Capability/Preference Profiles: A user side framework for content negotiation", is an extensible format based on RDF [RDF] [RDF-Schema] for describing device capabilities and user preferences. CC/PP can be provided by the user to servers and content providers. The servers can use this information describing the user's preferences to customize the service or content provided. The ability of RDF to reference profile information via URIs assists in minimizing the number of network transactions required to adapt content to a device, while the CC/PP fits well into the current and future protocols being developed. This document proposes a HTTP extension called "CC/PP exchange protocol" to exchange CC/PP descriptions effectively. The CC/PP exchange protocol is based on the HTTP Extension Framework and complies with HTTP/1.1 [HTTP/1.1].

1. Introduction

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 preferences [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.

The major disadvantage of this format is that it is verbose. Some networks are very slow and this would be a moderately expensive way to handle metadata. There are several optimizations possible to help deal with network performance issues. One strategy is to use a compressed form of XML [WBXML],  and a complementary strategy is to use references(URIs).

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 propogate 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 which it conveys. Therefore another profile format besides the CC/PP description format could be applied to the CC/PP exchange protocol.

2. Basic requirements for CC/PP exchange protocol

The basic requirements for the CC/PP exchange protocol are listed below.

3. Terminology

All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) used by [HTTP/1.1]. Implementors will need to be familiar with the notation in order to understand this specification.

The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "MAY," and "MAY NOT" in this document are to be interpreted as described in RFC 2119 [RFC2119] .

The many terms used in this document are defined and explained in the HTTP/1.1 specification [HTTP/1.1] , including "client," "user agent," "server," "origin server," "proxy," "gateway," "request-header," "response-header," "field-name," "field-value," "end-to-end," "hop-by-hop," "quoted-string," "HTTP-date," "first-hand," "fresh" and "stale". The reader is expected to be familiar with the HTTP/1.1 specification and its terminology.

The following terms are used in this specification.

CC/PP description
The device capabilities and user preferences which are described in the CC/PP framework. A CC/PP description is 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.
CC/PP repository
An application program which maintains CC/PP descriptions. The CC/PP repository should be HTTP/1.0 or HTTP/1.1 compliant. The CC/PP repository is not required to comply with the CC/PP exchange protocol.

4. Protocol considerations

Our protocol strategy is to send a request with profile information as little as possible using references(URIs).

For example, a user agent issues a request with URIs which address the profile information, 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 implementation whether the origin server should respond to the request with a tailored content, a non-tailored content or an error. In any case, the origin server should inform the user agent of the fact. A warning mechanism has been 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 responsibility 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 might convey natural language codes within header field-values. Therefore internationalization issues must be considered. The internationalization policy of the CC/PP exchange protocol is based on RFC2277 [RFC2277].

Considering how to maintain a session like RTSP [RFC2326] is worthwhile from the point of view of minimizing transactions(i.e. the session mechanism could permit the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted). However a session mechanism would reduce cache efficiency, and requires maintaining states between a user agent and an origin server [RFC2109].

The CC/PP exchange protocol is designed as a session-less(stateless) protocol. A session mechanism for exchanging CC/PP is beyond the scope of this specification. It might be designed for the future version of the CC/PP exchange protocol.

5.CC/PP exchange protocol

We propose the CC/PP exchange protocol based on the HTTP Extension Framework. The HTTP Extension Framework is a generic extension mechamism for HTTP/1.1, which is designed to interoperate with existing HTTP applications.

5.1. Extension Declaration

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 namespace identified by a header field prefix. The HTTP Extension Framework introduces two types of extension declaration strenght: mandatory and optional, and two types of extension declaration scope: hop-by-hop and end-to-end(See [HTTPext].)

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 orgin 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 non-tailored 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 apriori 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 apriori 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 extension identifier for the CC/PP exchange protocol is as follows:

"http://www.w3.org/1999/06/24-CCPPexchange"

NOTE: The integrity and persistence of the extension identifier("http://www.w3.org/1999/06/24-CCPPexchange") should be maintained and kept unquestioned throughout the lifetime of the extension. The name space prefix is generated dynamically.(See Section 3. Extension Declarations of [HTTPext].)

5.2. Header fields

5.2.1. Profile header

The Profile header field is a request-header field, which conveys a list of references which address CC/PP descriptions.

The grammar for the Profile header field is as follows:

Profile                = profile-field-name ":" 1#reference
profile-field-name        = "Profile"
reference                = <"> ( absoluteURI | profile-diff-name ) <">
profile-diff-name        = profile-diff-number "-" profile-diff-digest
profile-diff-number        = 1#DIGIT
profile-diff-digest        = sp; < MD5 message digest encoded by base64 >
DIGIT                = <any US-ASCII digit "0".."9">

The Profile header field-value is a list of references. Each reference in the Profile header field represents the corresponding entity of the CC/PP description. A reference is either an absoluteURI or a profile-diff-name. An entity of a CC/PP description which is represented by an absoluteURI exists outside of the request, and an entity of a CC/PP description which is represented by a profile-diff-name exisits inside of the request(i.e. in the Profile-Diff header field. See Section 5.2.2 Profile-Diff header).

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 which is provided 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 sending whole CC/PP descriptions, which contributes to reducing the amount of transaction. The syntax of the absoluteURI MUST conform to RFC2396[RFC2396]. An absoluteURI can unambiguously be distinguished from a profile-diff-name by the presence of a colon(":") in the Profile header field-value.

The profile-diff-name in the Profile header field addresses a CC/PP description in the corresponding Profile-Diff header within the same request. When the Profile header field includes a profile-diff-name, the corresponding Profile-Diff header MUST be included within the same request.

The main reason why the profile-diff-name is introduced is to specify the priority of each CC/PP description in the Profile header field-value. The priority is indicated by the order of references(i.e. absoluteURI or profile-diff-name) in the Profile header field-value. The latest reference in the Profile header field-value has the highest priority. Therefore a CC/PP description which is represented by the latest reference can override CC/PP descriptions which are represented by the precedent references. This is the default behavior in the absence of schema rules.

NOTE: The CC/PP schema provides its own overriding/protection rules. When applying these schema, a CC/PP description which is represented by the latest reference must not override the precedent CC/PP descriptions.

The profile-diff-name consists of a profile-diff-number part and a profile-diff-digest part.

The profile-diff-number is the number which indicates the corresponding Profile-Diff header. Multiple Profile-Diff headers are allowed to appear in the same request. Threfore the profile-diff-number is introduced for the purpose of indicating the corresponding Profile-Diff header. The profile-diff-number is generated, and corresponds to the suffix of the corresponding Profile-Diff  header field-name in the same request.

The profile-diff-digest is generated by applying MD5 message digest algorithm [RFC1321] and Base64 algorithm(See Section 6.8. Base64 Content-Transfer-Encoding in the MIME specification[RFC2045]) to the corresponding Profile-Diff header field-value. The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. The Base64 algorithm takes as input arbitrary binary data and produces as output printable encoding data of the input.

The profile-diff-digest is introduced for the efficiency of  the cache table look up in gateways, proxies and user agent.When the server uses some headers to select a representation that is subject to server-driven negotiation, these headers SHOULD be included in the Vary header field(See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers in [HTTP/1.1].) In that case, with introducing the profile-diff-digest, only the Profile header should be included in the Vary header instead of including the Profile header and the all multiple Profile-Diff headers because the profile-diff-digest(finger print of the Profile-Diff header field-value) could represent the Profile-Diff header field-value. Therefore gateways, proxies and user agent look up and examine only the Profile header for the validation of the cache expiration model.

The generation method of the profile-diff-name is as follows:

  1. The MD5 algorithm is applied to the CC/PP description which is the value of the corresponding Profile-Diff header field.
  2. The Base64 algorithm is applied to the output of step1.
  3. Insert the profile-diff-number at the head of the output of step2.

The examples of the Profile header are as follows:

Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw"
Profile: "http://www.aaa.com/hw","1-uKhJE/AEeeMzFSejsYshHg==","http://www.bbb.com/sw"

NOTE:  There is a choice to put all the references and CC/PP descriptions in one header instead of separating multiple Profile-Diff headers from Profile header. It is simple but we do not introduce this solution. The reasons are as follows:

  1. The headers should be small because some implementations of servers and proxies have the restriction of the header length.
  2. It is difficult to parse the header field when the profile descriptions and URI are mixed within the same header field-value.
  3. The CC/PP exchange protocol aims for independence from the profile format which it conveys. Therefore the mixture of references and profile descriptions is undesirable. ( e.g. when a profile format is required to add an absoluteURI at the top of the profile description, it causes problems.)

5.2.2 Profile-Diff header

The Profile-Diff header field is a request-header field, which contains CC/PP description. The Profile-Diff header field is always used with Profile header in the same request(See Section 5.2.1 Profile header).

All profile information could be represented by absoluteURIs in the Profile header. In this case, the Profile-Diff header field does not have to be added to the request. On the other hand, only one Profile-Diff header can contain all profile information. In this case, the Profile header includes only the profile-diff-name which indicates the Profile-Diff header.

The grammar for the Profile-Diff header field is as follows:

Profile-Diff                = profile-diff-field-name ":" profile-desc
profile-diff-field-name        = "Profile-Diff-" profile-diff-number
profile-desc                = < the CC/PP description based on XML/RDF text format
                                (any OCTET except CTLs,but including LWS)>

The Profile-Diff header field-name(profile-diff-field-name) consists of  the prefix("Profile-Diff-") and the following profile-diff-number.

The profile-diff-number is the number which indicates the corresponding profile-diff-name in the Profile header. Multiple Profile-Diff headers are allowed to appear in the same request. Threfore the profile-diff-number is introduced for the purpose of indicating the corresponding profile-diff-name in the Profile header. The profile-diff-number is generated and corresponds to the prefix of the profile-diff-name in the Profile header field within the same request(See Section 5.2.1 Profile header). The profile-diff-number SHOULD be increased by 1 when a Profile-Diff header is added by a user agent, a gateway, or a proxy.

The examples of the profile-diff-field-name are as follows:

Profile-Diff-1:
Profile-Diff-10:

It MUST NOT be allowed to appear "0" at the head of the profile-diff-number because of avoiding ambiguity of correspondence. (e.g, "Profile-Diff-01:" or "Profile-Diff-0015" is not allowed). Multiple Profile-Diff headers MUST NOT have the same profile-diff-number in the same request.

The format of the profile-desc complies with the HTTP/1.1 specification. The HTTP/1.1 header field-values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as a space(SP).

Having the HTTP/1.1 cache mechanisms work well, the Profile-Diff header field-value SHOULD shape into some kind of canonical representations(See Appendix 2: Fingerprints and Canonicalization in the P3P1.0 Syntax Specification[P3P-Syntax], Canonical XML document in James Clark's Home Page[Canonical-XML]).

NOTE : The canonical representation form will be introduced from the related activities(P3P Syntax WG or XML Syntax WG in W3C) when the specification is fixed.

NOTE: To minimize the transaction of CC/PP descriptions, we might consider a binary representation of a CC/PP description. In this case, the binary representation might not be included within the HTTP header field because of the confliction between CR/LF code and the part of  the binary representation. The birary representation should be included in the entity body. To consider the binary representation is beyond the scope of this specification.

The Profile-Diff header can contain complete CC/PP description. In this case, the Profile header includes only the profile-diff-name which indicates the Profile-Diff header.

The example is as follows:

Profile: "1-P1GRkSjKK50aTWXXndFcSQ=="
Profile-Diff-1: <?xml version="1.0"?>
     <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
          xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
      <Bag>
       <Description about="HardwarePlatform">
        <Defaults>
         <Description PRF:Vendor="Nokia"
                        PRF:Model="2160"
                        PRF:Type="PDA"
                        PRF:ScreenSize="800x600x24"
                        PRF:CPU="PPC"
                        PRF:Keyboard="Yes"
                        PRF:Memory="16mB"
                        PRF:Bluetooth="YES"
                        PRF:Speaker="Yes" />
        </Defaults>
        <Modifications>
         <Description PRF:Memory="32mB" />
        </Modifications>
       </Description>
       <Description about="SoftwarePlatform">
     .....
     </RDF>

5.2.3. Profile-warning header

The Profile-warning header field is a response-header field, which is used to carry warning information.

When a client issues a request with the Profile header field to a server, the server inquires of CC/PP repositories the CC/PP descriptions using the absoluteURIs in the Profile header field.  If any one of the CC/PP repositories is not available, the server might not obtain the fully enumerated CC/PP descriptions, or  the server might not obtain first-hand or fresh CC/PP descriptions.

The server SHOULD respond to the client with the Profile-warning header field if any one of the CC/PP descriptions could not be obtained, or any one of the CC/PP descriptions is stale.

The grammar for the Profile-warning header field is as follows:

Profile-warning                = profile-warning-field-name ":" 1#warning-value
profile-warning-field-name        = "Profile-Warning"
warning-value                = warn-code SP warn-target SP warn-text [SP warn-date]
warn-code                = 3DIGIT
warn-target                = (absoluteURI | host [ ":" port ])
warn-text                        = quoted-string
warn-date                = <"> HTTP-date <">

The definitions of  the absoluteURI and the host are given from RFC2396[RFC2396], and the definitions of the quoted-string and the HTTP-date are given from HTTP/1.1[HTTP/1.1].

The warn-code assignes three digits. The "1xx" indicates the status of the CC/PP description(e.g. it is fresh or stale). The "2xx" indicates the type of the content adaptation applied to the message(e.g. content selection, content transformation, or content generation).

The warn-target indicates either the absoluteURI or the host corresponding to the type of the warn-code. The warn-target indicates the absoluteURI when the warn-code forms "1xx". The warn-target indicates the host when the warn-code forms "2xx".

This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning.

100 OK
MAY be included if the CC/PP repository replies with first-hand or fresh information. The warn-target indicates the absoluteURI which addresses the CC/PP descriptions in the CC/PP repository.
101 Used stale profile
MUST be included if the CC/PP repository replies with stale information.Whether the CC/PP description is stale or not is decided in accordance with the HTTP header information with which the CC/PP repository responds(i.e. when the HTTP/1.1 header includes the Warning header field whose warn-code is 110 or 111.). The warn-target indicates the absoluteURI which addresses the CC/PP description in the CC/PP repository.
102 Not used profile
MUST be included if the CC/PP description could not be obtained(e.g. the CC/PP repository is not available.).The warn-target indicates the absoluteURI which addresses the CC/PP description in the CC/PP repository.
200 Not applied
MUST be included if the server replies with the non-tailored content which is the only one representation in the server. The warn-target indicates the host which addresses the server.
201 Content selection applied
MUST be included if the server replies with the content which is selected from one of the representations in the server. The warn-target indicates the host which addresses the server.
202 Content generation applied
MUST be included if the server replies with the tailored content which is generated by the server. The warn-target indicates the host which addresses the server.
203 Transformation applied
MUST be added by an intermediate proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the response. The warn-target indicates the host which addresses the proxy.

The examples of the Profile-warning header are as follows:

Profile-Warning: 102 http://www.aaa.com/hw "Not used profile",
                202 www.w3.org "Content generation applied"
Profile-Warning: 101 http://www.aaa.com/hw "Used stale profile",
                102 http://www.bbb.com/sw "Not used profile",
                200 18.23.0.23:80 "Not applied"  "Wed, 31 Mar 1999 08:49:37 GMT"

6. Examples

The following examples show some scenarios using the CC/PP exchange protocol.

6.1  Mandatory and end-to-end

The scenario is listed below.

  1. The user agent issues a mandatory extension request(M-GET) with the Profile header and the Profile-Diff header. The Profile-Diff header field-name is generated dynamically. The name space header prefix "99" of the Profile and the Profile-Diff header field-name is generated and correspond to the name space indicator "ns=99" in the extension declaration header(Man). Furthermore, the suffix number "1" of the Profile-Diff header field-name "99-Profile-Diff-1" is generated and corresponds to the prefix "1" of the profile-diff-name "1-uKhJE/AEeeMzFSejsYshHg==" in the Profile header field in the same request. In this example, only one Profile-Diff header field apprears in the request. However multiple Profile-Diff headers could apprear in a request if needed.
  2. The origin server examines the extension declaration header and determines if it is supported for this message, If not, it responds with a 510(Not Extended) status code.
  3. Otherwise the origin server splits the "M-" prefix from the method name and processes the remainder of the request according to the semantic of the extension and of the existing HTTP/1.1 method name(GET), and then the origin server gets the list of the references(i.e. absoluteURI and profile-diff-name) in the Profile header field. After that the origin server issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs("http://www.aaa.com/hw","http://www.bbb.com/sw"). These requests/reponses can be cached by the usual HTTP cache mechanisms so that these requests are HTTP requests.
  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(Ext). In this example, the content is not cacheable so that the origin server indicates no-cache directives in the Cache-control header field.

The requests and responses according to the scenario is described below.

   [1. UserAgent --> OriginServer]
        M-GET /a-resource HTTP/1.1
        Host: www.w3.org
        Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=99
        99-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
        99-Profile-Diff-1: <?xml version="1.0"?>
                <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                <Description ID="SoftwarePlatform" PRF:Sound="On" />
                </RDF>

   [2. OriginServer --> UserAgent (case of failure)]
        HTTP/1.1 510 Not Extended

   [3. OriginServer --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [4. OriginServer --> UserAgent]
        HTTP/1.1 200 OK
        Ext: 
        Cache-control: no-cache
        Content-Type: text/html
        Content-Length: 1200
        ....

NOTE: If the Profile-Diff header field is too long, the request(1.) might not be successful because some implementations of origin server/gateway/proxy restrict the length of headers. The alternative is to transmit runtime changes in an entity body. This solution is beyond the scope of the CC/PP exchange protocol.

   [0. UserAgent --> OriginServer]
        M-POST /a-resource HTTP/1.1
        Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=99
        99-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","uKhJE/AEeeMzFSejsYshHg=="
        Host: www.w3.org
        Content-Type: text/xml
        Content-Length: 258
        
        <?xml version="1.0"?>
        <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
        xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
        <Description ID="SoftwarePlatform" PRF:Sound="On" />
        </RDF> 

6.2  Optional and end-to-end

The scenario is listed below.

  1. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header.
  2. The origin server examines the extension declaration header(Opt) and determines if it is supported for this message. If not, the origin server ignores the extension headers, and sends back the non-tailored 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 requests and responses according to the scenario is described below.

   [1. UserAgent --> OriginServer]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        Opt: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=19
        19-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
        19-Profile-Diff-1: <?xml version="1.0"?>
                <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                <Description ID="SoftwarePlatform" PRF:Sound="On" />
                </RDF>
                
   [2. OriginServer --> UserAgent (case of failure)]
        HTTP/1.1 200 OK
        Content-Type: text/html
        Content-Length: 1200
        ....
        <!-- non-tailored content -->

   [3. OriginServer --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [4. OriginServer --> UserAgent]
        HTTP/1.1 200 OK
        Cache-control: no-cache
        Content-Type: text/html
        Content-Length: 1200
        ....

6.3  Mandatory and hop-by-hop

The scenario is listed below.

  1. The user agent issues a mandatory extension request(M-GET) with the Profile header and the Profile-Diff header. According to the HTTP extension framework specification for the hop-by-hop extension, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. In this example, "C-Man", "64-Profile" and "64-Profile-Diff-1" are protected by the Connect header field.
  2. The first-hop proxy examines the extension declaration header(C-Man) and determines if it is supported for this message. If not, it responds with a 510(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 enumerated CC/PP descriptions. After that the first-hop proxy sends back the tailored content with the mandatory hop-by-hop extension response header(C-Ext).

The requests and responses according to the scenario is described below.

   [1. UserAgent --> Proxy]
        M-GET /a-resource HTTP/1.1
        Host: www.w3.org
        C-Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=64
        64-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg=="
        64-Profile-Diff-1: <?xml version="1.0"?>
                <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                <Description ID="SoftwarePlatform" PRF:Sound="On" />
                </RDF>
        Connection: C-Man, 64-Profile, 64-Profile-Diff-1
        
   [2. Proxy --> UserAgent (case of failure)]
        HTTP/1.1 510 Not Extended

   [3. Proxy --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [4. Proxy --> OriginServer]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        Accept: text/xml, text/html, */*
        Accept-Charset: UTF-16, iso-2022-JP
        Accept-Encoding: compress, gzip
        Accept-Language: ja, en

   [5. OriginServer --> Proxy]
        HTTP/1.1 200 OK
        Cache-control: no-cache
        Content-Type: text/html; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 1200
        ....

   [6. Proxy --> UserAgent]
        HTTP/1.1 200 OK
        C-Ext: 
        Cache-control: no-cache
        Content-Type: text/xml; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 900
        ....

6.4  Optional and hop-by-hop

The scenario is listed below.

  1. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header.
  2. The first-hop proxy examines the extension declaration header(C-Opt) and determines if it is supported for this message. If not, the first-hop proxy foreward requests to the origin server after the first-hop proxy get rid of the headers which are listed in the Connection header.
  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 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 enumerated CC/PP descriptions. After that the first-hop proxy sends back the tailored content to the user agent.

The requests and responses according to the scenario is described below.

   [1. UserAgent --> Proxy]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        C-Opt: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=80
        80-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg=="
        80-Profile-Diff-1: <?xml version="1.0"?>
                <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                <Description ID="SoftwarePlatform" PRF:Sound="On" />
                </RDF>
        Connection: C-Opt, 80-Profile, 80-Profile-Diff-1
        
   [2. Proxy --> OriginServer (case of failure)]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        
   [3. Proxy --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [4. Proxy --> OriginServer]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        Accept: text/xml, text/html, */*
        Accept-Charset: UTF-16, iso-2022-JP
        Accept-Encoding: compress, gzip
        Accept-Language: ja, en

   [5. OriginServer --> Proxy]
        HTTP/1.1 200 OK
        Cache-control: no-cache
        Content-Type: text/html; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 1200
        ....

   [6. Proxy --> UserAgent]
        HTTP/1.1 200 OK
        Cache-control: no-cache
        Content-Type: text/xml; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 900
        ....

6.5. Response with Warning

The scenario is listed below.

  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(200 OK) from "http://www.aaa.com/hw", while the CC/PP description could not be obtained (404 Not Found) from "http://www.bbb.com/sw".
  4. The origin server generates the tailored content using only the CC/PP description from "http://www.aaa.com/hw", 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 non-tailored content or an error.)

The requests and responses according to the scenario is described below.

   [1. UserAgent --> OriginServer]
        M-GET /a-resource HTTP/1.1
        Host: www.w3.org
        Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=25
        25-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw"

   [2. OriginServer --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [3. CCPPrepositories --> OriginServer]
        HTTP/1.1 200 OK                ;; www.aaa.com
        ....

        HTTP/1.1 404 Not Found        ;; www.bbb.com
        
   [4. OriginServer --> UserAgent]
        HTTP/1.1 200 OK
        Ext: 
        25-Profile-warning: 102 http://www.bbb.com/sw "Not used profile",
                            202 www.w3.org "Content generation applied"
        Cache-control: no-cache
        Content-Type: text/html
        Content-Length: 1200
        ....

6.6. Enable the HTTP cache expiration model(end-to-end)

The scenario is listed below.

  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. In this example, the origin server indicates no-cache="Ext" and max-age=1200 directives in the Cache-control header field, which means the origin server intends to use the HTTP cache expiration model. The Vary header and the Expires header are also included. Therefore the response which is cached along the request/response chain might be used without revalidation with the origin server. The Profile-Diff header field does not have to be included in the Vary header field because the change of the Profile-Diff header is represented by profile-diff-name "1-uKhJE/AEeeMzFSejsYshHg==" in the Profile header field.

The requests and responses according to the scenario is described below.

   [1. UserAgent --> OriginServer]
        M-GET /a-resource HTTP/1.1
        Host: www.w3.org
        Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=70
        70-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg=="
        70-Profile-Diff-1: <?xml version="1.0"?>
                <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                <Description ID="SoftwarePlatform" PRF:Sound="On" />
                </RDF> 
        
   [2. OriginServer --> CCPPRepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [3. OriginServer --> UserAgent]
        HTTP/1.1 200 OK
        Ext: 
        Cache-control: max-age=1200, no-cache="Ext"
        Vary: Man, 70-Profile
        Expires: Tue, 05 Mar 1999 16:00:00 GMT
        Content-Type: text/html
        Content-Length: 1200
        ....

6.7. Enable the HTTP cache expiration model(hop-by-hop)

The scenario is listed below.

  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.

The requests and responses according to the scenario is described below.

   [1. UserAgent --> Proxy]
        M-GET /a-resource HTTP/1.1
        Host: www.w3.org
        C-Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=67
        67-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg=="
        67-Profile-Diff-1: <?xml version="1.0"?>
                        <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                        xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                        <Description ID="SoftwarePlatform" PRF:Sound="On" />
                        </RDF>
        Connection: C-Man, 67-Profile
        
   [2. Proxy --> CCPPrepositories]
        GET http://www.aaa.com/hw HTTP/1.1
        Host: www.aaa.com
        ....

        GET http://www.bbb.com/sw HTTP/1.1
        Host: www.bbb.com
        ....

   [3. Proxy --> OriginServer]
        GET /a-resource HTTP/1.1
        Host: www.w3.org
        Accept: text/xml, text/html, */*
        Accept-Charset: UTF-16, iso-2022-JP
        Accept-Encoding: compress, gzip
        Accept-Language: ja, en

   [4. OriginServer --> Proxy]
        HTTP/1.1 200 OK
        Content-Type: text/html; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 1200
        Vary: Content-Type, Content-Encoding, Content-Language, Content-Length
        Expires: Tue, 05 Mar 1999 16:00:00 GMT
        ....

   [5. Proxy --> UserAgent]
        HTTP/1.1 200 OK
        C-Ext: 
        Cache-control: max-age=1200, no-cache="C-Ext"
        Content-Type: text/xml; charset=UTF-16
        Content-Encoding: compress
        Content-Language: ja
        Content-Length: 900
        Vary: C-Man, 67-Profile
        Expires: Tue, 05 Mar 1999 16:00:00 GMT
        ....

7. Security considerations

The Profile and Profile-diff headers can reveal information about the hardware, software and user preferences to all servers which are accessed. Especially when headers in which the user preferences is included, implementers are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved.

This specification allows gateways/proxies which are in between a user agent and an origin server to add multiple CC/PP descriptions. This opens to attacks by malicious/inadvertent gateways/proxies.

In addition, the security considerations of this specifcation are the same as those of the HTTP Extension Framework.

References

[HTTPext] HTTP Extension Framework

[HTTP/1.1] HTTP/1.1, Rev6

[CC/PP] Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation

[RDF] Resource Description Framework, (RDF) Model and Syntax Specification

[RDF-Schema] Resource Description Framework (RDF) Schema Specification

[P3P] Platform for Privacy Preferences P3P Project

[RFC2396] RFC 2396 : Uniform Resource Identifiers (URI): Generic Syntax

[RFC2119] RFC 2119 : Key words for use in RFCs to Indicate Requirement Levels

[RFC2277] RFC 2277 : IETF Policy on Character Sets and Languages

[RFC1321] RFC 1321 : The MD5 Message-Digest Algorithm

[RFC2045] RFC 2045 : Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies

[RFC2109] RFC 2109 : HTTP State Management Mechanism

[RFC2326] RFC 2326 Real Time Streaming Protocol(RTSP)

[WBXML] Binary XML Content Format Specification

[P3P-Syntax] Platform for Privacy Preferences (P3P1.0) Syntax Specification Appendix 2: Fingerprints and Canonicalization

[Canonical-XML] Canonical XML


Valid HTML 4.0!  Made with CSS