discontinued / server · Files

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

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



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

table          { empty-cells: show; }


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}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.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>SOAP Version 1.2 Part 2: Adjuncts (Second Edition)</h1>
<h2>W3C Recommendation 27 April 2007</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2007/REC-soap12-part2-20070427/">http://www.w3.org/TR/2007/REC-soap12-part2-20070427/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/soap12-part2/">http://www.w3.org/TR/soap12-part2/</a></dd><dt>Previous versions:</dt><dd><a href="http://www.w3.org/TR/2006/PER-soap12-part2-20061219/">http://www.w3.org/TR/2006/PER-soap12-part2-20061219/</a></dd><dt>Editors:</dt>
      <dd>Martin Gudgin, Microsoft</dd>
      <dd>Marc Hadley, Sun Microsystems</dd>
      <dd>Noah Mendelsohn, IBM</dd>
      <dd>Jean-Jacques Moreau, Canon</dd>
      <dd>Henrik Frystyk Nielsen, Microsoft</dd>
      <dd>Anish Karmarkar, Oracle</dd>
      <dd>Yves Lafon, W3C</dd>
    </dl><p>Please refer to the <a href="http://www.w3.org/2007/04/REC-soap12-part2-20070427-errata.html"><strong>errata</strong></a> for this document, which may
      include normative corrections.</p>
<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=soap12-part2">  translations</a>.</p>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <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">Abstract</a></h2>
      <p>SOAP Version 1.2 is a lightweight protocol intended for
      exchanging structured information in a decentralized, distributed
      environment. SOAP Version 1.2 Part 2: Adjuncts defines a set of adjuncts that may
      be used with SOAP Version 1.2 Part 1: Messaging Framework. This specification
      depends on SOAP Version 1.2 Part 1: Messaging Framework <a href="#SOAP-PART1">[SOAP Part 1]</a>. </p>
  	</div><div>
<h2><a name="status">Status of this Document</a></h2>

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

<p>This document is a <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C">W3C Recommendation</a>. It has been produced by the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a>, which
is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services
Activity</a>.
This second edition updates and supersedes the <a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/">original Recommendation</a> by the inclusion of the accumulated <a href="http://www.w3.org/2003/06/REC-soap12-20030624-errata.html">errata</a>.
Changes between these two versions are described in a
<a href="diff-part2.html">diff document</a>.
Additionally, it incorporates changes to the SOAP Request Response Message
Exchange pattern (MEP) to permit the SOAP envelope in the response to be
optional, to allow for one-way message interactions.</p>

<p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>

<p>Please report errors in this document to the public mailing list <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a>
(<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archive</a>).
It is inappropriate to send discussion email to this address.</p>

<p>SOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 <a href="#soap11">[SOAP 1.1]</a></p>

<p>The SOAP 1.2 Implementation Report can be found at <a href="http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html">
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html</a>.
Additional implementation experience of the Request
Optional Response MEP can be found in the WSDL 2.0 implementation testing here:
<a href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html">http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html</a>.</p>

<p> This document is governed by the <a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">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>

<p>A list of current <a href="http://www.w3.org/TR/">W3C Recommendations and
other technical reports</a> can be found at <a href="http://www.w3.org/TR">http://www.w3.org/TR</a>.</p>
    </div>
  <hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#intro">Introduction</a><br>2. <a href="#datamodel">SOAP Data Model</a><br>3. <a href="#soapenc">SOAP Encoding</a><br>4. <a href="#soapforrpc">SOAP RPC Representation</a><br>5. <a href="#soapfeatspec">A Convention for Describing Features and Bindings</a><br>6. <a href="#soapsupmep">SOAP-Supplied Message Exchange Patterns and Features</a><br>7. <a href="#soapinhttp">SOAP HTTP Binding</a><br>8. <a href="#refs">References</a><br>A. <a href="#ietf-draft">The application/soap+xml Media Type</a><br>B. <a href="#namemap">Mapping Application-Defined Names to XML Names</a><br>C. <a href="#encschema">Using W3C XML Schema with SOAP Encoding</a> (Non-Normative)<br>D. <a href="#id2279382">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#intro">Introduction</a><br>    1.1 <a href="#notcon">Notational Conventions</a><br>2. <a href="#datamodel">SOAP Data Model</a><br>    2.1 <a href="#graphedges">Graph Edges</a><br>        2.1.1 <a href="#edgelabels">Edge labels</a><br>    2.2 <a href="#graphnodes">Graph Nodes</a><br>        2.2.1 <a href="#singlemultiref">Single and Multi Reference Nodes</a><br>    2.3 <a href="#values">Values</a><br>3. <a href="#soapenc">SOAP Encoding</a><br>    3.1 <a href="#encrules">Mapping between XML and the SOAP Data Model</a><br>        3.1.1 <a href="#encodingedgesandnodes">Encoding Graph Edges and Nodes</a><br>        3.1.2 <a href="#simpleenc">Encoding Simple Values</a><br>        3.1.3 <a href="#complexenc">Encoding Compound Values</a><br>        3.1.4 <a href="#enctypename">Computing the Type Name Property</a><br>            3.1.4.1 <a href="#itemtypeattr">itemType Attribute Information Item</a><br>        3.1.5 <a href="#uniqueids">Unique identifiers</a><br>            3.1.5.1 <a href="#idattr">id Attribute Information Item</a><br>            3.1.5.2 <a href="#refattr">ref Attribute Information Item</a><br>            3.1.5.3 <a href="#uniqueidconstraints">Constraints on id and ref Attribute Information
		  Items</a><br>        3.1.6 <a href="#arraySizeattr">arraySize Attribute Information Item</a><br>        3.1.7 <a href="#nodeTypeattr">nodeType Attribute Information Item</a><br>    3.2 <a href="#encfaults">Decoding Faults</a><br>4. <a href="#soapforrpc">SOAP RPC Representation</a><br>    4.1 <a href="#RPConWeb">Use of RPC on the World Wide Web</a><br>        4.1.1 <a href="#RPCWebArguments">Identification of RPC Resources</a><br>        4.1.2 <a href="#RPCResourceRetrieval">Distinguishing Resource Retrievals from other RPCs</a><br>    4.2 <a href="#rpcsoapbdy">RPC and SOAP Body</a><br>        4.2.1 <a href="#rpcinvocation">RPC Invocation</a><br>        4.2.2 <a href="#rpcresponse">RPC Response</a><br>        4.2.3 <a href="#rpcencrestriction">SOAP Encoding Restriction</a><br>    4.3 <a href="#rpcsoaphead">RPC and SOAP Header</a><br>    4.4 <a href="#rpcfaults">RPC Faults</a><br>5. <a href="#soapfeatspec">A Convention for Describing Features and Bindings</a><br>    5.1 <a href="#modprop">Model and Properties</a><br>        5.1.1 <a href="#bindprops">Properties</a><br>        5.1.2 <a href="#bindpropsscope">Property Scope</a><br>            5.1.2.1 <a href="#soapmec">Message Exchange Context</a><br>            5.1.2.2 <a href="#soapenvc">Environment Context</a><br>        5.1.3 <a href="#bindpropfeat">Properties and Features</a><br>6. <a href="#soapsupmep">SOAP-Supplied Message Exchange Patterns and Features</a><br>    6.1 <a href="#meppropconv">Property Conventions for SOAP Message Exchange Patterns</a><br>    6.2 <a href="#singlereqrespmep">SOAP Request-Response Message Exchange Pattern</a><br>        6.2.1 <a href="#mepname">SOAP Feature Name</a><br>        6.2.2 <a href="#bindinfdesc">Description</a><br>        6.2.3 <a href="#bindformdesc">State Machine Description</a><br>        6.2.4 <a href="#bindfaulthdn">Fault Handling</a><br>    6.3 <a href="#soapresmep">SOAP Response Message Exchange Pattern</a><br>        6.3.1 <a href="#mepname2">SOAP Feature Name</a><br>        6.3.2 <a href="#bindinfdesc2">Description</a><br>        6.3.3 <a href="#bindformdesc2">State Machine Description</a><br>        6.3.4 <a href="#bindfaulthdn2">Fault Handling</a><br>    6.4 <a href="#WebMethodFeature">SOAP Web Method Feature</a><br>        6.4.1 <a href="#WebMethodFeatureName">SOAP Feature Name</a><br>        6.4.2 <a href="#WebMethodFeatureDesc">Description</a><br>        6.4.3 <a href="#webmethodstatemachine">SOAP Web Method Feature State Machine </a><br>    6.5 <a href="#ActionFeature">SOAP Action Feature</a><br>        6.5.1 <a href="#ActionFeatureName">SOAP Feature Name</a><br>        6.5.2 <a href="#ActionFeatureDesc">Description</a><br>        6.5.3 <a href="#actionstatemachine">SOAP Action Feature State Machine </a><br>7. <a href="#soapinhttp">SOAP HTTP Binding</a><br>    7.1 <a href="#http-intro">Introduction</a><br>        7.1.1 <a href="#httpoptionality">Optionality</a><br>        7.1.2 <a href="#httpuse">Use of HTTP</a><br>        7.1.3 <a href="#httpinterop">Interoperability with non-SOAP HTTP Implementations</a><br>        7.1.4 <a href="#httpmediatype">HTTP Media-Type</a><br>    7.2 <a href="#http-bindname">Binding Name</a><br>    7.3 <a href="#http-suptransmep">Supported Message Exchange Patterns</a><br>    7.4 <a href="#http-suptfeatures">Supported Features</a><br>    7.5 <a href="#http-msgexop">MEP Operation</a><br>        7.5.1 <a href="#http-reqsoapnode">Behavior of Requesting SOAP Node</a><br>            7.5.1.1 <a href="#http-reqbindreqstate">Init</a><br>            7.5.1.2 <a href="#http-reqbindwaitstate">Requesting</a><br>            7.5.1.3 <a href="#http-reqbindrecstate">Sending+Receiving</a><br>            7.5.1.4 <a href="#http-reqbindrecstate2">Receiving</a><br>            7.5.1.5 <a href="#http-reqsuccfail">Success and Fail</a><br>        7.5.2 <a href="#http-bindrespnode">Behavior of Responding SOAP Node</a><br>            7.5.2.1 <a href="#http-respbindreceive">Init</a><br>            7.5.2.2 <a href="#http-respbindprocess">Receiving</a><br>            7.5.2.3 <a href="#http-respbindrespond">Receiving+Sending</a><br>            7.5.2.4 <a href="#http-respbindrespond2">Sending</a><br>            7.5.2.5 <a href="#http-respsuccfail">Success and Fail</a><br>    7.6 <a href="#seccond">Security Considerations</a><br>8. <a href="#refs">References</a><br>    8.1 <a href="#refs-norm">Normative References</a><br>    8.2 <a href="#refs-inform">Informative References</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#ietf-draft">The application/soap+xml Media Type</a><br>B. <a href="#namemap">Mapping Application-Defined Names to XML Names</a><br>    B.1 <a href="#namemap-rules">Rules for Mapping Application-Defined Names to XML Names</a><br>    B.2 <a href="#namemap-ex">Examples</a><br>C. <a href="#encschema">Using W3C XML Schema with SOAP Encoding</a> (Non-Normative)<br>    C.1 <a href="#validmin">Validating Using the Minimum Schema</a><br>    C.2 <a href="#validenc">Validating Using the SOAP Encoding Schema</a><br>    C.3 <a href="#validschema">Validating Using More Specific Schemas</a><br>D. <a href="#id2279382">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">


    <div class="div1">
      
<h2><a name="intro"></a>1. Introduction</h2>

      <p>SOAP Version 1.2 (SOAP) is a lightweight protocol intended
	for exchange of structured information in a
	decentralized, distributed environment. The SOAP specification
	consists of three parts. Part 2 (this document)
	defines a set of adjuncts that MAY be used with the SOAP
	messaging framework:</p>
      
      <ol>
	<li>
	  <p>The SOAP Data Model represents application-defined data structures and values
            as a directed, edge-labeled graph of nodes (see <a href="#datamodel"><b>2. SOAP Data Model</b></a>).</p>
	</li>
	<li>
	  <p>The SOAP Encoding defines a set of rules for encoding
            instances of data that conform to the SOAP Data Model for
            inclusion in SOAP messages (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>).</p>
	</li>
	<li>
	  <p>The SOAP RPC Representation defines a convention for how
	    to use the SOAP Data Model for representing RPC calls and
	    responses (see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>).</p>
	</li>
	<li>
	  <p>The section for describing features and bindings defines
	    a convention for describing features and binding in terms
	    of properties and property values (see <a href="#soapfeatspec"><b>5. A Convention for Describing Features and Bindings</b></a>).</p>
	</li>
				<li>
					<p>The section on SOAP-Supplied Message Exchange
					Patterns and Features defines a request response
					message exchange pattern and a message exchange
					pattern supporting non-SOAP requests for SOAP
					responses, (see <a href="#soapsupmep"><b>6. SOAP-Supplied Message Exchange Patterns and Features</b></a>).</p>
				</li>
                <li>
					<p>The SOAP Web Method feature defines a feature for
					control of methods used on the World Wide Web (see
					<a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>).</p>
				</li>
				<li>
					<p>The SOAP HTTP Binding defines a binding of SOAP
					to HTTP (see <a href="#RFC2616">[RFC 2616]</a>) following the
					rules of the <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol
					Binding Framework</a>, <a href="#SOAP-PART1">[SOAP Part 1]</a> (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>).</p>
				</li>
			</ol>
   <p>SOAP 1.2 Part 0 <a href="#SOAP-PART0">[SOAP Part 0]</a> is a non-normative document intended to
provide an easily understandable tutorial on the features of the SOAP Version
1.2 specifications.</p> 
   <p>SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> defines the SOAP messaging
framework.</p> 
			<div class="note"><p class="prefix"><b>Note:</b></p>
				<p>In previous versions of this specification the SOAP
	  name was an acronym. This is no longer the case.</p>
      </div>
	
        <div class="div2">
	
<h3><a name="notcon"></a>1.1 Notational Conventions</h3>

        <p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in RFC 2119 <a href="#RFC2119">[RFC 2119]</a>.</p>
	  
	  <p>This specification uses a number of namespace prefixes throughout; they
	  are listed in <a href="#tabprefns"><b>Table 1</b></a>. Note that the choice of any namespace
	  prefix is arbitrary and not semantically significant (see XML Infoset <a href="#XMLInfoSet">[XML InfoSet]</a>).</p>
  
        <a name="tabprefns"></a><table border="1">
          <caption>Table 1: Prefixes and Namespaces used in this specification</caption>
          <tbody>
          <tr>
            <th rowspan="1" colspan="1">Prefix</th>
            <th rowspan="1" colspan="1">Namespace</th>
            <th rowspan="1" colspan="1">Notes</th>
          </tr>
          <tr>
            <td rowspan="1" colspan="1">env</td>
            <td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-envelope"</td>
            <td rowspan="1" colspan="1">Defined by SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>.</td>
          </tr>
          <tr>
            <td rowspan="1" colspan="1">enc</td>
            <td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-encoding"</td>
            <td rowspan="1" colspan="1">A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>,
            <a href="#XMLSchemaP2">[XML Schema Part 2]</a> document for the
            "http://www.w3.org/2003/05/soap-encoding"
            namespace can be found at <a href="http://www.w3.org/2003/05/soap-encoding">http://www.w3.org/2003/05/soap-encoding</a>.</td>
          </tr>
          <tr>
            <td rowspan="1" colspan="1">rpc</td>
            <td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-rpc"</td>
            <td rowspan="1" colspan="1">A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>,
            <a href="#XMLSchemaP2">[XML Schema Part 2]</a> document for the
            "http://www.w3.org/2003/05/soap-rpc"
            namespace can be found at <a href="http://www.w3.org/2003/05/soap-rpc">http://www.w3.org/2003/05/soap-rpc</a>.</td>
          </tr>
          <tr>
            <td rowspan="1" colspan="1">xs</td>
            <td rowspan="1" colspan="1">"http://www.w3.org/2001/XMLSchema"</td>
            <td rowspan="1" colspan="1">Defined in the W3C XML Schema
          specification <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2]</a>.</td>
          </tr>
          <tr>
            <td rowspan="1" colspan="1">xsi</td>
            <td rowspan="1" colspan="1">"http://www.w3.org/2001/XMLSchema-instance"</td>
            <td rowspan="1" colspan="1">Defined in the W3C XML Schema
          specification <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2]</a>.</td>
          </tr>
          </tbody>
        </table>

        <p>Namespace names of the general form "http://example.org/..."
          and "http://example.com/..." represent
          application or context-dependent URIs (see RFC 3986 <a href="#RFC3986">[RFC 3986]</a>).</p>

        <p>This specification uses the Extended Backus-Naur Form
          (EBNF) as described in XML 1.0 <a href="#XML">[XML 1.0]</a>.</p>

    	<p>With the exception of examples and sections explicitly marked
    	as "Non-Normative", all parts of this specification are
    	normative.</p>
      
      </div>
    </div>

    <div class="div1">
      
<h2><a name="datamodel"></a>2. SOAP Data Model</h2>
      
      <p>The SOAP Data Model represents application-defined data
      structures and values as a directed edge-labeled graph of nodes.
      Components of this graph are described in the following
      sections.</p>

      <p>
	  The purpose of the SOAP Data Model is to provide a mapping
	  of non-XML based data to some wire representation. It is important
	  to note that use of the SOAP Data Model, the accompanying SOAP
	  Encoding (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>), and/or the SOAP RPC
	  Representation (see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>) is
	  OPTIONAL. Applications which already model data in XML may not need to use the SOAP
	  Data Model. Due to their optional nature, it is NOT a
	  requirement to implement the SOAP Data Model, the SOAP
	  Encoding and/or the SOAP RPC Representation as part of a
	  SOAP node.
      </p>

	  <div class="div2">
	    
<h3><a name="graphedges"></a>2.1 Graph Edges</h3>
	    <p>
	    Edges in the graph are said to <em>originate</em> at a
	    graph node
	    and <em>terminate</em> at a graph node. An edge that
	    originates at a graph
	    node is known as an <em>outbound edge</em> with respect to that
	    graph node. An edge that terminates at a graph node is known as an <em>inbound
	    edge</em> with respect to that graph node. An edge MAY originate and
	    terminate at the same graph node. An edge MAY
	    have only an originating graph node, that is be outbound only. An edge MAY have only a
	    terminating graph node, that is be inbound only.</p>
        
        <p>The outbound edges of a given graph node MAY be
	    distinguished by label or by position. Position 
	    is a total order on such edges; thus, if any
	    outbound edges from a given node are distinguished by
	    position, then all outbound edges from that node are so distinguished.</p>
	    
	    <div class="div3">
	    
<h4><a name="edgelabels"></a>2.1.1 Edge labels</h4>

	    <p>An edge label is an XML qualified name. Two edge
	    labels are equal if and only if their XML expanded names are
	    equal. I.e., both of the following are true:</p>

	    <ol>
	      <li>
		    <p>
		    Their local name values are the same.
		    </p>
		  </li>
	      <li>
		    <p>
		    Either of the following is true:</p>
		    <ol>
		      <li>
			    <p>
			    Both of their namespace name values are missing.
			    </p>
			  </li>
			  <li>
			    <p>
			    Their namespace name values are both present and are
			    both the same.
			    </p>
			  </li>
	        </ol>
		  </li>
	    </ol>

		<p>See <a href="#values"><b>2.3 Values</b></a> for uses of edge labels and position
	    to distinguish the members of encoded values, and 
	    XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a> for more
	    information about comparing XML qualified names.
	    </p>
		</div>
      </div>

	  <div class="div2">
	    
<h3><a name="graphnodes"></a>2.2 Graph Nodes</h3>

	    <p>A graph node has zero or more outbound edges. A graph node that has no
	    outbound edges has an optional lexical value. All graph nodes have an
	    optional type name of type <em>xs:QName</em> in the namespace named
	    "http://www.w3.org/2001/XMLSchema" (see 
	    XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a>).</p>
	
	    <div class="div3">
		  
<h4><a name="singlemultiref"></a>2.2.1 Single and Multi Reference Nodes</h4>
	      <p>
	      A graph node may be <em>single reference</em> or
	      <em>multi reference</em>. A 
	      single reference graph node has a single inbound edge. A multi
	      reference graph node has multiple inbound edges.
	      </p> 
		</div>
      </div>
	  <div class="div2">
	    
<h3><a name="values"></a>2.3 Values</h3>

	    <p>A simple value is represented as a graph node with a lexical value.
	    </p>

	    <p>A compound value is represented as a graph node with zero or more
	    outbound edges as follows:
	    </p>

   	    <ol>
   	      <li>
   	    	<p>
   	    	A graph node whose outbound edges are distinguished solely
   	    	by their labels is known as a "struct". The outbound edges
   	    	of a struct MUST be labeled with distinct names (see
   	    	<a href="#edgelabels"><b>2.1.1 Edge labels</b></a>).
   	    	</p>
   	    	</li>
   	    	<li>
   	    	<p>
   	    	A graph node whose outbound edges are distinguished solely
   	    	by position is known as an "array". The outbound edges of
   	    	an array MUST NOT be labeled.
   	    	</p>
   	    	</li>
   	    </ol>
		
  	  </div>
	</div> 

    <div class="div1">
      
<h2><a name="soapenc"></a>3. SOAP Encoding</h2>
      
      <p>
	  SOAP Encoding provides a means of encoding instances of data
	  that conform to the data model described in <a href="#datamodel"><b>2. SOAP Data Model</b></a>. This encoding
	  MAY be used to transmit data in SOAP header blocks and/or SOAP
	  bodies. Other data models, alternate encodings of the SOAP
	  Data Model as well as unencoded data MAY also be used in SOAP
	  messages (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>,
	  <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP
	  encodingStyle Attribute</a> for specification of alternative
	  encoding styles and see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>  for
	  restrictions on data models and encodings used to represent SOAP 
	  Remote Procedure Calls (RPC)).
	  </p>

      <p>The serialization rules defined in this section are
      identified by the URI
      "http://www.w3.org/2003/05/soap-encoding". SOAP
      messages using this particular serialization SHOULD indicate
      that fact by using the SOAP <code>encodingStyle</code>  attribute
      information item (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
      <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP
      encodingStyle Attribute</a>).
	  </p>

      <div class="div2">
        
<h3><a name="encrules"></a>3.1 Mapping between XML and the SOAP Data Model</h3>

        <p>
		XML allows very flexible encoding of data. SOAP Encoding
        defines a narrower set of rules for encoding the graphs
        described in <a href="#datamodel"><b>2. SOAP Data Model</b></a>. This section
        defines the encoding at a high level, and the subsequent
        sub-sections describe the encoding rules in more detail. The
        encodings described in this 
        section can be used in conjunction with the mapping of RPC
        requests and responses specified in <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>.
		</p>

		<p>
		The encodings are described below from the perspective of a
		de-serializer. In each case, the presence of an XML
		serialization is presumed, and the mapping to a corresponding
		graph is described.
		</p>

		<p>
		More than one encoding is typically possible
		for a given graph. When serializing a graph for transmission
		inside a SOAP message,
		a representation that deserializes to the identical graph MUST
		be used; when multiple such representations are possible, any
		of them MAY be used. When receiving an encoded SOAP message,
		all representations MUST be accepted.
		</p>
		
		<div class="div3">
		  
<h4><a name="encodingedgesandnodes"></a>3.1.1 Encoding Graph Edges and Nodes</h4>

		  <p>
		  Each graph edge is encoded as an <em>element information
		  item</em> and each <em>element information item</em>
		  represents a graph edge. <a href="#complexenc"><b>3.1.3 Encoding Compound Values</b></a>
		  describes the relationship between edge labels and the [local name] and
		  [namespace name] properties of such <em>element 
		  information items</em>.
		  </p>

		  <p>The graph node at which an edge terminates is
		  determined by examination of the serialized XML as follows:</p>
		  <ol>
		    <li>
		      <p>
			  If the <em>element information item</em> representing
			  the edge does not have a <code>ref</code>  <em>attribute
			  information item</em> (see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>)
			  among its attributes then that <em>element information
			  item</em> is said to <em>represent</em> a node in
			  the graph and the edge terminates at that node.
			  In such cases the <em>element
			  information item</em> represents both a graph edge
			  and a graph node</p>
		    </li>
		    <li>
		      <p>
			  If the <em>element information item</em> representing
			  the edge does have a <code>ref</code>  <em>attribute
			  information item</em> (see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>) among its attributes,
			  then the value of that <em>attribute information
			  item</em> MUST be identical to the value of exactly one
			  <code>id</code>  <em>attribute information item</em> (
			  see <a href="#idattr"><b>3.1.5.1 id Attribute Information Item</b></a>) in the same envelope. 
			  In this case the edge terminates at the graph node
			  represented by the <em>element information item</em>
			  on which the <code>id</code>  <em>attribute information
			  item</em> appears. That <em>element information
			  item</em> MUST be in the scope of an
			  <code>encodingStyle</code>  attribute with a value of
			  "http://www.w3.org/2003/05/soap-encoding"
                          (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>,
                          <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP encodingStyle
                          Attribute</a>).
			  </p>
		    </li>
		  </ol>

		  <p>
		  All nodes in the graph are encoded as described in 1
		  above. Additional inbound edges for multi reference graph nodes
		  are encoded as described in 2 above.
		  </p>
		</div>

		<div class="div3">
		  
<h4><a name="simpleenc"></a>3.1.2 Encoding Simple Values</h4>
		  <p>
		  The lexical
		  value of a graph node representing a simple value is the sequence of
		  Unicode characters identified by the <em>character
		  information item</em> children of the <em>element
		  information item</em> representing that node.
		  The <em>element information item</em> representing a simple value node MAY have
		  among its attributes a 'nodeType' <em>attribute information item</em> (see <a href="#nodeTypeattr"><b>3.1.7 nodeType Attribute Information Item</b></a>).
		  Note that
		  certain Unicode characters cannot be represented in XML (see XML 1.0 <a href="#XML">[XML 1.0]</a>).
		  </p>
		</div>

		<div class="div3">
		  
<h4><a name="complexenc"></a>3.1.3 Encoding Compound Values</h4>
		  <p>
		  An outbound edge of a graph node is encoded as an
		  <em>element information item</em> child of the
		  <em>element information item</em> that represents the
		  node (see <a href="#encodingedgesandnodes"><b>3.1.1 Encoding Graph Edges and Nodes</b></a>).
		  Particular rules apply depending on what kind of compound
		  value the graph node represents. These rules are as follows:</p>

		  <ol>
		    <li>
		      <p>For a graph edge which is distinguished by label, the [local name] and
			  [namespace name] properties of the child
			  <em>element information item</em>
			  together determine the value of the edge
			  label. 
			  </p>
			</li>
			<li>
			  <p>
			  For a graph edge which is distinguished by position:</p>
	
			  <ul>
			    <li>
				  <p>
				  The ordinal position of the graph edge corresponds
				  to the position of the child <em>element information
				  item</em> relative to its siblings
				  </p>
				</li>
			    <li>
				  <p>The [local name] and [namespace name]
				  properties of the child <em>element information
				  item</em> are not significant.
				  </p>
				</li>
			  </ul>
			</li>
			<li>
			  <p>The element information item representing a compound
			  value node MAY have among its attributes a
			  <code>nodeType</code>  <em>attribute information
			  item</em> (see <a href="#nodeTypeattr"><b>3.1.7 nodeType Attribute Information Item</b></a>).
			  </p>
			</li>
			<li>
			  <p>The following rules apply to the encoding of a graph node that
			  represents an "array":</p>
			  <ul>
			    <li>
				  <p>
				  The <em>element information item</em>
				  representing an array node MAY have among its
				  attributes an <code>itemType</code>  <em>attribute
				  information item</em> (see <a href="#itemtypeattr"><b>3.1.4.1 itemType Attribute Information Item</b></a>). 
				  </p>
				</li>
			    <li>
				  <p>
				  The <em>element information item</em>
				  representing an array node MAY have among its
				  attributes an <code>arraySize</code>  <em>attribute
				  information item</em> (see <a href="#arraySizeattr"><b>3.1.6 arraySize Attribute Information Item</b></a>). 
				  </p>
				</li>
			  </ul>
			</li>
			<li>
			  <p>
			   If a graph edge does not terminate in a graph node then
			   it can either be omitted from the serialization or it can be
			   encoded as an <em>element information item</em>
			   with an <em>xsi:nil</em> <em>attribute
			   information item</em> whose value is "true".
			  </p>
			</li>
		  </ol>
	  </div>

	  <div class="div3">
	    
<h4><a name="enctypename"></a>3.1.4 Computing the Type Name Property</h4>
		<p>
		The type name property of a graph node is a {namespace name,
		local name} pair computed as follows:</p>

		<ol>
		<li>
		<p>
		If the <em>element information item</em> representing the
		graph node has an <code>xsi:type</code>  <em>attribute
		information item</em> 
		among its attributes then the type name property of the
		graph node is the value of the <code>xsi:type</code>  <em>attribute
		information item</em>.</p>
		<div class="note"><p class="prefix"><b>Note:</b></p>
		<p>
		This attribute is of type <em>xs:QName</em> (see 
		XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a>); its value consists of the 
		pair {namespace name, local name}. Neither the prefix used to
		construct the QName nor any information relating to any
		definition of the type is considered to be part of the
		value. The SOAP graph carries only the qualified name of the
		type.
		</p>
		</div>
		</li>
		<li>
		<p>
		Otherwise if the parent <em>element information item</em> of the
		<em>element information item</em> representing the graph
		node has an <code>enc:itemType</code>  <em>attribute
		information item</em> (see <a href="#itemtypeattr"><b>3.1.4.1 itemType Attribute Information Item</b></a>)
		among its attributes then the type
		name property of the graph node is the value of the
		<code>enc:itemType</code>  <em>attribute information item</em>
		</p>
		</li>
		<li>
		<p>
		Otherwise the value of the type name property of the graph
		node is unspecified.
		</p>
		</li>
		</ol>

		<div class="note"><p class="prefix"><b>Note:</b></p>
		<p>
		These rules define how the type name property
		of a graph node in
		a graph is computed from a serialized encoding. This
		specification does not mandate validation using any particular
		schema language or type system. Nor does it include built in types or
		provide any standardized faults to reflect value/type
		name conflicts.
		</p>
		<p>
		However, nothing prohibits development of
		additional specifications to describe the use of SOAP Encoding with
		particular schema languages or type systems. Such additional
		specifications MAY mandate validation using particular
		schema language, and MAY specify faults to be generated if
		validation fails. Such additional specifications MAY specify
		augmentations to the deserialized graph based on information
		determined from such a validation. The use by SOAP Encoding of xsi:type
		is intended to facilitate integration with the W3C XML Schema
		language (see <a href="#encschema"><b>C. Using W3C XML Schema with SOAP Encoding</b></a>). Other XML based
		schema languages, data schemas and programmatic type systems
		MAY be used but only to the extent that they are compatible
		with the serialization described in this specification.
		</p>		
		</div>

	    <div class="div4">
	     
<h5><a name="itemtypeattr"></a>3.1.4.1 itemType Attribute Information Item</h5>
         <p>
		 The <code>itemType</code>  <em>attribute information item</em> has
		 the following Infoset properties:
		 </p> 
	 <ul>

	        <li>
			  <p>
			  A [local name] of <code>itemType</code> .
			  </p>
			</li>

            <li>
			  <p>
			  A [namespace name] of "http://www.w3.org/2003/05/soap-encoding". 
			  </p>
			</li>

            <li>
			  <p>
			  A [specified] property with a value of "true".
			  </p>
			</li>

		  </ul> 
	      <p>
		  The type of the <code>itemType</code>  <em>attribute
          information item</em> is <em>xs:QName</em>.
          The value of the <code>itemType</code>  <em>attribute 
          information item</em> is used to compute the type name
          property (see <a href="#enctypename"><b>3.1.4 Computing the Type Name Property</b></a>) of members of
          an array.
		  </p>

		</div>

	   </div>

	  <div class="div3">
	    
<h4><a name="uniqueids"></a>3.1.5 Unique identifiers</h4>
		
	    <div class="div4">
	     
<h5><a name="idattr"></a>3.1.5.1 id Attribute Information Item</h5>
         <p>
		 The <code>id</code>  <em>attribute information item</em> has
		 the following Infoset properties:
		 </p> 
		 <ul>

	        <li>
			  <p>A [local name] of <code>id</code> .</p>
			</li>

            <li>
			  <p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".</p>
			</li>

            <li>
			  <p>A [specified] property with a value of
			  "true".</p>
			</li>

		  </ul> 
	      <p>
		  The type of the <code>id</code>  <em>attribute
          information item</em> is <em>xs:ID</em>.
          The value of the <code>id</code>  <em>attribute information
          item</em> is a unique identifier that can be referred to by
          a <code>ref</code>  <em>attribute information item</em>
          (see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>).
		  </p>
		 </div>

	     <div class="div4">
	      
<h5><a name="refattr"></a>3.1.5.2 ref Attribute Information Item</h5>
          <p>
		  The <code>ref</code>  <em>attribute information item</em> has
		  the following Infoset properties:
		  </p> 
		  <ul>

	        <li>
			  <p>A [local name] of <code>ref</code> .</p>
			</li>

            <li>
			  <p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".</p>
			</li>

            <li>
              <p>A [specified] property with a value of
              "true".</p>
			</li>
 
		   </ul> 
	       <p>
		   The type of the <code>ref</code>  <em>attribute information
		   item</em> is <em>xs:IDREF</em>.
		   The value of the <code>ref</code>  <em>attribute information
		   item</em> is a reference to a unique identifier defined
		   by an <code>id</code>  <em>attribute information item</em>
		   (see <a href="#idattr"><b>3.1.5.1 id Attribute Information Item</b></a>).
		   </p>

		</div>
		<div class="div4">
		  
<h5><a name="uniqueidconstraints"></a>3.1.5.3 Constraints on id and ref Attribute Information
		  Items</h5>
		  <p>
		  The value of a <code>ref</code>  <em>attribute information item</em> MUST also be
		  the value of exactly one <code>id</code>  <em>attribute information item</em>.
		  </p>
		  <p>
		  A <code>ref</code>  <em>attribute information item</em> and
		  an <code>id</code>  <em>attribute information item</em>
		  MUST NOT appear on the same <em>element information item</em>.
		  </p>
		</div>
	  </div>



	   <div class="div3">
	     
<h4><a name="arraySizeattr"></a>3.1.6 arraySize Attribute Information Item</h4>
         <p>
		 The <code>arraySize</code>  <em>attribute information item</em> has
		 the following Infoset properties:
		 </p> 
		 <ul>

	        <li>
			  <p>
			  A [local name] of <code>arraySize</code> .
			  </p>
			</li>

            <li>
			  <p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding". 
              </p>
			</li>			
		  </ul> 
		  
	      <p>
		  The type of the <code>arraySize</code>  <em>attribute
          information item</em> is <em>enc:arraySize</em>.
          The value of the <code>arraySize</code>  <em>attribute information item</em>
          MUST conform to the following EBNF grammar</p>

		  
<h5></h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="arraysizedefn"></a>[1]   </td><td><code>arraySizeValue</code></td><td>   ::=   </td><td><code>("*" | concreteSize) nextConcreteSize*</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="nextconcretesize"></a>[2]   </td><td><code>nextConcreteSize</code></td><td>   ::=   </td><td><code>whitespace concreteSize</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="concretesize"></a>[3]   </td><td><code>concreteSize</code></td><td>   ::=   </td><td><code>[0-9]+</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="whitespace"></a>[4]   </td><td><code>white space</code></td><td>   ::=   </td><td><code>(#x20 | #x9 | #xD | #xA)+</code></td></tr></tbody></table>
		  <p>
		      The arraySize attribute conveys a suggested mapping of a SOAP array to a
multi-dimensional program data structure.  The cardinality of the arraySize
list represents the number of dimensions, with individual values providing
the extents of the respective dimensions.  When SOAP encoding
multidimensional arrays, nodes are selected such that the last subscript
(i.e., the subscript corresponding to the last specified dimension) varies
most rapidly, and so on with the first varying most slowly.    An asterisk
MAY be used only in place of the first size to indicate a dimension of
unspecified extent;  asterisks MUST NOT appear in other positions in the
list.  The default value of the <code>arraySize</code>  <em>attribute information item</em> is
"*", i.e., a single dimension of unspecified extent.
</p>

		</div>
	   <div class="div3">
	     
<h4><a name="nodeTypeattr"></a>3.1.7 nodeType Attribute Information Item</h4>
         <p>
		 The <code>nodeType</code>  <em>attribute information item</em> has
		 the following Infoset properties:
		 </p> 
		 <ul>

	        <li>
			  <p>
			  A [local name] of <code>nodeType</code> .
			  </p>
			</li>

            <li>
			  <p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding". 
              </p>
			</li>
            <li>
			  <p>A [specified] property with a value of
			  "true".</p>
			</li>
			
		  </ul> 
	      <p>
		  The type of the <code>nodeType</code>  <em>attribute
          information item</em> is <em>enc:nodeType</em>.</p>

             
            <p>
	    The value of the <code>nodeType</code>  <em>attribute information item</em>
            MUST, if present, be one of the strings "simple" or "struct" or "array". The value
	    indicates what kind of a value this node represents - a simple value, a 
	    compound struct value or a compound array value respectively.
	    </p>


	</div>

      </div>

      <div class="div2">
        
<h3><a name="encfaults"></a>3.2 Decoding Faults</h3>

		<p>
		During deserialization a SOAP receiver:
 	    </p>

        <ul>

		  <li>
		    <p>
			SHOULD generate an "env:Sender" SOAP
            fault with a subcode of <code>enc:MissingID</code>
			if the message contains a <code>ref</code>  <em>attribute
            information item</em> but no corresponding <code>id</code> 
            <em>attribute information item</em> (see <a href="#uniqueidconstraints"><b>3.1.5.3 Constraints on id and ref Attribute Information
		  Items</b></a>).
			</p>
		  </li>

		  <li>
		    <p>
			SHOULD generate an "env:Sender" SOAP
            fault with a subcode of <code>enc:DuplicateID</code>
			if the message contains two or more <code>id</code>  <em>attribute
            information item</em> that have the same value. (see <a href="#uniqueidconstraints"><b>3.1.5.3 Constraints on id and ref Attribute Information
		  Items</b></a>).
			</p>
		  </li>

	      <li>
		    <p>
			MAY generate an "env:Sender" SOAP fault with a
			subcode of <code>enc:UntypedValue</code> if the type name
			property of an encoded graph node is unspecified.
			</p>
	      </li>

        </ul>
     </div>

    </div>


    <div class="div1">
      
<h2><a name="soapforrpc"></a>4. SOAP RPC Representation</h2>
      
      <p>One of the design goals of SOAP is to facilitate
	the exchange of messages that map conveniently to definitions
	and invocations of methods and procedures in commonly used
	programming languages. For that purpose, this section defines
	a uniform representation of remote procedure call (RPC) requests and responses. It
	does not define actual mappings to any particular programming
	language. The representation is entirely platform-independent
	and considerable effort has been made to encourage usage that
	is consistent with the Web in general.</p>

      <p>As mentioned in section <a href="#datamodel"><b>2. SOAP Data Model</b></a>, use and
	implementation of the SOAP RPC Representation is OPTIONAL.</p>

      <p> The SOAP <code>encodingStyle</code>  attribute information item (see
      SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP encodingStyle
      Attribute</a>) is used to indicate the encoding style of
      the RPC representation. The encoding thus specified MUST support the <a href="#datamodel"><b>2. SOAP Data Model</b></a>. The encoding style defined in <a href="#soapenc"><b>3. SOAP Encoding</b></a> supports such constructs and is therefore
      suitable for use with the SOAP RPC Representation. </p>

      <p>
      This SOAP RPC Representation is not predicated on any SOAP
      protocol binding. When SOAP is bound to HTTP, an RPC invocation
      maps naturally to an HTTP request and an RPC response maps to an
      HTTP response. (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>). However, the
      SOAP RPC Representation is not limited to the SOAP HTTP Binding.
      </p>

      <p>To invoke an RPC, the following information is needed:</p>

      <ul>
        <li><p>The address of the target SOAP node.</p></li>

        <li><p>A procedure or method name.</p></li>

        <li>
					<p>The identities
        and values of any arguments to be passed to the procedure or method. Arguments used to
identify Web resources SHOULD be distinguished from those representing data or control information (see
<a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a>.)</p>
</li>
                                <li>
                                     <p>Values for properties as required by any features of the 
binding to be used. For example, "GET" or "POST"
for the <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  property of the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>.</p>
                                </li>

        <li><p>Optional header data.</p></li>

      </ul>

      <p>SOAP RPC relies on the protocol binding to provide a mechanism
      for carrying the URI of the target SOAP node. For HTTP the request URI
      indicates the resource against which the invocation is being
      made. Other than requiring it to be a valid URI, SOAP places no
      restriction on the form of an identifier (see RFC 3986 <a href="#RFC3986">[RFC 3986]</a>
      for more information on URIs). The section <a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a> further discusses the use
of URIs for identifying RPC resources.</p>
<p>The SOAP RPC Representation employs the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>. Use of the SOAP RPC Representation with other MEPs MAY be possible, but is beyond the
scope of this specification.</p>



			<div class="div2">
                              
<h3><a name="RPConWeb"></a>4.1 Use of RPC on the World Wide Web</h3>
                              <p> 
The following guidelines SHOULD be followed when deploying 
SOAP RPC applications 
on the World Wide Web.</p>
                            
<div class="div3">

<h4><a name="RPCWebArguments"></a>4.1.1 Identification of RPC Resources</h4>
<p>The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to 
procedures, or in the names of those procedures. For example, the call:</p>
<p><code>
updateQuantityInStock(PartNumber="123", NewQuantity="200")
</code></p>
<p>suggests that the resource to be
updated is the <code>QuantityInStock</code>  for <code>PartNumber</code>  "123".
Accordingly, when mapping to
or from a programming language method or procedure, any arguments that serve to identify resources
(such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed. 
When mapping to or from a programming language method or procedure, the name of which
identifies or qualifies the identification of a resource (such as QuantityInStock above), such naming or
qualification should when practical be represented in the URI to which the SOAP message is addressed.
No standard means of representation of arguments or method names is provided by this specification.</p>

<div class="note"><p class="prefix"><b>Note:</b></p>
<p>Conventions for specific URI encodings of procedure
names and arguments, as well as for controlling the
inclusion of such arguments in the SOAP RPC body could be established in conjunction with the development
of Web Service interface description languages. They could be developed when SOAP is bound to particular
programming languages or could be established on an application- or
procedure-specific basis.</p>
</div>

</div>

<div class="div3">

<h4><a name="RPCResourceRetrieval"></a>4.1.2 Distinguishing Resource Retrievals from other RPCs</h4>
<p>
The World Wide Web depends on mechanisms that optimize commonly performed information retrieval
tasks. Specifically, protocols such as HTTP <a href="#RFC2616">[RFC 2616]</a> provide a GET method which is 
used to perform safe
retrievals, i.e., to perform retrievals that are idempotent, free of side effects, and for which security considerations  do not
preclude the use of cached results or URI-based resource identification.</p>
<p>
Certain procedure or method calls represent requests for information retrieval. For example, the call:</p>
   <p><code>getQuantityInStock(PartNumber="123")</code></p>
<p>might be used to retrieve the quantity established in
the example above.</p>

<p>The following conventions can be employed to implement SOAP retrievals and other
RPCs on the Web:
</p>
<ul>
<li>
<p>
The conventions described in <a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a> are used to identify the
resource with a URI.
</p>
</li>
<li>
<p>In cases where all the arguments have been represented in the URI,
no SOAP header blocks are to be transmitted and the operation is a safe
retrieval, the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a> and the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> are used. Accordingly, no SOAP envelope is
transmitted for the request, and the
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> 
property is set to "GET". The results of the retrieval
are a SOAP RPC response as described in <a href="#rpcresponse"><b>4.2.2 RPC Response</b></a></p>
</li>
<li>
<p>
In cases where the operation to be performed is not a retrieval, when
SOAP header  blocks are to be transmitted (a digital signature, for example),
or when a retrieval is not safe, the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a> and the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> are used. The
request envelope is encoded as described in <a href="#rpcinvocation"><b>4.2.1 RPC Invocation</b></a>, and the results are as described in <a href="#rpcresponse"><b>4.2.2 RPC Response</b></a>. The <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  property is
set to "POST".</p>
</li></ul>

<p>The SOAP RPC Representation does not define any other value for the
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> .</p>

</div>

</div>

<div class="div2">
	
<h3><a name="rpcsoapbdy"></a>4.2 RPC and SOAP Body</h3>

    <p>RPC invocations (except for safe retrievals: see <a href="#RPCResourceRetrieval"><b>4.1.2 Distinguishing Resource Retrievals from other RPCs</b></a>) and responses are both carried in the
    SOAP <code>Body</code>  element (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapbody">SOAP Body</a>) using the
    following representation:</p>

    <div class="div3">
        
<h4><a name="rpcinvocation"></a>4.2.1 RPC Invocation</h4>
        
        <p>An RPC invocation is modeled as follows:</p>
          
        <ul>
          <li><p>The invocation is represented by a single
          struct containing an outbound edge for each [in] or [in/out]
          parameter. The struct is named identically to the procedure or
          method and the conventions of <a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a>
          SHOULD be used to represent method names that are not legal
          XML names.</p></li>

          <li><p>Each outbound edge has a label
          corresponding to the name of the parameter. The conventions of
          <a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a> SHOULD be used to represent parameter
          names that are not legal XML names.</p></li>

        </ul>

        <p>Applications MAY process invocations with missing
        parameters but also MAY fail to process the invocation and return a fault.</p>
        
        </div>
        
        
        <div class="div3">
        
<h4><a name="rpcresponse"></a>4.2.2 RPC Response</h4>
        
        <p>An RPC response is modeled as follows:</p>

        <ul>
          <li><p>The response is represented by a single struct
          containing an outbound edge for the return value and each [out]
          or [in/out] parameter. The name of the struct is not significant.</p></li>

		  <li><p>Each parameter is represented by an outbound edge
		  with a label corresponding to the name of the parameter. The conventions of
          <a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a> SHOULD be used to represent parameter
          names that are not legal XML names.</p></li>

		  <li><p>
		  A non-void return value is represented as follows:</p>

		  <ol>
		    <li>
			  <p>There MUST be an outbound edge with a local name of <code>result</code>  and a namespace
		  name of "http://www.w3.org/2003/05/soap-rpc"
		  which terminates in a terminal node</p>
			</li>
			<li>
			<p>
			The type of that terminal node is a xs:QName and its value
			is the name of the outbound edge which terminates in the
			actual return value. 
			</p>
			</li>
		  </ol>

		  <p>If the return value of the procedure is void
		  then an outbound edge with a local name of <code>result</code>  and a namespace
		  name of "http://www.w3.org/2003/05/soap-rpc"
		  MUST NOT be present.</p>
		  </li>


          <li><p>Invocation faults are handled according to the
          rules in <a href="#rpcfaults"><b>4.4 RPC Faults</b></a>. If a protocol binding
          adds additional rules for fault expression, those MUST also
          be followed.</p></li>
        </ul>

        
        </div>
        
        <div class="div3">
        
            
<h4><a name="rpcencrestriction"></a>4.2.3 SOAP Encoding Restriction</h4>
            
            <p>When using SOAP encoding (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>) in
            conjunction with the RPC convention described here, the SOAP
            <code>Body</code>  MUST contain only a single child <em>element
            information item</em>, that child being the serialized RPC
            invocation or response struct.</p>
                        
        </div>

      </div>

      <div class="div2">
	
<h3><a name="rpcsoaphead"></a>4.3 RPC and SOAP Header</h3>
        
        <p>Additional information relevant to the encoding of an RPC
        invocation but not part of the formal procedure or method
        signature MAY be expressed in a SOAP envelope carrying an RPC invocation or response.
        Such additional information MUST be expressed as SOAP header blocks.</p>
        

      </div>

      <div class="div2">
        
<h3><a name="rpcfaults"></a>4.4 RPC Faults</h3>

        <p>The SOAP RPC Representation introduces additional SOAP fault
        subcode values to be used in conjunction with the fault codes
        described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultcodes">SOAP Fault Codes</a>.</p>
        
        <p>Errors arising during RPC invocations are reported
        according to the following rules:</p>

	<ol>

	  <li><p>A fault with a <code>Value</code>  of
          <code>Code</code>  set to "env:Receiver" SHOULD
          be generated when the receiver cannot handle the message
          because of some temporary condition, e.g. when it is out of
          memory.</p>

	    <div class="note"><p class="prefix"><b>Note:</b></p>
	      <p>Throughout this document, the term "<code>Value</code>  of
		<code>Code</code> " is used as a shorthand for "value of
		the <code>Value</code>  child <em>element information
		item</em> of the <code>Code</code>  <em>element
		information item</em>" (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultcodeelement">SOAP Code
		Element </a>).</p>
	    </div>

	  </li>

          <li>
            <p>A fault with a <code>Value</code>  of <code>Code</code> 
            set to "env:DataEncodingUnknown"
	    SHOULD be generated when the arguments
            are encoded in a data encoding unknown to the
            receiver.</p>
          </li>

	  <li>
            <p>A fault with a <code>Value</code>  of <code>Code</code> 
            set to "env:Sender" and a
            <code>Value</code>  of <code>Subcode</code>  set to
	    "rpc:ProcedureNotPresent"
            MAY be generated when the receiver
            does not support the procedure or method specified.</p>

	    <div class="note"><p class="prefix"><b>Note:</b></p>
	      <p>Throughout this document, the term "<code>Value</code>  of
		<code>Subcode</code> " is used as a shorthand for "value of
		the <code>Value</code>  child <em>element information
		item</em> of the <code>Subcode</code>  <em>element
		information item</em>" (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultsubcodeelement">SOAP Subcode
		element</a>).</p>
	    </div>

	  </li>

	  <li>
            <p>A fault with a <code>Value</code>  of <code>Code</code> 
            set to "env:Sender" and a
            <code>Value</code>  of <code>Subcode</code>  set to 
            "rpc:BadArguments" 
            MUST be generated when the receiver
            cannot parse the arguments or when there is a
            mismatch in number and/or type of the arguments
            between what the receiver expects and what was
            sent.</p>
	  </li>

	  <li><p>Other faults arising in an extension or from the
          application SHOULD be generated as described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapfault">SOAP Fault Codes</a>.</p>
      </li>

	</ol>
        
        <p>In all cases the values of the <code>Detail</code>  and
        <code>Reason</code>  <em>element information items</em>
        are implementation-defined. Details of their use MAY be specified by an
        external document.</p>
        
        <div class="note"><p class="prefix"><b>Note:</b></p><p>Senders might receive different faults from
        those listed above in response to an RPC invocation if the
        receiver does not support the (optional) RPC convention described
        here.</p></div>

      </div>
    </div>

<div class="div1">
  
<h2><a name="soapfeatspec"></a>5. A Convention for Describing Features and Bindings</h2>

<p>This section describes a convention describing Features (including
MEPs) and Bindings in terms of properties and property values. The
convention is sufficient to describe the distributed states of Feature
and Binding specifications as mandated by the Binding Framework (see
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
Framework</a>) and it is used to describe a Request-Response MEP (see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a>),  a Response MEP (see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>), the SOAP Web Method feature (see <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>) and the SOAP HTTP Binding (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>) elsewhere in this document. Along with the convention
itself, an informal model is defined that describes how properties
propagate through a SOAP system. Note that this model is intended to be
illustrative only, and is not meant to imply any constraints on the
structure or layering of any particular SOAP implementation.</p>

<div class="div2">
<h3><a name="modprop"></a>5.1 Model and Properties</h3>

<p>In general, a SOAP message is the information that one SOAP node wishes to
exchange with another SOAP node according to a particular set of features,
including a MEP. In addition, there may be information essential to exchanging
a message that is not part of the message itself. Such information is sometimes
called message metadata. In the model, the message, any message metadata,
and the various information items that enable features are represented as
abstractions called properties.</p>

<div class="div3">
<h4><a name="bindprops"></a>5.1.1 Properties</h4>

<p>Under the convention, properties are represented as follows:</p>

<ul>
    <li><p>Properties are named with URIs.</p></li>

    <li><p>Where appropriate, property values SHOULD have
    an XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a> <a href="#XMLSchemaP2">[XML Schema Part 2]</a> type listed in the specification which
    introduces the property.</p></li>
</ul>

</div>

<div class="div3">
<h4><a name="bindpropsscope"></a>5.1.2 Property Scope</h4>

<p>Properties within a SOAP node differ in terms of their scope and the
origins of their values. As shown in the figure below, we make the
distinction between per-message-exchange properties and more widely scoped
properties by assigning them to different containers called Message
Exchange Context and Environment Context respectively. All properties,
regardless of their scope, are shared by a SOAP node and a particular
Binding.</p>

<img src="xmlp-framework-props.png" alt="Model describing properties shared between SOAP and Binding">
  <p align="center">Figure 1: Model describing properties shared between SOAP and Binding</p>


<div class="div4">
<h5><a name="soapmec"></a>5.1.2.1 Message Exchange Context</h5>

<p>A message exchange context is a collection of properties whose scope is
limited to an instance of a given message exchange pattern. An example
of a message exchange context property is the identifier of the message
exchange pattern in use.</p>

</div>



<div class="div4">
<h5><a name="soapenvc"></a>5.1.2.2 Environment Context</h5>

<p>The Environment Context is a collection of properties whose scope
extends beyond an instance of a given message exchange pattern.
Examples of Environment Context properties are the IP address of the
SOAP node or the current date and time.</p>

<p>The values of properties in Environment Context may depend upon local
circumstances (as depicted by the external arrow from Environment Context in
the figure above). More specifically, the properties in the example
could be influenced by an operating system user ID on whose behalf a
message exchange is being executed. The mapping of information in a
particular implementation to such properties is outside the scope of
the binding framework although the abstract representation of such
information as properties is not.</p>

</div>

</div>

<div class="div3">
<h4><a name="bindpropfeat"></a>5.1.3 Properties and Features</h4>

<p>A feature may be expressed through multiple properties and a single property
may enable more than one feature. For example, the properties called User ID and
Password may be used to enable a feature called Authentication. As a second example,
a single property called Message ID could be used to enable one feature called
Transaction and a second feature called Message Correlation.</p>

</div>

</div>

</div>

    <div class="div1">
<h2><a name="soapsupmep"></a>6. SOAP-Supplied Message Exchange Patterns and Features</h2>
    
      <div class="div2">
<h3><a name="meppropconv"></a>6.1 Property Conventions for SOAP Message Exchange Patterns</h3>

       <p><a href="#tabmeppropdefs"><b>Table 2</b></a> describes the properties
       (in accordance with the property naming conventions
       defined in this document) that support the description of
       message exchange patterns (MEPs). Other properties may
       be involved in the specification of particular MEPs,
       but the properties in this table are generally applicable to all MEPs.</p>

        <a name="tabmeppropdefs"></a><table border="1">
          <caption>Table 2: Property definitions supporting the description of MEPs</caption>
          <tbody>
	    <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b>The name
		of the MEP in
		operation.  
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Type:</b> xs:anyURI
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
	    <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> A value that denotes a pattern-specific, 
	       binding-independent reason for the failure of a message 
	       exchange. Underlying protocol binding specifications
		may define properties to convey more binding-specific
		details of the failure. 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Type:</b> xs:anyURI
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
	    <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b>The identifier of the pattern-specific role of the
		  local SOAP node participating in the message
		  exchange.
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Type:</b> xs:anyURI
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr><tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> The identifier of the current state of the message
		  exchange. This value is managed by the binding
		  instance and may be inspected by other entities
		  monitoring the progress of the message
		  exchange.
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Type:</b> xs:anyURI
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
	  </tbody>
        </table>

      </div>

      <div class="div2">
        
<h3><a name="singlereqrespmep"></a>6.2 SOAP Request-Response Message Exchange Pattern</h3>

	<p>This section defines the message exchange pattern (MEP) called "Request-Response". The
	  description is an abstract presentation of the operation of
	  this MEP. It is not intended to describe a real
	  implementation or to suggest how a real implementation should
	  be structured.</p>

	<div class="div3"> 
<h4><a name="mepname"></a>6.2.1 SOAP Feature Name</h4>

       <p>This message exchange pattern is identified by
	  the URI (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
	  <ul><li><p>"http://www.w3.org/2003/05/soap/mep/request-response/"</p></li></ul>
    
    </div>
         
         <div class="div3">
           
<h4><a name="bindinfdesc"></a>6.2.2 Description</h4>

	  <p>The SOAP Request-Response MEP defines a
	    pattern for the exchange of a SOAP message acting as a
	    request followed by a message acting as a response.
            The response message MAY contain a SOAP envelope,
            or else the response MUST be a binding-specific
            message indicating that the request has been received.
            In the absence of failure in the underlying
	    protocol, this MEP consists of exactly two 
	    messages.</p>

       <p>In the normal operation of a message exchange conforming to
       the Request-Response MEP, a
       request message is first transferred from the requesting SOAP
       node to the responding SOAP node. Following the successful
       processing of the request message by the responding SOAP node,
       a response message is transferred from the responding
       SOAP node to the requesting SOAP node. </p>

       <p>Abnormal operation during a Request-Response message exchange
       might be caused by a failure to transfer the request message, a
       failure at the responding SOAP node to process the request
       message, or a failure to transfer the response message. Such
       failures might be silent at either or both of the requesting and
       responding SOAP nodes involved, or might result in the generation of a SOAP 
       or binding-specific fault (see <a href="#bindfaulthdn"><b>6.2.4 Fault Handling</b></a>).
       Also, during abnormal operation
       each SOAP node involved in the message exchange might differ in
       its determination of the successful completion of the message
       exchange. </p>
       
       <p>The scope of a Request-Response MEP is limited to
       the exchange of a request message and a response message between
       one requesting and one responding SOAP node. This pattern does
       not mandate any correlation between multiple requests nor
       specific timing for multiple requests. Implementations MAY choose
       to support multiple ongoing requests (and associated response
       processing) at the same time.</p>
				</div>
    <div class="div3">
      
<h4><a name="bindformdesc"></a>6.2.3 State Machine Description</h4>

	  <p>The Request-Response MEP defines a set of properties described in <a href="#tabreqresprops"><b>Table 3</b></a>.</p>

<a name="tabreqresprops"></a><table border="1">
	    <caption>Table 3: Property definitions for Request-Response MEP</caption>
	    <tbody>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Value: </b>An abstract structure that represents the current
		  outbound message in the message exchange. This
		  abstracts both SOAP Envelope and any other
		  information structures that are transferred along
		  with the envelope.</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Type: </b>Not specified</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Value: </b>An abstract structure that represents the current
		  inbound message in the message exchange. This
		  abstracts both SOAP Envelope and any other
		  information structures that are transferred along
		  with the envelope.</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Type: </b>Not specified</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Value: </b>The identifier of the immediate destination of an
		  outbound message.</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Type: </b>xs:anyURI</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Value: </b>The identifier of the immediate sender of an inbound
		  message.</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Type: </b>xs:anyURI</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>

	  <p>To initiate a message exchange conforming to the
	  Request-Response MEP, the requesting SOAP node instantiates a
	  local message exchange context. <a href="#tabreqcon"><b>Table 4</b></a> describes how
	  the context is initialized.</p>

        <a name="tabreqcon"></a><table border="1">
          <caption>Table 4: Instantiation of a Message Exchange Context
              for a requesting SOAP node</caption>
          <tbody>
	    <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> "http://www.w3.org/2003/05/soap/mep/request-response/"</td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
           <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> "None"</td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Notes:</b> A relative URI whose 
      base URI is the value of the property named
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code> 
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
           <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> "RequestingSOAPNode"</td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Notes:</b>  A relative URI whose 
      base URI is the value of the property named
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code> 
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>

           <tr>
	    <td rowspan="1" colspan="1">
            <table> 
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> "Init"</td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Notes:</b> A relative URI whose base URI is the value of the property named
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</span></code> 
              </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
           <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/mep/OutboundMessage</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> An abstraction of the request message </td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>
           <tr>
	    <td rowspan="1" colspan="1">
            <table>
	    <tbody>
	    <tr>
	      <td rowspan="1" colspan="1">
                 <b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/mep/ImmediateDestination</span></code> 
              </td>
	    </tr>
	    <tr>
	      <td rowspan="1" colspan="1">
               <b>Value:</b> An identifier (URI) that denotes the responding SOAP node</td>
	    </tr>
	    </tbody>
            </table>
           </td>
           </tr>

	  </tbody>
        </table>
         
           <p>There may be other properties related to the operation of
           the message exchange context instance. Such properties are
           initialized according to their own feature specifications.
           </p>

           <p>Once the message exchange context is initialized, control
           of the context is passed to a (conforming) local binding
           instance. </p>

           <p>The diagram below shows the logical state transitions at
           the requesting and responding SOAP nodes during the lifetime
           of the message exchange. At each SOAP node, the local binding
           instance updates (logically) the value of the
           <code>http://www.w3.org/2003/05/soap/bindingFramework/
           ExchangeContext/State</code>  property to reflect the current
           state of the message exchange. The state names are relative
           URIs, relative to a base URI value carried in the
           <code>http://www.w3.org/2003/05/soap/bindingFramework/
           ExchangeContext/Role</code>  property of the local message
           exchange context.</p>

	   <img src="StateTransitions.png" alt="Request-Response MEP State Transition Diagram.">
	     <p align="center">Figure 2: Request-Response MEP State Transition Diagram.</p>
	   

           <p>When the local binding instance at the responding SOAP
           node starts to receive an inbound request message, it
           (logically) instantiates a message exchange context. <a href="#tabrescon"><b>Table 5</b></a>
           describes the properties that the binding initializes as
           part of the context's instantiation.</p>
           	  
<a name="tabrescon"></a><table border="1">
          <caption>Table 5: Instantiation of Message Exchange Context for
             an inbound request message at a responding SOAP node</caption>
          <tbody>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>"http://www.w3.org/2003/05/soap/mep/request-response/"
               </td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Notes: </b>Initialized as early as possible during the life cycle
              of the message exchange.</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>"None"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1"><b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>"RespondingSOAPNode"
              </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> .
Initialized as early as possible during the life cycle the message exchange.
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code> 
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>"Init"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><b>Notes: </b>A relative URI whose base URI is the
value of  the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>

	 <p>When the requesting and responding SOAP nodes transition between
	 states, the local binding instance (logically) updates a number of
	 properties. <a href="#tabreqstatetrans"><b>Table 6</b></a> and <a href="#tabresstatetrans"><b>Table 7</b></a> describe these updates for the requesting
	 and the responding SOAP nodes, respectively.</p>
     
<a name="tabreqstatetrans"></a><table border="1">
<caption>Table 6: Requesting SOAP Node State Transitions</caption>
<tbody>
<tr>
 <th rowspan="1" colspan="1">CurrentState</th>
 <th rowspan="1" colspan="1"> </th>
</tr>
<tr>
 <td rowspan="1" colspan="1">"Init"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Unconditional</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Requesting"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of request message
		    abstracted in
		    <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> .</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Requesting"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message transmission failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
		      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
		      "transmissionFailure"</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving response message</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Sending+Receiving"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
		      <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>  to denote the sender of the response message (may differ from the values in <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> ).
		      Start making an abstraction of the response message available in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Sending+Receiving"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
		      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
		      "exchangeFailure"</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed sending request message. Completed receiving response message.</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>If a SOAP envelope is received in the response (I.e., in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> ), then process it according to the SOAP processing model.</td></tr>
   </tbody>
  </table>
 </td>
</tr>
</tbody>
</table>

       <p> </p>

<a name="tabresstatetrans"></a><table border="1">
<caption>Table 7: Responding SOAP Node State Transitions</caption>
<tbody>
<tr>
 <th rowspan="1" colspan="1">CurrentState</th>
 <th rowspan="1" colspan="1"> </th>
</tr>
<tr>
 <td rowspan="1" colspan="1">"Init"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving request message</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
		      <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>  to denote the sender of the request message (if determinable).
		      Start making an abstraction of the request message available in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .
		      Pass control of message exchange context to SOAP processor.</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Receiving"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message reception failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
		      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
		      "receptionFailure".</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start of response message available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> </td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving+Sending"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of response message.  If an envelope is provided in  abstracted in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  then include that in the response message.</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Receiving+Sending"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to 
		      "exchangeFailure".</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed receiving request message. Completed sending response message.</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>

   </tbody>
  </table>
 </td>
</tr>
</tbody>
</table>

	  <p>Bindings that implement this MEP
	  MAY provide for streaming of SOAP responses.
	  That is, responding SOAP nodes MAY begin transmission
	  of a SOAP response while a SOAP request is still being
	  received and processed. When SOAP nodes implement
	  bindings that support streaming, the following
	  rules apply:</p>

      <ul>
        <li><p>All the rules in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
        <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#bindfw">Binding
        Framework</a> regarding streaming of individual SOAP
        messages MUST be obeyed for both request and response SOAP
        messages.</p></li>
        
        <li><p>When using streaming SOAP bindings, requesting SOAP nodes
        MUST avoid deadlock by accepting and if necessary processing
        SOAP response information while the SOAP request is being transmitted.</p>
        
        <div class="note"><p class="prefix"><b>Note:</b></p><p>Depending on the implementation used and the size of
        the messages involved, this rule MAY require that SOAP applications
        stream application-level response processing in parallel with request
        generation.</p></div>
        </li>
        
        <li><p>A requesting SOAP node MAY enter the "Fail" state,
        and thus abort transmission of the outbound SOAP request,
        based on information contained in an incoming streamed SOAP
        response.</p></li>

      </ul>
      
         </div>
         
         <div class="div3">
         
           
<h4><a name="bindfaulthdn"></a>6.2.4 Fault Handling</h4>
           
	  <p>During the operation of the Request-Response MEP, the
	    participating SOAP nodes may generate SOAP faults.</p>

           <p>If a SOAP fault is generated by the responding SOAP node
           while it is in the "Receiving" state, the SOAP
           fault is made available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  and the
           state machine transitions to the "Receiving+Sending" state.</p>

           <p>This MEP makes no claims about the disposition or
           handling of SOAP faults generated by the requesting SOAP node
           during any processing of the response message that follows the
           "Success" state in the requesting SOAP node's state transition
           table (see <a href="#tabreqstatetrans"><b>Table 6</b></a>).</p>
    
         </div>
         
      </div>

      
      <div class="div2">
        
        
<h3><a name="soapresmep"></a>6.3 SOAP Response Message Exchange Pattern</h3>
		
		<p>This section defines the message exchange pattern (MEP)
		called "SOAP Response". The description is an abstract
		presentation of the operation of this MEP. It is not intended to
		describe a real implementation or to suggest how a real
		implementation should be structured.</p>

        <div class="div3">
            
<h4><a name="mepname2"></a>6.3.1 SOAP Feature Name</h4>
	  <p>This message exchange pattern is identified by
	    the URI (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
            <ul>
                <li>
                    <p>
                        "http://www.w3.org/2003/05/soap/mep/soap-response/"
                    </p>
                </li>
            </ul>
        </div>
        <div class="div3">
            
<h4><a name="bindinfdesc2"></a>6.3.2 Description</h4>

	  <p>The SOAP Response MEP defines a pattern for
	    the exchange of a non-SOAP message acting as a request
	    followed by a SOAP message acting as a response. In the
	    absence of failure in the underlying protocol, this MEP
	    consists of exactly two messages, only one of which is a
	    SOAP message:</p>

            <ul>
                <li>
                    <p>A request  
transmitted in a binding-specific manner that does not include a SOAP envelope and hence does not
involve any SOAP processing by the receiving SOAP node.</p>
                </li>
                <li>
                    <p>A response message which contains a SOAP
envelope. The MEP is completed by the processing of the SOAP envelope
following the rules of the SOAP processing model (see
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, section
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).
</p>
                </li>
            </ul>
            <p>
Abnormal operation during a SOAP Response message exchange might be
caused by a failure to transfer the request message or the
response message. Such failures might be silent at either or both
of the requesting and responding SOAP nodes involved, or might
result in the generation of a SOAP or binding-specific fault (see
section <a href="#bindfaulthdn2"><b>6.3.4 Fault Handling</b></a>). Also, during abnormal
operation each SOAP node involved in the message exchange might
differ in its determination of the successful completion of the
message exchange.
</p>

            <p>The scope of a SOAP Response MEP is limited to
the request for an exchange of a response message between
one requesting and one responding SOAP node. This pattern does
not mandate any correlation between multiple requests nor
specific timing for multiple requests. Implementations MAY choose
to support multiple ongoing requests (and associated response
processing) at the same time.</p>
            <div class="note"><p class="prefix"><b>Note:</b></p>
                <p>This MEP cannot be used in conjunction with features expressed as SOAP header blocks in the request because there is no SOAP envelope in which to carry them.</p>
            </div>


        </div>

        <div class="div3">
            
<h4><a name="bindformdesc2"></a>6.3.3 State Machine Description</h4>
            <p>The SOAP Response MEP defines a set of properties described in <a href="#tabreqresprops2"><b>Table 8</b></a>.</p>
            <a name="tabreqresprops2"></a><table border="1">
                <caption>Table 8: Property definitions for SOAP Response MEP</caption>
                <tbody>
                    <tr>
                        <th rowspan="1" colspan="1">Property Name</th>
                        <th rowspan="1" colspan="1">Property Description</th>
                        <th rowspan="1" colspan="1">Property Type</th>
                    </tr>
                    <tr>
                        <td rowspan="1" colspan="1">
                            <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> 
                        </td>
                        <td rowspan="1" colspan="1">An abstract structure that represents the current
  outbound message in the message exchange. This
  abstracts both SOAP Envelope Infoset (which MAY be null) and any other
  information structures that are transferred along
  with the envelope.</td>
  <td rowspan="1" colspan="1">Not specified</td>
                    </tr>
                    <tr>
                        <td rowspan="1" colspan="1">
                            <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> 
                        </td>
                        <td rowspan="1" colspan="1">An abstract structure that represents the current
  inbound message in the message exchange. This
  abstracts both SOAP Envelope Infoset (which MAY be null) and any other
  information structures that are transferred along
  with the envelope.
                        </td>
                        <td rowspan="1" colspan="1">Not specified</td>
                    </tr>
                    <tr>
                        <td rowspan="1" colspan="1">
                            <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> 
                        </td>
                        <td rowspan="1" colspan="1"><p>The identifier of the immediate destination of an
  outbound message.</p></td>
  <td rowspan="1" colspan="1">xs:anyURI</td>
                    </tr>
                    <tr>
                        <td rowspan="1" colspan="1">
                            <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> 
                        </td>
                        <td rowspan="1" colspan="1"><p>The identifier of the immediate sender of an inbound
  message.</p></td>
  <td rowspan="1" colspan="1">xs:anyURI</td>
                    </tr>
                </tbody>
            </table>
            <p>To initiate a message exchange conforming to the
SOAP Response MEP, the requesting SOAP node instantiates a
local message exchange context. <a href="#tabreqcon2"><b>Table 9</b></a> describes how
the context is initialized.</p>

            <a name="tabreqcon2"></a><table border="1">
                <caption>Table 9: Instantiation of a Message Exchange Context
      for a requesting SOAP node</caption>
                <tbody>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
                            "http://www.w3.org/2003/05/soap/mep/soap-response/"
                        </td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"None"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"RequestingSOAPNode"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"Init"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>An abstraction of the request
                        message that does not include a SOAP
                        envelope infoset.</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>An identifier (URI) that denotes
                        the responding SOAP node </td>
</tr>

</tbody>
</table>
</td>
</tr>
</tbody>
            </table>

            <p>There may be other properties related to the operation of
   the message exchange context instance. Such properties are
   initialized according to their own feature specifications.
   </p>
            <p>Once the message exchange context is initialized, control
   of the context is passed to a (conforming) local binding
   instance. </p>
            <p>The diagram below shows the logical state transitions at
   the requesting and responding SOAP nodes during the lifetime
   of the message exchange. At each SOAP node, the local binding
   instance updates (logically) the value of the
   <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code>  property to
   reflect the current state of the message exchange. The state names
   are relative URIs, relative to a Base URI value carried in
   the <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code>  property of the local
   message exchange context.</p>
            <img src="StateTransitions2.png" alt="SOAP Response MEP State Transition Diagram.">
              <p align="center">Figure 3: SOAP Response MEP State Transition Diagram</p>
            
            <p>When the local binding instance at the responding SOAP
   node starts to receive an inbound request message, it
   (logically) instantiates a message exchange context. <a href="#tabrescon2"><b>Table 10</b></a>
   describes the properties that the binding initializes as
   part of the context's instantiation.</p>

            <a name="tabrescon2"></a><table border="1">
                <caption>Table 10: Instantiation of Message Exchange Context for
     an inbound request message</caption>
                <tbody>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
                            "http://www.w3.org/2003/05/soap/mep/soap-response/"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>
                            Initialized as early as possible during the life cycle of the message exchange. </td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"None"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"RespondingSOAPNode"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>
A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> .
Initialized as early as possible during the life cycle the message exchange.
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<table>
<tbody>
<tr>
<td rowspan="1" colspan="1">
<b>Property name: </b>
                            <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code> 
                        </td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Value: </b>
"Init"
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> 
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
            </table>

            <p>When the requesting and responding SOAP nodes transition between
states, the local binding instance (logically) updates a number of
properties. <a href="#tabreqstatetrans2"><b>Table 11</b></a> and <a href="#tabresstatetrans2"><b>Table 12</b></a> describe these updates for the requesting
and the responding SOAP nodes, respectively.</p>
<a name="tabreqstatetrans2"></a><table border="1">
<caption>Table 11: Requesting SOAP Node State Transitions</caption>
<tbody>
<tr>
 <th rowspan="1" colspan="1">CurrentState</th>
 <th rowspan="1" colspan="1"> </th>
</tr>

<tr>
 <td rowspan="1" colspan="1">"Init"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Unconditional</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Requesting"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate request</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Requesting"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message transmission failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
      "transmissionFailure"</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving response message</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
      <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>  to denote the sender of the response message
      (may differ from the values in <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> ).
      Start making an abstraction of the response message available in
      <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Receiving"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
      "exchangeFailure"</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed receiving response message.</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>

   </tbody>
  </table>
 </td>
</tr>
</tbody>
</table>
            <p> </p>

<a name="tabresstatetrans2"></a><table border="1">
<caption>Table 12: Responding SOAP Node State Transitions</caption>
<tbody>
<tr>
 <th rowspan="1" colspan="1">CurrentState</th>
 <th rowspan="1" colspan="1"> </th>
</tr>

<tr>
 <td rowspan="1" colspan="1">"Init"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving request</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> 
      to denote the sender of the request message (if determinable). Pass control of message exchange context to SOAP processor.</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Receiving"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message reception failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set
      <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to
      "receptionFailure".</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start of response message available in
                        <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> </td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Sending"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of response message abstracted in
                        <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> .</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="2" colspan="1">"Sending"</td>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
    <tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>  to 
      "exchangeFailure".</td></tr>
   </tbody>
  </table>
 </td>
</tr>

<tr>
 <td rowspan="1" colspan="1">
  <table>
   <tbody>
    <tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed sending response message.</td></tr>
    <tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>

   </tbody>
  </table>
 </td>
</tr>
</tbody>
</table>
        </div>
				<div class="div3">
					
<h4><a name="bindfaulthdn2"></a>6.3.4 Fault Handling</h4>
					<p>During the operation of the SOAP Response MEP, the
	    participating SOAP nodes may generate SOAP faults.</p>

					<p>If a SOAP fault is generated
					by the responding SOAP node while it is in the
					"Receiving" state, the SOAP fault is
					made available in
                        <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> 
					and the state machine transitions to the
					"Sending" state.</p>

					<p>This MEP makes no claims about the disposition or
           handling of SOAP faults generated by the requesting SOAP node
           during any processing of the response message that follows the
           "Success" state in the requesting SOAP node's state transition
           table (see <a href="#tabreqstatetrans2"><b>Table 11</b></a>).</p>

				</div>
			</div>
                       <div class="div2">
                           
<h3><a name="WebMethodFeature"></a>6.4 SOAP Web Method Feature</h3>
                              <p>This section defines the "SOAP Web Method Feature".</p>
                               <div class="div3">
					
<h4><a name="WebMethodFeatureName"></a>6.4.1 SOAP Feature Name</h4>
	  <p>The SOAP Web Method feature is identified by the URI (see
	  SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
					<ul>
						<li>
							<p>
								"http://www.w3.org/2003/05/soap/features/web-method/"
							</p>
						</li>
					</ul>

				</div>
                <div class="div3">
					
<h4><a name="WebMethodFeatureDesc"></a>6.4.2 Description</h4>

					
<p>
Underlying protocols designed for use on the World 
Wide Web provide for manipulation of resources using a small set of Web methods 
such as GET, PUT, POST, and DELETE.
These methods are formally defined in the HTTP specification <a href="#RFC2616">[RFC 2616]</a>, but other underlying protocols might also support them. 
Bindings to HTTP or such other protocols SHOULD use the 
SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message.</p>

<p>Bindings supporting this feature SHOULD use the appropriate embodiment of that method if provided by the underlying protocol; for example, the HTTP binding
provided with this specification represents the "GET" Web method as an HTTP GET request, and the "POST" method
as an HTTP POST request (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.</p>

<p>The SOAP Web Method feature MAY be implemented by bindings to underlying
transports that have no preferred embodiment of particular Web methods (e.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature. </p>
					
				</div>
<div class="div3">
					
<h4><a name="webmethodstatemachine"></a>6.4.3 SOAP Web Method Feature State Machine </h4>
					<p>The SOAP Web Method feature defines a single property, which is described in <a href="#tabwebmethprops"><b>Table 13</b></a>.</p>
					<a name="tabwebmethprops"></a><table border="1">
						<caption>Table 13: Property definition for the SOAP Web Method feature</caption>
						<tbody>
							<tr>
								<th rowspan="1" colspan="1">Property Name</th>
								<th rowspan="1" colspan="1">Property Description</th>
								<th rowspan="1" colspan="1">Property Type</th>
							</tr>
							<tr>
								<td rowspan="1" colspan="1">
									<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> 
								</td>
								<td rowspan="1" colspan="1">One of "GET", "POST",
								    "PUT", "DELETE" (or others which may subsequently be added to the repertoire
of Web methods.)</td>
<td rowspan="1" colspan="1">Not specified</td>
							</tr>
							
							
						</tbody>
					</table>
					<p>This specification provides for the use of the SOAP Web Method feature in conjunction with the
<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> message exchange patterns. This
feature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.</p>
<p>
A node sending a request message MUST provide a value for the
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  property. 
A protocol binding supporting this feature SHOULD set the value of the
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  property at the receiving node to match that provided by the sender;
the means of
transmission for the method property is binding-specific.</p>

<p>A responding node SHOULD respond in a manner consistent with the Web method requested (e.g. a
"GET" should
result in retrieval of a representation of the identified resource) or SHOULD fault in an
application-specific manner if the Web method cannot be supported. </p>

<p>Bindings implementing this feature
  MUST employ a Message Exchange Pattern with semantics that are
  compatible with the Web method selected.  For example, the SOAP
  Response Message Exchange Pattern (see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>) is compatible with GET.</p>
		
				</div>
             </div>

                       <div class="div2">
                           
<h3><a name="ActionFeature"></a>6.5 SOAP Action Feature</h3>
                              <p>This section defines the "SOAP Action Feature".</p>
                               <div class="div3">
					
<h4><a name="ActionFeatureName"></a>6.5.1 SOAP Feature Name</h4>
	  <p>The SOAP Action feature is identified by the URI
	  (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
					<ul>
						<li>
							<p>
								"http://www.w3.org/2003/05/soap/features/action/"
							</p>
						</li>
					</ul>

				</div>
                <div class="div3">
					
<h4><a name="ActionFeatureDesc"></a>6.5.2 Description</h4>

					
<p>
Many SOAP 1.2 underlying protocol bindings will likely
utilize the "application/soap+xml" media type (described in
<a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>) to transmit XML serializations of SOAP messages.
The media type specifies an optional <code>action</code>  parameter, which can be used to optimize dispatch or routing,
among other things. The Action Feature specifies well-known
URIs to indicate support for the <code>action</code>  parameter in
bindings which use MIME, and also to refer to value of the
parameter itself.
</p>
					
				</div>
<div class="div3">
					
<h4><a name="actionstatemachine"></a>6.5.3 SOAP Action Feature State Machine </h4>
					<p>The SOAP Action feature defines a single property, which is described in <a href="#tabactionprops"><b>Table 14</b></a>. The value of this property MUST be an absolute URI<a href="#RFC3986">[RFC 3986]</a> and MUST NOT be empty.</p>
					<a name="tabactionprops"></a><table border="1">
						<caption>Table 14: Property definition for the SOAP Action feature</caption>
						<tbody>
							<tr>
								<th rowspan="1" colspan="1">Property Name</th>
								<th rowspan="1" colspan="1">Property Type</th>
							</tr>
							<tr>
								<td rowspan="1" colspan="1">
									<p><code>http://www.w3.org/2003/05/soap/features/action/Action</code> </p>
								</td>
                                <td rowspan="1" colspan="1"><p><code>xsd:anyURI</code> </p></td>
							</tr>
							
							
						</tbody>
					</table>
					<p>If the <code>http://www.w3.org/2003/05/soap/features/action/Action</code> 
					property has a value at a SOAP sender utilizing a
binding supporting this feature, the sender MUST use the
property value as the value of the <code>action</code>  parameter in
the media type designator.</p>

<p>Conversely, if a value arrives in the <code>action</code>  parameter of
the media type designator at a SOAP receiver, the receiver MUST
make that value available as the value of the <code>http://www.w3.org/2003/05/soap/features/action/Action</code> 
property.</p>
		
				</div>
             </div>

                             
		</div>

<div class="div1">
<h2><a name="soapinhttp"></a>7. SOAP HTTP Binding</h2>

  <div class="div2">
<h3><a name="http-intro"></a>7.1 Introduction</h3>
  
    <p>The SOAP HTTP Binding provides a binding of SOAP to HTTP. The
    binding conforms to the SOAP Protocol Binding Framework (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
    Framework</a>) and supports the message
    exchange patterns and features described in <a href="#soapsupmep"><b>6. SOAP-Supplied Message Exchange Patterns and Features</b></a>.</p>

    <div class="div3">
    
      
<h4><a name="httpoptionality"></a>7.1.1 Optionality</h4>
	  
	  <p>The SOAP HTTP Binding is optional and SOAP nodes are NOT
	    required to implement it. A SOAP node that correctly and
	    completely implements the SOAP HTTP Binding may to be said
	    to "conform to the SOAP 1.2 HTTP Binding."</p>
	  
	  <p>The SOAP version 1.2 specification does not preclude
	    development of other bindings to HTTP or bindings to other
	    protocols, but communication with nodes using such other
	    bindings is not a goal. Note that other bindings of SOAP
	    to HTTP MAY be written to provide support for SOAP Message
	    exchange patterns other than <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>. Such alternate bindings MAY therefore
	    make use of HTTP features and status codes not required
	    for this binding. </p>
    
    </div>    
    
    
    <div class="div3">
<h4><a name="httpuse"></a>7.1.2 Use of HTTP</h4>   
    
      <p>The SOAP HTTP binding defines a base URI according
      to the rules in HTTP/1.1 <a href="#RFC2616">[RFC 2616]</a>. I.e., the base URI
      is the HTTP Request-URI or the value of the HTTP
      Content-Location header field.</p>
      
	  <p>This binding of SOAP to HTTP is intended to make
	    appropriate use of HTTP as an application protocol. For
	    example, successful responses are sent with status code
	    200 or 202, and failures are indicated as 4XX or 5XX. This
	    binding is not intended to fully exploit the features of
	    HTTP, but rather to use HTTP specifically for the purpose
	    of communicating with other SOAP nodes implementing the
	    same binding. Therefore, this HTTP binding for SOAP does
	    not specify the use and/or meaning of all possible HTTP
	    methods, header fields and status responses. It specifies
	    only those which are pertinent to the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>, or which are likely to be introduced
	    by HTTP mechanisms (such as proxies) acting between the
	    SOAP nodes.</p>
    
	    <p>Certain
	    optional features provided by this binding depend on capabilities provided by
	    HTTP/1.1, for example content
	    negotiation. Implementations SHOULD thus use HTTP/1.1
	    <a href="#RFC2616">[RFC 2616]</a> (or later compatible versions that share the
	    same major version number). Implementations MAY also be
	    deployed using HTTP/1.0, although in this case certain optional binding features
	    may not be provided.</p>

	    <div class="note"><p class="prefix"><b>Note:</b></p><p>SOAP HTTP Binding implementations need to account for the
	    fact that HTTP/1.0 intermediaries (which may or may
	    not also be SOAP intermediaries) may alter the representation of
	    SOAP messages, even in situations where both the initial SOAP sender and
	    ultimate SOAP receiver use HTTP/1.1.</p></div>

    
    </div>
    
    
    <div class="div3">
<h4><a name="httpinterop"></a>7.1.3 Interoperability with non-SOAP HTTP Implementations</h4>
		<p>
		Particularly when used with the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>, the HTTP messages 
		produced by this binding are likely to be
		indistinguishable from those produced by non-SOAP implementations
		performing similar operations. 
		Accordingly, some degree of interoperation can be made possible between SOAP nodes and other HTTP
		implementations when using this binding.
		For example, a conventional Web server (i.e., one not
		written specifically to conform to this specification) might be used to respond
		to SOAP-initiated HTTP GET's with representations of
		<code>Content-Type</code>  "application/soap+xml".
		Such interoperation is not a normative feature of this specification.
		</p>
    
	  <p>Even though HTTP often is used on the
	    well-known TCP port 80, the use of HTTP is not limited to
	    that port. As a result, it is possible to have a dedicated
	    HTTP server for handling SOAP processing on a distinct TCP
	    port. Alternatively, it is possible to use a separate
	    virtual host for dealing with SOAP processing. Such
	    configuration, however, is a matter of convenience and is
	    not a requirement of this specification (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#secbindappspecprot">Binding to
	    Application-Specific Protocols</a>).</p>
    </div>
    
    
    <div class="div3">
<h4><a name="httpmediatype"></a>7.1.4 HTTP Media-Type</h4>
    <p>Conforming implementations of this binding:</p>
    
    <ol>
    
        <li><p>MUST be capable of sending and receiving messages
        serialized using media type "application/soap+xml" whose proper
        use and parameters are described in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>.</p></li>

        <li><p>MAY send requests and responses using other media types
        providing that such media types provide for at least the
        transfer of SOAP XML Infoset.</p></li>
        
        <li><p>MAY, when sending requests, provide an HTTP Accept
        header field. This header field:</p>
        
            <ul>
            
                <li><p>SHOULD indicate an ability to accept at minimum
                "application/soap+xml".</p></li>

                <li><p>MAY additionally indicate willingness to accept
                other media types that satisfy 2 above.</p></li>
                
            </ul>
            
        </li>
        
    </ol>

	</div>

  </div>

  <div class="div2">
<h3><a name="http-bindname"></a>7.2 Binding Name</h3>

	<p>This binding is identified by the URI (see
	  SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
	  Framework</a>):</p>
    
    <ul>

      <li><p>"http://www.w3.org/2003/05/soap/bindings/HTTP/"</p>
      </li>

    </ul>
    
  </div>

  <div class="div2">
<h3><a name="http-suptransmep"></a>7.3 Supported Message Exchange Patterns</h3>

    <p>An implementation of the SOAP HTTP Binding
    MUST support the following message exchange
    patterns (MEPs):</p>
    
    <ul>
      <li><p>  
      "http://www.w3.org/2003/05/soap/mep/request-response/" 
      (see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a>) </p></li>
					<li>
						<p>
							"http://www.w3.org/2003/05/soap/mep/soap-response/" 
      (see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>) </p>
					</li>
				</ul>
			</div>
<div class="div2">
				
<h3><a name="http-suptfeatures"></a>7.4 Supported Features</h3>
				<p>An implementation of the SOAP HTTP Binding
    MUST support the following additional features:</p>
				<ul>
					<li>
						<p>
							"http://www.w3.org/2003/05/soap/features/web-method/" 
      (see <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>) </p>
					</li>
					
					<li>
					    <p>
					       "http://www.w3.org/2003/05/soap/features/action/"
      (see <a href="#ActionFeature"><b>6.5 SOAP Action Feature</b></a>) </p>
					</li>
    </ul>
    
    <p>The possible values of
    <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> 
    property are restricted in this HTTP binding according to the MEP
    in use (as present in
    <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> ):</p>

        <a name="tabwebmethodvalues"></a><table border="1">
          <caption>Table 15: Possible values of the Web-Method Method property</caption>
          <tbody>
            <tr>
              <th rowspan="1" colspan="1"><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> </th>
              <th rowspan="1" colspan="1"><code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> </th>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap/mep/request-response/"</td>
              <td rowspan="1" colspan="1">"POST"</td>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap/mep/soap-response/"</td>
              <td rowspan="1" colspan="1">"GET"</td>
            </tr>
         </tbody>
       </table>              

    <div class="note"><p class="prefix"><b>Note:</b></p><p>Other SOAP Version 1.2 bindings to HTTP may permit
    other combinations of
    <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> 
    and
    <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> .</p></div>


  </div>

  <div class="div2">
<h3><a name="http-msgexop"></a>7.5 MEP Operation</h3>

    <p>For binding instances conforming to this specification:</p>
    
    <ul>
    
      <li><p>A SOAP node instantiated at an HTTP client may assume the role (i.e., the 
      property <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> ) of 
      "RequestingSOAPNode".</p></li>
      
      <li><p>A SOAP node instantiated at an HTTP server may assume the role (i.e., 
      the property <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> ) of 
      "RespondingSOAPNode". </p></li>
      
    </ul>
    
    <p>The remainder of this section describes the MEP state machine 
    and its relation to the HTTP protocol. In the state tables below, 
    the states are defined as values of the property <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code> 
    (see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>), and are of type <code>xs:anyURI</code> .
    For brevity, relative URIs are used, the base URI being the value of <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> .</p>
    
    <p>The message exchange pattern in use is indicated by the HTTP method
used in the request. HTTP GET corresponds to the SOAP-Response MEP,
HTTP POST corresponds to the SOAP Request-Response MEP.</p>
      
	<div class="div3">
					
	  
<h4><a name="http-reqsoapnode"></a>7.5.1 Behavior of Requesting SOAP Node</h4>

	  <p>The overall flow of the behavior of a requesting SOAP node
	  follows a state machine description consistent with either <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>
	  (differences are indicated as necessary.) This binding supports
	  streaming and, as a result, requesting SOAP nodes MUST avoid
	  deadlock by accepting and if necessary processing SOAP response
	  information while the SOAP request is being transmitted (see
	  <a href="#bindformdesc"><b>6.2.3 State Machine Description</b></a>). The following subsections describe
	  each state in detail.</p>

      <div class="div4">
<h5><a name="http-reqbindreqstate"></a>7.5.1.1 Init</h5>
      
      <p>In the "Init" state, a HTTP request is formulated according to <a href="#tabreqstateinitfields"><b>Table 16</b></a> and transmission of the request is initiated.</p>


        <a name="tabreqstateinitfields"></a><table border="1">
          <caption>Table 16: HTTP Request Fields</caption>
          <tbody>
            <tr>
            <th rowspan="1" colspan="1">Field</th>
            <th rowspan="1" colspan="1">Value</th></tr>
            <tr>
            <td rowspan="1" colspan="1">HTTP Method</td>
            <td rowspan="1" colspan="1">According to the <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  property. POST and GET are the only values supported by this binding.</td></tr>
            <tr>
            <td rowspan="1" colspan="1">Request URI</td>
            <td rowspan="1" colspan="1">The value of the URI carried in the  
              <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>  property of the 
              message exchange context.</td></tr>
            <tr>
            <td rowspan="1" colspan="1"><p>Content-Type header field</p></td>
            <td rowspan="1" colspan="1">The media type of the request entity body, if present; otherwise,
              omitted (see <a href="#http-intro"><b>7.1 Introduction</b></a> for a description of permissible media types).
              If the SOAP envelope infoset in the <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  property is null,
              then the <code>Content-Type</code>  header field MAY be omitted.</td>
            </tr>
            <tr>
            <td rowspan="1" colspan="1"><p>action parameter</p></td>
            <td rowspan="1" colspan="1"><p>According to the value of the <code>http://www.w3.org/2003/05/soap/features/action/Action</code>  property.</p></td>
            </tr>
            <tr>
            <td rowspan="1" colspan="1"><p>Accept header field (optional)</p></td>
            <td rowspan="1" colspan="1">List of media types that are acceptable in 
            response to the request message.</td>
            </tr>
            <tr>
            <td rowspan="1" colspan="1"><p>Additional header fields</p></td>
            <td rowspan="1" colspan="1"><p>Generated in accordance with the rules for the binding-specific expression of any optional features in use for this
            message exchange. For example, a Content-Encoding header field
            (see HTTP <a href="#RFC2616">[RFC 2616]</a>, section 14.11) may be used to
            express an optional compression feature.</p></td>
            </tr>
            <tr>
            <td rowspan="1" colspan="1">HTTP entity body</td>
            <td rowspan="1" colspan="1"><p>SOAP message serialized according to the rules for
            carrying SOAP messages in the media type given by the
            Content-Type header field. Rules for carrying SOAP messages in
            media type "application/soap+xml" are given
            in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>. If the SOAP envelope infoset in the
            <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  property is null,
            the entity body is omitted</p></td>
            </tr>
          </tbody>
        </table>

      </div>

      <div class="div4">
        
        
<h5><a name="http-reqbindwaitstate"></a>7.5.1.2 Requesting</h5>
              
        <p>In the "Requesting" state, sending
        of the request continues while waiting for the start of the
        response message. <a href="#tabreqstatereqtrans"><b>Table 17</b></a> details
        the transitions that take place when a requesting SOAP node
        receives an HTTP status line and response header fields. For
        some status codes there is a choice of possible next state. In
        cases where "Fail" is one of the choices, the
        transition is dependent on whether a SOAP message is present in
        the HTTP response. If a SOAP message is present, the next state
        is "Sending+Receiving" or
        "Receiving", otherwise the next state is
        "Fail". The choice between
        "Sending+Receiving" and
        "Receiving" depends of the MEP in use:
        "Sending+Receiving" is the next state for Request-Response while
        "Receiving" is the next state for SOAP-Response.</p>

<a name="tabreqstatereqtrans"></a><table border="1">
  <caption>Table 17: HTTP status code dependent transitions</caption>
  <tbody>
  <tr>
    <th valign="top" rowspan="1" colspan="1">Status Code</th>
    <th valign="top" rowspan="1" colspan="1">Reason phrase</th>
    <th valign="top" rowspan="1" colspan="1">Significance/Action</th>
    <th valign="top" rowspan="1" colspan="1">NextState</th></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">2xx</td>
    <td valign="top" rowspan="1" colspan="1">Successful</td>
    <td valign="top" rowspan="1" colspan="1"> </td>
    <td valign="top" rowspan="1" colspan="1"> </td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">200</td>
    <td valign="top" rowspan="1" colspan="1">OK</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>The response message follows in the HTTP response entity body.
      Start making an abstraction of the response message available in
      <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</p></td>
    <td valign="top" rowspan="1" colspan="1">"Sending+Receiving" or "Receiving"</td></tr>
   <tr>
    <td valign="top" rowspan="1" colspan="1">202</td>
    <td valign="top" rowspan="1" colspan="1">OK</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>        The request has been accepted, but either (a) no response envelope 
       is provided or (b) an envelope representing information related to 
       the request is provided -- such envelopes SHOULD be processed using 
       the SOAP Processing model (see
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, section
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).</p></td>
    <td valign="top" rowspan="1" colspan="1">"Receiving" (which will immediately transition to 
          "Success")</td></tr>
 <tr>
    <td valign="top" rowspan="1" colspan="1">301, 302, 307</td>
    <td valign="top" rowspan="1" colspan="1">Redirect</td>
    <td valign="top" rowspan="1" colspan="1"><p>The requested resource has 
      moved. In the case of unsafe HTTP method, like POST or PUT, explicit confirmation
      is required before proceeding as follow. </p>
      <p>In the case of a safe method, like GET, or if the redirection has been approved, 
      the HTTP request SHOULD be retried using the URI carried in the 
      associated Location header field as the new value for the  
      <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>  property.</p></td>
    <td valign="top" rowspan="1" colspan="1">"Init" or "Fail"</td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">303</td>
    <td valign="top" rowspan="1" colspan="1">See Other</td>
    <td valign="top" rowspan="1" colspan="1"><p>The requested resource has moved and the HTTP request SHOULD be 
	retried using the URI carried in the associated Location header field as the new
        value for the <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> 
        property. The value of 
        <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  is changed to
        ""GET"", the value of <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  is 
        set to "null". [Note: Status code 303 MUST NOT be sent unless the request 
        SOAP envelope has been processed according to the SOAP processing model 
        and the SOAP response is to be made available by retrieval from the URI
        provided with the 303.]</p></td>
    <td valign="top" rowspan="1" colspan="1">"Init"</td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">4xx</td>
    <td valign="top" rowspan="1" colspan="1">Client Error</td>
    <td valign="top" rowspan="1" colspan="1"> </td>
    <td valign="top" rowspan="1" colspan="1"> </td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">400</td>
    <td valign="top" rowspan="1" colspan="1">Bad Request</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>Indicates a problem with the received HTTP request message.</p></td>
    <td valign="top" rowspan="1" colspan="1"><p>"Sending+Receiving", "Receiving" or "Fail"</p></td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">401</td>
    <td valign="top" rowspan="1" colspan="1">Unauthorized</td>
    <td valign="top" rowspan="1" colspan="1"><p>Indicates that the HTTP 
      request requires authorization.</p>
      <p>The message exchange is 
      regarded as having completed unsuccessfully.</p>
    </td>
    <td valign="top" rowspan="1" colspan="1"> 
      "Requesting" or "Fail"</td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">405</td>
    <td valign="top" rowspan="1" colspan="1">Method not allowed</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>Indicates that the peer HTTP server does not support the requested HTTP 
      method at the given request URI. The message exchange is 
      regarded as having completed unsuccessfully.</p></td>
    <td valign="top" rowspan="1" colspan="1">"Fail"</td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">415</td>
    <td valign="top" rowspan="1" colspan="1">Unsupported Media Type</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>Indicates that the peer HTTP server does not support the Content-type used 
      to encode the request message. The message exchange is regarded 
      as having completed unsuccessfully.</p></td>
    <td valign="top" rowspan="1" colspan="1"> 
      "Fail"</td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">5xx</td>
    <td valign="top" rowspan="1" colspan="1">Server Error</td>
    <td valign="top" rowspan="1" colspan="1"> </td>
    <td valign="top" rowspan="1" colspan="1"> </td></tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">500</td>
    <td valign="top" rowspan="1" colspan="1">Internal Server Error</td>
    <td valign="top" rowspan="1" colspan="1">
      <p>Indicates a server problem or a problem with the received request</p></td>
    <td valign="top" rowspan="1" colspan="1"> 
      <p>"Sending+Receiving", "Receiving" or "Fail"</p></td></tr>
</tbody>
</table>

        <p><a href="#tabreqstatereqtrans"><b>Table 17</b></a> refers to
        some but not all of the existing HTTP/1.1 <a href="#RFC2616">[RFC 2616]</a> status codes. In addition to these status codes,
        HTTP provides an open-ended mechanism for supporting status
        codes defined by HTTP extensions (see RFC 2817 <a href="#RFC2817">[RFC 2817]</a>
        for a registration mechanism for new status codes). HTTP status
        codes are divided into status code classes as described in
        HTTP <a href="#RFC2616">[RFC 2616]</a>, section 6.1.1. The SOAP HTTP binding
        follows the rules of any HTTP application which means that an
        implementation of the SOAP HTTP binding must understand the
        class of any status code, as indicated by the first digit, and
        treat any unrecognized response as being equivalent to the x00
        status code of that class, with the exception that an
        unrecognized response must not be cached.</p>

    <div class="note"><p class="prefix"><b>Note:</b></p><p>There may be elements in the HTTP infrastructure
    configured to modify HTTP response entity bodies for
    4xx and 5xx status code responses. For example, some
    HTTP origin servers have such a feature as
    a configuration option. This behavior may interfere with
    the use of 4xx and 5xx status code responses carrying SOAP
    fault messages in HTTP and it is recommended that such behavior
    be disabled for resources accepting SOAP/HTTP requests.
    If the rewriting behavior cannot be disabled, SOAP/HTTP
    cannot be used in such configurations.</p></div>
    
</div>

<div class="div4">
<h5><a name="http-reqbindrecstate"></a>7.5.1.3 Sending+Receiving</h5>
      
  <p>In the "Sending+Receiving" state
  (<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> only), the transmission of the
  request message and receiving of the response message is completed.
  Only in the case that a status code 200 is received, 
  the response message is assumed to contain a SOAP envelope serialized
  according to the rules for carrying SOAP messages in the media type
  given in the Content-Type header field.</p>

  <p>The response MAY be of content type other than
  "application/soap+xml". Such usage is considered
  non-normative, and accordingly is not modeled in the state machine.
  Interpretation of such responses is at the discretion of the
  receiver.
  Similarly, receipt of any response entity-body with a status code of 202
  is not normative.  If such an unexpected response is of type 
  "application/soap+xml", then SOAP processing of that
  response is beyond the scope of the specification for this binding.</p>

</div>

<div class="div4">

    
<h5><a name="http-reqbindrecstate2"></a>7.5.1.4 Receiving</h5>
    
    <p>In the "Receiving" state (<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> only), receiving of the response message is
    completed. Only in the case of status code 200, 
    the response message is assumed to contain a SOAP
    envelope serialized according to the rules for carrying SOAP
    messages in the media type given in the Content-Type header
    field.</p>

    <p>The response MAY be of content type other than
    "application/soap+xml". Such a result is particularly
    likely when a SOAP request sent with a <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>  of
    "GET" is directed (intentionally or otherwise) to a
    non-SOAP HTTP server. Such usage is considered non-normative, and
    accordingly is not modeled in the state machine. Interpretation of
    such responses is at the discretion of the receiver.
    Similarly, receipt of any response entity-body with a status code of 202
  is not normative.  If such an unexpected response is of type 
  "application/soap+xml", then SOAP processing of that
  response is beyond the scope of the specification for this binding.</p>

</div>


<div class="div4">
<h5><a name="http-reqsuccfail"></a>7.5.1.5 Success and Fail</h5>

<p>"Success" and "Fail" are the terminal states of the 
Request-Response and SOAP-Response MEPs. Control over the  
message exchange context returns to the local SOAP node.</p>

<p>If the "success" state has been reached and if a SOAP envelope has been 
received, then the local node is a SOAP Receiver as defined in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> section
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#senderreceiverconcepts">Message Sender and Receiver Concepts</a>, and in particular MUST obey the 
requirement of section
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapnodes">SOAP Nodes</a> to 
process the message according to the SOAP Processing Model (see <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).</p>

</div>

</div>

<div class="div3">
<h4><a name="http-bindrespnode"></a>7.5.2 Behavior of Responding SOAP Node</h4>

<p>The overall flow of the behavior of a responding SOAP node
      follows a state machine description consistent with either <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or
<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> (differences are indicated as necessary). The following subsections describe each state
in detail.</p>

<div class="div4">
<h5><a name="http-respbindreceive"></a>7.5.2.1 Init</h5>

<p>In the "Init" state, the binding waits for
the start of an inbound request message. <a href="#tabresstateinitfaults"><b>Table 18</b></a> describes the errors that a responding
SOAP node might generate while in the "Init" state. In
this state no SOAP message has been received, therefore the SOAP node
cannot generate a SOAP fault.</p>

<a name="tabresstateinitfaults"></a><table border="1">
  <caption>Table 18: Errors generated in the Init state</caption>
  <tbody>
  <tr>
    <th valign="top" rowspan="1" colspan="1">Problem with Message</th>
    <th valign="top" rowspan="1" colspan="1">HTTP Status Code</th>
    <th valign="top" rowspan="1" colspan="1">HTTP Reason Phrase 
      (informative)</th>
  </tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">Malformed Request Message</td>
    <td valign="top" rowspan="1" colspan="1">400</td>
    <td valign="top" rowspan="1" colspan="1">Bad request</td>
  </tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">HTTP Method is neither POST nor GET</td>
    <td valign="top" rowspan="1" colspan="1">405</td>
    <td valign="top" rowspan="1" colspan="1">Method Not Allowed</td>
  </tr>
  <tr>
    <td valign="top" rowspan="1" colspan="1">Unsupported message encapsulation method</td>
    <td valign="top" rowspan="1" colspan="1">415</td>
    <td valign="top" rowspan="1" colspan="1">Unsupported Media</td>
  </tr>
  </tbody>
</table>

</div>

<div class="div4">
<h5><a name="http-respbindprocess"></a>7.5.2.2 Receiving</h5>

<p>In the "Receiving" state, the binding
receives the request and any associated message and waits for the
start of a response message to be available. <a href="#tabresstaterecheads"><b>Table 19</b></a> describes the HTTP response header fields
generated by the responding SOAP node. <a href="#tabresstatereccodes"><b>Table 20</b></a> describes the HTTP status codes associated
with SOAP faults that can be generated by the responding SOAP node.</p>

<a name="tabresstaterecheads"></a><table border="1">
  <caption>Table 19: HTTP Response Headers Fields</caption>
  <tbody>
  <tr>
    <th rowspan="1" colspan="1">Field</th>
    <th rowspan="1" colspan="1">Value</th></tr>
  <tr>
    <td rowspan="1" colspan="1">Status line</td>
    <td rowspan="1" colspan="1"><p>If a SOAP Envelope response is available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>  then 200, or set according to <a href="#tabresstatereccodes"><b>Table 20</b></a> if a SOAP
    fault was generated.  Otherwise, if no such SOAP envelope is provided, then 202.</p></td></tr>
  <tr>
    <td rowspan="1" colspan="1"><p>Content-Type header field</p></td>
    <td rowspan="1" colspan="1"><p>If Status line is 200, then the media type of the response body, see <a href="#http-intro"><b>7.1 Introduction</b></a> for a description of permissible media
    types.  If status line is other than 200, then the Content-Type header is not sent.</p></td>
  </tr>
  <tr>
    <td rowspan="1" colspan="1"><p>Additional header fields</p></td>
    <td rowspan="1" colspan="1"><p>Generated in accordance with the rules for the binding-specific
    expression of any optional features in use for this message
    exchange. For example, a Content-Encoding header field (see HTTP <a href="#RFC2616">[RFC 2616]</a>, section 14.11) may be used to express an optional
    compression feature.</p></td>
  </tr>
  <tr>
    <td rowspan="1" colspan="1">HTTP Entity Body</td>
    <td rowspan="1" colspan="1"><p>Only if status line is 200, the SOAP message serialized according to the rules for carrying SOAP
    messages in the media type given by the Content-Type header field. Rules
    for carrying SOAP messages in "application/soap+xml" are
    given in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>.</p></td>
</tr>
</tbody></table>
       <p> </p>

<a name="tabresstatereccodes"></a><table border="1">
  <caption>Table 20: SOAP Fault to HTTP Status Mapping</caption>
  <tbody>
  <tr>
    <th rowspan="1" colspan="1">SOAP Fault</th>
    <th rowspan="1" colspan="1">HTTP Status Code</th>
    <th rowspan="1" colspan="1">HTTP Reason Phrase (informative)</th></tr>
  <tr>
    <td rowspan="1" colspan="1">env:VersionMismatch</td>
    <td rowspan="1" colspan="1">500</td>
    <td rowspan="1" colspan="1">Internal server error</td></tr>
  <tr>
    <td rowspan="1" colspan="1">env:MustUnderstand</td>
    <td rowspan="1" colspan="1">500</td>
    <td rowspan="1" colspan="1">Internal server error</td></tr>
  <tr>
    <td rowspan="1" colspan="1">env:Sender</td>
    <td rowspan="1" colspan="1">400</td>
    <td rowspan="1" colspan="1">Bad request</td></tr>
  <tr>
    <td rowspan="1" colspan="1">env:Receiver</td>
    <td rowspan="1" colspan="1">500</td>
    <td rowspan="1" colspan="1">Internal server error</td></tr>
  <tr>
    <td rowspan="1" colspan="1">env:DataEncodingUnknown</td>
    <td rowspan="1" colspan="1">500</td>
    <td rowspan="1" colspan="1">Internal server error</td></tr> 
  </tbody></table>
</div>
     
<div class="div4">
<h5><a name="http-respbindrespond"></a>7.5.2.3 Receiving+Sending</h5>

<p>In the "Receiving+Sending" state (<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> only) the binding completes receiving of the
request message and transmission of the response message.</p>
</div>

<div class="div4">
<h5><a name="http-respbindrespond2"></a>7.5.2.4 Sending</h5>

<p>In the "Sending" state (<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> only) the binding completes transmission of the response message.</p>
          
</div>

<div class="div4">
<h5><a name="http-respsuccfail"></a>7.5.2.5 Success and Fail</h5>

<p>"Success" and "Fail" are the terminal states for the 
Request-Response and SOAP-Response MEPs. From the point-of-view of 
the local node this message exchange has completed.</p>

</div>

</div>

</div>


<div class="div2">
<h3><a name="seccond"></a>7.6 Security Considerations</h3>

<p>The SOAP
      HTTP Binding (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>) can be considered as
      an extension of the HTTP application protocol. As such, all of the
      security considerations identified and described in section 15 of
      the HTTP specification <a href="#RFC2616">[RFC 2616]</a>
      apply to the SOAP HTTP Binding in
      addition to those described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
      <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#secconsiderations">Security Considerations</a>.
      Implementors of the SOAP HTTP Binding should
      carefully review this material.</p>
      
</div>

</div>



	

    <div class="div1">
      
<h2><a name="refs"></a>8. References</h2>

      <div class="div2">
	
<h3><a name="refs-norm"></a>8.1 Normative References</h3>

        <dl>

   <dt class="label"><a name="SOAP-PART1"></a>[SOAP Part 1] </dt><dd>
	<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427"><cite>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)</cite></a>, 
	Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,
	Henrik Frystyk Nielsen, Anish Karmarkar, Yves Lafon, Editors.
	World Wide Web Consortium, 27 April 2007.
	This version is http://www.w3.org/TR/2007/REC-soap12-part1-20070427.
	The <a href="http://www.w3.org/TR/soap12-part1/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part1/.</dd>

    <dt class="label"><a name="RFC2616"></a>[RFC 2616] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext 
	Transfer Protocol -- HTTP/1.1</cite></a>, R. Fielding,
 	J. Gettys, J. C. Mogul, H. Frystyk Nielsen, P. Leach, 
	L. Masinter and T. Berners-Lee,
	Editors.
	IETF, June 1999. 
	This RFC is available at http://www.ietf.org/rfc/rfc2616.txt.</dd>

    <dt class="label"><a name="RFC2119"></a>[RFC 2119] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for 
	use in RFCs to Indicate Requirement Levels</cite></a>, S. Bradner, 
	Editor.
	IETF, March 1997.
	This RFC is available at http://www.ietf.org/rfc/rfc2119.txt.</dd>

    <dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Part 1] </dt><dd>
        <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>
	XML Schema Part 1: 
	Structures Second Edition</cite></a>, David Beech, Murray Maloney, 
	Henry S. Thompson, and Noah Mendelsohn, Editors. 
	World Wide Web Consortium, 28 October 2004. 
	This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
	The <a href="http://www.w3.org/TR/xmlschema-1/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-1/.</dd>

    <dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Part 2] </dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>
	XML Schema Part 2:
	Datatypes Second Edition</cite></a>, 
	Ashok Malhotra and Paul V. Biron, Editors. 
	World Wide Web Consortium, 28 October 2004. 
	This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. 
	The <a href="http://www.w3.org/TR/xmlschema-2/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-2/.</dd>

    <dt class="label"><a name="RFC3986"></a>[RFC 3986] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource 
	Identifiers (URI): Generic Syntax</cite></a>, T. Berners-Lee, 
	R. Fielding and L. Masinter, Editors.
	IETF, January 2005. 
	<em>Obsoletes: <span id="RFC2396">RFC 2396</span>, 
	<span id="RFC2732">RFC 2732</span></em>.
	This RFC is available at http://www.ietf.org/rfc/rfc3986.txt.</dd>

    <dt class="label"><a name="XMLNS"></a>[Namespaces in XML] </dt><dd>
	<a href="http://www.w3.org/TR/2006/REC-xml-names-20060816"><cite>
	Namespaces in
	XML (Second Edition)</cite></a>, Tim Bray, Dave Hollander, 
        Andrew Layman, and Richard Tobin, Editors. 
	World Wide Web Consortium, 16 August 2006. 
	This version is http://www.w3.org/TR/2006/REC-xml-names-20060816.
	The <a href="http://www.w3.org/TR/REC-xml-names">latest version</a> is
	available at http://www.w3.org/TR/REC-xml-names.</dd>

    <dt class="label"><a name="XML"></a>[XML 1.0] </dt><dd>
	<a href="http://www.w3.org/TR/2006/REC-xml-20060816"><cite>Extensible
	Markup Language (XML) 1.0 (Fourth Edition)</cite></a>, Jean Paoli,
	Eve Maler, Tim Bray, <em>et. al.</em>, Editors. 
	World Wide Web Consortium, 16 August 2006. 
	This version is http://www.w3.org/TR/2006/REC-xml-20060816. 
	The <a href="http://www.w3.org/TR/REC-xml">latest version</a> is
	available at http://www.w3.org/TR/REC-xml.</dd>

    <dt class="label"><a name="XMLInfoSet"></a>[XML InfoSet] </dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"><cite>XML
	Information Set (Second Edition)</cite></a>, Richard Tobin and 
	John Cowan, Editors. 
	World Wide Web Consortium, 04 February 2004. 
	This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204. 
	The <a href="http://www.w3.org/TR/xml-infoset">latest version</a> is
	available at http://www.w3.org/TR/xml-infoset.</dd>

    <dt class="label"><a name="RFC3023"></a>[RFC 3023] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc3023.txt"><cite>XML Media Types</cite></a>
        M. Murata, S. St.Laurent, D. Kohn, Editors.
        IETF, January 2001.
	This RFC is available at http://www.ietf.org/rfc/rfc3023.txt.</dd>
	
    <dt class="label"><a name="soap-media-type"></a>[RFC 3902] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc3902.txt"><cite>
	The "application/soap+xml" media type</cite></a>, M. Baker, 
	M. Nottingham, Editors.
	IETF, September 2004.
	This RFC is available at http://www.ietf.org/rfc/rfc3902.txt.</dd>

        </dl>

      </div>

      <div class="div2">
 	
<h3><a name="refs-inform"></a>8.2 Informative References</h3>

	<dl>
   <dt class="label"><a name="soap11"></a>[SOAP 1.1] </dt><dd>
	<a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/"><cite>Simple Object
	Access Protocol (SOAP) 1.1</cite></a>, 
	Don Box, David Ehnebuske, Gopal
	Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen,
	Satish Thatte, Dave Winer, Editors.
	DevelopMentor, IBM, Microsoft, Lotus Development Corp., 
        UserLand Software, Inc., 30 July 2003.
	This version is http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.</dd>

   <dt class="label"><a name="SOAP-PART0"></a>[SOAP Part 0] </dt><dd>
	<a href="http://www.w3.org/TR/2007/REC-soap12-part0-20070427"><cite>SOAP Version 1.2 Part 0: Primer (Second Edition)</cite></a>, 
	Nilo Mitra, Yves Lafon, Editors. 
	World Wide Web Consortium, 27 April 2007.
	This version is http://www.w3.org/TR/2007/REC-soap12-part0-20070427.
	The <a href="http://www.w3.org/TR/soap12-part0/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part0/.</dd>


      <dt class="label"><a name="CommentArchive"></a>[XMLP Comments] </dt><dd>XML Protocol Comments Archive  (See <a href="http://lists.w3.org/Archives/Public/xmlp-comments/">http://lists.w3.org/Archives/Public/xmlp-comments/</a>.)</dd>

	  <dt class="label"><a name="DiscussionArchive"></a>[XMLP Dist-App] </dt><dd>XML Protocol Discussion
	    Archive  (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/">http://lists.w3.org/Archives/Public/xml-dist-app/</a>.)</dd>

	  <dt class="label"><a name="XMLPCharter"></a>[XMLP Charter] </dt><dd>XML Protocol Charter  (See <a href="http://www.w3.org/2005/07/XML-Protocol-Charter">http://www.w3.org/2005/07/XML-Protocol-Charter</a>.)</dd>

        <dt class="label"><a name="RFC2045"></a>[RFC 2045] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2045.txt"><cite>
	Multipurpose Internet Mail Extensions (MIME) Part One:
        Format of Internet Message Bodies
	</cite></a>, N. Freed, N. Borenstein, Editors.
	IETF, November 1996. 
	This RFC is available at http://www.ietf.org/rfc/rfc2045.txt.</dd>

        <dt class="label"><a name="RFC2026"></a>[RFC 2026] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2026.txt"><cite>
	The Internet Standards Process -- Revision 3</cite></a>, 
        S. Bradner, Editor.
	IETF, October 1996. 
	This RFC is available at http://www.ietf.org/rfc/rfc2026.txt.</dd>

        <dt class="label"><a name="RFC2817"></a>[RFC 2817] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2817.txt"><cite>
	Upgrading to TLS Within HTTP/1.1</cite></a>, 
        R. Khare, S. Lawrence, Editors.
	IETF, May 2000. 
	This RFC is available at http://www.ietf.org/rfc/rfc2817.txt.</dd>

    <dt class="label"><a name="RFC3987"></a>[RFC 3987] </dt><dd>
	<a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>
	Internationalized Resource Identifiers (IRIs)
	</cite></a>, 
	M. Duerst, Editors.
	IETF, January 2005. 
	This RFC is available at http://www.ietf.org/rfc/rfc3987.txt.</dd>

   <dt class="label"><a name="CharMod"></a>[CharMod] </dt><dd>
	<a href="http://www.w3.org/TR/2005/REC-charmod-20050215/"><cite>
        Character Model for the World Wide Web 1.0: Fundamentals</cite></a>, 
        Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, 
        Tex Texin, Editors. 
	World Wide Web Consortium, 15 February 2005.
	This version is http://www.w3.org/TR/2005/REC-charmod-20050215/.
	The <a href="http://www.w3.org/TR/charmod/">latest version</a> is 
	available at http://www.w3.org/TR/charmod/.</dd>

	</dl>

      </div>

    </div>

  </div>




  <div class="back">

    <div class="div1">
    
<h2><a name="ietf-draft"></a>A. The "application/soap+xml" Media Type</h2>
      
    <p>The original contents of this section have been superceded by RFC3902<a href="#soap-media-type">[RFC 3902]</a>.</p>

	  </div>
    
    
    
    <div class="div1">
      
<h2><a name="namemap"></a>B. Mapping Application-Defined Names to XML Names</h2>
      
	  <p>This appendix details an algorithm for taking an
	  application-defined name, such as the name of a variable or
	  field in a programming language, and mapping it to the Unicode
	  characters that are legal in the names of XML elements and
	  attributes as defined in Namespace in XML <a href="#XMLNS">[Namespaces in XML]</a></p>
	  

      
<h5>Hex Digits</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="hexDigit"></a>[5]   </td><td><code>hexDigit</code></td><td>   ::=   </td><td><code>[0-9A-F]</code></td></tr></tbody></table>

	  <div class="div2">
      
<h3><a name="namemap-rules"></a>B.1 Rules for Mapping Application-Defined Names to XML Names</h3>

      <ol>

        <li><p>An XML Name has two parts: <var>Prefix</var> and
        <var>LocalPart</var>. Let
        <var>Prefix</var> be determined per the rules and constraints
        specified in Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a>.</p></li>

        <li><p>Let <var>T</var> be a name in an application, represented as
		a sequence of characters encoded in a particular character encoding.
		</p>
		</li>

        <li><p>Let <code>M</code> be the implementation-defined function for
		transcoding of the characters used in the application-defined
		name to an equivalent string of Unicode characters.
		</p>
		<div class="note"><p class="prefix"><b>Note:</b></p><p>Ideally, if this transcoding is from a
		non-Unicode encoding, it should be both reversible and Unicode
		Form C normalizing (that is, combining sequences will be in
		the prescribed canonical order). It should be noted that some
		transcodings cannot be perfectly reversible and that Normalization Form C (NFC)
		normalization may alter the original sequence in a few
		cases (see Character Model for the World Wide Web <a href="#CharMod">[CharMod]</a>). To
		ensure that matching names continue to match after mapping,
		Unicode sequences should be normalized using Unicode
		Normalization Form C.
		</p></div>
		<div class="note"><p class="prefix"><b>Note:</b></p><p>This transcoding is explicitly to Unicode
		scalar values ("code points") and not to any particular
		character encoding scheme of Unicode, such as UTF-8 or UTF-16.
		</p></div>
		<div class="note"><p class="prefix"><b>Note:</b></p><p>Note: Properly formed surrogate pair
		sequences must be converted to their respective scalar values
		("code points") [That is, the sequence U+D800 U+DC00 should be
		transcoded to the character U+10000]. If the transcoding
		begins with a Unicode encoding, non-conforming (non-shortest
		form) UTF-8 and UTF-16 sequences must be converted to their
		respective scalar values.
		</p></div>
		<div class="note"><p class="prefix"><b>Note:</b></p><p>The number of characters in <var>T</var> is not
		necessarily the same as the number of characters in <code>M</code>, because
		transcoding may be one-to-many or many-to-one. The details of
		transcoding may be implementation-defined. There may be (very
		rarely) cases where there is no equivalent Unicode
		representation for <var>T</var>; such cases are not covered here.
		</p></div>
		</li>

        <li><p>Let <var>C</var> be the sequence of Unicode
		scalar values (characters) represented by <code>M(T)</code></p>
		</li>

        <li><p>Let <var>N</var> be the number of characters in
		<var>C</var>. Let <var>C</var><sub>1</sub>,
		<var>C</var><sub>2</sub>, ..., <var>C</var><sub>N</sub> be the
		characters of <var>C</var>, in order from most to least
		significant (logical order).</p>
		</li>
		<li>
		<p>For each <var>i</var> between 1 (one) and
		<var>N</var>, let <var>X</var><sub>i</sub> be the Unicode
		character string defined by the following rules:
		</p>

        <p>Case:</p>
        <ol>

          <li><p>If <var>C</var><sub>i</sub> is undefined (that
		  is, some character or sequence of characters as defined in
		  the application's character sequence <var>T</var> contains
		  no mapping to Unicode), then <var>X</var><sub>i</sub> is
		  implementation-defined.</p>
		  </li>

          <li><p>If <var>i</var>&lt;=<var>N</var>-1 and
		  <var>C</var><sub>i</sub> is "_" (U+005F LOW LINE) and
		  <var>C</var><sub>i+1</sub> is "x" (U+0078 LATIN SMALL LETTER
		  X), then let <var>X</var><sub>i</sub> be "_x005F_".
		  </p>
		  </li>

          <li><p>If <var>i</var>=1, and <var>N</var>&gt;=3, and
		  <var>C</var><sub>1</sub> is "x" (U+0078 LATIN
		  SMALL LETTER X) or "X" (U+0058 LATIN CAPITAL
		  LETTER X), and <var>C</var><sub>2</sub> is "m" (U+006D LATIN
		  SMALL LETTER M) or "M" (U+004D LATIN CAPITAL
		  LETTER M), and <var>C</var><sub>3</sub> is "l" (U+006C LATIN
		  SMALL LETTER L) or "L" (U+004C LATIN CAPITAL
		  LETTER L) (in other words, a string three letters or longer
		  starting with the text "xml" or any
		  re-capitalization thereof), 
                  then if <var>C</var><sub>1</sub> is
		  "x" (U+0078 LATIN SMALL LETTER X)
		  then let <var>X</var><sub>1</sub> be
		  "_x0078_"; otherwise, if
		  <var>C</var><sub>1</sub> is "X"
		  (U+0058 LATIN CAPITAL LETTER X) then let
		  <var>X</var><sub>1</sub> be "_x0058_".
		  </p>
		  </li>

          <li><p>If <var>C</var><sub>i</sub> is not a valid XML
		  NCName character (see Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a>) or if
		  <var>i</var>=1 (one) and <var>C</var><sub>1</sub> is not a
		  valid first character of an XML NCName then:</p>

          <p>Let <var>U<sub>1</sub></var>, <var>U<sub>2</sub></var>,
          ... , <var>U<sub>6</sub></var> be the six hex digits
          <b>[PROD: <a href="#hexDigit">5</a>]</b> such
          that <var>C<sub>i</sub></var> is "U+"
          <var>U<sub>1</sub></var> <var>U<sub>2</sub></var>
          ... <var>U<sub>6</sub></var> in the Unicode scalar value.</p>

          <p>Case:</p>

          <ol>

            <li>

              <p>If <var>U<sub>1</sub></var>=0,
              <var>U<sub>2</sub></var>=0, <var>U<sub>3</sub></var>=0, and
              <var>U<sub>4</sub></var>=0, then let
              <var>X<sub>i</sub></var>="_x"
              <var>U<sub>5</sub></var>
              <var>U<sub>6</sub></var> "_".</p>

              <p>This case implies that
              <var>C<sub>i</sub></var> is a character in the Basic
              Multilingual Plane (Plane 0) of Unicode and can be
              wholly represented by a single UTF-16 code point sequence
              U+<var>U<sub>5</sub></var><var>U<sub>6</sub></var>.</p>
            </li>

            <li>

              <p>Otherwise, let <var>X<sub>i</sub></var> be
              "_x" <var>U<sub>1</sub></var>
              <var>U<sub>2</sub></var>
              <var>U<sub>3</sub></var> <var>U<sub>4</sub></var>
              <var>U<sub>5</sub></var>
              <var>U<sub>6</sub></var> "_".</p>
            </li>

          </ol>

          </li>

          <li><p>Otherwise, let <var>X<sub>i</sub></var> be
          <var>M<sub>i</sub></var>. That is, any character in <var>X</var> that is a
          valid character in an XML NCName is simply copied.</p></li>

        </ol>
        </li>


        <li>
          <p>Let <var>LocalPart</var> be the character string
          concatenation of <var>X<sub>1</sub></var>, <var>X<sub>2</sub></var>,
          ... , <var>X<sub>N</sub></var> in order from most to least significant.</p>
        </li>

        <li>
          <p>Let XML Name be the QName per Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a></p>
        </li>

      </ol>
	  </div>
	  <div class="div2">
<h3><a name="namemap-ex"></a>B.2 Examples</h3>

	  <div class="exampleOuter">
	  <div class="exampleInner"><pre>
Hello world -&gt; Hello_x0020_world
Hello_xorld -&gt; Hello_x005F_xorld
Helloworld_ -&gt; Helloworld_

          x -&gt; x
        xml -&gt; _x0078_ml
       -xml -&gt; _x002D_xml
       x-ml -&gt; x-ml

     Ælfred -&gt; Ælfred
   άγνωστος -&gt; άγνωστος
ᜉᜅᜎᜈ        -&gt; _x1709__x1705__x170E__x1708_
ᏙᏚᎥ         -&gt; _x13D9__x13DA__x13A5_
      </pre></div>
	  </div>
	  </div>
    </div>

    <div class="div1">
	  
<h2><a name="encschema"></a>C. Using W3C XML Schema with SOAP Encoding (Non-Normative)</h2>
	  
	  <p>
	  As noted in <a href="#enctypename"><b>3.1.4 Computing the Type Name Property</b></a> SOAP graph nodes are
	  labeled with type names, but conforming processors are not required to perform
	  validation of encoded SOAP messages.</p>

	  <p>These sections
	  describe techniques that can be used when validation with W3C
	  XML schemas is desired for use by SOAP applications. Any errors
	  or faults resulting from such validation are beyond those
	  covered by the normative Recommendation; from the perspective of
	  SOAP, such faults are considered to be application-level
	  failures.
	  </p>	  
	  <div class="div2">
	    
<h3><a name="validmin"></a>C.1 Validating Using the Minimum Schema</h3>
		<p>
		Although W3C XML schemas are conventionally exchanged in the
		form of schema documents (see XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>), the schema
		Recommendation is built on an abstract definition of schemas,
		to which all processors need to conform. The schema
		Recommendation provides that all such schemas include
		definitions for a core set of built in types, such as
		integers, dates, and so on (see XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, 
		<a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#Simple_Type_Definitions">Built-in Simple Type Definition</a>). 
		Thus, it is possible to discuss validation of a SOAP
		message against such a minimal schema, which is the one that
		would result from providing no additional definitions or
		declarations (i.e., no schema document) to a schema processor.
		</p>

		<p>
		The minimal schema provides that any well formed XML document
		will validate, except that where an xsi:type is provided, the
		type named must be built in, and the corresponding element must be
		valid per that type. Thus, validation of a SOAP 1.2 message using a
		minimal schema approximates the behavior of the built-in types
		of SOAP 1.1.
		</p>
	  </div>
	  <div class="div2">
	    
<h3><a name="validenc"></a>C.2 Validating Using the SOAP Encoding Schema</h3>

		<p>
		Validation against the minimal schema (see <a href="#validmin"><b>C.1 Validating Using the Minimum Schema</b></a>) will not succeed where encoded graph nodes
		have multiple inbound edges. This is because
		elements representing such graph nodes will carry <code>id</code> 
		<em>attribute information items</em> which are not legal
		on elements of type "xs:string",
		"xs:integer" etc. The SOAP Encoding of such graphs MAY be validated
		against the <a href="http://www.w3.org/2003/05/soap-encoding">SOAP Encoding schema</a>.
		In order for the encoding to validate, edge labels, and
		hence the
		[local name] and [namespace name] properties of the
		<em>element information items</em>, need to match those
		defined in the SOAP Encoding schema. Validation of the encoded
		graph against the SOAP Encoding schema would result in the
		type name property of the nodes in the graph being assigned
		the relevant type name.
		</p>

	  </div>
	  <div class="div2">
	    
<h3><a name="validschema"></a>C.3 Validating Using More Specific Schemas</h3>

		<p>
		It may be that schemas could be constructed to describe the encoding of
		certain graphs. Validation of the encoded graph against such a schema would
		result in the type name property of the graph nodes being assigned the
		relevant type name.   Such a schema can also supply default or fixed values
		for one or more of the <code>itemType</code> , <code>arraySize</code>  or 
		<code>nodeType</code>  <em>attribute
		information items</em>;  the values of such defaulted attributes affect the
		deserialized graph in the same manner as if the attributes had been
		explicitly supplied in the message.  Errors or inconsistencies thus
		introduced (e.g. if the value of the attribute is erroneous or inappropriate)
		should be reported as application-level errors; faults from the 
		"http://www.w3.org/2003/05/soap-encoding"
		namespace should be reported only if the normative parts of this
		specification are violated.
		</p>

	  </div>
	</div>    

    <div class="div1">
      
<h2><a name="id2279382"></a>D. Acknowledgements (Non-Normative)</h2>

      <p>This document is the work of the W3C XML Protocol Working Group.</p>

      <p>Participants in the Working Group are (at the time of writing, and by
      alphabetical order): Glen Daniels (Sonic Software, formerly of Macromedia),
Vikas Deolaliker (Sonoa Systems, Inc.),
Chris Ferris (IBM, formerly of Sun Microsystems),
Marc Hadley (Sun Microsystems),
David Hull (TIBCO Software, Inc.),
Anish Karmarkar (Oracle),
Yves Lafon (W3C),
Jonathan Marsh (WSO2),
Jeff Mischkinsky (Oracle),
Eric Newcomer (IONA Technologies),
David Orchard (BEA Systems, formerly of Jamcracker),
Seumas Soltysik (IONA Technologies),
Davanum Srinivas (WSO2),
Pete Wenzel (Sun Microsystems, formerly of SeeBeyond).
</p>

      <p>Previous participants were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (webMethods),
Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems),
Philippe Bedu (EDF (Electricite De France)),
Olivier Boudeville (EDF (Electricite De France)),
Carine Bournez (W3C),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus (Novell, Inc.),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
Dave Cleary (webMethods),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (Excelon Corporation),
Ron Daniel (Interwoven),
Doug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning (MITRE Corporation),
Frank DeRose (TIBCO Software, Inc.),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Hewlett Packard),
James Falek (TIBCO Software, Inc.),
David Fallside (IBM),
Eric Fedok (Active Data Exchange),
Daniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Tony Graham (Sun Microsystems),
Mike Greenberg (IONA Technologies),
Rich Greenfield (Library of Congress),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Frederick Hirsch (Zolera Systems),
Gerd Hoelzing (SAP AG),
Erin Hoffmann (Tradia Inc.),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu Limited),
Oisin Hurley (IONA Technologies),
Yin-Leng Husband (Hewlett Packard, formerly of Compaq),
John Ibbotson (IBM),
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
Scott Isaacson (Novell, Inc.),
Kazunori Iwasa (Fujitsu Limited),
Murali Janakiraman (Rogue Wave),
Mario Jeckle (DaimlerChrysler Research and Technology),
Eric Jenkins (Engenia Software),
Mark Jones (AT&amp;T),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Suresh Kodichath (IONA Technologies),
Richard Koo (Vitria Technology Inc.),
Jacek Kopecky (Systinet),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
Michah Lerner (AT&amp;T),
Bob Lojek (Intalio Inc.),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Michael Mahan (Nokia),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
Noah Mendelsohn (IBM, formerly of Lotus Development),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Nilo Mitra (Ericsson),
Ed Mooney (Sun Microsystems),
Jean-Jacques Moreau (Canon),
Dean Moses (Epicentric),
Highland Mary Mountain (Intel),
Don Mullen (TIBCO Software, Inc.),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Cisco Systems),
Masahiko Narita (Fujitsu Limited),
Mark Needleman (Data Research Associates),
Art Nevarez (Novell, Inc.),
Henrik Nielsen (Microsoft Corporation),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
Conleth O'Connell (Vignette),
Kevin Perkins (Compaq),
Doug Purdy (Microsoft Corporation),
Jags Ramnaryan (BEA Systems),
Andreas Riegg (DaimlerChrysler Research and Technology),
Vilhelm Rosenqvist (NCR),
Herve Ruellan (Canon),
Marwan Sabbouh (MITRE Corporation),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (Zolera Systems),
Krishna Sankar (Cisco Systems),
Jeff Schlimmer (Microsoft Corporation),
George Scott (Tradia Inc.),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
Miroslav Simek (Systinet),
Simeon Simeonov (Macromedia),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Anne Thomas Manes (Sun Microsystems),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (webMethods),
Mike Vernal (Microsoft Corporation),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Volker Wiechers (SAP AG),
Stuart Williams (Hewlett Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (MartSoft Corp.).
</p>

<p>The people who have contributed to discussions on
<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
are also gratefully acknowledged.</p>

    </div>

  </div>
</body></html>