index.html 47.8 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>

<HEAD>
<TITLE>CC/PP Implementors Guide: Privacy and Protocols</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css">  
</HEAD>
<BODY>

<DIV class="head">
<A href="http://www.w3.org/"><IMG  alt="W3C" 
src="http://www.w3.org/Icons/w3c_home" height=48 width=72></A> 

<H1>CC/PP Implementors Guide:<br>
Privacy and Protocols</H1>
<H2>W3C Working Draft 20 December 2001</H2>

<dl>
<dt>This Version:</dt>
  <dd><a href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/">
  http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/</a></dd>
  <dt>Latest Version:</dt>
  <dd><a href="http://www.w3.org/TR/CCPP-trust">
  http://www.w3.org/TR/CCPP-trust</a></dd>
  <dt>Previous Version:</dt>
  <dd>None</dd>
  <dt>Editors:</dt>
  <dd>Hidetaka Ohto &lt;
      <A href="mailto:ohto@w3.org">ohto@w3.org</A>&gt;,
      W3C/Panasonic</dd>
  <dd>Lalitha Suryanarayana &lt;<A 
      href="mailto:lalitha@tri.sbc.com">mailto:lalitha@tri.sbc.com</A>
      &gt;, SBC</dd>
  <dd>Johan Hjelm &lt;<A href="mailto:johan.hjelm@nrj.ericsson.se">
      johan.hjelm@nrj.ericsson.se</a>&gt;, 
      Ericsson Research Japan</dd>
</dl>

<!--
<TABLE 
summary="This table lists URIs for this version, latest public version
and previous version of this document, and authors of this document.">

<TABLE 
  <TBODY>
  <TR vAlign=baseline>
    <TD>This version:</TD>
    <TD><A class=loc 
      href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011218">
      http://www.w3.org/TR/2001/WD-CCPP-trust-20011218</A></TD></TR>
  <TR vAlign=baseline>
    <TD>Latest version:</TD>
    <TD><A class=loc 
      href="http://www.w3.org/TR/CCPP-trust">
      http://www.w3.org/TR/CCPP-trust</A></TD></TR>
  <TR vAlign=baseline>
    <TD>Editors:</TD>
    <TD>Hidetaka Ohto &lt;<A href="mailto:ohto@w3.org">ohto@w3.org</A>&gt;, 
      W3C/Panasonic<BR>Lalitha Suryanarayana &lt;<A 
      href="mailto:lalitha@tri.sbc.com">mailto:lalitha@tri.sbc.com</A>
      &gt;, SBC<br>
      Johan Hjelm &lt;<A 
      href="mailto:johan.hjelm@nrj.ericsson.se">johan.hjelm@nrj.ericsson.se</A>&gt;, 
      Ericsson Research Japan</TD></TR></TBODY></TABLE>
<P>
-->
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
Copyright</a> &copy;2001 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a
href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of
Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr
lang="fr" title="Institut National de Recherche en Informatique et
Automatique">INRIA</abbr></a>, <a
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p> 
</DIV>

<HR>

<H2><A id=Abstract name=Abstract>Abstract</A></H2>
<P>This document gives implementors advice on how to protect the privacy of a 
CC/PP user, and outlines how this can be applied using P3P in HTTP with the 
CC/PP Exchange protocol.</P>

<H2><A id=status name=status>Status of this document</A></H2>

<p>
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest
status of this document series is maintained at the W3C.</p>

<p>
This document is a very preliminary public Working Draft made
available by the World Wide Web Consortium (W3C) for discussion
only. It is intended to become a W3C Note. This indicates no
endorsement of its content. This is work in progress, may be updated,
replaced, or obsoleted by other documents at any time.  
A list of current W3C working drafts can be found at 
<a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<p>
This document is produced by the <a href="/Mobile/CCPP/Group/">
CC/PP working group</a> (member only) (part of the 
<a href="/2001/di">Device Independence activity</a>). 
The working group welcomes feedback and discussion,
preferably on the public mailing list <a
href="mailto:www-mobile@w3.org">www-mobile@w3.org</a>, although
comments may also be sent to the authors.
Public comments and their responses can be accessed at
<a href="http://lists.w3.org/Archives/Public/www-mobile/">
http://lists.w3.org/Archives/Public/www-mobile/</a>.</p>

<p>


<!--
<P>This document is a very preliminary working draft made available by
the World  Wide Web Consortium (W3C) for discussion only. It is
intended to become a W3C  Note. This indicates no endorsement of its
content. 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>Not included in this version.</P>
<H2><A id=Introduction name=Introduction>1. Introduction</A></H2>
<P>CC/PP data is not in itself personal, i.e. tied to a named user, but since 
there are a number of ways for the user to be identified as the holder of the 
profile, e.g. by identity transmision in HTTP parameters, or through 
recognition of the IP-number or such, there is a need for a suggested privacy 
method for implementors.</P>
<P>Descriptions of single features in a description of a terminal or the users 
preferences for how that terminal should be used cannot in themselves be used to 
infringe on a users privacy. However, when a profile contains a collection of 
such properties, it can be used to personalize information; the closer the 
personalization, the bigger risk that the user can be identified from his 
specific use of the terminal; and the bigger the risk of misuse from a privacy 
standpoint. There is also a possible risk that a user can be identified as 
having certain abilities (e.g. if he constantly requests text in double-sized 
fonts, it is likely that he is hard of seeing), and this may be possible to 
misuse.</P>
<P>Generally speaking, a user may not want to share some or all of the data in a 
CC/PP profile, and may wish to have control over who receives that information 
and when. Origin servers customizing the content should therefore express to the 
user or user agent regarding their privacy practices with regard to the use of 
CC/PP data, so that, the user can make a decision on whether or not to share 
that data with the server.</P>
<P>P3P is a way for an origin server to express the privacy policy it adheres to 
for the user and/or his terminal. While the match between P3P and CC/PP is not 
perfect, and while the intent and implementation of the two are different, they 
can be used together to enhance the privacy protection of the user.</P>
<P>CC/PP is an abbreviation of "Composite Capability/Preference Profiles", and 
is an extensible format based on RDF <a href="#RDF">[RDF]</A>
<a href="#RDF-Schema">[RDF-Schema]</A> 
for describing device capabilities and user preferences. In general, user 
preferences and device capabilities need to be protected from malicious use but 
there is no trust management framework for CC/PP so far. Without trust 
management, sensitive information opens to attacks by malicious servers or 
content providers.</P>
<P>We do not aim to create new technologies in terms of network security, 
authentication, message validation, personal privacy protection, and 
cryptography. We intend to employ the existing technologies in terms of trust 
management while considering how to apply such technologies well fit into the 
use cases of CC/PP.</P>
<H2><A id="scope" name="scope">2. Scope of this document</A></H2>
<P>This document is a discussion document, containing implementation advice for 
developers of services based on CC/PP. It demonstrates the interactions between 
CC/PP and P3P given the current state of implementations. However, since CC/PP 
only specifies a data structure and not a protocol, this work should be taken as 
future input to a formal specification, and currently be seen as advice to 
implementors only.</P>
<P></P>
<H2><a id="protocol-transport" name="protocol-transport"></a>
3. Protocol and transport issues.</H2>
<P>There is, currently, no CC/PP protocol. There are a number of proposals, but 
for various reasons, the group is not chartered to develop a protocol. It will 
do so as soon as possible, but it does require a rechartering. Meanwhile, there 
are two proposals: The CC/PP Exchange Protocol, and the W-HTTP protocol.</P>
<P>Note that it would be possible to use the "profile" header Mark Baker 
suggests in draft-baker-xhtml-media-reg-01.txt and 
draft-baker-xhtml-media-reg-02.txt to reference a CC/PP profile (the mechanism 
has been demonstrated by Kiniko Yasuda of Keio University).</P>
<P>There are two main ways of transporting CC/PP over HTTP: Using the CC/PP 
Exchange Protocol, or using the UAProf W-HTTP Protocol.</P>
<P></P>
<H3><a name="ccpp-exchange" id="ccpp-exchange"></a>
3.1 CC/PP Exchange Protocol</H3>
<P>The CC/PP Exchange Protocol (CCPP-ex) was presented as a W3C Note on June 24, 
1999. It uses the HTTP Extension Framework <a
href="#RFC2396">[RFC2396]</a>. 
The intent was to provide 
a framework that was both possible to map into HTTP headers, and that can handle 
defaults as URIs. The idea was to minimize data transfer over the air, a goal 
that was accomplished, as has been demonstrated by <A 
href="/Mobile/CCPP/implday/0011ccpp/Overview.html">Kiniko 
Yasuda of Keio University</A>.</P>
<P>CCPP-ex uses two headers, one for the defaults and one for the updates 
(profile-diff:s), which are separated using MD5 hashes. A third header carries 
warning information. The protocol is documented in the W3C Note "<A 
href="/TR/NOTE-CCPPexchange">CC/PP exchange protocol based on 
HTTP Extension Framework</A>".</P>
<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. 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.</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.</P>
<P>There are several optimizations possible to help deal with network 
performance issues. One strategy is to use a compressed form of XML, 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 
propagate changes to the current CC/PP descriptions to an origin server, a 
gateway or a proxy. One solution is to transmit the entire CC/PP descriptions 
with each change. This is not ideal for slow networks. An alternative is to send 
only the changes.</P>
<P>The CC/PP exchange protocol does not depend on the profile format that it 
conveys. Therefore another profile format besides the CC/PP description format 
could be applied to the CC/PP exchange protocol. 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.</P>
<P>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 users 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.</P>
<P>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. 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.</P>
<P>The HTTP Extension Framework introduces two types of extension declaration 
strength: mandatory and optional, and two types of extension declaration scope: 
hop-by-hop and end-to-end. Which type of the extension declaration strengths 
and/or which type of the extension declaration scopes should be used depends on 
what the user agent needs to do.</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 origin server, a gateway 
or a proxy) does not comply with the CC/PP exchange protocol.</P>
<P>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 a priori knowledge that the first hop 
proxy complies with the CC/PP exchange protocol.</P>
<P>The scope of the extension declaration should be end-to-end if the user agent 
has a priori knowledge that the first hop proxy does not comply with the CC/PP 
exchange protocol, or the user agent does not use a proxy.</P>
<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>
<TABLE border=1>
  <TBODY>
  <TR>
    <TD>Header field</TD>
    <TD>Grammar</TD></TR>
  <TR>
    <TD>Profile</TD>
    <TD>= profile-field-name ":" 1#reference</TD></TR>
  <TR>
    <TD>profile-field-name</TD>
    <TD>= "Profile"</TD></TR>
  <TR>
    <TD>reference</TD>
    <TD>= &lt;"&gt; ( absoluteURI | profile-diff-name ) &lt;"&gt;</TD></TR>
  <TR>
    <TD>profile-diff-name</TD>
    <TD>
      <P>= profile-diff-number "-" profile-diff-digest</P></TD></TR>
  <TR>
    <TD>profile-diff-number</TD>
    <TD>= 1#DIGIT</TD></TR>
  <TR>
    <TD>profile-diff-digest</TD>
    <TD>= sp; &lt; MD5 message digest encoded by base64 &gt;</TD></TR>
  <TR>
    <TD>DIGIT</TD>
    <TD>= &lt;any US-ASCII digit "0".."9"&gt;</TD></TR></TBODY></TABLE>
<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.</P>
<P>A reference is either an absolute URI 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. The profile-diff-name in the Profile header field addresses a CC/PP 
description in the corresponding Profile-Diff header within the same 
request.</P>
<P>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.</P>
<P>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. 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>
<H3><a id="w-http" name="w-http"></a>3.2 W-HTTP</H3>
<P>The WAP Forum UAProf group has defined a transport for CC/PP over W-HTTP 
(Wireless Profiled HTTP). It can be found in section 9 of the UAProf 
specification. In the case where the mobile terminal supports wireless profiled 
HTTP the profile is transported using meta data defined by
<!--
HTTP [W-HTTP] the profile is transported using meta data defined by
-->
this  
specification. The CC/PP Framework remains unaltered. The defined mechanism 
provides a functional equivalent for the CC/PP exchange protocol <a href="#CCPP-ex">[CCPP-ex]</a> but 
the definition of the syntax and semantics of the transport remains in this 
specification.</P>
<P></P>
<H4><a id="w-http-trans-ccpp" name="w-http-trans-ccpp"></a>
3.2.1 Using W-HTTP to transport CC/PP</H4>
<P>The following extension headers are defined to transport CC/PP in W-HTTP. The 
defined extension headers are considered to be end to end headers..</P>
<P></P>
<H5>3.2.1.1 X-WAP-PROFILE</H5>
<P>The x-wap-profile header is a general header field which MUST contain the 
following :</P>
<P>·a URI referencing the CC/PP profile, or</P>
<P>·a reference to a profile difference, transported using the 
x-wap-profile-diff or</P>
<P>·a combination of multiple instances of these two types of data. This data 
MAY be generated by the mobile terminal or attached by an intermediary point in 
a request to an origin server.</P>
<P>In the case of Push this header MAY be generated as a response to a request. 
In the case of Push this data may be cached. However this header MUST be present 
in any request or response when UAProf is used.</P>
<P>The x-wap-profile header MAY contain references to instances of the 
x-wap-profile-diff header (defined in the following section ). Each reference 
contains two parts, the sequence number and the profile-digest. The sequence 
number is used to determine the order of how the x-wap-profile-diff headers 
should be applied and the digest is used to validate that the profile-desc in 
the x-wap-profile-diff header value is correct.</P>
<P></P>
<H5>3.2.1.2. X-WAP-PROFILE-DIFF</H5>
<P>The x-wap-profile-diff header is a general header and MAY be generated by the 
mobile terminal or an intermediate proxy to enhance or alter the CPI. There may 
be multiple profile differences, each profile difference must also have a 
reference in the x-wap-profile header which indicates the order in which 
differences should be applied. This header contains two parts, a sequence 
identifier and the entity which represents the part of the CC/PP description 
that is being enhanced. This header MAY be present in a request or response. In 
the case of Push this data may be cached.</P>
<P></P>
<H5>3.2.1.3. X-WAP-PROFILE-WARNING</H5>
<P>The x-wap-profile-warning header is a general header. Essentially, it is the 
same as the X-WAP-PROFILE-WARNING header in the CC/PP Exchange Protocol. Its 
presence indicates the level to which the response has been tailored in relation 
to profile data that has been supplied in the request. This header MAY be 
present in a request or response. The warning codes that are defined fall into 
the following categories :</P>
<P>·1xx - reserved</P>
<P>·100 -- reserved</P>
<P>·2xx - indicates whether the content has been adapted depending on the 
profile</P>
<P>·5xx - indicates the server is incapable of processing CPI.</P>
<P>The x-wap-profile-warning may have the following values.</P>
<P>200Not applied</P>
<P>This value MUST be included if the content has not been tailored, and is sent 
in a representation, which is the only representation available in the 
server.</P>
<P>201Content selection applied</P>
<P>MUST be included if the included content has been selected from one of the 
representations available.</P>
<P>202 Content generation applied</P>
<P>MUST be included if the content has been tailored or generated as a result of 
applying the included profile.</P>
<P>203 Transformation applied</P>
<P>MUST be added by an intermediate proxy if it applies any transformation 
changing the content-coding based on the CPI data.</P>
<P>500Not Supported</P>
<P>Indicates that the entity sending this warning code does not support 
UAProf.</P>
<P></P>
<H5>3.2.1.4. Protocol Procedures</H5>
<P></P>
<H6>3.2.1.4.1. Over The Air</H6>
<P>In this transport variant the headers and their values are not compressed for 
over the air transmission. It is recommended that the hardware and software 
manufacturer only use the x-wap-profile header to indicate an absoluteURI as the 
reference for CPI for the mobile terminal when transmitted over the air. However 
this specification does not preclude the use x-wap-profile-diff in this 
case.</P>
<P></P>
<H6>3.2.1.4.2. Combining X-WAP-Profile and X-WAP-Profile-Diff</H6>
<P>If the x-wap-profile-diff header is included the profile-diff-seq MUST match 
a sequence number in the x-wap-profile header otherwise the associated 
profile-diff-desc MUST NOT be processed. The reference to each 
x-wap-profile-diff header contains two parts, a sequence number which governs 
the order in which the x-wap-profile-diff headers are processed and an MD5 
message digest which is used to validate the profile-desc which is contained in 
the x-wap-profile-diff. If either the sequence or the MD5 validation do not 
match, the particular profile-diff MUST be ignored.</P>
<P>If the x-wap-profile-diff header is added by an intermediate proxy, it MUST 
NOT alter the existing sequence of x-wap-profile-diff headers, the proxy MUST 
append using the next available sequence number in numeric order. The digest 
associated with an x-wap-profile-diff MUST be generated by applying MD5 message 
digest algorithm [RFC1321] and base64 algorithm, section 6.8 in the MIME 
specification [RFC2045] to the corresponding profile-desc part of the header 
field-value.</P>
<P>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></P>
<H5>3.2.1.5. Relationship with HTTP Headers</H5>
<P>The profile information referred to in the x-wap-profile and 
x-wap-profile-diff header does not supersede HTTP request or response header 
information.</P>
<P></P>
<H5>3.2.1.5.1. Caching</H5>
<P>The x-wap-profile-warning header MUST NOT be used for cache control purposes. 
If a server wishes to indicate a caching dependency based on these
headers then hit should use the Vary header as defined in section
14.44 of the HTTP 1.1 specification <a href="#HTTP-1.1">[HTTP/1.1]</a>.</P> 
<P></P>
<H3><a id="soap" name="soap">3.3 XML Protocol/SOAP</a></H3>
<P>How CC/PP will be transported and handled in of XML Protocol/SOAP is not 
clear. This is something the working group wishes to investigate further.</P>
<H3><a id="other-proto" name="other-proto"></a>3.4 Other protocols</H3>
<P>The WAP Forum has provided a mapping to the headers of WSP, the Wireless 
Session Protocol (defined in the WAP UAPROF specification). Work is also ongoing 
in 3GPP to transport CC/PP over RSVP.</P>
<H2><A id="usecase" name="usecase">4.Use Cases</A></H2>
<H3><A id="http-usecase" name="http-usecase">4.1 HTTP use case</A></H3>
<P>Since CC/PP is intended to be protocol neutral, it will work with any 
protocol which can transport it. Mappings have been produced for other 
protocols, most notably WSP. However, it is to be expected that it will be 
implemented for HTTP, using HTTP headers as a transport. The working group also 
intends to look at the transport of CC/PP over SOAP/XML Protocol as a future 
work item.</P>
<H4><A id="turst-mechanism" name="trust-mechnism">
4.1.1 Trust mechanisms</A><A></A></H4>
<P>Policy publishing does not bring trust by itself. Trust has to be obtained in 
other ways, before it is even worth the trouble to publish a policy. In this 
context, <A href="http://www.w3.org/P3P/">P3P</A> should rather be seen as a 
means to retrieve the user's consent for data storage and/or processing. It 
enables the client to retrieve a policy declaration from the server, and match 
this with the preferences of the client. However, P3P is not defined for other 
protocols than HTTP. No other mechanisms exist, to our knowledge, to communicate 
policies between client and server. Note, however, the known problem that P3P 
does nothing to enforce the policy - this is assumed to take place out of 
band.</P>
<H4><A id="p3p-with-http">4.1.2 Using P3P with HTTP</A></H4>
<P>In the document CC/PP exchange protocol <a
href="#CCPP-ex">[CCPP-ex]</a> based on HTTP Extension Framework 
<a href="#HTTP-ext">[HTTPext]</a>, a mechanism to transport CC/PP over HTTP is described. This document 
describes how that interaction could take place, given a P3P interaction as 
well.</P>
<P>Before a policy can be exchanged, the client must request it from a server. 
If this is not a proxy in a trusted domain, the client will expose his profile 
to a possibly malicious party if the CC/PP Exchange Protocol is used, since the 
profile is sent in its entirety with the first GET request. Thus, a malicious 
server could take this profile and do anything it wanted with it, since no 
relationship has been established.</P>
<P>One solution to this is to transmit a minimal profile as part of the first 
request, as described in <a href="#pemi">[PEMI]</a>. When the policy has been received and approved, 
a full profile is sent (as a profile-diff). Note that if the policy is rejected, 
there is currently no way for the server to maintain a state over users 
requests, and there is no way for the server to recognize that the client does 
not approve of the policy, since there is no fallback method in P3P.</P>
<P>Note that it is possible for the profile declared to be a null profile (i.e. 
without content), and the correct profile to be transferred as a diff upon 
approval of the servers policy. Note also that the state management mechanism in 
the server is currently is not specified. It should be possible to use cookies 
for this, although the ramifications of a discussion of this would lead too 
far.</P>
<P>The interaction with P3P might have two levels of granularity:</P>
<P>a) where the privacy policy includes all CC/PP vocabulary [generic statement 
stating that all data in the profile and profile diff headers will not be 
retained or misused, or will be used only for the purposes of content 
customization]</P>
<P>b) where the policy specifically states what attributes (data elements) from 
the CC/PP vocabulary is collected and state the purpose. This can be extended at 
a later date to include negotiation capabilities (which is currently out of the 
scope of P3P1.0) or alternately, the user agent can be smart enough to parse 
these elements out and send only those attributes (as indicated in the policy) 
in the profile and profile diff headers following the acceptable of the site's 
policy.</P>
<H5><A id="p3p-ccpp" name="p3p-ccpp">4.1.2.1 P3P and CC/PP
vocabularies</A></H5> 
<P>The P3P vocabulary is defined in XML. The CC/PP vocabularies are defined in 
RDF (using the XML encoding of RDF). The P3P specification <a
href="#P3P">[P3P]</a> declares that  
an RDF encoding will be made available; when this happens, P3P elements can be 
used inside CC/PP profiles (and vice versa). For further information on mixing 
namespaces in profiles, see <a href="#CCPP">[CCPP]</a> and <a href="#CCPP-vocab">[CCPP-vocab]</a>. Since this effort has been 
advertised, the CC/PP working group has decided not to create any mapping of 
their own, but await the P3P working group efforts. An alternative solution is 
to create a CC/PP data schema in the P3P syntax, but that would seem redundant 
if an RDF version of P3P is forthcoming. The two working groups will continue to 
investigate this. </P>
<P>4.1.2.2 Safe Zone</P>
<P>The P3P specification defines a concept of a "safe zone". This concept does 
not exist a priori in CC/PP, since no protocol has been defined. However, the 
PIMI method as described in section 5.1 can be used to provide a safe zone in 
the way that is indicated in the P3P specification, section 2.4.3. As noted 
above, an empty profile can be used while negotiating within the safe zone, 
instead of a minimal one. </P>
<P>4.1.2.3 APPEL</P>
<P>No rules language is defined for CC/PP. Existing implementations make use of 
XSLT to predicate transformations (using Xpath, profile documents can be 
addressed from within a style sheet). In the future, it is foreseen that there 
will be a need for a more extensive rule system, such that decisions can concern 
not just the formatting, but the content itself as well. In that regard, 
synergies with the APPEL rules language for P3P could be investigated.</P>
<H3><a id="trused-interm" name="trusted-interm"></a>
4.2 Use of trusted intermediaries</H3>
<P>In the CC/PP Exchange protocol, profiles can be referenced and retrieved by 
an intermediary (a gateway or other proxy). It is also possible that this entity 
could handle the P3P negotiations, if a mechanism to delegate authority to it 
existed, and end-to-end security was not required. This may occur in situations 
where the user is in a trusted domain, which is interfaced with the Internet 
through the proxy or gateway.</P>
<P>In this case, the P3P negotiation will be terminated in the proxy. It will 
also be necessary for the proxy not just to keep a cache of documents, but to 
maintain a database of user state. It may even be necessary for the proxy to 
become the entity which performs not just transcoding, but also personalization 
on behalf of the origin server.</P>
<P>The advantage for the user of this would be that the personal information - 
including the CC/PP profile - stays in the trusted proxy. The advantage for the 
origin server owner is harder to identify, since the version of the document 
which has to be delivered will have to be "universal", and there will not be any 
record of the number of retrievals, who retrieved it, etc (which, conversely, 
can be seen as a privacy enhancement for the user).</P>
<P>As this type of system continues to emerge, e.g. in the scope of the IETF 
WEBI and APEX working groups, we foresee that the issue will become more 
important. However, since the mechanism is transparent to HTTP, and since it can 
be for CC/PP, we will not discuss it to any further extent here.</P>
<H2><A id="example" name="example">5. Examples</A></H2>
<H3><A id="p3p-ccpp-exchange" name="p3p-ccpp-exchange">5.1 Using P3P with CC/PP Exchange Protocol using 
the</A><A href="http://www.cs.kau.se/~helena/research/pimi.pdf">PIMI</A> 
method</H3>
<P>The idea behind the PIMI method is that the client has defined a minimal 
profile with non-contentious information (which cannot be used to infringe on 
the privacy of the client). This minimal profile is used in an initial request 
to get the privacy policy of the server. As demonstrated below, using the 
profile-diff headers of the CC/PP Exchange protocol, it becomes possible for the 
client to signal satisfaction or dissatisfaction with the policy by returning a 
profile difference or not. In response to the empty diff, the server can provide 
a document which does not contain the adaption which would have been done using 
the information which the client will not reveal.</P>
<P>What constitutes a "minimal profile" is most likely subjective. Ultimately, 
the user will have to determine what information he or she wants to give out. 
However, for the purposes of discussion, we will assume that the properties 
which enable a generic display and data input on the device, without expressing 
any preferences and without any modifications, will constitute a minimum. That 
would imply the following, using the properties defined by the WAP UAProf 
drafting committee:</P>
<P><EM>Screen size</EM></P>
<P><EM>Color capable</EM></P>
<P>In this document, we propose that an empty diff be sent as response (in a 
second GET), which would imply that the profile has not changed. Depending on 
the implementation, the server could return a document containing a different 
information set than the user would have got if he had accepted the policy; or 
returned nothing. This is not specified in the P3P specification, and out of 
scope for the CC/PP work.</P>
<P>This would apply when the client initially contacted the server during a 
session. During the rest of the session, it would be able to refer to the policy 
first retrieved, or to follow-up policies which can be added later during a 
session (using the LINK tag in HTTP, using a well-known location, or an HTTP 
header).</P>
<P>The interactions would look as follows:</P>
<P>1. Client sends request with minimal profile to server. This request can be 
directed to the well-known location of the P3P reference file, /w3c/p3p.xml. It 
can also be directed at another location, if this has been indicated in a LINK 
tag in a document that references this server. The reference file is returned. 
After that, another request will retrieve the policy file. </P>
<P>2. Server returns policy.</P>
<P>3. Client reads policy and matches against own rule set</P>
<P>3'. Client approves policy, sends diff with full information (or a GET with 
full information directed at the URI where the document resides, if the policy 
was retrieved from the well-known or LINK-ed location).</P>
<P>4'. Client receives document</P>
<P>3". Client rejects policy, resends request with empty diff</P>
<P>4". Client receives less important document.</P>
<P>With protocol interactions, this would look as follows:</P>
<P><EM>1. Client sends request with minimal profile to server.</EM></P><PRE>        GET /a-resource HTTP/1.1
        Host: www.w3.org
        Opt: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19
        19-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
        Accept: */*        
        Accept-Language: de, en</PRE>
<P><EM>2. Server returns policy.</EM></P><PRE>        HTTP/1.1 200 OK
        P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"
        Content-Type: text/html
        Content-Length: 7413
        Server: CC-Galaxy/1.3.18</PRE>
<P><EM>3. Client reads policy and matches against own rule set</EM></P>
<P>(not shown)</P>
<P><EM>3'. Client approves policy, sends diff with full information</EM></P><PRE>         GET /a-resource HTTP/1.1
         Host: www.w3.org
         Opt:"http://www.w3.org/TR/NOTE-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"?&gt;
         &lt;RDF xmlns="http://www.w3.org/TR/PR-rdf-syntax"                
              xmlns:PRF="http://www.example.org/TR/WD-profile-vocabulary#"&gt;                
                 &lt;Description ID="SoftwarePlatform" PRF:Sound="On" /&gt;                
                 &lt;/RDF&gt;</PRE>
<P><EM>4'. Client receives document</EM></P>
<P>(not shown)</P>
<P><EM>3". Client rejects policy, resends request with empty diff</EM></P><PRE>         GET /a-resource HTTP/1.1
         Host: www.w3.org
         Opt:"http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19         
         19-Profile:"http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="  
         19-Profile-Diff-1: </PRE>
<P><EM>4". Client receives less important document</EM></P>
<P>(not shown)</P>
<P><EM></EM></P>
<HR>

<H2><A id="References" name="References">6. References</A></H2>
<P><A id="HTTP-ext" 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 id="HTTP-1.1" 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 id="CCPP" name="CCPP">[CC/PP]</A> <A 
href="http://www.w3.org/TR/NOTE-CCPP">Composite Capability/Preference Profiles 
(CC/PP): A user side framework for content negotiation</A></P>
<P><A id="RDF" name="RDF">[RDF]</A> <A 
href="http://www.w3.org/TR/REC-rdf-syntax">Resource Description Framework, (RDF) 
Model and Syntax Specification</A></P>
<P><A id="RDF-Schema" name="RDF-Schema">[RDF-Schema]</A> <A 
href="http://www.w3.org/TR/WD-rdf-schema">Resource Description Framework (RDF) 
Schema Specification</A></P>
<P><A id="P3P" name="P3P">[P3P]</A> <A href="http://www.w3.org/P3P/">Platform 
for Privacy Preferences P3P Project</A></P> 
<!--
<P><A id="P3P-Syntax" name="P3P-Syntax1">[P3P-Syntax]</A> <A 
href="http://www.w3.org/TR/WD-P3P/syntax.html">Platform for Privacy
Preferences [P3P] Syntax Specification</A></P>
-->
<P><A id="RFC2396" name="RFC2396">[RFC2396]</A> <A 
href="http://info.internet.isi.edu/rfc/rfc2396.txt">RFC 2396 : 
Uniform Resource Identifiers (URI): Generic Syntax</A></P>
<!--
<P><A id="RFC2119" name="RFC2119">[RFC2119]</A> <A 
href="http://info.internet.isi.edu/rfc/rfc2119.txt">RFC 2119 : 
Key words for use in RFCs to Indicate Requirement Levels</A></P>
-->
<!--
<P>[IOTP] <A 
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt">Internet 
Open Trading Protocol - IOTP Version 1.0</A></P>
<P>[IOTPsig] <A 
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt">Digital 
Signatures for the Internet Open Trading Protocol</A></P>
<P>[DOMHASH] <A 
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt">Digest 
Values for DOM (DOMHASH)</A></P>
-->
<P><a id="CCPP-ex" name="CCPP-ex">[CCPP-ex]</a> <A href="http://www.w3.org/TR/NOTE-CCPPexchange">CC/PP exchange 
protocol based on HTTP Extension Framework</A></P>
<P><a id="pemi" name="pemi">[PEMI]</a> <A href="http://www.cs.kau.se/~helena/research/pimi.pdf">Privacy 
Enhancements in the Mobile Internet, Mikael Nilsson, Helena Lindskog, Simone 
Fischer-Huebner, Karlstad University.(PDF format)</A></P>
<P><a id="CCPP-vocab">[CCPP-vocab]</a> W3C Note, CC/PP Implementers Guide
Harmonization with Existing Vocabularies and Content Transformation Heuristics, to be appeared.</p>
<HR>

<P>Appendix</P>
<H1><a id="req-turst-frame" name="req-trust-frame"></a>
Basic requirements for trust management frameworks</H1>
<H3><a id="basic-req" name="basic-req"></a>
A.1 Basic requirements</H3>
<P>The basic requirements for the CC/PP trust management framework, which were 
discussed in the 1999 version of this document, are listed below.</P>
<OL>
  <LI>A client must be able to discover the privacy practices of an origin 
  server before revealing private profile information 
  <LI>The privacy mechanism must be separable from CC/PP framework so that the 
  user has a choice of whether or not privacy mechanism is to be
  used. In other
 
  words, enable CC/PP content negotiation with or without privacy 
  <LI>The protocol must allow each client individually to determine what 
  information is private<BR>Any or all of the profile can be considered private. 
  What may be a private piece of information for one user may not be so for 
  another. 
  <LI>Since CC/PP is protocol independent, the privacy mechanism should also be 
  supported on various transport protocols (including HTTP, MIME, SMTP etc) 
  <LI>A client must be able to interact with a server to the point of 
  discovering its privacy policy without having to disclose any particular item 
  of information. 
  <P>For example, a user agent first sends non-private profile data to a server, 
  which then responds with a privacy policy, as a result of which, the user 
  agent may either choose to send or not send any additional (private) 
  information to the server for the purposes of receiving tailored content.</P>
  <LI>It should be possible for the origin server to render content best effort, 
  if the private information is not shared by the user. 
  <LI>Intermediate proxies, servers and gateways asserting profile data must 
  also honor the privacy needs of the user. In other words, if the user deems a 
  profile attribute to be private, an intermediate proxy must not disclose that 
  attribute in its profile diff. 
  <LI>May require user-agent side privacy capability (e.g. P3P user agents) must 
  be supported by such servers/ proxies/ gateways. 
  <LI>As with CC/PP mechanism, the private profile must also support. 
  <UL>
    <LI>additions and overrides by other network elements as specified in the 
    CC/PP specs 
    <LI>inline or URI (indirect) references to the profile information </LI></UL>
  <LI>the privacy mechanism should support the split client model.<BR>Thin 
  clients such as for low-end devices (on a mobile network for example), may not 
  be able to support the necessary mechanism for privacy (e.g. P3P user agent) 
  perhaps due to overhead. Such a function should be enabled on a gateway or 
  proxy that acts on behalf of the thin client. [is this within the scope of our 
  work?] 
  <LI>Any requirements relative to P3P policy asserted by servers to be in XML 
  versus RDF formats? 
  <LI>The privacy mechanism must be independent of and separable from security 
  mechanisms. In other words, it should be possible to transmit private CC/PP 
  profile information with or without security. 
  <LI>The combined system of capability profiles and privacy practice 
  declarations must work in the presence of information caches without leaking 
  private information to parties who have not agreed to treat it properly. 
</LI></OL>
<H3><A id="p3p-req-trust" name="p3p-req-trust">A.2 P3P and the requirements for the trust 
mechanism</A></H3>
<P>This is an analysis of how the proposed use of P3P would fulfill the basic 
requirements for the CC/PP trust management framework (section 3).</P>
<OL>
  <LI>A client must be able to discover the privacy practices of an origin 
  server before revealing private profile information 
  <P><EM>Fulfilled, provided no private information is transmitted..</EM></P>
  <LI>The privacy mechanism must be separable from CC/PP framework so that the 
  user has a choice of whether or not privacy mechanism is to be used. In other 
  words, enable CC/PP content negotiation with or without privacy 
  <P><EM>Protocol dependent. Not possible in the examples given.</EM></P>
  <LI>The protocol must allow each client individually to determine what 
  information is private<BR>Any or all of the profile can be considered private. 
  What may be a private piece of information for one user may not be so for 
  another. 
  <P><EM>Fulfilled, provided APPEL, a similar rules language, or a proprietary 
  solution in the device, can be applied to profile construction (or various 
  profiles can be selected). I.e. not in this version.</EM></P>
  <LI>Since CC/PP is protocol independent, the privacy mechanism should also be 
  supported on various transport protocols (including HTTP, MIME, SMTP etc) 
  <P><EM>Not fulfilled (P3P can be used with other protocols than HTTP, as noted 
  in the specification, but how has not been specified). .</EM></P>
  <LI>A client must be able to interact with a server to the point of 
  discovering its privacy policy without having to disclose any particular item 
  of information. 
  <P>For example, a user agent first sends non-private profile data (or an empty 
  profile) to a server, which then responds with a privacy policy, as a result 
  of which, the user agent may either choose to send or not send any additional 
  (personal) information to the server for the purposes of receiving tailored 
  content.</P>
  <P><EM>Fulfilled.</EM></P>
  <LI>It should be possible for the origin server to render content best effort, 
  if the private information is not shared by the user. 
  <P><EM>Fulfilled</EM></P>
  <LI>Intermediate proxies, servers and gateways asserting profile data must 
  also honor the privacy needs of the user. In other words, if the user deems a 
  profile attribute to be private, an intermediate proxy must not disclose that 
  attribute in its profile diff. 
  <P><EM>Fulfilled, if the method above is used..</EM></P>
  <LI>May require user-agent side privacy capability (e.g. P3P user agents) must 
  be supported by such servers/ proxies/ gateways. 
  <P><EM>Fulfilled (although this is actually a strange requirement)</EM></P>
  <LI>As with CC/PP mechanism, the private profile must also support. 
  <UL>
    <LI>additions and overrides by other network elements as specified in the 
    CC/PP specs 
    <LI>inline or URI (indirect) references to the profile information </LI></UL>
  <P><EM>Not fulfilled.</EM></P>
  <LI>The privacy mechanism should support the split client model.<BR>Thin 
  clients such as for low-end devices (on a mobile network for example), may not 
  be able to support the necessary mechanism for privacy (e.g. P3P user agent) 
  perhaps due to overhead. Such a function should be enabled on a gateway or 
  proxy that acts on behalf of the thin client. [is this within the scope of our 
  work?] 
  <P><EM>Fulfilled? (Not sure)</EM></P>
  <LI>Any requirements relative to P3P policy asserted by servers to be in XML 
  versus RDF formats? 
  <P><EM>Not sure what this requirement means.</EM></P>
  <LI>The privacy mechanism must be independent of and separable from security 
  mechanisms. In other words, it should be possible to transmit private CC/PP 
  profile information with or without security. 
  <P><EM>Fulfilled.</EM></P>
  <LI>The combined system of capability profiles and privacy practice 
  declarations must work in the presence of information caches without leaking 
  private information to parties who have not agreed to treat it properly. 
  <P><EM>Not fulfilled (since proxies can still be 
transparent).</EM></P></LI></OL>

<hr>
<p>
  <a href="http://validator.w3.org/check/referer"><img border="0"
     src="http://www.w3.org/Icons/valid-html401"
     alt="Valid HTML 4.01!" height="31" width="88"></a>
</p>

</BODY></HTML>