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 Contents2. Basic requirements for CC/PP exchange protocol
AbstractIn 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. IntroductionThe 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 protocolThe basic requirements for the CC/PP exchange protocol are listed below.
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.
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 protocolWe 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 DeclarationAn 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 headerThe 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:
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:
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.
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-endThe 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/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.
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.
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.
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.
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.
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.
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
[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3