NOTE-CCPPexchange-19990129
| This version: | http://www.w3.org/TR/1999/NOTE-CCPPexchange-19990129 |
| Latest version: | http://www.w3.org/TR/NOTE-CCPPexchange |
| Authors: | Hidetaka Ohto <ohto@w3.org>, W3C/Panasonic Johan Hjelm <hjelm@w3.org>, W3C/Ericsson |
Copyright © 1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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 Activity. This is work in progress, and future updates and changes are likely. Please send comments and feedback to www-mobile@w3.org.
2. Basic requirements for CC/PP exchange protocol
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 user preferences and device capabilities. 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 URLs 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 HTTP extension called CC/PP exchange protocol to exchange CC/PP information effectively. The CC/PP exchange protocol is based on the HTTP Extension Framework and complies with HTTP/1.1[HTTP].
CC/PP is a mechanism for describing the capabilities and preferences associated with users and user agents accessing the World Wide Web. Information about user agents include the hardware platform, system software, applications and user preferences[P3P]. User agent capabilities and preferences can be thought of as metadata or properties and descriptions of the user agent hardware and software. 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 network performance issues. One strategy is compressed form of XML [TokenXML] and a complementary strategy is to use indirect references.
Instead of enumerating each set of attributes, a indirect 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 description to the server/gateway/proxy. One solution is to transmit the entire CC/PP description with each change. This is not ideal for slow networks. An alternative is to send only the changes.
The CC/PP exchange protocol is independent from the representation of the profiles, which means the CC/PP exchange protocol does not use the CC/PP description specific information, so that the CC/PP exchange protocol can be applied for any other profile description format which is distributed on the Web.
The basic requirements for the CC/PP exchange protocol are listed below.
Our protocol strategy is to send as little information as possible and if anyone is missing something, they have to ask for it.
Consider the following possible interaction between an user agent and an origin server. When the user agent issues a request with a minimal profile using as much indirection(URIs) as possible. If the server/gateway/proxy does not have a CC/PP information for this request, then it asks for one. When a profile is sent, the user agent tries a minimal form, i.e., it uses as much indirection as possible and only names the non default attributes of the profile. The server/gateway/proxy can try to fill in the profile using the indirect references (which should be independently cacheable). If any of these fail, a request for additional data can be sent to the user-agent/gateway/proxy which can respond with a fully enumerated profile. If the user agent changes the value of an attribute, such as turning sound off, only that change needs to be sent.
It is likely that servers and gateways/proxies will be concerned with different preferences. For example, the server may need to know which language the user prefers and the gateway may have responsibility to trim images to 8 bits of color (to save bandwidth). However, the exact use of profile information by each server/gateway/proxy is hard to predict. Therefore gateways/proxies should forward all profile information to the server. Any requests for profile information that the gateway/proxy cannot satisfy should be forwarded to the client.
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 interoperates with exsisting 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 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.
Which type of the extension declaration strength and/or which type of the extension declaration scope should be used depends on what the user agent desires to do.
The strength of the extension declaration should be mandatory if the user agent wants to get a error response from a server or a proxy which does not comply with the CC/PP exchange protocol. The strength of the extension declaration should be optional if the user agent wants to get the non-tailored content without a error or a warning from a server or a proxy which 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 declaration for the CC/PP exchange protocol is as follows:
"http://www.w3.org/TR/NOTE-CCPPexchange"; ns=99-
NOTE: The name of the extension identifier(http://www.w3.org/TR/NOTE-CCPPexchange) and name space prefix(ns=99-) are not fixed yet. The integrity and persistence of the extension identifier should be maintained and kept unquestioned throughout the lifetime of the extension. The header prefix might be generated dynamically when the name space prefix is conflicted by another extension. However the name space prefix should have a "preferred" name because of the cache efficiency.
To minimize content negotiation transactions using indirect references, profile header field is introduced.
The profile header is a general header field which represents indirect references for CC/PP default profiles. The profile header can include the list of indirect reference. Each indirect reference in the list represents capabilities and preferences originating from multiple sources (e.g. hardware vendors, software vendors, users, etc.).
This header field name might be included in Vary header field to express the parameters the server uses to select a representation that is subject to server-driven negotiation. (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 [HTTP1.1].)
The grammar for profile header is as follows:
profile-header = profile-field-name ":" 1#indirect-ref
profile-field-name = "Profile"
indirect-ref = <"> ( absoluteURI | field-name ) <">
The syntax of the absoluteURI described above should conform to RFC2396[RFC2396].
The priority of each indirect reference is implied by the sequence of indirect references in the profile header field in this specification. The priority indicates the order of applying the CC/PP description which is represented by the indirect references in the profile header field.
The indirect reference could be a field-name. The priority is given to the content(CC/PP descriptions or URIs) included in the fileld which is indicated by the field name.
NOTE: The CC/PP descriptions which is indicated by absoluteURIs in a profile header might not be got by an origin server when CC/PP servers(the servers which maintain CC/PP information) are down and/or proxies which are in between the CC/PP servers and the origin server are down. In this case, whether the origin server should respond the tailored contents or not will depend on the implementation. However if the origin server could not get the profile information, the origin server might want to inform the facts to the user agent. The profile warining header might be introduced for the purpose of it.
One of the solution to propagate changes to the current CC/PP information to the server/gateway/proxy is transmitting the entire CC/PP infromatin with each change. It would replace the previous profile. This is not ideal for slow networks. An alternative is to send only the changes. To provide a lightweight exchange mechanism that permits the client to avoid resending the elements of the CC/PP information that have not changed since the last time the information was transmitted, the profile difference header field is introduced.
The profile difference header field is a general header field which represents only the changes of the CC/PP information. Therefore the profile difference header field does not be added to the header, if the CC/PP information have not changed since the last time the information was transmitted.
This header field name might be included in Vary header field to express the parameters the server uses to select a representation that is subject to server-driven negotiation. (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 [HTTP1.1].)
The grammar for profile difference header is as follows:
difference-header = difference-field-name ":" profile-desc
difference-field-name = "Profile-Diff"
profile-desc = < the CC/PP description based on XML/RDF text format(any OCTET except CTLs,but including LWS)>
NOTE: 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 SP. The profile-desc header field vaule described above complies with this HTTP/1.1 specification.
NOTE: Having the HTTP/1.1 cache mechanisms work well, the value of the profile difference header should shape into some kind of canonical representation.
NOTE: To minimise the transactions of CC/PP difference information, we should consider a binary representation of CC/PP. 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 binary representation. the birary representation should be included in the entity body.
To minimize content negotiation transactions using indirect references, dynamic profile reference header field is introduced.
The dynamic profile reference header is a response header field which represents indirect references to the CC/PP information which is maintained on the ultimate receipient(server/gateway/proxy) side. When an ultimate receipent receives a request with a profile difference header from an user agent, the ultimate receipent maintains the CC/PP difference information in itself. The ultimate receipent might merge the CC/PP difference information into the previous CC/PP difference information. The ultimate receipent might generate the dynamic profile reference to indicate the self-maintained CC/PP information when the ulitimate receipent issues a response with dynamic profile reference header.
The dynamic profile reference header can include a URI which indicates the self-maintained CC/PP information on the ultimate recipent side.
The grammar for profile header is as follows:
reference-header = reference-field-name ":" indirect-ref
reference-field-name = "Profile-Ref"
indirect-ref = <"> URI <">
The syntax of the URI described above should conform to RFC2396[RFC2396].
NOTE: The representation for the value of the dynamic profile reference field depends on the implementation of the ultimate receipent(server/gateway/proxy) side. But the value of the dynamic profile reference should be unique on the server side.
The following examples show some scenarios using the CC/PP exchange protocol.
NOTE: The all examples in this document are in the case of mantatory, end-to-end extension. The other case examples will be added in the next version of this document.
The scenario is listed below.
The requests and responses according to the scenario is described below.
[1. UserAgent --> OriginServer] M-GET /a-resource HTTP/1.1 Man: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=99- 99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw" Host: www.w3.org [2. OriginServer --> UserAgent] HTTP/1.1 510 Not Extended [3. OriginServer --> CCPPServers] 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 ....
The scenario is listed below.
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/TR/NOTE-CCPPexchange" ; ns=99-
99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "99-Profile-Diff"
99-Profile-Diff: <?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]
HTTP/1.1 510 Not Extended
[3. OriginServer --> CCPPServers]
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 profile difference header field is too long, the request(1.) might not be successful. Because some implementations of server/proxy/gateway restrict the length of header. The alternative is to transmit runtime changes in an entity body.
[0. UserAgent --> OriginServer]
M-POST /a-resource HTTP/1.1
Host: www.w3.org
Man: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=99-
99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw"
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>
NOTE: In this example, all runtime changes must be transmitted from the user agent to the origin server. The alternative for minimizing runtime exchange is to maintain a dynamic indirect reference on the origin server. The example for minimizing runtime exchange is described in the next example.
The scenario is listed below.
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/TR/NOTE-CCPPexchange" ; ns=99-
99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "99-Profile-Diff"
99-Profile-Diff: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3c.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
[2. OriginServer --> UserAgent]
HTTP/1.1 510 Not Extended
[3. OriginServer --> CCPPServers]
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:
99-Profile-Ref: "urn:md5:PEFjWBDv/sd9a1S9BYuX0w=="
Cache-control: no-cache
Content-Type: text/html
Content-Length: 1200
....
[5. UserAgent --> OriginServer] M-POST /a-resource HTTP/1.1 Host: www.w3.org Man: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=99- 99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "urn:md5:PEFjWBDv/sd9a1S9BYuX0w=="
The scenario is listed below.
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/TR/NOTE-CCPPexchange" ; ns=99-
99-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "99-Profile-Diff"
99-Profile-Diff: <?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]
HTTP/1.1 510 Not Extended
[3. OriginServer --> CCPPServers]
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: max-age=1200, no-cache="Ext"
Vary: Man, 99-Profile, 99-Profile-Diff
Expires: Tue, 05 Jan 1999 16:00:00 GMT
Content-Type: text/html
Content-Length: 1200
....
[HTTPext] HTTP Extension Framework
[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
[TokenXML] Binary XML Content Format Specification
The editors wish to acknowledge the contributions of Henrik Frystyk Nielsen, and the other staff members of the W3C.
