[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

DOCTYPE HTML PUBLIC DTD HTML

Found at: ftp.icm.edu.pl:70/packages/normos/w3c/NOTE-CCPPexchange

<!DOCTYPE  HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
   "http://www.w3.org/TR/REC-html40/loose.dtd"><HTML>
<HEAD>
<META CONTENT="$Id: NOTE-CCPPexchange-19990624.html,v 1.6 1999/06/24 21:09:56 renaudb Exp $" NAME="RCS-Id">
<TITLE>CC/PP exchange protocol using HTTP Extension Framework</TITLE>
<LINK TYPE="text/css" REL="stylesheet" HREF="http://www.w3.org/StyleSheets/TR/W3C-NOTE.css">
</HEAD>
<BODY>

		
<DIV CLASS="head">

		
<A HREF="http://www.w3.org/"><IMG STYLE="border: none" HEIGHT="48" ALIGN="left" ALT="W3C" BORDER="0" WIDTH="72" SRC="http://www.w3.org/Icons/WWW/w3c_home">
</A>

		
<H1>CC/PP exchange protocol based on HTTP Extension Framework</H1>
<H2>W3C Note 24 June 1999</H2>

		
<DL>
<DT>
This version:
<DD>
<A CLASS="loc" HREF="http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624">http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624</A>
<DT>
Latest version:
<DD>
<A CLASS="loc" HREF="NOTE-CCPPexchange" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange">http://www.w3.org/TR/NOTE-CCPPexchange</A>
<DT>
Previous version:
<DD>
<A CLASS="loc" HREF="http://www.w3.org/1999/04/23-CCPPexchange">http://www.w3.org/1999/04/23-CCPPexchange</A>
<DT>
Authors:
<DD>
Hidetaka Ohto &lt;<A HREF="mailto:/ohto@w3.org">ohto@w3.org</A>>,
W3C/Panasonic<BR>
Johan Hjelm &lt;<A HREF="mailto:/hjelm@w3.org">hjelm@w3.org</A>>, W3C/Ericsson
</DL>
<P>The authors wish to acknowledge the contributions of WAP Forum/UAPROF WG
members, Franklin Reynolds, Henrik Frystyk Nielsen and staff members of the
W3C.</P>

		
<P CLASS="copyright"><A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">Copyright</A>
&nbsp;&copy;&nbsp; 1999 <A HREF="http://www.w3.org/">W3C</A> (<A HREF="http://www.lcs.mit.edu/">MIT</A>, <A HREF="http://www.inria.fr/">INRIA</A>, <A HREF="http://www.keio.ac.jp/">Keio</A>), All Rights Reserved. W3C <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal%0ADisclaimer">liability</A>, <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C%0ATrademarks">trademark</A>, <A HREF="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use </A>and <A HREF="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing </A>rules apply.</P>
<HR TITLE="Separator for Header">
</DIV>

		
<H2><A NAME="status">Status of this document</A></H2>

		
<P>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 <A HREF="http://www.w3.org/Mobile/Activity">W3C Mobile Access Activity</A>. This
is work in progress, and future updates and changes are likely. Please send
comments and feedback to <A HREF="mailto:/www-mobile@w3.org">www-mobile@w3.org</A>.</P>

		
<H2>Table of Contents</H2>

		
<P><A HREF="#Abstract" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#Abstract">Abstract</A></P>

		
<P><A HREF="#1" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#1">1. Introduction</A></P>

		
<P><A HREF="#2" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#2">2. Basic requirements for CC/PP exchange protocol</A></P>

		
<P><A HREF="#3" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#3">3. Terminology</A>&nbsp;</P>

		
<P><A HREF="#4" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#4">4. Protocol considerations</A></P>

		
<P><A HREF="#5" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#5">5. CC/PP exchange protocol</A></P>

		
<P><A HREF="#6" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#6">6. Examples</A></P>

		
<P><A HREF="#7" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#7">7. Security considerations</A></P>

		
<P><A HREF="#References" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#References">References</A></P>
<HR>

		

		
<H2><A NAME="Abstract">Abstract</A></H2>

		
<P>In this document we describe the CC/PP exchange protocol based on the HTTP
Extension Framework [<A HREF="#%5BHTTPext%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTPext%5D">HTTPext</A>]. CC/PP [<A HREF="#%5BCCPP%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BCCPP%5D">CC/PP</A>], "Composite Capability/Preference Profiles: A user
side framework for content negotiation", is an extensible format based on RDF
[<A HREF="#%5BRDF%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRDF%5D">RDF</A>] [<A HREF="#%5BRDF-Schema%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRDF-Schema%5D">RDF-Schema</A>] 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 [<A HREF="#%5BHTTP/1.1%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTP/1.1%5D">HTTP/1.1</A>].</P>

		
<H2><A NAME="1">1. Introduction</A></H2>

		
<P>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 [<A HREF="#%5BP3P%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BP3P%5D">P3P</A>]. The
user agent capabilities and preferences can be thought of as metadata,&nbsp;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.</P>

		
<P>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 [<A HREF="#%5BWBXML%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BWBXML%5D">WBXML</A>], &nbsp;and a complementary strategy is to use
references(URIs).</P>

		
<P>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.</P>

		
<P>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.</P>

		
<P>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.</P>

		
<H2><A NAME="2">2. Basic requirements for CC/PP exchange protocol</A></H2>

		
<P>The basic requirements for the CC/PP exchange protocol are listed
below.</P>
<UL>
<LI>
The transmissions of the CC/PP descriptions should be HTTP/1.1-compatible.
</LI>
<LI>
The CC/PP exchange protocol should support an indirect addressing scheme based
on RFC2396 [<A HREF="#%5BRFC2396%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2396%5D">RFC2396</A>] for referencing profile
information.
</LI>
<LI>
Components used to construct CC/PP descriptions, such as vendor default
descriptions, should be independently cacheable.
</LI>
<LI>
The CC/PP exchange protocol should provide a lightweight exchange mechanism
that permits the client to avoid resending the elements of the CC/PP
descriptions that have not changed since the last time the information was
transmitted.
</LI>
</UL>

		
<H2><A NAME="3">3. Terminology</A></H2>

		
<P>All of the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur Form (BNF) used by [<A HREF="#%5BHTTP/1.1%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTP/1.1%5D">HTTP/1.1</A>]. Implementors will need to be familiar with
the notation in order to understand this specification.</P>

		
<P>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 [<A HREF="#%5BRFC2119%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2119%5D">RFC2119</A>] .</P>

		
<P>The many terms used in this document are defined and explained in the
HTTP/1.1 specification [<A HREF="#%5BHTTP/1.1%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTP/1.1%5D">HTTP/1.1</A>] , 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.</P>

		
<P>The following terms are used in this specification.</P>
<DL>
<DT>CC/PP description</DT>
<DD>
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.
</DD>
<DT>CC/PP repository</DT>
<DD>
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.
</DD>
</DL>

		
<H2><A NAME="4">4. Protocol considerations</A></H2>

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

		
<P>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.</P>

		
<P>The origin server might not obtain the fully&nbsp;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.</P>

		
<P>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 &nbsp;the content. Therefore gateways or proxies
might&nbsp;not forward all profile information to an origin server.</P>

		
<P>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 [<A HREF="#%5BRFC2277%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2277%5D">RFC2277</A>].</P>

		
<P>Considering how to maintain a session like RTSP [<A HREF="#%5BRFC2326%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2326%5D">RFC2326</A>] is worthwhile&nbsp;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 [<A HREF="#%5BRFC2109%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2109%5D">RFC2109</A>].</P>

		
<P>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.</P>

		
<H2><A NAME="5">5.CC/PP exchange protocol</A></H2>

		
<P>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.</P>

		
<H3><A NAME="51">5.1. Extension Declaration</A></H3>

		
<P>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 [<A HREF="#%5BHTTPext%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTPext%5D">HTTPext</A>].)</P>

		
<P>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.</P>

		
<P>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, &nbsp;a
gateway or a proxy)&nbsp;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.</P>

		
<P>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.</P>

		
<P>The extension identifier for the CC/PP exchange protocol is as follows:</P>
<PRE>"http://www.w3.org/1999/06/24-CCPPexchange"</PRE>

		
<P>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 [<A HREF="#%5BHTTPext%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTPext%5D">HTTPext</A>].)</P>

		
<H3><A NAME="52">5.2. Header fields</A></H3>

		
<H4><A NAME="521">5.2.1. Profile header</A></H4>

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

		
<P>The grammar for the Profile header field is as follows:</P>
<PRE>Profile                = profile-field-name ":" 1#reference
profile-field-name        = "Profile"
reference                = &lt;"> ( absoluteURI |&nbsp;profile-diff-name ) &lt;">
profile-diff-name        = profile-diff-number "-" profile-diff-digest
profile-diff-number        = 1#DIGIT
profile-diff-digest        = sp; &lt; MD5 message digest encoded by base64 >
DIGIT                = &lt;any US-ASCII digit "0".."9"></PRE>

		
<P>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.&nbsp;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 <A HREF="#522" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#522">Section 5.2.2 Profile-Diff
header</A>).</P>

		
<P>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. &nbsp;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[<A HREF="#%5BRFC2396%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2396%5D">RFC2396</A>]. An absoluteURI can unambiguously be
distinguished from a profile-diff-name by the presence of a colon(":") in the
Profile header field-value.</P>

		
<P>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.</P>

		
<P>The main reason why the profile-diff-name is introduced is to
specify&nbsp;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.</P>

		
<P>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.</P>

		
<P>The profile-diff-name consists of a profile-diff-number part and a
profile-diff-digest part.</P>

		
<P>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 &nbsp;header field-name in the same request.</P>

		
<P>The profile-diff-digest is generated by applying MD5 message digest
algorithm [<A HREF="#%5BRFC1321%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC1321%5D">RFC1321</A>] and Base64 algorithm(See Section
6.8. Base64 Content-Transfer-Encoding in the MIME specification[<A HREF="#%5BRFC2045%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2045%5D">RFC2045</A>]) 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.</P>

		
<P>The profile-diff-digest is introduced for the efficiency of &nbsp;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 [<A HREF="#%5BHTTP/1.1%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTP/1.1%5D">HTTP/1.1</A>].) 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.</P>

		
<P>The generation method of the profile-diff-name&nbsp;is as follows:</P>
<OL>
<LI>
The MD5 algorithm is applied to the CC/PP description which is the value of
the corresponding Profile-Diff header field.
</LI>
<LI>
The Base64 algorithm is applied to the output of step1.
</LI>
<LI>
Insert the profile-diff-number at the head of the output of step2.
</LI>
</OL>

		
<P>The examples of the Profile header are as follows:</P>
<PRE>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"</PRE>

		
<P>NOTE: &nbsp;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:</P>
<OL>
<LI>
The headers should be small because some implementations of servers and
proxies have the restriction of the header length.
</LI>
<LI>
It is difficult to parse the header field when the profile descriptions and
URI are mixed within the same header field-value.
</LI>
<LI>
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.)
</LI>
</OL>

		
<P></P>

		
<H4><A NAME="522">5.2.2 Profile-Diff header</A></H4>

		
<P>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 <A HREF="#521" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#521">Section 5.2.1 Profile
header</A>).</P>

		
<P>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.</P>

		
<P>The grammar for the Profile-Diff header field is as follows:</P>
<PRE>Profile-Diff                = profile-diff-field-name&nbsp;":"&nbsp;profile-desc
profile-diff-field-name        = "Profile-Diff-" profile-diff-number
profile-desc                = &lt; the CC/PP description based on XML/RDF text format
                                (any OCTET except CTLs,but including LWS)></PRE>

		
<P>The Profile-Diff header field-name(profile-diff-field-name) consists of
&nbsp;the prefix("Profile-Diff-") and the following profile-diff-number.</P>

		
<P>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 <A HREF="#521" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#521">Section 5.2.1 Profile header</A>). 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.</P>

		
<P>The examples of the profile-diff-field-name are as follows:</P>
<PRE>Profile-Diff-1:
Profile-Diff-10:</PRE>

		
<P>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.</P>

		
<P>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).</P>

		
<P>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[<A HREF="#%5BP3P-Syntax%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BP3P-Syntax%5D">P3P-Syntax</A>], Canonical XML document
in James Clark's Home Page[<A HREF="#%5BCanonical-XML%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BCanonical-XML%5D">Canonical-XML</A>]).</P>

		
<P>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.</P>

		
<P>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 &nbsp;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.</P>

		
<P>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.</P>

		
<P>The example is as follows:</P>
<PRE>Profile: "1-P1GRkSjKK50aTWXXndFcSQ=="
Profile-Diff-1: &lt;?xml version="1.0"?>
     &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
          xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
      &lt;Bag>
       &lt;Description about="HardwarePlatform">
        &lt;Defaults>
         &lt;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" />
        &lt;/Defaults>
        &lt;Modifications>
         &lt;Description PRF:Memory="32mB" />
        &lt;/Modifications>
       &lt;/Description>
       &lt;Description about="SoftwarePlatform">
     .....
     &lt;/RDF></PRE>

		
<H4><A NAME="523">5.2.3. Profile-warning header</A></H4>

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

		
<P>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. &nbsp;If any one of the CC/PP
repositories is not available, the server might not obtain the
fully&nbsp;enumerated CC/PP descriptions, or &nbsp;the server might not obtain
first-hand or fresh CC/PP descriptions.</P>

		
<P>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.</P>

		
<P>The grammar for the Profile-warning header field is as follows:</P>
<PRE>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                = &lt;"> HTTP-date &lt;"></PRE>

		
<P>The definitions of &nbsp;the absoluteURI and the host are given from
RFC2396[<A HREF="#%5BRFC2396%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BRFC2396%5D">RFC2396</A>], and the definitions of the
quoted-string and the HTTP-date are given from HTTP/1.1[<A HREF="#%5BHTTP/1.1%5D" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPPexchange#%5BHTTP/1.1%5D">HTTP/1.1</A>].</P>

		
<P>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).</P>

		
<P>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".</P>

		
<P>This is a list of the currently-defined warn-codes, each with a recommended
warn-text in English, and a description of its meaning.</P>
<DL>
<DT>100 OK</DT>
<DD>
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.
</DD>
<DT>101 Used stale profile</DT>
<DD>
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.
</DD>
<DT>102 Not used profile</DT>
<DD>
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.
</DD>
<DT>200 Not applied</DT>
<DD>
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.
</DD>
<DT>201 Content selection applied</DT>
<DD>
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.
</DD>
<DT>202 Content generation applied</DT>
<DD>
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.
</DD>
<DT>203 Transformation applied</DT>
<DD>
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.
</DD>
<DT></DT>
</DL>

		
<P>The examples of the Profile-warning header are as follows:</P>
<PRE>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" &nbsp;"Wed, 31 Mar 1999 08:49:37 GMT"</PRE>

		
<H2><A NAME="6">6. Examples</A></H2>

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

		
<H3><A NAME="62">6.</A><A NAME="621">1 &nbsp;Mandatory and end-to-end</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
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.
</LI>
<LI>
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.
</LI>
<LI>
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&nbsp;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.
</LI>
<LI>
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.
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                &lt;/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
        ....</PRE>

		
<P>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.</P>
<PRE>   [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
        
        &lt;?xml version="1.0"?>
        &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
        xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
        &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
        &lt;/RDF> </PRE>

		
<H3><A NAME="62">6.2 &nbsp;Optional and end-to-end</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
The user agent issues an optional extension request(GET) with the Profile
header and the Profile-Diff header.
</LI>
<LI>
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.
</LI>
<LI>
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.
</LI>
<LI>
The origin server generates the tailored content according to the enumerated
CC/PP descriptions, and sends back the tailored content.
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                &lt;/RDF>
                
   [2. OriginServer --> UserAgent (case of failure)]
        HTTP/1.1 200 OK
        Content-Type: text/html
        Content-Length: 1200
        ....
        &lt;!-- 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
        ....</PRE>

		
<H3><A NAME="63">6.3 &nbsp;Mandatory and hop-by-hop</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
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.
</LI>
<LI>
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.
</LI>
<LI>
Otherwise, the first-hop proxy issues requests to the CC/PP repositories to
get the CC/PP descriptions using the absoluteURIs.
</LI>
<LI>
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.
</LI>
<LI>
The origin server responds to the first-hop proxy with the content.
</LI>
<LI>
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).
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                &lt;/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
        ....</PRE>

		
<H3><A NAME="64">6.4 &nbsp;Optional and hop-by-hop</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
The user agent issues an optional extension request(GET) with the Profile
header and the Profile-Diff header.
</LI>
<LI>
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.
</LI>
<LI>
Otherwise, the first-hop proxy issues requests to the CC/PP repositories to
get the CC/PP descriptions using the absoluteURIs.
</LI>
<LI>
The first-hop proxy generates the request and issues the request to the origin
server.
</LI>
<LI>
The origin server responds to the first-hop proxy with the content.
</LI>
<LI>
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.
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                &lt;/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
        ....</PRE>

		
<H3><A NAME="65">6.5. Response with Warning</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
The user agent issues a request.
</LI>
<LI>
The origin server issues requests to the CC/PP repositories to get the CC/PP
descriptions.
</LI>
<LI>
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".
</LI>
<LI>
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&nbsp;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.)
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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
        ....</PRE>

		
<H3><A NAME="66">6.6. Enable the HTTP cache expiration
model(end-to-end)</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
The user agent issues a request.
</LI>
<LI>
The origin server issues requests to the CC/PP repositories to get the CC/PP
descriptions.
</LI>
<LI>
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&nbsp;represented
by profile-diff-name "1-uKhJE/AEeeMzFSejsYshHg==" in the Profile header field.
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                &lt;/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
        ....</PRE>

		
<H3><A NAME="67">6.7. Enable the HTTP cache expiration
model(hop-by-hop)</A></H3>

		
<P>The scenario is listed below.</P>
<OL>
<LI>
The user agent issues a request.
</LI>
<LI>
The first-hop proxy issues requests to the CC/PP repositories to get the CC/PP
descriptions.
</LI>
<LI>
The first-hop proxy generates and issues a request to the origin server.
</LI>
<LI>
The origin server responds to the first-hop proxy with the content.
</LI>
<LI>
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.
</LI>
</OL>

		
<P>The requests and responses according to the scenario is described
below.</P>
<PRE>   [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: &lt;?xml version="1.0"?>
                        &lt;RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
                        xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
                        &lt;Description ID="SoftwarePlatform" PRF:Sound="On" />
                        &lt;/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
        ....</PRE>

		
<H2><A NAME="7">7. Security considerations</A></H2>

		
<P>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.</P>

		
<P>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.</P>

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

		
<H2><A NAME="References">References</A></H2>

		
<P><A NAME="[HTTPext]">[HTTPext]</A> <A HREF="http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-extensions-03.txt">HTTP
Extension Framework</A></P>

		
<P><A NAME="[HTTP/1.1]">[HTTP/1.1]</A> <A HREF="http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt">HTTP/1.1,
Rev6</A></P>

		
<P><A NAME="[CCPP]">[CC/PP]</A> <A HREF="NOTE-CCPP" W3MIRHREF="http://www.w3.org/TR/NOTE-CCPP">Composite Capability/Preference Profiles
(CC/PP): A user side framework for content negotiation</A></P>

		
<P><A NAME="[RDF]">[RDF]</A> <A HREF="REC-rdf-syntax" W3MIRHREF="http://www.w3.org/TR/REC-rdf-syntax">Resource Description Framework,
(RDF) Model and Syntax Specification</A></P>

		
<P><A NAME="[RDF-Schema]">[RDF-Schema]</A> <A HREF="WD-rdf-schema" W3MIRHREF="http://www.w3.org/TR/WD-rdf-schema">Resource Description Framework (RDF)
Schema Specification</A></P>

		
<P><A NAME="[P3P]">[P3P]</A> <A HREF="http://www.w3.org/P3P/">Platform for
Privacy Preferences P3P Project</A></P>

		
<P><A NAME="[RFC2396]">[RFC2396]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2396.txt">RFC 2396
: Uniform Resource Identifiers (URI): Generic Syntax</A></P>

		
<P><A NAME="[RFC2119]">[RFC2119]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt">RFC 2119
: Key words for use in RFCs to Indicate Requirement Levels</A></P>

		
<P><A NAME="[RFC2277]">[RFC2277]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2277.txt">RFC 2277
: IETF Policy on Character Sets and Languages</A></P>

		
<P><A NAME="[RFC1321]">[RFC1321]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc1321.txt">RFC 1321
: The MD5 Message-Digest Algorithm</A></P>

		
<P><A NAME="[RFC2045]">[RFC2045]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2045.txt">RFC 2045
: Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet
Message Bodies</A></P>

		
<P><A NAME="[RFC2109]">[RFC2109]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2109.txt">RFC 2109
: HTTP State Management Mechanism</A></P>

		
<P><A NAME="[RFC2326]">[RFC2326]</A> <A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2326.txt">RFC 2326
Real Time Streaming Protocol(RTSP)</A></P>

		
<P><A NAME="[WBXML]">[WBXML]</A> <A HREF="wbxml" W3MIRHREF="http://www.w3.org/TR/wbxml">Binary XML
Content Format Specification</A></P>

		
<P><A NAME="[P3P-Syntax]">[P3P-Syntax]</A> <A HREF="WD-P3P/syntax.html#Appendix_Fingerprints" W3MIRHREF="http://www.w3.org/TR/WD-P3P/syntax.html#Appendix_Fingerprints">Platform
for Privacy Preferences (P3P1.0) Syntax Specification Appendix 2: Fingerprints
and Canonicalization</A></P>

		
<P><A NAME="[Canonical-XML]">[Canonical-XML]</A> <A HREF="http://www.jclark.com/xml/canonxml.html">Canonical XML</A></P>
<HR>

		

		
<P><A HREF="http://validator.w3.org/"><IMG HEIGHT="31" ALT="Valid HTML 4.0!" BORDER="0" WIDTH="88" SRC="http://validator.w3.org/images/vh40.gif"></A>&nbsp; <A HREF="http://www.w3.org/Style/CSS/Buttons"> <IMG HEIGHT="31" ALT="Made with CSS" BORDER="0" WIDTH="88" SRC="http://www.w3.org/Style/CSS/Buttons/mwcos"></A></P>
</BODY>
</HTML>

		
.

NEW PAGES:

[ODDNUGGET]

[GOPHER]