discontinued / server · Files

WD-P3P-preferences-20020415 186 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta name="generator" content="HTML Tidy, see www.w3.org" />

    <title>A P3P Preference Exchange Language 1.0 (APPEL1.0)</title>
    <meta http-equiv="Content-Type"
    content="text/html; charset=iso-8859-1" />
<style type="text/css">
<!--
code.c3 {font-weight: bold}
img.c2 {border:0;width:88px;height:31px}
ol.c1 {list-style-type: lower-alpha}

.new      {color: red}
.comment  {color: gray}
.highlit  {color: #009900; font-weight: bold}
.dim      {color: #808080}
tt,pre,code    {font-family: fixed;}

pre.xsd,pre.dtd { 
   font-family: monospace;
   font-size: 85%;
   white-space: pre;
   background-color: rgb(204,204,255);
   padding: 0.5em;
   margin-left: 0;
   border: none;
   width: 97%;
}

th      { text-align: left; vertical-align: top; }
th.top  { background: rgb(0,90,156); color: white; }
th.side { background: #999999; }
td      { vertical-align: top; }
td.top  { background: #cccccc; }
td.desc { background: white; }

div.negmargn {margin-left: -65px;}
div.bnf, div.framed-bnf {
    background-color: rgb(204,204,255);
    padding: 0.5em;
    border: none;
}   

div.framed-bnf {
    border: solid black;
        border-width: 1px;
    margin-right: 5%;
    margin-top: -0.5em;
}   
div.contents {
    background-color: rgb(204,204,255);
    padding: 0.5em;
    border: none;
    margin-right: 5%;
}
div.navbar { text-align: center; }

div.framed {
    border: solid black;
        border-width: 1px;
}   

div.table, div.figure {
    background-color: rgb(255,255,204);
    border: solid black;
        border-width: 1px;
    margin-right: 5%;
    margin-top: -0.2em;
}   
div.figure {
    padding: 0.5em;
}
div.table {
    padding: 0em;
}
div.caption {
/*  background-color: rgb(204,204,204); */
    padding-left: 0.5em;
    padding-top: 0.2em;
    padding-bottom: 0.2em;
    border: none;
    margin-right: 5%;
}   
img {
        color: white;
        border: none;
}
BODY {
  margin: 2em 1em 0em 70px;
}
-->
  
</style>
    <link rel="stylesheet" type="text/css"
    href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
  </head>

  <body>
    <!--     <div class="navbar">
                            <a href="#toc">table of contents</a> 
                            <hr />
                            </div>
                            -->

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

      <h1>A P3P Preference Exchange Language 1.0 (APPEL1.0)</h1>

      <h2>W3C Working Draft 15 April 2002</h2>

      <dl>
        <dt>This version:</dt>

        <dd><a
        href="http://www.w3.org/TR/2002/WD-P3P-preferences-20020415">http://www.w3.org/TR/2002/WD-P3P-preferences-20020415</a></dd>

        <dt>Latest Version:</dt>

        <dd><a
        href="http://www.w3.org/TR/P3P-preferences">http://www.w3.org/TR/P3P-preferences</a></dd>

        <dt>Previous Version:</dt>

        <dd><a
        href="http://www.w3.org/TR/2001/WD-P3P-preferences-20010226">http://www.w3.org/TR/2001/WD-P3P-preferences-20010226</a></dd>

        <dt>Editor</dt>

        <dd><a href="http://www.inf.ethz.ch/~langhein/">Marc
        Langheinrich</a>, ETH Zurich &lt; <a
        href="mailto:langhein@inf.ethz.ch">langhein@inf.ethz.ch</a>
        &gt;</dd>

        <dt>Authors</dt>

        <dd><a href="http://www.research.att.com/~lorrie/">Lorrie
        Cranor</a>, AT&amp;T Labs-Research<br />
         <a href="http://www.inf.ethz.ch/~langhein/">Marc
        Langheinrich</a>, ETH Zurich<br />
         <a href="http://www.w3.org/People/Massimo/">Massimo
        Marchiori</a>, W3C/MIT</dd>
      </dl>

      <p class="copyright"><a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
      Copyright</a> ©2002 <a href="http://www.w3.org/"><abbr
      title="World Wide Web Consortium">W3C</abbr></a> <sup>®</sup> (
      <a href="http://www.lcs.mit.edu/"><abbr
      title="Massachusetts Institute of Technology">MIT</abbr></a> , <a
      href="http://www.inria.fr/"><abbr lang="fr"
      title="Institut National de Recherche en Informatique et Automatique">
      INRIA</abbr></a> , <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved. W3C <a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
      liability</a>, <a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
      trademark</a>, <a
      href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
      document use</a> and <a
      href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
      software licensing</a> rules apply.</p>
      <br />
       
      <hr title="Separator for header" />
    </div>

    <h2>Abstract</h2>

    <p>This document complements the <a
    href="http://www.w3.org/TR/P3P/">P3P1.0 specification</a> [<a
    href="#P3P10">P3P10</a>] by specifying a language for describing
    collections of preferences regarding P3P policies between P3P
    agents. Using this language, a user can express her preferences in
    a set of preference-rules (called a <b>ruleset</b>), which can then
    be used by her user agent to make automated or semi-automated
    decisions regarding the acceptability of machine-readable privacy
    policies from P3P enabled Web sites.</p>

    <h2>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. The latest status of this document series is maintained
    at the W3C.</em></p>

    <p>This is a W3C Working Draft of the P3P Specification Working
    Group, for review by W3C members and other interested parties. This
    document has been produced as part of the <a
    href="http://www.w3.org/Privacy/Activity.html">P3P Activity</a>,
    and may eventually be advanced toward W3C Recommendation status.
    Being a Working Draft document, this specification may be updated,
    replaced, or obsoleted by other documents at any time. It is
    therefore inappropriate to use W3C Working Drafts as reference
    material or to cite them as other than &quot;work in
    progress.&quot; A list of current W3C working drafts can be found
    at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

    <p>This Working Group has considered a number of different
    approaches to developing a P3P preference interchange language and
    has decided to document one approach and solicit feedback on it.
    The group may consider other approaches, including more
    general-purpose languages (for example, XML or RDF query
    languages). We encourage the development of experimental
    implementations and prototypes so as to provide feedback on the
    specification. However, this Working Group will not allow early
    implementations to affect their ability to make changes to future
    versions of this document.</p>

    <p>This version of the APPEL language relies on ordered rules. The
    Working Group is particulary interested in feedback on how to
    improve this mechanism in terms of better supporting merging and
    editing of rulesets. Please note that the examples in this draft
    document are based on the <a href="http://www.w3.org/TR/P3P/">16
    April 2002</a> Recommendation of the P3P Specification and that
    such examples might need to be updated should a revised version of
    the P3P Specification appear.</p>

    <p>This draft document will be considered by W3C and its members
    according to W3C process. This document is made public for the
    purpose of receiving comments that inform the W3C membership and
    staff on issues likely to affect the implementation, acceptance,
    and adoption of P3P.</p>

    <p>Comments should be sent to <a
    href="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</a>.
    This is the preferred method of providing feedback. Public comments
    and their responses can be accessed at <a
    href="http://lists.w3.org/Archives/Public/www-p3p-public-comments/">
    http://lists.w3.org/Archives/Public/www-p3p-public-comments/</a>.
    Alternatively, if you do not wish your comment to be made public,
    you can send your comment to <a
    href="mailto:p3p-comments@w3.org">p3p-comments@w3.org</a>. In
    this case, your comments will only be accessible to W3C members (at
    <a
    href="http://lists.w3.org/Archives/Member/p3p-comments/">http://lists.w3.org/Archives/Member/p3p-comments/</a>).</p>
    <hr />

    <h2 class="notoc"><a id="toc" name="toc">Contents</a></h2>

    <div class="contents">
      <ul class="toc">
        <li class="tocline">
          1. <a href="#introduction">Introduction</a> 

          <ul class="toc">
            <li class="tocline">1.1 <a href="#basics">P3P
            Basics</a></li>

            <li class="tocline">1.2 <a href="#appel">Goals of a P3P
            Preference Exchange Language</a></li>

            <li class="tocline">1.3 <a
            href="#requirements">Requirements</a></li>

            <li class="tocline">1.4 <a href="#P3Ppolicies">APPEL and
            P3P policies</a></li>

            <li class="tocline">1.5 <a
            href="#definitions">Definitions</a></li>
          </ul>
        </li>

        <li class="tocline">
          2. <a href="#operation">General Operation and Semantics</a> 

          <ul class="toc">
            <li class="tocline">2.1 <a href="#inout">Inputs and Outputs
            to the Rule Evaluator</a></li>

            <li class="tocline">
              2.2 <a href="#proc_eval">Rule Processing &amp;
              Evaluation</a> 

              <ul class="toc">
                <li class="tocline">2.2.1 <a href="#proc">Rule
                Processing</a></li>

                <li class="tocline">2.2.2 <a
                href="#expr">Expressions</a></li>

                <li class="tocline">2.2.3 <a href="#eval">Rule
                Evaluation</a></li>
              </ul>
            </li>
          </ul>
        </li>

        <li class="tocline">
          3. <a href="#example">Simple Example Scenarios</a> 

          <ul class="toc">
            <li class="tocline">3.1 <a href="#ex_prefs">User
            Preferences</a></li>

            <li class="tocline">3.2 <a href="#ex_tabs">Tabular
            Overview</a></li>

            <li class="tocline">3.3 <a href="#ex_rs">APPEL
            ruleset</a></li>

            <li class="tocline">3.4 <a href="#ex_expl">Example
            explanation</a></li>
          </ul>
        </li>

        <li class="tocline">
          4. <a href="#techdef">Technical Definition</a> 

          <ul class="toc">
            <li class="tocline">
              4.1 <a href="#syntax">Syntax &amp; Encoding</a> 

              <ul class="toc">
                <li class="tocline">4.1.1 <a href="#bnf">BNF
                Syntax</a></li>

                <li class="tocline">4.1.2 <a
                href="#transport">Transport &amp; Storage</a></li>
              </ul>
            </li>

            <li class="tocline">
              4.2 <a href="#elements">Elements</a> 

              <ul class="toc">
                <li class="tocline">4.2.1 <a
                href="#RULESET">RULESET</a></li>

                <li class="tocline">4.2.2 <a href="#RULE">RULE</a></li>

                <li class="tocline">4.2.3 <a
                href="#OTHERWISE">OTHERWISE</a></li>

                <li class="tocline">4.2.4 <a
                href="#REQUEST">REQUEST</a></li>

                <li class="tocline">4.2.5 <a
                href="#connective">connective</a></li>

                <li class="tocline">4.2.6 <a href="#p3p10policy">P3P1.0
                policy snippet</a></li>
              </ul>
            </li>
          </ul>
        </li>

        <li class="tocline">
          5. <a href="#semantics">Semantics</a> 

          <ul class="toc">
            <li class="tocline">
              5.1 <a href="#nut">The Rule Evaluator in a nutshell</a> 

              <ul class="toc">
                <li class="tocline">5.1.1 <a
                href="#nut_be">Behaviors</a></li>

                <li class="tocline">5.1.2 <a
                href="#nut_rs">Rulesets</a></li>

                <li class="tocline">5.1.3 <a
                href="#nut_ex">Expressions</a></li>
              </ul>
            </li>

            <li class="tocline">5.2 <a href="#order">Rule
            Ordering</a></li>

            <li class="tocline">5.3 <a
            href="#expressions">Expressions</a></li>

            <li class="tocline">
              5.4 <a href="#match">Matching</a> 

              <ul class="toc">
                <li class="tocline">5.4.1 <a
                href="#match_connectives">Connectives</a></li>

                <li class="tocline">5.4.2 <a
                href="#match_attr_expr">Attribute Expressions</a></li>

                <li class="tocline">5.4.3 <a
                href="#match_wild">Expression Metacharacters</a></li>

                <li class="tocline">5.4.4 <a
                href="#match_pcdata">Matching
                <code>#PCDATA</code></a></li>

                <li class="tocline">5.4.5 <a
                href="#match_dataref">Matching <code>p3p:DATA</code>
                elements</a></li>

                <li class="tocline">5.4.6 <a href="#match_cat">Category
                expansion</a></li>

                <li class="tocline">5.4.7 <a
                href="#match_optional">Matching optional data
                elements</a></li>

                <li class="tocline">5.4.8 <a
                href="#match_extension">Matching optional and mandatory
                extensions</a></li>
              </ul>
            </li>

            <li class="tocline">
              5.5 <a href="#match_sum_and_example">Matching Summary
              &amp; Examples</a> 

              <ul class="toc">
                <li class="tocline">5.5.1 <a
                href="#match_pseudocode">Matching Semantics in
                pseudocode</a></li>

                <li class="tocline">5.5.2 <a
                href="#match_algorithm">Sample Matching
                Algorithm</a></li>
              </ul>
            </li>
          </ul>
        </li>

        <li class="tocline">
          <a href="#appendices">Appendices</a> 

          <ul class="toc">
            <li class="tocline">A. <a href="#future">Future
            Work</a></li>

            <li class="tocline">B. <a href="#examples">Ruleset
            Examples</a></li>

            <li class="tocline">C. <a href="#xmlschema">XML Schema
            (normative)</a></li>

            <li class="tocline">D. <a href="#dtd">Document Type
            Definition (informative)</a></li>

            <li class="tocline">E. <a href="#abnf">ABNF Notation
            (informative)</a></li>

            <li class="tocline">F. <a href="#related">Trust Engines and
            Database Engines</a></li>

            <li class="tocline">G. <a
            href="#contrib">Contributors</a></li>
          </ul>
        </li>

        <li class="tocline"><a href="#references">References</a></li>
      </ul>
    </div>
    <hr />

    <h1><a name="introduction" id="introduction">1.
    Introduction</a></h1>

    <p>This document specifies a language for describing collections of
    preferences regarding P3P policies between P3P agents. Using this
    language, a user can express her preferences in a set of
    preference-rules (called a <b>ruleset</b>), which can then be used
    by her user agent to make automated or semi-automated decisions
    regarding the acceptability of machine-readable privacy policies
    from P3P enabled Web sites.</p>

    <p><b>Note:</b> This language is intended as a transmission format;
    individual implementations must be able to read and write their
    specifications in this language, but need not use this format
    internally.</p>

    <p>This language complements the <a
    href="http://www.w3.org/TR/P3P/">P3P1.0 specification</a> [<a
    href="#P3P10">P3P10</a>]. Much of the underlying logic is based on
    [<a href="#PICSRules">PICSRules</a>]. We hope in time that this
    will merely be an application of [<a href="#XML">XML</a>] rules or
    query languages.</p>

    <h2><a name="basics" id="basics">1.1 P3P Basics</a></h2>

    <p>P3P is designed to inform users about the privacy policies of
    services (Web sites and applications that declare privacy
    practices). When a P3P compliant client requests a resource, a
    service sends a link to a machine-readable privacy policy in which
    the organization responsible for the service declares its identity
    and privacy practices. The privacy policy enumerates the data
    elements that the service proposes to collect and explains how each
    will be used, with whom data may be shared, and how long the data
    will be retained.</p>

    <p>Policies can be parsed automatically by user agents -- such as
    Web browsers, browser plug-ins, or proxy servers -- and compared
    with privacy preferences set by the user. Depending on those
    preferences, a user agent may then simply display information for
    the user, generate prompts or take other actions.</p>

    <p>A basic P3P interaction might proceed as follows:</p>

    <ol>
      <li>The agent requests a Web page from a service.</li>

      <li>The service responds by sending a reference to a P3P
      <b>policy-reference</b> in the header of its HTTP response. A
      policy-reference file lists parts of a Web site and the URIs of
      their corresponding privacy policies. A policy consists of one or
      more statements about a service&#39;s privacy practices.</li>

      <li>The agent fetches the policy-reference file and determines
      the URI of the policy that applies to the requested page.</li>

      <li>The agent fetches the policy, evaluates it according to the
      user&#39;s <b>ruleset</b> (which represents her
      <b>preferences</b>) and determines what action to take (e.g.,
      simply informing the user about the privacy policy in place, or
      prompting her for a decision).</li>
    </ol>

    <p>In some implementations, a match between the user&#39;s
    preferences and a site&#39;s policy might authorize electronic
    wallets and other data repositories to (semi-) automatically
    release information to the service.</p>

    <h2><a name="appel" id="appel">1.2 Goals of A P3P Preference
    Exchange Language</a></h2>

    <p>The P3P1.0 specification provides a syntax for specifying
    policies and a mechansim for associating policies with Web
    resources. It does not specify requirements upon the graphical user
    interface (GUI) or <a href="#def_trustengine">trust engines</a>.
    However, there are benefits associated with being able to express
    user preferences as captured by the GUI and processed by the trust
    engine:</p>

    <ul>
      <li><b>Sharing and installation of rulesets.</b> Sophisticated
      preferences may be difficult for end-users to specify, even
      through well-crafted user interfaces. An organization can create
      a set of recommended preferences for users. Users who trust that
      organization can install a pre-defined ruleset rather than
      specifying a new set from scratch. It will be easy to change the
      active ruleset on a single computer, or to carry a ruleset to a
      new computer.</li>

      <li><b>Communication to agents, search engines, proxies, or other
      servers.</b> Servers of various kinds may wish to tailor their
      output to better meet users&#39; preferences, as expressed in a
      ruleset. For example, a search service might return only links
      that match a user&#39;s ruleset, which may specify criteria based
      on a variety of factors including quality, privacy, age
      suitability, or the safety of downloadable code.</li>

      <li><b>Portability between products.</b> The same ruleset will
      work with any P3P-APPEL enabled product.</li>
    </ul>

    <p><b>Primarily, we envision this language will be used to allow
    users to import preference rulesets created by other parties and to
    transport their own rulesets files between multiple user
    agents.</b> User agent implementors might also choose to use this
    language (or some easily-derived variation) to encode user
    preferences for use by the rule evaluators that serve as the
    decision-making components of their user agents.</p>

    <h2><a name="requirements" id="requirements">1.3
    Requirements</a></h2>

    <p>In defining the scope of the APPEL language, the working group
    generated a large list of possible requirements. The group then
    narrowed the scope to eliminate those requirements that were deemed
    less important or easier to implement if handled elsewhere. Thus,
    this draft is based on the following requirements:</p>

    <ul>
      <li>APPEL rules should allow the expression of preferences over
      anything that can be expressed in the P3P base schema as well as
      all other XML metadata relevant to P3P decision making (e.g., is
      the communication channel secured). (APPEL rules may express
      preferences over PICS labels if they are translated into an
      appropriate XML schema.)</li>

      <li>APPEL should address situations in which a service does not
      offer a P3P policy.</li>

      <li>APPEL rules should be able to prescribe the following set of
      behaviors: request, don&#39;t request, limit request. In
      addition, APPEL should include extensibility mechanisms that
      allow rules to describe additional behaviors.</li>

      <li>APPEL encoding should be consistent with other P3P work and
      leverage members&#39; existing work and code base. As much as
      possible, the encoding should be simple and support the efficient
      computation of rule matches.</li>
    </ul>

    <p>The working group limited the scope of APPEL as follows:</p>

    <ul>
      <li>APPEL rules need not allow the expression of
      &quot;sophisticated&quot; rules based on the presence of multiple
      data elements within a P3P policy (for example, a rule that would
      allow a zipcode to be collected unless a full name is also
      collected).</li>

      <li>APPEL need not be capable of expressing rules for ranking
      multiple policies. Rather it expresses the rules necessary for
      determining whether a single policy triggers a behavior. If more
      than one P3P policy is available, they should be submitted to the
      rule evaluator individually. It is up to the calling program to
      determine what to do if multiple policies are acceptable, or if a
      &quot;prompt&quot; behavior is returned while evaluating multiple
      policies.</li>

      <li>A compact or easy-to-read representation is not
      essential.</li>

      <li>APPEL need not be capable of expressing negotiation
      strategies.</li>

      <li>APPEL rules need not be able to express preferences based on
      state information (unless such information is encoded in XML and
      submitted to an APPEL engine as any other metadata would be
      submitted).</li>
    </ul>

    <p>In order to facilitate the rapid development of prototype
    implementations of the language the working group decided to first
    release a Version 1.0 specification designed to express only basic
    privacy preferences, and later prepare a more detailed
    specification that would implement the rest of the requirements
    outlined above. Specifically, APPEL <b>1.0</b> limits the
    requirements to</p>

    <ul>
      <li>only support three <a href="#def_beh_standard">standard
      behaviors</a>, <em>request</em>, <em>limited</em> (request), and
      <em>block</em> ed (request); together with an optional
      <em>prompt</em> (i.e. no custom behaviors).</li>

      <li>only support preferences over P3P policies and a limited set
      of metadata.</li>

      <li>only support restricted matching capabilities using a limited
      set of comparison operators and wildcards.</li>
    </ul>

    <p>The remainder of this document will discuss the thus restricted
    version of APPEL, refered to as the APPEL1.0 specification. See <a
    href="#future">Appendix A: Future Work</a> for a list of possible
    extensions regarding the full list of requirements given above.</p>

    <h2><a name="P3Ppolicies" id="P3Ppolicies">1.4 APPEL and P3P
    policies</a></h2>

    <p>Since APPEL rulesets are intended to express preferences over
    P3P policies, most of APPEL&#39;s synatx and semantics are very
    much influenced by the <a href="http://www.w3.org/TR/P3P/">P3P 1.0
    Specification</a>. In order to follow many of the examples in this
    draft, the working group strongly recommends that you first
    familiarize yourself with the P3P 1.0 Specification itself. This
    will also allow you to better understand the choices in syntax and
    semantics that were made in the APPEL specification.</p>

    <p>As a quick reference, the following figure shows an example
    policy that features most of the elements and attributes of an XML
    P3P 1.0 policy. Please refer to section <a
    href="http://www.w3.org/TR/P3P/#P3P_markup">3. Policy Syntax and
    Semantics</a> of the P3P 1.0 Specification for details on the
    individual elements and their usage.<br />
    </p>

    <div class="caption">
      <b>Figure 1.1:</b> P3P Example Policy
    </div>

    <div class="figure">
<pre>
&lt;POLICY xmlns=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
        discuri=&quot;http://www.example.com/ourprivacypolicy.html&quot;&gt;
  &lt;ENTITY&gt;
    &lt;DATA-GROUP&gt;
      &lt;DATA ref=&quot;#business.name&quot;&gt;CatalogExample&lt;/DATA&gt;
      &lt;DATA ref=&quot;#business.contact-info.postal.street&quot;&gt;123 Main Street&lt;/DATA&gt;
      &lt;DATA ref=&quot;#business.contact-info.postal.city&quot;&gt;Bethesda&lt;/DATA&gt;
      &lt;DATA ref=&quot;#business.contact-info.postal.stateprov&quot;&gt;MD&lt;/DATA&gt;
      &lt;DATA ref=&quot;#business.contact-info.postal.postalcode&quot;&gt;20814&lt;/DATA&gt;
      &lt;DATA ref=&quot;#business.contact-info.postal.country&quot;&gt;US&lt;/DATA&gt;
    &lt;/DATA-GROUP&gt;
  &lt;/ENTITY&gt;
  &lt;ACCESS&gt;
    &lt;nonident/&gt;
  &lt;/ACCESS&gt;
  &lt;DISPUTES-GROUP&gt;
    &lt;DISPUTES resolution-type=&quot;independent&quot; 
              service=&quot;http://www.PrivacySeal.example.org&quot; 
          short-description=&quot;PrivacySeal.example.org&quot;&gt;
      &lt;IMG src=&quot;http://www.PrivacySeal.example.org/Logo.gif&quot; 
           alt=&quot;Privacy Seal Logo&quot;/&gt;
      &lt;REMEDIES&gt;
        &lt;correct/&gt;
      &lt;/REMEDIES&gt;
    &lt;/DISPUTES&gt;
  &lt;/DISPUTES-GROUP&gt;
  &lt;STATEMENT&gt;
    &lt;CONSEQUENCE&gt;We tailor our site based on your past visits, 
                 preferences, and personal information&lt;/CONSEQUENCE&gt;
    &lt;PURPOSE&gt;
      &lt;customization/&gt;
      &lt;develop/&gt;
    &lt;/PURPOSE&gt;
    &lt;RECIPIENT&gt;
      &lt;ours/&gt;
    &lt;/RECIPIENT&gt;
    &lt;RETENTION&gt;
      &lt;stated-purpose/&gt;
    &lt;/RETENTION&gt;
    &lt;DATA-GROUP&gt;
      &lt;DATA ref=&quot;#dynamic.cookies&quot;&gt;
        &lt;CATEGORIES&gt;
          &lt;state/&gt;
        &lt;/CATEGORIES&gt;
      &lt;/DATA&gt;
      &lt;DATA ref=&quot;#dynamic.miscdata&quot;&gt;
        &lt;CATEGORIES&gt;
          &lt;preference/&gt;
        &lt;/CATEGORIES&gt;
      &lt;/DATA&gt;
      &lt;DATA ref=&quot;#user.gender&quot;/&gt;
      &lt;DATA ref=&quot;#user.home-info&quot; optional=&quot;yes&quot;/&gt;
    &lt;/DATA-GROUP&gt;
  &lt;/STATEMENT&gt;
  &lt;STATEMENT&gt;
    &lt;CONSEQUENCE&gt;We record some information in order to serve your request 
                 and to secure and improve our Web site.&lt;/CONSEQUENCE&gt;
    &lt;PURPOSE&gt;
      &lt;admin/&gt;
      &lt;develop/&gt;
    &lt;/PURPOSE&gt;
    &lt;RECIPIENT&gt;
      &lt;ours/&gt;
    &lt;/RECIPIENT&gt;
    &lt;RETENTION&gt;
      &lt;indefinitely/&gt;
    &lt;/RETENTION&gt;
    &lt;DATA-GROUP&gt;
      &lt;DATA ref=&quot;#dynamic.clickstream&quot;/&gt;
      &lt;DATA ref=&quot;#dynamic.http.useragent&quot;/&gt;
    &lt;/DATA-GROUP&gt;
  &lt;/STATEMENT&gt;
&lt;/POLICY&gt;
</pre>
    </div>

    <h2><a name="definitions" id="definitions">1.5 Definitions</a></h2>

    <p>The following definitions (in alphabetical order) reflect the
    way terms are commonly used in this document.</p>

    <dl>
      <dt><a name="def_behavior" id="def_behavior">behavior</a></dt>

      <dd>The activity taken upon the successful matching of a <a
      href="#def_rule">rule</a>. APPEL1.0 supports three <a
      href="#def_beh_standard">standard behaviors</a> (request, limited
      and block), as well as an optional <em>prompt</em>
      parameter.</dd>

      <dt><a name="def_beh_standard" id="def_beh_standard">behavior,
      standard</a></dt>

      <dd>The three behaviors that have to be supported by every APPEL
      user agent: <em>request</em>, <em>limited</em> and
      <em>block</em>. Please note that APPEL1.0 does not allow for
      custom behaviors.</dd>

      <dt><a name="def_connective"
      id="def_connective">connective</a></dt>

      <dd>An attribute of an expression that determines how any <a
      href="#def_cont_expr">contained expressions</a> will be matched.
      APPEL1.0 supports six connectives: <code>or</code>,
      <code>and</code>, <code>non-or</code>, <code>non-and</code>,
      <code>or-exact</code> and <code>and-exact</code>. See section <a
      href="#match_connectives">5.4.1 Connectives</a> for more
      details.</dd>

      <dt><a name="def_repository" id="def_repository">data
      repository</a></dt>

      <dd>A mechanism for storing user information under the control of
      the user agent.</dd>

      <dt><a name="def_evidence" id="def_evidence">evidence</a></dt>

      <dd>A P3P application provides an APPEL <a
      href="#def_ruleeval">rule evaluator</a> with an APPEL <a
      href="#def_ruleset">ruleset</a> and various pieces of
      <em>evidence</em>. This evidence for example includes the URI of
      the service and a P3P policy from the service if present.
      Evidence should be presented in the form of XML elements,
      although implementations are free to use other formats
      internally.</dd>

      <dt><a name="def_expr" id="def_expr">expression</a></dt>

      <dd>
        A component of a rule that is expressed as an XML element and
        that can be evaluated to TRUE or FALSE with respect to some
        (piece of) <a href="#def_evidence">evidence</a>. An expression
        consists of 

        <ol>
          <li>an element identifier (element name)</li>

          <li>zero or more <a href="#def_attr_expr">attribute
          expressions</a></li>

          <li>zero or more <a href="#def_cont_expr">contained
          expressions</a></li>

          <li>an optional <a href="#def_connective">connective</a></li>
        </ol>
        See sections <a href="#expressions">2.2 Expressions</a> for a
        list of expressions and <a href="#expressions">5.3
        Expressions</a> for details on how they match available <a
        href="#def_evidence">evidence</a>. Please note that APPEL1.0
        only allows for the <code>&lt;POLICY&gt;</code> and
        <code>&lt;appel:REQUEST&gt;</code> elements to be used as <a
        href="#def_top_expr">top-level expressions</a> in a rule.
      </dd>

      <dt><a name="def_attr_expr" id="def_attr_expr">expression,
      attribute</a></dt>

      <dd>An attribute-value pair contained in an <a
      href="#def_expr">expression</a>. They can be used to compare the
      values of two strings surrounded by quotes (i.e. the value of an
      attribute) or test for the presence or absence of a particular
      attribute without checking for a particular value (when used with
      wildcards). Please see section <a href="#match_attr_expr">5.4.2
      Matching Attribute Expressions</a> for more information.</dd>

      <dt><a name="def_cont_expr" id="def_cont_expr">expression,
      contained</a></dt>

      <dd>An expression that is enclosed in another expression, i.e. an
      XML element or <code>#PCDATA</code> that is enclosed in another
      (non-APPEL) XML element. In order for an expression to match,
      some or all of its contained expressions (depending on the <a
      href="#def_connective">connective</a> used) have to match as
      well. See section <a href="#expressions">5.3 Expressions</a> for
      details.</dd>

      <dt><a name="def_dege_expr" id="def_dege_expr">expression,
      degenerate</a></dt>

      <dd>An <a href="#def_expr">expression</a> that always evaluates
      to true. See section <a href="#OTHERWISE">4.2.3 The
      <code>&lt;OTHERWISE&gt;</code> element</a>.</dd>

      <dt><a id="def_top_expr" name="def_top_expr">expression,
      top-level</a></dt>

      <dd>The expressions contained immediately below an
      <code>&lt;appel:RULE&gt;</code> element. In APPEL1.0 , the
      top-level expression can only be a <code>&lt;POLICY&gt;</code> or
      <code>&lt;appel:REQUEST&gt;</code> element, or the <a
      href="#def_dege_expr">degenerate expression</a>.</dd>

      <dt><a name="def_persona" id="def_persona">persona</a></dt>

      <dd>A unique identifier for a set of data element values in the
      user&#39;s <a href="#def_repository">data repository</a> that the
      user wants to use during the current browsing session.
      Implementations could offer to store multiple values for the same
      data element and allow users to conveniently choose between
      certain sets of values when giving out information from the
      repository (e.g. a set of values to be used in the office and a a
      different set to be used on weekends).</dd>

      <dt><a name="def_preference" id="def_preference">preference</a>
      (privacy, not qualified in use)</dt>

      <dd>The user&#39;s desires regarding the collection and treatment
      of information exchanged under P3P and HTTP. Privacy preferences
      are formally expressed by a set of APPEL <a
      href="#def_rule">rules</a> and should preferably be captured
      through a GUI.</dd>

      <dt><a name="def_policy" id="def_policy">policy</a> (privacy, not
      qualified in use)</dt>

      <dd>A site&#39;s privacy practices, as expressed in its <a
      href="#def_P3Ppolicy">P3P policies</a>.</dd>

      <dt><a name="def_P3Ppolicy" id="def_P3Ppolicy">policy</a>,
      P3P</dt>

      <dd>A P3P policy is a collection of one or more privacy <a
      href="#def_statement">statements</a> together with information
      asserting the identity, URI, assurances, and disclosures of the
      service covered by the policy. The format of such a P3P policy is
      defined in the <a href="http://www.w3.org/TR/P3P/">P3P 1.0
      Specification</a></dd>

      <dt><a name="def_rule" id="def_rule">rule</a></dt>

      <dd>The formal expression of a user&#39;s preference. Rules
      express the users preferences that are then compared to a
      services <a href="#def_P3Ppolicy">P3P policy</a>. The action
      resulting from a successful match is defined by the <a
      href="#def_behavior">behavior</a> specified by the rule. The rule
      is delimited by an opening and closing element of the form<br />
       <code>&lt;appel:RULE behavior=&quot;...&quot;
      ...&gt;rule&lt;/appel:RULE&gt;</code></dd>

      <dt><a name="def_ruleeval" id="def_ruleeval">rule
      evaluator</a></dt>

      <dd>Process responsible for comparing a user&#39;s privacy <a
      href="#def_preference">preferences</a> (for example in form of an
      APPEL <a href="#def_ruleset">ruleset</a>) with a P3P <a
      href="#def_policy">policy</a> sent from a service. See also
      comments in <a href="#related">Appendic C: Trust Engines and
      Database Engines</a>.</dd>

      <dt><a name="def_ruleset" id="def_ruleset">ruleset</a></dt>

      <dd>A set of <a href="#def_rule">rules</a> that define all of the
      user&#39;s P3P <a href="#def_preference">preferences</a>.</dd>

      <dt><a name="def_schema_P3P_base"
      id="def_schema_P3P_base">schema, P3P base</a></dt>

      <dd>schema defined in the <a href="http://www.w3.org/TR/P3P/">P3P
      1.0 Specification</a>.</dd>

      <dt><a name="def_service" id="def_service">service</a></dt>

      <dd>A program that issues <a href="#def_policy">policies</a> and
      (possibly) data requests. By this definition, a service may be a
      server (site), a local application, a piece of locally active
      code, such as an ActiveX control or Java applet, or even another
      user agent. In most cases this will be a P3P-enabled Web
      server.</dd>

      <dt><a name="def_statement" id="def_statement">statement</a>,
      P3P</dt>

      <dd>A <a href="http://www.w3.org/TR/P3P/#Statements">P3P
      statement</a> is a set of privacy practice disclosures relevant
      to a collection of data elements, sets, and categories. The
      enumerated elements act as an embedded data request. A statement
      that references no data, requests no data.</dd>

      <dt><a name="def_trustengine" id="def_trustengine">trust
      engine</a></dt>

      <dd>See <a href="#def_ruleeval">rule evaluator</a>.</dd>

      <dt><a name="def_user" id="def_user">user</a></dt>

      <dd>An individual (or group of individuals acting as a single
      entity) on whose behalf a <a href="#def_service">service</a> is
      accessed and for which personal data exists.</dd>

      <dt><a name="def_user_agent" id="def_user_agent">user
      agent</a></dt>

      <dd>A program that acts on a user&#39;s behalf. The agent may act
      on preferences ( <a href="#def_rule">rules</a>) for a broad range
      of purposes, such as content filtering, trust decisions, or
      privacy. For P3P purposes, a user agent acts on a <a
      href="#def_user">user</a> &#39;s privacy preferences. Users may
      use different user agents at different times.</dd>
    </dl>

    <p>In addition, this specification uses the same words as RFC 2119
    [ <a href="#RFC2119">RFC2119</a> ] for defining the significance of
    each particular requirement. These words are:</p>

    <dl>
      <dt>MUST</dt>

      <dd>This word, or the terms &quot;REQUIRED&quot; or
      &quot;SHALL&quot;, mean that the definition is an absolute
      requirement of the specification.</dd>

      <dt>MUST NOT</dt>

      <dd>This phrase, or the phrase &quot;SHALL NOT&quot;, mean that
      the definition is an absolute prohibition of the
      specification.</dd>

      <dt>SHOULD</dt>

      <dd>This word, or the adjective &quot;RECOMMENDED&quot;, mean
      that there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.</dd>

      <dt>SHOULD NOT</dt>

      <dd>This phrase, or the phrase &quot;NOT RECOMMENDED&quot; mean
      that there may exist valid reasons in particular circumstances
      when the particular behavior is acceptable or even useful, but
      the full implications should be understood and the case carefully
      weighed before implementing any behavior described with this
      label.</dd>

      <dt>MAY</dt>

      <dd>This word, or the adjective &quot;OPTIONAL&quot;, mean that
      an item is truly optional. One vendor may choose to include the
      item because a particular marketplace requires it or because the
      vendor feels that it enhances the product while another vendor
      may omit the same item. An implementation that does not include a
      particular option MUST be prepared to interoperate with another
      implementation that does include the option, though perhaps with
      reduced functionality. In the same vein an implementation that
      does include a particular option MUST be prepared to interoperate
      with another implementation that does not include the option
      (except, of course, for the feature the option provides.)</dd>
    </dl>

    <h1><a name="operation" id="operation">2. General Operation and
    Semantics</a></h1>

    <p>The following sections give an overview of the basic operations
    of an APPEL rule evaluator.</p>

    <h2><a name="inout" id="inout">2.1 Inputs and Outputs of the Rule
    Evaluator</a></h2>

    <p>An APPEL rule evaluator is activated by a P3P application. The
    activating application provides the evaluator with various pieces
    of &quot;evidence,&quot; the <a
    href="http://www.w3.org/TR/P3P/base">P3P base data schema</a>, any
    custom data schemas referenced in the evidence, and a rule set for
    processing them. Evidence includes the URI of the service and a
    single P3P policy (together with the URI of the policy ) from the
    service if present.</p>

    <p>The scope of the rule is determined by the opening and closing
    elements of an <code>&lt;appel:RULE&gt;</code> element. The
    evaluator returns the behavior (as specified in its
    <code>behavior</code> and <code>prompt</code> attributes) of the
    rule that fired on the basis of the evidence discussed above. In
    addition, the rule evaluator may optionally return an explanation
    string (suitable for user display), a prompt message (used for
    prompting the user for a decision if necessary), the name of a
    persona, and/or the rule that fired.</p>

    <p>Applications should interpret the <em>behavior</em> outputs as
    follows:</p>

    <ul>
      <li><a name="beh_request" id="beh_request">&quot; <b>request</b>
      &quot;</a> : the provided evidence is acceptable. If a URI is
      provided, the resource at that URI SHOULD be accessed. Note that
      P3P 1.0 does not support the concept of <em>binding
      agreements</em> : Acceptance of a policy only indicates a
      corresponding user agent behavior (i.e. displaying certain
      &quot;acceptance&quot;-symbols), not a legal agreement. This
      functionality might be extended if later versions of P3P support
      this.</li>

      <li><a name="beh_limited" id="beh_limited">&quot; <b>limited</b>
      &quot;</a> : the provided evidence is somewhat acceptable. If a
      URI is provided, the resource at that URI SHOULD be accessed.
      However, the request made to access the resource SHOULD be
      limited, that is, all but absolutely necessary request headers
      should be suppressed.</li>

      <li><a name="beh_block" id="beh_block">&quot; <b>block</b>
      &quot;</a> : the provided evidence is not acceptable. If a URI is
      provided, the resource at that URI SHOULD NOT be accessed. Note
      that in some instances of the P3P 1.0 protocol, the resource URI
      might have already been accessed in order to receive a the P3P
      policy URI. In these cases it is up to the calling program to
      determine what information to present to the user.</li>
    </ul>

    <p>HTTP user agents often include a variety of non-essential
    headers with their requests. These are optional headers such as the
    <code>REFERER</code> header, and headers that may help the server
    provide a response in an appropriate language or format. P3P user
    agents that implement APPEL SHOULD, whenever feasible, limit the
    use of these non-essential headers, sending them only to sites that
    have declared them in P3P policies that trigger the request
    behavior when evaluated against the user&#39;s preferences. This
    may not always be feasible, however, if user agents need to send
    requests before a P3P policy is evaluated to prevent performance
    problems.</p>

    <p>User agents MAY wish to monitor Web forms and
    <code>set_cookie</code> requests from Web sites, to make sure they
    are consistent with the site&#39;s declared policy. Techniques for
    doing this are beyond the scope of this specification.</p>

    <p>In addition, applications should interpret the <em>prompt</em>
    attribute as follows:</p>

    <ul>
      <li>prompt = &quot; <b>no</b> &quot;: The behavior specified in
      the <em>behavior</em> attribute SHOULD be performed seamlessly,
      i.e. without soliciting input from the user. However, calling
      programs MAY still display information about rule evaluation that
      does not require user interaction (i.e. a message in the status
      bar, audio feedback, etc).</li>

      <li>prompt = &quot; <b>yes</b> &quot;: The user SHOULD be
      prompted for a decision whether the behavior triggered by the
      rule should be performed. User agents SHOULD whenever possible
      use the message contained in the corresponding <em>promptmsg</em>
      attribute of the rule when prompting the user.</li>
    </ul>

    <h2><a name="proc_eval" id="proc_eval">2.2 Rule Processing and
    Evaluation</a></h2>

    <p>The information described in the following sections is only
    intended to give a first overview. Details can be found in section
    <a href="#semantics">5 Semantics</a>, and should be referenced from
    the corresponding sections below.</p>

    <h3><a name="proc" id="proc">2.2.1 Rule Processing</a></h3>

    <p>Rules are evaluated with respect to the evidence provided. A
    rule evaluates to true if all of its enclosed expressions are
    satisfied. Basically, an expression is satisfied if <i>any</i> of
    the available evidence satisfies it.</p>

    <p>Each rule in the ruleset is evaluated in the order in which it
    appears. Once a rule evaluates to true, the corresponding behavior
    is returned and rule evaluation ends. However, in order to provide
    a comprehensive list of reasons why a particular behavior got
    triggered, user agents SHOULD continue evaluation and find
    additional rules with identical <em>behavior</em> and
    <em>prompt</em> attribute values. By having access to the combined
    list of <em>description-message</em> attribute values in all
    triggered rules, the user can get a comprehensive explanation for
    the behavior of the user agent.</p>

    <p>Rulesets should be written so that there is always a rule that
    will fire. A rule evaluator should return an error if it is called
    without a ruleset, with an empty ruleset, or if no rule fires. It
    is up to the calling program to determine what to do if an error is
    returned; however, calling programs SHOULD NOT treat an error as
    they would a &quot;request&quot; behavior without a
    <em>prompt</em>.</p>

    <p>Further information on rule processing can be found in sections
    <a href="#nut">5.1 The Rule Evaluator in a nutshell</a> and <a
    href="#order">5.2 Rules ordering</a>.</p>

    <h3><a name="expr" id="expr">2.2.2 Expressions</a></h3>

    <p>APPEL uses 3 basic types of expressions:</p>

    <ol>
      <li><span class="highlit">expression</span> : uses attribute- and
      contained-expressions to match a full XML element in the
      evidence.</li>

      <li><span class="highlit">attribute expression</span> : matches a
      single attribute and its value in an XML element.</li>

      <li><span class="highlit">contained expression</span> :
      recursively matches contained subelements and #PCDATA of an XML
      element.</li>
    </ol>

    <p>An expression in APPEL is represented by an XML element that can
    be evaluated to TRUE or FALSE by matching it against the available
    <a href="#def_evidence">evidence</a>. An expression always consists
    of (see figure 2.1 for examples):</p>

    <ol>
      <li>an element identifier (element name)</li>

      <li>zero or more <a href="#def_attr_expr">attribute
      expressions</a></li>

      <li>zero or more <a href="#def_cont_expr">contained
      expressions</a></li>

      <li>an optional <a href="#def_connective">connective</a></li>
    </ol>

    <div class="caption">
      <b>Figure 2.1:</b> Example Expressions
    </div>

    <div class="table">
      <table summary="Example expressions" border="1" cellpadding="5"
      width="100%">
        <tbody>
          <tr>
            <td>
              <small>Element name only:</small> 

              <p>
              <code>&lt;CONSEQUENCE&gt;&lt;/CONSEQUENCE&gt;</code></p>
            </td>

            <td rowspan="3" valign="top">
              <small>Element name, attributes, contained elements &amp;
              connective:</small> 

              <p><code>&lt;POLICY&gt;</code><br />
               <code>&#160; &#160; &lt;ENTITY&gt;</code><br />
               <code>&#160; &#160; &#160; &lt;DATA
              ref=&quot;#business.name&quot;&gt;</code><br />
               <code>&#160; &#160; &#160; &#160; W3C</code><br />
               <code>&#160; &#160; &#160; &lt;/DATA&gt;</code><br />
               <code>&#160; &#160; &lt;/ENTITY&gt;</code><br />
               <code>&#160; &#160; &lt;STATEMENT&gt;</code><br />
               <code>&#160; &#160; &#160; &lt;PURPOSE</code><br />
               <code>&#160; &#160; &#160; &#160;
              appel:connective=&quot;or-exact&quot;&gt;</code><br />
               <code>&#160; &#160; &#160; &#160;
              &lt;current/&gt;</code><br />
               <code>&#160; &#160; &#160; &lt;/PURPOSE&gt;</code><br />
               <code>&#160; &#160; &lt;/STATEMENT&gt;</code><br />
               <code>&lt;/POLICY&gt;</code><br />
              </p>
            </td>
          </tr>

          <tr>
            <td>
              <small>Element and attribute:</small> 

              <p><code>&lt;DISPUTES
              resolution-type=&quot;independent&quot;/&gt;</code></p>
            </td>
          </tr>

          <tr>
            <td>
              <small>Element name, contained elements and
              connective:</small> 

              <p><code>&lt;RECIPIENT appel:connective=&quot;or&quot;
              &gt;</code><br />
               <code>&#160; &lt;ours/&gt;</code><br />
               <code>&#160; &lt;same/&gt;</code><br />
               <code>&#160; &lt;delivery/&gt;</code><br />
               <code>&lt;/RECIPIENT&gt;</code><br />
              </p>
            </td>
          </tr>
        </tbody>
      </table>
    </div>

    <p>Attribute-expressions may take string or numeric values,
    although APPEL will treat all values as simple strings. APPEL1.0
    supports only the equality operator in attribute-expressions.<br />
    </p>

    <p>APPEL offers a single wildcard metacharacter &quot;*&quot; that
    closely resembles the wildcard character in many operating system
    shells. Attribute expressions can use this metacharacter to match
    ranges of values such as <code>&lt;DATA
    name=&quot;#User.*&quot;&gt;</code> (any element from the
    &quot;User&quot; data set). Contained expressions can use the
    wildcard character anywhere where <code><a
    href="http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-chardata">#PCDATA</a></code>
    (&quot;parsed character data&quot;, SGML term for character data
    that may contain both <code>&amp;entity;</code> and markup) can be
    used, i.e., between the opening and closing of a tag. Further
    details are given in sections <a href="#match_attr_expr">5.4.2
    Attribute Expressions</a>, <a href="#match_wild">5.4.3 Expression
    Metacharacters</a> and <a href="#match_pcdata">5.4.4 Matching
    <code>#PCDATA</code></a> .</p>

    <p>A special form of expression is the so called <a
    href="#def_dege_expr">degenerate expression</a>
    <code>&lt;appel:OTHERWISE&gt;</code>. Instead of matching it
    against the evidence, the rule evaluator MUST always evaluate this
    expression to true. This expression usally appears in the last rule
    of a ruleset in order to catch all possible cases that haven&#39;t
    been matched yet.<br />
    </p>

    <h3><a name="eval" id="eval">2.2.3 Rule Evaluation</a></h3>

    <p>A rule includes a behavior, an optional persona, optional
    explanation and prompt messages, and a number of <a
    href="#def_expr">expressions</a>. A rule without any expression
    always evaluates to false. A rule containing the <a
    href="#def_dege_expr">degenerate expression</a> always evaluates to
    true. Individual expressions are each composed of <a
    href="#def_attr_expr">attribute expressions</a> and <a
    href="#def_cont_expr">contained expressions</a>, and optionally
    feature a <a href="#def_connective">connective</a>.</p>

    <p>When multiple attribute expressions and/or contained expressions
    are placed within the scope of a single expression, all are matched
    within the scope of a single piece of evidence. For example, if a
    rule contains a <code>&lt;STATEMENT&gt;</code> expression that
    contains both a
    <code>&lt;PURPOSE&gt;&lt;develop/&gt;&lt;/PURPOSE&gt;</code>
    expression and a
    <code>&lt;RECIPIENT&gt;&lt;ours/&gt;&lt;/RECIPIENT&gt;</code>
    expression, then it will only evaluate to true if the P3P policy
    contains a statement that both declares local recipients and a
    research &amp; development purpose. If both expressions are
    satisfied, but only in separate statements, then the expression
    evaluates to false.</p>

    <p>While attribute expressions within an expression are implicitly
    ANDed together, a special <a
    href="#def_connective"><code>connective</code></a> attribute is
    used to govern the matching semantics of <a
    href="#def_cont_expr">contained expressions</a>. APPEL supports six
    such connectives: <em>or</em>, <em>and</em>, <em>non-or</em>,
    <em>non-and</em> ¸ <em>or-exact</em>, and <em>and-exact</em>. If no
    connective is given, APPEL defaults to requiring <em>and</em>
    matches: only if all of the elements in the evidence can be found
    in the rule (additional elements are ignored), a match is
    triggered.</p>

    <p>The matching of attribute and contained expressions is described
    in more detail in section <a href="#match">5.4 Matching</a>.</p>

    <h1><a name="example" id="example">3 Simple Example
    Scenario</a></h1>

    <p>In the following section we will describe a simple APPEL
    preference file in order to introduce the different elements of the
    APPEL language and illustrate their usage. Although the example is
    a well formed APPEL ruleset (i.e. it is enclosed in an <code><a
    href="#RULESET">&lt;appel:RULESET&gt;</a></code> element), it is
    only used to demonstrate a small set of example rules.</p>

    <p>We will start with a plain text description of the user&#39;s
    (admittedly simple) preferences, followed by a tabular overview of
    the involved elements and their allowed values. Finally, we will
    give an example of the corresponding APPEL encoding. Note that each
    listing in this document features line numbers for ease of
    reference; they are not part of the actual encoding!<br />
    </p>

    <h2><a name="ex_prefs" id="ex_prefs">3.1 User Preferences</a></h2>

    <ol>
      <li>Requests for personal information that will be given out to
      3rd parties should be blocked.</li>

      <li>The user does not mind revealing click-stream and user agent
      information to sites that collect no other information. However,
      she insists that the service provides some form of
      assurance.</li>

      <li>The user is comfortable with giving out her first and last
      name, as long as it is for non-marketing purposes. She requires
      assurances (i.e., dispute information) from both
      &quot;PrivacyProtect and &quot;TrustUs&quot; before trusting such
      a statement. However, she always wants to be explicitly informed
      about such cases before actually accessing such a page.</li>

      <li>When interacting with her bank&#39;s Web site at
      <code>http://www.my-bank.com</code>, she accepts any data request
      as long as her data is not redistributed to other
      recipients.</li>

      <li>All other requests for data transfer should be prompted for
      (indicating a conflict with her privacy preferences) and will be
      decided by the user on a site-by-site basis.</li>
    </ol>

    <h2><a name="ex_tabs" id="ex_tabs">3.2 Tabular Overview</a></h2>

    <p>The following table describes the fields the user is referencing
    in her privacy preferences, together with the matching conditions
    and actions that should be taken (Please refer to the <a
    href="http://www.w3.org/TR/P3P/#Base_Data_Schema">Base data
    elements and sets</a> as well as the <a
    href="http://www.w3.org/TR/P3P/#encoding">XML encoding of a
    policy</a>, defined in the <a href="http://www.w3.org/TR/P3P/">P3P
    1.0 Specification</a> for the list of fields referenced). Do not
    try to use it as a lookup table for finding a behavior, given a
    list of attributes/elements and their values. Instead one has to
    step through the table row by row until the values referenced in
    the table match. This is because each row represents an ordered
    rule in our ruleset.</p>

    <p>Please note that some of the cells feature a wildcard symbol
    &quot;*&quot;, while others are empty. APPEL <a
    href="#match_attr_expr">distinguishes</a> between non-referenced
    attributes and those that are referenced but contain only
    wildcards. In the former case, the user truly does not care about
    the attribute, even whether it is included in the policy or not. In
    the latter case, the user might not care about the attributes
    value, but at least expects it to have <em>some</em> value. For
    further details see section <a href="#match_wild">5.4.3 Expression
    Metacharacters</a>. In row two of our example below, the user does
    not care about the <em>purpose</em> of the collected clickstream
    data (hence the empty fields in the table), but requires that
    <em>some</em> form of <em>dispute</em> -information is present
    (represented by a wildcard &quot;*&quot; character).<br />
    </p>

    <div class="negmargn">
      <table summary="Tabular overview of example preferences"
      border="1" cellpadding="2" width="100%">
        <tbody>
          <tr>
            <td><b>Behavior /<br />
             Prompt</b> </td>

            <td><b><a
            href="http://www.w3.org/TR/P3P/#Base_Data_Schema">Element/Set</a></b>
            </td>

            <td><b><small><a href="#REQUEST">URI</a></small></b> </td>

            <td><b><small><a
            href="http://www.w3.org/TR/P3P/#DISPUTES">Disputes</a></small></b>
            </td>

            <td><b><small><a
            href="http://www.w3.org/TR/P3P/#PURPOSE">Purpose</a></small></b>
            </td>

            <td><b><small><a
            href="http://www.w3.org/TR/P3P/#RECPNT">Recipient</a></small></b>
            </td>
          </tr>

          <tr>
            <td>block /<br />
             no</td>

            <td>category=&quot;physical&quot;, or<br />
             category=&quot;demographic&quot;, or<br />
             category=&quot;uniqueid&quot;</td>

            <td>&#160;</td>

            <td>&#160;</td>

            <td>&#160;</td>

            <td>same, other,<br />
             delivery, public<br />
             or unrelated</td>
          </tr>

          <tr>
            <td>request /<br />
             no</td>

            <td>dynamic.http.useragent, dynamic.clickstream.server</td>

            <td>&#160;</td>

            <td>*</td>

            <td>&#160;</td>

            <td>&#160;</td>
          </tr>

          <tr>
            <td>request /<br />
             yes</td>

            <td>user.name.*</td>

            <td>&#160;</td>

            <td>&quot;PrivacyProtect&quot; and &quot;TrustUs&quot;</td>

            <td>current, admin, customization or develop</td>

            <td>&#160;</td>
          </tr>

          <tr>
            <td>request /<br />
             no</td>

            <td>&#160;</td>

            <td><small>www.my-bank.com</small> </td>

            <td>&#160;</td>

            <td>&#160;</td>

            <td>ours</td>
          </tr>

          <tr>
            <td>limited /<br />
             yes</td>

            <td>[otherwise]</td>

            <td>&#160;</td>

            <td>&#160;</td>

            <td>&#160;</td>

            <td>&#160;</td>
          </tr>
        </tbody>
      </table>
    </div>

    <h2><a name="ex_rs" id="ex_rs">3.3 APPEL ruleset</a></h2>

    <p>The following listing illustrates one way to encode the above
    preferences into an APPEL ruleset. Five rules are used to handle
    all incoming policies from a service. A <em>block</em> -rule (i.e.,
    a rule with the string &quot;block&quot; in its
    <code>behavior</code> attribute) first rejects any policies asking
    for identifiable data that is distributed to 3rd parties.</p>

    <p>Using an explicit match for the request URL, a second rule then
    accepts a policy if, when connecting to
    <code>www.my-bank.com</code>, the requested data is only
    distributed to the bank and its agents.</p>

    <p>Next, a &quot;request&quot; rule checks to see if only
    non-identifiable clickstream data and/or user agent information
    (such as browser version, operating system, etc) is collected, and
    seamlessly continues to request the resource if dispute information
    is available.</p>

    <p>A &quot;request&quot; rule featuring a
    <em>prompt=&quot;yes&quot;</em> attribute then matches any requests
    for the user&#39;s name for non-marketing purposes and eventually
    initiates a prompt informing the user that a site wants to collect
    her name under acceptable circumstances.</p>

    <p>If none of the other rules matches, a &quot;limited&quot;-rule
    (again using a <em>prompt=&quot;yes&quot;</em> attribute)
    encapsulating the <a href="#def_dege_expr">degenerate
    expression</a> &quot; <a href="#OTHERWISE">appel:OTHERWISE</a>
    &quot; will fire, prompting the user to (cautiously) decide on any
    policy that has not been covered by any of the rules above, while
    using only the absolutely required headers to make the request, if
    at all.<br />
    </p>

    <div class="caption">
      <b>Figure 3.1:</b> Simple Ruleset in APPEL1.0
    </div>

    <div class="figure">
<pre>
001: &lt;appel:RULESET
xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; 
002:                xmlns:p3p=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
003:                crtdby=&quot;W3C&quot; crtdon=&quot;1999-11-03T09:21:32-05:00&quot;&gt;

004:   &lt;appel:RULE behavior=&quot;block&quot; description=&quot;Service collects personal
005:                   data for 3rd parties&quot;&gt;
006:     &lt;p3p:POLICY&gt;
007:       &lt;p3p:STATEMENT&gt;
008:         &lt;p3p:DATA-GROUP&gt;
009:           &lt;p3p:DATA&gt;
010:             &lt;p3p:CATEGORIES appel:connective=&quot;or&quot;&gt;
011:               &lt;p3p:physical/&gt;
012:               &lt;p3p:demographic/&gt;
013:               &lt;p3p:uniqueid/&gt;
014:             &lt;/p3p:CATEGORIES&gt;
015:           &lt;/p3p:DATA&gt;
016:         &lt;/p3p:DATA-GROUP&gt;
017:         &lt;p3p:RECIPIENT appel:connective=&quot;or&quot;&gt;
018:           &lt;p3p:same/&gt;
019:           &lt;p3p:other-recipient/&gt;
020:           &lt;p3p:public/&gt;
021:           &lt;p3p:delivery/&gt;
022:           &lt;p3p:unrelated/&gt;
023:         &lt;/p3p:RECIPIENT&gt;
024:       &lt;/p3p:STATEMENT&gt;
025:     &lt;/p3p:POLICY&gt;
026:   &lt;/appel:RULE&gt;

027:   &lt;appel:RULE behavior=&quot;request&quot; 
028:               description=&quot;My Bank collects data only for itself 
029:                            and its agents&quot;&gt;
030:     &lt;appel:REQUEST-GROUP&gt;
031:       &lt;appel:REQUEST uri=&quot;http://www.my-bank.com/*&quot;/&gt;
032:     &lt;/appel:REQUEST-GROUP&gt;
033:     &lt;p3p:POLICY&gt;
034:       &lt;p3p:STATEMENT&gt;
035:         &lt;p3p:RECIPIENT appel:connective=&quot;or-exact&quot;&gt;
036:           &lt;p3p:ours/&gt;
037:         &lt;/p3p:RECIPIENT&gt;
038:       &lt;/p3p:STATEMENT&gt;
039:     &lt;/p3p:POLICY&gt;
040:   &lt;/appel:RULE&gt;

041:   &lt;appel:RULE behavior=&quot;request&quot; 
042:               description=&quot;Service only collects clickstream data&quot;&gt;
043:     &lt;p3p:POLICY&gt;
044:       &lt;p3p:STATEMENT&gt;
045:         &lt;p3p:DATA-GROUP appel:connective=&quot;or-exact&quot;&gt;
046:           &lt;p3p:DATA ref=&quot;#dynamic.http.useragent&quot;/&gt;
047:           &lt;p3p:DATA ref=&quot;#dynamic.clickstream.server&quot;/&gt;
048:         &lt;/p3p:DATA-GROUP&gt;
049:       &lt;/p3p:STATEMENT&gt;
050:       &lt;p3p:DISPUTES-GROUP&gt;
051:         &lt;p3p:DISPUTES service=&quot;*&quot;/&gt;
052:       &lt;/p3p:DISPUTES-GROUP&gt;
053:     &lt;/p3p:POLICY&gt;
054:   &lt;/appel:RULE&gt;

055:   &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
056:               promptmsg=&quot;Service only collects your name
057:                            for non-marketing purposes (assured)

058:                            Do you want to continue?&quot;&gt;
059:     &lt;p3p:POLICY&gt;
060:       &lt;p3p:STATEMENT&gt;
061:         &lt;p3p:PURPOSE appel:connective=&quot;or-exact&quot;&gt;
062:           &lt;p3p:current/&gt;
063:           &lt;p3p:admin/&gt;
064:           &lt;p3p:customization/&gt;
065:           &lt;p3p:develop/&gt;
066:         &lt;/p3p:PURPOSE&gt;
067:         &lt;p3p:DATA-GROUP appel:connective=&quot;or-exact&quot;&gt;
068:           &lt;p3p:DATA ref=&quot;#user.name.*&quot;/&gt;
069:         &lt;/p3p:DATA-GROUP&gt;
070:       &lt;/p3p:STATEMENT&gt;
071:       &lt;p3p:DISPUTES-GROUP&gt;
072:         &lt;p3p:DISPUTES service=&quot;http://www.privacyprotect.com&quot;/&gt;
073:         &lt;p3p:DISPUTES service=&quot;http://www.trustus.org&quot;/&gt;
074:       &lt;/p3p:DISPUTES-GROUP&gt;
075:     &lt;/p3p:POLICY&gt;
076:   &lt;/appel:RULE&gt;

077:   &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
078:     promptmsg=&quot;Suspicious Policy.  Do you want to continue (limited access)?&quot;&gt;
079:     &lt;appel:OTHERWISE/&gt;
080:   &lt;/appel:RULE&gt;

081: &lt;/appel:RULESET&gt;
</pre>
    </div>

    <h2><a name="ex_expl" id="ex_expl">3.4 Example Explanation</a></h2>

    <p>Using the line numbers in the example above, we will briefly
    explain the basic structure of an APPEL ruleset.<br />
    </p>

    <div class="framed">
      <table summary="Example explanation" border="0" cellpadding="5">
        <tbody>
          <tr>
            <th align="left">Lines</th>

            <th align="left">Explanation</th>
          </tr>

          <tr>
            <td valign="top">000&#160;- 081</td>

            <td valign="top">
              <em>APPEL ruleset</em>. Usually a single APPEL ruleset
              (i.e., a set of ordered <a href="#RULE">rules</a>
              enclosed in an <code><a
              href="#RULESET">&lt;appel:RULESET&gt;</a></code> tag) is
              installed in a user agent. Implementations might offer to
              hold different rulesets depending on the current user of
              the system, or on the persona the user wants to use
              during the current browsing session. The <code><a
              href="#RULESET">&lt;appel:RULESET&gt;</a></code> element
              can be tagged with additional information such as author
              or date of creation: 

              <div class="bnf">
<pre>
[1] ruleset = &#39;&lt;appel:RULESET 
                 xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; &#39;
                 common-attributes &#39;&gt;&#39;
                 rseq
              &#39;&lt;/appel:RULESET&gt;&#39;
 
[2] rseq    = 1*rule
</pre>
              </div>
            </td>
          </tr>

          <tr>
            <td valign="top">004 - 026</td>

            <td valign="top">
              <em>&quot;block&quot; rule</em>. APPEL offers three
              distinct kinds of <a href="#def_behavior">behaviors</a>
              for rules: <a
              href="#beh_request">&quot;request&quot;</a>, <a
              href="#beh_block">&quot;block&quot;</a>, and <a
              href="#beh_limited">&quot;limited&quot;</a>, each of
              which can optionally prompt the user (
              <code>prompt=&quot;yes&quot;</code>). Each rule consists
              of an <code><a href="#RULE">&lt;appel:RULE&gt;</a></code>
              element surrounding a set of expressions or the <a
              href="#def_dege_expr">degenerate expression</a> <code><a
              href="#OTHERWISE">&lt;appel:OTHERWISE&gt;</a></code> . 

              <div class="bnf">
<pre>
[3] rule     = &#39;&lt;appel:RULE behavior=&quot;&#39; behavior &#39;&quot;&#39;
                  common-attributes
                  rule-attributes
                  [connective] &#39;&gt;&#39;
                      body
               &#39;&lt;/appel:RULE&gt;&#39;

[7] behavior = &#39;request&#39; | &#39;block&#39; | &#39;limited&#39;
</pre>
              </div>

              <p>Each rule can be augmented by a set of attributes. In
              our example we use the description field to supply a
              human readable explanation (&quot;Service only collects
              clickstream data&quot;) in case the rule should fire
              (this could be displayed by the user agent during data
              transfer, or could be used for debugging purposes). In
              case we want the rule to prompt the user for a decision,
              a separate prompt message attribute
              (<code>promptmsg</code>) allows the specification of an
              apropriate question.</p>

              <div class="bnf">
<pre>
[4] common-attributes = [&#39; crtdby=&#39; quoted-string]
                        [&#39; crtdon=&quot;&#39; datetime &#39;&quot;&#39;]
                        [&#39; description=&#39; quoted-string]

[5] rule-attributes   = [&#39; prompt =&quot;&#39; (&#39;yes&#39;|&#39;no&#39;) &#39;&quot;&#39;] 
                        [&#39; persona=&#39; quoted-string]
                        [&#39; promptmsg=&#39; quoted-string]
</pre>
              </div>
            </td>
          </tr>

          <tr>
            <td valign="top">006 - 025</td>

            <td valign="top">
              <em>P3P Policy to match</em>. Most APPEL rules have a P3P
              policy as the matching expression inside a
              <code>&lt;RULE&gt;</code> element. Elements and attribute
              values that the rule should match on are simply spelled
              out in the policy, while wildcards (&quot;*&quot;) are
              used to match a range of values. Omitting an attribute or
              element completely allows the attribute/element to be
              missing from the policy supplied by the service (or to be
              included with any value). 

              <div class="bnf">
<pre>
[8] top-expression = policy | request-group [policy]

[9] policy         = &lt;[<a
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)&gt; 

[10] request-group = &#39;&lt;appel:REQUEST-GROUP &#39; [connective] &#39;&gt;&#39;
                          1*request
                     &#39;&lt;/appel:REQUEST-GROUP&gt;&#39;

[11] request       = &#39;&lt;appel:REQUEST uri=&quot;&#39; [<a
href="#URI">URI</a>] as per <a
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>&#39;&quot;/&gt;&#39;
</pre>
              </div>
            </td>
          </tr>

          <tr>
            <td valign="top">007 - 024</td>

            <td valign="top"><em>STATEMENT element match</em>. The
            &quot;block&quot; rule should fire (i.e. reject the policy)
            if the service asks for personal data (
            <code>&lt;DATA&gt;</code> elements in the categories
            <code>physical</code>, <code>demographic</code> or
            <code>uniqueid</code>) that is distributes to 3rd parties (
            <code>&lt;RECIPIENT&gt;</code> matching
            <code>&lt;same/&gt;</code>,
            <code>&lt;other-recipient/&gt;</code> &quot; or
            <code>&lt;published/&gt;</code>). Note that rules do not
            always feature <em>all</em> required elements of a P3P
            policy. Given that both the <code>&lt;DATA&gt;</code> and
            <code>&lt;RECIPIENT&gt;</code> element match, this block
            rule will match regardless of the <a
            href="http://www.w3.org/TR/P3P/#PURPOSE">purpose</a> (
            <code>&lt;PURPOSE&gt;</code>) specified in the policy.</td>
          </tr>

          <tr>
            <td valign="top">010, 017, ...</td>

            <td valign="top">
              <em>Connectives.</em> Using the
              <code>appel:connective</code> attribute, the rule author
              can explictly specify different matching semantics for
              the contained expressions of an element. APPEL supports
              six different connectives ( <code>or</code>,
              <code>and</code>, <code>non-or</code>,
              <code>non-and</code>, <code>or-exact</code> and
              <code>and-exact</code>) that implement different matching
              semantics. If no connective is given, the default
              matching semantics require an <em>and</em> match between
              the rule and the available evidence. 

              <div class="bnf">
<pre>
[12] connective      = &#39;appel:connective=&quot;&#39; conn &#39;&quot;&#39;

[13] conn            = or | and | non-or | non-and | or-exact | and-exact
</pre>
              </div>
            </td>
          </tr>

          <tr>
            <td valign="top">027 - 040</td>

            <td valign="top"><em>Restricted request-rule</em>. This
            &quot;request&quot; rule only continues to match the policy
            if it has been fetched while requesting a Web resource from
            <code>www.my-bank.com</code>. This is because of the
            additional <a
            href="#REQUEST"><code>&lt;appel:REQUEST&gt;</code></a>
            element in the rule body, which evaluates to false unless
            the user agent is currently requesting a resource from the
            uri listed in the element. This allows users to easily
            write rules that only apply to policies from a restricted
            set of domains.</td>
          </tr>

          <tr>
            <td valign="top">041 - 054</td>

            <td valign="top"><em>request</em>. The &quot;request&quot;
            rule should only continue to request the resource if the
            policy sent by the service at most declares the collection
            of user agent and/or clickstream data. Note that the <a
            href="http://www.w3.org/TR/P3P/#PURPOSE">purpose</a> (
            <code>&lt;PURPOSE&gt;</code>) and <a
            href="http://www.w3.org/TR/P3P/#RECPNT">recipient
            element</a> ( <code>&lt;RECIPIENT&gt;</code>) <em>do
            not</em> have to appear in the rule, even though they are
            required in a P3P policy statement.</td>
          </tr>

          <tr>
            <td valign="top">046 - 047</td>

            <td valign="top"><em>Data Elements to match</em>. Because
            of the use of the &quot; <code>or-exact</code> &quot;- <a
            href="#def_connective">connective</a>, the
            &quot;request&quot; rule will only match if the statement
            in the policy does not contain any <em>additional</em> data
            references <em>not</em> contained in the rule.
            Consequently, a policy requesting any other element than
            the ones explicitly enumerated in between lines 45 and 48
            of the ruleset would immediately evaluate the expression to
            <em>false</em> (i.e. <em>not</em> accepting the
            policy).</td>
          </tr>

          <tr>
            <td valign="top">050 - 052</td>

            <td valign="top"><em>DISPUTE-resolution information to
            match</em>. The user wants to make sure that the service
            included a reference to an organization that can provide
            assurance about its privacy policy in case disputes should
            arise.</td>
          </tr>

          <tr>
            <td valign="top">055 - 076</td>

            <td valign="top"><em>&quot;prompt and request&quot;
            rule</em>. Although the user agrees to releasing her name
            for non-marketing purposes to Web Sites that have
            assurances from both TrustUs <i>and</i> PrivacyProtect, she
            wants to supervise each individual data transfer.
            Implementations might offer User Interfaces that allow
            users to explicitly accept all subsequent data transfers to
            a particular site, effectively prompting the user only for
            her first visit to a new site.</td>
          </tr>

          <tr>
            <td valign="top">010, 017, 028, ...</td>

            <td valign="top"><em>Matching a list of alternatives</em>.
            In order to match a number of different purposes or
            recipients, we use either the &quot;or&quot; or the
            &quot;or-exact&quot; connective and enclose a list of valid
            alternatives recipients and purposes elements. If a number
            of alternatives should <em>not</em> be matched, the
            &quot;non-or&quot; connective can be used.</td>
          </tr>

          <tr>
            <td valign="top">071 - 074</td>

            <td valign="top"><em>Matching conjunctive values</em>. In
            order to require both assurances from TrustUs <i>and</i>
            PrivacyProtect in the policy, the rule lists the same
            element ( <code>&lt;DISPUTES&gt;</code>) multiple times
            (but with different values in their attributes). Because of
            the implied &quot;and&quot; connective (this is the default
            connective if no <code>appel:connective</code> attribute is
            given) in the enclosing <code>DISPUTES-GROUP</code>
            element, this represents a logical AND between the
            values.</td>
          </tr>

          <tr>
            <td valign="top">077 - 080</td>

            <td valign="top"><em>&quot;limited&quot; rule</em>. Since
            rules in an APPEL ruleset are ordered, the
            &quot;limited&quot; rule only gets evaluated should all
            preceding rules fail to match the policy sent by the
            publisher. If we would reverse the order of our rules (i.e.
            putting the <code>&lt;OTHERWISE&gt;</code> rule at the
            top), our user agent would always issue a prompt for all
            incoming policies (see comment below).</td>
          </tr>

          <tr>
            <td valign="top">079</td>

            <td valign="top">
              <em>Degenerate Expression</em>. Using the degenerate
              expression <code>&lt;OTHERWISE&gt;</code>, we can create
              &quot;catch-all&quot; rules that are always known to
              evaluate to true. Rules containing
              <code>&lt;OTHERWISE&gt;</code> should usually be placed
              at the end of a ruleset, since all following rules will
              never be evaluated. Note that empty rules never match
              anything. 

              <p>Rulesets should be written so that for any possible
              evidence set, there is always a rule that will fire.
              Thus, if no rule fires, the rule evaluator should return
              an error.</p>
            </td>
          </tr>
        </tbody>
      </table>
    </div>

    <h1><a name="techdef" id="techdef">4. Technical Definition</a></h1>

    <p>The following syntax must be used for implementations to be
    compliant. In addition, compliant applications must process rules
    according to the semantics defined in section <a href="#match">5.4
    Matching Semantics</a>.</p>

    <h2><a name="syntax" id="syntax">4.1 Syntax &amp; Encoding</a></h2>

    <p>This section lists the exact syntax used for the APPEL1.0
    language, as well as encoding issues.</p>

    <h3><a name="bnf" id="bnf">4.1.1 BNF Syntax, APPEL1.0
    (non-normative)</a></h3>

    <p>The BNF syntax below is just an informal representation of the
    actual syntax. Please refer to <a href="#xmlschema">Appendix C: XML
    Schema</a> for the normative description of the APPEL syntax.
    Detailed explanations can be found in section <a
    href="#elements">4.2 Elements</a>.<br />
    </p>

    <div class="caption">
      <b>Figure 4.1:</b> APPEL1.0 BNF Syntax (informative)
    </div>

    <div class="framed-bnf">
<pre>
[1] ruleset          = &#39;&lt;appel:RULESET 
                          xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; &#39;
                          common-attributes &#39;&gt;&#39;
                          rseq
                       &#39;&lt;/appel:RULESET&gt;&#39;
      
[2] rseq             =  1*rule 

[3] rule             = &#39;&lt;appel:RULE behavior=&quot;&#39; behavior &#39;&quot;&#39;
                         common-attributes
                         rule-attributes
                         [connective] &#39;&gt;&#39;
                            body
                       &#39;&lt;/appel:RULE&gt;&#39;

[4] common-attributes= [&#39; crtdby=&#39; quoted-string]
                       [&#39; crtdon=&quot;&#39; datetime &#39;&quot;&#39;]
                       [&#39; description=&#39; quoted-string]

[5] rule-attributes  = [&#39; prompt =&quot;&#39; (&#39;yes&#39;|&#39;no&#39;) &#39;&quot;&#39;]
                       [&#39; persona=&#39; quoted-string]
                       [&#39; promptmsg=&#39; quoted-string]

[6] body             = top-expression | &#39;&lt;appel:OTHERWISE/&gt;&#39;

[7] behavior         = &#39;request&#39; | &#39;block&#39; | &#39;limited&#39;

[8] top-expression   = policy | request-group [policy]

[9] policy           = &lt;[<a
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)&gt; 

[10] request-group   = &#39;&lt;appel:REQUEST-GROUP &#39; [connective]&#39;&gt;&#39;
                          1*request
                       &#39;&lt;/appel:REQUEST-GROUP&gt;&#39;

[11] request         = &#39;&lt;appel:REQUEST uri=&quot;&#39; [<a
href="#URI">URI</a>] as per <a
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>&#39;&quot;&gt;&#39;

[12] connective      = &#39;appel:connective=&quot;&#39; conn &#39;&quot;&#39;

[13] conn            = or | and | non-or | non-and | or-exact | and-exact

[14] quoted-string   = &#39;&quot;&#39; string &#39;&quot;&#39;

[15] string          = &lt;[<a
href="#utf8">UTF-8</a>] string (with &quot; and &amp; escaped)&gt;

[16] datetime        = &lt;date/time as per  [<a
href="#bib_iso8601">ISO8601</a>] or section 3.3.1 in [<a
href="#RFC2616">RFC2616</a>]&gt;      
</pre>
    </div>

    <p>Details are described in section <a href="#elements">4.2
    Elements</a> below. Please see also <a href="#future">Appendix A:
    Future Work</a>.</p>

    <h3><a name="transport" id="transport">4.1.2 Transport &amp;
    Storage</a></h3>

    <p>APPEL rulesets are represented as XML documents, following the
    same character set conventions as generic XML. Legal characters are
    tab, carriage return, line feed, and the legal graphic characters
    of Unicode and ISO/IEC 10646. For further details see the <a
    href="http://www.w3.org/TR/1998/REC-xml-19980210#charencoding">character
    encoding</a> section in the <a
    href="http://www.w3.org/TR/1998/REC-xml-19980210">XML
    Recommendation</a>. Note that in XML documents both element and
    attribute names are <em>case-sensitive</em>. All element names in
    APPEL are in uppercase, while attributes are using all lowercase.
    The P3P uses a similar convention, so it should be a uniform format
    even for P3P policies. However, please refer to <a
    href="http://www.w3.org/TR/P3P/">the latest P3P Specification</a>
    for a normative definition of case in P3P elements.</p>

    <p>In contrast to P3P policies, APPEL rulesets are not intended to
    be exchanged in real time by special means such as an HTTP protocol
    extension. Instead, they should be treated and downloaded like
    simple files, using any means available depending on the hard- and
    software setup in use.</p>

    <p>Internally, user agents may use any convenient encoding of a
    user&#39;s ruleset (e.g. in binary form), as long as they provide
    methods to synchronize a user&#39;s plain text ruleset file with
    its internal representation.</p>

    <h2><a name="elements" id="elements">4.2 Elements</a></h2>

    <p>This section describes the elements that are used to create an
    APPEL ruleset. Each element is given in <code>&lt;&gt;</code>
    brackets, followed by the list of attributes that can appear in the
    element. All listed attributes are optional, except when tagged as
    <em>mandatory</em>. For more information on the actual usage of
    these elements, please refer to section <a href="#semantics">5.
    Semantics</a> as well as section <a href="#example">3. Simple
    Example Scenario</a>.</p>

    <h3><a name="RULESET" id="RULESET">4.2.1 The
    <code>&lt;appel:RULESET&gt;</code> element</a></h3>

    <dl>
      <dt><code>&lt;appel:RULESET&gt;</code></dt>

      <dd>This tag is the delimiter that denotes an APPEL file. It
      includes a sequence of one or more rules. Each rule features a
      certain behavior that is returned to the calling program if the
      expressions listed in the rule all evaluate to <b>true</b>.</dd>

      <dt><code>crtdby</code></dt>

      <dd>Name or ID of the ruleset author (could be the user
      agent).</dd>

      <dt><code>crtdon</code></dt>

      <dd>Time &amp; Date of ruleset creation.</dd>

      <dt><code>description</code></dt>

      <dd>A short natural language explanation that can be displayed by
      the user agent when the ruleset gets selected, or to help
      debugging a rulefile.</dd>
    </dl>

    <div class="bnf">
<pre>
[1] ruleset          = &#39;&lt;appel:RULESET 
                          xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; &#39;
                          common-attributes &#39;&gt;&#39;
                          rseq
                       &#39;&lt;/appel:RULESET&gt;&#39;
 
[2] rseq             =  1*rule 

[4] common-attributes= [&#39; crtdby=&#39; quoted-string]
                       [&#39; crtdon=&quot;&#39; datetime &#39;&quot;&#39;]
                       [&#39; description=&#39; quoted-string]
</pre>
    </div>

    <h3><a name="RULE" id="RULE">4.2.2 The
    <code>&lt;appel:RULE&gt;</code> element</a></h3>

    <dl>
      <dt><code>&lt;appel:RULE&gt;</code></dt>

      <dd>Contains conditions under which a certain behavior should be
      carried out by the calling program.</dd>

      <dt><code>behavior</code> &#160; &#160; <em>(mandatory
      attribute)</em></dt>

      <dd>Behavior that should be carried out by the calling program if
      the expressions match the evidence.</dd>

      <dt><code>connective</code></dt>

      <dd>Allows for different matching semantics of enclosed
      subelements. See section <a href="#connective">4.2.5 The
      <code>appel:connective</code> attribute</a> below.</dd>

      <dt><code>crtdby</code></dt>

      <dd>Name or ID of the rule author (could be the user agent).</dd>

      <dt><code>crtdon</code></dt>

      <dd>Time &amp; Date of rule creation.</dd>

      <dt><code>description</code></dt>

      <dd>A short natural language explanation that can be displayed by
      the user agent when the rule gets executed, or to help debugging
      a rulefile. Note that a separate <code>promptmsg</code> should be
      used in case the user should be prompted for a decision.</dd>

      <dt><code>prompt</code></dt>

      <dd>Indicates whether a prompt message should be displayed to the
      user. If this attribute is not present, no prompt message is
      displayed.</dd>

      <dt><code>persona</code></dt>

      <dd>If the user agent supports multiple user repositories, this
      string identifies the data repository that should be used in case
      the resource is accessed (i.e. if the rule that fires features a
      &quot;request&quot; or &quot;limited&quot; behavior, or if a
      &quot;block&quot; rule is overridden at the prompt). If no
      persona is given, the user agent&#39;s default value is
      used.</dd>

      <dt><code>promptmsg</code></dt>

      <dd>A short natural language explanation or question that can be
      displayed by the user agent when the user should be prompted for
      a decision. Note that the <code>description</code> field can be
      used to hold a brief summary of the rule for debugging or
      informational purposes.</dd>
    </dl>

    <p>A rule that only contains a <code>&lt;POLICY&gt;</code> element,
    but no <code>&lt;appel:REQUEST&gt;</code> element, will try to
    match policies on <em>any</em> site. A rule that contains both a
    <code>&lt;POLICY&gt;</code> element <em>and</em> an
    <code>&lt;appel:REQUEST&gt;</code> element will only match policies
    at sites that match the URI given in the
    <code>&lt;appel:REQUEST&gt;</code> element. A rule that only
    contains an <code>&lt;appel:REQUEST&gt;</code> element, but no
    <code>&lt;POLICY&gt;</code> element, will match whenever a resource
    from that particular site is requested, no matter what P3P policy
    applies (even if <em>no</em> policy applies). If you want to match
    sites that <em>don&#39;t</em> have a P3P policy, use the
    <code>non-or</code> or <code>non-and</code> connectives in the
    <code>&lt;appel:RULE&gt;</code> element, together with a
    <code>&lt;POLICY&gt;</code> element. A rule with an empty list of
    expressions will never get activated. In order to create a
    <em>default rule</em> that will trigger if no other (preceding)
    rule fired, the degenerate expression
    <code>&lt;OTHERWISE/&gt;</code> should be used.<br />
    </p>

    <div class="bnf">
<pre>
[3] rule             = &#39;&lt;appel:RULE behavior=&quot;&#39; behavior &#39;&quot;&#39;
                         common-attributes
                         rule-attributes
                         [connective] &#39;&gt;&#39;
                            body
                       &#39;&lt;/appel:RULE&gt;&#39;
      
[5] rule-attributes  = [&#39; prompt =&quot;&#39; (&#39;yes&#39;|&#39;no&#39;) &#39;&quot;&#39;]
                       [&#39; persona=&#39; quoted-string]
                       [&#39; promptmsg=&#39; quoted-string]
      
[6] body             = top-expression | &#39;&lt;appel:OTHERWISE/&gt;&#39;

[7] behavior         = &#39;request&#39; | &#39;block&#39; | &#39;limited&#39;

[8] top-expression   = policy | request-group [policy] 
</pre>
    </div>

    <h3><a name="OTHERWISE" id="OTHERWISE">4.2.3 The
    <code>&lt;appel:OTHERWISE&gt;</code> element</a></h3>

    <dl>
      <dt><code>&lt;appel:OTHERWISE&gt;</code></dt>

      <dd>so called degenerate-expression, which always evaluates to
      <b>true</b>. This can be used to craft &quot;catch-all&quot;
      rules that match all cases not covered by previous rules.</dd>
    </dl>

    <p><code>&lt;appel:OTHERWISE&gt;</code> should be the only
    expression in a rule. A ruleset should usually contain one and only
    one rule featuring the degenerate expression, and such a rule
    should be the last one in a ruleset. Users should take care not to
    use the <code>&lt;OTHERWISE&gt;</code> element together with a
    <em>request</em> behavior, which would result in indiscriminated
    access to all sites not covered by the preceding rules.<br />
    </p>

    <div class="bnf">
<pre>
[6] body             = top-expression | &#39;&lt;appel:OTHERWISE/&gt;&#39;
</pre>
    </div>

    <h3><a name="REQUEST" id="REQUEST">4.2.4 The
    <code>&lt;appel:REQUEST&gt;</code> element</a></h3>

    <dl>
      <dt><code>&lt;appel:REQUEST&gt;</code></dt>

      <dd>allows the creation of rules that only apply to a certain
      resource or domain.</dd>

      <dt><code>connective</code></dt>

      <dd>Allows for different matching semantics of enclosed
      subelements. See section <a href="#connective">4.2.5 The
      <code>appel:connective</code> attribute</a> below.</dd>

      <dt><code>uri</code> &#160; &#160; <em>(mandatory
      attribute)</em></dt>

      <dd>the URI of the currently requested resource (not the policy
      URI).</dd>
    </dl>

    <p>Together with a <code>&lt;POLICY&gt;</code> -expression, the
    <code>&lt;appel:REQUEST&gt;</code> element (embedded in an
    <code>&lt;appel:REQUEST-GROUP&gt;</code> element) can be used to
    create rules that only apply to a certain resource or domain. Since
    both expressions need to evaluate to true in order for the rule to
    fire, any existing <code>&lt;appel:REQUEST&gt;</code> element will
    limit the application of the <code>&lt;POLICY&gt;</code> expression
    to the given URI.</p>

    <p>In order to list multiple, alternative resources and/or domains
    in a single rule, you can embed multiple
    <code>&lt;appel:REQUEST&gt;</code> elements in an
    <code>&lt;appel:REQUEST-GROUP&gt;</code> element and connect them
    using an <code>or</code> or <code>or-exact</code> connective.<br />
    </p>

    <div class="bnf">
<pre>
[8] top-expression   = policy | request-group [policy]

[10] request-group   = &#39;&lt;appel:REQUEST-GROUP &#39; [connective]&#39;&gt;&#39;
                          1*request
                       &#39;&lt;/appel:REQUEST-GROUP&gt;&#39;

[11] request         = &#39;&lt;appel:REQUEST uri=&quot;&#39; [<a
href="#URI">URI</a>] as per <a
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>

 &#39;&quot;&gt;&#39;
</pre>
    </div>

    <h3><a name="connective" id="connective">4.2.5 The
    <code>appel:connective</code> attribute</a></h3>

    <dl>
      <dt><code>appel:connective</code></dt>

      <dd>determines how contained expressions are matched when a rule
      is compared to the available evidence.</dd>
    </dl>

    <p>APPEL supports six different kinds of connectives:
    <code>or</code>, <code>and</code>, <code>non-or</code>,
    <code>non-and</code>, <code>or-exact</code> and
    <code>and-exact</code>. Please refer to section <a
    href="#match_connectives">5.4.1 Connectives</a> for a description
    of their semantics. If no <code>appel:connective</code> is given,
    APPEL&#39;s matching semantics default to an <code>and</code>
    match: <em>All</em> of the contained­expressions <em>must</em>
    appear in the evidence, <em>additional</em> elements will be
    ignored.<br />
    </p>

    <div class="bnf">
<pre>
[12] connective      = &#39;appel:connective=&quot;&#39; conn &#39;&quot;&#39;

[13] conn            = or | and | non-or | non-and | or-exact | and-exact
</pre>
    </div>

    <h3><a name="p3p10policy" id="p3p10policy">4.2.6 The P3P1.0 policy
    snippet</a></h3>

    <p>The primary focus of APPEL is the matching of P3P1.0 policies,
    although in principle any kind of XML evidence could potentially be
    matched against. While P3P1.0 policies must adhere to the strict
    syntax and semantics of the P3P1.0 specification, the P3P1.0 policy
    snippets given in an APPEL rule can consist of any set of P3P1.0
    elements, in any order.</p>

    <div class="bnf">
<pre>
[8] top-expression = policy | request-group [policy]    

[9] policy         = &lt;[<a
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)&gt; 
</pre>
    </div>

    <p>Not only can required parts of a P3P1.0 policiy be omitted (in
    case they are not relevant for the matching), even enclosing tags
    need not be present: it is perfectly legal for a rule to contain,
    for example, a single <code>DATA</code> element, even though such
    an element would need to be embedded within a
    <code>STATEMENT</code> element when part of a P3P1.0 policy. APPEL
    rule evaluators need not verify a given policy for P3P1.0
    compliance, this must be done by the calling application. Only when
    matching <code>DATA</code> elements and their
    <code>CATEGORIES</code>, APPEL rule evaluators must properly check
    the corresponding P3P1.0 semantics (see sections <a
    href="#match_dataref">5.4.5 Matching <code>p3p:DATA</code>
    elements</a> and <a href="#match_cat">5.4.6 Category expansion</a>
    below).</p>

    <h1><a name="semantics" id="semantics">5 Semantics</a></h1>

    <p>While section <a href="#operation">2. General Operation and
    Semantics</a> already gave an overview of the basic operations of
    an APPEL rule evaluator, the following sections describe the
    semantics of the APPEL language in more detail. We first revisit
    the basic operation of an APPEL rule evaluator described in <a
    href="#operation">section 2</a>, and then focus on individual
    issues concerning rule evaluation: rule ordering, expressions,
    matching, and rule expiration.</p>

    <h2><a name="nut" id="nut">5.1 The Rule Evaluator in a
    Nutshell</a></h2>

    <p>A P3P user agent or other program will invoke an APPEL rule
    evaluator, providing an APPEL <b>ruleset</b> and various pieces of
    &quot;<b>evidence</b>,&quot; which may include the URI of the
    currently requested resource, and a single P3P policy. If multiple
    P3P policies are available, the user agent SHOULD call the rule
    evaluator repeatedly and feed it each policy separately (in any
    order).</p>

    <p>The rule evaluator MUST return a <b>behavior</b> (i.e., one of
    the three <a href="#def_beh_standard">standard behaviors</a>
    &quot;request&quot;, &quot;block&quot; or &quot;limited&quot;) that
    the calling program should carry out (including any optional
    <code>prompt</code> attribute). In addition, the rule evaluator
    SHOULD optionally return a prompt message (if applicable) and MAY
    optionally return an explanation string (suitable for user
    display), the name of a persona, and/or the rule that fired.</p>

    <h3><a name="nut_be" id="nut_be">5.1.1 Behaviors</a></h3>

    <p>A user agent MUST at least support the three <a
    href="#def_beh_standard">standard behaviors</a>
    &quot;request&quot;, &quot;block&quot; or &quot;limited&quot;. Each
    behavior may optionally require a user prompt, as indicated by the
    <code>prompt</code> attribute. User agents SHOULD if possible
    support such prompts.</p>

    <h3><a name="nut_rs" id="nut_rs">5.1.2 Rulesets</a></h3>

    <p>A ruleset consists of an ordered list of <b>rules</b>. Rules
    describe conditions under which a certain behavior should be
    carried out by the calling program.</p>

    <p>Each rule in a ruleset is evaluated in the order in which it
    appears. Once a rule evaluates to true, the corresponding behavior
    is returned and rule evaluation ends. If no match occurs and all
    rules have been processed, an error is returned to the calling
    program.</p>

    <p>Rulesets should be written so that for any possible evidence
    set, there is always a rule that will fire. It is up to the calling
    program (usually the user agent) to determine what to do if an
    error is returned; however, calling programs should not treat an
    error as they would an &quot;request&quot;.</p>

    <h3><a name="nut_ex" id="nut_ex">5.1.3 Expressions</a></h3>

    <p>Each rule contains a number of top-level <b>expressions</b> in
    form of a well-formed XML element and features one single
    <b>behavior</b> (with an optional <code>prompt</code> attribute).
    An APPEL compliant user agent MUST at least support the P3P
    <code>&lt;POLICY&gt;</code> element, the APPEL
    <code>&lt;appel:OTHERWISE&gt;</code> element, as well as the
    <code>&lt;appel:REQUEST&gt;</code> element (representing the URI of
    the <em>currently requested resource</em>, not the policy URI).</p>

    <p>Each expression in a rule is implicitly ANDed together with all
    of its enclosed <a href="#def_attr_expr">attribute expressions</a>.
    <a href="#def_cont_expr">Contained expressions</a> (including <a
    href="#def_top_expr">top-level expressions</a>) are by default also
    ANDed together, unless the rule author explicitly specified an
    alternative matching using the <code>connective</code>
    attribute.</p>

    <p>All expressions and their sub-expressions (i.e. attribute and
    contained expressions) are matched by the rule evaluator against
    the elements in the evidence according to the nesting in which they
    appear in the rule. For example, a <code>STATEMENT</code> element
    nested inside a <code>POLICY</code> element in the rule will only
    match a <code>STATEMENT</code> element in the evidence that is
    nested inside a matching <code>POLICY</code> element.</p>

    <p>A rule containing no expressions always evaluates to false, a
    rule containing only the <a href="#def_dege_expr">degenerate
    expression</a> always evaluates to true.</p>

    <h2><a name="order" id="order">5.2 Rules ordering</a></h2>

    <blockquote>
      <p><em>How APPEL evaluates multiple rules in a ruleset</em></p>
    </blockquote>

    <p>There is no need for logic operators between multiple rules in
    an APPEL ruleset, since all rules in APPEL are evaluated strictly
    in order. However, inserting a new rule or changing the order of an
    existing list of rules can greatly influence the behavior of the
    user agent!</p>

    <p>Even though rules are evauluated strictly in order,
    independently of their behavior, the working group has found the
    following ordering to be helpful when (manually) creating APPEL
    rulesets:</p>

    <ol>
      <li>Exceptions (any behavior)</li>

      <li>Request rules</li>

      <li>Limited rules</li>

      <li>Block rules</li>
    </ol>

    <p>After starting out with all cases that are deemed acceptable
    (request rules), append all situations under which only limited
    request should be made (limited rules). The final set of rules
    cover all cases that should result in a blocked request (block
    rules). Finally, prepend a list of exceptions (any behavior) to the
    list of rules, such as special provisions for trusted sites, etc.
    This ordering has proven to be helpful for members of the working
    group, both for creating as well as for maintaining rulesets.</p>

    <p>Care should be taken that only a single rule containing the
    degenerate expression <code>&lt;OTHERWISE&gt;</code> exists and is
    placed at the end of the ruleset.</p>

    <h2><a name="expressions" id="expressions">5.3 Expressions</a></h2>

    <blockquote>
      <p><em>How to specify what to match in a rule</em></p>
    </blockquote>

    <p>Every rule in an APPEL ruleset contains a number of top-level <a
    href="#def_expr">expressions</a> that must be in valid XML format.
    Each expression tries to match a certain piece of evidence, which
    in APPEL1.0 can only be in the form of a P3P policy or represent
    request information such as the resource URI (using the
    <code>&lt;appel:REQUEST&gt;</code> element).</p>

    <p>All sub-expressions of a single expression are per default
    always ANDed together, that is, <i>all</i> <a
    href="#def_attr_expr">attribute</a> and <a
    href="#def_cont_expr">contained</a> expressions have to evaluate to
    <b>true</b> in order for the expression to match. However, using
    the <code>appel:connective</code> attribute, the rule author can
    explictly specify different matching semantics for the top-level
    and contained expressions.</p>

    <p>Note that connectives only govern the matching of contained
    expressions appearing <em>at this level</em>. Should these
    contained expressions in turn contain other expressions, they will
    be matched using the default matching semantics (i.e.,
    <code>and</code>) unless another <code>connective</code> attribute
    is used within the contained expression. See section <a
    href="#match_connectives">5.4.1 Connectives</a> for details.</p>

    <p>Figure 5.1 below gives the informal definition of the 3 main
    types of expressions in APPEL.<br />
    </p>

    <div class="caption">
      <b>Figure 5.1:</b> APPEL Expressions (informative)
    </div>

    <div class="framed-bnf">
<pre>
[1] <span
class="highlit">expression</span>            = empty-expression | containing-expression | <code><a
 href="http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-chardata">#PCDATA</a></code>

[2] empty-expression      = &quot;&lt;&quot; element-name *attribute-expression &quot;/&gt;&quot;
      
[3] containing-expression = &quot;&lt;&quot; element-name *attribute-expression [connective]&quot;&gt;&quot;
                                1*contained-expression
                            &quot;&lt;/&quot; element-name &quot;&gt;&quot; 

[4] element-name          = identifier
      
[5] <span
class="highlit">attribute-expression</span>  = attribute_name &quot;=&quot; quoted-string
      
[6] <span class="highlit">contained-expression</span>  = expression
      
[7] attribute_name        = identifier

[8] identifier            = &lt;a valid XML identifier&gt;

[9] quoted-string         = `&quot;` string `&quot;`

[10] string               = &lt;[<a
href="#utf8">UTF-8</a>] string (with &quot; and &amp; escaped)&gt;

[11] connective           = &#39;appel:connective=&quot;&#39; conn &#39;&quot;&#39;

[12] conn                 = or | and | non-or | non-and | or-exact | and-exact
</pre>
    </div>

    <p>Note that it is possible in APPEL that multiple expressions in
    the rule match one and the same element in the evidence. Rule
    evaluators do not need to keep track of which part of the rule
    matched which part in the evidence. Instead, each expression can
    separately be checked against the available evidence, as shown in
    the example below: Both <code>STATEMENT</code> -expressions in the
    rule independantly match the same <code>&lt;STATEMENT&gt;</code>
    element in the evidence.<br />
    </p>

    <div class="caption">
      <b>Figure 5.2:</b> Matching Example
    </div>

    <div class="table">
      <table summary="Matching example" border="0" width="100%">
        <tbody>
          <tr>
            <td>
<pre>
&lt;-- ruleset --&gt;

&lt;appel:RULE behavior=&quot;request&quot;&gt;
  &lt;POLICY&gt;
    &lt;STATEMENT&gt;
      &lt;RECIPIENT appel:connective=&quot;or-exact&quot;&gt;
        &lt;ours/&gt;
      &lt;/RECIPIENT&gt;
      &lt;DATA-GROUP appel:connective=&quot;or-exact&quot;&gt;
        &lt;DATA ref=&quot;#user.*&quot;/&gt;
      &lt;/DATA-GROUP&gt;
    &lt;/STATEMENT&gt;
    &lt;STATEMENT&gt;
      &lt;PURPOSE appel:connective=&quot;or-exact&quot;&gt;
        &lt;customization/&gt;
      &lt;/PURPOSE&gt;
      &lt;DATA-GROUP&gt;
        &lt;DATA&gt;
          &lt;CATEGORIES appel:connective=&quot;or-exact&quot;&gt;
            &lt;online/&gt;
          &lt;/CATEGORIES&gt;
        &lt;/DATA&gt;
      &lt;/DATA-GROUP&gt;
    &lt;/STATEMENT&gt;
  &lt;/POLICY&gt;
&lt;/appel:RULE&gt;
</pre>
            </td>
          </tr>

          <tr>
            <td valign="top">
<pre>
&lt;-- evidence (abbreviated) --&gt;

&lt;POLICY&gt;
  ...
  &lt;STATEMENT&gt;
      &lt;RECIPIENT&gt;&lt;ours/&gt;&lt;/RECIPIENT&gt;
      &lt;PURPOSE&gt;&lt;customization/&gt;&lt;/PURPOSE&gt;
      &lt;DATA-GROUP&gt;
        &lt;DATA ref=&quot;#user.home.online.email&quot;/&gt;
      &lt;/DATA-GROUP&gt;
  &lt;/STATEMENT&gt;
&lt;/POLICY&gt;
</pre>
            </td>
          </tr>
        </tbody>
      </table>
    </div>

    <p>Expressions over elements that are <em>not</em> in the set of
    evidence provided by the calling program always evaluate to
    <b>false</b>, unless the rule author explicitly used the
    <code>appel:connective</code> attribute with either the
    <code>or</code>, <code>or-exact</code>, <code>non-or</code> or
    <code>non-and</code> flag. For example, a rule using a (contained)
    expression to match a <a
    href="http://www.w3.org/TR/P3P/#DISPUTES">disputes element</a>
    without any connectives would always fail unless the evidence would
    contain such an element.</p>

    <p>On the other hand, elements in the evidence that do not have a
    corresponding expression in the rule are always ignored, unless the
    rule author explicitly used the <code>appel:connective</code>
    attribute with either the <code>or-exact</code>,
    <code>and-exact</code>, <code>non-or</code> or <code>non-and</code>
    flag. For example, a rule referencing a P3P policy containing a
    disputes element but no disclosure element (and using no
    connectives) could possibly match evidence of a P3P policy
    featuring <em>both</em> a disputes <em>and</em> a disclosure
    element.</p>

    <p>When using APPEL1.0 all elements other that P3P policies and
    <code>appel:REQUEST</code> elements will be ignored (i.e. do not
    alter rule evaluation). Also remember that if more than one P3P
    policy is available, they should be submitted to the rule evaluator
    individually (see <a href="#nut">5.1 The Rule Evaluator in a
    Nutshell</a>).</p>

    <h2><a name="match" id="match">5.4 Matching</a></h2>

    <blockquote>
      <p><em>How APPEL matches expressions against available
      evidence</em></p>
    </blockquote>

    <p>Expressions in APPEL are used to match a rule against the
    available evidence. For a given element in the rule, an expression
    can test whether the evidence contains an identical element
    featuring the same attributes, values, and matching sub-elements.
    The standard matching semantics for all expressions in APPEL depend
    on the choice of connective that is used (see section <a
    href="#match_connectives">5.4.1 Connectives</a> below) and can be
    summarized as follows:<br />
    </p>

    <ol>
      <li><b>All attribute expressions in a rule are ANDed, additional
      attributes are ignored.</b><br />
       Attributes are ANDed within a single element, that is all
      attributes in an expression have to appear in a single element in
      the evidence. Any attribute in the evidence that can not be found
      in the element in the rule is ignored.</li>

      <li>
        <b>Contained expressions are...</b><br />
         

        <ol>
          <li><b>...ORed</b> ( <code>or</code>, <code>or-exact</code>
          and <code>non-or</code> connectives)<br />
           At least <em>one</em> contained expression in the current
          expression has to match an element in a corresponding element
          of the evidence.<br />
           If the <code>non-or</code> connective is used, the rule will
          <em>fail</em> in the above case, i.e. it only evaluates to
          true if <em>none</em> of the contained expressions in the
          current expression can be found in a corresponding element of
          the evidence.</li>

          <li><b>...ANDed</b> ( <code>and</code>,
          <code>and-exact</code> and <code>non-and</code>
          connectives)<br />
           Any contained element listed in the expression <em>has</em>
          to appear in a corresponding position in the evidence, with
          matching attributes and values.<br />
           If the <code>non-and</code> connective is used, the rule
          will <em>fail</em> in the above case, i.e. it only evaluates
          to true if <em>all</em> of the contained expressions in the
          current expression can <em>not</em> be found in a
          corresponding element of the evidence.</li>
        </ol>
      </li>

      <li>
        <b>Additional evidence (non-attribute)...</b> 

        <ol>
          <li><b>...is ignored</b> ( <code>or</code>, <code>and</code>,
          <code>non-or</code> and <code>non-and</code>
          connectives)<br />
           Any element listed in the evidence that can not be found in
          the rule (or which can be found but without matching
          attributes and values) will be ignored.</li>

          <li><b>...is <em>not</em> ignored</b> ( <code>or-exact</code>
          and <code>and-exact</code> connectives)<br />
           Any element listed in the evidence that can not be found in
          the rule (or which can be found but without matching
          attributes and values) will prompt the rule to fail.</li>
        </ol>
      </li>
    </ol>

    <p>The different matching semantics that result from the six
    available connectives are summarized in Table 5.3 below:<br />
    </p>

    <div class="table">
      <table summary="Connectives" width="100%" cellspacing="0"
      cellpadding="5" border="1">
        <caption>
          <b>Table 5.3:</b> Connectives Summary (informative)
        </caption>

        <tbody>
          <tr>
            <th rowspan="2" colspan="2">
            </th>

            <th colspan="2">Contained expressions are</th>
          </tr>

          <tr>
            <th>ORed</th>

            <th>ANDed</th>
          </tr>

          <tr>
            <th rowspan="2">Additional evidence</th>

            <th>is ignored</th>

            <td><code>or</code>, <code>non-or</code> </td>

            <td><code>and</code> (default), <code>non-and</code> </td>
          </tr>

          <tr>
            <th>is not ignored</th>

            <td><code>or-exact</code> </td>

            <td><code>and-exact</code> </td>
          </tr>
        </tbody>
      </table>
    </div>

    <h3><a name="match_connectives" id="match_connectives">5.4.1
    Connectives</a></h3>

    <p>While <em>attribute-expressions</em> are always ANDed, the
    matching of <em>contained-expressions</em> is subject to matching
    connectives that can be specified as attributes to the enclosing
    element. Note that even if an element does not feature any
    contained expressions or <code>#PCDATA</code>, specifying a
    connective will affect its matching semantics! APPEL1.0 supports
    six connectives, which are described in Table 5.4 below. In the
    informative mathematical formulas, <em><strong>R</strong></em>
    denotes the set of immediate subelements below the currently
    compared rule element (i.e., the contained expressions, including
    <code>#PCDATA</code>), while <em><strong>E</strong></em> identifies
    the immediate subelements (including <code>#PCDATA</code>) below
    the corresponding element in the evidence. Note that subelements of
    subelements are <em>not</em> part of these sets but need to be
    compared recursively in turn for each of the subelements.</p>

    <table summary="Matching Semantics of Connectives" border="1">
      <caption>
        <b>Table 5.4:</b> Matching Semantics of Connectives
      </caption>

      <tbody>
        <tr>
          <th class="top" rowspan="2">Connective</th>

          <th class="top">Short Description (informative)</th>

          <th class="top">Formula (informative)</th>
        </tr>

        <tr>
          <th class="top" colspan="3">Long Description (normative)</th>
        </tr>

        <tr>
          <th rowspan="2" class="side">or</th>

          <td class="top">at least one common element between rule
          elements <strong>R</strong> and evidence <strong>E</strong>
          </td>

          <td class="top"><img width="75" height="31"
          src="or-20020415.png" alt="\( R\cap E\neq \emptyset \)" />
          </td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>one or more</em>
          of the contained expressions can be found (at the correct
          position) in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, such evidence is
          <em>ignored</em>. Using this connective requires that at
          least one of the listed contained expressions appear in the
          evidence. In case an element does not feature any contained
          expressions, matching <em>always fails</em> !</td>
        </tr>

        <tr>
          <th rowspan="2" class="side">and</th>

          <td class="top">rule elements <strong>R</strong> subset of
          evidence <strong>E</strong> </td>

          <td class="top"><img width="49" height="29"
          src="and-20020415.png" alt="\( R\subseteq E \)" /> </td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>all</em> of the
          contained expressions can be found (at the correct position)
          in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, such evidence is
          <em>ignored</em>. Using this connective requires that all of
          the listed contained expressions appear in the evidence. In
          case no contained expressions are given, the enclosing
          expression <em>always matches</em> (provided that all of its
          attribute-expressions match). <b>This is the default matching
          semantics if no connective is given.</b> </td>
        </tr>

        <tr>
          <th rowspan="2" class="side">non-or</th>

          <td class="top">no common elements between rule elements
          <strong>R</strong> and evidence <strong>E</strong> </td>

          <td class="top"><!-- MATH: $R\cap E=\emptyset$ -->
          <img width="75" height="31" src="non-or-20020415.png"
          alt="\( R\cap E=\emptyset \)" /> </td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>none</em> of the
          contained expressions can be found (at the correct position)
          in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, such evidence is
          <em>ignored</em>. In case no contained expressions are
          listed, the enclosing expression <em>always matches</em>
          (provided that all of its attribute-expressions match). This
          connective is the equivalent of negating a standard
          <code>or</code> match described above: <code>NOT (... or ...
          or ...)</code>.</td>
        </tr>

        <tr>
          <th rowspan="2" class="side">non-and</th>

          <td class="top">at least one rule element <strong>R</strong>
          not in evidence <strong>E</strong> </td>

          <td class="top"><!-- MATH: $R\setminus E\neq \emptyset$ -->
          <img width="72" height="31" src="non-and-20020415.png"
          alt="\( R\setminus E\neq \emptyset \)" /> </td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>not all</em> of
          the contained expressions can be found (at the correct
          position) in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, such evidence is
          <em>ignored</em>. In case no contained expressions are
          listed, matching <em>always fails</em> ! This connective is
          the equivalent of negating a standard <code>and</code> match
          described above: <code>NOT (... and ... and ...)</code>.</td>
        </tr>

        <tr>
          <th rowspan="2" class="side">or-exact</th>

          <td class="top">non-empty evidence <strong>E</strong> subset
          of rule elements <strong>R</strong> </td>

          <td class="top"><!-- MATH: $\emptyset\neq E\subseteq R$ -->
          <img width="79" height="23" src="or-exact-20020415.png"
          alt="\( E\subseteq R \)" /> </td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>one or more</em>
          of the contained expressions can be found (at the correct
          position) in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, matching <em>fails</em>. In
          case no contained expressions are listed, matching <em>always
          fails!</em> Using this connective ensures that only those
          elements listed in the rule appear in the evidence.</td>
        </tr>

        <tr>
          <th rowspan="2" class="side">and-exact</th>

          <td class="top">evidence <strong>E</strong> equals rule
          elements <strong>R</strong> </td>

          <td class="top">E=R</td>
        </tr>

        <tr>
          <td class="desc" colspan="3">Matches if <em>all</em> of the
          contained expressions can be found (at the correct position)
          in the evidence. If the evidence contains elements
          <em>not</em> listed in the rule, matching <em>fails</em>.
          Using this connective ensures that the elements listed in the
          rule are identical with the evidence -- no elements are
          missing, no additional elements appear. In case no contained
          expressions are listed, the enclosing expression only matches
          if the evidence does not contain any subelements (at the
          corresponding position).</td>
        </tr>
      </tbody>
    </table>

    <h3><a name="match_attr_expr" id="match_attr_expr">5.4.2 Attribute
    Expressions</a></h3>

    <p>An <b>attribute expression</b> matches an attribute-value pair
    of an XML element in the evidence if and only if:</p>

    <ol>
      <li>the attribute names are identical</li>

      <li>AND the values are identical (using string comparison)</li>
    </ol>

    <p>Only the = operator may be applied to attribute expressions. All
    attribute values are treated as strings in APPEL, even if they
    represent numbers (No P3P element features numeric attribute
    values, so this shouldn&#39;t really matter). In order for an
    expression to match, <i>all</i> of the attributes and values listed
    in the expression&#39;s attribute expressions have to appear in a
    single element with the same name in the evidence. Any additional
    attributes that are found in the evidence but which are not
    referenced in the rule are <em>ignored</em>. Since some attributes
    in P3P have a default value that applies when the attribute is not
    explicitly given in an element, the matching algorithm MUST
    represent such default attributes with their implicit values, in
    case a rule explicitly tries to match an attribute with its default
    value.</p>

    <p>If a rule requires that a particular attribute appears in an
    element without restrictions on the value for that attribute
    (including the empty value!), the wildcard character &quot;
    <b>*</b> &quot; may be used (e.g. as in
    <code>attribute=&quot;*&quot;</code>). However, if a rule does not
    require that a particular attribute appear at all, the attribute
    should not appear in the rule at all. It is not possible in APPEL
    to write rules that require that a certain attribute does
    <em>not</em> appear in an element of the evidence set (e.g.
    matching <code>&lt;DISPUTES&gt;</code> elements without
    <code>resolution-type</code> attribute).</p>

    <p>Please note that attribute expressions match independently from
    any given connective, that is, no matter which connective is in
    effect, additional attributes found in the evidence but not in the
    rule are <em>always</em> ignored.</p>

    <h3><a name="match_wild" id="match_wild">5.4.3 Expression
    Metacharacters</a></h3>

    <p>APPEL offers a single metacharacter for providing simple regular
    expression support in its expressions: the asterix (&quot; <b>*</b>
    &quot;) character, which is used to represent a sequence of 0 or
    more characters. This usage of the asterix character is similar to
    popular operating system shells under DOS/Windows and UNIX, but
    differs from its semantics in standard regular expression systems
    such as <em>egrep</em>.</p>

    <p>Using metacharacters with strings allows us to specify ranges of
    string-values, for example &quot; <code>*.foo.com</code> &quot; for
    any host in the foo.com domain, or &quot; <code>*://*&quot;</code>
    &quot; for a URI (or at least something that looks like one).
    Please note that string values are always matched <em>from the
    beginning</em> of the string, unless the user specified an initial
    <b>*</b> star symbol. Forcing a string match from the end is not
    possible in APPEL1.0.</p>

    <p>Note that since the asterix is also a legal character in URIs ([
    <a href="#URI">URI</a> ]), some special conventions have to be
    followed when encoding such &quot;extended URIs&quot; in an APPEL
    ruleset:</p>

    <ul>
      <li>URIs represented in an APPEL ruleset MUST be properly
      escaped, as in [ <a href="#URI">URI</a> ].</li>

      <li>APPEL rule evaluators MUST escape any characters that should
      be escaped, as according to [ <a href="#URI">URI</a> ], before
      attempting to match a URI in an APPEL ruleset.</li>

      <li>APPEL rule evaluators MUST un-escape any escaped sequences
      that resolve to URI-legal characters, according to [ <a
      href="#URI">URI</a> ], before attempting to match a URI in an
      APPEL ruleset, EXCEPT</li>

      <li>Literal &#39;*&#39;s in URIs MUST be escaped by APPEL rule
      evaluators before attempting to match a URI in an APPEL
      ruleset.</li>
      <!-- <li> P3P user agents MUST ignore any URI pattern that do not conform to
                                           [<a href="#URI">URI</a>]</li> -->
    </ul>

    <p>Please note also that the wildcard character is both allowed
    within quoted strings (i.e., in attribute expressions) and between
    XML elements (i.e., matching <code>#PCDATA</code>). However, you
    can not use the wildcard character to match attribute or element
    names, as for example in <code>&lt;DISPUTES
    res*=&quot;service&quot;&gt;</code> or <code>&lt;DISP*
    resolution-type=&quot;service&quot;&gt;</code> ! Nor can you use it
    in the <code>ref</code> attribute of <code>&lt;DATA&gt;</code>
    elements or the <code>base</code> attribute of
    <code>&lt;DATA-GROUP</code> elements. For details on matching P3P
    data elements, see section <a href="#match_dataref">5.4.5 Matching
    <code>p3p:DATA</code> elements</a> below.</p>

    <h3><a name="match_pcdata" id="match_pcdata">5.4.4 Matching
    <code>#PCDATA</code></a></h3>

    <p>It is possible to write APPEL rules that match
    <code>#PCDATA</code> in the evidence, simply by including the text
    to match as <code>#PCDATA</code> within the corresponding element
    in the APPEl rule.</p>

    <p>However, in order to facilitate rule formulation, the APPEL
    ruleset evaluator MUST normalize both pieces of
    <code>#PCDATA</code> before <code>#PCDATA</code> taken from the
    ruleset is matched against <code>#PCDATA</code> taken from the
    policy. The normalization algorithm to use is given below:</p>

    <ol>
      <li>Replace all occurrences of <code>#x9</code> (tab),
      <code>#xA</code> (line feed) and <code>#xD</code> (carriage
      return) with <code>#x20</code> (space).</li>

      <li>Replace contiguous sequences of spaces with a single
      space.</li>

      <li>Delete any leading and trailing space.</li>
    </ol>

    <p>Once both values have been normalized, matching
    <code>#PCDATA</code> is similar to <a
    href="#match_attr_expr">attribute expression matching</a> described
    above: Two pieces of <code>#PCDATA</code> match if and only if</p>

    <ul>
      <li>the values are identical (using string comparison over the
      normalized values)</li>
    </ul>

    <p>Similarly to contained expressions, the matching of
    <code>#PCDATA</code> is subject to the <a
    href="#connective">appel:connective</a> given in its enclosing
    element. For practical purposes, each block of <code>#PCDATA</code>
    can be seen as a separate subelement for which the matching
    semantics described in section <a href="#match_connectives">5.4.1
    Connectives</a> above must be applied.</p>

    <p>Please note that some XML parsers might treat a block of
    <code>#PCDATA</code> that contains one or more <a
    href="http://www.w3.org/TR/REC-xml#sec-comments">XML comments</a>
    as two or more separate <code>#PCDATA</code> blocks. XML comments
    both within the rule and the evidence MUST be ignored , so
    implementors must make sure that such separated
    <code>#PCDATA</code> blocks are treated as if they were a single,
    contiguous section (i.e., as if no comments were present).</p>

    <h3><a name="match_dataref" id="match_dataref">5.4.5 Matching
    <code>p3p:DATA</code> elements</a></h3>

    <p><code>&lt;p3p:DATA&gt;</code> and
    <code>&lt;p3p:DATA-GROUP&gt;</code> elements carry a special
    semantic in P3P policies. They reference sets and elements of the
    <a href="http://www.w3.org/TR/P3P/#Base_Data_Schema">P3P base data
    schema</a> and potentially custom schemas. Each reference to a data
    element or data set consists of a URI reference, where the fragment
    identifier part denotes the <em>name</em> of the data element or
    set, while the URI part denotes the corresponding <em>data
    schema</em> (compare with section <a
    href="http://www.w3.org/TR/P3P/#DATA">3.3.7 The
    <code>DATA-GROUP</code> and <code>DATA</code> elements</a> in the
    <a href="http://www.w3.org/TR/P3P/">P3P1.0 Specification</a>).</p>

    <p>In order to correctly handle the semantics of data schemas, the
    following exceptions to standard matching apply to
    <code>p3p:DATA-GROUP</code> and <code>p3p:DATA</code> elements:</p>

    <ol>
      <li>The <code>base</code> attribute of a <code>DATA-GROUP</code>
      element is <em>omitted</em> from standard attribute matching.
      Instead, it is used to set the <em>base URI</em> for all URI
      references in the <code>DATA</code> elements contained by this
      <code>DATA-GROUP</code> element (see step 2 below). When this
      attribute is not present, the default value is the URI of the P3P
      base data schema ( <a
      href="http://www.w3.org/TR/P3P/base">http://www.w3.org/TR/P3P/base</a>).
      When the attribute appears as an empty string (&quot;&quot;), the
      base is the local document. Note that this process must be
      applied to <code>DATA-GROUP</code> elements in <em>both</em> the
      rule <em>and</em> the evidence.</li>

      <li>Each <code>ref</code> attribute of a <code>DATA</code>
      element that contains only a fragment identifier (e.g.,
      &quot;#user.name&quot;) is expanded using the corresponding
      <code>base</code> of its enclosing <code>DATA-GROUP</code>
      element (see step 1 above). This process must be applied to
      <code>DATA</code> elements in <em>both</em> the rule <em>and</em>
      the evidence.</li>

      <li>Two <code>ref</code> attributes match if both their URI parts
      (i.e., without the fragment identifier) match, <em>and</em> one
      fragment identifier is a <em>prefix</em> of the other. It does
      not matter whether it is the <code>ref</code> attribute in the
      rule that is a prefix of the <code>ref</code> attribute in the
      evidence, or the other way around.</li>

      <li>Wildcards in <code>base</code> and <code>ref</code> elements
      of <code>DATA-GROUP</code> and <code>DATA</code> elements are not
      permitted.</li>
    </ol>

    <p>The above matching semantics will have the effect that a rule
    specifying, for example, the <em>data set</em>
    <code>#user.name</code>, matches the <em>data element</em>
    <code>#user.name.first</code> in the evidence. Equally, a single
    <em>data element</em> in the rule, like
    <code>#user.home­info.postal.street</code> will match a whole
    <em>data set</em> specified in the evidence, such as
    <code>#user.home-info</code>. In order to write a rule matching all
    data elements from a specific data schema, rule authors can use the
    empty fragment identifier &#39; <code>#</code> &#39; in conjunction
    with an enclosing <code>DATA-GROUP</code> element that features a
    corresponding <code>base</code> attribute.</p>

    <p>However, note that in order for a <code>p3p:DATA</code> element
    to match, any implicitly or explicitly given <em>categories</em>
    must match as well, as described in section <a
    href="#match_cat">5.4.6 Category expansion</a> below.</p>

    <h3><a name="match_cat" id="match_cat">5.4.6 Category
    expansion</a></h3>

    <p><a href="http://www.w3.org/TR/P3P/#Categories">P3P
    categories</a> are subelements of data reference elements that
    provide hints to users and user agents as to the intended uses of
    the data. Categories are vital to making P3P user agents easier to
    use; they allow users to express more generalized preferences and
    rules over the exchange of their data. Categories have to be
    included when defining a new element or referring to variable
    abstract elements such as form data or cookies.</p>

    <p>In order for rule evaluators to be able to identify and expand
    data element categories, the corresponding data schema for each
    encountered data element must be known to the rule evaluator.
    Consequently, both the P3P base data schema, as well as any custom
    data schemas referenced in the evidence MUST be passed to the rule
    evaluator when processing a ruleset (compare section <a
    href="#inout">2.1 Inputs and Outputs of the Rule
    Evaluator</a>).</p>

    <p>APPEL rule evaluators must expand <code>DATA</code> and
    <code>CATEGORIES</code> elements in the evidence according to the
    steps described below before attempting to match
    <code>CATEGORIES</code> elements in a rule:</p>

    <ol>
      <li>If the data element enclosing a <code>CATEGORIES</code>
      element is a <a href="http://www.w3.org/TR/P3P/#fixed">fixed
      categories data element</a>, any explicit category referenced in
      the evidence MUST be part of the element&#39;s fixed set of
      categories as defined in its base data schema. Non-matching
      categories MUST be removed prior to matching. User agents MAY
      optionally alert the user to any mismatch.</li>

      <li>For each <a
      href="http://www.w3.org/TR/P3P/#variable">variable-categories
      data element</a>, the evidence MUST contain one or more explicit
      categories. Otherwise the evidence is not a valid P3P policy and
      user agents MUST treat them as they treat other malformed P3P
      policies (compare with section <a
      href="http://www.w3.org/TR/P3P/#variable">5.5.2 Variable-Category
      Data Elements/Structures</a> in the <a
      href="http://www.w3.org/TR/P3P/">P3P1.0 Specification</a>).</li>

      <li>Each <a
      href="http://www.w3.org/TR/P3P/#fixed">fixed-categories data
      element</a> in the evidence MUST be expanded to contain a
      <code>CATEGORIES</code> sublement listing <em>all</em> its
      categories (as defined in the element&#39;s data schema).</li>
    </ol>

    <p>Implementors might want to note that unless a ruleset does
    contain at least one <code>CATEGORIES</code> element, the above
    expansion can be skipped.</p>

    <h3><a name="match_optional" id="match_optional">5.4.7 Matching
    optional data elements</a></h3>

    <p>Data elements in P3P can be tagged as
    <code>optional=&quot;yes&quot;</code>, indicating that the declared
    element is not required. Intuitively, an optional element in the
    evidence which would cause a rule to fail should be treated
    differently from a mandatory element when being evaluated by an
    APPEL rule evaluator.</p>

    <p>Since fully transparent support for such optional elements would
    require rule evaluators to be able to <em>selectively remove</em>
    certain non-mandatory elements from the evidence in order to find a
    possible match for a rule (an NP-hard problem), the working group
    decided to simplify optional-element handling by the rule evaluator
    at slightly additional costs for the rule authors. In practice,
    this means that optional element handling is done using standard <a
    href="#match_attr_expr">attribute matching</a> (as described in
    section <a href="#match_attr_expr">5.4.2 Attribute Expressions</a>)
    on the corresponding <code>optional</code> attribute identifying
    such elements.</p>

    <p>Due to its standard <a href="#match_attr_expr">attribute
    matching semantics</a>, APPEL rules must <em>ignore</em> attributes
    present in the evidence that are not referenced in the rule.
    Consequently, a rule featuring a data element without explicitly
    specifying an <code>optional=&quot;yes&quot;</code> or
    <code>optional=&quot;no&quot;</code> attribute will match
    <em>any</em> corresponding data element in the evidence
    <em>regardless</em> of its mandatory or optional status. This
    default should be suitable for most rules (especially those
    resulting in a <em>request</em> behavior).</p>

    <p>However, in some cases (notably <em>block</em> rules) rule
    authors might want to differentiate between data elements declared
    as <em>mandatory</em> and those being <em>optional</em>. This can
    be done by adding an explicit <code>optional=&quot;no&quot;</code>
    to data elements in the corresponding rule, forcing the rule
    evaluator to check for an <code>optional</code> attribute in the
    corresponding evidence and rejecting the match unless the evidence
    features an explicit <code>optional=&quot;yes&quot;</code> for this
    element.</p>

    <p>Rule authors must thus decide for every element that they want
    to match in their rules whether they want to match only
    <em>optional</em> elements in the evidence (by using
    <code>optional=&quot;yes&quot;</code> in the rule), only mandatory
    elements (by using <code>optional=&quot;no&quot;</code> in the
    rule), or if the optional status of an element does not matter (by
    leaving out the <code>optional</code> attribute altogether). Note
    that different <code>connective</code>s in each of the enclosing
    elements in the rule might affect this requirement.</p>

    <h3><a name="match_extension" id="match_extension">5.4.8 Matching
    optional and mandatory extensions</a></h3>

    <p>P3P 1.0 also supports the concept of <a
    href="http://www.w3.org/TR/P3P/#extension">optional and mandatory
    extensions</a>. Such extensions are enclosed in a set of
    <code>&lt;EXTENSION&gt;...&lt;/EXTENSION&gt;</code> tags and
    feature an <code>optional</code> attribute that is used to indicate
    wheter an unknown extension can either be safely ignored (
    <code>optional=&quot;yes&quot;</code>) or not.</p>

    <p>As with the concept of optional data elements discribed in
    section <a href="#match_optional">5.4.7 Matching optional data
    elements</a> above, the optional extension mechanism does
    <em>not</em> require any special handling on behalf of the APPEL
    rule evaluator. Again, standard <a
    href="#match_attr_expr">attribute matching semantics</a> apply, as
    described in section <a href="#match_attr_expr">5.4.2 Attribute
    Expressions</a>.</p>

    <p>This is because the availability of an extension (i.e., whether
    or not it will be ignored) is neither a feature of the user&#39;s
    preferences, nor of the P3P1.0 policy: it is up to the
    implementation calling the APPEL rule evaluator to decide whether
    it can understand any extensions embedded in P3P1.0 policies. If it
    does understand the extension, it can remove any
    <code>optional=&quot;yes&quot;</code> attribute present and pass
    the evidence on to the APPEL rule evaluator. If it does
    <em>not</em> understand the extension, it must decide whether it
    can safely remove the unknown extension (in case it is tagged as
    being optional) or abort evaluation of this policy if it is
    mandatory, as it cannot understand the meaning of the whole policy
    (compare with section <a
    href="http://www.w3.org/TR/P3P/#extension">3.5 Extension
    Mechanism</a> of the <a href="http://www.w3.org/TR/P3P/">P3P1.0
    Specification</a>.</p>

    <p>APPEL rule evaluators NEED NOT care about whether a certain
    extension matched in the evidence is known to the calling
    application or not. In most cases, rules covering extensions will
    not use the <code>optional</code> attribute at all: either the
    calling application supports this extension, then it will pass such
    evidence on to the rule evaluator. In case it does not support such
    an extensions, it will probably never pass any evidence containing
    such an extension to the rule evaluator in the first place.</p>

    <h2><a name="match_sum_and_example" id="match_sum_and_example">5.5
    Matching Summary &amp; Examples</a></h2>

    <p>The following section summarizes the different matching
    semantics described above and tries to give examples for matching
    algrorithms.</p>

    <h3><a name="match_pseudocode" id="match_pseudocode">5.5.1 Matching
    Semantics in Pseudocode</a></h3>

    <p>The standard matching semantics for rules in APPEL are as
    follows (compare with section <a href="#match_connectives">5.4.1
    Connectives</a>):</p>

    <blockquote>
      <p>An expression &quot; <b>E</b> &quot; matches a piece of
      evidence &quot; <b>X</b> &quot; (i.e. a certain XML element in
      the evidence) if and only if all of the following holds:</p>

      <ol>
        <li>the element names of <b>E</b> and <b>X</b> are
        identical</li>

        <li>all of <b>E</b> &#39;s attribute expressions match
        attributes of <b>X</b> (additional attributes in evidence
        <b>X</b> that are not referenced in expression <b>E</b> are
        ignored)</li>

        <li>[if an <code>or</code> connective is given in <b>E</b> ]
        <em>at least one</em> of <b>E</b> &#39;s contained expressions
        match <b>X</b> &#39;s enclosed elements or <code>#PCDATA</code>
        (additional enclosed elements or <code>#PCDATA</code> in
        evidence <b>X</b> that are not referenced in expression
        <b>E</b> are ignored). In case an element does not feature any
        contained expressions, matching always fails!</li>

        <li>[if an <code>and</code> connective, or if no connective is
        given in <b>E</b> ] <em>all</em> of <b>E</b> &#39;s contained
        expressions match <b>X</b> &#39;s enclosed elements and
        <code>#PCDATA</code> (additional enclosed elements and
        <code>#PCDATA</code> in evidence <b>X</b> that are not
        referenced in expression <b>E</b> are ignored).</li>

        <li>[if an <code>non-or</code> connective is given in <b>E</b>
        ] <em>none</em> of <b>E</b> &#39;s contained expressions match
        <b>X</b> &#39;s enclosed elements and <code>#PCDATA</code>
        (additional enclosed elements and <code>#PCDATA</code> in
        evidence <b>X</b> that are not referenced in expression
        <b>E</b> are ignored).</li>

        <li>[if an <code>non-and</code> connective is given in <b>E</b>
        ] <em>not all</em> of <b>E</b> &#39;s contained expressions
        match <b>X</b> &#39;s enclosed elements and
        <code>#PCDATA</code> (additional enclosed elements and
        <code>#PCDATA</code> in evidence <b>X</b> that are not
        referenced in expression <b>E</b> are ignored). In case an
        element does not feature any contained expressions, matching
        always fails!</li>

        <li>[if an <code>or-exact</code> connective is given in
        <b>E</b> ] <em>at least one</em> of <b>E</b> &#39;s contained
        expressions match <b>X</b> &#39;s enclosed elements or
        <code>#PCDATA</code> (additional enclosed elements or
        <code>#PCDATA</code> in evidence <b>X</b> that are not
        referenced in expression <b>E</b> are <em>not</em> ignored). In
        case element <b>E</b> does not feature any contained
        expressions, matching <em>always fails</em>!</li>

        <li>[if an <code>and-exact</code> connective is given in
        <b>E</b> ] <em>all</em> of <b>E</b> &#39;s contained
        expressions match <b>X</b> &#39;s enclosed elements and
        <code>#PCDATA</code> (additional enclosed elements and
        <code>#PCDATA</code> in evidence <b>X</b> that are not
        referenced in expression <b>E</b> are <em>not</em> ignored). In
        case element <b>E</b> does not feature any contained
        expressions, the corresponding element <b>X</b> in the evidence
        must also not contain any subelements or #PCDATA.</li>
      </ol>
    </blockquote>

    <h3><a name="match_algorithm" id="match_algorithm">5.5.2 Sample
    Matching Algorithm</a></h3>

    <p>In order to better understand the implications of the above
    distinctions in the matching process this sections lists a sample
    algorithm for implementing the matching semantics of APPEL1.0.</p>

    <blockquote>
      <p>For [ at least one | each ] <sup>*</sup> expression in the
      rule, find a match in the evidence such that the following
      conditions (C1-C3) [ do | do not ] <sup>*</sup> hold:</p>

      <table summary="Sample Matching Algorithm" cellpadding="4">
        <tbody>
          <tr>
            <th valign="top">C1</th>

            <td>the matching evidence is the same type of XML element
            as the rule expression (i.e. &lt;STATEMENT&gt;,
            &lt;POLICY&gt;, etc.)</td>
          </tr>

          <tr>
            <th valign="top">C2</th>

            <td>for every attribute-expression in the rule expression,
            an attriubte-expression exists in the evidence with the
            same attribute name and a value that matches according to
            the appropriate attribute-expression matching rules</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features an
            <code>or</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3a</th>

            <td>for <em>at least one</em> nested XML element or
            <code>#PCDATA</code> contained within the expression, C1
            through C3 are satisfied.</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features no
            connective, or an <code>and</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3b</th>

            <td>for <em>each</em> nested XML element and
            <code>#PCDATA</code> contained within the expression, C1
            through C3 are satisfied.</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features an
            <code>non-or</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3c</th>

            <td>for <em>none</em> of the nested XML element and
            <code>#PCDATA</code> contained within the expression, C1
            through C3 are satisfied.</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features an
            <code>non-and</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3d</th>

            <td>for <em>at least one</em> nested XML element and
            <code>#PCDATA</code> contained within the expression, C1
            through C3 are <b>not</b> satisfied.</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features an
            <code>or-exact</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3c</th>

            <td>for <em>each</em> nested XML element and
            <code>#PCDATA</code> <b>in the evidence</b>, C1 through C3
            are satisfied.</td>
          </tr>

          <tr>
            <th>
            </th>

            <td valign="top"><b>If the expressions features an
            <code>and-exact</code> connective:</b> </td>
          </tr>

          <tr>
            <th valign="top">C3d</th>

            <td>for <em>each</em> nested XML element and
            <code>#PCDATA</code> contained within the expression, and
            for <em>each</em> nested XML element and
            <code>#PCDATA</code> <b>in the evidence</b>, C1 through C3
            are satisfied.</td>
          </tr>
        </tbody>
      </table>

      <p>If a match [ can | can not ] <sup>*</sup> be found for [ at
      least one | each ] <sup>*</sup> expression, then the rule
      fires.</p>
    </blockquote>

    <p>* depending on the <code>appel:connective</code> used in the
    <code>&lt;appel:RULE&gt;</code> element (compare with C3a-C3d).</p>
    <hr />

    <h1><a name="appendices" id="appendices">Appendices</a></h1>
    <hr />

    <h1><a name="future" id="future">Appendix A: Future Work</a></h1>

    <p>When the first draft of this document was released, the working
    group felt that, although it had met the requirements it had set,
    the resulting language was complex and difficult to grasp fully. It
    was argued that as long no one actually tried to use this language
    in a real world application it would be hard to assess the
    suitability of the language design for expressing privacy
    preferences.</p>

    <p>As mentioned in section <a href="#requirements">1.3
    Requirements</a> above, an effort was made to simplify the
    specification in order to facilitate the implementation of early
    P3P user agents that would support rulesets expressed in APPEL. By
    separating a set of extensions from the core language (APPEL
    <b>1.0</b>) the working group hopes to encourage early adoptions of
    APPEL, allowing us to gain some first hand experiences with a
    privacy preference language before finalizing the full feature set
    of APPEL.</p>

    <p>In future revisions, the working group considers adding the
    following constructs to the syntax and semantics of the language
    that have so far been left out (i.e. in APPEL <b>1.0</b>) in order
    to allow for simple initial implementations:</p>

    <ul>
      <li><b>Extensible behaviors:</b> User Agents (e.g. browsers) can
      define their own set of behaviors and let rules use them. In
      order to preserve portability accross different user agents, a
      fallback mechanism guarantees that a <em>known</em> behavior is
      always executed.</li>

      <li><b>Matching external schemas:</b> Expressions can contain
      <code>&lt;POLICY&gt;</code> elements as well as external elements
      such as PICS labels or Protocol features (e.g. &quot;SSL in
      use&quot;).</li>

      <li><b>Optional rules:</b> Rules that are truly cosmetic can be
      ignored should a non-standard behavior be unknown to the
      particular user agent in use.</li>

      <li><b>Optional schemas:</b> Expressions can be tagged
      <em>optional</em> and thus allow rule execution even if a
      referenced schema is not available (e.g. no information about the
      status of the Protocol Security, no existing P3P policy,
      etc).</li>

      <li><b>Groups &amp; Triggers:</b> Sets of rules can be collated
      into <em>groups</em> allowing selective activation of certain
      privacy preferences depending on <em>triggers</em> such as URLs,
      PICS labels, etc.</li>

      <li><b>Comparison operators for simple numeric expressions:</b>
      Ranges of allowed values can be expressed by using common
      mathematical comparison operators such as &lt;, &gt;, &lt;=,
      &gt;=, etc.</li>

      <li><b>Expiration dates:</b> Rules and Groups can be set to
      expire at a certain point, allowing user agents (and users) to
      create temporary rules.</li>

      <li>
        <b>String-passing:</b> In order to create more informative
        <code>prompt</code> and <code>description</code> messages,
        <code>sprintf</code> -like placeholders can be used within
        those attributes-strings and will be replaced by the trust
        engine with corresponding values from the matched evidence.
        Examples for such placeholders would be: 

        <ul>
          <li><code>%cq</code> (consequence)</li>

          <li><code>%op</code> (other purpose)</li>

          <li><code>%oc</code> (other category)</li>

          <li><code>%rd</code> (recipient description)</li>

          <li><code>%si</code> (site name)</li>
        </ul>
      </li>
    </ul>

    <p>Comments to <a
    href="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</a>
    regarding the usability of current and planned features are highly
    encouraged.</p>

    <h1><a name="examples" id="examples">Appendix B: Ruleset
    Examples</a></h1>

    <h2><a name="b.1" id="b.1">B.1 ALMOST ANONYMOUS</a></h2>

    <p>This ruleset provides a nearly anonymous browsing experience. It
    prompts the user for a decision about Web sites that make an access
    disclosure other than &quot;identifiable data is not used.&quot; It
    also prompts for Web sites that collect physical contact
    information, online contact information, financial account
    identifiers, and data described as &quot;other&quot; data. All
    prompts imply that all but the absolutely necessary request headers
    should be suppressed if the user decides to access the resource. It
    allows for the collection of other kinds of data and the use of
    state management mechanisms as long as this data will not be
    shared, will not be used for contacting visitors for marking, will
    not be used for individual tailoring, and will not be used for
    purposes described as &quot;other&quot; uses. Users wishing to
    engage in electronic commerce activities that require the exchange
    of personal information such as payment and billing information
    will have to override these settings on a site by site basis.<br />
    </p>

    <div class="caption">
      <b>Figure B.1:</b> &quot;Almost Anonymous&quot; Ruleset
    </div>

    <div class="figure">
<pre>
&lt;appel:RULESET xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot;
         xmlns:p3p=&quot;http://www.w3.org/2000/12/P3Pv1&quot;
         crtdby=&quot;W3C&quot; crtdon=&quot;2000-03-15T10:55:32+01:00&quot;&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Service collects some kind of identifiable 
                           information&quot;
              promptmsg=&quot;Warning! Service collects some kind of identifiable 
                         information. Do you want to continue (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:ACCESS appel:connective=&quot;non-and&quot;&gt;
        &lt;p3p:nonident/&gt;
      &lt;/p3p:ACCESS&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Service collects physical and/or online 
                           contact information and/or financial account 
                           identifiers and/or other data that may be 
                           personally-identifiable&quot;
              promptmsg=&quot;Warning! Service collects physical and/or online 
                         contact information and/or financial account 
                         identifiers and/or other data that may be 
                         personally-identifiable. Do you want to 
                         continue (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:DATA-GROUP&gt;
          &lt;p3p:DATA&gt;
            &lt;p3p:CATEGORIES appel:connective=&quot;or&quot;&gt;
              &lt;p3p:physical/&gt;
              &lt;p3p:online/&gt;
              &lt;p3p:uniqueid/&gt;
              &lt;p3p:financial/&gt;
              &lt;p3p:other-category/&gt;
            &lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Service does not collect identifiable data or share
                           data with other parties&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;and-exact&quot;&gt;
          &lt;p3p:ours/&gt;
        &lt;/p3p:RECIPIENT&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;non-and&quot;&gt;
          &lt;p3p:contact/&gt;
          &lt;p3p:telemarketing/&gt;
          &lt;p3p:individual-analysis/&gt;
          &lt;p3p:individual-decision/&gt;
          &lt;p3p:other-purpose/&gt;
        &lt;/p3p:PURPOSE&gt;
        &lt;p3p:DATA-GROUP appel:connective=&quot;or-exact&quot;&gt;
          &lt;p3p:DATA ref=&quot;#user.*&quot;/&gt;
          &lt;p3p:DATA ref=&quot;#dynamic.*&quot;&gt;
       &lt;p3p:CATEGORIES&gt;&lt;state&gt;&lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; 
              description=&quot;Warning! Service requests data from your data 
                           repository or has a practice that doesn&#39;t match
                           your preferences&quot;&gt;
    &lt;appel:OTHERWISE/&gt;
  &lt;/appel:RULE&gt;
&lt;/appel:RULESET&gt;
</pre>
    </div>

    <h2><a name="b.2" id="b.2">B.2 PRIVACY AND COMMERCE</a></h2>

    <p>This ruleset allows users to exchange personal information
    needed for electronic commerce activities while providing warning
    prompts when that information may be shared with legal entities
    following different practices, public fora, or unrelated third
    parties; or used for marketing, tailoring, or &quot;other&quot;
    purposes. A warning prompt will also be provided if the site
    collects healthcare information. All warnings imply that all but
    the absolutely necessary request headers should be suppressed if
    the user decides to access the resource. An informational prompt
    will be provided at sites that provide no access to identifiable
    information.<br />
    </p>

    <div class="caption">
      <b>Figure B.2:</b> &quot;Privacy And Commerce&quot; Ruleset
    </div>

    <div class="figure">
<pre>
&lt;appel:RULESET xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; 
               xmlns:p3p=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
               crtdby=&quot;W3C&quot; crtdon=&quot;2000-03-15T16:41:21+01:00&quot;&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Data may be shared with legal entities 
                           following different practices, public fora, or
                           unrelated third parties.&quot;
              promptmsg=&quot;Warning! Data may be shared with legal entities 
                         following different practices, public fora, or
                         unrelated third parties. Do you want to continue 
                         (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;or&quot;&gt;
          &lt;p3p:other-recipient/&gt;
          &lt;p3p:public/&gt;
          &lt;p3p:unrelated/&gt;
        &lt;/p3p:RECIPIENT&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Data may be used for marketing, tailoring
                           or other purposes.&quot;
              promptmsg=&quot;Warning! Data may be used for marketing, tailoring
                         or other purposes. Do you want to continue (using
                         limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;or&quot;&gt;
          &lt;p3p:contact/&gt;
          &lt;p3p:tailoring/&gt;
          &lt;p3p:other-purpose/&gt;
        &lt;/p3p:PURPOSE&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Site collects healthcare information.&quot;&gt;
              promptmsg=&quot;Warning! Site collects healthcare information.
                         Do you want to continue (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:DATA-GROUP&gt;
          &lt;p3p:DATA&gt;
            &lt;p3p:CATEGORIES&gt;
              &lt;p3p:health/&gt;
            &lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
              description=&quot;Service does not provide access to identifiable data
                           it collects&quot;&gt;
              promptmsg=&quot;Service does not provide access to identifiable data
                    it collects. Do you want to continue anyway?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:ACCESS&gt;
        &lt;p3p:none/&gt;
      &lt;/p3p:ACCESS&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Privacy policy matches Privacy And Commerce
                           preferences&quot;&gt; 
    &lt;appel:OTHERWISE/&gt;
  &lt;/appel:RULE&gt;
&lt;/appel:RULESET&gt;
</pre>
    </div>

    <h2><a name="b.3" id="b.3">B.3 LOOK FOR THE SEAL</a></h2>

    <p>This ruleset allows users to exchange any type of personal
    information for any purpose with Web sites that have either a
    &quot;PrivacyProtect&quot; or &quot;TrustUs&quot; seal as long as
    those sites do not share the information with unrelated third
    parties. It also allows users to exchange personal information
    needed for electronic commerce activities with any site, while
    providing warning prompts (and suppressing unnecessary request
    headers) when that information may be shared with legal entities
    following different practices, public fora, or unrelated third
    parties; or used for marketing, tailoring, or &quot;other&quot;
    purposes by sites that do not have a seal. An informational prompt
    will be provided at sites that have seals and collect healthcare
    information; a warning prompt (again, suppressing all unnecessary
    headers) will be provided at sites that do not have seals and
    collect healthcare information. An informational prompt will be
    provided at sites that provide no access.<br />
    </p>

    <div class="caption">
      <b>Figure B.3:</b> &quot;Look For The Seal&quot; Ruleset
    </div>

    <div class="figure">
<pre>
&lt;appel:RULESET xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot;
               xmlns:p3p=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
               crtdby=&quot;W3C&quot; crtdon=&quot;2001-02-19T16:21:21+01:00&quot;&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Service has privacy seal and does not share data
                           with unrelated third parties.&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:DISPUTES-GROUP appel:connective=&quot;or&quot;&gt;
        &lt;p3p:DISPUTES resolution-type=&quot;independent&quot; 
                      service=&quot;http://www.privacyprotect.org/*&quot;/&gt;
        &lt;p3p:DISPUTES resolution-type=&quot;independent&quot; 
                      service=&quot;http://www.trustus.org/*&quot;/&gt;
      &lt;/p3p:DISPUTES-GROUP&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;non-and&quot;&gt;
          &lt;p3p:unrelated/&gt;
        &lt;/p3p:RECIPIENT&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Service collects data needed for e-commerce
                           activities but may share this data with legal
                           entities following different practices, public fora,
                           or unrelated third parties.&quot;&gt;
              promptmsg=&quot;Warning! Service collects data needed for e-commerce
                         activities but may share this data with legal
                         entities following different practices, public fora,
                         or unrelated third parties. Do you want to continue
                         (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;and-exact&quot;&gt;
          &lt;p3p:current/&gt;
        &lt;/p3p:PURPOSE&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;or&quot;&gt;
          &lt;p3p:other-recipient/&gt;
          &lt;p3p:public/&gt;
          &lt;p3p:unrelated/&gt;
        &lt;/p3p:RECIPIENT&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Service collects data needed for e-commerce 
                           activities but may use it also for marketing,
                           tailoring, or &#39;other&#39; purposes.&quot;&gt;
              promptmsg=&quot;Warning! Service collects data needed for e-commerce 
                         activities but may use it also for marketing,
                         tailoring, or &#39;other&#39; purposes. Do you still
                         want to continue (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:PURPOSE&gt;
          &lt;p3p:current/&gt;
        &lt;/p3p:PURPOSE&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;or&quot;&gt;
          &lt;p3p:contact/&gt;
          &lt;p3p:tailoring/&gt;
          &lt;p3p:other-purpose/&gt;
        &lt;/p3p:PURPOSE&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
              description=&quot;Site collects healthcare information but
                           participates in a seal program.&quot;&gt;
              promptmsg=&quot;FYI: This site collects healthcare information but
                         participates in a seal program. Continue?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:DISPUTES-GROUP&gt;
        &lt;p3p:DISPUTES p3p:resolution-type=&quot;independent&quot; p3p:service=&quot;*&quot;/&gt;
      &lt;/p3p:DISPUTES-GROUP&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:DATA-GROUP&gt;
          &lt;p3p:DATA&gt;
            &lt;p3p:CATEGORIES&gt;
              &lt;p3p:health/&gt;
            &lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Site collects healthcare information but
                           does not participate in a seal program.&quot;&gt;
              promptmsg=&quot;Warning! Site collects healthcare information but does not
                         participate in a seal program. Do you want to continue anyway&quot;&gt;
                         (using limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:DATA-GROUP&gt;
          &lt;p3p:DATA&gt;
            &lt;p3p:CATEGORIES&gt;
              &lt;p3p:health/&gt;
            &lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Service collects data needed for e-commerce
                           activities only, without sharing with legal entities
                           following different practices, public fora or
                           unrelated third parties.  A seal program vouches for
                           this.&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:DISPUTES-GROUP&gt;
        &lt;p3p:DISPUTES p3p:resolution-type=&quot;independent&quot; p3p:service=&quot;*&quot;/&gt;
      &lt;/p3p:DISPUTES-GROUP&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;and-exact&quot;&gt;
          &lt;p3p:current/&gt;
        &lt;/p3p:PURPOSE&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;or-exact&quot;&gt;
          &lt;p3p:ours/&gt;
          &lt;p3p:same/&gt;
          &lt;p3p:delivery/&gt;
        &lt;/p3p:RECIPIENT&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;limited&quot; prompt=&quot;yes&quot; 
              description=&quot;Service does not provide access to
                           identifiable data it collects&quot;&gt;
              promptmsg=&quot;Warning! Service does not provide access to identifiable 
                         data it collects. Do you want to continue anyway (using 
                         limited access)?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:ACCESS&gt;
        &lt;p3p:none/&gt;
      &lt;/p3p:ACCESS&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Privacy policy matches Look For The Seal
                           preferences&quot;&gt; 
    &lt;appel:OTHERWISE/&gt;
  &lt;/appel:RULE&gt;
&lt;/appel:RULESET&gt;
</pre>
    </div>

    <h2><a name="b.4" id="b.4">B.4 INFORMATION ONLY</a></h2>

    <p>This ruleset allows users to exchange any type of personal
    information for any purpose. However, it provides informational
    prompts when sites collect data for marketing, pseudonymous or
    individual tailoring, or &quot;other&quot; purposes; share data
    with legal entities following different practices, public fora, or
    unrelated third parties; or collect healthcare information.<br />
    </p>

    <div class="caption">
      <b>Figure B.4:</b> &quot;Information Only&quot; Ruleset
    </div>

    <div class="figure">
<pre>
&lt;appel:RULESET xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; 
               xmlns:p3p=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
               crtdby=&quot;W3C&quot; crtdon=&quot;2001-02-19T16:04:02+01:00&quot;&gt;
  &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
              description=&quot;Service collects data for marketing, tailoring, or
                           &#39;other&#39; purposes.&quot;&gt;
              promptmsg=&quot;FYI: This service collects data for marketing, 
                         tailoring, or &#39;other&#39; purposes. Continue?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:PURPOSE appel:connective=&quot;or&quot;&gt;
          &lt;p3p:contact/&gt;
          &lt;p3p:telemarketing/&gt;
          &lt;p3p:pseudo-analysis/&gt;
          &lt;p3p:pseudo-decision/&gt;
          &lt;p3p:individual-analysis/&gt;
          &lt;p3p:individual-decision/&gt;
          &lt;p3p:other-purpose/&gt;
        &lt;/p3p:PURPOSE&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
              description=&quot;Service shares information with legal entities
                           following different practices, public fora, or
                           unrelated third parties.&quot;&gt;
              promptmsg=&quot;FYI: This service shares information with legal entities
                         following different practices, public fora, or
                         unrelated third parties. Continue anyway?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:RECIPIENT appel:connective=&quot;or&quot;&gt;
          &lt;p3p:other-recipient/&gt;
          &lt;p3p:public/&gt;
          &lt;p3p:unrelated/&gt;
        &lt;/p3p:RECIPIENT&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; prompt=&quot;yes&quot; 
              description=&quot;Site collects healthcare information.&quot;&gt;
              promptmsg=&quot;FYI: Site collects healthcare information. Continue?&quot;&gt;
    &lt;p3p:POLICY&gt;
      &lt;p3p:STATEMENT&gt;
        &lt;p3p:DATA-GROUP&gt;
          &lt;p3p:DATA&gt;
            &lt;p3p:CATEGORIES&gt;
              &lt;p3p:health/&gt;
            &lt;/p3p:CATEGORIES&gt;
          &lt;/p3p:DATA&gt;
        &lt;/p3p:DATA-GROUP&gt;
      &lt;/p3p:STATEMENT&gt;
    &lt;/p3p:POLICY&gt;
  &lt;/appel:RULE&gt;
  &lt;appel:RULE behavior=&quot;request&quot; 
              description=&quot;Privacy policy matches Information Only
                           preferences&quot;&gt; 
    &lt;appel:OTHERWISE/&gt;
  &lt;/appel:RULE&gt;
&lt;/appel:RULESET&gt;
</pre>
    </div>

    <h2><a name="xmlschema" id="xmlschema">Appendix C: XML Schema
    Definition</a> (normative)</h2>

    <p>This appendix contains the XML schema [ <a href="#xsd1">XML
    Schema 1</a>, <a href="#xsd2">XML Schema 2</a> ] for APPEL ruleset
    documents. An XML schema may be used to validate the structure and
    datastruct values used in an instance of the schema given as an XML
    document. APPEL ruleset documents are XML documents that MUST
    conform to this schema. The schema is also present as a separate
    file at the URI <!-- 
                <a href="http://www.w3.org/2002/04/APPELv1.xsd"> -->
     <a href="APPELv1-20020415.xsd">APPELv1-20020415.xsd</a></p>
<pre class="xsd">
&lt;?xml version=&#39;1.0&#39; encoding=&#39;UTF-8&#39;?&gt;
&lt;schema targetNamespace=&quot;http://www.w3.org/2002/04/APPELv1&quot; 
        xmlns=&quot;http://www.w3.org/2000/10/XMLSchema&quot; 
        xmlns:appel=&quot;http://www.w3.org/2002/04/APPELv1&quot; 
        elementFormDefault=&quot;qualified&quot;&gt;
  &lt;!-- ********* APPEL Data Types ******** --&gt;
  &lt;simpleType name=&quot;yes_no&quot;&gt;
    &lt;restriction base=&quot;string&quot;&gt;
      &lt;enumeration value=&quot;yes&quot;/&gt;
      &lt;enumeration value=&quot;no&quot;/&gt;
    &lt;/restriction&gt;
  &lt;/simpleType&gt;
  &lt;simpleType name=&quot;connective-value&quot;&gt;
    &lt;restriction base=&quot;string&quot;&gt;
      &lt;enumeration value=&quot;or&quot;/&gt;
      &lt;enumeration value=&quot;and&quot;/&gt;
      &lt;enumeration value=&quot;non-or&quot;/&gt;
      &lt;enumeration value=&quot;non-and&quot;/&gt;
      &lt;enumeration value=&quot;or-exact&quot;/&gt;
      &lt;enumeration value=&quot;and-exact&quot;/&gt;
    &lt;/restriction&gt;
  &lt;/simpleType&gt;
  &lt;simpleType name=&quot;behavior-value&quot;&gt;
    &lt;restriction base=&quot;string&quot;&gt;
      &lt;enumeration value=&quot;request&quot;/&gt;
      &lt;enumeration value=&quot;block&quot;/&gt;
      &lt;enumeration value=&quot;limited&quot;/&gt;
    &lt;/restriction&gt;
  &lt;/simpleType&gt;
  &lt;attributeGroup name=&quot;common-attributes&quot;&gt;
    &lt;attribute name=&quot;crtdby&quot; type=&quot;string&quot; use=&quot;optional&quot;/&gt;
    &lt;attribute name=&quot;crtdon&quot; type=&quot;timeInstant&quot; use=&quot;optional&quot;/&gt;
    &lt;attribute name=&quot;description&quot; type=&quot;string&quot; use=&quot;optional&quot;/&gt;
  &lt;/attributeGroup&gt;
  &lt;!-- ************ RULESET ************* --&gt;
  &lt;element name=&quot;RULESET&quot;&gt;
    &lt;complexType&gt;
      &lt;sequence&gt;
        &lt;element ref=&quot;appel:RULE&quot; maxOccurs=&quot;unbounded&quot;/&gt;
      &lt;/sequence&gt;
      &lt;attributeGroup ref=&quot;appel:common-attributes&quot;/&gt;
    &lt;/complexType&gt;
  &lt;/element&gt;
  &lt;!-- ************** RULE ************** --&gt;
  &lt;element name=&quot;RULE&quot;&gt;
    &lt;complexType&gt;
      &lt;choice&gt;
        &lt;element ref=&quot;appel:OTHERWISE&quot;/&gt;
        &lt;sequence&gt;
          &lt;element ref=&quot;appel:REQUEST-GROUP&quot; minOccurs=&quot;0&quot;/&gt;
          &lt;any namespace=&quot;http://www.w3.org/2000/12/P3Pv1&quot; 
               processContents=&quot;skip&quot; minOccurs=&quot;0&quot;/&gt;
        &lt;/sequence&gt;
      &lt;/choice&gt;
      &lt;attribute name=&quot;behavior&quot; type=&quot;appel:behavior-value&quot; use=&quot;required&quot;/&gt;
      &lt;attribute name=&quot;connective&quot; type=&quot;appel:connective-value&quot; use=&quot;optional&quot;/&gt;
      &lt;attribute name=&quot;prompt&quot; type=&quot;appel:yes_no&quot; use=&quot;default&quot; value=&quot;no&quot;/&gt;
      &lt;attribute name=&quot;persona&quot; type=&quot;string&quot; use=&quot;optional&quot;/&gt;
      &lt;attribute name=&quot;promptmsg&quot; type=&quot;string&quot; use=&quot;optional&quot;/&gt;
      &lt;attributeGroup ref=&quot;appel:common-attributes&quot;/&gt;
    &lt;/complexType&gt;
  &lt;/element&gt;
  &lt;!-- ********* REQUEST-GROUP ********** --&gt;
  &lt;element name=&quot;REQUEST-GROUP&quot;&gt;
    &lt;complexType&gt;
      &lt;sequence&gt;
        &lt;element ref=&quot;appel:REQUEST&quot; maxOccurs=&quot;unbounded&quot;/&gt;
      &lt;/sequence&gt;
      &lt;attribute name=&quot;connective&quot; type=&quot;appel:connective-value&quot; use=&quot;optional&quot;/&gt;
    &lt;/complexType&gt;
  &lt;/element&gt;
  &lt;!-- ************* REQUEST ************ --&gt;
  &lt;element name=&quot;REQUEST&quot;&gt;
    &lt;complexType&gt;
      &lt;attribute name=&quot;uri&quot; type=&quot;string&quot; use=&quot;required&quot;/&gt;
    &lt;/complexType&gt;
  &lt;/element&gt;
  &lt;!-- ************* OTHERWISE ************* --&gt;
  &lt;element name=&quot;OTHERWISE&quot;&gt;
    &lt;complexType/&gt;
  &lt;/element&gt;
&lt;/schema&gt;
</pre>

    <h2><a name="dtd" id="dtd">Appendix D: Document Type Definition
    (DTD)</a> (informative)</h2>

    <p>This appendix contains the DTD for policy documents and for data
    schemas. The DTD is also present as a separate file at the URI 
    <!-- <a
                href="http://www.w3.org/2002/04/APPELv1.dtd"> -->
     <a href="APPELv1-20020415.dtd">APPELv1-20020415.dtd</a></p>
<pre class="dtd">
&lt;!-- ************ Entities ************ --&gt;
&lt;!ENTITY % URI &quot;CDATA&quot;&gt;
&lt;!ENTITY % TIME &quot;CDATA&quot;&gt;

&lt;!-- ************ RULESET ************* --&gt;
&lt;!ELEMENT RULESET (RULE+)&gt;
&lt;!ATTLIST RULESET
  xmlns       CDATA  #FIXED &#39;http://www.w3.org/2002/04/APPELv1&#39;
  crtdby      CDATA  #IMPLIED
  crtdon      %TIME; #IMPLIED
  description CDATA  #IMPLIED &gt;

&lt;!-- ************** RULE ************** --&gt;
&lt;!ELEMENT RULE ANY&gt;
&lt;!ATTLIST RULE
  connective  (or | and | non-or | non-and | or-exact | and-exact) #IMPLIED
  behavior    (request | block | limited) #REQUIRED
  prompt      (yes | no) #IMPLIED
  persona     CDATA      #IMPLIED
  promptmsg   CDATA      #IMPLIED
  crtdby      CDATA      #IMPLIED
  crtdon      %TIME;     #IMPLIED
  description CDATA      #IMPLIED &gt;

&lt;!-- ********* REQUEST-GROUP ********** --&gt;
&lt;!ELEMENT REQUEST-GROUP (REQUEST+)&gt;
&lt;!ATTLIST REQUEST-GROUP
  connective  (or | and | non-or | non-and | or-exact | and-exact) #IMPLIED &gt; 

&lt;!-- ************* REQUEST ************ --&gt;
&lt;!ELEMENT REQUEST EMPTY&gt;
&lt;!ATTLIST REQUEST
  uri %URI; #REQUIRED &gt;
</pre>

    <h2><a name="abnf" id="abnf">Appendix E: ABNF Notation</a>
    (informative)</h2>

    <p>The formal grammar of APPEL is given in this specification using
    a slight modification of [ <a href="#ABNF">ABNF</a> ]. Please note
    that such syntax is only a grammar representative of the XML
    syntax: all the syntactic flexibilities of XML are also implicitly
    included; e.g. whitespace rules, quoting using either single quote
    (&#39;) or double quote (&quot;), <a
    href="http://www.w3.org/TR/REC-xml#dt-chardata">character
    escaping</a>, comments, and case sensitivity. In addition, note
    that attributes and elements may appear in any order.</p>

    <p>The following is a simple description of the ABNF.</p>

    <dl>
      <dt><code class="c3">name = (elements)&#160;</code></dt>

      <dd>where &lt;name&gt; is the name of the rule, &lt;elements&gt;
      is one or more rule names or terminals combined through the
      operands provided below. Rule names are
      case-insensitive.&#160;</dd>

      <dt><code>(</code> <code class="c3">element1
      element2)</code></dt>

      <dd>elements enclosed in parentheses are treated as a single
      element, whose contents are strictly ordered.</dd>

      <dt><code class="c3">&lt;a&gt;*&lt;b&gt;element</code></dt>

      <dd>at least &lt;a&gt; and at most &lt;b&gt; occurrences of the
      element.</dd>

      <dd><em>(1*4&lt;element&gt; means one to four
      elements.)</em></dd>

      <dt><code class="c3">&lt;a&gt;element</code></dt>

      <dd>exactly &lt;a&gt; occurrences of the element.</dd>

      <dd><em>(4&lt;element&gt; means exactly 4 elements.)</em></dd>

      <dt><code class="c3">&lt;a&gt;*element</code></dt>

      <dd>&lt;a&gt; or more elements</dd>

      <dd><em>(4*&lt;element&gt; means 4 or more elements.)</em></dd>

      <dt><code class="c3">*&lt;b&gt;element</code></dt>

      <dd>0 to &lt;b&gt; elements.</dd>

      <dd><em>(*5&lt;element&gt; means 0 to 5 elements.)</em></dd>

      <dt><code class="c3">*element</code></dt>

      <dd>0 or more elements.</dd>

      <dd><em>(*&lt;element&gt; means 0 to infinite
      elements.)</em></dd>

      <dt><code class="c3">[element]</code></dt>

      <dd>optional element, equivalent to *1(element).</dd>

      <dd><em>([element] means 0 or 1 element.)</em></dd>

      <dt><code class="c3">&quot;string&quot;</code> or <code
      class="c3">&#39;string&#39;</code></dt>

      <dd>matches the literal string given inside double quotes.</dd>
    </dl>

    <p>Other notations used in the productions are:</p>

    <dl>
      <dt>; or <b><code>/* ... */</code></b></dt>

      <dd>comment.</dd>
    </dl>

    <h1><a name="related" id="related">Appendix F: Trust Engines and
    Database Engines</a></h1>

    <p>While a special-purpose APPEL engine might be built for use in a
    P3P user agent, P3P implementors might also consider using an
    existing database engine or trust engine for this purpose. For
    example, an SQL engine or an engine for the Keynote Trust
    Management System [ <a href="#keynote">Keynote</a> ] might prove
    useful. Use of one of these engines would likely require that the
    APPEL syntax be translated into the syntax expected by the engine.
    This could likely be done trivially by a translation script. The
    Working Group encourages experimentation in this area.</p>

    <h1><a name="contrib" id="contrib">Appendix G: Working Group
    Contributors</a></h1>

    <table summary="Working group contributors">
      <tbody>
        <tr>
          <td>Nikolaj Budzyn</td>

          <td>Christian-Albrechts-University of Kiel</td>
        </tr>

        <tr>
          <td>Lorrie Cranor</td>

          <td>AT&amp;T Labs-Research</td>
        </tr>

        <tr>
          <td>Matthias Enzmann</td>

          <td>GMD</td>
        </tr>

        <tr>
          <td>Marit Köhntopp</td>

          <td>Independent Center for Privacy Protection
          Schleswig-Holstein</td>
        </tr>

        <tr>
          <td>Yuichi Koike</td>

          <td>NEC</td>
        </tr>

        <tr>
          <td>Marc Langheinrich</td>

          <td>ETH Zürich (Editor &amp; Chair)</td>
        </tr>

        <tr>
          <td>Massimo Marchiori</td>

          <td>W3C</td>
        </tr>

        <tr>
          <td>Joerg Meyer</td>

          <td>IBM</td>
        </tr>

        <tr>
          <td>Joseph Reagle</td>

          <td>W3C</td>
        </tr>

        <tr>
          <td>Drummond Reed</td>

          <td>OneName</td>
        </tr>

        <tr>
          <td>Rigo Wenning</td>

          <td>W3C</td>
        </tr>

        <tr>
          <td>Mary Ellen Zurko</td>

          <td>Iris (former Chair)</td>
        </tr>
      </tbody>
    </table>

    <h1><a name="references" id="references">References</a></h1>

    <dl>
      <dt><a name="URI" id="URI">[URI]</a></dt>

      <dd>T. Berners-Lee, R. Fielding, and L. Masinter. <a
      href="http://www.ietf.org/rfc/rfc2369.txt">&quot;RFC2396 --
      Uniform Resource Identifiers (URI): Generic Syntax and
      Semantics.&quot;</a> August 1998. See <a
      href="http://www.ietf.org/rfc/rfc2369.txt">/rfc/rfc2369.txt</a>
      at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.
      (updates <a
      href="http://www.ietf.org/rfc/rfc1738.txt">RFC1738</a>)</dd>

      <dt><a name="xsd2" id="xsd2">[XML-Schema 2]</a></dt>

      <dd>Paul V. Biron, Ashok Malhotra (editors), <a
      href="http://www.w3.org/TR/xmlschema-2/">&quot;XML Schema Part 2:
      Datatypes&quot;</a> 24 October 2000. W3C Candidate
      Recommendation. See <a
      href="http://www.w3.org/TR/xmlschema-2/">/TR/xmlschema-2/</a> at
      <a href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="keynote" id="keynote">[Keynote]</a></dt>

      <dd>Blaze, Feigenbaum, Keromytis, <a
      href="http://www.cis.upenn.edu/~angelos/keynote.html">&quot;Keynote
      Trust Management System&quot;</a>.</dd>

      <dt><a name="RFC2119" id="RFC2119">[RFC 2119]</a></dt>

      <dd>S. Bradner, <a
      href="http://www.ietf.org/rfc/rfc2119.txt">&quot;Key words for
      use in RFCs to Indicate Requirement Levels&quot;</a> See <a
      href="http://www.ietf.org/rfc/rfc2119.txt">/rfc/rfc2119.txt</a>
      at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.</dd>

      <dt><a name="XML" id="XML">[XML]</a></dt>

      <dd>Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, <a
      href="http://www.w3.org/TR/REC-xml">&quot;Extensible Markup
      Language (XML) 1.0 (Second Edition)&quot;</a> 14 January 1999 <a
      href="http://www.w3.org/">World Wide Web Consortium</a>
      Recommendation. See <a
      href="http://www.w3.org/TR/REC-xml">/TR/REC-xml</a> at <a
      href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="RFC822" id="RFC822">[RFC 822]</a></dt>

      <dd>David H. Crocker (editor), <a
      href="http://www.faqs.org/rfcs/rfc822.html">Standard for the
      format of ARPA Internet text messages</a> See <a
      href="http://www.faqs.org/rfcs/rfc822.html">/rfc/rfc822.txt</a>
      at <a href="http://www.faqs.org/">http://www.faqs.org/</a>.</dd>

      <dt><a name="ABNF" id="ABNF">[ABNF]</a></dt>

      <dd>D. Crocker, P. Overel. &quot; <a
      href="http://www.ietf.org/rfc/rfc2234.txt">RFC2234 -- Augmented
      BNF for Syntax Specifications: ABNF</a>,&quot; Internet Mail
      Consortium, Demon Internet Ltd., November 1997. See <a
      href="http://www.ietf.org/rfc/rfc2119.txt">/rfc/rfc2119.txt</a>
      at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.</dd>

      <dt><a name="PICSRules" id="PICSRules">[PICSRules]</a></dt>

      <dd>Christopher Evans, Clive D.W. Feather, Alex Hopmann, Martin
      Presler-Marshall, Paul Resnick, <a
      href="http://www.w3.org/TR/REC-PICSRules">&quot;PICSRules
      Specification&quot;</a> 29 December 1997. See <a
      href="http://www.w3.org/TR/REC-PICSRules">/TR/REC-PICSRules</a>
      at <a href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="RFC2616" id="RFC2616">[RFC 2616]</a></dt>

      <dd>R. Fielding et al, <a
      href="http://www.ietf.org/rfc/rfc2616.txt">&quot;RFC2616 --
      Hypertext Transfer Protocol -- HTTP/1.1&quot;</a> June 1999. See
      <a
      href="http://www.ietf.org/rfc/rfc2616.txt">/rfc/rfc2616.txt</a>
      at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.
      (updates <a
      href="http://www.ietf.org/rfc/rfc2616.txt">RFC2068</a>)</dd>

      <dt><a name="bib_iso8601" id="bib_iso8601">[ISO8601]</a></dt>

      <dd>&quot;ISO8601: Data elements and interchange formats --
      Information interchange -- Representation of dates and
      times.&quot; International Organization for Standardization.</dd>

      <dt><a name="bib_rdf" id="bib_rdf">[RDF]</a></dt>

      <dd>Ora Lassila, Ralph R. Swick (editors), <a
      href="http://www.w3.org/TR/REC-rdf-syntax/">&quot;Resource
      Description Framework (RDF) Model and Syntax
      Specification&quot;</a> 22 February 1999. See <a
      href="http://www.w3.org/TR/REC-rdf-syntax/">/TR/REC-rdf-syntax</a>
      at <a href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="P3P10" id="P3P10">[P3P10]</a></dt>

      <dd>Massimo Marchiori (editor), <a
      href="http://www.w3.org/TR/P3P/">&quot;Platform for Privacy
      Preferences 1.0 (P3P1.0) Specification&quot;</a> 16 April 2002.
      <a href="http://www.w3.org/">World Wide Web Consortium</a>
      Recommendation. See <a
      href="http://www.w3.org/TR/P3P/">/TR/P3P/</a> at <a
      href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="xsd1" id="xsd1">[XML-Schema 1]</a></dt>

      <dd>Henry S. Thompson, David Beech, Murray Maloney, Noah
      Mendelsohn (editors), <a
      href="http://www.w3.org/TR/xmlschema-1/">&quot;XML Schema Part 1:
      Structures&quot;</a> 24 October 2000. W3C Candidate
      Recommendation. See <a
      href="http://www.w3.org/TR/xmlschema-1/">/TR/xmlschema-1/</a> at
      <a href="http://www.w3.org/">http://www.w3.org/</a></dd>

      <dt><a name="utf8" id="utf8">[UTF-8]</a></dt>

      <dd>F. Yergeau. <a
      href="http://www.ietf.org/rfc/rfc2279.txt">&quot;RFC 2279 --
      UTF-8, a transformation format of ISO 10646.&quot;</a> January
      1998. See See <a
      href="http://www.ietf.org/rfc/rfc2279.txt">/rfc/rfc2279.txt</a>
      at <a href="http://www.ietf.org/">http://www.ietf.org/</a></dd>
    </dl>
    <hr />

    <p><a href="http://validator.w3.org/check/referer"><img
    src="http://validator.w3.org/images/vxhtml10"
    alt="Valid XHTML 1.0!" height="31" width="88" /></a> <a
    href="http://jigsaw.w3.org/css-validator/"><img class="c2"
    src="http://jigsaw.w3.org/css-validator/images/vcss.gif"
    alt="Valid CSS!" /></a></p>
  </body>
</html>