discontinued / server · Files

index.html 102 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 
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Guidelines for Web Content Transformation Proxies 1.0</title>
    <style type="text/css">
      code           { font-family: monospace; }

      div.constraint,
      div.issue,
      div.note,
      div.notice     { margin-left: 2em; }

      ol.enumar      { list-style-type: decimal; }
      ol.enumla      { list-style-type: lower-alpha; }
      ol.enumlr      { list-style-type: lower-roman; }
      ol.enumua      { list-style-type: upper-alpha; }
      ol.enumur      { list-style-type: upper-roman; }


      div.exampleInner pre { margin-left: 1em;
      margin-top: 0em; margin-bottom: 0em}
      div.exampleOuter {border: 4px double gray;
      margin: 0em; padding: 0em}
      div.exampleInner { background-color: #d5dee3;
      border-top-width: 4px;
      border-top-style: double;
      border-top-color: #d3d3d3;
      border-bottom-width: 4px;
      border-bottom-style: double;
      border-bottom-color: #d3d3d3;
      padding: 4px; margin: 0em }
      div.exampleWrapper { margin: 4px }
      div.exampleHeader { font-weight: bold;
      margin: 4px}

      .new
      {
      background-color: #FFFF80;
      color: inherit;
      }

      .requirement
      {
      background-color: #DDDD80;
      color: inherit;
      border: 1px black solid;
      padding: 0.5em;
      }

      .requirement:before
      {
      content: "Requirement: ";
      font-weight: bold;
      }

      .image
      {
      text-align: center;
      }

      .flow1
      {
      font-family: monospace;
      font-size:smaller
      }

      .flow2
      {
      margin-left: 2em;
      font-family: monospace;
      font-size:smaller
      }

      .flow3
      {
      margin-left: 4em;
      font-family: monospace;
      font-size:smaller
      }

      pre
      {
      border:none;
    }</style>
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
  </head>
  <body>
    <div class="head">
      <p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"/></a></p>
      <h1><a name="title" id="title"></a>Guidelines for Web Content Transformation Proxies 1.0</h1>
      
      <h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 26 October 2010</h2>

      <dl>
        <dt>This version:</dt>
        <dd>
          <a href="http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/">http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/</a>
        </dd>
        <dt>Latest version:</dt>
        <dd>
          <a href="http://www.w3.org/TR/ct-guidelines/">http://www.w3.org/TR/ct-guidelines/</a>
        </dd>
        <dt>Previous version:</dt>
        <dd>
          <a href="http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/">http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/</a>
        </dd>
        <dt>Editor:</dt>
        <dd>Jo Rabin, Invited Expert (and before at mTLD Top Level Domain, dotMobi)</dd>
      </dl>
      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></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> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
      </p>
    </div>
    <hr />
    <div>
      
      <h2><a name="abstract" id="abstract"></a>Abstract</h2>
      <p>This document provides guidance to Content Transformation proxies as to whether and how to transform Web content.</p>
      <p>Content Transformation proxies alter requests sent by user agents to
      servers and responses returned by servers so that the appearance,
      structure or control flow of Web
      applications are modified. Content Transformation proxies are mostly
      used to convert Web sites designed for desktop computers to a form
      suitable for mobile
      devices.
      </p>
      <p>Based on current practice and standards, this document specifies
      mechanisms with which Content Transformation proxies should make their
      presence known to other parties, present the outcome of alterations
      performed on HTTP traffic, and react to indications set by clients or
      servers to constrain these alterations.
      </p>
      <p>The objective is to reduce undesirable effects on Web applications,
      especially mobile-ready ones, and to limit the diversity in the modes of
      operation of Content Transformation proxies, while at the same time
      allowing proxies to alter content that would otherwise not display
      successfully on mobile devices. 
      </p>
      <p>Important considerations regarding the impact on security are highlighted.</p>
    </div>
    <div>
      <h2><a name="status" id="status"></a>Status of this Document</h2>      

      <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

      <p>This document was developed by the <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> as part of the <a href="http://www.w3.org/Mobile/">Mobile Web Initiative</a>.</p>

      <p>This document was expected to become a W3C Recommendation and was published as a W3C Candidate Recommendation on <a href="http://www.w3.org/TR/2010/CR-ct-guidelines-20100617/" title="Candidate Recommendation of the Guidelines for Web Content Transformation Proxies published on 17 June 2010">17 June 2010</a>. As of October 2010, the Mobile Web Best Practices Working Group acknowledges the lack of existing implementations. Nevertheless, it also believes that the guidelines establish a framework acceptable by all parties involved.</p>

      <p>The Mobile Web Best Practices Working Group eventually resolved to discontinue the work on this document and to publish it as a <strong>Working Group Note</strong>. The Working Group hopes that this Note may serve as a basis for discussion and negotiation among players.</p>

      <p>Other than changes to this section, the document has not changed since its publication as a W3C Candidate Recommendation. In particular, the use of normative language has been kept as-is.</p>

      <p>Comments on this document may be sent to the Working Group's public email list <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> (with <a href="http://lists.w3.org/Archives/Public/public-bpwg-comments/">public archive</a>).</p>

      <p>The public <a href="mailto:public-content-transformation-conformance@w3.org">public-content-transformation-conformance@w3.org</a> mailing-list (with <a href="http://lists.w3.org/Archives/Public/public-content-transformation-conformance/" title="Public archive for the public-content-transformation-conformance mailing-list">public archive</a>) that had been created to gather implementation feedback may still be used for that purpose. The Working Group also invites people willing to contribute to the <a href="http://dev.w3.org/2010/ct-guidelines/test-suite/">test case repository</a> to let themselves known on the <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> public mailing-list, noting however that no further work is anticipated on that topic within the group as of October 2010. Please check the <a href="http://dev.w3.org/2010/ct-guidelines/test-suite/">test case repository</a> for up-to-date information.</p>

      <p>Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>

      <p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/37584/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>

    </div>
    <div class="toc">
      
      <h2><a name="contents" id="contents"></a>Table of Contents</h2>
      <p class="toc">1 <a href="#sec-introduction">Introduction (Non-Normative)</a><br />
          1.1 <a href="#sec-purpose">Purpose</a><br />
          1.2 <a href="#sec-audience">Audience</a><br />
          1.3 <a href="#sec-scope">Scope</a><br />
          1.4 <a href="#sec-principles">Principles</a><br />
              1.4.1 <a href="#sec-iab-considerations">IAB Considerations</a><br />
              1.4.2 <a href="#sec-priority-of-intention">Priority of Intention</a><br />
      2 <a href="#sec-terminology">Terminology (Normative)</a><br />
          2.1 <a href="#sec-types-of-proxy">Types of Proxy</a><br />
          2.2 <a href="#sec-types-of-transformation">Types of Transformation</a><br />
          2.3 <a href="#sec-informing-the-user">User Interaction</a><br />
      3 <a href="#sec-conformance">Conformance (Normative)</a><br />
          3.1 <a href="#sec-classes-of-product">Classes of Product</a><br />
          3.2 <a href="#sec-normative-and-informative-parts">Normative and Informative Parts</a><br />
          3.3 <a href="#sec-rfc2119">Normative Language for Conformance Requirements</a><br />
          3.4 <a href="#sec-transformation-deployment-conformance">Transformation Deployment Conformance</a><br />
      4 <a href="#sec-Components">Behavior of Components (Normative)</a><br />
          4.1 <a href="#sec-ProxyReqest">Proxy Forwarding of Request</a><br />
              4.1.1 <a href="#sec-applicable-HTTP-methods">Applicable HTTP Methods</a><br />
              4.1.2 <a href="#sec-request-no-transform">no-transform directive in Request</a><br />
              4.1.3 <a href="#sec-non-web-browsers">Treatment of Requesters that are not Web browsers</a><br />
              4.1.4 <a href="#sec-serving-cached-responses">Serving Cached Responses</a><br />
              4.1.5 <a href="#sec-altering-header-values">Alteration of HTTP Header Field Values</a><br />
                  4.1.5.1 <a href="#sec-content-tasting">Content Tasting</a><br />
                  4.1.5.2 <a href="#sec-avoiding-request-unacceptable">Avoiding "Request Unacceptable" Responses</a><br />
                  4.1.5.3 <a href="#sec-user-selection">User Selection of Restructured Experience</a><br />
                  4.1.5.4 <a href="#sec-sequence-of-requests">Sequence of Requests</a><br />
                  4.1.5.5 <a href="#sec-original-headers">Original Header Fields</a><br />
              4.1.6 <a href="#sec-additional-headers">Additional HTTP Header Fields</a><br />
                  4.1.6.1 <a href="#sec-via-headers">Proxy Treatment of Via Header Field</a><br />
          4.2 <a href="#sec-Proxy-Response">Proxy Forwarding of Response to User Agent</a><br />
              4.2.1 <a href="#sec-administrative-arrangements">User Preferences</a><br />
              4.2.2 <a href="#sec-receipt-of-cache-control-no-transform">Receipt of Cache-Control: no-transform</a><br />
              4.2.3 <a href="#sec-proxy-use-of-no-transform">Use of Cache-Control: no-transform</a><br />
              4.2.4 <a href="#sec-unacceptable-response">Server Rejection of HTTP Request</a><br />
              4.2.5 <a href="#sec-receipt-of-vary-header">Receipt of Vary HTTP Header Field</a><br />
              4.2.6 <a href="#sec-receipt-of-link-to-handheld">Link to "handheld" Representation</a><br />
              4.2.7 <a href="#sec-WML-content">WML Content</a><br />
              4.2.8 <a href="#sec-proxy-decision-to-transform">Proxy Decision to Transform</a><br />
                  4.2.8.1 <a href="#sec-alteration-of-response">Alteration of Response</a><br />
                  4.2.8.2 <a href="#sec-link-rewriting">Link Rewriting</a><br />
                  4.2.8.3 <a href="#sec-https-link-rewriting">HTTPS Link Rewriting</a><br />
      5 <a href="#sec-testing">Testing (Normative)</a><br />
      
      </p>
      
      <h3><a name="appendices" id="appendices"></a>Appendices
      </h3>
      <p class="toc">A <a href="#sec-references">References</a><br />
      B <a href="#sec-ConformanceStatement">Conformance Statement</a><br />
      C <a href="#sec-Mobile-Content-Types">Internet Content Types associated with Mobile Content</a><br />
      D <a href="#sec-Data-Content-Types">Internet Content Types associated with Data Content</a><br />
      E <a href="#sec-Mobile-DOCTYPES">DOCTYPEs Associated with Mobile Content</a><br />
      F <a href="#sec-Mobile-URI-Patterns">URI Patterns Associated with Mobile Web Sites</a><br />
      G <a href="#sec-Summary-User-Preference-Handling">Summary of User Preference Handling</a><br />
      H <a href="#sec-example-transformation-interactions">Example Transformation Interactions</a> (Non-Normative)<br />
          H.1 <a href="#sec-basic-content-tasting">Basic Content Tasting by Proxy</a><br />
          H.2 <a href="#sec-proxy-a-priori-knowledge">Optimization based on Previous Server Interaction</a><br />
          H.3 <a href="#sec-optimization-previous-interaction">Optimization based on Previous Server Interaction, Server has Changed its
      Operation</a><br />
          H.4 <a href="#sec-representation-intended">Server Response Indicating that this Representation is Intended for the Target
      Device</a><br />
          H.5 <a href="#sec-another-representation">Server Response Indicating that another Representation is Intended for the
      Target Device</a><br />
      I <a href="#sec-guidance-origin-servers">Informative Guidance for Origin Servers</a> (Non-Normative)<br />
          I.1 <a href="#sec-ServerResponse">Server Response to Proxy</a><br />
              I.1.1 <a href="#sec-server-use-of-406">Use of HTTP 406 Status</a><br />
              I.1.2 <a href="#sec-server-use-of-403">Use of HTTP 403 Status</a><br />
              I.1.3 <a href="#sec-cache-control-no-transform">Server Origination of Cache-Control: no-transform</a><br />
              I.1.4 <a href="#sec-varying-representations">Varying Representations</a><br />
                  I.1.4.1 <a href="#sec-use-of-vary-header">Use of Vary HTTP Header Field</a><br />
                  I.1.4.2 <a href="#sec-use-of-link-element">Indication of Intended Presentation Media Type of Representation</a><br />
      J <a href="#sec-applicability">Applicability to Transforming Solutions which are Out of Scope</a> (Non-Normative)<br />
      K <a href="#sec-scope-for-future-work">Scope for Future Work</a> (Non-Normative)<br />
          K.1 <a href="#sec-powder">POWDER</a><br />
          K.2 <a href="#sec-link-http-header">link HTTP Header Field</a><br />
          K.3 <a href="#sec-sources-devinfo">Sources of Device Information</a><br />
          K.4 <a href="#sec-inter-proxy-comm">Inter Proxy Communication</a><br />
          K.5 <a href="#sec-explicit-consent">Explicit Consent</a><br />
          K.6 <a href="#sec-amendment-http">Amendment to and Refinement of HTTP</a><br />
      L <a href="#sec-acknowledgements">Acknowledgments</a> (Non-Normative)<br />
      
      </p>
    </div>
    <hr />
    <div class="body">
      <div class="div1">
        
        <h2><a name="sec-introduction" id="sec-introduction"></a>1 Introduction (Non-Normative)</h2>
        <div class="div2">
          
          <h3><a name="sec-purpose" id="sec-purpose"></a>1.1 Purpose
          </h3>
          <p>Within this document <em>Content Transformation</em> refers to the
          manipulation of requests to, and responses from, an origin server.
          This manipulation is carried out by proxies in order to provide a
          better user experience of content that would otherwise result in an
          unsatisfactory experience on the device making the request.
          </p>
          <p>The W3C Mobile Web Best Practices Working Group neither approves nor disapproves of Content Transformation, but
          recognizes that is being deployed widely across mobile data access networks. The
          deployments are widely divergent to each other, with many non-standard HTTP
          implications, and no well-understood means either of identifying the presence of
          such transforming proxies, nor of controlling their actions. This document
          establishes a framework to allow that to happen.
          </p>
          <p>The overall objective of this document is to provide a means, as far as is
          practical, for users to be provided with at least a <a href="http://www.w3.org/TR/di-gloss/#def-functional-user-experience"
          >"functional user experience"</a>
          <a href="#ref-DIGLOSS">[Device Independence Glossary]</a> of the Web, when mobile, taking into account the
          fact that an increasing number of content providers create experiences specially
          tailored to the mobile context which they do not wish to be altered by third
          parties. Equally it takes into account the fact that there remain a very large
          number of Web sites that do not provide a <em>functional user
          experience</em> when perceived on many mobile devices.
          </p>
          <p>It is stressed that this document is unlikely to be the last word on this topic. As noted below (<a href="#sec-scope"><span class="specref">1.3 Scope</span></a>) it is out of scope of this document to provide a comprehensive solution to control of transforming proxies, though such
          a solution would appear to be needed. The document is an attempt to improve a situation at a point in time where there appears
          to be disregard of the provisions of HTTP - and is primarily a reminder and an encouragement to follow those provisions more
          closely.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-audience" id="sec-audience"></a>1.2 Audience
          </h3>
          <p>The audience for this document is creators of Content Transformation proxies and
          purchasers and operators of such proxies.  The document also contains non-normative guidance for content providers whose services
          may be accessed by means of such proxies.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-scope" id="sec-scope"></a>1.3 Scope
          </h3>
          <p>The recommendations in this document refer only to "Web browsing" - i.e. access
          by user agents that are intended primarily for interaction by users with HTML
          Web pages (Web browsers) using HTTP. Clients that interact with proxies using
          mechanisms other than HTTP (and that typically involve the download of a special
          client) are out of scope, and are considered to be a distributed user agent.
          Proxies which are operated in the control of or under the direction of the
          operator of an origin server are similarly considered to be a distributed origin
          server and hence out of scope.
          </p>
          <p>The W3C <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> (BPWG) is not chartered to create new technology - its role is to advise on
          best practice for use of existing technology. In satisfying Content
          Transformation requirements, existing HTTP header fields, directives and behaviors
          must be respected, and as far as is practical, no extensions to <a href="#ref-HTTP">[RFC 2616 HTTP]</a> are to be used.
          </p>
          <p>The recommendations in this document refer to interactions of a proxy and do not refer to any presumed aspects of the internal
          operation of the proxy. For this reason, the document does not discuss use of "allow" and "disallow" lists (though it does
          discuss behavior that is induced by the implementation of such lists). In addition it does not discuss details of how transformation
          is carried out except if this is reflected in interoperability. For this reason, it does not discuss the insertion or insertion
          of headers and footers or any other specific behaviors (though it does discuss the need for essential user interaction of
          some form). 
          </p>
          <p>Moral, legal and other similar questions are not in scope of this document. The BPWG does not have authority or expertise
          to comment one way or another about setting precedent or authorising any particular behavior or its absence.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-principles" id="sec-principles"></a>1.4 Principles
          </h3>
          <div class="div3">
            
            <h4><a name="sec-iab-considerations" id="sec-iab-considerations"></a>1.4.1 IAB Considerations
            </h4>
            <p>The BPWG made reference to Internet Architecture Board (IAB) work on "Open Pluggable Edge Services" <a href="#ref-OPES">[RFC 3238 OPES]</a> for various 
            principles that underlie behavior of proxies. In this work the IAB expressed its 
            concerns about privacy, 
            control, monitoring, and accountability of such services.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-priority-of-intention" id="sec-priority-of-intention"></a>1.4.2 Priority of Intention
            </h4>
            <p>The Web allows users considerable flexibility in respect of the representation of content. At the same time, Content Providers
            may have a preferred manner in which they wish their content to be represented. Content Transformation must reconcile these
            contrasting factors. In creating this Recommendation the BPWG has determined that Content Transformation proxies should respect
            Content Providers intentions, where they are expressed, but may allow users to choose other representations, except where
            Content Providers specifically prohibit this.
            </p>
            <p>The BPWG recognizes that there is neither a systematic vocabulary for Content Provider Intentions, nor a systematic means
            of expression of such intentions. There is scope for further work in this area (see <a href="#sec-scope-for-future-work"><span class="specref">K Scope for Future Work</span></a>). 
            </p>
          </div>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-terminology" id="sec-terminology"></a>2 Terminology (Normative)</h2>
        <div class="div2">
          
          <h3><a name="sec-types-of-proxy" id="sec-types-of-proxy"></a>2.1 Types of Proxy
          </h3>
          <p>Alteration of HTTP requests and responses is not prohibited by HTTP other than in
          the circumstances referred to in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
          <a href="http://tools.ietf.org/html/rfc2616#section-13.5.2">Section 13.5.2</a> and <a href="http://tools.ietf.org/html/rfc2616#section-14.9.5">Section 14.9.5</a>. 
          </p>
          <p>HTTP defines two types of proxy: transparent proxies and non-transparent proxies.
          As discussed in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
          <a href="http://tools.ietf.org/html/rfc2616#section-1.3">Section 1.3, Terminology</a>:
          </p>
          <p>
            <a name="term-transparent" id="term-transparent" title="transparent proxy"
               ></a>"A <b>transparent
            proxy</b> is a proxy that does not modify the request or response
            beyond what is required for proxy authentication and identification.
            <a name="term-non-transparent" id="term-non-transparent"
               title="non-transparent proxy"
               ></a>A
            <b>non-transparent proxy</b> is a proxy that modifies the request
            or response in order to provide some added service to the user agent, such
            as group annotation services, media type transformation, protocol reduction,
            or anonymity filtering. Except where either transparent or
            non-transparent behavior is explicitly stated, the HTTP proxy requirements apply
            to both types of proxies." 
          </p>
          <p>This document elaborates the behavior of non-transparent proxies, when used for
          Content Transformation in the context discussed in <a href="#ref-CT-Landscape">[CT Landscape]</a>.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-types-of-transformation" id="sec-types-of-transformation"
                 ></a>2.2 Types of Transformation
          </h3>
          <p>Transforming proxies can carry out a wide variety of operations. In this document
          we categorize these operations as follows (noting that these are general concepts that we do not formalize further): 
          </p>
          <ol class="enumar">
            <li>
              <p>Alteration of Requests</p>
              <p>Transforming proxies process requests in a number of ways, especially
              replacement of various request header fields to avoid HTTP 406 Status
              responses (if a server can not provide content that is compatible with
              the original HTTP request header fields) and at user request.
              </p>
            </li>
            <li>
              <p>Alteration of Responses</p>
              <p>There are three classes of operation on responses:</p>
              <ol class="enumla">
                <li>
                  <p>Restructuring content </p>
                  <p>
                    <a name="term-restructuring" id="term-restructuring" title="restructuring"
                       ></a><b>Restructuring</b> content is a process whereby
                    the original layout is altered so that content is added or
                    removed or where the spatial or navigational relationship of
                    parts of content is altered, e.g. linearization 
                    (i.e. reordering presentation elements, especially tables, 
                    so that they fit on a narrow display and can be traversed 
                    without horizontal scrolling) or pagination 
                    (i.e. splitting a document too large to be stored 
                    in or transmitted to the terminal in one piece, 
                    so that it can be nevertheless accessed by browsing 
                    through a succession of smaller interlinked documents). 
                    It also includes rewriting URIs so that subsequent 
                    requests are routed via the proxy handling the response.
                    
                    
                  </p>
                </li>
                <li>
                  <p>Recoding content</p>
                  <p>
                    <a name="term-recoding" id="term-recoding" title="recoding"></a><b>Recoding</b> content is a process whereby the
                    layout of the content remains the same, but details of its
                    encoding may be altered. Examples include re-encoding HTML
                    as XHTML, correcting invalid markup in HTML, conversion of
                    images between formats (but not, for example, reducing
                    animations to static images). 
                    
                  </p>
                </li>
                <li>
                  <p>Optimizing content</p>
                  <p>
                    <a name="term-optimizing" id="term-optimizing" title="optimizing"></a><b>Optimizing</b> content includes removing redundant
                    white space, re-compressing images (without loss of
                    fidelity) and compressing for transfer.
                    
                  </p>
                </li>
              </ol>
            </li>
          </ol>
        </div>
        <div class="div2">
          
          <h3><a name="sec-informing-the-user" id="sec-informing-the-user"></a>2.3 User Interaction
          </h3>
          <p>At various points in this document there is reference to "notifying the user", "informing the user" - in general making the
          user aware that a situation exists or interacting with the user to solicit a choice of options. The expectation is that such
          user interaction is conducted in a way that allows the user to perceive and interact with such information or choices in the
          same way as they interact with the Web sites that they are visiting.
          </p>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-conformance" id="sec-conformance"></a>3 Conformance (Normative)</h2>
        <div class="div2">
          
          <h3><a name="sec-classes-of-product" id="sec-classes-of-product"></a>3.1 Classes of Product
          </h3>
          <p>The Content Transformation Guidelines specification has one class of products:</p>
          <dl>
            <dt class="label">Transformation Deployment</dt>
            <dd>
              <p>A Transformation Deployment is the provision of <a title="non-transparent proxy" href="#term-non-transparent">non-transparent</a> components
              in the path of HTTP requests and responses. Provisions that are
              applicable to a Transformation Deployment are identified in this
              document by use of the term "transforming proxy" or "proxy" in the
              singular or plural.
              </p>
            </dd>
          </dl>
        </div>
        <div class="div2">
          
          <h3><a name="sec-normative-and-informative-parts"
                 id="sec-normative-and-informative-parts"
                 ></a>3.2 Normative and Informative Parts
          </h3>
          <p>Normative parts of this document are identified by the use of "(Normative)"
          following the section name. Informative parts are identified by use of
          "(Non-Normative)" following the section name.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-rfc2119" id="sec-rfc2119"></a>3.3 Normative Language for Conformance Requirements
          </h3>
          <p>The key words <strong>must</strong>, <strong>must not</strong>,
          <strong>required</strong>, <strong>shall</strong>, <strong>shall
          not</strong>, <strong>should</strong>, <strong>should not</strong>,
          <strong>recommended</strong>, <strong>not recommended</strong>, <strong>may</strong>, and
          <strong>optional</strong> in this Recommendation have the meaning defined
          in <a href="#ref-rfc-2119">[RFC 2119]</a>.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-transformation-deployment-conformance"
                 id="sec-transformation-deployment-conformance"></a>3.4 Transformation Deployment Conformance
          </h3>
          <p>A Transformation Deployment conforms to these guidelines if it follows the
          statements in <a href="#sec-transformation-deployment-conformance"><span class="specref">3.4 Transformation Deployment Conformance</span></a>, <a href="#sec-ProxyReqest"><span class="specref">4.1 Proxy Forwarding of Request</span></a>, <a href="#sec-Proxy-Response"><span class="specref">4.2 Proxy Forwarding of Response to User Agent</span></a> and <a href="#sec-testing"><span class="specref">5 Testing (Normative)</span></a>.
          </p>
          <p>A Transformation Deployment that wishes to claim conformance <strong>must</strong> make available a conformance statement <a href="#sec-ConformanceStatement"><span class="specref">B Conformance Statement</span></a> that specifies the reasons for non-compliance with any clauses containing the key words "<strong>should</strong>" and "<strong>should not</strong>", "<strong>recommended</strong>" and "<strong>not recommended</strong>". 
          </p>
          <p>Conformance statements <strong>must</strong> be sent to <a href="mailto:public-content-transformation-conformance@w3.org">public-content-transformation-conformance@w3.org</a>. Public archive of this list may be found at <a href="http://lists.w3.org/Archives/Public/public-content-transformation-conformance/">http://lists.w3.org/Archives/Public/public-content-transformation-conformance/</a>.
          </p>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Components" id="sec-Components"></a>4 Behavior of Components (Normative)</h2>
        <div class="div2">
          
          <h3><a name="sec-ProxyReqest" id="sec-ProxyReqest"></a>4.1 Proxy Forwarding of Request
          </h3>
          <div class="div3">
            
            <h4><a name="sec-applicable-HTTP-methods" id="sec-applicable-HTTP-methods"
                   ></a>4.1.1 Applicable HTTP Methods
            </h4>
            <p>User agents sometimes issue HTTP HEAD requests in order to determine if a
            resource is of a type and/or size that they are capable of handling. A
            transforming proxy <strong>may</strong> convert a HEAD request into a GET
            request (in order to determine the characteristics of a transformed response
            that it would return if the user agent subsequently issued a GET request for
            the same resource).
            </p>
            <p>If the HTTP method is altered from HEAD to GET, proxies
            <strong id="ta-49078">should</strong> (providing such action is in accordance with
            normal HTTP caching rules) cache the response so that a second GET request
            for the same content is not required (see also <a href="#sec-serving-cached-responses"><span class="specref">4.1.4 Serving Cached Responses</span></a>).
            </p>
            <p>Other than to convert between HEAD and GET proxies <strong id="ta-59418">must not</strong> alter request methods.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-request-no-transform" id="sec-request-no-transform"></a>4.1.2 <code>no-transform</code> directive in Request
            </h4>
            <p>If the request contains a <code>Cache-Control: no-transform</code> directive, proxies <strong id="ta-41855">must not</strong> alter the request other than to comply with <a title="transparent proxy" href="#term-transparent">transparent</a> HTTP behavior defined in <a href="#ref-HTTP">[RFC 2616 HTTP]</a> sections <a href="http://tools.ietf.org/html/rfc2616.html#section-14.9.5">section 14.9.5</a> and <a href="http://tools.ietf.org/html/rfc2616.html#section-13.5.2">section 13.5.2</a> and to add header fields as described in <a href="#sec-additional-headers"><span class="specref">4.1.6 Additional HTTP Header Fields</span></a> below.
            </p>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p>An example of the use of <code>Cache-Control: no-transform</code> is the
              issuing of asynchronous HTTP requests, perhaps by means of
              XMLHttpRequest <a href="#ref-XHR">[XHR]</a>, which may include such a
              directive in order to prevent transformation of both the request and the
              response.
              </p>
            </div>
          </div>
          <div class="div3">
            
            <h4><a name="sec-non-web-browsers" id="sec-non-web-browsers"></a>4.1.3 Treatment of Requesters that are not Web browsers
            </h4>
            <p>Before altering aspects of HTTP requests and responses proxies need to take account of the fact that HTTP is used as a transport
            mechanism for many applications other than "Traditional Browsing". Increasingly browser based applications involve exchanges
            of data using XMLHttpRequest (see <a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a>) and alteration of such exchanges is likely to cause misoperation.
            
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-serving-cached-responses" id="sec-serving-cached-responses"
                   ></a>4.1.4 Serving Cached Responses
            </h4>
            <p>Aside from the usual caching procedures defined in <a href="#ref-HTTP">[RFC 2616 HTTP]</a>, in some circumstances, proxies <strong>may</strong> paginate responses and
            where this is the case a request may be for a subsequent page of a
            previously requested resource. In this case proxies <strong>may</strong>
            for the sake of consistency of representation serve stale data but when
            doing so <strong id="ta-17538">should</strong> notify the user that this is the case and
            <strong id="ta-19789">must</strong> provide a simple means of retrieving a fresh
            copy.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-altering-header-values" id="sec-altering-header-values"></a>4.1.5 Alteration of HTTP Header Field Values
            </h4>
            <p>Other than the modifications required by <a href="#ref-HTTP">[RFC 2616 HTTP]</a> proxies <strong id="ta-19234">should not</strong> modify the values of header fields other than 
            the <code>User-Agent</code>, <code>Accept</code>, <code>Accept-Charset</code>, <code>Accept-Encoding</code>, and <code>Accept-Language</code> header fields 
            and <strong id="ta-13875">must not</strong> delete header fields  (see <a href="#sec-original-headers"><span class="specref">4.1.5.5 Original Header Fields</span></a>). 
            
            </p>
            <p>Other than to comply with <a title="transparent proxy" href="#term-transparent">transparent</a> HTTP operation, proxies <strong id="ta-5564">should not</strong> modify <em>any</em> request header fields unless one of the following applies: 
            </p>
            <ol class="enumar">
              <li>
                <p>the user would be prohibited from accessing content as a result of
                the server responding that the request is "unacceptable" (see
                <a href="#sec-unacceptable-response"><span class="specref">4.2.4 Server Rejection of HTTP Request</span></a>);
                </p>
              </li>
              <li>
                <p>the user has specifically requested a <a title="restructuring" href="#term-restructuring">restructured</a> desktop
                experience (see <a href="#sec-user-selection"><span class="specref">4.1.5.3 User Selection of Restructured Experience</span></a>);
                </p>
              </li>
              <li>
                <p>the request is part of a sequence of requests comprising either included resources or linked resources 
                on the same Web site (see <a href="#sec-sequence-of-requests"><span class="specref">4.1.5.4 Sequence of Requests</span></a>).
                </p>
              </li>
            </ol>
            <p>These circumstances are detailed in the following sections.</p>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p>It is emphasized that requests <strong id="ta-32212">must not</strong> be altered in the presence of <code>Cache-Control: no-transform</code> as described under <a href="#sec-request-no-transform"><span class="specref">4.1.2 no-transform directive in Request</span></a>.
              </p>
            </div>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p id="term-web-site">In this section, the concept of "Web site" is used
              (rather than "origin server") as some origin servers host many different
              Web sites. Since the concept of "Web site" is not strictly defined,
              proxies <strong id="ta-34769">should</strong> use heuristics including comparisons
              of domain name to assess whether resources form part of the same "Web
              site".
              </p>
            </div>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p>The URI referred to in the request plays no part in
              determining whether or not to alter HTTP request header field values. In
              particular the patterns mentioned in
              <a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a> are not material.
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-content-tasting" id="sec-content-tasting"></a>4.1.5.1 Content Tasting
              </h5>
              <p>While complying with this section (<a href="#sec-altering-header-values"><span class="specref">4.1.5 Alteration of HTTP Header Field Values</span></a>) and section <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a> proxies <strong id="ta-37267">should</strong> avoid making repeated requests for the same resource.
              </p>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>While HTTP does not prohibit repetition of GET requests, repeated requests place an unnecessary load on the network and server.
                
                </p>
              </div>
            </div>
            <div class="div4">
              
              <h5><a name="sec-avoiding-request-unacceptable" id="sec-avoiding-request-unacceptable"
                     ></a>4.1.5.2 Avoiding "Request Unacceptable" Responses
              </h5>
              <p>A proxy <strong>may</strong> reissue a request with altered HTTP header field
              values if a previous request with unaltered values resulted in the
              origin server rejecting the request as "unacceptable" (see <a href="#sec-unacceptable-response"><span class="specref">4.2.4 Server Rejection of HTTP Request</span></a>). A proxy <strong>may</strong> apply heuristics of
              various kinds to assess, in advance of sending unaltered header field values,
              whether the request is likely to cause a "request unacceptable"
              response. If it determines that this is likely then it
              <strong>may</strong> alter header field values without sending unaltered
              values in advance, providing that it subsequently assesses the response
              as described under <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a> below,
              and is prepared to reissue the request with unaltered header fields, and alter
              its subsequent behavior in respect of the Web site so that unaltered
              header fields are sent.
              </p>
              <p>A proxy <strong id="ta-8535">must not</strong> reissue a POST request as it is unsafe (see <a href="#ref-HTTP">[RFC 2616 HTTP]</a> <a href="http://tools.ietf.org/html/rfc2616#section-9.1.1">Section 9.1.1</a>).
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-user-selection" id="sec-user-selection"></a>4.1.5.3 User Selection of Restructured Experience
              </h5>
              <p>Proxies <strong id="ta-38106">must</strong> assume that by default users will wish
              to receive a representation prepared by the Web site.
              </p>
              <p>Proxies <strong>may</strong> offer users an option to choose to view a
              restructured experience even when a Web site offers a choice of user
              experience. If a user has made such a choice then proxies
              <strong>may</strong> alter header field values when requesting resources in
              order to reflect that choice, but <strong id="ta-21844">must</strong>, on receipt of
              an indication from a Web site that it offers alternative representations
              (see <a href="#sec-use-of-link-element"><span class="specref">I.1.4.2 Indication of Intended Presentation Media Type of Representation</span></a>), inform the user of that
              and allow them to select an alternative representation.
              </p>
              <p>Proxies
              <strong id="ta-38061">must</strong> assess whether a user's expressed preference
              for a restructured representation is still valid if a Web site changes
              its choice of representations (see <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a>).
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-sequence-of-requests" id="sec-sequence-of-requests"></a>4.1.5.4 Sequence of Requests
              </h5>
              <p>When requesting resources that are <a href="http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources"
              >included resources</a> (e.g. style sheets, images), proxies <strong id="ta-46682">should</strong>
              make the request for such resources with the same <code>User-Agent</code> header field as the request
              for the resource from which they are referenced.
              </p>
              <p>For the purpose of consistency of representation, proxies
              <strong>may</strong> request linked resources (e.g. those referenced
              using the <code>a</code> element) that form part of the same Web site as
              a previously requested resource with the same header fields as the resource
              from which they are referenced.
              </p>
              <p>When requesting linked resources that do not form part of the same Web
              site as the resource from which they are linked, proxies <strong id="ta-7181">should
              not</strong> base their choice of header fields on a consistency of
              presentation premise.
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-original-headers" id="sec-original-headers"></a>4.1.5.5 Original Header Fields
              </h5>
              <p>When forwarding an HTTP request with altered HTTP header fields, in addition to complying with the rules of normal HTTP operation,
              proxies
              <strong id="ta-65343">must</strong> include in the request additional fields of the form <code>"X-Device-"&lt;original
              header name&gt;</code> whose values are verbatim copies of the corresponding
              unaltered header field values, so that it is possible to reconstruct the original header fields. For example, if the <code>User-Agent</code>
              header field has been altered, an <code>X-Device-User-Agent</code> header field
              would be added with the value of the received
              <code>User-Agent</code> header field.
              </p>
              <p>Specifically the following mapping <strong id="ta-23178">must</strong> be used:
              </p>
              <table>
                <thead>
                  <tr>
                    <th rowspan="1" colspan="1">Original</th>
                    <th rowspan="1" colspan="1">Replacement</th>
                    <th rowspan="1" colspan="1">Ref</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td rowspan="1" colspan="1"><code>User-Agent</code></td>
                    <td rowspan="1" colspan="1"><code>X-Device-User-Agent</code></td>
                    <td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.43">RFC2616 Section 14.43</a> 
                    </td>
                  </tr>
                  <tr>
                    <td rowspan="1" colspan="1"><code>Accept</code></td>
                    <td rowspan="1" colspan="1"><code>X-Device-Accept</code></td>
                    <td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.1">RFC2616 Section 14.1</a> 
                    </td>
                  </tr>
                  <tr>
                    <td rowspan="1" colspan="1"><code>Accept-Charset</code></td>
                    <td rowspan="1" colspan="1"><code>X-Device-Accept-Charset</code></td>
                    <td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.2">RFC2616 Section 14.2</a> 
                    </td>
                  </tr>
                  <tr>
                    <td rowspan="1" colspan="1"><code>Accept-Encoding</code></td>
                    <td rowspan="1" colspan="1"><code>X-Device-Accept-Encoding</code></td>
                    <td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.3">RFC2616 Section 14.3</a> 
                    </td>
                  </tr>
                  <tr>
                    <td rowspan="1" colspan="1"><code>Accept-Language</code></td>
                    <td rowspan="1" colspan="1"><code>X-Device-Accept-Language</code></td>
                    <td rowspan="1" colspan="1"><a href="http://tools.ietf.org/html/rfc2616#section-14.4">RFC2616 Section 14.4</a> 
                    </td>
                  </tr>
                </tbody>
              </table>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>The <code>X-Device-</code> prefixed header names listed in this section have been provisionally registered with IANA (see <a href="http://www.iana.org/assignments/message-headers/prov-headers.html"
                >Provisional Message Header Field Names</a>).
                </p>
              </div>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>The <code>X-Device-</code> prefix was chosen primarily on the basis
                that this is an already existing convention. It is noted that the
                values encoded in such header fields may not ultimately derive from a
                device, they are merely received fields. The treatment of received
                <code>X-Device</code> header fields, which may happen where there are
                multiple transforming proxies, is undefined (see <a href="#sec-scope-for-future-work"><span class="specref">K Scope for Future Work</span></a>).
                </p>
              </div>
            </div>
          </div>
          <div class="div3">
            
            <h4><a name="sec-additional-headers" id="sec-additional-headers"></a>4.1.6 Additional HTTP Header Fields
            </h4>
            <p>Irrespective of the presence of a <code>no-transform</code> directive:
            </p>
            <ul>
              <li>
                <p>proxies <strong id="ta-12437">should</strong> add the IP address of the initiator
                of the request to the end of a comma separated list in an
                <code>X-Forwarded-For</code> HTTP header field;
                </p>
              </li>
              <li>
                <p>proxies <strong id="ta-14351">must</strong> (in accordance with RFC
                2616) include a <code>Via</code> HTTP
                header field (see <a href="#sec-via-headers"><span class="specref">4.1.6.1 Proxy Treatment of Via Header Field</span></a>).
                </p>
              </li>
            </ul>
            <div class="div4">
              
              <h5><a name="sec-via-headers" id="sec-via-headers"></a>4.1.6.1 Proxy Treatment of <code>Via</code> Header Field
              </h5>
              <p>Proxies <strong id="ta-49612">should</strong> indicate their ability to transform content by including a comment in the <code>Via</code> HTTP
              header field consisting of the URI "http://www.w3.org/ns/ct".
              </p>
              <p>When forwarding <code>Via</code> header fields, proxies <strong id="ta-41044">should
              not</strong> alter them by removing comments from them.
              </p>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>According to <a href="#ref-HTTP">[RFC 2616 HTTP]</a>
                <a href="http://tools.ietf.org/html/rfc2616#section-14.45">Section 14.45</a>
                <code>Via</code> header field comments "<strong>may</strong> be removed
                by any recipient prior to forwarding the message". However, the
                justification for removing such comments is based on memory
                limitations of early proxies. Most modern proxies do not suffer such
                limitations.
                </p>
              </div>
            </div>
          </div>
        </div>
        <div class="div2">
          
          <h3><a name="sec-Proxy-Response" id="sec-Proxy-Response"></a>4.2 Proxy Forwarding of Response to User Agent
          </h3>
          <p>In the following, proxies <strong id="ta-32045">must</strong> check for the presence of equivalent <code>&lt;meta http-equiv&gt;</code> elements in HTML content, if the relevant HTTP header field is not present.
          </p>
          <div class="div3">
            
            <h4><a name="sec-administrative-arrangements" id="sec-administrative-arrangements"
                   ></a>4.2.1 User Preferences
            </h4>
            <p>Proxies <strong id="ta-14363">must</strong> provide a means for users to express preferences for inhibiting content transformation even when content transformation has
            been chosen by the user as the default behavior. Those preferences <strong id="ta-21589">must</strong> be maintained on a user by user and Web site by Web site basis.
            </p>
            <p>Proxies <strong id="ta-1707">must</strong> solicit re-expression of preferences in respect of a server if the server starts to indicate that it offers varying responses
            as discussed under <a href="#sec-receipt-of-vary-header"><span class="specref">4.2.5 Receipt of Vary HTTP Header Field</span></a>.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-receipt-of-cache-control-no-transform"
                   id="sec-receipt-of-cache-control-no-transform"
                   ></a>4.2.2 Receipt of <code>Cache-Control: no-transform</code></h4>
            <p>If the response includes a <code>Cache-Control: no-transform</code> directive
            then proxies <strong id="ta-4894">must not</strong> alter it other than to comply with
            <a title="transparent proxy" href="#term-transparent">transparent</a> HTTP behavior as described in <a href="#ref-HTTP">[RFC 2616 HTTP]</a> <a href="http://tools.ietf.org/html/rfc2616.html#section-13.5.2">Section 13.5.2</a> and <a href="http://tools.ietf.org/html/rfc2616.html#section-14.9.5">Section 14.9.5</a>.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-proxy-use-of-no-transform" id="sec-proxy-use-of-no-transform"
                   ></a>4.2.3 Use of <code>Cache-Control: no-transform</code></h4>
            <p>Proxies <strong>may</strong> use <code>Cache-Control: no-transform</code> to inhibit transformation by further proxies.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-unacceptable-response" id="sec-unacceptable-response"></a>4.2.4 Server Rejection of HTTP Request
            </h4>
            <p>Proxies <strong>may</strong>
            treat responses with an HTTP 200 Status as though they were responses with
            an HTTP 406 Status if it has determined that the content (e.g. "Your browser
            is not supported") is equivalent to a response with an HTTP 406 Status.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-receipt-of-vary-header" id="sec-receipt-of-vary-header"></a>4.2.5 Receipt of <code>Vary</code> HTTP Header Field
            </h4>
            <p>A proxy may not be carrying out content tasting as described under <a href="#sec-avoiding-request-unacceptable"><span class="specref">4.1.5.2 Avoiding "Request Unacceptable" Responses</span></a> if it anticipates receiving a "request unacceptable" response. However, if it makes a request with altered header fields
            in these circumstances, and receives a response
            containing a <code>Vary</code> header field referring to one of the altered
            header fields then it <strong id="ta-58567">should</strong> request the resource again with
            unaltered header fields. It <strong id="ta-52209">should</strong> also update whatever heuristics
            it uses so that unaltered header fields are presented first in subsequent requests
            for this resource.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-receipt-of-link-to-handheld" id="sec-receipt-of-link-to-handheld"
                   ></a>4.2.6 Link to "handheld" Representation
            </h4>
            <p>If the response is an HTML response and it contains a <code>&lt;link
            rel="alternate" media="handheld" /&gt;</code> element (and the user agent is determined as being "handheld"), a proxy
            <strong id="ta-43424">should</strong> request and process the referenced resource,
            unless the resource referenced is the <a title="current representation" href="#term-current-representation">current representation</a>.
            </p>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p><a name="term-current-representation" id="term-current-representation"
                    title="current representation"
                    ></a>In this document the term <b>current representation</b> means a "same document reference" as defined in <a href="#ref-rfc-3986">[RFC 3986]</a> <a href="http://tools.ietf.org/html/rfc3986#section-4.4">Section 4.4</a>, with the addition that if a <code>Vary</code> HTTP header field was present on the response then it is the same representation if the values of the HTTP header fields
              of the request have not been altered.
              </p>
            </div>
          </div>
          <div class="div3">
            
            <h4><a name="sec-WML-content" id="sec-WML-content"></a>4.2.7 WML Content
            </h4>
            <p>If the content is WML proxies <strong id="ta-43472">should</strong> act in a <a title="transparent proxy" href="#term-transparent">transparent</a> manner.
            </p>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p>This does not affect the operation of proxies that are also WAP Gateways.</p>
            </div>
          </div>
          <div class="div3">
            
            <h4><a name="sec-proxy-decision-to-transform" id="sec-proxy-decision-to-transform"
                   ></a>4.2.8 Proxy Decision to Transform
            </h4>
            <p>In the absence of a <code>Vary</code> or <code>no-transform</code> directive
            (or a <code>meta HTTP-Equiv</code> element containing <code>Cache-Control:
            no-transform</code>) proxies <strong id="ta-64788">should not</strong> transform content matching any of the following rules unless the user has specifically requested transformation:
            </p>
            <ul>
              <li>
                <p>the content is HTML and contains <code>&lt;link rel="alternate" media="handheld"/&gt;</code> with a reference to the <a title="current representation" href="#term-current-representation">current representation</a>;
                </p>
              </li>
              <li>
                <p>the <code>DOCTYPE</code> of the content (if it has one) indicates XHTML-MP, XHTML Basic, WML or iMode as listed in <a href="#sec-Mobile-DOCTYPES"><span class="specref">E DOCTYPEs Associated with Mobile Content</span></a>;
                </p>
              </li>
              <li>
                <p>the <code>Content-Type</code> has a value listed in <a href="#sec-Mobile-Content-Types"><span class="specref">C Internet Content Types associated with Mobile Content</span></a>.
                </p>
              </li>
              <li>
                <p>the URI of the response (following redirection or as indicated by the
                <code>Content-Location</code> HTTP header field) matches a pattern listed in <a href="#sec-Mobile-URI-Patterns"><span class="specref">F URI Patterns Associated with Mobile Web Sites</span></a>;
                </p>
              </li>
              <li>
                <p>the response contains a resource that is referenced as an <a href="http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources"
                >included resource</a> suitable for "handheld" in a resource that was itself handled transparently;
                </p>
              </li>
              <li>
                <p>the <code>Content-Type</code> indicates that the content is "data" - some values are listed in <a href="#sec-Data-Content-Types"><span class="specref">D Internet Content Types associated with Data Content</span></a>;
                </p>
              </li>
              <li>
                <p>a claim of mobileOK Basic <a href="#ref-mobileOK">[mobileOK Basic Tests]</a> conformance
                is indicated (see <a href="#ref-mobileOK-scheme">[mobileOK Scheme]</a> for how such a claim may be indicated).
                </p>
              </li>
            </ul>
            <p>Other factors that a proxy <strong>may</strong> take into account:
            </p>
            <ul>
              <li>
                <p>The Web site (see <a href="#term-web-site">note</a>) has previously shown that it is
                contextually aware, even if the present response does not indicate
                this;
                </p>
              </li>
              <li>
                <p>the user agent has features (such as linearization or zoom, or is a desktop device using a mobile network for access) that
                allow it to present the content unaltered;
                </p>
              </li>
              <li>
                <p>the response contains client side scripts that may misoperate if the
                resource is restructured;
                </p>
              </li>
              <li>
                <p>the response is an HTML response and it includes
                <code>&lt;link&gt;</code> elements specifying
                alternatives according to presentation media type.
                </p>
              </li>
            </ul>
            <div class="div4">
              
              <h5><a name="sec-alteration-of-response" id="sec-alteration-of-response"></a>4.2.8.1 Alteration of Response
              </h5>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>Other than as noted in this
                section the nature of restructuring that is carried out, any character encoding alterations and what is
                omitted and what is inserted is, as discussed in <a href="#sec-scope"><span class="specref">1.3 Scope</span></a>, out of scope of this document.
                </p>
              </div>
              <p>If a proxy alters the response then:</p>
              <ol class="enumar">
                <li>
                  <p>It <strong id="ta-34526">must</strong> add a <code>Warning 214 Transformation
                  Applied</code> HTTP header field;
                  </p>
                </li>
                <li>
                  <p>The altered content <strong id="ta-55014">should</strong> validate according
                  to an appropriate published formal grammar and if XML <strong id="ta-10803">must</strong> be <a href="http://www.w3.org/TR/xml/#dt-wellformed">well-formed</a>;
                  </p>
                </li>
                <li>
                  <p>It <strong id="ta-39889">should</strong> indicate to the user that the
                  content has been transformed for mobile presentation and provide
                  an option to view the original, unmodified content.
                  </p>
                </li>
              </ol>
            </div>
            <div class="div4">
              
              <h5><a name="sec-link-rewriting" id="sec-link-rewriting"></a>4.2.8.2 Link Rewriting
              </h5>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p><a name="term-same-origin" id="term-same-origin" title="Same-Origin"></a>In this document two URIs have the <b>Same-Origin</b> if the <code>scheme</code> component and the <code>host</code> and <code>port</code> subcomponents, as defined in <a href="#ref-rfc-3986">[RFC 3986]</a>, all match. <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a> of <a href="#ref-rfc-3986">[RFC 3986]</a> discusses URI comparison.
                </p>
              </div>
              <p>Some proxy deployments have to "rewrite" links in content in order for the user agent to request the referenced resources
              through the proxy. In so doing, proxies make unrelated resources appear as though they have the <a title="Same-Origin" href="#term-same-origin">same-origin</a> and hence there is a danger of introducing security vulnerabilities.
              </p>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>This section (on link rewriting) refers also to insertion of links, frame flattening and any other techniques that introduces
                the "same-origin" issue.
                </p>
              </div>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile adapted
                web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the
                CT Proxy for adaptation of a web page. Link rewriting may be used by CT Proxies acting as normal HTTP proxies (e.g. configured
                or transparent) for the browser, but may not be required since all browser requests flow through the CT Proxy.
                </p>
              </div>
              <p>Proxies <strong id="ta-5078">must not</strong> rewrite links when content transformation is prohibited.
              </p>
              <p>Proxies <strong id="ta-18105">must</strong> preserve security between requests for domains that are not <a title="Same-Origin" href="#term-same-origin">same-origin</a> in respect of cookies and scripts.
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-https-link-rewriting" id="sec-https-link-rewriting"></a>4.2.8.3 HTTPS Link Rewriting
              </h5>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>For clarity it is emphasized that it is not possible for a
                transforming proxy to transform content accessed via an HTTPS link
                without breaking end-to-end security.
                </p>
                <p>Interception of HTTPS and the circumstances in which it might be permissible is not a "mobile" question, as such, but is highly
                pertinent to this document. The BPWG is aware that interception of HTTPS happens in many networks today. Interception of HTTPS
                is inherently problematic and may be unsafe. The BPWG would like to refer to protocol based "two party consent" mechanisms,
                but such mechanisms do not exist at the time of writing of this document.
                </p>
              </div>
              <p>The practice of intercepting HTTPS links is strongly <strong id="ta-43818">NOT RECOMMENDED</strong>.
              </p>
              <p>If a proxy rewrites HTTPS links, it
              <strong id="ta-26858">must</strong> advise the user of the security implications
              of doing so and <strong id="ta-17637">must</strong> provide the option to bypass it and to communicate with the server directly.
              </p>
              <p>Notwithstanding anything else in this document, proxies <strong id="ta-53227">must not</strong> rewrite HTTPS links in the presence of a <code>Cache-Control: no-transform</code> directive.
              </p>
              <p>If a proxy rewrites HTTPS links, replacement links
              <strong id="ta-36041">must</strong> have the scheme <code>https</code>.
              </p>
              <p>When forwarding requests originating from HTTPS links proxies <strong id="ta-40493">must</strong> include a <code>Via</code> header field as discussed under <a href="#sec-via-headers"><span class="specref">4.1.6.1 Proxy Treatment of Via Header Field</span></a>.
              </p>
              <p>When forwarding responses from servers proxies <strong id="ta-10117">must</strong> notify the user of invalid server certificates.
              </p>
            </div>
          </div>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-testing" id="sec-testing"></a>5 Testing (Normative)</h2>
        <p>Operators of content transformation proxies <strong id="ta-58462">should</strong>
        make available an interface through which the functions of
        the proxy can be exercised. The operations possible
        through this interface <strong id="ta-4172">must</strong> cover those necessary to
        settle the outcome of all conformance statements listed in
        section B.
        </p>
        <p>The interface <strong id="ta-23958">must</strong> be reachable from terminals with
        browsing capabilities connected to the Web via a
        conventional Internet access environment at the tester's
        premises; accessing the interface <strong>may</strong> necessitate
        adjusting standard Web browsing configuration 
        parameters -- such as specifying a proxy IP address and
        port on a desktop browser, or activating a WAP setting on
        a mobile browser.
        </p>
        <p>Such access <strong id="ta-1181">must</strong> be granted under fair, reasonable and non-discriminatory conditions. In
        particular:
        </p>
        <ul>
          <li>
            <p>it is available to all, worldwide, whether or not they are W3C Members;</p>
          </li>
          <li>
            <p>it does not impose any further conditions or restrictions on the use of any 
            technology, intellectual property rights, or other restrictions on behaviour of the
            tester, but may include reasonable, customary terms relating to operation or 
            maintenance of the relationship between tester and proxy operator such as the 
            following: choice of law and dispute resolution, confidentiality of parameters to 
            access the interface, disclaimer of liability.
            </p>
          </li>
        </ul>
      </div>
    </div>
    <div class="back">
      <div class="div1">
        
        <h2><a name="sec-references" id="sec-references"></a>A References</h2>
        <dl>
          <dt class="label"><a name="ref-CT-Landscape" id="ref-CT-Landscape"></a>CT Landscape
          </dt>
          <dd>Content
          Transformation Landscape 1.0, Jo Rabin, Andrew Swainston (eds), W3C Working
          Group Note 27 October 2009  (See <a href="http://www.w3.org/TR/2009/NOTE-ct-landscape-20091027/">http://www.w3.org/TR/2009/NOTE-ct-landscape-20091027/</a>)
          </dd>
          <dt class="label"><a name="ref-rfc-2119" id="ref-rfc-2119"></a>RFC 2119
          </dt>
          <dd>Key words for use in RFCs to Indicate
          Requirement Levels, , Request for Comments: 2119, S. Bradner, March 1997  (See <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>)
          </dd>
          <dt class="label"><a name="ref-HTTP" id="ref-HTTP"></a>RFC 2616 HTTP
          </dt>
          <dd> Hypertext Transfer Protocol --
          HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H.
          Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999  (See <a href="http://tools.ietf.org/html/rfc2616">http://tools.ietf.org/html/rfc2616</a>)
          </dd>
          <dt class="label"><a name="ref-rfc-3986" id="ref-rfc-3986"></a>RFC 3986
          </dt>
          <dd>Uniform Resource Identifier (URI):
          Generic Syntax, Request for Comments: 3986, T. Berners-Lee, R. Fielding, L.
          Masinter, January 2005   (See <a href="http://tools.ietf.org/html/rfc3986">http://tools.ietf.org/html/rfc3986</a>)
          </dd>
          <dt class="label"><a name="ref-OPES" id="ref-OPES"></a>RFC 3238 OPES
          </dt>
          <dd>
            IAB Architectural and Policy Considerations for Open Pluggable Edge Services, Request for Comments: 3238, 
            S. Floyd, L. Daigle, January 2002  (See <a href="http://tools.ietf.org/html/rfc3238">http://tools.ietf.org/html/rfc3238</a>)
          </dd>
          <dt class="label"><a name="ref-DIGLOSS" id="ref-DIGLOSS"></a>Device Independence Glossary
          </dt>
          <dd>W3C Glossary of Terms for Device Independence, Rhys Lewis
          (ed), W3C Working Draft 18 January 2005
          </dd>
          <dt class="label"><a name="ref-BestPractices" id="ref-BestPractices"></a>Best Practices
          </dt>
          <dd>Mobile Web Best
          Practices 1.0 Basic Guidelines, Jo Rabin, Charles McCathieNevile (eds), W3C
          Recommendation, 29 July 2008  (See <a href="http://www.w3.org/TR/2008/REC-mobile-bp-20080729/">http://www.w3.org/TR/2008/REC-mobile-bp-20080729/</a>)
          </dd>
          <dt class="label"><a name="ref-mobileOK" id="ref-mobileOK"></a>mobileOK Basic Tests
          </dt>
          <dd>W3C mobileOK
          Basic Tests 1.0, Sean Owen, Jo Rabin (eds), W3C Recommendation, 08 December 2008  (See <a href="http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/"
          >http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/</a>)
          </dd>
          <dt class="label"><a name="ref-mobileOK-scheme" id="ref-mobileOK-scheme"></a>mobileOK Scheme
          </dt>
          <dd>W3C mobileOK
          Scheme 1.0, Jo Rabin, Phil Archer (eds), W3C Note, 25 August 2009  (See <a href="http://www.w3.org/TR/2009/NOTE-mobileOK-20090825/">http://www.w3.org/TR/2009/NOTE-mobileOK-20090825/</a>)
          </dd>
          <dt class="label"><a name="ref-powder-grouping" id="ref-powder-grouping"></a>POWDER Resource Grouping
          </dt>
          <dd>Protocol for Web Description Resources (POWDER): Grouping of Resources, Phil Archer, Andrea Perego, Kevin Smith (eds), W3C
          Recommendation, 1 September 2009  (See <a href="http://www.w3.org/TR/2009/REC-powder-grouping-20090901/">http://www.w3.org/TR/2009/REC-powder-grouping-20090901/</a>)
          </dd>
          <dt class="label"><a name="ref-XHR" id="ref-XHR"></a>XHR
          </dt>
          <dd>XMLHttpRequest, Anne van
          Kesteren (ed), W3C Candidate Recommendation 3 August 2010  (See <a href="http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/">http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/</a>)
          </dd>
          <dt class="label"><a name="ref-XML" id="ref-XML"></a>XML
          </dt>
          <dd>Extensible Markup Language (XML) 1.0 (Fifth Edition),  T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. Yergeau (eds),
          W3C Recommendation, 26 November 2008.  (See <a href="http://www.w3.org/TR/2008/REC-xml-20081126/">http://www.w3.org/TR/2008/REC-xml-20081126/</a>)
          </dd>
        </dl>
      </div>
      <div class="div1">
        
        <h2><a name="sec-ConformanceStatement" id="sec-ConformanceStatement"></a>B Conformance Statement</h2>
        <p>See <a href="http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/ics">http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/ics</a> 
        </p>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Mobile-Content-Types" id="sec-Mobile-Content-Types"></a>C Internet Content Types associated with Mobile Content</h2>
        <p>This list is not exhaustive and is likely to change.</p>
        <div class="exampleInner"><pre>application/vnd.wap.xhtml+xml</pre></div>
        <div class="exampleInner"><pre>text/vnd.wap.wml</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.wmlc</pre></div>
        <div class="exampleInner"><pre>text/vnd.wap.wml+xml</pre></div>
        <div class="exampleInner"><pre>text/vnd.wap.wmlscript</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.wmlscriptc</pre></div>
        <div class="exampleInner"><pre>image/vnd.wap.wbmp</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.wbxml</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.multipart.mixed</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.multipart.related</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.multipart.alternative</pre></div>
        <div class="exampleInner"><pre>application/vnd.wap.multipart.form-data</pre></div>
        <div class="exampleInner"><pre>image/x-up-wpng</pre></div>
        <div class="exampleInner"><pre>image/x-up-bmp</pre></div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Data-Content-Types" id="sec-Data-Content-Types"></a>D Internet Content Types associated with Data Content</h2>
        <p>This list is not exhaustive and is likely to change.</p>
        <div class="exampleInner"><pre>application/json</pre></div>
        <div class="exampleInner"><pre>application/soap+xml</pre></div>
        <div class="exampleInner"><pre>application/soap+fastinfoset</pre></div>
        <div class="exampleInner"><pre>application/fastsoap</pre></div>
        <div class="exampleInner"><pre>application/fastinfoset</pre></div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Mobile-DOCTYPES" id="sec-Mobile-DOCTYPES"></a>E DOCTYPEs Associated with Mobile Content</h2>
        <p>This list is not exhaustive and is likely to change.</p>
        <div class="exampleInner"><pre>-//OMA//DTD XHTML Mobile 1.2//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD XHTML Mobile 1.1//EN </pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD XHTML Mobile 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//W3C//DTD XHTML Basic 1.1//EN</pre></div>
        <div class="exampleInner"><pre>-//W3C//DTD XHTML Basic 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//OPENWAVE//DTD XHTML 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//OPENWAVE//DTD XHTML Mobile 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.0) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.1) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.0) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.1) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.2) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.3) 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//W3C//DTD Compact HTML 1.0 Draft//EN</pre></div>
        <div class="exampleInner"><pre>-//BBSW//DTD Compact HTML 2.0//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.0//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.1//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.2//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD WML 1.3//EN</pre></div>
        <div class="exampleInner"><pre>-//WAPFORUM//DTD WML 2.0//EN</pre></div>
        <div class="exampleInner"><pre>-//PHONE.COM//DTD WML 1.1//EN</pre></div>
        <div class="exampleInner"><pre>-//OPENWAVE.COM//DTD WML 1.3//EN</pre></div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Mobile-URI-Patterns" id="sec-Mobile-URI-Patterns"></a>F URI Patterns Associated with Mobile Web Sites</h2>
        <p>Using the notation defined in <a href="#ref-powder-grouping">[POWDER Resource Grouping]</a>: 
        </p>
        <div class="exampleInner"><pre>&lt;iriset&gt;
        &lt;includehosts&gt;mobi&lt;/includehosts&gt;
        &lt;/iriset&gt;</pre></div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-Summary-User-Preference-Handling" id="sec-Summary-User-Preference-Handling"></a>G Summary of User Preference Handling</h2>
        <p>User expression of preferences is referred to in several sections in this document. Those sections are:</p>
        <ol class="enumar">
          <li>
            <p><a href="#sec-priority-of-intention"><span class="specref">1.4.2 Priority of Intention</span></a></p>
          </li>
          <li>
            <p><a href="#sec-serving-cached-responses"><span class="specref">4.1.4 Serving Cached Responses</span></a></p>
          </li>
          <li>
            <p><a href="#sec-user-selection"><span class="specref">4.1.5.3 User Selection of Restructured Experience</span></a></p>
          </li>
          <li>
            <p><a href="#sec-administrative-arrangements"><span class="specref">4.2.1 User Preferences</span></a></p>
          </li>
          <li>
            <p><a href="#sec-receipt-of-cache-control-no-transform"><span class="specref">4.2.2 Receipt of Cache-Control: no-transform</span></a></p>
          </li>
          <li>
            <p><a href="#sec-proxy-decision-to-transform"><span class="specref">4.2.8 Proxy Decision to Transform</span></a></p>
          </li>
          <li>
            <p><a href="#sec-alteration-of-response"><span class="specref">4.2.8.1 Alteration of Response</span></a></p>
          </li>
          <li>
            <p><a href="#sec-https-link-rewriting"><span class="specref">4.2.8.3 HTTPS Link Rewriting</span></a></p>
          </li>
        </ol>
        <p>User preferences are also referred to non-normatively under <a href="#sec-varying-representations"><span class="specref">I.1.4 Varying Representations</span></a>.
        </p>
      </div>
      <div class="div1">
        
        <h2><a name="sec-example-transformation-interactions" id="sec-example-transformation-interactions"></a>H Example Transformation Interactions (Non-Normative)</h2>
        <div class="note">
          <p class="prefix"><b>Note:</b></p>
          <p>The following examples refer to requests with the GET method.</p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-basic-content-tasting" id="sec-basic-content-tasting"></a>H.1 Basic Content Tasting by Proxy
          </h3>
          <div class="exampleOuter">
            <p class="flow1">Request resource with original header fields</p>
            <p class="flow1">If the response is a 406 response:</p>
            <p class="flow2">If the response contains <code>Cache-Control:
            no-transform</code>, forward it
            </p>
            <p class="flow2">Otherwise request again with altered header fields</p>
            <p class="flow1">If the response is a 200 response:</p>
            <p class="flow2">If the response contains <code>Vary: User-Agent</code>, an
            appropriate <code>link</code> element or header field, or <code>Cache-Control:
            no-transform</code>, forward it
            </p>
            <p class="flow2">Otherwise assess whether the 200 response is a form of "Request
            Unacceptable"
            </p>
            <p class="flow3">If it is not, forward it</p>
            <p class="flow3">If it is, request again with altered header fields</p>
          </div>
        </div>
        <div class="div2">
          
          <h3><a name="sec-proxy-a-priori-knowledge" id="sec-proxy-a-priori-knowledge"
                 ></a>H.2 Optimization based on Previous Server Interaction
          </h3>
          <div class="exampleOuter">
            <p class="flow1">Proxy receives a request for resource P that it has not
            encountered before
            </p>
            <p class="flow1">Proxy forwards this request</p>
            <p class="flow1">Response is 200 OK containing the text "Unsupported browser.
            Please get a different one or use a CT proxy."
            </p>
            <p class="flow1">Proxy determines that this equates to a 406 Status and
            requests the resource from the origin server again with altered header fields
            (emulating a well known desktop browser)
            </p>
            <p class="flow1">Response is a desktop oriented representation of the resource</p>
            <p class="flow1">Proxy transforms this response into content that the user agent
            can display well and forwards it
            </p>
            <p class="flow1">Proxy receives a further request for the resource P</p>
            <p class="flow1">Based on evidence from the previous interaction (e.g. that there
            was no <code>Vary</code> header field, that the response was not targeted at only
            the previous user in that there was no <code>Cache-Control: private</code>
            directive) the CT proxy forwards the request with altered header fields
            </p>
            <p class="flow1">Response is a desktop oriented representation of the resource</p>
            <p class="flow1">Proxy transforms this response into content that the user agent
            can display well and forwards it
            </p>
          </div>
        </div>
        <div class="div2">
          
          <h3><a name="sec-optimization-previous-interaction" id="sec-optimization-previous-interaction"></a>H.3 Optimization based on Previous Server Interaction, Server has Changed its
          Operation
          </h3>
          <div class="exampleOuter">
            <p class="flow1">Proxy receives a request for resource P, that it has previously
            encountered as in <a href="#sec-proxy-a-priori-knowledge"><span class="specref">H.2 Optimization based on Previous Server Interaction</span></a></p>
            <p class="flow1">Proxy forwards request with altered header fields</p>
            <p class="flow1">Response is 200 OK containing a <code>Vary: User-Agent</code>
            header field
            </p>
            <p class="flow1">Proxy notices that behavior has changed and reissues the request
            with original header fields
            </p>
            <p class="flow1">Response is 200 OK and proxy forwards it</p>
          </div>
        </div>
        <div class="div2">
          
          <h3><a name="sec-representation-intended" id="sec-representation-intended"></a>H.4 Server Response Indicating that this Representation is Intended for the Target
          Device
          </h3>
          <div class="exampleOuter">
            <p class="flow1">Proxy receives a request for resource P</p>
            <p class="flow1">Proxy forwards request with original header fields</p>
            <p class="flow1">Response is 200 OK with <code>Vary: User-Agent</code> and
            <code>&lt;link type="alternate" media="handheld" href="P#id"
            /&gt;</code> where id is a document local reference
            </p>
            <p class="flow1">Proxy forwards response as designed specifically for the
            requesting device
            </p>
          </div>
        </div>
        <div class="div2">
          
          <h3><a name="sec-another-representation" id="sec-another-representation"></a>H.5 Server Response Indicating that another Representation is Intended for the Target Device</h3>
          <div class="exampleOuter">
            <p class="flow1">Proxy receives a request for resource P</p>
            <p class="flow1">Proxy forwards request with original header fields</p>
            <p class="flow1">Response is 200 OK with <code>&lt;link type="alternate"
            media="handheld" href="Q" /&gt;</code> and Q is not P
            </p>
            <p class="flow1">Proxy requests Q with original header fields</p>
            <p class="flow1">Response is 200 OK and proxy forwards it</p>
          </div>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-guidance-origin-servers" id="sec-guidance-origin-servers"></a>I Informative Guidance for Origin Servers (Non-Normative)</h2>
        <p>Content providers may wish to follow these procedures in order to improve interoperability.</p>
        <div class="div2">
          
          <h3><a name="sec-ServerResponse" id="sec-ServerResponse"></a>I.1 Server Response to Proxy
          </h3>
          <div class="div3">
            
            <h4><a name="sec-server-use-of-406" id="sec-server-use-of-406"></a>I.1.1 Use of HTTP 406 Status
            </h4>
            <p>Servers should consider using an HTTP 406 Status (and not an
            HTTP 200 Status) if a request cannot be satisfied with content that meets
            the criteria specified by values of the HTTP request header fields. However, some browsers do not display the content of HTTP
            406 Status responses.
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-server-use-of-403" id="sec-server-use-of-403"></a>I.1.2 Use of HTTP 403 Status
            </h4>
            <p>Servers should consider using an HTTP 403 Status if concerned that the security of a link assumed to be private has been compromised
            (for example this may be inferred by the presence of a <code>Via</code> HTTP header field in an HTTPS request).
            </p>
          </div>
          <div class="div3">
            
            <h4><a name="sec-cache-control-no-transform" id="sec-cache-control-no-transform"
                   ></a>I.1.3 Server Origination of <code>Cache-Control: no-transform</code></h4>
            <p>Servers should consider including a <code>Cache-Control:
            no-transform</code> directive if one is received in the HTTP request, as it may be an indication that the client does not wish to receive a transformed
            response.
            </p>
            <p>Include a <code>Cache-Control:
            no-transform</code> directive if, for any reason, 
            transformation of the response is prohibited.
            </p>
            <div class="note">
              <p class="prefix"><b>Note:</b></p>
              <p id="wml-no-transform-note">Including a <code>Cache-Control:
              no-transform</code> directive can disrupt the behavior of WAP Gateways, 
              because it can inhibit such proxies from converting WML to
              WMLC.
              </p>
              <p>Including such a directive may also disrupt the behavior of a proxy based accessibility solution.</p>
            </div>
          </div>
          <div class="div3">
            
            <h4><a name="sec-varying-representations" id="sec-varying-representations"
                   ></a>I.1.4 Varying Representations
            </h4>
            <p>It is good practice to take account of user agent capabilities and
            formulate an appropriate experience according to those capabilities. It is good practice to  provide a means for users to
            select among
            available representations, to default to the last
            selected representation and to provide a means of
            changing the selection.
            </p>
            <div class="div4">
              
              <h5><a name="sec-use-of-vary-header" id="sec-use-of-vary-header"></a>I.1.4.1 Use of <code>Vary</code> HTTP Header Field
              </h5>
              <p>If a server varies its representation according to examination of
              received HTTP header fields then <a href="#ref-HTTP">[RFC 2616 HTTP]</a> describes how to use the <code>Vary</code> header field to indicate this.
              </p>
              <p>Servers that are aware of the presence of a transforming proxy, as identified by a
              <code>Via</code> HTTP Header field might alter their responses according to their knowledge of specific proxy behavior. When doing so it is
              good practice to make sure that the
              Internet content type for a response is correct for the actual content (e.g. a server should
              not choose <code>Content-Type: application/vnd.wap.xhtml+xml</code>
              because it suspects that proxies will not transform
              content of this type, if its content is not valid XHTML-MP). 
              </p>
            </div>
            <div class="div4">
              
              <h5><a name="sec-use-of-link-element" id="sec-use-of-link-element"></a>I.1.4.2 Indication of Intended Presentation Media Type of Representation
              </h5>
              <p>If a server has distinct representations that vary according to the
              target presentation media type, it can inhibit
              transformation of the response by including a <code>Cache-Control:
              no-transform</code> directive (see <a href="#sec-cache-control-no-transform"><span class="specref">I.1.3 Server Origination of Cache-Control: no-transform</span></a>).
              </p>
              <p>In addition, in HTML content it can indicate the medium for
              which the representation is intended by including a <code>link</code>
              element identifying in its <code>media</code> attribute the target
              presentation media types of this representation and setting the
              <code>href</code> attribute to "Same-Document Reference" (see <a href="#ref-rfc-3986">[RFC 3986]</a> <a href="http://tools.ietf.org/html/rfc3986.html#section-4.4">section 4.4</a>) and in particular an empty <code>href</code> attribute is a "Same Document Reference".
              </p>
              <p>In addition it is good practice to include <code>link</code>
              elements identifying the target presentation media types of other
              available representations in a similar manner.
              </p>
              <p>If content for more than one presentation media type is served from the same URI, it is better not to use a link element identifying
              the presentation media types as the URI will appear to be a "same document reference", indicating to a client that this representation
              is suitable for all the named presentation media types. Instead, use a <code>Vary</code> HTTP header field indicating that the response varies according to the received <code>User-Agent</code> HTTP header field.
              </p>
              <div class="note">
                <p class="prefix"><b>Note:</b></p>
                <p>Some examples of the use of the <code>link</code> element are
                included above in <a href="#sec-example-transformation-interactions"><span class="specref">H Example Transformation Interactions</span></a>.
                </p>
              </div>
            </div>
          </div>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-applicability" id="sec-applicability"></a>J Applicability to Transforming Solutions which are Out of Scope (Non-Normative)</h2>
        <p>There are a number of well-known examples of solutions that seem to their users as
        though they are using a browser, but because the client software communicates 
        using proprietary protocols and techniques, it is the combination of the client and
        the network component that is regarded as the HTTP User Agent. The communication
        between the client and the network component is therefore out of scope of this
        document.
        </p>
        <p>Additionally, where some kind of administrative arrangement exists between a
        transforming proxy and an origin server for the purposes of transforming content on
        the origin server's behalf, this is also out of scope of this document.
        </p>
        <p>In both of the above cases, it is good practice to adhere to the provisions of this document in
        respect of providing information about the device and the original IP address.
        </p>
      </div>
      <div class="div1">
        
        <h2><a name="sec-scope-for-future-work" id="sec-scope-for-future-work"></a>K Scope for Future Work (Non-Normative)</h2>
        <div class="div2">
          
          <h3><a name="sec-powder" id="sec-powder"></a>K.1 POWDER
          </h3>
          <p>The BPWG believes that <a href="http://www.w3.org/2007/powder/">POWDER</a>
          will represent a powerful mechanism by which
          a server may express transformation preferences. Future work in this area may
          recommend the use of POWDER to provide a mechanism for origin servers to
          indicate more precisely which alternatives they have and what transformation
          they are willing to allow on them, and in addition to provide for Content
          Transformation proxies to indicate which services they are able to perform.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-link-http-header" id="sec-link-http-header"></a>K.2 <code>link</code> HTTP Header Field
          </h3>
          <p>The BPWG believes that the <code>link</code> HTTP header field which was removed from
          HTTP/1.1, and which is under discussion for reintroduction, would
          represent a more general and flexible mechanism than use of the HTML
          <code>link</code> element, as discussed in this recommendation.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-sources-devinfo" id="sec-sources-devinfo"></a>K.3 Sources of Device Information
          </h3>
          <p>The process of adapting content at the origin server, or transforming it in a
          proxy is likely to have a dependency on a repository of device descriptions. An
          origin server's willingness to allow a transforming proxy to transform content
          may depend on its evaluation of the trustworthiness of device description data
          that is being used. There is scope for enhancement of the trust relationship by
          some means of indicating this.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-inter-proxy-comm" id="sec-inter-proxy-comm"></a>K.4 Inter Proxy Communication
          </h3>
          <p>There is scope for further work to define how multiple proxies may interoperate.
          A common case of multiple proxies is where a network provider transforming proxy
          and a search engine transforming proxy are both present.
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-explicit-consent" id="sec-explicit-consent"></a>K.5 Explicit Consent
          </h3>
          <p>Robust mechanisms are needed for indicating consent to or prohibition of transformation operations of various kinds, especially
          HTTPS link rewriting (see <a href="#sec-https-link-rewriting"><span class="specref">4.2.8.3 HTTPS Link Rewriting</span></a>). 
          </p>
        </div>
        <div class="div2">
          
          <h3><a name="sec-amendment-http" id="sec-amendment-http"></a>K.6 Amendment to and Refinement of HTTP
          </h3>
          <p>The BPWG believes that amendments to HTTP are needed to improve the interoperability of transforming proxies. For example,
          HTTP does not provide a way to
          distinguish between prohibition of any kind of transformation and the
          prohibition only of restructuring (and not recoding or compression).
          </p>
          <p>At present HTTP does not provide a mechanism for communicating original header field
          values. The scheme based on X-Device 
          prefixed fields described under <a href="#sec-altering-header-values"><span class="specref">4.1.5 Alteration of HTTP Header Field Values</span></a> records
          and clarifies an approach used to achieve this effect by some content 
          transformation proxies. This scheme relies upon non-standard HTTP header fields which have been provisionally registered with
          IANA. While the mechanism defined in that section, based on
          current practice, applies to conforming transformation proxy deployments, it is possible that in future, in collaboration
          with the IETF, this 
          approach will be reconsidered. This implies that the specified X-Device 
          prefixed fields may, at some time, become deprecated in favor of new 
          equivalent fields, or that an entirely different approach will be taken 
          to representing such values.
          </p>
          <p>A number of mechanisms exist in HTTP which might be exploited given more precise
          definition of their operation - for example the <code>OPTIONS</code> method and
          the HTTP 300 (Multiple Choices) Status.
          </p>
        </div>
      </div>
      <div class="div1">
        
        <h2><a name="sec-acknowledgements" id="sec-acknowledgements"></a>L Acknowledgments (Non-Normative)</h2>
        <p>The editor acknowledges contributions of various kinds from members of the <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> and earlier from the
        <a href="http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/">Content Transformation Task Force</a> of that group.
        </p>
        <p>The editor acknowledges significant written contributions from:</p>
        <ul>
          <li>François Daoust (Task Force Leader), W3C</li>
          <li>Magnus Lönnroth, Ericsson (and previously at Drutt)</li>
          <li>Bryan Sullivan, AT&amp;T</li>
          <li>Sean Patterson, Novarra</li>
          <li>Aaron Kemp, Google</li>
          <li>Rob Finean, Openwave</li>
          <li>Heiko Gerlach, Vodafone</li>
          <li>Martin Jones, Volantis</li>
          <li>Tom Hume, W3C Invited Expert</li>
          <li>Eduardo Casais, W3C Invited Expert</li>
        </ul>
      </div>
    </div>
  </body>
</html>