discontinued / server · Files

index.html 78.2 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 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
                      "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <title>Composite Capabilities/Preference Profiles: Requirements and
  Architecture</title>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-WD">
  <style type="text/css">  
  <!--
TH {text-align : left}
.figure {text-align : center}
PRE {font-family : courier, "MS Courier New", Prestige, "Everson Mono", "Osaka", monospace }
-->




  </style>
</head>

<body lang="en">

<div class="head">
<a href="http://www.w3.org/"><img border="0" height="48" width="72" alt="W3C"
src="http://www.w3.org/Icons/w3c_home"></a>

<h1>Composite Capabilities/Preference Profiles: Requirements and
Architecture</h1>

<h2>W3C Working Draft 21 July 2000</h2>
<dl title="This is a list of URIs for this version, latest public version and
previous version of this document, and authors of this document.">
  <dt>This version:</dt>
    <dd><a href="http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/"
      class="loc">http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/</a></dd>
  <dt>Latest version:</dt>
    <dd><a class="loc"
      href="http://www.w3.org/TR/CCPP-ra/">http://www.w3.org/TR/CCPP-ra/</a></dd>
  <dt>Previous version:</dt>
    <dd><a href="http://www.w3.org/TR/2000/WD-CCPP-ra-20000228/"
      class="loc">http://www.w3.org/TR/2000/WD-CCPP-ra-20000228/</a></dd>
  <dt>Editors:</dt>
    <dd>Mikael Nilsson, <a
      href="mailto:mikael.nilsson@ks.ericsson.se">mikael.nilsson@ks.ericsson.se</a>,
      Ericsson</dd>
    <dd>Johan Hjelm, <a href="mailto:hjelm@w3.org">hjelm@w3.org</a>,
      W3C/Ericsson</dd>
    <dd>Hidetaka Ohto, <a href="mailto:ohto@w3.org">ohto@w3.org</a>,
      W3C/Panasonic</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
2000 <a href="http://www.w3.org/"><abbr title="World Wide Web
Consortium">W3C</abbr></a> <sup>®</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#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#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 title="Separator for header">

<h2><a name="Abstract">Abstract</a></h2>

<p>This document outlines the requirements for a CC/PP framework, vocabulary,
and trust model, and provides an overview of an architecture that satisfies
these requirements. It represents the current consensus of the working
group.</p>

<p></p>

<h2><a name="status">Status of this document</a></h2>

<p>This document is a working draft made available by the World Wide Web
Consortium (W3C) for discussion only. This indicates no endorsement of its
content. This is work in progress, representing the current consensus of the
working group, and future updates and changes are likely.</p>

<p>The working group is part of the <a
href="http://www.w3.org/Mobile/Activity">W3C Mobile Access activity</a>.
Continued status of the work is reported on the <a
href="http://www.w3.org/Mobile/CCPP/">CC/PP Working Group Home Page</a> (<a
href="http://www.w3.org/Mobile/CCPP/Group/">Member-only link</a>).</p>

<p>It incorporates suggestions resulting from reviews and active participation
by members of the IETF CONNEG working group and the WAP Forum UAprof drafting
committee.</p>

<p>Please send comments and feedback to <a
href="mailto:www-mobile@w3.org">www-mobile@w3.org.</a></p>

<p>A list of current W3C Recommendations and other technical documents can be
found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<p></p>

<h2>Table of Contents</h2>
<dl>
  <dt>1. <a href="#Executive_summary">Executive summary</a></dt>
  <dt>2. <a href="#Use_cases">Use cases</a></dt>
  <dt>3. <a href="#Design_assumptions">Design assumptions</a></dt>
  <dt>4. <a href="#Requirements_summary">Requirements summary</a></dt>
  <dt>5. <a href="#Design_goals">Design goals</a></dt>
  <dt>6. <a href="#Architectural_description">Architectural
  description</a></dt>
  <dt>7. <a href="#References">References</a></dt>
  <dt>8. <a href="#Acknowledgments">Acknowledgments</a></dt>
  <dt><a href="#Appendix2">Appendix 1: Requirements used to derive the
  high-level requirements</a></dt>
  <dt><a href="#Appendix3">Appendix 2: Protocol requirements</a></dt>
</dl>

<p></p>
<hr>

<h2><a name="Executive_summary">1. Executive summary</a></h2>

<h3>1.1 Overview</h3>

<p>The goal of the CC/PP framework is to specify how client devices express
their capabilities and preferences (the user agent profile) to the server that
originates content (the origin server). The origin server uses the "user agent
profile" to produce and deliver content appropriate to the client device. In
addition to computer-based client devices, particular attention is being paid
to other kinds of devices such as mobile phones.</p>

<h3>1.2 Executive summary of requirements.</h3>

<p>The requirements on the framework emphasize three aspects: Flexibility,
extensibility, and distribution. The framework must be flexible, since we can
not today predict all the different types of devices that will be used in the
future, or the ways those devices will be used. It must be extensible for the
same reasons: It should not be hard to add and test new descriptions. And it
must be distributed, since relying on a central registry might make it
inflexible.</p>

<h3>1.3 Architecture</h3>

<p>The basic problem that the CC/PP framework addresses is to create a
structured and universal format for how a client device tells an origin server
about its user agent profile. This work aims to present a container that can
be used to convey the profile, and is independent on the protocols used to
transport it. It does not present mechanisms or protocols to facilitate the
transmission of the profile.</p>

<p>The framework describes a standardized set of CC/PP attributes - a
vocabulary - that can be used to express a user agent profile in terms of
capabilities, and the users preferences for the use of these capabilities.
This is implemented using the XML [<a href="#[XML]">XML</a>] application RDF
[<a href="#[RDF]">RDF</a>]. This enables the framework to be flexible,
extensible, and decentralized, thus fulfilling the requirements.</p>

<p>RDF is used to express the client device's user agent profile. The client
device may be a workstation, personal computer, mobile terminal, or set-top
box.</p>

<p>When used in a request-response protocol like HTTP, the user agent profile
is sent to the origin server which, subsequently, produces content that
satisfies the constraints and preferences expressed in the user agent profile.
The CC/PP framework may be used to convey to the client device what variations
in the requested content are available from the origin server.</p>

<p>Fundamentally, the CC/PP framework starts with RDF and then overlays a
CC/PP-defined set of semantics that describe profiles.</p>

<p>The CC/PP framework does not specify whether the client device or the
origin server initiates this exchange of profiles. What the CC/PP framework
does specify is the RDF usage and associated semantics that should be applied
to all profiles that are being exchanged.</p>

<h2><a name="Use_cases">2. Use cases for CC/PP</a></h2>

<p>In this section, we describe use cases for the use of a profile to adapt
information for presentation by a client. The use cases are intended to
describe a number of situations where the CC/PP format can be used; however,
they are not an exhaustive list, nor are the behaviour of any element in the
use cases described below mandatory. Rather, they represent the working groups
best understanding at the time.</p>

<h3></h3>

<h3>2.1 Web CC/PP usecases</h3>

<h4>2.1.1 Background</h4>

<p>Using the World Wide Web with content negotiation as it is designed today
enables the selection of a variant of a document. Using an extended
capabilities description, an optimized presentation can be produced. This can
take place by selecting a style sheet that is transmitted to the client, or by
selecting a style sheet that is used for transformations. It can also take
place through the generation of content, or transformation, e.g. using XSLT <a
href="#[XSLT]">[XSLT]</a>.</p>

<p>The CC/PP Exchange Protocol [<a href="#[CCPPex]">CCPPex</a>] extends this
model by allowing for the transmission and caching of profiles, and the
handling of profile differences.</p>

<p>This use case in itself consists of two different use cases: The origin
server receives the CC/PP profile directly from the client; the origin server
retrieves the CC/PP profile from an intermediate repository.</p>

<h4>2.1.2 Profile is communicated directly to origin server</h4>

<p>This use case describes a case where the profile is used by an origin
server on the web to adapt the information returned in the request.</p>

<p>The CC/PP Exchange Protocol [<a href="#[HTTPex]">HTTPex</a>] creates a
modified HTTP GET which carries the profile or the profile difference. The
extended content negotiation with the CC/PP Exchange Protocol uses the CC/PP
format to describe the device. In this context, no vocabulary has been
defined. The existence of the CC/PP Exchange protocol is assumed.</p>

<h5>2.1.2.1 Protocol interactions</h5>

<div class="figure">
<img src="Webcase.png" alt="Image of a request and a response from a client to
a server"> <br>
<i>Figure 1: The HTTP use case</i></div>

<p>When the interaction passes directly between a client and a server, the
process is relatively simple: The user agent sends the profile information
with the request, and the server returns adapted information. The interaction
takes place over an extended HTTP method, as described in the CC/PP Exchange
framework.</p>

<h4>2.1.3 CC/PP profile is retrieved from repository</h4>

<p>When the profile is composed by resolving inline references from a
repository for the profile information, the process is slightly more
complicated, but in principle the same.</p>

<div class="figure">
<img src="Proxyrepositorycase.png" alt="Image of request and response with the
origin server resolving an inline profile"> <br>
<i>Figure 2: The HTTP use case with repository for the profile
information</i></div>

<p>The interactions take place in more steps, but is basically the same:</p>

<p>1: Request from client with profile information.</p>

<p>2: Server resolves and retrieves profile (from CC/PP repository on the
network), and uses it to adapt the content.</p>

<p>4: Server returns adapted content.</p>

<p>5: Proxy forwards response to client.</p>

<p>Note that the notion of a proxy resolving the information and retrieving it
from a repository might assume the use of an XML processor and encoding of the
profile in XML.</p>

<h4>2.1.4 The document profile use case</h4>

<p>In case the document contains a profile, the above could still apply.
However, there will be some interactions inside the server, as the client
profile information needs to be matched with the document profile. The
interactions in the server are not defined. This group will not standardize
the matching algorithm. We will standardize the profile system, which is the
interface to it.</p>

<div class="figure">
<img src="Docprofcase.png" alt="Image illustrating profile processing using a
document profile"> <br>
<i>Figure 3: The document profile usecase</i></div>
<ol>
  <li>Request (extended method) with profile information.</li>
  <li>Document profile is matched against device profile to derive optimum
    representation.</li>
  <li>Document is adapted.</li>
  <li>Response to client with adapted content.</li>
</ol>

<h4>2.1.4 Requirements</h4>

<p>No formal requirements document has been formulated in this activity.
However, the use of the CC/PP Exchange Protocol is assumed.</p>

<p>One requirement is that the integrity of the information is guaranteed
during transit.</p>

<p>In the proxy use case, a requirement is the existence of a method to
resolve references in the proxy. This might presume the use of an XML
processor and XML encoding.</p>

<p>The privacy of the user needs to be safeguarded. This is not a technical
requirement, but a societal.</p>

<p>The document profile and the device profile can use a common vocabulary for
common features. They can also use compatible feature constraining forms so
that it is possible to match a document profile against a receiver profile and
determine compatibility. If not, a mapping needs to be provided for the
matching to take place.</p>

<h3>2.2. The WAP usecase</h3>

<p>This use case describes a mixed architecture with an active proxy in the
network. The use of CC/PP profiles in the WAP architecture is more fully
described in <a href="#[UAProf]">[UAProf]</a>.</p>

<h4>2.2.1 Background</h4>

<p>In the WAP Forum, an architecture optimized for connecting devices working
with very low bandwidths and small message sizes has been developed. In
version 1.2 of this architecture, a format based on RDF is used to communicate
client profile information<strong></strong>.</p>

<p>The WAP Forum architecture is based on a proxy server, which acts as a
gateway to the optimized protocol stack for the mobile environment. It is to
this proxy which the mobile device connects. On the wireless side of the
communication, it uses an optimized, stateful protocol (Wireless Session
Protocol, WSP [<a href="#[WSP]">WSP</a>]; and an optimized transmission
protocol, Wireless Transaction Protocol, WTP [<a href="#[WTP]">WTP</a>]); on
the fixed side of the connection, it uses HTTP [<a
href="#[HTTP/1.1]">HTTP/1.1</a>]. The content is marked up in WML, the
Wireless Markup Language of the WAP Forum.</p>

<p>The mobile environment requires small messages and has a much narrower
bandwidth than fixed environments.</p>

<h4>2.2.2 Architecture</h4>

<p>When a user agent profile is used with a WAP device, it looks like
this:</p>

<div class="figure">
<img src="Wapusecase.png" alt="Image illustrating the flow of a profile in a
WAP environment"> <br>
<i>Figure 4: The WAP use case</i></div>

<p></p>
<ol>
  <li>WSP request with profile information or difference relative to a
    specified default.</li>
  <li>Gateway caches WSP header, composes the current profile (using the
    cached header as defaults, and diffs from the client). UAprof values can
    change at setup or resume of session.</li>
  <li>Gateway passes request to server using extended HTTP method.</li>
  <li>Server returns adapted information.</li>
  <li>Response in WSP with adapted content.</li>
</ol>

<p></p>

<p>The user agent profile is transmitted as a parameter of the WSP session to
the WAP gateway and cached; it is then transferred over HTTP using the CC/PP
Exchange Protocol [<a href="#[CCPPex]">CCPPex</a>], which is an application of
the HTTP Extension Framework[<a href="#[HTTPex]">HTTPex</a>].</p>

<p>Note that the WAP system uses WML[<a href="#[WML]">WML</a>] as its content
format, not HTML. This is an XML application, and the adaption could for
instance be transformation from another XML format into WML.</p>

<p></p>

<h4>2.2.2.1 Vocabulary</h4>

<p>The WAP UAPROF group has developed a core vocabulary for mobile devices, as
presented in [<a href="#[UAProf]">UAProf</a>].</p>

<h4>2.2.3 Requirements</h4>

<p>The WAP Forum went through an extensive requirements gathering process
before producing their specifications. The requirements document lists a
number of requirements that has been placed on the solution. These have been
included in our requirements with the prefix UAprof. For more information, see
[<a href="#[UAProf]">UAProf</a>].</p>

<h4>Requirements for future versions are:</h4>

<p>Addressing XML fragments</p>

<p>Secure transmission</p>

<h3>2.3. The MIME multipart usecase</h3>

<h4>2.3.1 Background</h4>

<p>The Conneg working group in the IETF has developed a form of media feature
descriptors, which are registered with IANA. Like the CC/PP format and
vocabulary, this is intended to be independent of protocol. The Conneg working
group also defined a matching semantics, based on constraints.</p>

<h4>2.3.2 Architecture</h4>

<p>The CONNEG framework defines an IANA registry for feature tags, which are
used to label media feature values associated with the presentation of data
(e.g. display resolution, color capabilities, audio capabilities, etc.). To
describe a profile, CONNEG uses predicate expressions ("feature predicates")
on collections of media feature values ("feature collection") as an acceptable
set of media feature combinations ("feature set"). The same basic framework is
applied to describe receiver and sender capabilities and preferences, and also
document characteristics. Profile matching is performed by finding the feature
set that matches two (or more) profiles. This involves finding the feature
predicate that is equivalent to the logical-AND of the predicates being
matched. (See RFCs [<a href="#[RFC2506]">RFC2506</a>] and [<a
href="#[RFC2533]">RFC2533</a>] for further information.)</p>

<p></p>

<h4>2.3.2.1 Mime multipart server-initiated use case</h4>

<div class="figure">
<img src="Broadcastcase.png" alt="Image illustrating what essentially is a
broadcast use case"> <br>
<i>Figure 5: The Conneg use case</i></div>

<p>The Conneg system is not dependent on any one protocol, and could
conceivably be used in all the use cases above, given that the information set
to be matched could be expressed in the Conneg format.</p>

<p>Conneg is protocol independent, but can be used for server-initiated
transactions.</p>

<p>Here is what the server-initiated use case would look like:</p>
<ol>
  <li>Server sends to proxy</li>
  <li>Proxy retrieves profile from client (or checks against a cache)</li>
  <li>Client returns profile</li>
  <li>Proxy formats information and forwards it</li>
</ol>

<h4>2.3.2.2 Information structure(s)</h4>

<p>The Conneg system uses a structured text format to describe the device and
its capabilities. This is described in [<a href="#[RFC2533]">RFC2533</a>].</p>

<h4>2.3.2.3 Vocabulary</h4>

<p>The Conneg working group has defined a set of core media features, which
are described in [<a href="#[RFC2543]">RFC2543</a>]. A comparison of these and
the UAPROF features is found in [<a href="#[UAProf]">UAProf</a>].</p>

<h4>2.3.3 Requirements</h4>

<p>The Conneg group started its work with developing an extensive requirements
document, which is found in [<a href="#[RFC2703]">RFC2703</a>]. They are
listed as CONNEG in appendix 2.</p>

<h3>2.4. The TV/broadcast usecase</h3>

<p>This use case describes a push situation, where a broadcaster sends out an
information set to a device without a backchannel. The server can not get
capabilities for all devices. So it broadcasts a minimum set of elements. Or a
multipart document, which is then adapted to the optimal presentation for the
device.</p>

<h4>2.4.1 Background</h4>

<p>Television manufacturers desire to turn their appliances into interactive
devices. This effort is based on the use of XHTML as language for the content
representation, which for instance enables the use of content profiles as seen
in 2.2.4.</p>

<h4>2.4.2 Architecture</h4>

<p>Unlike the use cases above, a television set does not have a local
intelligence of its own, and does not allow for bidirectional communication
with the origin server. This architecture also applies to several different
device classes, such as pagers, e-mail clients and other similar devices.</p>

<p>It is not the case that they are entirely without interaction, however. In
reality, these devices follow a split-client model, where the broadcaster,
cable head-end, or similar entity interacts with the origin server, and sends
a renderable version of the content to the part of the client which resides at
the user site. In this aspect, they resemble the intermediary proxy in
2.5.</p>

<p>There are however also use cases where the entire data set is downloaded
into the client, and the optimal rendering is constructed there, for instance
in a settop box. This resembles 2.1.4, except that the matching of the
document profile with the device capabilities does not take place in the
origin server, but in the client. In these cases, the CC/PP client profile
will need to be matched against a document profile, representing the authors
preferences for the rendering of the document.</p>

<h4>2.4.3 Protocol interactions</h4>
<ol>
  <li>Document is pushed to the client including alternate information and
    document profile.</li>
  <li>Client matches the rules in the document profile and its own
  profile.</li>
  <li>The client adapts content to its optimal presentation using the derived
    intersection of the two sets.</li>
</ol>

<h5>2.4.3.1 Information structure(s)</h5>

<p>The CC/PP profile and the document profile should ideally be in the same
format, as described in 2.2.4.</p>

<h5>2.4.3.2 Vocabulary</h5>

<p>The level of detail in a vocabulary that is intended to enable rendering of
information on devices without an intelligence of their own is unclear. See
section 6.3 for a further discussion on the vocabulary developed by the group,
and possible extensions.</p>

<h4>2.4.4 Requirements</h4>

<p>Since this can be seen as a special case of the application of document
profiles, no separate requirements have been derived.</p>

<h3>2.5 Assertion of capabilities by intermediate network elements (proxies
and caches)</h3>

<p>This use case describes how an intermediate entity interacts with the
profile and the information received in the response.</p>

<h4>2.5.1 Background</h4>

<p>When a request for content is made by a user agent to an origin server, a
CC/PP profile describing the capabilities and preferences is transmitted along
with the request. It is quite conceivable that intermediate network elements
such as gateways and transcoding proxies that have additional capabilities
might be able to translate or adapt the content before rendering it to the
device. Such capabilities are not known to the user agents and therefore
cannot be included in the original profile. However, these capabilities would
need to be conveyed to the origin server or proxy serving/ generating the
content. In some instances, the profile information provided by the requesting
client device may need to be overridden or augmented.</p>

<p>For instance, consider a user agent that can render gif images. If there is
a transcoding proxy in the network that has the ability to convert jpeg images
to gif, the proxy can assert this capability to the origin server that may be
able to render content only in jpeg. Similarly, a gateway may wish to add
information to the profile to override the profile information sent by the
requestor, for example, to reflect the policies in place by the network or
gateway operator.</p>

<h4>2.5.2 Architecture</h4>

<p>CC/PP framework must therefore support the ability for such proxies and
gateways to assert their capabilities using the existing vocabulary or
extensions thereof. This can be done as amendments or overrides to the profile
included in the request. Given the use of XML as our base format, these can be
inline references, to be downloaded from a repository as the profile is
resolved (see use case 2.2.3).</p>

<h4>2.5.3 Protocol interactions</h4>

<div class="figure">
<img src="Proxytranscodecase.png" alt="Image illustrating the use of a
transcoding proxy appending profile information"> <br>
<i>Figure 6: The Intermediate Entity use case</i></div>

<p>1. The CC/PP compliant user agent requests content with the profile.</p>

<p>2. The transcoding proxy appends additional capabilities (profile segment),
or overrides the default values, and forwards the profile to the network.</p>

<p>3. The origin server constructs the profile and generates adapted
content.</p>

<p>4. The transcoding proxy transcodes the content received based on its
abilities, and forwards the resulting customized content to the device for
rendering.</p>

<h4>2.5.3.1 Information structure(s)</h4>

<p>The CC/PP framework can still be used, given the ability of overrides or
amendments. It is also possible that users wish to select attributes that can
not be overridden.</p>

<h4>2.5.3.2 Vocabulary</h4>

<p>No specific vocabulary is necessary to express this use case.</p>

<h4>2.5.4 Requirements</h4>

<p>This use case requires that entries can be added to the CC/PP profile.</p>

<p>An implicit requirement is that this takes place in a secure way,
safeguarding the integrity of the original profile.</p>

<h2><a name="Design_assumptions">3. Design assumptions</a></h2>

<p>The following assumptions have been identified during the process of the
work. These assumptions are basic tenets of the design, as well as assumptions
about other elements in the process, such as network elements and origin
servers. There are implicit requirements inherent in this, which constitute
MUST requirements (e.g. the implication of internationalization on the use of
XML).</p>

<p>The basic assumptions are:</p>
<ul>
  <li>We use RDF</li>
  <li>We use XML (with all that is inherent in that)</li>
  <li>We use the structures in the CC/PP Note</li>
  <li>HTTP is the assumed protocol but the framework must also be
    transportable over other protocols</li>
  <li>Rendering of information is a primary goal but not exclusive</li>
  <li>A wide variety of devices will be supported by customizing an
    information set for them (so there is no need to design in all possible
    that will occur in the future).</li>
  <li>The transmission of the CC/PP profile and the transmission of the
    content are separate.</li>
</ul>

<h3>3.2 Security considerations</h3>

<p>Security is here understood to be something else than privacy and trust.
Security, in this context, is the safeguarding of the transmitted information
in the course of transmission. These problems are usually addressed by the
protocol used to carry the information, not the information structure or
vocabulary itself. Privacy may be handled using the P3P mechanism of the W3C
<a href="#[P3P]">[P3P]</a>. Integrity of the information is another matter,
and is addressed in the requirements under section 4.1.3 below.</p>

<h2><a name="Requirements_summary">4. Requirements summary</a></h2>

<p>These requirements have been derived from the usecases above. But since
several efforts exist to produce systems for content negotiation, we have also
derived requirements from the work of others, especially the IETF Conneg
working group (CONNEG) and the WAP Forum UAPROF Drafting Committee (UAP).
Requirements have also been derived from the HTML working group in the W3C
(XHTML), and from our own face-to-face meetings (F2F). Requirements have also
been derived from experimental implementations presented to the working group
(CCPP-IMPL).</p>

<p>The requirements are summarized in the order they impact the deliverables
of the working group. However, requirements will typically impact the entire
architecture, not one single deliverable. This listing is therefore for
convenience only.</p>

<p>In addition, we have derived a set of protocol requirements. While the
working group is not chartered to develop a protocol, it is still clear that
its work will impact the design of any protocol used in the content
negotiation process. These requirements have therefore been highlighted in
Appendix 3.</p>

<p>The fulfillment of these requirements are mandatory for the design of
CC/PP. They are MUST requirements.</p>

<h3>4.1. Requirements Listing</h3>

<h4>4.1.1 Requirements on the framework</h4>
<ul>
  <li>FW1: This group shall develop a framework to specify how client devices
    express their capabilities and preferences to a server which uses this
    information to produce and deliver content appropriate to the client
    device.</li>
  <li>FW-2: The framework shall ultimately enable delivery of content in a
    format tailored to the specific device characteristics, application
    settings, operating environment and user preferences.</li>
</ul>
<ul>
  <li>FW-3: The design shall support the ability to reference capability
    information stored separately on various systems and databases in the
    network. The profile can be dynamically composed from client-provided
    default values and referenced values. It shall be possible to override or
    append CC/PP attributes to a profile.</li>
</ul>

<h4>4.1.2 Requirements on the vocabulary and schema</h4>
<ul>
  <li>VS-1: The vocabulary shall allow for the expression of relations between
    CC/PP attribute values.</li>
  <li>VS-2: There shall be a stable, common, minimum vocabulary for
    designating features and feature sets.</li>
  <li>VS-3: There shall be a simple, uniform way to extend vocabularies.</li>
</ul>

<h4>4.1.3 Requirements on the trust model</h4>
<ul>
  <li>TF1: It must be possible to disclose (at a transaction level) only a
    subset of the CC/PP.</li>
  <li>TF2: It must be possible for the originator or recipient of a profile or
    a profile element to detect cases where the integrity of the profile was
    not violated.</li>
  <li>TF3: The CC/PP trust framework MUST provide a mechanism for a server (or
    proxy) that processes a CC/PP profile to indicate whether it requires a
    profile to be authenticated.</li>
  <li>TF4: The trust mechanisms are not allowed to break other things that are
    important (such as added headers by transcoding proxies, cache matches
    etc).</li>
</ul>

<h2><a name="Design_goals">5. Design goals</a></h2>

<p>Design goals are not as strong as requirements (SHOULD instead of MUST),
and concern the entire architecture rather than a specific part of it.</p>

<p>The goals for the system are as follows:</p>
<ul>
  <li>DG-1: It is to consume as little network, client and server resources as
    possible.</li>
  <li>DG-2: Vocabulary items are to be defined in RDF Schema. Vocabularies and
    profiles can be extended using namespaces. The vocabularies created shall
    include vocabularies that are semantically compatible with established
    practices, so as to enable speedy adoption and ease of use for
  developers.</li>
  <li>DG-3: Digital signatures are to be used as part of the trust
  framework.</li>
  <li>DG-4: P3P is to be used as management mechanism for the privacy of
    profiles.</li>
  <li>DG-5: Proxies and caches are to be allowed to participate in the
    negotiation process, as appropriate.</li>
  <li>DG-6: It shall be possible to match two profiles for equality in a
    lightweight manner.</li>
  <li>DG-7: The system shall enable the expression of "hints" in the content
    for optimized rendering based on a given, or a set of given, CC/PP
    profiles.</li>
  <li>DG-8: The system shall enable less abled users to access information in
    a manner that they have defined. (WAI coordination is needed for this
    goal).</li>
  <li>DG-9: The system shall be usable with existing protocols. It shall be
    possible to describe whether it is mandatory or optional to enforce an
    attribute.</li>
</ul>

<h3>5.1 Desirable features and future work</h3>

<p>Desirable features are not mandated, and optional to the design only if we
feel like it. In terms of RFC 2119 <a href="#[RFC2119]">[RFC2119]</a> they are
MAY-requirements.</p>

<p>FW-4: The framework shall allow for the description of preferences for its
use, either through an algorithm within the framework or through a set of
constraint semantics.</p>

<h2><a name="Architectural_description">6 Architectural description</a></h2>

<p>To fulfill the requirements in 3, 4 and 5, the CC/PP working group intend
to produce a framework to handle and structure the profile information. The
working group will also produce a basic vocabulary and describe how this can
be extended (or other vocabularies can be created and referenced). In
addition, the trust model for the work will be described in a separate
document, as well as implementation issues.</p>

<h3>6.1 Profile framework</h3>

<p>The capabilities of the users client agent, and the preferences for the way
the user wants them to be used, are expressed in a profile. The profile is
constructed of a set of components that can be used to convey a group of
attributes that are in some way related. The profile can consist of URI's that
reference information or properties available in other documents or
profiles.</p>

<p>The components that are available in a profile, along with the applicable
attributes are specified as an instance of an RDF schema [<a
href="#[RDF-Schema]">RDF-Schema</a>]. The profile may contain URI's that
reference separately provided information or properties. A user agent or
intermediary network entity can change the value of a CC/PP attribute. RDF is
explained in further detail in section 6.2.</p>

<h3>6.2 RDF</h3>

<h4>6.2.1 Basic RDF Model</h4>

<p>The foundation of RDF is a model for representing named properties and
property values. The RDF model draws on principles from various data
representation communities. RDF properties may be thought of as attributes of
resources and in this sense correspond to traditional attribute-value pairs.
RDF properties also represent relationships between resources and an RDF model
can therefore resemble an entity-relationship diagram. (More precisely, RDF
Schemas which are themselves instances of RDF data models are ER diagrams.) In
object-oriented design terminology, resources correspond to objects and
properties correspond to instance variables.</p>

<p>The RDF data model is a syntax-neutral way of representing RDF expressions.
The data model representation is used to evaluate equivalence in meaning. Two
RDF expressions are equivalent if and only if their data model representations
are the same. This definition of equivalence permits some syntactic variation
in expression without altering the meaning. (See Section 6.6 for additional
discussion of string comparison issues.)</p>

<p>The basic data model consists of three object types:</p>
<dl>
  <dt>Resources</dt>
    <dd>All things being described by RDF expressions are called resources. A
      resource may be an entire Web page; such as the HTML document
      "http://www.w3.org/Overview.html" for example. A resource may be a part
      of a Web page; e.g. a specific HTML or XML element within the document
      source. A resource may also be a whole collection of pages; e.g. an
      entire Web site. A resource may also be an object that is not directly
      accessible via the Web; e.g. a printed book. Resources are always named
      by URIs plus optional anchor id:s (see [<a
      href="#[RFC2396]">RFC2396</a>]). Anything can have a URI; the
      extensibility of URIs allows the introduction of identifiers for any
      entity imaginable.</dd>
</dl>
<dl>
  <dt>Properties</dt>
    <dd>A property is a specific aspect, characteristic, attribute, or
      relation used to describe a resource. Each property has a specific
      meaning, defines its permitted values, the types of resources it can
      describe, and its relationship with other properties. This document does
      not address how the characteristics of properties are expressed; for
      such information, refer to the RDF Schema specification).</dd>
</dl>
<dl>
  <dt>Statements</dt>
    <dd>A specific resource together with a named property plus the value of
      that property for that resource is an RDF statement. These three
      individual parts of a statement are called, respectively, the subject,
      the predicate, and the object. The object of a statement (i.e., the
      property value) can be another resource or it can be a literal; i.e., a
      resource (specified by a URI) or a simple string or other primitive
      datatype defined by XML. In RDF terms, a literal may have content that
      is XML markup but is not further evaluated by the RDF processor. There
      are some syntactic restrictions on how markup in literals may be
      expressed; see Section 6.2.1.</dd>
</dl>

<h4>6.2.2 Referencing of external resources</h4>

<p>RDF properties may be thought of as attributes of resources and in this
sense correspond to traditional attribute-value pairs. RDF properties also
represent relationships between resources. As such, the RDF data model can
therefore resemble an entity-relationship diagram. The RDF data model,
however, provides no mechanisms for declaring these properties, nor does it
provide any mechanisms for defining the relationships between these properties
and other resources. That is the role of RDF Schema.</p>

<p>Each RDF schema is identified by its own static URI. The schema's URI can
be used to construct unique URI references for the resources defined in a
schema. This is achieved by combining the local identifier for a resource with
the URI associated with that schema namespace. The XML representation of RDF
uses the XML namespace mechanism for associating elements and attributes with
URI references for each vocabulary item used.</p>

<p>Please refer to the Namespaces in XML <a href="#[XML-name]">[XML-name]</a>
document for a complete description of how namespaces can be constructed in
XML/RDF.</p>

<h4>6.2.3. RDF Schema Constraints</h4>

<p>An RDF schema can declare constraints associated with classes and
properties. In particular, the concepts of domain and range are used in RDF
schemas to make statements about the contexts in which certain properties
"make sense". Although the RDF data model does not allow for explicit
properties (such as an rdf:type property) to be ascribed to Literals (atomic
values), we nevertheless consider these entities to be members of classes
(e.g. the string "John Smith" is considered to be a member of the class
rdfs:Literal.) We expect future work in RDF and XML data-typing to provide
clarifications in this area.</p>

<p>An RDF model that violates any of the consistency constraints specified in
this document is said to be an inconsistent model. The following constraints
are specified: rdfs:domain and rdfs:range constraints on property usage, the
rule that rdfs:subPropertyOf and rdfs:subClassOf properties should not form
loops, plus any further consistency constraints defined using the
rdfs:ConstraintResource extensibility mechanism. Different applications may
exhibit different behaviors in the face of an inconsistent model.</p>

<p>Some examples of constraints include:</p>
<ul>
  <li>That the value of a property should be a resource of a designated class.
    This is expressed by the range property. For example, a range constraint
    applying to the 'author' property may express that the value of an
    'author' property must be a resource of class 'Person'.</li>
  <li>That a property may only be used on resources of a certain class. For
    example, that an 'author' property could only originate from a resource
    that was an instance of class 'Book'. This is expressed using the domain
    property.</li>
</ul>

<p>RDF schemas can express constraints that relate vocabulary items from
multiple independently developed schemas. Since URI references are used to
identify classes and properties, it is possible to create new properties whose
domain or range is constrained to be a class defined in another namespace.</p>

<p>The RDF Schema uses the constraint properties to constrain how its own
properties can be used. These constraints are shown below in figure 7. Nodes
with bold outlines are instances of rdfs:Class.</p>

<div class="figure">
<img src="constraints.png" alt="Image illustrating constraints in RDF Schema">
<br>
<i>Figure 7: Constraints in the RDF Schema</i></div>

<p>Please refer to the RDF Schema <a href="#[RDF-Schema]">[RDF-schema]</a> for
a more complete description of RDF Constraints.</p>

<h3>6.3 Vocabulary</h3>

<p>A CC/PP profile describes client capabilities in terms of a number of
"CC/PP attributes", or "features". Each of these features is identified by a
name in the form of a URI. A collection of such names used to describe a
client is called a "vocabulary".</p>

<p>CC/PP defines a small, core set of features that are applicable to wide
range of user agents, and which provide a broad indication of a clients
capabilities. This is called the "core vocabulary". It is expected that any
CC/PP processor will recognize all names in the core vocabulary, together with
an arbitrary number of additional names drawn from one or more "extension
vocabularies".</p>

<p>When using names from the core vocabulary or an extension vocabulary, it is
important that all system components (clients, servers, proxies, etc.) that
generate or interpret the names all apply a common meaning to the same name.
It is preferable that different components use the same name to refer to the
same feature, even when they are part of different applications, as this
improves the chances of effective interworking across applications that use
capability information.</p>

<p>Within an RDF expression describing a device, a vocabulary name appears as
the label on a graph edge linking a resource to a value for the named
attribute. The attribute value may be a simple string value, or another
resource, with its own attributes representing the component parts of a
composite value.</p>

<p></p>
<pre title="ASCII image of resource, attribute-name, and attribute-value">+-------------+                     +------------+ 
| Resource    |---attribute-name--->| Attribute  | 
|             |                     | value      | 
+-------------+                     +------------+ </pre>

<p>Simple string values may be used in comparison constraints
[Ref-CCPP-format-document], which may interpret the attribute value as a
textual or numeric value.</p>

<h4>6.3.1 Vocabulary extensions</h4>

<p>Vocabulary extensions are used to identify more detailed information than
can be described using the core vocabulary. Any application or operational
environment that uses CC/PP may define its own vocabulary extensions, but
wider interoperability is enhanced if vocabulary extensions are defined that
can be used more generally; e.g. a standard extension vocabulary for imaging
devices, or voice messaging devices, or wireless access devices, etc.</p>

<p>Any CC/PP expression can use terms drawn from an arbitrary number of
different vocabularies, so there is no restriction caused by re-using terms
from an existing vocabulary rather then defining new names to identify the
same information.</p>

<p>As indicated above, CC/PP attribute names are in the form of a URI. Any
CC/PP vocabulary is associated with an XML namespace, which combines a base
URI with a local XML element name (or XML attribute name) to yield a URI
corresponding to an element name. Thus, CC/PP vocabulary terms are constructed
from an XML namespace base URI and a local attribute name; e.g. the namespace
URI:</p>

<p>http://w3c.org/ccpp-core-vocabulary/</p>

<p>and the core vocabulary name:</p>

<p>type</p>

<p>are combined to yield the attribute name URI:</p>

<p>http://w3c.org/ccpp-core-vocabulary/type</p>

<p>Anyone can define and publish a CC/PP vocabulary extension (assuming
administrative control or allocation of a URI for an XML namespace). For such
a vocabulary to be useful, it must be interpreted in the same way by
communicating entities. Thus, use of an existing extension vocabulary is
encouraged wherever possible, or publication of a new vocabulary definition
containing detailed descriptions of the various CC/PP attribute names.</p>

<p>Many extension vocabularies will be drawn from existing applications and
protocols; e.g. WAP UAPROF, IETF media feature registrations, etc.</p>

<h3>6.4 Document profiles and service profiles</h3>

<p>CC/PP expresses the user agent capabilities and how the user wants to use
them.</p>

<p>XHTML document profiles[<a href="#[XHTML-docprof]">XHTML-docprof</a>]
express the required functionalities for what the author perceives as optimal
rendering, and how the author wants them to be used.</p>

<p>The same mechanisms can be used to describe the document profile as the
device capabilities profile, i.e. the framework described in section 6.2
combined with an extension vocabulary as described in 6.3.1 expressing the
specific functionalities. This can, for instance, reflect the XHTML modules
used, copyright issues, etc.</p>

<h3>6.5 Matching of profiles in different formats</h3>

<p>It is quite conceivable that when a device profile is expressed in CC/PP,
it will have to be matched with a document profile expressed in a different
format to achieve the adaption of content described above. This means that
either of the profiles has to be translated to either the format of the other,
or both to a common format.</p>

<p>In the scope of this activity, we will not discuss the translation of CC/PP
profiles to other formats. We will regard the CC/PP format as the common
format, to which other profile formats have been mapped (other groups are of
course welcome to create converse mappings; we are trying to work out how this
would work in the scope of our activity).</p>

<p>The interactions would work as follows:</p>
<ol>
  <li>Request (extended method) with profile information.</li>
  <li>Profile translation (note: The following refers to functional elements.
    The entire process could conceivably take place in the origin server).
    <ol type="a">
      <li>Schema for document profile is retrieved (from a repository or other
        entity).</li>
      <li>Server resolves mappings and creates an intermediary CC/PP schema
        for the matching.</li>
    </ol>
  </li>
  <li>Document profile is matched against device profile to derive optimum
    representation.</li>
  <li>Document is adapted.</li>
  <li>Response to client with adapted content. Depending on the format of the
    document profile, the translation can be done in different ways.</li>
  <li>In the case of a dedicated XML-based format, mapping the XML Schema for
    the dedicated format to the schema for RDF will allow the profile to be
    expressed as RDF by the translating entity. In the case of a non-XML-based
    format, a one-to-one mapping will have to be provided for the
  translation.</li>
</ol>

<p>This group will also describe how to map a different format to the CC/PP
format, using the Conneg vocabulary as an example.</p>

<h2><a name="7"></a><a name="References">7. References</a></h2>

<p><a name="[CC/PP]">[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 name="[CCPPex]">[CCPPex] </a><a
href="http://www.w3.org/TR/NOTE-CCPPexchange">CC/PP exchange protocol based on
HTTP Extension Framework</a></p>

<p><a name="[FAX-conneg]">[FAX-conneg] </a><a
href="http://www.ietf.org/internet-drafts/draft-ietf-fax-content-negotiation-02.txt">Content
Negotiation for Facsimile Using Internet Mail</a></p>

<p><a name="[HTTPex]">[HTTPex]</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="[IOTPsig]">[Dsig] </a><a
href="http://www.w3.org/TR/2000/WD-xmldsig-core-20000208/">XML-Signature
Syntax and Processing</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="[P3P-Syntax]">[P3P-Syntax]</a> <a
href="http://www.w3.org/TR/P3P/">Platform for Privacy Preferences (P3P1.0)
Syntax Specification</a></p>

<p><a 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 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 name="[RFC2543]">[RFC2543] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2534.txt">RFC 2543 : Media Features for
Display, Print, and Fax</a></p>

<p><a name="[RFC2506]">[RFC2506] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2506.txt">RFC 2506 : Media Feature Tag
Registration Procedure</a></p>

<p><a name="[RFC2533]">[RFC2533] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2533.txt">RFC 2533 : A Syntax for
Describing Media Feature Sets</a></p>

<p><a name="[RFC2703]">[RFC2703] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2703.txt">RFC 2703 : Protocol-independent
content negotiation framework</a></p>

<p><a name="[RFC2738]">[RFC2738] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2738.txt">RFC 2738 : Corrections to 'A
syntax for describing media feature sets'</a></p>

<p><a name="[RFC2246]">[RFC2246] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2246.txt">RFC2246 : The TLS Protocol
Version 1.0</a></p>

<p><a name="[RFC2119]">[RFC2119]</a> <a
href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">RFC 2119 : Key words for use in
RFCs to Indicate Requirement Levels</a></p>

<p><a name="[RFC2045]">[RFC2045]</a> <a
href="ftp://ftp.isi.edu/in-notes/rfc2045.txt">RFC 2045 : Multipurpose Internet
Mail Extensions(MIME) Part One: Format of Internet Message Bodies</a></p>

<p><a name="[RFC2396]">[RFC2396] </a><a
href="ftp://ftp.isi.edu/in-notes/rfc2396.txt">RFC 2396 : Uniform Resource
Identifiers (URI): Generic Syntax</a></p>

<p><a name="[UAProf]">[UAProf] </a><a
href="http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf">User
Agent Profiling Specification 10-Nov-1999</a></p>

<p><a name="[WSP]">[WSP] </a><a
href="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WSP-19991105.pdf">WAP
Wireless Session Protocol Specification</a></p>

<p><a name="[WTP]">[WTP] </a><a
href="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WSP-19991105.pdf">WAP
Wireless Transaction Protocol Specification</a></p>

<p><a name="[WML]">[WML] </a><a
href="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WML-19991104.pdf">WAP
Wireless Markup Language Specification</a></p>

<p><a name="[WTLS]">[WTLS] </a><a
href="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WTLS-19991105.pdf">WAP
Wireless Transport Layer Security Specification</a></p>

<p><a name="[WBXML]">[WBXML] </a><a
href="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WBXML-19991104.pdf">WAP
Binary XML Content Format Specification</a></p>

<p><a name="[XHTML-docprof]">[XHTML-docprof]</a> <a
href="http://www.w3.org/TR/xhtml-prof-req/">XHTML Document Profile
Requirements - Document profiles - a basis for interoperability
guarantees</a></p>

<p><a name="[XML]">[XML] </a><a
href="http://www.w3.org/TR/1998/REC-xml-19980210">Extensible Markup Language
(XML) 1.0</a></p>

<p><a name="[XML-name]">[XML-name]</a> <a
href="http://www.w3.org/TR/REC-xml-names/">Namespaces in XML</a></p>

<p><a name="[XSLT]">[XSLT] </a><a href="http://www.w3.org/TR/xslt">XSL
Transformations</a></p>

<p></p>

<h2><a></a><a name="Acknowledgments">8. Acknowledgments</a></h2>

<p>This document has been edited by the editors, but the real credit goes to
the CC/PP working group, especially those members who provided input to this
document, listed below:</p>

<p>Anne Owen, Nortel<br>
Barry Briggs, Interleaf<br>
Chris Woodrow, Information Architects<br>
Franklin Reynolds, Nokia<br>
Graham Klyne, Content Technologies Ltd.<br>
Hidetaka Ohto, W3C/Panasonic<br>
Johan Hjelm, W3C/Ericsson. Working Group Chair.<br>
Kynn Bartlett, HTML Writers Guild<br>
Lalitha Suryanarayana, SBC Technology Resources<br>
Mikael Nilsson, Ericsson. Editor.<br>
Noboru IWAYAMA, Fujitsu<br>
Sandeep Singhal, IBM. Chair WAP Forum UAProf DC.<br>
Ted Hardie, Equinix<br>
Ted Wugofski, Gateway2000<br>
Ulrich Kauschke, T-Mobil</p>

<p></p>
<hr>

<h1><a name="Appendix2">Appendix 1</a>: Listing of detailed design
assumptions, design goals, and requirements</h1>

<p>This is a listing of design assumptions, design goals, and requirements
used in our work to derive the requirements in section 4 of the document.</p>

<h2>1. Listing of design assumptions</h2>
<ul>
  <li>CCPP3: P3P is fundamentally limited because it is server-based. This
    limits the namespaces to those the server proposes.</li>
  <li>CCPP-IMPL 1: Follow RDF</li>
  <li>CCPP-IMPL 2: Valid XML (or only well formed?)</li>
  <li>UAPR 6-12: The UAPROF framework shall support internationalization as
    required.</li>
  <li>XHTML-docprof 3.2.16 The design shall support referencing resources
    indirectly. This is also intended in our work; it is also inherent in
  RDF.</li>
  <li>UAPR 6-8: The UAPROF framework shall support an indirect addressing
    scheme based on RFC 1630 for referencing profile information.</li>
  <li>F2F-3: Web-based (URL-based) mechanism for the framework</li>
  <li>F2F-9: Overrides of defaults</li>
  <li>CCPP1: Base: The CC/PP framework, as described in the Note.</li>
  <li>F2F-1: XML-based, RDF-based.</li>
  <li>XHTML-docprof 3.2.3 The design shall support machine readable profiles.
    Suggestion: We make it stronger: The design shall support machine
    understandable profiles. This is a likely requirement for the future.</li>
  <li>XHTML-docprof 3.2.7 The design shall support a human readable
    description of the profile. Well, if RDF can be said to be human
  readable.</li>
  <li>XHTML-docprof 3.2.9 The design shall use XML or RDF. Well, we do.</li>
  <li>XHTML-docprof 3.2.6 The design shall support multiple XML name spaces.
    We do this using RDF, as in the original CC/PP Note[<a
    href="#[CC/PP]">CC/PP</a>].</li>
  <li>F2F-2: Multiple namespaces must be supported, logical operators would be
    a single set only by revving the protocol.</li>
  <li>F2FA-1: An assumption during the work has been that the base is the
    CC/PP framework, as described in the CC/PP Note <a
    href="#[CC/PP]">[CC/PP]</a>. This implies the use of RDF and XML.</li>
  <li>F2FA-2: Receiver-initiated transfer and sender-initiated transfers are
    two protocol families. We need to be able to handle both. It must be
    possible to send profile differences over the same protocol that conveys
    the profile. We assume HTTP but we must make sure not to be bound to
  it.</li>
  <li>F2FA-3: P3P is fundamentally limited because it is server-based. This
    limits the namespaces to those the server proposes.</li>
  <li>F2FA-4: We are not specifying any specific behaviors internal to
    clients, intermediary network elements, or proxies.</li>
  <li>UAPA 4-1: Implicit in the requirements and the architecture is an
    assumption of the existence of a WAP gateway function in the network.</li>
  <li>UAPA 4-2: Synergy of goals and requirements with the CC/PP
  proposal.</li>
  <li>UAPA 4-3: any statement on the security aspects of UAPROF information as
    it is cached in the gateway? (note: UAPA 4-1 and 4-3 are more or less WAP
    specific)</li>
  <li>CONNEG 5.1: The data is transmitted in one transaction (e.g. a mail or
    an HTTP transaction). Metadata and the content negotiation framework may
    be applicable to streaming media, even though it may be too much for the
    framework.</li>
  <li>CONNEG 5.7: Performance may sometimes impact content negotiation.</li>
  <li>CONNEG 6.4: In cases where secure services are used, it should be
    possible to continue to use them.</li>
</ul>

<h2>2 Listing of requirements and design assumptions with bearing on security
concerns</h2>
<ul>
  <li>CONNEG 6.5.1 User agent identification: Disclosure of capability
    information may allow a potential attacker to deduce what message handling
    agent is used, and hence may lead to the exploitation of known security
    weaknesses in that agent. Implicit requirement: this should be
  avoided.</li>
  <li>CONNEG 6.5.2 Macro viruses: Macro viruses are a widespread problem among
    applications such as word processors and spreadsheets. Knowing which
    applications a recipient employs (e.g. by file format) may assist in a
    malicious attack. However, such viruses can be spread easily without such
    knowledge by sending multiple messages, where each message infects a
    specific application version. Implicit requirement: The trust model must
    take this into account.</li>
  <li>CONNEG 6.5.3 Personal vulnerability: One application of content
    negotiation is to enable the delivery of message content that meets
    specific requirements of less able people. Disclosure of this information
    may make such people potential targets for attacks that play on their
    personal vulnerabilities. Implicit requirement: Their privacy must be
    safeguarded.</li>
  <li>CONNEG 6.6 Problems of negotiating security: If feature negotiation is
    used to decide upon security-related features to be used, some special
    problems may be created if the negotiation procedure can be subverted to
    prevent the selection of effective security procedures. Implicit
    requirement: This needs to be addressed. (The security considerations
    section of GSS-API negotiation discusses the use of integrity protecting
    mechanisms with security negotiation).</li>
  <li>CONNEG 6: The following security threats have been identified: Privacy
    violations and denial of service attacks. Negotiation with a mailing list
    server has also been identified as not consistent with good practice. Out
    of scope? Or do W3C recommendations carry the equivalent of a "security
    considerations" section required for IETF specifications?</li>
  <li>CONNEG 4.2.4 A request for capability information, if sent other than in
    response to delivery of a message, should clearly identify the requester,
    the party whose capabilities are being requested, and the time of the
    request. It should include sufficient information to allow the request to
    be authenticated. (Or is this a protocol requirement?)</li>
  <li>OHTO-6.1: The protocol SHOULD support the method of authenticating the
    originator(s) of CC/PP description(s).</li>
  <li>OHTO-6.2: The protocol SHOULD support the method of assuring the
    integrity of CC/PP description.</li>
</ul>

<h2>3. Requirements used in the derivation of high-level requirements</h2>

<h3>3.1 Requirements used for the framework requirements</h3>
<ul>
  <li>FW-1
    <ul>
      <li>UAPG 5-1: The User Agent Profile (UAPROF) framework shall ultimately
        enable delivery of content in a format tailored to the specific device
        characteristics, application settings, operating environment and user
        preferences, while enhancing the speed of content negotiation between
        the client and origin server.</li>
      <li>UAPG 5-2: For this purpose, the UAPROF data model shall adequately
        represent the capabilities of the WAP client device, operating
        environment, user agent settings as well as the user's
      preferences.</li>
    </ul>
  </li>
  <li>FW-2
    <ul>
      <li>XHTML-docprof 3.2.1 The design shall support lightweight testing of
        two profiles for equality. Do we have a way that is generic to RDF of
        doing this? Or is that something we need to introduce?</li>
      <li>CONNEG 4.2.3b Should this be a goal: should it be clear from an
        isolated CCPP profile what entity to which is is applicable?</li>
      <li>XHTML-docprof 3.2.2 The design shall support lightweight testing of
        a clients capabilities and preferences against a documents profile.
        Yes, that is our intention. And the easiest way of doing this is using
        the same mechanisms.</li>
      <li>CCPP-IMPL4: Extensibility for matching rules by creating a specific
        set of operand tags</li>
    </ul>
  </li>
  <li>FW-3
    <ul>
      <li>XHTML-docprof 3.2.14 The design shall support in-place linked
        assertions. This is something we need to look into; if it assumes that
        a subgraph can be expressed in terms of the node that points to it, we
        can do it.</li>
      <li>UAPR 6-5: The UAPROF framework shall support the ability to
        reference capability information stored separately on various systems
        and databases on the Internet and wireless network.</li>
      <li>UAPR 6-5-1: The UAPROF shall be extensible to dynamically compose
        capability information located at several sites in the network.</li>
      <li>CONNEG 4.2.1 A CCPP profile should allow a sender to determine an
        acceptable form of data to send to a client.</li>
      <li>UAPG 5-3: The framework for UAPROF shall provide the ability to
        transmit the information across the wireless network (from the device
        to the WAP gateway) in a flexible, yet efficient and optimum manner
        that minimizes round-trip-delays and network resources consumption in
        terms of bandwidth and number of messages exchanged.</li>
      <li>UAPG 5-3-1: The UAPROF information shall be optimized with the above
        objectives in mind.</li>
      <li>UAPG 5-4: The UAPROF may be changed during the life span of a user's
        interaction with the wireless network and the Internet</li>
      <li>UAPR 6-5-2: UAPROF shall support unification of information provided
        by the device with information located at other sites in the
      network.</li>
    </ul>
  </li>
  <li>FW-4
    <ul>
      <li>CONNEG 4.2.7 Profiles should provide a way to describe both
        capabilities and preferences for specific features</li>
      <li>CONNEG 4.1.4 Permit an indication of quality or preference. (see
        CONNEG 4.2.7 above)</li>
    </ul>
  </li>
</ul>

<h3>3.2 Requirements used to derive the vocabulary and schema
requirements</h3>
<ul>
  <li>VS-1
    <ul>
      <li>XHTML-docprof 3.2.4 The design shall specify document syntax by
        reference to external definitions. The intention of this requirement
        is to say that schemas should be used for definitions (it says in the
        comments), which is something we always intended, too.</li>
      <li>XHTML-docprof 3.2.8 The design shall support reference to
        specifications and documentation defining a document type for the
        profiled documents. It seems more like 3.2.4 than 3.2.7, as the HTML
        WG says. Could it not be covered by those? If so, it is a basic
        assumption of our architecture.</li>
      <li>UAPR 6-14: The UAPROF data model shall adequately represent the
        characteristics specific to a bearer service (such as required for
        ETSI/MExE).</li>
    </ul>
  </li>
  <li>VS-2
    <ul>
      <li>CONNEG 4.1.5 Capture dependencies between feature values. This is
        about constraints: do we want a common way to do this. I think it's
        useful.</li>
      <li>CCPP-IMPL6: Expression of hints as well as absolutes</li>
      <li>F2F-7: Constraints</li>
      <li>F2F-8: Requirements, hints, or both</li>
    </ul>
  </li>
  <li>VS-3
    <ul>
      <li>CONNEG 4.1.1 A common vocabulary for designating features and
        feature sets. This would be a naming framework for client
      features.</li>
      <li>UAPG 5-5: (Design goal or desirable feature?) UAPROF shall include
        vocabularies that are semantically compatible with established
        practices, so as to enable speedy adoption and ease of use for
        developers.</li>
      <li>CONNEG 4.1.2 A stable reference for commonly used features. This
        would be the "core nouns" we discussed.</li>
      <li>UAPR 6-4: An initial set of capabilities that comprise the UAPROF
        shall be defined. Additionally, the UAPROF data model shall be
        extensible to allow for rapid and easy adoption of new features and
        capabilities of the device.</li>
    </ul>
  </li>
  <li>VS-4
    <ul>
      <li>XHTML-docprof 3.2.10 The design shall support a uniform way in which
        to extend profiles.</li>
      <li>CONNEG 4.1.3 An extensible framework, to allow rapid and easy
        adoption of new features. This would be mechanisms for extension.</li>
      <li>CCPP-IMPL5: Extend feature tags by using namespaces</li>
    </ul>
  </li>
</ul>

<h3>3.3 Requirements used in deriving requirements for the trust model</h3>
<ul>
  <li>TF-1
    <ul>
      <li>CONNEG 4.2.9 CCPP should indicate mechanisms to be used to protect
        the privacy of users' profiles.</li>
    </ul>
  </li>
  <li>TF-2
    <ul>
      <li>CONNEG 4.2.10 CCPP should indicate mechanisms to be used to protect
        the accuracy/integrity of users' profiles.</li>
      <li>UAPA 4-3: any statement on the security aspects of UAPROF
        information as it is cached in the gateway?</li>
      <li>CCPP-IMPL3: Trust relationship w/repositories, origin servers, over
        the wire. Encryption?</li>
      <li>F2F-9: Use IOTP (DSIG) for signing documents</li>
    </ul>
  </li>
  <li>TF-3
    <ul>
      <li>F2F2-1: The client must be able to determine whether the profile was
        authenticated by the server (viz, the server needs to be indicate that
        it authenticated the profile).</li>
      <li>F2F2-2: The client must be able to determine that it needs to
        provide authentication information (viz, the server must be able to
        indicate that it requires authentication information with the
      profile)</li>
      <li>F2F2-3: If the client includes authentication information in the
        profile, then the server SHOULD authenticate it and MUST indicate
        whether it did.</li>
      <li>F2F2-4: Maybe the server should similarly indicate whether it used
        the profile supplied, and if not, why not (thus potentially providing
        an indication of authenticated-profile-required)? A server-signed
        response might even usefully include a digest of the profile
      used?</li>
    </ul>
  </li>
</ul>

<h3>3.4 Requirements used in deriving the design goals</h3>
<ul>
  <li>VS-1: Vocabulary items shall be defined in an RDF schema (with the
    implications of XML and RDF implicit in that). They can be externally
    referenced.</li>
  <li>TF3: The digital signature shall be considered a part of the CC/PP.</li>
  <li>FW-2: The design shall support lightweight testing of two profiles for
    equality.</li>
  <li>CONNEG 4.1.9 Be capable of addressing the role of content negotiation in
    fulfilling the communication needs of less able computer users. WAI
    coordination should take care of this.</li>
  <li>CONNEG 5.3: It is clearly helpful to use existing protocols such as LDAP
    to exchange content negotiation metadata. (See CONNEG 4.2.5 in appendix
  2)</li>
  <li>F2FG-3: It shall be possible to extend feature tags by using
  namespaces.</li>
  <li>F2FG-4-1: It shall be possible to express "hints" in the content of to
    present it to the user, based on the CC/PP profile.</li>
  <li>F2FG-4-2: It shall be possible to describe whether it is mandatory or
    optional to enforce an attribute.</li>
  <li>UAPG 5-1: The content negotiation between the client and origin server
    shall take place with a minimum consumption of network resources and
    computational capacity.</li>
  <li>UAPG 5-3-1: The UAPROF information shall be optimized with the above
    objectives in mind.</li>
  <li>UAPG 5-3-2: OTA transmission mechanism shall be optimized as mentioned
    above.</li>
  <li>CONNEG 4.1.5 Capture dependencies between feature values.</li>
  <li>CONNEG 5.2: To allow proxies and caches to participate in the
    negotiation process, as appropriate.</li>
  <li>UAPG 5-5: UAPROF shall include vocabularies that are semantically
    compatible with established practices, so as to enable speedy adoption and
    ease of use for developers.</li>
</ul>

<p>(Note: The CONNEG goals are in an unordered list in the original
document)</p>

<p></p>
<hr>

<h1><a name="Appendix3">Appendix 2: Protocol Requirements</a></h1>

<p>This section describes the requirements the CC/PP working group have been
able to identify that applies to the protocol used to transport the
information and/or perform the negotiation between the client and origin
server. Since the CC/PP framework itself is intended to be independent from
protocols, the protocol which conveys CC/PP information could be based on or
extend a protocol of any kind such as HTTP, SMTP, LDAP etc.</p>

<p>The CC/PP information can be transported in in other messaging formats, for
instance included in an email, sent on a backchannel, or out of band (either
the head or the body) for describing the required capabilities of the
recipient. How to convey content negotiation information in the extended MIME
headers is being worked on the Internet FAX Working Group in the IETF [<a
href="#[FAX-conneg]">FAX-conneg</a>].</p>

<p>The use case that is most likely (given that 80% of all Internet traffic is
HTTP), is the use case where a web user agent sends a request with CC/PP
information, and an origin server or intermediaries creates or selects
tailored content, and includes the tailored content in the response. The use
of HTTP has been a design assumption in the work.</p>

<p>Given this, the protocol requirements are as follows.</p>

<p></p>
<ul>
  <li>P-1: The design shall support inclusion of profile information in a
    request to a server (in request-response protocols); and in the message
    (in message-sending protocols).
    <ul>
      <li>XHTML-docprof 3.2.13 The design shall support including document
        profile information in a request to a server. This is protocol work
        and outside our scope; however, the CC/PP Exchange Protocol
        demonstrates how this could be done using the HTTP Extension
        Framework.</li>
      <li>CONNEG 4.2.2 If capabilities are being sent at times other than the
        time of message transmission, then they should include sufficient
        information to allow them to be verified and authenticated.</li>
      <li>CONNEG 4.2.5 A CCPP profile may be transferred by a number of
        different mechanisms appropriate to the circumstances of its use (or
        does this belong under framework?).</li>
      <li>UAPR 6-2: The format and communication mechanism of the UAPROF
        information shall support and be compatible with existing and emerging
        Internet standards for the desktop environment.</li>
      <li>CONNEG 4.2.6 The negotiation mechanism should include a standardized
        method for associating features with resource variants. Out of scope?
        This reflects in part my (here: GK) view that the same profile
        framework can describe document and client profiles. This conneg usage
        requirement about having a means to identify the features of a
        particular type of data resource.</li>
      <li>OHTO-8.1:The protocol MUST convey CC/PP descriptions originating
        from multiple sources.
        <ul>
          <li>CC/PP descriptions which describes device capabilities would
            originate from multiple sources such as hardware vendors, software
            vendors etc.</li>
        </ul>
        <ul>
          <li>CC/PP descriptions which represent capabilities for one device
            would be provided by multiple sources such as hardware vendors and
            software vendors. Therefore the protocol SHOULD support the
            ability to reference capability information stored separately on
            various systems and databases in the network.</li>
        </ul>
      </li>
      <li>OHTO-8.2: The protocol SHOULD support partial distribution of
        profile information be able to indicate what information is missing so
        that the client can decide what to do.</li>
      <li>UAPG 5-3: The framework for UAPROF shall provide the ability to
        transmit the information across the wireless network (from the device
        to the WAP gateway) in a flexible, yet efficient and optimum manner
        that minimizes round-trip-delays and network resources consumption in
        terms of bandwidth and number of messages exchanged.</li>
    </ul>
  </li>
</ul>

<p></p>
<ul>
  <li>P-2: Matching of profiles and/or content negotiation shall have as
    little impact as possible in terms of network resources, especially
    protocol round trips.
    <ul>
      <li>CONNEG 4.2.8 Negotiation should have the minimum possible impact on
        network resource consumption, particularly in terms of bandwidth and
        number of protocol round trips required. Out of scope?</li>
      <li>F2F-6: Minimum number of roundtrips for profile matching (none is
        best)</li>
      <li>OTHO-5.1: The protocol SHOULD support the way of minimizing the
        amount of CC/PP information conveyed with a request.</li>
      <li>OHTO-5.2: CC/PP descriptions would be verbose. Therefore conveying
        CC/PP descriptions with a request would be a moderately expensive way
        in some networks such as wireless networks.</li>
      <li>OHTO-5.3: There are several optimization possibilities(those might
        not be mutual exclusive) such as :
        <ul>
          <li>compress CC/PP description(s) when it is conveyed.</li>
          <li>send reference(s)(URI) which represents CC/PP descriptions
            instead of sending CC/PP descriptions themselves.</li>
          <li>send only the changes when propagating changes to the current
            CC/PP description(s) to an origin server, a gateway or a
          proxy.</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>
<ul>
  <li>P-3: The protocol must work in the presence of gateways or proxies,
    including enabling intermediate network elements to interact with the
    profile and content.
    <ul>
      <li>F2F-5: Must work in the presence of gateways and proxies. Web is
        receiver initiated.</li>
      <li>CONNEG 4.2.12 Intelligent gateways, proxies, or caches should be
        allowed to participate in the negotiation.</li>
      <li>CONNEG 4.2.13 CCPP data should be regarded as cacheable. It may be
        desirable to indicate cache control directives to forestall the
        introduction of ad-hoc cache-busting techniques</li>
      <li>CONNEG 5.2: To allow proxies and caches to participate in the
        negotiation process, as appropriate.</li>
      <li>OHTO-4.1: The protocol SHOULD allow intermediaries to participate in
        the content negotiation.</li>
      <li>OHTO-4.2: It is quite conceivable that intermediate network elements
        such as gateways or proxies take participate in the content
        negotiation(content generation, content transformation and content
        variant selection). For example, a transcoding proxy transcodes a
        content received based on its abilities, and forwards the resulting
        customized content to the device for rendering. Such kind of gateways,
        proxies, or caches should be allowed to participate in the content
        negotiation.</li>
      <li>OHTO-4.3: The protocol SHOULD support asserting capabilities by
        intermediate network elements. When a request for a content is made by
        a user agent to an origin server, a CC/PP profile describing the
        capabilities and preferences is transmitted along with the request. It
        is quite conceivable that intermediaries such as gateways and
        transcoding proxies that have additional capabilities might be able to
        translate or adapt the content before rendering it to the device. Such
        capabilities are not known to the user agents and therefore cannot be
        included in the original profile. However, these capabilities would
        need to be conveyed to the origin server or proxy serving/ generating
        the content. Therefore the protocol MUST support the ability for such
        proxies and gateways to assert their capabilities.</li>
      <li>OHTO-4.4: The protocol SHOULD support overriding capabilities by
        intermediate network elements.</li>
      <li>OHTO-4.5: In some instances, the profile information provided by the
        requesting client device may need to be overridden.</li>
      <li>OHTO-4.6: The protocol SHOULD maintain the original CC/PP profiles
        intact up to the point where content selection/generation is performed
        (by origin or proxy). Any overrides are described by a combining form,
        somewhat like the 'default' combining form, that forces values in the
        original profile to be disregarded. This approach maintains end-to-end
        security for the client's profile.</li>
    </ul>
  </li>
</ul>
<ul>
  <li>P-4: The profile shall work independently of the protocol type. However,
    any protocols which enable extended content negotiation using CC/PP shall
    support the ability dynamically modify and update any changes to the
    profile information during the scope of a session or transaction.
    <ul>
      <li>CCPP2: Receiver-initiated transfer and sender-initiated transfers
        are two protocol families. We need to be able to handle both. Send
        diffs over protocol. We assume HTTP but we must make sure not to be
        bound to it. It's pretty obvious what we have to steal.</li>
      <li>CONNEG 4.1.7 Efficient negotiation should be possible in both
        receiver initiated ('pull') and sender initiated ('push') message
        transfers. I.e. allow for fax/email/etc as well as web access.</li>
      <li>CONNEG 4.1.8 The structure of the negotiation procedure framework
        should stand independently of any particular message transfer
        protocol. (See CONNEG 4.2.5 above).</li>
      <li>UAPR 6-7: The UAPROF framework shall support the ability to
        dynamically modify and update any changes to the UAPROF capabilities/
        preferences during the scope of a single request or during the
        life-span a WSP session.</li>
      <li>UAPR 6-13: It shall be possible for a WAP client to embed in the
        request, UAPROF information (granularity = attribute) which can be
        used instead of the cached information available at the WAP gateway
        (i.e. overwrite the existing information temporarily). This
        information embedded in the request shall not be cached at the
        gateway.</li>
      <li>UAPG 5-3-2: OTA transmission mechanism shall be optimized as
        mentioned above.</li>
      <li>F2F-4: Sender-initiated and receiver-initiated protocols</li>
      <li>CONNEG 4.2.3a A capability assertion should clearly identify the
        party to whom the capabilities apply, the party to whom they are being
        sent, and some indication of their date/time or range of validity. To
        be secure, capability assertions should be protected against
        interception and substitution of valid data by invalid data.</li>
    </ul>
  </li>
</ul>

<p>Assuming a protocol based on HTTP 1.1, the following applies:</p>
<ul>
  <li>The protocol SHOULD be HTTP/1.1 compatible.</li>
  <li>For the purpose of taking advantage of the technologies such as cache
    controls, and making use of the existing web server infrastructures, the
    protocol should be HTTP/1.1 compatible.</li>
  <li>The protocol SHOULD support caching mechanisms for both of CC/PP
    descriptions and tailored contents.</li>
  <li>Caching is very important for performance improvement. HTTP/1.1 cache
    control mechanisms would be used for the purpose of it.</li>
</ul>

<p></p>
<hr>

<p><a href="http://validator.w3.org/"><img border="0"
src="http://validator.w3.org/images/vh40.gif" alt="Valid HTML 4.0!"
height="31" width="88"></a> <a href="http://www.w3.org/Style/CSS/Buttons/">
<img alt="Made with CSS" border="0" width="88" height="31"
src="http://www.w3.org/Style/CSS/Buttons/mwcos"></a></p>
</body>
</html>