discontinued / server · Files

NOTE-ws-policy-primer-20071112 164 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 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang=
"en-US">
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
<meta http-equiv="Content-Type" content=
"text/html; charset=utf-8" />
<title>Web Services Policy 1.5 - Primer</title>

<style type="text/css">
/*<![CDATA[*/
/**/
code           { font-family: monospace; }

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

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

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

.diff-chg       { background-color: yellow; }
.diff-del       { background-color: red; text-decoration: line-through;}
.diff-add       { background-color: lime; }

table          { empty-cells: show; }

table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}

div.issue {
  color: red;
}
.rfc2119 {
  font-variant: small-caps;
}

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

div.boxedtext {
   border: solid #bebebe 1px;
   margin: 2em 1em 1em 2em;
 }

span.practicelab {
   margin: 1.5em 0.5em 1em 1em;
   font-weight: bold;
   font-style: italic;
 }

span.practicelab   { background: #dfffff; }

 span.practicelab {
   position: relative;
   padding: 0 0.5em;
   top: -1.5em;
 }
p.practice
{
   margin: 1.5em 0.5em 1em 1em;
 }

@media screen {
 p.practice {
   position: relative;
   top: -2em;
   padding: 0;
   margin: 1.5em 0.5em -1em 1em;
}
}
/**/
/*]]>*/
</style>
<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img src=
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
"72" /></a></p>
<h1><a name="title" id="title"></a>Web Services Policy 1.5 -
Primer</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group
Note 12 November 2007</h2>
<dl>
<dt>This version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112">http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112</a></dd>
<dt>Latest version:</dt>
<dd><a href=
"http://www.w3.org/TR/ws-policy-primer">http://www.w3.org/TR/ws-policy-primer</a></dd>
<dt>Previous version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/WD-ws-policy-primer-20070928">http://www.w3.org/TR/2007/WD-ws-policy-primer-20070928</a></dd>
<dt>Editors:</dt>
<dd>Asir S Vedamuthu, Microsoft Corporation</dd>
<dd>David Orchard, BEA Systems, Inc.</dd>
<dd>Frederick Hirsch, Nokia</dd>
<dd>Maryann Hondo, IBM Corporation</dd>
<dd>Prasad Yendluri, webMethods (A subsidiary of Software AG)</dd>
<dd>Toufic Boubez, Layer 7 Technologies</dd>
<dd>Ümit Yalçinalp, SAP AG.</dd>
</dl>
<p>This document is also available in these non-normative formats:
<a href="ws-policy-primer.pdf">PDF</a>, <a href=
"ws-policy-primer.ps">PostScript</a>, <a href=
"ws-policy-primer.xml">XML</a>, and&nbsp;<a href=
"ws-policy-primer.txt">plain text</a>.</p>
<p class="copyright"><a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;2007&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><acronym title=
"Massachusetts Institute of Technology">MIT</acronym></a>, <a href=
"http://www.ercim.org/"><acronym title=
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
W3C <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr />
<div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
<p><em>Web Services Policy 1.5 - Primer</em> is an introductory
description of the Web Services Policy language. This document
describes the policy language features using numerous examples. The
associated Web Services Policy 1.5 - Framework and Web Services
Policy 1.5 - Attachment specifications provide the complete
normative description of the Web Services Policy language.</p>
</div>
<div>
<h2><a name="status" id="status"></a>Status of this Document</h2>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href=
"http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>
<p>This is a <a href=
"http://www.w3.org/2004/02/Process-20040205/tr#WGNote">W3C Working
Group Note</a> of the Web Services Policy 1.5 - Primer
specification, developed by the members of the <a href=
"http://www.w3.org/2002/ws/policy/">Web Services Policy Working
Group</a>, which is part of the <a href=
"http://www.w3.org/2002/ws/Activity">W3C Web Services
Activity</a>.</p>
<p>A list of <a href="#change-description">changes in this version
of the document</a> and a <a href=
"ws-policy-primer-diff20070928.html">diff-marked version against
the previous version of this document</a> are available. Please
send comments about this document to the <a href=
"mailto:public-ws-policy-comments@w3.org">public-ws-policy-comments@w3.org</a>
mailing list (<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-comments/">public
archive</a>) with a subject that is prefaced with
[ws-policy-primer].</p>
<p>Publication as a Working Group Note does not imply endorsement
by the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in
progress.</p>
<p>This document was produced by a group operating under the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
February 2004 W3C Patent Policy</a>. W3C maintains a <a href=
"http://www.w3.org/2004/01/pp-impl/39293/status">public list of any
patent disclosures</a> made in connection with the deliverables of
the group; that page also includes instructions for disclosing a
patent. An individual who has actual knowledge of a patent which
the individual believes contains <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
Essential Claim(s)</a> must disclose the information in accordance
with <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
section 6 of the W3C Patent Policy</a>.</p>
</div>
<div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
<p class="toc">1. <a href="#introduction">Introduction</a><br />
2. <a href="#basic-concepts-policy-expression">Basic Concepts:
Policy Expression</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#web-services-policy">Web
Services Policy</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#simple-message">Simple
Message</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#secure-message">Secure
Message</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#other-assertions">Other
Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.5 <a href=
"#combining-policy-assertions">Combining Policy
Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.6 <a href=
"#optional-policy-assertion">Optional Policy Assertion</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.7 <a href=
"#ignorable-policy-assertions">Ignorable Policy
Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.8 <a href=
"#Both-Optional-Ignorable">Marking Assertions both Optional and
Ignorable</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.9 <a href=
"#nested-policy-expressions">Nested Policy Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.10 <a href=
"#Referencing_Policy_Expressions">Referencing Policy
Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.11 <a href=
"#attaching-policy-expressions-to-wsdl">Attaching Policy
Expressions to WSDL</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.12 <a href=
"#policy-automates-web-services-interaction">Policy Automates Web
Services Interaction</a><br />
3. <a href="#advanced-concepts-policy-expression">Advanced
Concepts: Policy Expression</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#policy-expression">Policy
Expression</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href=
"#normal-form-for-policy-expressions">Normal Form for Policy
Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#policy-data-model">Policy
Data Model</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href=
"#compatible-policies">Compatible Policies</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.4.1 <a href=
"#strict-lax-policy-intersection">Strict and Lax Policy
Intersection</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.5 <a href=
"#attaching-policy-expressions-to-wsdl2">Attaching Policy
Expressions to WSDL</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.6 <a href="#policy-retrieval">Policy
Retrieval</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.7 <a href="#combine-policies">Combine
Policies</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.8 <a href=
"#extensibility-and-versioning">Extensibility and
Versioning</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.1 <a href=
"#ext-vers-policylanguage">Policy Language</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href=
"#d3e1496">Policy Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.3 <a href=
"#ignorable-and-versioning">Use of Ignorable attribute and an
alternative Versioning Scenario</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.4 <a href=
"#ignorable-and-optional-and-versioning">Use of Ignorable and
Optional attributes</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;3.9 <a href=
"#parts-of-a-policy-assertion">Parts of a Policy
Assertion</a><br />
4. <a href="#versioning-policy-language">Versioning Policy
Language</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href=
"#versioning-policy-framework">Policy Framework</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href=
"#versioning-policy-attachment">Policy Attachment</a><br />
5. <a href="#conclusion">Conclusion</a><br /></p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3>
<p class="toc">A. <a href="#security-considerations">Security
Considerations</a><br />
B. <a href="#xml-namespaces">XML Namespaces</a><br />
C. <a href="#references">References</a><br />
D. <a href="#acknowledgments">Acknowledgements</a>
(Non-Normative)<br />
E. <a href="#change-description">Changes in this Version of the
Document</a> (Non-Normative)<br />
F. <a href="#change-log">Web Services Policy 1.5 - Primer Change
Log</a> (Non-Normative)<br /></p>
</div>
<hr />
<div class="body">
<div class="div1">
<h2><a name="introduction" id="introduction"></a>1.
Introduction</h2>
<p>This document, <em>Web Services Policy 1.5 - Primer</em>,
provides an introductory description of the Web Services Policy
language and should be read alongside the formal descriptions
contained in the WS-Policy and WS-PolicyAttachment
specifications.</p>
<p>This document is:</p>
<ul>
<li>
<p>for policy expression authors who need to understand the syntax
of the language and understand how to build consistent policy
expressions,</p>
</li>
<li>
<p>for policy implementers whose software modules read and write
policy expressions and</p>
</li>
<li>
<p>for policy assertion authors who need to know the features of
the language and understand the requirements for describing policy
assertions.</p>
</li>
</ul>
<p>This document assumes a basic understanding of XML 1.0,
Namespaces in XML, WSDL 1.1 and SOAP.</p>
<p>Each major section of this document introduces the features of
the policy language and describes those features in the context of
concrete examples.</p>
<p><a href="#basic-concepts-policy-expression"><b>2. Basic
Concepts: Policy Expression</b></a> covers the basic mechanisms of
Web Services Policy. It describes how to declare and combine
capabilities and requirements of a Web service as policy
expressions, attach policy expressions to WSDL constructs such as
endpoint and message, and re-use policy expressions.</p>
<p><a href="#advanced-concepts-policy-expression"><b>3. Advanced
Concepts: Policy Expression</b></a> this is the advanced section
that provides more in-depth materials for policy implementers and
assertion authors. It explains the basics of normalizing policy
expressions, merging policies, determining the compatibility
(intersection) of policies, the policy data model, the policy
expression and the extensibility points built into the Web Services
Policy language.</p>
<p><a href="#versioning-policy-language"><b>4. Versioning Policy
Language</b></a> provides examples and best practices on versioning
of the policy language itself, mostly intended for policy
implementers.</p>
<p>The Web Services Policy 1.5 - Guidelines for Policy Assertion
Authors specification provides guidelines for designing policy
assertions and enumerates the minimum requirements for describing
policy assertions in specifications.</p>
<p>This is a non-normative document and does not provide a
definitive specification of the Web Services Policy language.
<a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all
the namespaces that are used in this document. (XML elements
without a namespace prefix are from the Web Services Policy XML
Namespace.)</p>
</div>
<div class="div1">
<h2><a name="basic-concepts-policy-expression" id=
"basic-concepts-policy-expression"></a>2. Basic Concepts: Policy
Expression</h2>
<div class="div2">
<h3><a name="web-services-policy" id="web-services-policy"></a>2.1
Web Services Policy</h3>
<p>Web services are being successfully used for interoperable
solutions across various industries. One of the key reasons for
interest and investment in Web services is that they are
well-suited to enable service-oriented systems. XML-based
technologies such as SOAP, XML Schema and WSDL provide a
broadly-adopted foundation on which to build interoperable Web
services. The WS-Policy and WS-PolicyAttachment specifications
extend this foundation and offer mechanisms to represent the
capabilities and requirements of Web services as Policies.</p>
<p>Service metadata is an expression of the visible aspects of a
Web service, and consists of a mixture of machine- and
human-readable languages. Machine-readable languages enable
tooling. For example, tools that consume service metadata can
automatically generate client code to call the service. Service
metadata can describe different parts of a Web service and thus
enable different levels of tooling support.</p>
<p>First, service metadata can describe the format of the payloads
that a Web service sends and receives. Tools can use this metadata
to automatically generate and validate data sent to and from a Web
service. The XML Schema language is frequently used to describe the
message interchange format within the SOAP message construct, i.e.
to represent SOAP Body children and SOAP Header blocks.</p>
<p>Second, service metadata can describe the ‘how’ and ‘where’ a
Web service exchanges messages, i.e. how to represent the concrete
message format, what headers are used, the transmission protocol,
the message exchange pattern and the list of available endpoints.
The Web Services Description Language is currently the most common
language for describing the ‘how’ and ‘where’ a Web service
exchanges messages. WSDL has extensibility points that can be used
to expand on the metadata for a Web service.</p>
<p>Third, service metadata can describe the capabilities and
requirements of a Web service, i.e. representing whether and how a
message must be secured, whether and how a message must be
delivered reliably, whether a message must flow a transaction, etc.
Exposing this class of metadata about the capabilities and
requirements of a Web service enables tools to generate code
modules for engaging these behaviors. Tools can use this metadata
to check the compatibility of requesters and providers. Web
Services Policy can be used to represent the capabilities and
requirements of a Web service.</p>
<p>Web Services Policy is a machine-readable language for
representing the capabilities and requirements of a Web service.
These are called ‘policies’. Web Services Policy offers mechanisms
to represent consistent combinations of capabilities and
requirements, to determine the compatibility of policies, to name
and reference policies and to associate policies with Web service
metadata constructs such as service, endpoint and operation. Web
Services Policy is a simple language that has four elements -
<code>Policy, All</code>, <code>ExactlyOne</code> and
<code>PolicyReference</code> - and two attributes -
<code>wsp:Optional</code> and <code>wsp:Ignorable</code>.</p>
</div>
<div class="div2">
<h3><a name="simple-message" id="simple-message"></a>2.2 Simple
Message</h3>
<p>Let us start by considering a SOAP Message in the example
below.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-1.</span> SOAP Message</i></p>
<div class="exampleInner">
<pre>
&lt;soap:Envelope&gt;
  &lt;soap:Header&gt;
            &lt;wsa:To&gt;http://x.example.com/realquote&lt;/wsa:To&gt;
            &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
  &lt;/soap:Header&gt;
  &lt;soap:Body&gt;…&lt;/soap:Body&gt;
&lt;/soap:Envelope&gt;
</pre></div>
</div>
<p>This message uses message addressing headers. The
<code>wsa:To</code> and <code>wsa:Action</code> header blocks
identify the destination and the semantics implied by this message
respectively. (The prefix <code>wsa</code> is used here to denote
the Web Services Addressing XML Namespace. <a href=
"#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the
namespaces and prefixes that are used in this document.)</p>
<p>Let us look at a fictitious scenario used in this document to
illustrate the features of the policy language. A Web service
developer is building a client application that retrieves real time
stock quote information from Company-X, Ltd. Company-X supplies
real time data using Web services. The developer has Company-X’s
advertised WSDL description of these Web services. Company-X
requires the use of addressing headers for messaging. Just the WSDL
description is not sufficient for the developer to enable the
interaction between her client and these Web services. WSDL
constructs do not indicate requirements such as the use of
addressing.</p>
<p>(<em>The example companies, organizations, products, domain
names, e-mail addresses, logos, people, places, and events depicted
herein are fictitious. No association with any real company,
organization, product, domain name, email address, logo, person,
places, or events is intended or should be inferred.</em>)</p>
<p>Providers have the option to convey requirements, such as the
use of addressing, through word-of-mouth and documentation – as
they always have. To interact successfully with this service, the
developer may have to read any related documentation, call someone
at Company-X to understand the service metadata, or look at sample
SOAP messages and infer such requirements or behaviors.</p>
<p>Web Services Policy is a machine-readable language for
representing these Web service capabilities and requirements as
policies. Policy makes it possible for providers to represent such
capabilities and requirements in a machine-readable form. For
example, Company-X may augment the service WSDL description with a
policy that requires the use of addressing. The client application
developer can use a policy-aware client that understands this
policy and engages addressing automatically.</p>
<p>How does Company-X use policy to represent the use of
addressing? The example below illustrates a policy expression that
requires the use of addressing.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-2.</span> Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The policy expression in the above example consists of a Policy
main element and a child element wsam:Addressing. Child elements of
the Policy element that are not from the Policy namespace are
policy assertions. Company-X attaches the above policy expression
to a WSDL binding description.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-3.</span> Policy Expression Attached to Binding</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" &gt;
  &lt;Policy&gt;
    &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
  &lt;/Policy&gt;
  …
&lt;/wsdl:binding&gt;
            
</pre></div>
</div>
<p>Policies can also be attached to WSDL using references (See
<a href="#Referencing_Policy_Expressions"><b>2.10 Referencing
Policy Expressions</b></a>.)</p>
<p>The <code>wsam:Addressing</code> element is a policy assertion.
(The prefix <code>wsam</code> is used here to denote the Web
Services Addressing – Metadata XML Namespace.) This assertion
identifies the use of Web Services Addressing information headers.
A policy-aware client can recognize this policy assertion, engage
addressing automatically, and use headers such as
<code>wsa:To</code> and <code>wsa:Action</code> in SOAP
Envelopes.</p>
<p>It is important to understand the association between the SOAP
message and policy expression in the above example. As you can see
by careful examination of the message, there is no reference to any
policy expression. Just as WSDL does not require a message to
reference WSDL constructs (such as port, binding and portType), Web
Services Policy does not require a message to reference a policy
expression though the policy expression describes the message.</p>
</div>
<div class="div2">
<h3><a name="secure-message" id="secure-message"></a>2.3 Secure
Message</h3>
<p>In addition to requiring the use of addressing, Company-X
requires the use of transport-level security for protecting
messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-4.</span> Secure Message</i></p>
<div class="exampleInner">
<pre>
&lt;soap:Envelope&gt;
  &lt;soap:Header&gt;
    &lt;wss:Security soap:mustUnderstand="1" &gt;
      &lt;wsu:Timestamp wsu:Id="_0"&gt;
       &lt;wsu:Created&gt;2006-01-19T02:49:53.914Z&lt;/u:Created&gt;
       &lt;wsu:Expires&gt;2006-01-19T02:54:53.914Z&lt;/u:Expires&gt;
      &lt;/wsu:Timestamp&gt;
    &lt;/wss:Security&gt;
   &lt;wsa:To&gt;http://x.example.com/quote&lt;/wsa:To&gt;
   &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
  &lt;/soap:Header&gt;
  &lt;soap:Body&gt;…&lt;/soap:Body&gt;
&lt;/soap:Envelope&gt;
</pre></div>
</div>
<p>The SOAP message in the example above includes security
timestamps that express creation and expiration times of this
message. Company-X requires the use of security timestamps and
transport-level security - such as <code>HTTPS</code> – for
protecting messages. (The prefixes <code>wss</code> and
<code>wsu</code> are used here to denote the Web Services Security
and Utility namespaces.)</p>
<p>Similar to the use of addressing, Company-X indicates the use of
transport-level security using a policy expression. The example
below illustrates a policy expression that requires the use of
addressing and transport-level security for securing messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-5.</span> Addressing and Security Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
  &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The <code>sp:TransportBinding</code> element is a policy
assertion. (The prefix <code>sp</code> is used here to denote the
Web Services Security Policy XML Namespace.) This assertion
identifies the use of transport-level security – such as
<code>HTTPS</code> - for protecting messages. Policy-aware clients
can recognize this policy assertion, engage transport-level
security for protecting messages and include security timestamps in
SOAP Envelopes.</p>
<p>The client application developer can use a policy-aware client
that recognizes this policy expression and engages both addressing
and transport-level security automatically.</p>
<p>For the moment, let us set aside the contents of the
<code>sp:TransportBinding</code> policy assertion and consider its
details in a later section.</p>
</div>
<div class="div2">
<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other
Assertions</h3>
<p>Thus far, we explored how Company-X uses policy expressions and
assertions for representing behaviors that must be engaged for a
Web service interaction. What is a policy assertion? What role does
it play? In brief, a policy assertion is a piece of service
metadata, and it identifies a domain (such as messaging, security,
reliability and transaction) specific behavior that is a
requirement. Company-X uses a policy assertion to convey a
condition under which they offer a Web service. A policy-aware
client can recognize policy assertions and engage these behaviors
automatically.</p>
<p>Providers, like Company-X, have the option to combine behaviors
for an interaction from domains such as messaging, security,
reliability and transactions. Using policy assertions, providers
can represent these behaviors in a machine-readable form. Web
service developers can use policy-aware clients that recognize
these assertions and engage these behaviors automatically.</p>
<p>Who defines policy assertions? Where are they? Policy assertions
are defined by Web services developers, product designers, protocol
authors and users. Like XML Schema libraries, policy assertions are
a growing collection. Several WS-* protocol specifications and
applications define policy assertions:</p>
<ul>
<li>
<p>Web Services Security Policy [<cite><a href=
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</p>
</li>
<li>
<p>Web Services Reliable Messaging Policy [<cite><a href=
"#WS-RM-Policy">Web Services Reliable Messaging Policy
Assertion</a></cite>]</p>
</li>
<li>
<p>Web Services Atomic Transaction [<cite><a href="#WS-Atomic">Web
Services Atomic Transaction</a></cite>]</p>
</li>
<li>
<p>Web Services Business Activity Framework [<cite><a href=
"#WS-BA">Web Services Business Activity Framework</a></cite>]</p>
</li>
<li>
<p>Devices Profile for Web Services [<cite><a href=
"#WS-Device">Devices Profile for Web Services</a></cite>]</p>
</li>
<li>
<p>…</p>
</li>
</ul>
</div>
<div class="div2">
<h3><a name="combining-policy-assertions" id=
"combining-policy-assertions"></a>2.5 Combining Policy
Assertions</h3>
<p>Policy assertions can be combined in different ways to express
consistent combinations of behaviors (capabilities and
requirements). There are three policy operators for combining
policy assertions: <code>Policy</code>, <code>All</code> and
<code>ExactlyOne</code> (the <code>Policy</code> operator is a
synonym for <code>All).</code></p>
<p>Let us consider the <code>All</code> operator first. The policy
expression in the example below requires the use of addressing and
transport-level security. There are two policy assertions. These
assertions are combined using the <code>All</code> operator.
Combining policy assertions using the <code>Policy</code> or
<code>All</code> operator means that all the behaviors represented
by these assertions are required.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-6.</span> Addressing and Security Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;All&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
  &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
&lt;/All&gt;
</pre></div>
</div>
<p>In addition to requiring the use of addressing, Company-X allows
either the use of transport- or message-level security for
protecting messages. Web Services Policy language can indicate this
choice of behaviors in a machine-readable form. To indicate the use
of message-level security for protecting messages, Company-X uses
the <code>sp:AsymmetricBinding</code> policy assertion (see the
example below).</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-7.</span> Asymmetric Binding Security Policy Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
</pre></div>
</div>
<p>The <code>sp:AsymmetricBinding</code> element is a policy
assertion. (The prefix <code>sp</code> is used here to denote the
Web Services Security Policy namespace.) This assertion identifies
the use of message-level security – such as <em>WS-Security
1.0</em> - for protecting messages. Policy-aware clients can
recognize this policy assertion, engage message-level security for
protecting messages and use headers such as
<code>wss:Security</code> in SOAP Envelopes.</p>
<p>To allow the use of either transport- or message-level security,
Company-X uses the <code>ExactlyOne</code> policy operator. Policy
assertions combined using the <code>ExactlyOne</code> operator
requires exactly one of the behaviors represented by the
assertions. The policy expression in the example below requires the
use of either transport- or message-level security for protecting
messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-8.</span> Transport- or Message-Level Security Policy
Expression</i></p>
<div class="exampleInner">
<pre>
&lt;ExactlyOne&gt;
  &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
  &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
&lt;/ExactlyOne&gt;
</pre></div>
</div>
<p>Company-X requires the use of addressing and requires the use of
either transport- or message-level security for protecting
messages. They represent this combination using the
<code>All</code> and <code>ExactlyOne</code> operators. Policy
operators can be mixed to represent different combinations of
behaviors (capabilities and requirements). The policy expression in
the example below requires the use of addressing and one of
transport- or message-level security for protecting messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-9.</span> Addressing and Transport- OR Message-Level Security
Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;All&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
  &lt;ExactlyOne&gt;
    &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
  &lt;/ExactlyOne&gt;
&lt;/All&gt;
</pre></div>
</div>
<p>Using this policy expression, Company-X gives the choice of
mechanisms for protecting messages to clients (or requesters).</p>
</div>
<div class="div2">
<h3><a name="optional-policy-assertion" id=
"optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3>
<p>Through a customer survey program, Company-X learns that a
significant number of their customers prefer to use the Optimized
MIME Serialization (as defined in the MTOM specification) for
sending and receiving messages. Company-X adds optional support for
the Optimized MIME Serialization and expresses this optional
behavior in a machine-readable form.</p>
<p>To indicate the use of optimization using the Optimized MIME
Serialization, Company-X uses the
<code>mtom:OptimizedMimeSerialization</code> policy assertion (see
the example below).</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-10.</span> Optimized MIME Serialization Policy Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;mtom:OptimizedMimeSerialization /&gt;
</pre></div>
</div>
<p>The <code>mtom:OptimizedMimeSerialization</code> element is a
policy assertion. (The prefix <code>mtom</code> is used here to
denote the Optimized MIME Serialization Policy namespace.) This
assertion identifies the use of MIME Multipart/Related
serialization as required for request and response messages.
Policy-aware clients can recognize this policy assertion and engage
Optimized MIME Serialization for messages. The semantics of this
assertion are reflected in messages: they use an optimized wire
format (MIME Multipart/Related serialization).</p>
<p>Like Company-X’s optional support for Optimized MIME
Serialization, there are behaviors that may be engaged (in contrast
to must be engaged) for a Web service interaction. A service
provider will not fault if these behaviors are not engaged. Policy
assertions can be marked optional to represent behaviors that may
be engaged for an interaction. A policy assertion is marked as
optional using the <code>wsp:Optional</code> attribute. Optional
assertions represent the capabilities of the service provider as
opposed to the requirements of the service provider.</p>
<p>In the example below, the Optimized MIME Serialization policy
assertion is marked optional. This policy expression allows the use
of optimization and requires the use of addressing and one of
transport- or message-level security. If a client sends an
optimized (MTOM) message, this will be indicated by characteristics
associated by using such an optimized message, including a wire
format that is a Multipart/Related message and a content-type
header of "application/xop+xml" for the outer package. In this
case, the response message will also be optimized, also having a
Multipart/Related message and content-type header of
"application/xop+xml". Note that when optimized messages are used,
the Multipart/Related message can have a single part containing the
primary SOAP envelope.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-11.</span> Optional MIME Serialization, Addressing and Transport-
OR Message-Level Security Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;All&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
  &lt;ExactlyOne&gt;
    &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
  &lt;/ExactlyOne&gt;
&lt;/All&gt;
</pre></div>
</div>
<p>Company-X is able to meet their customer needs by adding
optional support for the Optimized MIME Serialization. Optional
support is outlined in section 3.4 Web Services Policy 1.5 -
Framework and detailed in section 4.5.2, Web Services Policy 1.5 -
Guidelines for Policy Assertion Authors, specifically for Optimized
MIME Serialization. An optional policy assertion represents a
behavior that may be engaged. When that policy assertion is absent
from a policy alternative (See section 3.2, Web Services Policy 1.5
- Framework), a policy-aware client should not conclude anything
(other than ‘no claims’) about the absence of that policy
assertion. See section <a href=
"#attaching-policy-expressions-to-wsdl"><b>2.11 Attaching Policy
Expressions to WSDL</b></a> on the absence of policy
expressions.</p>
</div>
<div class="div2">
<h3><a name="ignorable-policy-assertions" id=
"ignorable-policy-assertions"></a>2.7 Ignorable Policy
Expressions</h3>
<p>Suppose Company-X decides that it will log SOAP messages sent
and received in an exchange. This behavior has no direct impact on
the messages sent on the wire, and does not affect
interoperability. Some parties might have a concern about such
logging and might decide not to interact with Company-X knowing
that such logging is performed. To address this concern, Company-X
includes a Logging assertion in its policy to enable such parties
to be aware of logging. By marking the Logging assertion with the
<code>wsp:Ignorable</code> attribute with a value of "true"
Company-X indicates that a requester may choose to either ignore
such assertions or to consider them as part of policy intersection.
An assertion that may be ignored for policy intersection is called
an ignorable assertion.</p>
<p>The <code>wsp:Ignorable</code> attribute allows providers to
clearly indicate which policy assertions indicate behaviors that
don’t manifest on the wire and may not be of concern to a requester
when determining policy compatibility. Using the
<code>wsp:Optional</code> attribute would be incorrect in this
scenario, since it would indicate that the behavior would not occur
if the alternative without the assertion were selected.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-12.</span> Ignorable Logging Policy Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;log:Logging wsp:Ignorable="true" /&gt;
</pre></div>
</div>
<p>(The log: prefix is used here to denote a hypothetical example
namespace for this example logging policy assertion.)</p>
<p>The attribute <code>wsp:Ignorable</code> is of type
<em>xs:boolean</em>. Omitting this attribute is semantically
equivalent to including it with a value of "false".</p>
<p>The use of the <code>wsp:Ignorable</code> attribute has no
impact on normalization. Assertions marked with the
<code>wsp:Ignorable</code> attribute remain marked with the
<code>wsp:Ignorable</code> attribute after normalization. Please
note that the impact of the ignorable attribute is at the
discretion of policy consumers through selection of "lax" or
"strict" mode (See <a href=
"#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy
Intersection</b></a>). Therefore ignorable assertions may have an
effect on determining compatibility of provider and consumer
policies.</p>
</div>
<div class="div2">
<h3><a name="Both-Optional-Ignorable" id=
"Both-Optional-Ignorable"></a>2.8 Marking Assertions both Optional
and Ignorable</h3>
<p>As described in the sections above and in Section <a href=
"#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy
Intersection</b></a>, the WS-Policy 1.5 specification defines two
attributes that can be used to mark an assertion: wsp:Optional and
wsp:Ignorable.</p>
<p>The WS-Policy Framework allows a policy assertion to be marked
with both "Optional" and "Ignorable" attributes simultaneously. The
presence of "@wsp:optional=true" on an assertion is a syntactic
compact form for two alternatives in normal form, one with the
assertion and the other without the assertion. Hence syntactically
marking an assertion "A" with both the @wsp:Optional and
@wsp:Ignorable with the value of "true" for both, is equivalent to
two alternatives; one where the assertion A exists with
@wsp:Ignorable=true and the second where the assertion A does not
exist.</p>
</div>
<div class="div2">
<h3><a name="nested-policy-expressions" id=
"nested-policy-expressions"></a>2.9 Nested Policy Expressions</h3>
<p>In the previous sections, we considered two security policy
assertions. In this section, let us look at one of the security
policy assertions in a little more detail.</p>
<p>As you would expect, securing messages is a complex usage
scenario. Company-X uses the <code>sp:TransportBinding</code>
policy assertion to indicate the use of transport-level security
for protecting messages. Just indicating the use of transport-level
security for protecting messages is not sufficient. To successfully
interact with Company-X’s Web services, the developer must also
know what transport token to use, what particular secure transport
to use, what specific algorithm suite to use for performing
cryptographic operations, etc. The <code>sp:TransportBinding</code>
policy assertion can represent these dependent behaviors. In this
section, let us look at how to capture these dependent behaviors in
a machine-readable form.</p>
<p>A policy assertion – like the <code>sp:TransportBinding</code> -
identifies a visible domain specific behavior that is a
requirement. Given an assertion, there may be other dependent
behaviors that need to be enumerated for a Web Service interaction.
In the case of the <code>sp:TransportBinding</code> policy
assertion, Company-X needs to identify the use of a transport
token, a secure transport, an algorithm suite for performing
cryptographic operations, etc. A nested policy expression can be
used to enumerate such dependent behaviors.</p>
<p>What is a nested policy expression? A nested policy expression
is a policy expression that is a child element of a policy
assertion element. A nested policy expression further qualifies the
behavior of its parent policy assertion.</p>
<p>In the example below, the child <code>Policy</code> element is a
nested policy expression and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> is a nested policy assertion of the
<code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> assertion requires the use of a
specific transport token and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion (which already
requires the use of transport-level security for protecting
messages).</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-13.</span> Transport Security Policy Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;sp:TransportBinding&gt;
  &lt;Policy&gt;
    &lt;sp:TransportToken&gt;
      &lt;Policy&gt;
        &lt;sp:HttpsToken&gt;
          &lt;wsp:Policy/&gt;
        &lt;/sp:HttpsToken&gt;
      &lt;/Policy&gt;
    &lt;/sp:TransportToken&gt;
    &lt;sp:AlgorithmSuite&gt;
      &lt;Policy&gt;
        &lt;sp:Basic256Rsa15/&gt;
      &lt;/Policy&gt;
    &lt;/sp:AlgorithmSuite&gt;
    …
  &lt;/Policy&gt;
&lt;/sp:TransportBinding&gt;
</pre></div>
</div>
<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion
of the <code>sp:TransportBinding</code> policy assertion. The
<code>sp:AlgorithmSuite</code> assertion requires the use of the
algorithm suite identified by its nested policy assertion
(<code>sp:Basic256Rsa15</code> <em>in the example above</em>) and
further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion.</p>
<p>Setting aside the details of using transport-level security, Web
service developers can use a policy-aware client that recognizes
this policy assertion and engages transport-level security and its
dependent behaviors automatically. That is, the complexity of
security usage is absorbed by a policy-aware client and hidden from
these Web service developers.</p>
<p>In another example, WS-Security Policy defines a sp:HttpToken
assertion to contain three possible nested elements,
sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and
sp:RequireClientCertificate. When the HttpToken is used with an
empty nested policy in a policy expression by a provider, it will
indicate that none of the dependent behaviors namely authentication
or client certificate is required. A non-anonymous client who
requires authentication or client certificate will not be able to
use this provider solely on the basis of policy intersection
algorithm alone.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-14.</span> Empty Nested Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;sp:TransportToken&gt;
    &lt;wsp:Policy&gt;
      &lt;sp:HttpsToken&gt; 
       &lt;wsp:Policy/&gt; 
      &lt;/sp:HttpsToken&gt; 
    &lt;/wsp:Policy&gt;
&lt;/sp:TransportToken&gt;
</pre></div>
</div>
</div>
<div class="div2">
<h3><a name="Referencing_Policy_Expressions" id=
"Referencing_Policy_Expressions"></a>2.10 Referencing Policy
Expressions</h3>
<p>Company-X has numerous Web service offerings that provide
different kinds of real-time quotes and book information on
securities such as <code>GetRealQuote</code>,
<code>GetRealQuotes</code> and <code>GetExtendedRealQuote</code>.
To accommodate the diversity of Company-X’s customers, Company-X
supports multiple WSDL bindings for these Web services. Company-X
provides consistent ways to interact with their services and wants
to represent these capabilities and requirements consistently
across all of their offerings without duplicating policy
expressions multiple times. How? It is simple - a policy expression
can be named and referenced for re-use.</p>
<p>Section <a href="#simple-message"><b>2.2 Simple Message</b></a>,
showed how a policy expression can be attached directly to a
binding inline. A single policy expression may be used in several
parts of a WSDL document. In this case it is desirable to use
references to the policy expression rather than to directly inline
the policy expression.</p>
<p>A policy expression may be identified by an IRI and referenced
for re-use as a standalone policy or within another policy
expression. There are three mechanisms to identify a policy
expression: the <code>wsu:Id</code>, <code>xml:id</code> and
<code>Name</code> attributes. A <code>PolicyReference</code>
element can be used to reference a policy expression identified
using either of these mechanisms.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-15.</span> Common Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy wsu:Id=”common”&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>In the example above, the <code>wsu:Id</code> attribute is used
to identify a policy expression. The value of the
<code>wsu:Id</code> attribute is an XML ID. The relative IRI for
referencing this policy expression (within the same document) is
<code>#common</code>. If the policy document IRI is
<code>http://x.example.com/policy.xml</code> then the absolute IRI
for referencing this policy expression is
<code>http://x.example.com/policy.xml#common. (</code>The absolute
IRI is formed by combining the document IRI, <code>#</code> and the
value of the <code>wsu:Id</code> attribute.)</p>
<p>In addition to the Example 2-12, Company-X could have used
either the xml:id or wsu:Id. An example of the use of xml:id
similar to that of wsu:Id is shown in Example 2-13.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-16.</span> Common Policy Expression [xml:id]</i></p>
<div class="exampleInner">
<pre>
&lt;Policy xml:id=”common”&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>Conditions and constraints on the use of the |xml:id| attribute
in conjunction with Canonical XML 1.0 are specified in Appendix C
of <cite><a href="#XMLID">XML ID</a></cite> and are further
detailed in <cite><a href="#C14NNOTE">C14N 1.0 Note</a></cite>.
Significant care is suggested in the use of xml:id.</p>
<div class="note">
<p class="prefix"><b>Note:</b></p>
<p>Note: Canonical XML 1.1 [<cite><a href=
"#C14N11">C14N11</a></cite>] is intended to address the issues that
occur with Canonical XML 1.0 with regards to <code>xml:id</code>.
The W3C XML Security Specifications Maintenance WG has been
chartered to address how to integrate Canonical XML 1.1 with XML
Security, including XML Signature [<cite><a href=
"#SecSpecMaintWG">SecSpecMaintWG</a></cite>] (See
http://www.w3.org/2007/xmlsec/.)</p>
</div>
<p>For re-use, a <code>PolicyReference</code> element can be used
to reference a policy expression as a standalone policy or within
another policy expression. The example below is a policy expression
that re-uses the common policy expression above.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-17.</span> PolicyReference to Common Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;PolicyReference URI="#common"/&gt;
</pre></div>
</div>
<p>For referencing a policy expression within the same XML
document, Company-X uses the <code>wsu:Id</code> attribute for
identifying a policy expression and an IRI to this ID value for
referencing this policy expression using a
<code>PolicyReference</code> element.</p>
<p>The example below is a policy expression that re-uses the common
policy expression within another policy expression. This policy
expression requires the use of addressing, one of transport- or
message-level security for protecting messages and allows the use
of optimization.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-18.</span> Secure Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy wsu:Id=”secure”&gt;
  &lt;All&gt;
    &lt;PolicyReference URI="#common"/&gt;
    &lt;ExactlyOne&gt;     
      &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
      &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
    &lt;/ExactlyOne&gt;
  &lt;/All&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The <code>Name</code> attribute is an alternate mechanism to
identify a policy expression. The value of the <code>Name</code>
attribute is an absolute IRI and is independent of the location of
the XML document where the identified policy expression resides in.
As such, referencing a policy expression using the Name attribute
relies on additional out of band information and is outside the
scope of the Web Services Policy Framework and Attachment (See
<a href="#policy-retrieval"><b>3.6 Policy Retrieval</b></a>). In
the example below, the <code>Name</code> attribute identifies the
policy expression. The IRI of this policy expression is
<code>http://x.example.com/policy/common</code>.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-19.</span> Common Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy Name=”http://x.example.com/policy/common”&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The example below is a policy expression that re-uses the common
policy expression above.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-20.</span> PolicyReference to Common Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;PolicyReference URI="http://x.example.com/policy/common"/&gt;
</pre></div>
</div>
<p>The following example shows a policy expression identified using
a UDDI key, which may refer to a tModel that references the
reusable policy expression as described in section 6.3 of
<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-21.</span> PolicyReference to Reusable Policy Expression in
UDDI</i></p>
<div class="exampleInner">
<pre>
&lt;PolicyReference URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"/&gt;
</pre></div>
</div>
<p>The reusable policy expression could be registered in UDDI using
a tModel as shown below</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-22.</span> UDDI tModel for a Reusable Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;tModel tModelKey="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"&gt;
  &lt;name&gt;…&lt;/name&gt;
  &lt;description xml:lang="EN"&gt;
Policy Expression for example's Web services
  &lt;/description&gt;
  &lt;overviewDoc&gt;
    &lt;description xml:lang="EN"&gt;Web Services Policy Expression&lt;/description&gt;
    &lt;overviewURL&gt;http://repository.example.com/policy/common&lt;/overviewURL&gt;
  &lt;/overviewDoc&gt;
  &lt;categoryBag&gt;
    &lt;keyedReference
      keyName="Reusable policy Expression"
      keyValue="policy"
      tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:policytypes" /&gt;
    &lt;keyedReference
      keyName="Policy Expression for example's Web services"
      keyValue="http://x.example.com/policy/common"
      tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference" /&gt;
  &lt;/categoryBag&gt;
&lt;/tModel&gt;
</pre></div>
</div>
<p>As policy expressions are composed from other policy expressions
and assertions from different domains are used in a policy
expression, complex expressions will emerge. Naming parts of
complex expressions for reuse and building more complex policies
through referencing enables building more complicated policy
scenarios easily. This approach enables the association of
additional policy subjects to identified policy expressions. It
also promotes manageability of the expressions as they are uniquely
identified and allows profiles for common scenarios to be
developed. Note that when a named expression has assertions that
contains parameterized expressions, care must be given to ensure
that the parameterized content is statically available to enable
reuse.</p>
</div>
<div class="div2">
<h3><a name="attaching-policy-expressions-to-wsdl" id=
"attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy
Expressions to WSDL</h3>
<p>A majority of Company-X’s customers use WSDL for building their
client applications. Company-X leverages this usage by attaching
policy expressions to the WSDL binding descriptions.</p>
<p>In the example below, the <code>SecureBinding</code> WSDL
binding description defines a binding for an interface that
provides real-time quotes and book information on securities. (The
prefixes <code>wsdl</code> and <code>tns</code> are used here to
denote the Web Services Description language XML namespace and
target namespace of this WSDL document.) To require the use of
security for these offerings, Company-X attaches the secure policy
expression in the previous section to this binding description. The
WSDL <code>binding</code> element is a common policy attachment
point. The secure policy expression attached to the
<code>SecureBinding</code> WSDL binding description applies to any
message exchange associated with any <code>port</code> that
supports this binding description. This includes all the message
exchanges described by operations in the
<code>RealTimeDataInterface</code>.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-23.</span> Secure Policy Expression Attached to WSDL
Binding</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
  &lt;PolicyReference URI="#secure" /&gt;
  &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
  …
&lt;/wsdl:binding&gt;
</pre></div>
</div>
<p>In addition to providing real-time quotes and book information
on securities, Company-X provides other kinds of data through Web
services such as quotes delayed by 20 minutes and security symbols
through Web services (for example <code>GetDelayedQuote</code>,
<code>GetDelayedQuotes,</code> <code>GetSymbol</code> and
<code>GetSymbols</code>). Company-X does not require the use of
security for these services, but requires the use of addressing and
allows the use of optimization.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-24.</span> Open Policy Expression Attached to WSDL
Binding</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" &gt;
  &lt;PolicyReference URI="#common" /&gt;
  &lt;wsdl:operation name="GetDelayedQuote"&gt;…&lt;/wsdl:operation&gt;
  …
&lt;/wsdl:binding&gt;
</pre></div>
</div>
<p>In the example above, the <code>OpenBinding</code> WSDL binding
description defines a binding for an interface that provides other
kinds of data such as quotes delayed by 20 minutes and security
symbols. To require the use of addressing and allow the use of
optimization, Company-X attaches the common policy expression in
the previous section to this binding description. As we have seen
in the <code>SecureBinding</code> case, the common policy
expression attached to the <code>OpenBinding</code> WSDL binding
description applies to any message exchange associated with any
<code>port</code> that supports this binding description. This
includes all the message exchanges described by operations in the
<code>DelayedDataInterface</code>.</p>
<p>As mentioned earlier, providers have the option to convey
requirements, such as the use of addressing or security, through
word-of-mouth and documentation – as they always have. The absence
of policy expressions, for example, in a WSDL document does not
indicate anything about the capabilities and requirements of a
service. The service may have capabilities and requirements that
can be expressed as policy expressions, such as the use of
addressing, security and optimization. Or, the service may not have
such capabilities and requirements. A policy aware client should
not conclude anything about the absence of policy expressions.</p>
<p>Service providers, like Company-X, can preserve and leverage
their investments in WSDL and represent the capabilities and
requirements of a Web service as policies. A WSDL document may
specify varying behaviors across Web service endpoints. Web service
developers can use a policy-aware client that recognizes these
policy expressions in WSDL documents and engages behaviors
automatically for each of these endpoints. Any complexity of
varying behaviors across Web service endpoints is absorbed by a
policy-aware client or tool and hidden from these Web service
developers.</p>
</div>
<div class="div2">
<h3><a name="policy-automates-web-services-interaction" id=
"policy-automates-web-services-interaction"></a>2.12 Policy
Automates Web Services Interaction</h3>
<p>As you have seen, Web Services Policy is a simple language that
has four elements - <code>Policy, All</code>,
<code>ExactlyOne</code> and <code>PolicyReference</code> - and two
attributes - <code>wsp:Optional</code> and
<code>wsp:Ignorable</code>. In practice, service providers, like
Company-X, use policy expressions to represent combinations of
capabilities and requirements. Web service developers use
policy-aware clients that understand policy expressions and engage
the behaviors represented by providers automatically. A sizable
amount of complexity is absorbed by policy-aware clients (or tools)
and is invisible to these Web service developers.</p>
<p>Web Services Policy extends the foundation on which to build
interoperable Web services, hides complexity from developers and
automates Web service interactions.</p>
</div>
</div>
<div class="div1">
<h2><a name="advanced-concepts-policy-expression" id=
"advanced-concepts-policy-expression"></a>3. Advanced Concepts:
Policy Expression</h2>
<p>In <a href="#basic-concepts-policy-expression"><b>2. Basic
Concepts: Policy Expression</b></a>, we covered the basics of Web
Services Policy language. This is the advanced section that
provides more in-depth materials for Web Services Policy
implementers and assertion authors. This section covers the
following topics:</p>
<ul>
<li>
<p>What is a policy expression?</p>
</li>
<li>
<p>What is the normal form of a policy expression and how to
normalize policy expressions?</p>
</li>
<li>
<p>What is the policy data model?</p>
</li>
<li>
<p>How to select a compatible policy alternative?</p>
</li>
<li>
<p>How to attach policy expressions to WSDL constructs?</p>
</li>
<li>
<p>How to combine policies?</p>
</li>
<li>
<p>What are the extensibility points?</p>
</li>
<li>
<p>What are the parts of a policy assertion?</p>
</li>
</ul>
<div class="div2">
<h3><a name="policy-expression" id="policy-expression"></a>3.1
Policy Expression</h3>
<p>A policy expression is the XML representation and interoperable
form of a Web Services Policy. A policy expression consists of a
<code>Policy</code> wrapper element and a variety of child and
descendant elements. Child and descendent elements from the policy
language are <code>Policy, All</code>, <code>ExactlyOne</code> and
<code>PolicyReference</code>. Other child elements of
<code>Policy</code>, <code>All</code> and <code>ExactlyOne</code>
are policy assertions. (The <code>Policy</code> element plays two
roles: wrapper element and operator.) Policy assertions can contain
a nested policy expression. Policy assertions can also be marked
optional to represent behaviors that may be engaged (capabilities)
for an interaction. The optional marker is the
<code>wsp:Optional</code> attribute which is placed on a policy
assertion element.</p>
<p>Let us take a closer look at Company-X’s policy expression (see
below) from the previous section.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-1.</span> Company-X’s Secure Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;All&gt;
    &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
    &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
    &lt;ExactlyOne&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
     &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
    &lt;/ExactlyOne&gt;
  &lt;/All&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The <code>Policy</code> element is the wrapper element. The
<code>All</code> and <code>ExactlyOne</code> elements are the
policy operators. All other child elements of the <code>All</code>
and <code>ExactlyOne</code> elements are policy assertions from
domains such as messaging, addressing, security, reliability and
transactions.</p>
</div>
<div class="div2">
<h3><a name="normal-form-for-policy-expressions" id=
"normal-form-for-policy-expressions"></a>3.2 Normal Form for Policy
Expressions</h3>
<p>Web Services Policy language defines two forms of policy
expressions: compact and normal form. Up to this point, we have
used the compact form. The compact form is less verbose than the
normal form. The compact form is useful for authoring policy
expressions. The normal form is an intuitive representation of the
policy data model. We will look into the policy data model in the
next section.</p>
<p>The normal form uses a subset of constructs used in the compact
form and follows a simple outline for its XML representation:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-2.</span> Normal Form for Policy Expressions</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt;
     &lt;x:AssertionA&gt;…&lt;/x:AssertionA&gt;
     &lt;y:AssertionB&gt;…&lt;/y:AssertionB&gt;
      …
    &lt;/All&gt;
    &lt;All&gt;
     &lt;x:AssertionA&gt;…&lt;/x:AssertionA&gt;
     &lt;z:AssertionC&gt;…&lt;/z:AssertionC&gt;
      …
    &lt;/All&gt;
   … 
  &lt;/ExactlyOne&gt;
&lt;Policy/&gt;
</pre></div>
</div>
<p>The normal form consists of a <code>Policy</code> wrapper
element and has one child <code>ExactlyOne</code> element. This
<code>ExactlyOne</code> element has zero or more <code>All</code>
child elements. Each of these <code>All</code> elements has zero or
more policy assertions. The <code>PolicyReference</code> element
and <code>wsp:Optional</code> attribute are not used in the normal
form. And, a nested policy expression in the normal form has at
most one policy alternative.</p>
<p>The normal form represents a policy as a collection of policy
alternatives and a policy alternative as a collection of policy
assertions in a straight-forward manner.</p>
<p>The example below is a policy expression in the normal form.
This expression contains two policy alternatives: one that requires
the use of transport-level security and the other that requires the
use of message-level security for protecting messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-3.</span> Transport- or Message-Level Security Policy Expression
in Normal Form</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
    &lt;All&gt;
     &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
    &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>A policy expression in the compact form can be converted to the
normal form. Web Services Policy language describes the algorithm
for this conversion.</p>
<p>Let us re-consider Company-X’s policy expression (see the
example below). Company-X requires the use of addressing and either
transport- or message-level security and allows the use of
optimization. This policy expression is in the compact form and has
four policy alternatives for requesters:</p>
<ol class="enumar">
<li>
<p>Requires the use of addressing and transport-level security</p>
</li>
<li>
<p>Requires the use of addressing and message-level security</p>
</li>
<li>
<p>Requires the use of optimization, addressing and transport-level
security and</p>
</li>
<li>
<p>Requires the use of optimization, addressing and message-level
security.</p>
</li>
</ol>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-4.</span> Company-X’s Secure Policy Expression in Compact
Form</i></p>
<div class="exampleInner">
<pre>
&lt;Policy wsu:Id=”secure”&gt;
  &lt;All&gt;
    &lt;PolicyReference URI=”#common”/&gt;
    &lt;ExactlyOne&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
     &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
    &lt;/ExactlyOne&gt;
  &lt;/All&gt;
&lt;/Policy&gt;

&lt;Policy wsu:Id=”common”&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>Let us look at the normal form for this policy expression. The
example below is Company-X’s policy expression in the normal form.
As you can see, the compact form is less verbose than the normal
form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy
alternative. There are four policy alternatives in the normal form.
These alternatives map to list items (1) through (4) above.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-5.</span> Company-X’s Policy Expression in Normal Form</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (a) --&gt;
       &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
       &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (b) --&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
      &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
    &lt;/All&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (c) --&gt;
      &lt;mtom:OptimizedMimeSerialization /&gt;
       &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
       &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (d) --&gt;
      &lt;mtom:OptimizedMimeSerialization /&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
      &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
    &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The <code>wsp:Optional</code> attribute, nested policy
expression and <code>Policy</code><code>Reference</code> element
are converted to their corresponding normal form. The
<code>wsp:Optional</code> attribute converts to two alternatives,
one with and the other without the assertion. A policy alternative
containing an assertion with a nested policy expression that has
multiple policy alternatives converts to multiple policy
alternatives where the assertion contains a nested policy
expression that has at most one policy alternative.</p>
<p>The <code>PolicyReference</code> element is replaced with its
referenced policy expression. See section <a href=
"#policy-retrieval"><b>3.6 Policy Retrieval</b></a> for more
details on how to retrieve referenced policy expressions.</p>
</div>
<div class="div2">
<h3><a name="policy-data-model" id="policy-data-model"></a>3.3
Policy Data Model</h3>
<p>In the previous section, we considered the normal form for
policy expressions. As we discussed, the normal form represents a
policy as a collection of policy alternatives. In this section, let
us look at the policy data model.</p>
<p>Company-X uses a policy to convey the conditions for an
interaction. Policy-aware clients, like the one used by the
developer in our example (as explained earlier in <a href=
"#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy
Expression</b></a>), view a policy as an unordered collection of
zero or more policy alternatives. A policy alternative is an
unordered collection of zero or more policy assertions. A policy
alternative represents a collection of behaviors or requirements or
conditions for an interaction. In simple words, each policy
alternative represents a set of conditions for an interaction. The
diagram below describes the policy data model.</p>
<div class="figure" style="text-align: center"><br />
<img src="ws-policy-data-model.jpg" alt="WS-Policy Data Model" />
<p style="text-align:left"><i><span>Figure 3-1.</span> WS-Policy
Data Model</i></p>
<br /></div>
<p>A policy-aware client uses a policy to determine whether one of
these policy alternatives (i.e. the conditions for an interaction)
can be met in order to interact with the associated Web Service.
Such clients may choose any of these policy alternatives and must
choose exactly one of them for a successful Web service
interaction. Clients may choose a different policy alternative for
a subsequent interaction. It is important to understand that a
policy is a useful piece of metadata in machine-readable form that
enables tooling, yet is not required for a successful Web service
interaction. Why? Web service developers could use the
documentation, talk to the service providers, or look at message
traces to infer these conditions for an interaction. Developers
continue to have these options, as they always had.</p>
<p>As we discussed, a policy assertion identifies a domain specific
behavior or requirement or condition. A policy assertion has a
QName that identifies its behavior or requirement or condition. In
the XML representation, the QName of the assertion element is the
QName of the policy assertion. A policy assertion may contain
assertion parameters and a nested policy.</p>
<p>The assertion parameters are the opaque payload of an assertion.
Parameters carry additional useful pieces of information necessary
for engaging the behavior described by an assertion. In the XML
representation, the child elements and attributes of an assertion
excluding the child elements and attributes from the WS-Policy
language XML namespace name, are the assertion parameters. For
example @wsp:Optional and @wsp:Ignorable are not assertion
parameters.</p>
<p>We considered nested policy expressions in the context of a
security usage scenario. Let us look at its shape in the policy
data model. A nested policy expression is a policy expression that
is a child element of an assertion. In the normal form, a nested
policy expression has at most one policy alternative. The policy
alternative in a nested policy expression represents a collection
of associated or dependent behaviors, requirements or conditions
that qualify its parent policy assertion.</p>
<p>A policy-aware client supports a policy assertion if the client
engages the behavior or requirement or condition indicated by the
assertion. A policy-aware client supports a policy alternative if
the client engages the behaviors represented by all the assertions
in the alternative. A policy-aware client supports a policy if the
client engages the behaviors represented by at least one of the
policy alternatives.</p>
<p>In the previous section, we saw how the normal form of a policy
expression represents a policy as a collection of policy
alternatives. By policy language design, the normal form of a
policy expression directly maps to the policy data model:</p>
<ul>
<li>
<p>Each child element of <code>Policy/ExactlyOne/All</code> maps to
a policy assertion.</p>
</li>
<li>
<p>Each <code>Policy/ExactlyOne/All</code> element and policy
assertions which correspond to its children map to a policy
alternative.</p>
</li>
<li>
<p>The <code>Policy/ExactlyOne</code> element maps to a collection
of policy alternatives.</p>
</li>
<li>
<p>The <code>Policy</code> wrapper element and policy alternatives
which correspond to the <code>Policy/ExactlyOne</code> element map
to a policy.</p>
</li>
</ul>
<p>The diagram below describes this mapping from the normal form of
a policy expression to the policy data model.</p>
<div class="figure" style="text-align: center"><br />
<img src="normal-form-2-data-model.jpg" alt=
"Mapping from Normal Form to Policy Data Model" />
<p style="text-align:left"><i><span>Figure 3-2.</span> Mapping from
Normal Form to Policy Data Model</i></p>
<br /></div>
</div>
<div class="div2">
<h3><a name="compatible-policies" id="compatible-policies"></a>3.4
Compatible Policies</h3>
<p>A provider, like Company-X, and a requester, like the
policy-aware client used in our example, may represent their
capabilities and requirements for an interaction as policies and
want to limit their message exchanges to mutually compatible
policies. Web Services Policy defines an intersection mechanism for
selecting compatible policy alternatives when there are two or more
policies.</p>
<p>The example below is a copy of Company-X’s policy expression
(from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal
Form for Policy Expressions</b></a>). As we saw before, Company-X
offers four policy alternatives. Of them, one of the policy
alternatives requires the use of addressing and transport-level
security.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-6.</span> Company-X’s Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - -  Company-X’s Policy Alternative (a) --&gt;
       &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) --&gt;
       &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
       &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) --&gt;
      &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
    …
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The client application developer's organization requires the use
of addressing and transport-level security for any interaction with
Company-X’s Web services. The developer represents these behaviors
using a policy expression illustrated in the example below in
normal form. This policy expression contains one policy alternative
that requires the use of addressing and transport-level
security.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-7.</span> The Client Application's Policy Expression in Normal
Form</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - -  Client’s Policy Alternative --&gt;
       &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) --&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
       &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) --&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
    &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The developer lets her policy-aware client select a compatible
policy alternative in Company-X’s policy. How does this client
select a compatible policy alternative? It is simple – it uses the
policy intersection. That is, the policy-aware client uses these
two policy expressions (the client’s and Company-X’s) and the
policy intersection to select a compatible policy alternative for
this interaction. Let us look at the details of policy
intersection.</p>
<p>For two policy assertions to be compatible they must have the
same QName. And, if either assertion has a nested policy, both
assertions must have a nested policy and the nested policies must
be compatible. For example, policy assertions (c2) and (t1) have
the same QName, <code>sp:TransportBinding</code>. For this
discussion, let us assume that these two assertions have compatible
nested policies. These two assertions are compatible because they
have the same QName and their nested policies are compatible.</p>
<p>Two policy alternatives are compatible if each policy assertion
in one alternative is compatible with a policy assertion in the
other and vice-versa. For instance in Examples 3.6 and 3.7, policy
assertions (c1) and (c2) in Company-X’s policy alternative are
compatible with policy assertions (t2) and (t1) in the client’s
policy alternative. Company-X’s policy alternative (a) and the
client’s policy alternative are compatible because assertions in
these two alternatives are compatible.</p>
<p>Two policies are compatible if a policy alternative in one is
compatible with a policy alternative in the other. For example,
Company-X’s policy alternative (a) is compatible with the client’s
policy alternative. Company-X’s policy and the client’s policy are
compatible because one of Company-X’s policy alternative is
compatible with the client’s policy alternative.</p>
<p>For this interaction, the developer’s policy-aware client can
use policy alternative (a) to satisfy Company-X’s conditions or
requirements.</p>
<p>Similarly, policy intersection can be used to check if providers
expose endpoints that conform to a standard policy. For example, a
major retailer might require all their supplier endpoints to be
compatible with an agreed upon policy.</p>
<p>Consider a similar scenario between Company X and the client
where nested policy expressions exist in the policy alternatives.
The nested policy expressions are compared for compatibility in the
context of their parent policy assertions during policy
intersection. For example, take these two incompatible policies in
Examples 3.8 and 3.9:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-8.</span> Company X Nested incompatible policy example</i></p>
<div class="exampleInner">
<pre>
Company X    
(P001)&lt;wsp:Policy wsu:Id="..." &gt;
(P002)  &lt;wsp:ExactlyOne&gt;
(P003)    &lt;wsp:All&gt;
(P004)      &lt;sp:EndorsingSupportingTokens 
(P005)        xmlns:sp="..."&gt; &lt;!-- parent policy assertion a --&gt;      
(P006)        &lt;wsp:Policy&gt; &lt;!-- nested policy a1  --&gt;
(P007)          &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
(P008)            &lt;wsp:Policy&gt;       
(P009)              &lt;sp:RequireThumbprintReference /&gt;
(P010)              &lt;sp:WssX509V3Token10 /&gt;
(P011)            &lt;/wsp:Policy&gt;
(P012)          &lt;/sp:X509Token&gt;
(P013)        &lt;/wsp:Policy&gt;
(P014)      &lt;/sp:EndorsingSupportingTokens&gt;... 
(P015)    &lt;/wsp:All&gt;
(P016)  &lt;/wsp:ExactlyOne&gt;
(P017)&lt;/wsp:Policy&gt;
</pre></div>
</div>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-9.</span> Client Nested incompatible policy example</i></p>
<div class="exampleInner">
<pre>
Client
(P001)&lt;wsp:Policy wsu:Id="..." &gt;
(P002)   &lt;wsp:ExactlyOne&gt;
(P003)     &lt;wsp:All&gt;
(P004)       &lt;sp:SignedSupportingTokens 
(P005)         xmlns:sp="..."&gt; &lt;!-- parent policy assertion b --&gt;      
(P006)         &lt;wsp:Policy&gt; &lt;!-- nested policy b1 --&gt;
(P007)           &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
(P008)             &lt;wsp:Policy&gt;       
(P009)               &lt;sp:RequireThumbprintReference /&gt;
(P010)               &lt;sp:WssX509V3Token10 /&gt;
(P011)             &lt;/wsp:Policy&gt;
(P012)          &lt;/sp:X509Token&gt;
(P013)        &lt;/wsp:Policy&gt;
(P014)      &lt;/sp:SignedSupportingTokens&gt;... 
(P015)    &lt;/wsp:All&gt;
(P016)  &lt;/wsp:ExactlyOne&gt;
(P017)&lt;/wsp:Policy&gt;
          
</pre></div>
</div>
<p>In this scenario as illustrated in Examples 3.8 and 3.9, the
EndorsingSupportingTokens and SignedSupportingTokens assertions are
incompatible even though their nested policy expressions are
compatible. This is because the parent policy assertions
EndorsingSupportingTokens and SignedSupportingTokens have different
QNames.</p>
<div class="div3">
<h4><a name="strict-lax-policy-intersection" id=
"strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy
Intersection</h4>
<p>The previous sections outlined how the normal-form of a policy
expression relates to the policy data model and how the
compatibility of requester and provider policies may be determined.
This section outlines how ignorable assertions may impact the
process of determining compatibility.</p>
<p>In order to determine compatibility of its policy expression
with a provider policy expression, a requester may use either a
"lax" or "strict" mode of the intersection algorithm.</p>
<p>In the strict intersection mode two policy alternatives are
compatible when each assertion in one is compatible with an
assertion in the other, and vice versa (See section 4.5, Web
Services Policy 1.5 - Framework). For this to be possible they must
contain the same policy assertion types. The strict intersection
mode is the mode of intersection discussed in the previous sections
of this document.</p>
<p>When using the strict intersection mode compatibility is
computed for all assertions that are part of the policy
alternative, including those marked with
<code>wsp:Ignorable</code>. Thus the <code>wsp:Ignorable</code>
attribute does not impact the intersection result even when its
attribute value is “true”.</p>
<p>If a requester wishes to ignore ignorable assertions in a
provider's policy, then the requester should use the lax
intersection mode. In the lax intersection mode all ignorable
assertions (i.e. with the value "true" for the
<code>wsp:Ignorable</code> attribute) are to be ignored by the
intersection algorithm. Thus in the lax intersection mode two
policy alternatives are compatible when each non-ignorable
assertion in one is compatible with an assertion in the other, and
vice versa. For this to be possible the two policy alternatives
must contain the same policy assertion types for all
“non-ignorable” assertions.</p>
<p>Regardless of the chosen intersection mode, ignorable assertions
do not express any wire-level requirements on the behavior of
consumers - in other words, a consumer could choose to ignore any
such assertions that end up in the resulting policy after
intersection, with no adverse effects on runtime interactions.</p>
<p>Domain-specific processing could take advantage of any
information from the policy data model, such as the ignorable
property of a policy assertion.</p>
<p>A requester can decide how to process a provider's policy to
determine if and how the requester will interact with the provider.
The requester can have its own policy that expresses its own
capabilities and requirements, and can make one or more attempts at
policy intersection in order to determine a compatible alternative
and/or isolate the cause of an empty intersection result. The
requester can use and analyze the result(s) of policy intersection
to select a compatible alternative or trigger other domain-specific
processing options. For example, a requester can at first attempt
strict mode intersection, and then lax mode as another choice, if
the previous attempt returns an empty intersection result.</p>
</div>
</div>
<div class="div2">
<h3><a name="attaching-policy-expressions-to-wsdl2" id=
"attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy
Expressions to WSDL</h3>
<p>In <a href="#basic-concepts-policy-expression"><b>2. Basic
Concepts: Policy Expression</b></a>, we looked into how Company-X
attached their policy expressions to the WSDL <code>binding</code>
element. In addition to the WSDL <code>binding</code> element, a
policy expression can be attached to other WSDL elements such as
<code>service</code>, <code>port</code>, <code>operation</code> and
<code>message</code>. These elements are the WSDL policy attachment
points in a WSDL document.</p>
<p>The WSDL attachment points are partitioned (as illustrated
below) into four policy subjects: message, operation, endpoint and
service. When attached, capabilities and requirements represented
by a policy expression apply to a message exchange or message
associated with (or described by) a policy subject.</p>
<div class="figure" style="text-align: center"><br />
<img src="policy-subjects-in-wsdl.jpg" alt=
"Policy Subjects and Effective Policy in WSDL" />
<p style="text-align:left"><i><span>Figure 3-3.</span> Policy
Subjects and Effective Policy in WSDL</i></p>
<br /></div>
<p>The WSDL <code>service</code> element represents the service
policy subject. Policy expressions associated with a service policy
subject apply to any message exchange using any of the endpoints
offered by that service.</p>
<p>The WSDL <code>port</code>, <code>binding</code> and
<code>portType</code> elements collectively represent the endpoint
policy subject. Policy expressions associated with an endpoint
policy subject apply to any message exchange made using that
endpoint.</p>
<p>The WSDL <code>binding/operation</code> and
<code>portType/operation</code> elements collectively represent the
operation policy subject. Policy expressions associated with an
operation policy subject apply to the message exchange defined by
that operation.</p>
<p>The WSDL <code>binding/operation/input</code>,
<code>portType/operation/input</code>, and <code>message</code>
element collectively represent the message policy subject for the
input message. The WSDL <code>binding/operation/output</code>,
<code>portType/operation/output</code>, and <code>message</code>
element collectively represent the message policy subject for the
output message. The WSDL <code>binding/operation/fault</code>,
<code>portType/operation/fault</code>, and <code>message</code>
element collectively represent the message policy subject for the
fault message. Policy expressions associated with a message policy
subject apply only to that message.</p>
<p>In the example below, the policy expression is attached to an
endpoint policy subject.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-10.</span> Company-X’s Policy Expression Attached to WSDL binding
Element</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
  &lt;PolicyReference URI="#secure" /&gt;
  &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
  …
&lt;/wsdl:binding&gt;
</pre></div>
</div>
<p>If multiple policy expressions are attached to WSDL elements
that collectively represent a policy subject then the effective
policy of these policy expressions applies. The effective policy is
the combination of the policy expressions that are attached to the
same policy subject. For example, the effective policy of an
endpoint policy subject is the combination of policy expressions
attached to a WSDL <code>port</code> element, policy expressions
attached to the <code>binding</code> element referenced by this
port, and policy expressions attached to the <code>portType</code>
element that is supported by this port. Let us consider how to
combine policy expressions in the next section.</p>
<p>Most of the policy assertions are designated for the endpoint,
operation or message policy subject. The commonly used WSDL
attachment points are:</p>
<a name="Table2" id="Table2"></a>
<table border="1" cellspacing="0" cellpadding="5">
<tbody>
<tr>
<th rowspan="1" colspan="1">Policy Subject</th>
<td rowspan="1" colspan="1">Commonly used attachment point (s)</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Endpoint</th>
<td rowspan="1" colspan="1"><code>binding</code> element</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Operation</th>
<td rowspan="1" colspan="1"><code>binding/operation</code>
element</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Message</th>
<td rowspan="1" colspan="1"><code>binding/operation/input</code>
and <code>binding/operation/output</code> elements</td>
</tr>
</tbody>
</table>
<br /></div>
<div class="div2">
<h3><a name="policy-retrieval" id="policy-retrieval"></a>3.6 Policy
Retrieval</h3>
<p>Just as other service metadata languages, Web Services Policy
does not mandate any specific policy retrieval mechanism. Any
combination of any retrieval mechanisms in any order may be used
for referencing policy expressions. Example retrieval mechanisms
are:</p>
<ul>
<li>
<p>Do nothing. A policy expression with the referenced IRI is
already known to be available in a local cache or chip (embedded
systems).</p>
</li>
<li>
<p>Use the referenced IRI and retrieve an existing policy
expression from the containing XML document: a policy element with
an XML ID.</p>
</li>
<li>
<p>Use the referenced IRI and retrieve a policy expression from
some policy repository (local or remote), registry or catalog.
Policy tools or policy-aware clients may use any protocols (say
UDDI or Web Services Metadata Exchange) for such metadata
retrieval. These protocols may require additional out of band
information.</p>
</li>
<li>
<p>Attempt to resolve the referenced IRI on the Web. This may
resolve to a policy element or a resource that contains a policy
element.</p>
</li>
</ul>
<p>If the referenced policy expression is in the same XML document
as the reference, then the policy expression should be identified
using the <code>wsu:Id|xml:id</code> (XML ID) attribute and
referenced using an IRI reference to this XML ID value.</p>
<p>WSDL 1.1 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] section
2.1 and WSDL 2.0 [<cite><a href="#WSDL20">WSDL 2.0 Core
Language</a></cite>] chapter 4 allow to import or include WSDL
documents into another WSDL document with the wsdl11:import,
wsdl20:import, and wsdl20:include statements. The importing and
imported WSDL documents constitute separate XML documents each. If
e.g. the importing WSDL document references a policy in the
imported WSDL document, the rules for policy references between
separate XML documents apply as described in <a href=
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
Expressions</b></a>.</p>
</div>
<div class="div2">
<h3><a name="combine-policies" id="combine-policies"></a>3.7
Combine Policies</h3>
<p>Multiple policy expressions may be attached to WSDL constructs.
Let us consider how Company-X could have used multiple policy
expressions in a WSDL document. In the example below, there are two
policy expressions <code>#common2</code> and <code>#secure2</code>
attached to the <code>SecureBinding</code> WSDL binding and
<code>RealTimeDataPort</code> WSDL port descriptions.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-11.</span> Multiple Policy Expressions Attached to Endpoint
Policy Subject</i></p>
<div class="exampleInner">
<pre>
&lt;Policy wsu:Id=”common2”&gt;
  &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
  &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
&lt;/Policy&gt;
&lt;Policy wsu:Id=”secure2”&gt;
  &lt;ExactlyOne&gt;
   &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
   &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
  &lt;PolicyReference URI="#secure2" /&gt;
  &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
  …
&lt;/wsdl:binding&gt;
&lt;wsdl:service name=”RealTimeDataService”&gt;
  &lt;wsdl:port name=”RealTimeDataPort” binding=”tns:SecureBinding”&gt;
    &lt;PolicyReference URI="#common2"/&gt;
    …
  &lt;/wsdl:port&gt;
&lt;/wsdl:service&gt;
</pre></div>
</div>
<p>As we discussed before, the WSDL <code>port</code>,
<code>binding</code> and <code>portType</code> elements
collectively represent the endpoint policy subject. In the example
above, the <code>#common2</code> and <code>#secure2</code> policy
expressions attached to the <code>SecureBinding</code> WSDL binding
and <code>RealTimeDataPort</code> WSDL port descriptions
collectively apply to any message exchange associated with the
<code>RealTimeDataPort</code> WSDL port.</p>
<p>As in the example above, multiple policy expressions may be
attached to Web service constructs that collectively represent a
single policy subject. When there are multiple policy expressions
attached to the same policy subject then the effective policy or
combination of these policy expressions apply to the associated
policy subject.</p>
<p>The effective policy is the combination of two or more policy
expressions attached to the same policy subject. The combination of
two policy expressions, also known as the merged policy expression,
is a new policy expression that combines these two policy
expressions using the <code>All</code> policy operator.</p>
<p>The policy expression below is the combination of the two policy
expressions attached to the <code>SecureBinding</code> WSDL binding
and <code>RealTimeDataPort</code> WSDL port descriptions. The
<code>#common2</code> policy expression has two policy
alternatives. The <code>#secure2</code> policy expression has two
policy alternatives. The combination of these two policies is
equivalent to Company-X’s secure policy in <a href=
"#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy
Expression</b></a> and has four policy alternatives. In other
words, the combination of two policies is the cross product of
alternatives in these two policies.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-12.</span> Effective Policy of the Endpoint Policy Subject in the
Previous Example</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;All&gt;
    &lt;Policy&gt;
     &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
    &lt;/Policy&gt;
    &lt;Policy&gt;
      &lt;ExactlyOne&gt;
       &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
       &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding &gt;
      &lt;/ExactlyOne&gt;
    &lt;/Policy&gt;
  &lt;/All&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>Of course, the above policy expression can be normalized. There
are four policy alternatives in the normal form. As we have seen in
the policy data model, a policy is an unordered collection of
policy alternatives. That is, the order of policy alternatives is
insignificant. Therefore, the order of combining these policy
expressions is insignificant.</p>
</div>
<div class="div2">
<h3><a name="extensibility-and-versioning" id=
"extensibility-and-versioning"></a>3.8 Extensibility and
Versioning</h3>
<div class="div3">
<h4><a name="ext-vers-policylanguage" id=
"ext-vers-policylanguage"></a>3.8.1 Policy Language</h4>
<p>Web Services Policy language is an extensible language by
design. The <code>Policy</code>, <code>ExactlyOne</code>,
<code>All</code> and <code>wsp:PolicyReference</code> elements are
extensible. The <code>Policy</code> element allows child element
and attribute extensibility, while the <code>ExactlyOne</code> and
<code>All</code> elements allow child element extensibility. The
<code>PolicyReference</code> child element allows element and
attribute extensibility. Extensions must not use the policy
language XML namespace name. A consuming processor processes known
attributes and elements, ignores unknown attributes and treats
unknown children of the <code>Policy</code>,
<code>ExactlyOne</code>, <code>All</code> elements as policy
assertions. The child elements of <code>wsp:PolicyReference</code>
are ignored.</p>
<p>The <code>PolicyReference</code> element allows element and
attribute extensibility.</p>
</div>
<div class="div3">
<h4><a name="d3e1496" id="d3e1496"></a>3.8.2 Policy
Expressions</h4>
<p>Services that use the Web Services Policy language for policy
expression enable simple versioning practices that allow requesters
to continue the use of older policy alternatives in a backward
compatible manner. This versioning practice allows service
providers, like Company-X, to deploy new behaviors using additional
(or new) policy assertions without breaking compatibility with
clients that rely on any older policy alternatives. We use examples
below to illustrate how versioning might be done.</p>
<p>The example below represents a Company-X version 1 policy
expression. This expression requires the use of addressing and
transport-level security for protecting messages.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-13.</span> Company-X’s Version 1 Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>Over time, Company-X adds support for advanced behaviors:
requiring the use of addressing and message-level security for
protecting messages. They would like to add this advanced support
without breaking compatibility with requesters that rely on
addressing and transport-level security. The example below is
Company-X’s version 2 policy expression. In this version, Company-X
adds a new policy alternative that requires the use of addressing
and message-level security. The clients that rely on addressing and
transport-level security may continue to interact with Company-X’s
using the old policy alternative. Of course, these clients have the
option to migrate from using old policy alternatives to new policy
alternatives.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-14.</span> Company-X’s Version 2 Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
    &lt;All&gt; &lt;!-- - - - - - - - - - - - - - - - NEW Policy Alternative --&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
      &lt;sp:AsymmetricBinding&gt;…&lt;/sp: AsymmetricBinding &gt;
    &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>When Company-X added support for advanced behaviors, they spent
time to plan for the continued support for existing clients, the
smooth migration from using current to advanced behaviors, and the
switch to use only the advanced behaviors in the near future (i.e.
sun-setting current behaviors). In this versioning scenario, a
policy expression with multiple alternatives was used to represent
current and advanced behaviors in a non-disruptive manner: no
immediate changes to existing clients are required and these
clients can smoothly migrate to new functionality when they choose
to. This level of versioning support in a policy expression enables
the same class of versioning best practices built into WSDL
constructs such as service, port and binding.</p>
<p>Let us look at tooling for unknown policy assertions. As service
providers, like Company-X, incrementally deploy advanced behaviors,
some requesters may not recognize these new policy assertions. As
discussed before, these requesters may continue to interact using
old policy alternatives. New policy assertions will emerge to
represent new behaviors and slowly become part of everyday
interoperable interaction between requesters and providers. For
example, most tools use a practical tolerant strategy to process
new or unrecognized policy assertions. These tools consume such
unrecognized assertions and designate these for user intervention.
As you would recognize, there is nothing new in this practice. This
is similar to how a proxy generator that generates code from WSDL
creates code for all the known WSDL constructs and allows Web
service developers to fill in code for custom or unknown constructs
in the WSDL.</p>
</div>
<div class="div3">
<h4><a name="ignorable-and-versioning" id=
"ignorable-and-versioning"></a>3.8.3 Use of Ignorable attribute and
an alternative Versioning Scenario</h4>
<p>One potential use of the wsp:Ignorable attribute is to mark
versioning related information by creating a new policy assertion
within a policy expression. The new assertion is added to the
original policy expression and then the service can update the
assertion parameter values when the service expires.</p>
<p>One scenario that illustrates this is a service which will
support a particular version of a service until a certain point in
time. After that time, the service will not be supported. In this
scenario, the expiry date and time of the service would be a new
policy assertion [see Guidelines section 4] that the service
provider defines . This hypothetical EndOfLife policy assertion is
then included in the original policy expression, but it could be
marked as ignorable. The service, in this case, wants to inform the
consumers it does have an expiry time, and so it is useful to
convey this information from the beginning to help smooth the
versioning process.</p>
<p>Company-X could specify that one policy alternative will expire
at a certain point in time using the hypothetical ignorable
Company-X expiry assertion. The example below shows how Company-X
can create a new version 2 policy expression with a second
hypothetical ignorable EndOfLife Assertion with a different date
and time.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
3-15.</span> Company-X's Version 2 Policy Expression with
hypothetical ignorable EndOfLife Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;ExactlyOne&gt;
    &lt;All&gt;
      &lt;company-x:EndOfLife wsp:Ignorable="true"/&gt;Mar-31-2008&lt;/company-x:EndOfLife&gt;
      &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
      &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
    &lt;/All&gt;
                
    &lt;!-- NEW Policy Alternative --&gt;
    &lt;All&gt; 
      &lt;company-x:EndOfLife wsp:Ignorable="true"&gt;Mar-31-2999&lt;/company-x:EndOfLife&gt;
        &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
        &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
      &lt;/All&gt;
  &lt;/ExactlyOne&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>In this variant of the versioning scenario, the use of ignorable
allows versioning related information to be conveyed and used where
understood.</p>
<p>In a scenario such as this, CompanyX is acting as both a policy
assertion author and a policy expression author. As a policy
expression author, when an assertion type is tagged as ignorable
information, the use of strict or lax mode and presence or absence
of the assertion type in the first version are important
decisions.</p>
</div>
<div class="div3">
<h4><a name="ignorable-and-optional-and-versioning" id=
"ignorable-and-optional-and-versioning"></a>3.8.4 Use of Ignorable
and Optional attributes</h4>
<p>If Company-X knows about the hypothetical EndOfLife Policy
assertion, it may or may not mark that assertion with
wsp:Optional="true" in the first version. If it does include the
assertion, marks the assertion with wsp:Ignorable="true" and
wsp:Optional="false", then a client that:</p>
<ul>
<li>
<p>does not know about the assertion and using lax intersection
will produce an intersection.</p>
</li>
<li>
<p>does not know about the assertion and using strict intersection
will not produce an intersection.</p>
</li>
<li>
<p>does know about the assertion and using strict or lax
intersection will produce an intersection.</p>
</li>
</ul>
<p>If it does include the assertion, marks the assertion with
wsp:Ignorable="true" and wsp:Optional="true", then a client
that:</p>
<ul>
<li>
<p>does or does not know about the assertion and using lax or
strict intersection will produce an intersection.</p>
</li>
</ul>
<p>The following table summarizes the requester assertion knowledge
and intersection mode on the left vs provider ignorable and
optional on the top</p>
<table summary=
"Requester assertion knowledge and intersection mode vs provider ignorable and optional"
border="true">
<tbody>
<tr>
<td rowspan="1" colspan="1">Requester \ Provider</td>
<td rowspan="1" colspan="1">Required</td>
<td rowspan="1" colspan="1">Required and Ignorable (for
intersection)</td>
<td rowspan="1" colspan="1">Optional</td>
<td rowspan="1" colspan="1">Optional and Ignorable (for
intersection)</td>
</tr>
<tr>
<td rowspan="1" colspan="1">does not know, lax</td>
<td rowspan="1" colspan="1">No</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="1">does not know, strict</td>
<td rowspan="1" colspan="1">No</td>
<td rowspan="1" colspan="1">No</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="1">does know, lax</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
</tr>
<tr>
<td rowspan="1" colspan="1">does know, strict</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
<td rowspan="1" colspan="1">Yes</td>
</tr>
</tbody>
</table>
<br />
<p>If Company-X adds the hypothetical EndOfLife policy assertion
type to a subsequent Alternative and does not mark the assertion
with wsp:Optional="true", then after the policy expression has been
deployed/used the same algorithm holds true, notably that a client
using strict mode that does not understand the assertion will not
intersect with the alternative. If CompanyX adds the hypothetical
EndOfLife policy assertion with an ignorable attribute and does
mark the assertion with wsp:Optional="true", then clients using
strict mode who do not understand the hypothetical EndOfLife
assertion with the ignorable information will still be compatible
with the alternative that does not contain the hypothetical
EndOfLife policy assertion as per the intersection rules. When
wsp:Ignorable="true" is used, clients that are unaware of the
hypothetical EndOfLife assertion may make more requests for expired
services. This could result in servers generating Faults if the
request is received after the expiry date. .</p>
<p>If Company-X knows about the hypothetical EndOfLife Policy
assertion, it can guarantee that clients that know or don't know
about the hypothetical EndOfLife Policy Assertion can intersect
under any mode by marking the assertion with wsp:Optional="true".
Clients that know about the hypothetical EndOfLife Policy assertion
and performing strict intersection can guarantee interaction with
services that know or don't know about the hypothetical EndOfLife
Policy assertion by marking the assertion with wsp:Optional="true".
Clients that know about the hypothetical EndOfLife Policy assertion
and performing lax intersection can guarantee interaction with
services that know or don't know about the hypothetical EndOfLife
Policy assertion by marking the assertion with wsp:Optional="true"
or marking it with wsp:Ignorable="true".</p>
<p>Because the actual value of the date/time may not be known when
the policy expression is first created, a value that is roughly
infinitely in the future is used. A subsequent policy alternative
could refine the value and domain specific processing of the
assertion can differentiate the value. The advantage of adding the
end of life information through a domain specific assertion is that
some clients will have a machine processable way of knowing when
the alternative will no longer be supported by evaluating the
policy assertions in a policy expression. Without this information
in a policy expression, the information must be conveyed in some
other way or it will not be conveyed at all. This can usefully
smooth the transition between versions of a service.</p>
<p>The disadvantage of adding the end of life information through a
domain specific assertion is that clients need to understand the
semantics of the hypothetical EndOfLife assertion in order to know
whether a particular alternative is still valid. For example, a
client that doesn’t know what the parameter “Mar-31-2008” means,
will not know that the service is no longer available on April 1,
and may send messages to this service in April, and if the service
enforces “end of life”, these messages may fail.</p>
</div>
</div>
<div class="div2">
<h3><a name="parts-of-a-policy-assertion" id=
"parts-of-a-policy-assertion"></a>3.9 Parts of a Policy
Assertion</h3>
<p>As we discussed, a policy assertion identifies a domain specific
behavior or requirement or condition. A policy assertion has a
QName that identifies its behavior or requirement or condition. A
policy assertion may contain assertion parameters and a nested
policy.</p>
<p>Let us look at the anatomy of a policy assertion from the
security domain. The policy expression in the diagram below uses
the <code>sp:IssuedToken</code> policy assertion. This assertion
illustrates the use of assertion parameters and nested policy.</p>
<div class="figure" style="text-align: center"><br />
<img src="policy-assertion.jpg" alt=
"sp:IssuedToken Policy Assertion" />
<p style="text-align:left"><i><span>Figure 3-4.</span>
sp:IssuedToken Policy Assertion</i></p>
<br /></div>
<p>The <code>sp:IssuedToken</code> element is a policy assertion
that identifies the use of a security token – such as SAML token -
issued by a third party for protecting messages. A policy assertion
is an XML element. The QName of this element represents the
behavior identified by this policy assertion.</p>
<p>The <code>sp:IssuedToken</code> policy assertion has three
parameters: <code>@sp:IncludeToken</code>, <code>sp:Issuer</code>
and <code>sp:RequestSecurityTokenTemplate</code>.</p>
<p>The <code>sp:IncludeToken</code> attribute is a parameter that
contains information on whether a security token should be included
in messages or an external reference to the key of this security
token should be used. The <code>sp:Issuer</code> parameter is an
endpoint reference to a security token issuer. The
<code>sp:RequestSecurityTokenTemplate</code> parameter contains the
necessary information to request a security token from the
specified issuer. Parameters are the opaque payload of a Policy
Assertion, carry useful information for engaging the behavior
described by an assertion and are preserved through policy
processing such as normalize, merge and intersection. requesters
may use policy intersection to select a compatible policy
alternative for an interaction. Assertion parameters do not affect
the outcome of policy intersection.</p>
<p>For the <code>sp:Issuer</code> policy assertion parameter, the
assertion author uses the natural XML structural relationships (the
child elements and attributes) and encodes the relationship between
an assertion and its parameters in a machine readable form.
Assertion parameters may be represented as child XML elements or
attributes of an assertion. The policy language allows assertion
authors to strongly tie the relationship between an assertion and
its parameters using the natural XML structural relationships.</p>
<p>The <code>sp:IssuedToken</code> policy assertion has a nested
policy expression. The <code>sp:RequireInternalReference</code>
element is a nested policy assertion of the
<code>sp:IssuedToken</code> policy assertion. The
<code>sp:RequireInternalReference</code> assertion requires the use
of an internal reference for referencing the issued token. A nested
policy assertion further qualifies a dependent behavior of its
parent policy assertion. As mentioned earlier, requesters may use
policy intersection to select a compatible policy alternative for
an interaction. Nested policy assertions affect the outcome of
policy intersection.</p>
<p>The <code>sp:IssuedToken</code> security policy assertion
identifies a visible domain specific behavior: the use of a
security token – such as SAML token - issued by a third party for
protecting messages. This behavior is relevant to a Web service
interaction. For the sake of discussion, let us assume that
Company-X requires the use of a SAML token issued by a third party.
Service providers, like Company-X, must convey this usage and all
the necessary information to obtain this security token for Web
service developers. This is a key piece of metadata for a
successful interaction with Company-X’s Web services.</p>
</div>
</div>
<div class="div1">
<h2><a name="versioning-policy-language" id=
"versioning-policy-language"></a>4. Versioning Policy Language</h2>
<p>Over time, the Policy WG or third parties can version or extend
the Policy Language with new or modified constructs. These
constructs may be compatible or incompatible with previous
versions. Some of the possible new constructs that have been
mentioned previously are: new operators, operator cardinality,
policy identification, compact syntax, Policy Inclusion, security,
referencing, attachment points, alternative priority, effective
dating, negotiation.</p>
<p>WS-Policy provides extensibility points on 6 elements with a
combination of attribute and/or element extensibility. The possible
extensibility points are:</p>
<ol class="enumar">
<li>
<p>Policy: element from ##other namespace and any attribute</p>
</li>
<li>
<p>PolicyReference: any attribute and any element</p>
</li>
<li>
<p>ExactlyOne, All: element from ##other namespace, no attribute
extensibility</p>
</li>
<li>
<p>PolicyAttachment: element from ##other namespace and any
attribute</p>
</li>
<li>
<p>AppliesTo: any element and any attribute</p>
</li>
</ol>
<div class="div2">
<h3><a name="versioning-policy-framework" id=
"versioning-policy-framework"></a>4.1 Policy Framework</h3>
<p>WS-Policy Framework 1.5 specifies that any child element that is
not known inside a Policy, ExactlyOne or All will be treated as an
assertion. The default value for wsp:Optional is "false". After
normalization, such an element will be inside an ExactlyOne/All
operator.</p>
<p>Let us show an example with a hypothetical new operator that is
a Choice with a minOccurs and a maxOccurs attributes, ala
XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate
a hypothetical Policy Language 1.6 that is intended to be
compatible with Policy Language 1.5:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-1.</span> Policy containing 1.5 and 1.6 Policies.</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"&gt;
      ...
    &lt;/wsp16:Choice&gt;
    &lt;wsp:All&gt;
       ...
    &lt;/wsp:All&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>The normalization rule for wsp:Optional="false" would be applied
to the wsp16:Choice, yielding the following expression:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-2.</span> Normalized Policy containing 1.5 and 1.6
Policies</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp:ExactlyOne&gt;
      &lt;wsp:All&gt;
         &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"&gt;
          ...
        &lt;/wsp16:Choice&gt;
      &lt;/wsp:All&gt;
    &lt;/wsp:ExactlyOne&gt;
    &lt;wsp:All&gt;
       ...
    &lt;/wsp:All&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>Alternatively, the wsp:Optional could be set to "true" on the
choice, as in:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-3.</span> Policy containing explicit wsp:Optional="true"</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
wsp:Optional="true"&gt;
      ...
  &lt;/wsp16:Choice&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>The normalized form will be:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-4.</span> Normalized policy</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;wsp:ExactlyOne&gt;
     &lt;wsp:All&gt;
         &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"&gt;
          ...
        &lt;/wsp16:Choice&gt;
      &lt;/wsp:All&gt;
     &lt;wsp:All/&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>Because the wsp16:Choice alternative isn't understood in either
normalized form, it will not be chosen as one of the alternatives
and will effectively be ignored. Policy intersection may be more
difficult with such compatible extensions. For example, the
previous will "look" like it has a wsp16:Choice typed assertion. To
determine intersection with a Policy that does not have the
wsp16:Choice type assertion, domain specific processing would have
to be done. However, there is an alternative that does not have the
wsp16:Choice, so intersection would yield the expected result.</p>
<p>Best practice: insert new elements in an optional alternative or
mark with wsp:Optional="true".</p>
<p>Incompatible versions of the Policy language may be indicated by
a new namespace name for at least the new and/or incompatible
elements or attributes. Imagine that the Choice operator is
required by a future version of Policy, then there will be a new
namespace for the Policy element. We use the wsp20 prefix to
indicate a hypothetical Policy Language 2.0 that is intended to be
incompatible with Policy Language 1.5:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-5.</span> Policy containing 2.0 only Policies.</i></p>
<div class="exampleInner">
<pre>
&lt;wsp20:Policy&gt;
  &lt;wsp20:ExactlyOne&gt;
    &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
      ...
    &lt;/wsp20:Choice&gt;
    ...
  &lt;/wsp20:ExactlyOne&gt;
&lt;/wsp20:Policy&gt; 
</pre></div>
</div>
<p>The new Policy operator could be embedded inside an existing
Policy element:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-6.</span> Policy containing 2.0 (incompatible with 1.5) Policies
embedded in wsp 1.5 Policy.</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
    &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
      ...
    &lt;/wsp20:Choice&gt;
    ...
&lt;/wsp20:Policy&gt; 
</pre></div>
</div>
<p>This will be treated as an Assertion for normalization and
intersection computation. This will result in only one alternative
that requires the wsp20:Choice, the intended behaviour for
incompatible changes.</p>
<p>Best practice: use a new namespace for new incompatible
construct and insert inside either: new Policy element OR existing
All for future incompatible policy extensions.</p>
<p>A future version of WS-Policy could support the current
operators in the existing namespace, such as:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-7.</span> Policy containing 1.5 operator in 2.0 Policy</i></p>
<div class="exampleInner">
<pre>
&lt;wsp20:Policy&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
      ...
    &lt;/wsp20:Choice&gt;
    ...
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp20:Policy&gt; 
</pre></div>
</div>
<p>It is difficult to predict whether this functionality would be
useful. The future version of WS-Policy doesn't appear to be
precluded from doing this.</p>
</div>
<div class="div2">
<h3><a name="versioning-policy-attachment" id=
"versioning-policy-attachment"></a>4.2 Policy Attachment</h3>
<p>Policy attachment provides WSDL 1.1 and UDDI attachment points.
It appears that exchange of Policy will be in the context of WSDL
or UDDI. WRT WSDL, the policy model is an extension of the WSDL
definition. As such, it is likely that future versions of Policy
will be exchanged as multiple Policy expressions within a WSDL. One
alternative is that there would be a separate WSDL for each version
of Policy. The problem of how to specify and query for compound
documents is very difficult, so it is more likely that each version
of Policy will be exchanged within a WSDL.</p>
<p>We show an example of a new version of policy that allows QName
reference to Policies in the PolicyReference:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-8.</span> WSDL containing 1.5 and 1.6 (compatible with 1.5)
Policy References.</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
       &lt;wsoap12:binding style="document"
          transport="http://schemas.xmlsoap.org/soap/http" /&gt;
        &lt;wsp:Policy&gt;
          &lt;wsp:ExactlyOne&gt;
                &lt;wsp:All&gt;
                &lt;wsp:PolicyReference URI="#RmPolicy"
wsdl11:required="true" /&gt;
              &lt;wsp:PolicyReference URI="#X509EndpointPolicy"
wsdl11:required="true" /&gt;
                &lt;/wsp:All&gt;
                &lt;wsp:All&gt;
                &lt;wsp16:PolicyReferenceByQName ref="rmp:RMAssertion"
wsdl11:required="true" /&gt;
              &lt;wsp16:PolicyReferenceByQName ref="sp:AsymmetricBinding"
wsdl11:required="true" /&gt;
                &lt;/wsp:All&gt;
         &lt;/wsp:ExactlyOne&gt;
        &lt;/wsp:Policy&gt;
  &lt;wsdl11:operation name="GetLastTradePrice" &gt; ....
  ...
</pre></div>
</div>
<p>The PolicyReference element is element or attribute extensible.
One example of an addition is a list of backup URIs for the
PolicyReference:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
4-9.</span> WSDL containing 1.5 and 1.6 (compatible with 1.5)
Policy References.</i></p>
<div class="exampleInner">
<pre>
&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
       &lt;wsoap12:binding style="document"
          transport="http://schemas.xmlsoap.org/soap/http" /&gt;
        &lt;wsp:Policy&gt;
          &lt;wsp:ExactlyOne&gt;
                &lt;wsp:All&gt;
                &lt;wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
wsdl11:required="true" /&gt;
              &lt;wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
wsdl11:required="true" /&gt;
                &lt;/wsp:All&gt;
         &lt;/wsp:ExactlyOne&gt;
        &lt;/wsp:Policy&gt;
  &lt;wsdl11:operation name="GetLastTradePrice" &gt; ....
  ...
</pre></div>
</div>
<p>The policy framework specification says that any unknown
attributes are ignored. A Policy 1.5 processor will not understand
the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6
processor will understand the alternate URIs so it won't be
ignored.</p>
<p>PolicyAttachment and AppliesTo also have extensibility points.
We choose not to illustrate these at this time.</p>
</div>
</div>
<div class="div1">
<h2><a name="conclusion" id="conclusion"></a>5. Conclusion</h2>
<p>Service providers use Web Services Policy to represent
combinations of behaviors (capabilities and requirements). Web
service developers use policy-aware clients that understand policy
expressions and engage the behaviors represented by providers
automatically. These behaviors may include security, reliability,
transaction, message optimization, etc. Web Services Policy is a
simple language, hides complexity from developers, automates Web
service interactions, and enables secure, reliable and transacted
Web Services.</p>
</div>
</div>
<div class="back">
<div class="div1">
<h2><a name="security-considerations" id=
"security-considerations"></a>A. Security Considerations</h2>
<p>Security considerations are discussed in the <cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite> document.</p>
</div>
<div class="div1">
<h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML
Namespaces</h2>
<p>The table below lists XML Namespaces that are used in this
document. The choice of any namespace prefix is arbitrary and not
semantically significant.</p>
<a name="nsprefix" id="nsprefix"></a>
<table summary=
"Prefixes and XML Namespaces used in this specification" border="1"
cellspacing="0" cellpadding="5">
<caption>Table B-1. Prefixes and XML Namespaces used in this
specification.</caption>
<thead>
<tr>
<th rowspan="1" colspan="1">Prefix</th>
<th rowspan="1" colspan="1">XML Namespace</th>
<th rowspan="1" colspan="1">Specifications</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1"><code>mtom</code></td>
<td rowspan="1" colspan="1">
<code>http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-MTOMPolicy">WS-MTOMPolicy</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>soap</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/2003/05/soap-envelope</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#SOAP12">SOAP 1.2
Messaging Framework (Second Edition)</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>sp</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsa</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/2005/08/addressing</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Addressing">WS-Addressing Core</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsam</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/2007/05/addressing/metadata</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsdl</code></td>
<td rowspan="1" colspan="1">
<code>http://schemas.xmlsoap.org/wsdl/</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#WSDL11">WSDL
1.1</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsp</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/ns/ws-policy</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#WS-Policy">Web
Services Policy Framework</a></cite>, <cite><a href=
"#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wss</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Security2004">WS-Security 2004</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wst</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/ws-sx/ws-trust/200512</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Trust">WS-Trust</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsu</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Security2004">WS-Security 2004</a></cite>]</td>
</tr>
</tbody>
</table>
<br /></div>
<div class="div1">
<h2><a name="references" id="references"></a>C. References</h2>
<dl>
<dt class="label"><a name="C14NNOTE" id="C14NNOTE"></a>[C14N 1.0
Note]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/">Known Issues
with Canonical XML 1.0 (C14N/1.0)</a></cite>, J. Kahan and K. Lanz,
Editors. World Wide Web Consortium, 20 December 2006. Available at
http:/www.w3.org/TR/2006/NOTE-C14N-issues-20061220/&gt;.</dd>
<dt class="label"><a name="MTOM" id="MTOM"></a>[MTOM]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message
Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web
Consortium, 25 January 2005. This version of the SOAP Message
Transmission Optimization Mechanism Recommendation is
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The <a href=
"http://www.w3.org/TR/soap12-mtom/">latest version of SOAP Message
Transmission Optimization Mechanism</a> is available at
http://www.w3.org/TR/soap12-mtom/.</dd>
<dt class="label"><a name="WS-MTOMPolicy" id=
"WS-MTOMPolicy"></a>[WS-MTOMPolicy]</dt>
<dd><cite><a href=
"http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/">
MTOM Serialization Policy Assertion (WS-MTOMPolicy)</a></cite>, C.
Ferris, et al, Authors. International Business Machines Corporation
and Microsoft Corporation, Inc., September 2006. Available at
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/</dd>
<dt class="label"><a name="SOAP11" id="SOAP11"></a>[SOAP 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object
Access Protocol (SOAP) 1.1</a></cite>, D. Box, et al, Editors.
World Wide Web Consortium, 8 May 2000. Available at
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.</dd>
<dt class="label"><a name="SOAP12" id="SOAP12"></a>[SOAP 1.2
Messaging Framework (Second Edition)]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)</a></cite>, M.
Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
A. Karmarkar, and Y. Lafon, Editors. World Wide Web Consortium, 27
April 2007. This version of the SOAP Version 1.2 Part 1: Messaging
Framework Recommendation is
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The <a href=
"http://www.w3.org/TR/soap12-part1/">latest version of SOAP Version
1.2 Part 1: Messaging Framework</a> is available at
http://www.w3.org/TR/soap12-part1/.</dd>
<dt class="label"><a name="SecSpecMaintWG" id=
"SecSpecMaintWG"></a>[SecSpecMaintWG]</dt>
<dd><cite><a href="http://www.w3.org/2007/xmlsec">XML Security
Specifications Maintenance Working Group</a></cite> , See
http://www.w3.org/2007/xmlsec.</dd>
<dt class="label"><a name="WS-Addressing" id=
"WS-Addressing"></a>[WS-Addressing Core]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/">Web Services
Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, and T.
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This
version of the Web Services Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href=
"http://www.w3.org/TR/ws-addr-core/">latest version of Web Services
Addressing 1.0 - Core</a> is available at
http://www.w3.org/TR/ws-addr-core.</dd>
<dt class="label"><a name="WS-AddressingMetadata" id=
"WS-AddressingMetadata"></a>[WS-Addressing Metadata]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web
Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M.
Hadley, T. Rogers and Ü. Yalçinalp, Editors. World Wide Web
Consortium, 4 September 2007. This version of the Web Services
Addressing 1.0 - Metadata W3C Recommendation is
http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. The
<a href="http://www.w3.org/TR/ws-addr-metadata">latest version of
Web Services Addressing 1.0 - Metadata</a> is available at
http://www.w3.org/TR/ws-addr-metadata.</dd>
<dt class="label"><a name="WS-Atomic" id="WS-Atomic"></a>[Web
Services Atomic Transaction]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html">
Web Services Atomic Transaction (WS-AtomicTransaction) Version
1.1</a></cite>, M. Little, A. Wilkinson, Editors. Organization for
the Advancement of Structured Information Standards, OASIS
Standard, 16 April 2007. This version available at
http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-tx/wsat/2006/06">http://docs.oasis-open.org/ws-tx/wsat/2006/06</a>.</dd>
<dt class="label"><a name="WS-BA" id="WS-BA"></a>[Web Services
Business Activity Framework]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html">
Web Services Business Activity (WS-BusinessActivity) Version
1.1</a></cite>, T. Freund, M. Little, Editors. Organization for the
Advancement of Structured Information Standards, OASIS Standard, 16
April 2007. This version available at
http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-tx/wsba/2006/06">http://docs.oasis-open.org/ws-tx/wsba/2006/06</a>.</dd>
<dt class="label"><a name="WS-Device" id="WS-Device"></a>[Devices
Profile for Web Services]</dt>
<dd><cite><a href=
"http://schemas.xmlsoap.org/ws/2006/02/devprof/">Devices Profile
for Web Services</a></cite>, S. Chan, et al, Authors. Intel
Corporation, Lexmark, Inc., Microsoft Corporation, and Richo
Software, Inc., February 2006. Available at
http://schemas.xmlsoap.org/ws/2006/02/devprof/.</dd>
<dt class="label"><a name="WS-MetadataExchange" id=
"WS-MetadataExchange"></a>[WS-MetadataExchange]</dt>
<dd><cite><a href="http://schemas.xmlsoap.org/ws/2004/09/mex/">Web
Services Metadata Exchange (WS-MetadataExchange)</a></cite>, K.
Ballinger, et al, Authors. BEA Systems Inc., Computer Associates
International, Inc., International Business Machines Corporation,
Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and
webMethods, August 2006. Available at
http://schemas.xmlsoap.org/ws/2004/09/mex/</dd>
<dt class="label"><a name="WS-Policy" id="WS-Policy"></a>[Web
Services Policy Framework]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-policy-20070904/">Web Services
Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F.
Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors.
World Wide Web Consortium, 4 September 2007. This version of the
Web Services Policy 1.5 - Framework specification is at
http://www.w3.org/TR/2007/REC-ws-policy-20070904/. The <a href=
"http://www.w3.org/TR/ws-policy/">latest version of Web Services
Policy 1.5 - Framework</a> is available at
http://www.w3.org/TR/ws-policy/.</dd>
<dt class="label"><a name="WS-PolicyAttachment" id=
"WS-PolicyAttachment"></a>[Web Services Policy Attachment]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/">Web
Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D.
Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü.
Yalçinalp, Editors. World Wide Web Consortium, 4 September 2007.
This version of the Web Services Policy 1.5 - Attachment
specification is at
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. The
<a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
http://www.w3.org/TR/ws-policy-attach/.</dd>
<dt class="label"><a name="WS-RM-Policy" id="WS-RM-Policy"></a>[Web
Services Reliable Messaging Policy Assertion]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf">
Web Services Reliable Messaging Policy Assertion (WS-RM Policy)
Version 1.1</a></cite>, D. Davis, A. Kamarkar, G. Pilz, and Ü.
Yalçinalp, Editors. Organization for the Advancement of Structured
Information Standards, OASIS Standard, 14 June 2007. This version
available at
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-rx/wsrmp/200702">http://docs.oasis-open.org/ws-rx/wsrmp/200702</a>.</dd>
<dt class="label"><a name="WSDL11" id="WSDL11"></a>[WSDL 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services
Description Language (WSDL) 1.1</a></cite>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.</dd>
<dt class="label"><a name="WSDL20" id="WSDL20"></a>[WSDL 2.0 Core
Language]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626/">Web Services
Description Language (WSDL) Version 2.0 Part 1: Core
Language</a></cite>, R. Chinnici, J. J. Moreau, A. Ryman, S.
Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
version of the WSDL 2.0 specification is
http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The <a href=
"http://www.w3.org/TR/wsdl20/">latest version of WSDL 2.0</a> is
available at http://www.w3.org/TR/wsdl20.</dd>
<dt class="label"><a name="WS-Security2004" id=
"WS-Security2004"></a>[WS-Security 2004]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">
Web Services Security: SOAP Message Security 1.0</a></cite>, A.
Nadalin, C. Kaler, P. Hallam-Baker and R. Monzillo, Editors.
Organization for the Advancement of Structured Information
Standards, March 2004. Available at
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.</dd>
<dt class="label"><a name="WS-SecurityPolicy" id=
"WS-SecurityPolicy"></a>[WS-SecurityPolicy]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf">
WS-SecurityPolicy v1.2</a></cite>, A. Nadalin, M. Goodner, M.
Gudgin, A. Barbir, and H. Granqvist, Editors. Organization for the
Advancement of Structured Information Standards, 1 July 2007.
Available at
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702</a>.</dd>
<dt class="label"><a name="WS-Trust" id=
"WS-Trust"></a>[WS-Trust]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf">
Web Services Atomic Transaction (WS-AtomicTransaction) Version
1.1</a></cite>, M. Little, A. Wilkinson, Editors. Organization for
the Advancement of Structured Information Standards, OASIS
Standard, 16 April 2007. This version available at
http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-tx/wsat/2006/06">http://docs.oasis-open.org/ws-tx/wsat/2006/06</a>.</dd>
<dt class="label"><a name="XMLID" id="XMLID"></a>[XML ID]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-xml-id-20050909/">xml:id Version
1.0</a></cite>, J. Marsh, D. Veillard and N. Walsh, Editors. World
Wide Web Consortium, 9 September 2005. This version of the xml:id
Version 1.0 Recommendation is
http://www.w3.org/TR/2005/REC-xml-id-20050909/. The <a href=
"http://www.w3.org/TR/xml-id/">latest version of xml:id Version
1.0</a> is available at http://www.w3.org/TR/xml-id/.</dd>
<dt class="label"><a name="C14N11" id="C14N11"></a>[C14N11]</dt>
<dd><cite><a href="http://www.w3.org/TR/xml-c14n11/">Canonical XML
1.1</a></cite>, J. Boyer and G. Marcy Authors. W3C Candidate
Recommendation, 21 June 2007. This is a work in progress. This
version is available at
http://www.w3.org/TR/2007/CR-xml-c14n11-20070621. The <a href=
"http://www.w3.org/TR/xml-c14n11/">latest version of Canonical XML
1.1</a> is available at http://www.w3.org/TR//xml-c14n11/.</dd>
<dt class="label"><a name="XOP" id="XOP"></a>[XOP]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-xop10-20050125/">XML-binary
Optimized Packaging</a></cite>, M. Gudgin, N. Mendelsohn, M.
Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25
January 2005. This version of the XML-binary Optimized Packaging
Recommendation is http://www.w3.org/TR/2005/REC-xop10-20050125/.
The <a href="http://www.w3.org/TR/xop10/">latest version of
XML-binary Optimized Packaging</a> is available at
http://www.w3.org/TR/xop10/.</dd>
</dl>
</div>
<div class="div1">
<h2><a name="acknowledgments" id="acknowledgments"></a>D.
Acknowledgements (Non-Normative)</h2>
<p>This document is the work of the <a href=
"http://www.w3.org/2002/ws/policy/">W3C Web Services Policy Working
Group</a>.</p>
<p>Members of the Working Group are (at the time of writing, and by
alphabetical order): Dimitar Angelov (SAP AG), Abbie Barbir (Nortel
Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin
(IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic
Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.),
Paul Cotton (Microsoft Corporation), Doug Davis (IBM Corporation),
Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2),
Christopher Ferris (IBM Corporation), William Henry (IONA
Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM
Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones
(Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul
Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark
Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation),
Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Arnaud
Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation),
Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation),
David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula
Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel
Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka
Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA),
Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2),
Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).</p>
<p>Previous members of the Working Group were: Jeffrey Crump, Glen
Daniels, Jong Lee, Monica Martin, Bob Natale, Eugene Osovetsky,
Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.</p>
<p>The people who have contributed to <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.</p>
</div>
<div class="div1">
<h2><a name="change-description" id="change-description"></a>E.
Changes in this Version of the Document (Non-Normative)</h2>
<p>A list of editorial changes since the Working Draft dated 28
September, 2007 is below:</p>
<ul>
<li>
<p>Added a UDDI example to <a href=
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
Expressions</b></a>.</p>
</li>
<li>
<p>Dropped the terms policy vocabulary and policy alternative
vocabulary.</p>
</li>
<li>
<p>Dropped an incorrect wsp:Choice example and changed wsp to wsp16
prefix in <a href="#versioning-policy-language"><b>4. Versioning
Policy Language</b></a>.</p>
</li>
<li>
<p>Updated <a href="#references"><b>C. References</b></a>.</p>
</li>
</ul>
</div>
<div class="div1">
<h2><a name="change-log" id="change-log"></a>F. Web Services Policy
1.5 - Primer Change Log (Non-Normative)</h2>
<a name="ws-policy-primer-changelog-table" id=
"ws-policy-primer-changelog-table"></a>
<table border="1">
<tbody>
<tr>
<th rowspan="1" colspan="1">Date</th>
<th rowspan="1" colspan="1">Author</th>
<th rowspan="1" colspan="1">Description</th>
</tr>
<tr>
<td rowspan="1" colspan="1">20060816</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Created first draft per action item
<a href=
"http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02">2</a>
from the Austin F2F. This draft is based on a <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0001.html">
contribution</a> from Microsoft.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060829</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/2006/08/23-ws-policy-minutes.html#action06">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3561">3561</a>:
replaced URI with IRI.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060919</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/26">action
26</a> to add versioning material to primer.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060924</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35">editorial
action 35</a> to move the Security Considerations section to the
Framework document.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060924</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/36">editorial
action 36</a> to insert a reference to the Security Considerations
section from the Framework document.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060926</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Made a first pass at the changes to
address issues <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">
reported by Paul Cotton.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20060928</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Completed making remaining changes to
address issues <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">
reported by Paul Cotton.</a> Fixing up the Acknowledgements is
pending</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061020</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented resolution for Issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3827">3827.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/56">56.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061027</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented resolution for Issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3815">3815.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/55">55.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061101</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented resolution for Issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3795">3815.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/68">68.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061101</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented the resolution for Issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3791">3791.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/67">67.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061121</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/0216.html">
resolution</a> for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3809">3809.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/79">79.</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061121</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/2006/11/15-ws-policy-minutes.html#item08">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3966">3966.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/81">81</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061125</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061125</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3792#c2">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3792">3792.</a>
Editors Action Item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/80">80:</a>
moved Sections <a href=
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#parts-of-a-policy-assertion">
4.2 Parts of a Policy Assertion</a> and <a href=
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#versioning-policy-language">
4.4.8 Versioning Policy Language</a> into Section <a href=
"#advanced-concepts-policy-expression"><b>3. Advanced Concepts:
Policy Expression</b></a>; moved Section <a href=
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#advanced-concepts-2-policy-assertion-design">
4 Advanced Concepts II: Policy Assertion Design</a> into the
Guidelines document.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061127</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">
Frederick</a> and <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">
Umit</a> to the list of editors. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061207</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3952">issue 3952</a>
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0018.html">
as outlined</a> (with editorial correction replacing "for as" with
"as"), Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/92">92</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061213</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3965">issue 3965</a>
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0016.html">
as outlined.</a> Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/94">94</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070104</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4069">issue 4069</a>
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0081.html">
as outlined.</a> Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/110">110</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070108</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070118</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4041">issue 4041</a>
<a href=
"http://www.w3.org/2007/01/18-ws-policy-irc#T22-09-36">resolution</a>
corresponding to Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/143">143</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070122</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/118">118</a>
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070122</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/127">127</a>
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070131</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4270">4270</a> as
Resolved on 31 January 2007, closing editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/151">151</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070313</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T18-27-19">resolution</a>
to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4379">issue 4379</a>
with minor editorial revision (editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/181">181</a>).
Updated references order.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070314</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T22-33-55">resolution</a>
to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4263">issue 4263</a>
(editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/195">195</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T22-27-24">the
resolution</a> to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4339">issue 4339</a>
(editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/194">194</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/14-ws-policy-irc#T17-29-32">the
resolution</a> to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4262">issue 4262</a>
(editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/201">201</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T21-39-50">resolution</a>
to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4255">issue 4255</a>
(editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/192">192</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4288#c4">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4288">issue
4288</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/196">196</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979">issue
3979</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/198">198</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Applied <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T21-39-50">resolution</a>
to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4253">issue 4253</a>
(editors action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191">191</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070319</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4213">issue 4213</a>
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html">
as outlined.</a> Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189">189</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070319</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103">issue 4103</a>
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">
as outlined.</a> Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070320</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue
4300</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070321</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070321</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Formatted the example in <a href=
"#ignorable-and-versioning"><b>3.8.3 Use of Ignorable attribute and
an alternative Versioning Scenario</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070322</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Deleted residual text in <a href=
"#versioning-policy-language"><b>4. Versioning Policy
Language</b></a>; <code>s/The possible extensibility points with
their current extensibility - including some outstanding issues
related to extensibility - are:/The possible extensibility points
are:/</code> ; <code>s/PolicyReference: any attribute and a
proposal to add any element/PolicyReference: any attribute and any
element/</code>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070426</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Editorial changes to align with the
OASIS WS-SecurityPolicy specification. For <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4318">issue
4318</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/244">244</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070430</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Editorial changes for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue
4393</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070501</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070502</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Further changes for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue
4393</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070502</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Finished changes for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414">issue
4414</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070524</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Finished changes for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4559">issue
4559</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/281">281</a>,
and <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4376">issue
4375</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/282">282</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Updated the C14N11 reference
[<cite><a href="#C14N11">C14N11</a></cite>] for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4851">4851</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/337">337</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Updated Web Services Reliable Messaging
Policy reference [<cite><a href="#WS-RM-Policy">Web Services
Reliable Messaging Policy Assertion</a></cite>] and WS-Addressing
Metadata reference [<cite><a href=
"#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>].
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331">331</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Fixed a typo in Section <a href=
"#compatible-policies"><b>3.4 Compatible Policies</b></a>. Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/349">349</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857">4857</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070806</td>
<td rowspan="1" colspan="1">FS</td>
<td rowspan="1" colspan="1">Updated references for draft
publication.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070912</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5036">5036</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">355</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070912</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4943">4943</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354">354</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070919</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented the Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">
362</a> to drop the ed-note.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070921</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated references [<cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite>] and
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>].</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070921</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071017</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5204">5204</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/370">370</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071023</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5188">5188</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/369">369</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071024</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5187">5187</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/368">368</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5226">5226</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/377">377</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5219">5219</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Applied missed changes (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5219">5219</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>)
to <a href="#policy-retrieval"><b>3.6 Policy Retrieval</b></a>.
s/(local or remote) or catalog/(local or remote), registry, or
catalog/ and s/Policy tools may use any/Policy tools or
policy-aware clients may use any/.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Applied missed changes (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5187">5187</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/368">368</a>)
to <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> and
<a href="#references"><b>C. References</b></a>. Fixed C14N 1.0
Note, SOAP 1.2, Web Services Atomic Transaction, Web Services
Business Activity Framework, Web Services Reliable Messaging Policy
Assertion, WS-SecurityPolicy and WS-Trust references.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Fixed … in <a href=
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
Expressions</b></a> (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5219">5219</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
</tbody>
</table>
<br /></div>
</div>
</body>
</html>