1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821 5822 5823 5824 5825 5826 5827 5828 5829 5830 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 5844 5845 5846 5847 5848 5849 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 5870 5871 5872 5873 5874 5875 5876 5877 5878 5879 5880 5881 5882 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 5911 5912 5913 5914 5915 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976 5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 5999 6000 6001 6002 6003 6004 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6018 6019 6020 6021 6022 6023 6024 6025 6026 6027 6028 6029 6030 6031 6032 6033 6034 6035 6036 6037 6038 6039 6040 6041 6042 6043 6044 6045 6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 6067 6068 6069 6070 6071 6072 6073 6074 6075 6076 6077 6078 6079 6080 6081 6082 6083 6084 6085 6086 6087 6088 6089 6090 6091 6092 6093 6094 6095 6096 6097 6098 6099 6100 6101 6102 6103 6104 6105 6106 6107 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 6118 6119 6120 6121 6122 6123 6124 6125 6126 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163 6164 6165 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 6177 6178 6179 6180 6181 6182 6183 6184 6185 6186 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 6199 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6211 6212 6213 6214 6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227 6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6259 6260 6261 6262 6263 6264 6265 6266 6267 6268 6269 6270 6271 6272 6273 6274 6275 6276 6277 6278 6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6295 6296 6297 6298 6299 6300 6301 6302 6303 6304 6305 6306 6307 6308 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6337 6338 6339 6340 6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 6424 6425 6426 6427 6428 6429 6430 6431 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 6482 6483 6484 6485 6486 6487 6488 6489 6490 6491 6492 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 6532 6533 6534 6535 6536 6537 6538 6539 6540 6541 6542 6543 6544 6545 6546 6547 6548 6549 6550 6551 6552 6553 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 6577 6578 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 6596 6597 6598 6599 6600 6601 6602 6603 6604 6605 6606 6607 6608 6609 6610 6611
|
Network Working Group G. Clemm
Request for Comments: 3253 Rational Software
Category: Standards Track J. Amsden
T. Ellison
IBM
C. Kaler
Microsoft
J. Whitehead
U.C. Santa Cruz
March 2002
Versioning Extensions to WebDAV
(Web Distributed Authoring and Versioning)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies a set of methods, headers, and resource types
that define the WebDAV (Web Distributed Authoring and Versioning)
versioning extensions to the HTTP/1.1 protocol. WebDAV versioning
will minimize the complexity of clients that are capable of
interoperating with a variety of versioning repository managers, to
facilitate widespread deployment of applications capable of utilizing
the WebDAV Versioning services. WebDAV versioning includes automatic
versioning for versioning-unaware clients, version history
management, workspace management, baseline management, activity
management, and URL namespace versioning.
Table of Contents
1 Introduction.................................................... 6
1.1 Relationship to WebDAV........................................ 7
1.2 Notational Conventions........................................ 8
1.3 Terms......................................................... 8
1.4 Property Values............................................... 11
1.4.1 Initial Property Value..................................... 11
Clemm, et al. Standards Track [Page 1]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.4.2 Protected Property Value................................... 12
1.4.3 Computed Property Value.................................... 12
1.4.4 Boolean Property Value..................................... 12
1.4.5 DAV:href Property Value.................................... 12
1.5 DAV Namespace XML Elements.................................... 12
1.6 Method Preconditions and Postconditions....................... 12
1.6.1 Example - CHECKOUT request................................. 13
1.7 Clarification of COPY Semantics with Overwrite:T.............. 13
1.8 Versioning Methods and Write Locks............................ 14
2 Basic Versioning Features....................................... 14
2.1 Basic Versioning Packages..................................... 14
2.2 Basic Versioning Semantics.................................... 16
2.2.1 Creating a Version-Controlled Resource..................... 16
2.2.2 Modifying a Version-Controlled Resource.................... 17
2.2.3 Reporting.................................................. 19
3 Version-Control Feature......................................... 20
3.1 Additional Resource Properties................................ 20
3.1.1 DAV:comment................................................ 20
3.1.2 DAV:creator-displayname.................................... 20
3.1.3 DAV:supported-method-set (protected)....................... 20
3.1.4 DAV:supported-live-property-set (protected)................ 21
3.1.5 DAV:supported-report-set (protected)....................... 21
3.2 Version-Controlled Resource Properties........................ 21
3.2.1 DAV:checked-in (protected)................................. 21
3.2.2 DAV:auto-version........................................... 22
3.3 Checked-Out Resource Properties............................... 22
3.3.1 DAV:checked-out (protected)................................ 23
3.3.2 DAV:predecessor-set........................................ 23
3.4 Version Properties............................................ 23
3.4.1 DAV:predecessor-set (protected)............................ 23
3.4.2 DAV:successor-set (computed)............................... 23
3.4.3 DAV:checkout-set (computed)................................ 23
3.4.4 DAV:version-name (protected)............................... 24
3.5 VERSION-CONTROL Method........................................ 24
3.5.1 Example - VERSION-CONTROL.................................. 25
3.6 REPORT Method................................................. 25
3.7 DAV:version-tree Report....................................... 26
3.7.1 Example - DAV:version-tree Report.......................... 27
3.8 DAV:expand-property Report.................................... 29
3.8.1 Example - DAV:expand-property.............................. 30
3.9 Additional OPTIONS Semantics.................................. 31
3.10 Additional PUT Semantics..................................... 31
3.11 Additional PROPFIND Semantics................................ 32
3.12 Additional PROPPATCH Semantics............................... 33
3.13 Additional DELETE Semantics.................................. 33
3.14 Additional COPY Semantics.................................... 34
3.15 Additional MOVE Semantics.................................... 34
3.16 Additional UNLOCK Semantics.................................. 35
Clemm, et al. Standards Track [Page 2]
RFC 3253 Versioning Extensions to WebDAV March 2002
4 Checkout-In-Place Feature....................................... 35
4.1 Additional Version Properties................................. 35
4.1.1 DAV:checkout-fork.......................................... 36
4.1.2 DAV:checkin-fork........................................... 36
4.2 Checked-Out Resource Properties............................... 36
4.2.1 DAV:checkout-fork.......................................... 36
4.2.2 DAV:checkin-fork........................................... 37
4.3 CHECKOUT Method............................................... 37
4.3.1 Example - CHECKOUT......................................... 38
4.4 CHECKIN Method................................................ 38
4.4.1 Example - CHECKIN.......................................... 40
4.5 UNCHECKOUT Method............................................. 40
4.5.1 Example - UNCHECKOUT....................................... 41
4.6 Additional OPTIONS Semantics.................................. 42
5 Version-History Feature......................................... 42
5.1 Version History Properties.................................... 42
5.1.1 DAV:version-set (protected)................................ 42
5.1.2 DAV:root-version (computed)................................ 42
5.2 Additional Version-Controlled Resource Properties............. 42
5.2.1 DAV:version-history (computed)............................. 43
5.3 Additional Version Properties................................. 43
5.3.1 DAV:version-history (computed)............................. 43
5.4 DAV:locate-by-history Report.................................. 43
5.4.1 Example - DAV:locate-by-history Report..................... 44
5.5 Additional OPTIONS Semantics.................................. 45
5.6 Additional DELETE Semantics................................... 46
5.7 Additional COPY Semantics..................................... 46
5.8 Additional MOVE Semantics..................................... 46
5.9 Additional VERSION-CONTROL Semantics.......................... 46
5.10 Additional CHECKIN Semantics................................. 47
6 Workspace Feature............................................... 47
6.1 Workspace Properties.......................................... 48
6.1.1 DAV:workspace-checkout-set (computed)...................... 48
6.2 Additional Resource Properties................................ 48
6.2.1 DAV:workspace (protected).................................. 48
6.3 MKWORKSPACE Method............................................ 48
6.3.1 Example - MKWORKSPACE...................................... 49
6.4 Additional OPTIONS Semantics.................................. 49
6.4.1 Example - OPTIONS.......................................... 51
6.5 Additional DELETE Semantics................................... 51
6.6 Additional MOVE Semantics..................................... 52
6.7 Additional VERSION-CONTROL Semantics.......................... 52
6.7.1 Example - VERSION-CONTROL.................................. 53
7 Update Feature.................................................. 53
7.1 UPDATE Method................................................. 53
7.1.1 Example - UPDATE........................................... 55
7.2 Additional OPTIONS Semantics.................................. 55
8 Label Feature................................................... 56
Clemm, et al. Standards Track [Page 3]
RFC 3253 Versioning Extensions to WebDAV March 2002
8.1 Additional Version Properties................................. 56
8.1.1 DAV:label-name-set (protected)............................. 56
8.2 LABEL Method.................................................. 56
8.2.1 Example - Setting a label.................................. 58
8.3 Label Header.................................................. 58
8.4 Additional OPTIONS Semantics.................................. 59
8.5 Additional GET Semantics...................................... 59
8.6 Additional PROPFIND Semantics................................. 59
8.7 Additional COPY Semantics..................................... 60
8.8 Additional CHECKOUT Semantics................................. 60
8.9 Additional UPDATE Semantics................................... 61
9 Working-Resource Feature........................................ 62
9.1 Additional Version Properties................................. 62
9.1.1 DAV:checkout-fork.......................................... 62
9.1.2 DAV:checkin-fork........................................... 63
9.2 Working Resource Properties................................... 63
9.2.1 DAV:auto-update (protected)................................ 63
9.2.2 DAV:checkout-fork.......................................... 63
9.2.3 DAV:checkin-fork........................................... 63
9.3 CHECKOUT Method (applied to a version)........................ 63
9.3.1 Example - CHECKOUT of a version............................ 65
9.4 CHECKIN Method (applied to a working resource)................ 65
9.4.1 Example - CHECKIN of a working resource.................... 66
9.5 Additional OPTIONS Semantics.................................. 67
9.6 Additional COPY Semantics..................................... 67
9.7 Additional MOVE Semantics..................................... 67
10 Advanced Versioning Features.................................. 67
10.1 Advanced Versioning Packages................................. 68
10.2 Advanced Versioning Terms.................................... 68
11 MERGE Feature................................................. 70
11.1 Additional Checked-Out Resource Properties................... 70
11.1.1 DAV:merge-set............................................. 70
11.1.2 DAV:auto-merge-set........................................ 71
11.2 MERGE Method................................................. 71
11.2.1 Example - MERGE........................................... 74
11.3 DAV:merge-preview Report..................................... 75
11.3.1 Example - DAV:merge-preview Report........................ 76
11.4 Additional OPTIONS Semantics................................. 77
11.5 Additional DELETE Semantics.................................. 77
11.6 Additional CHECKIN Semantics................................. 77
12 Baseline Feature.............................................. 77
12.1 Version-Controlled Configuration Properties.................. 78
12.1.1 DAV:baseline-controlled-collection (protected)............ 78
12.2 Checked-Out Configuration Properties......................... 78
12.2.1 DAV:subbaseline-set....................................... 78
12.3 Baseline Properties.......................................... 78
12.3.1 DAV:baseline-collection (protected)....................... 79
12.3.2 DAV:subbaseline-set (protected)........................... 79
Clemm, et al. Standards Track [Page 4]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.4 Additional Resource Properties............................... 79
12.4.1 DAV:version-controlled-configuration (computed)........... 79
12.5 Additional Workspace Properties.............................. 80
12.5.1 DAV:baseline-controlled-collection-set (computed)......... 80
12.6 BASELINE-CONTROL Method...................................... 80
12.6.1 Example - BASELINE-CONTROL................................ 82
12.7 DAV:compare-baseline Report.................................. 84
12.7.1 Example - DAV:compare-baseline Report..................... 85
12.8 Additional OPTIONS Semantics................................. 86
12.9 Additional MKCOL Semantics................................... 86
12.10 Additional COPY Semantics................................... 86
12.11 Additional CHECKOUT Semantics............................... 86
12.12 Additional CHECKIN Semantics................................ 86
12.13 Additional UPDATE Semantics................................. 87
12.14 Additional MERGE Semantics.................................. 89
13 Activity Feature.............................................. 90
13.1 Activity Properties.......................................... 91
13.1.1 DAV:activity-version-set (computed)....................... 91
13.1.2 DAV:activity-checkout-set (computed)...................... 92
13.1.3 DAV:subactivity-set....................................... 92
13.1.4 DAV:current-workspace-set (computed)...................... 92
13.2 Additional Version Properties................................ 92
13.2.1 DAV:activity-set.......................................... 93
13.3 Additional Checked-Out Resource Properties................... 93
13.3.1 DAV:unreserved............................................ 93
13.3.2 DAV:activity-set.......................................... 93
13.4 Additional Workspace Properties.............................. 93
13.4.1 DAV:current-activity-set.................................. 94
13.5 MKACTIVITY Method............................................ 94
13.5.1 Example - MKACTIVITY...................................... 95
13.6 DAV:latest-activity-version Report........................... 95
13.7 Additional OPTIONS Semantics................................. 96
13.8 Additional DELETE Semantics.................................. 96
13.9 Additional MOVE Semantics.................................... 97
13.10 Additional CHECKOUT Semantics............................... 97
13.10.1 Example - CHECKOUT with an activity...................... 98
13.11 Additional CHECKIN Semantics................................ 99
13.12 Additional MERGE Semantics.................................. 99
14 Version-Controlled-Collection Feature.........................100
14.1 Version-Controlled Collection Properties.....................102
14.1.1 DAV:eclipsed-set (computed)...............................102
14.2 Collection Version Properties................................103
14.2.1 DAV:version-controlled-binding-set (protected)............103
14.3 Additional OPTIONS Semantics.................................103
14.4 Additional DELETE Semantics..................................103
14.5 Additional MKCOL Semantics...................................104
14.6 Additional COPY Semantics....................................104
14.7 Additional MOVE Semantics....................................104
Clemm, et al. Standards Track [Page 5]
RFC 3253 Versioning Extensions to WebDAV March 2002
14.8 Additional VERSION-CONTROL Semantics.........................104
14.9 Additional CHECKOUT Semantics................................105
14.10 Additional CHECKIN Semantics................................105
14.11 Additional UPDATE and MERGE Semantics.......................106
15 Internationalization Considerations...........................106
16 Security Considerations.......................................107
16.1 Auditing and Traceability....................................107
16.2 Increased Need for Access Control............................108
16.3 Security Through Obscurity...................................108
16.4 Denial of Service............................................108
17 IANA Considerations...........................................109
18 Intellectual Property.........................................109
19 Acknowledgements..............................................109
20 References....................................................110
Appendix A - Resource Classification..............................111
A.1 DeltaV-Compliant Unmapped URL.................................111
A.2 DeltaV-Compliant Resource.....................................111
A.3 DeltaV-Compliant Collection...................................112
A.4 Versionable Resource..........................................112
A.5 Version-Controlled Resource...................................112
A.6 Version.......................................................113
A.7 Checked-In Version-Controlled Resource........................113
A.8 Checked-Out Resource..........................................113
A.9 Checked-Out Version-Controlled Resource.......................114
A.10 Working Resource.............................................114
A.11 Version History..............................................114
A.12 Workspace....................................................115
A.13 Activity.....................................................115
A.14 Version-Controlled Collection................................115
A.15 Collection Version...........................................115
A.16 Version-Controlled Configuration.............................116
A.17 Baseline.....................................................116
A.18 Checked-Out Version-Controlled Configuration.................116
Authors' Addresses................................................117
Full Copyright Statement..........................................118
1 Introduction
This document specifies a set of methods, headers, and properties
that define the WebDAV (Web Distributed Authoring and Versioning)
versioning extensions to the HTTP/1.1 protocol. Versioning is
concerned with tracking and accessing the history of important states
of a web resource, such as a standalone web page. The benefits of
versioning in the context of the worldwide web include:
Clemm, et al. Standards Track [Page 6]
RFC 3253 Versioning Extensions to WebDAV March 2002
- A resource has an explicit history and a persistent identity
across the various states it has had during the course of that
history. It allows browsing through past and alternative versions
of a resource. Frequently the modification and authorship history
of a resource is critical information in itself.
- Resource states (versions) are given stable names that can support
externally stored links for annotation and link server support.
Both annotation and link servers frequently need to store stable
references to portions of resources that are not under their
direct control. By providing stable states of resources, version
control systems allow not only stable pointers into those
resources, but also well defined methods to determine the
relationships of those states of a resource.
WebDAV Versioning defines both basic and advanced versioning
functionality.
Basic versioning allows users to:
- Put a resource under version control
- Determine whether a resource is under version control
- Determine whether a resource update will automatically be captured
as a new version
- Create and access distinct versions of a resource
Advanced versioning provides additional functionality for parallel
development and configuration management of sets of web resources.
This document will first define the properties and method semantics
for the basic versioning features, and then define the additional
properties and method semantics for the advanced versioning features.
An implementer that is only interested in basic versioning should
skip the advanced versioning sections (Section 10 to Section 14).
1.1 Relationship to WebDAV
To maximize interoperability and the use of existing protocol
functionality, versioning support is designed as extensions to the
WebDAV protocol [RFC2518], which itself is an extension to the HTTP
protocol [RFC2616]. All method marshalling and postconditions
defined by RFC 2518 and RFC 2616 continue to hold, to ensure that
versioning unaware clients can interoperate successfully with
versioning servers. Although the versioning extensions are designed
to be orthogonal to most aspects of the WebDAV and HTTP protocols, a
clarification to RFC 2518 is required for effective interoperable
versioning. This clarification is described in Section 1.7.
Clemm, et al. Standards Track [Page 7]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.2 Notational Conventions
The key words "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.
The term "protected" is placed in parentheses following the
definition of a protected property (see Section 1.4.2).
The term "computed" is placed in parentheses following the definition
of a computed property (see Section 1.4.3).
When an XML element type in the "DAV:" namespace is referenced in
this document outside of the context of an XML fragment, the string
"DAV:" will be prefixed to the element type.
When a method is defined in this document, a list of preconditions
and postconditions will be defined for that method. If the semantics
of an existing method is being extended, a list of additional
preconditions and postconditions will be defined. A precondition or
postcondition is prefixed by a parenthesized XML element type that
identifies that precondition or postcondition (see Section 1.6).
1.3 Terms
This document uses the terms defined in RFC 2616, in RFC 2518, and in
this section. Section 2.2 defines the semantic versioning model
underlying this terminology.
Version Control, Checked-In, Checked-Out
"Version control" is a set of constraints on how a resource can be
updated. A resource under version control is either in a
"checked-in" or "checked-out" state, and the version control
constraints apply only while the resource is in the checked-in
state.
Versionable Resource
A "versionable resource" is a resource that can be put under
version control.
Version-Controlled Resource
When a versionable resource is put under version control, it
becomes a "version-controlled resource". A version-controlled
resource can be "checked out" to allow modification of its content
or dead properties by standard HTTP and WebDAV methods.
Clemm, et al. Standards Track [Page 8]
RFC 3253 Versioning Extensions to WebDAV March 2002
Checked-Out Resource
A "checked-out resource" is a resource under version control that
is in the checked-out state.
Version Resource
A "version resource", or simply "version", is a resource that
contains a copy of a particular state (content and dead
properties) of a version-controlled resource. A version is
created by "checking in" a checked-out resource. The server
allocates a distinct new URL for each new version, and this URL
will never be used to identify any resource other than that
version. The content and dead properties of a version never
change.
Version History Resource
A "version history resource", or simply "version history", is a
resource that contains all the versions of a particular version-
controlled resource.
Version Name
A "version name" is a string chosen by the server to distinguish
one version of a version history from the other versions of that
version history. Versions from different version histories may
have the same version name.
Predecessor, Successor, Ancestor, Descendant
When a version-controlled resource is checked out and then
subsequently checked in, the version that was checked out becomes
a "predecessor" of the version created by the checkin. A client
can specify multiple predecessors for a new version if the new
version is logically a merge of those predecessors. When a
version is connected to another version by traversing one or more
predecessor relations, it is called an "ancestor" of that version.
The inverse of the predecessor and ancestor relations are the
"successor" and "descendant" relations. Therefore, if X is a
predecessor of Y, then Y is a successor of X, and if X is an
ancestor of Y, then Y is a descendant of X.
Root Version Resource
The "root version resource", or simply "root version", is the
version in a version history that is an ancestor of every other
version in that version history.
Clemm, et al. Standards Track [Page 9]
RFC 3253 Versioning Extensions to WebDAV March 2002
Workspace Resource
A "workspace resource", or simply "workspace", is a collection
that contains at most one version-controlled resource for a given
version history (see Section 6).
Working Resource
A "working resource" is a checked-out resource created by the
server at a server-defined URL when a version (instead of a
version-controlled resource) is checked out. Unlike a checked-out
version-controlled resource, a working resource is deleted when it
is checked in.
Fork, Merge
When a second successor is added to a version, this creates a
"fork" in the version history. When a version is created with
multiple predecessors, this creates a "merge" in the version
history. A server may restrict the version history to be linear
(with no forks or merges), but an interoperable versioning client
should be prepared to deal with both forks and merges in the
version history.
Clemm, et al. Standards Track [Page 10]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates several of the previous
definitions. Each box represents a version and each line between two
boxes represents a predecessor/successor relationship. For example,
it shows V3 is a predecessor of V5, V7 is a successor of V5, V1 is an
ancestor of V4, and V7 is a descendant of V4. It also shows that
there is a fork at version V2 and a merge at version V7.
History of foo.html
+---+
Root Version -------> | | V1
+---+ ^
| |
| |
+---+ |
Version Name ----> V2 | | | Ancestor
+---+ |
/ \ |
/ \ |
+---+ +---+
| | V3 | | V4
^ +---+ +---+
| | | |
Predecessor | | | |
+---+ +---+ |
| | V5 | | V6 | Descendant
+---+ +---+ |
Successor | \ / |
| \ / |
v +---+ v
| | V7
+---+
Label
A "label" is a name that can be used to select a version from a
version history. A label can be assigned by either a client or
the server. The same label can be used in different version
histories.
1.4 Property Values
1.4.1 Initial Property Value
Unless an initial value of a property of a given type is defined by
this document, the initial value of a property of that type is
implementation dependent.
Clemm, et al. Standards Track [Page 11]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.4.2 Protected Property Value
When a property of a specific kind of resource is "protected", the
property value cannot be updated on that kind of resource except by a
method explicitly defined as updating that specific property. In
particular, a protected property cannot be updated with a PROPPATCH
request. Note that a given property can be protected on one kind of
resource, but not protected on another kind of resource.
1.4.3 Computed Property Value
When a property is "computed", its value is defined in terms of a
computation based on the content and other properties of that
resource, or even of some other resource. When the semantics of a
method is defined in this document, the effect of that method on
non-computed properties will be specified; the effect of that method
on computed properties will not be specified, but can be inferred
from the computation defined for those properties. A computed
property is always a protected property.
1.4.4 Boolean Property Value
Some properties take a Boolean value of either "false" or "true".
1.4.5 DAV:href Property Value
The DAV:href XML element is defined in RFC 2518, Section 12.3.
1.5 DAV Namespace XML Elements in Request and Response Bodies
Although WebDAV request and response bodies can be extended by
arbitrary XML elements, which can be ignored by the message
recipient, an XML element in the DAV namespace MUST NOT be used in
the request or response body of a versioning method unless that XML
element is explicitly defined in an IETF RFC.
1.6 Method Preconditions and Postconditions
A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a
method describes the state of the server that must be true after that
method has been completed. If a method precondition or postcondition
for a request is not satisfied, the response status of the request
MUST be either 403 (Forbidden) if the request should not be repeated
because it will always fail, or 409 (Conflict) if it is expected that
the user might be able to resolve the conflict and resubmit the
request.
Clemm, et al. Standards Track [Page 12]
RFC 3253 Versioning Extensions to WebDAV March 2002
In order to allow better client handling of 403 and 409 responses, a
distinct XML element type is associated with each method precondition
and postcondition of a request. When a particular precondition is
not satisfied or a particular postcondition cannot be achieved, the
appropriate XML element MUST be returned as the child of a top-level
DAV:error element in the response body, unless otherwise negotiated
by the request. In a 207 Multi-Status response, the DAV:error
element would appear in the appropriate DAV:responsedescription
element.
1.6.1 Example - CHECKOUT request with DAV:must-be-checked-in response
>>REQUEST
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
>>RESPONSE
HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:must-be-checked-in/>
</D:error>
In this example, the request to CHECKOUT /foo.html fails because
/foo.html is not checked in.
1.7 Clarification of COPY Semantics with Overwrite:T
RFC 2518, Section 8.8.4 states:
"If a resource exists at the destination and the Overwrite header is
"T" then prior to performing the copy the server MUST perform a
DELETE with "Depth: infinity" on the destination resource."
The purpose of this sentence is to ensure that following a COPY, all
destination resources have the same content and dead properties as
the corresponding resources identified by the request-URL (where a
resource with a given name relative to the Destination URL
"corresponds" to a resource with the same name relative to the
request-URL). If at the time of the request, there already is a
resource at the destination that has the same resource type as the
corresponding resource at the request-URL, that resource MUST NOT be
deleted, but MUST be updated to have the content and dead properties
Clemm, et al. Standards Track [Page 13]
RFC 3253 Versioning Extensions to WebDAV March 2002
of its corresponding member. If a client wishes all resources at the
destination to be deleted prior to the COPY, it MUST explicitly issue
a DELETE request.
The difference between updating a resource and replacing a resource
with a new resource is especially important when resource history is
being maintained (the former adds to an existing history, while the
latter creates a new history). In addition, locking and access
control constraints might allow you to update a resource, but not
allow you to delete it and create a new one in its place.
Note that this clarification does not apply to a MOVE request. A
MOVE request with Overwrite:T MUST perform the DELETE with
"Depth:infinity" on the destination resource prior to performing the
MOVE.
1.8 Versioning Methods and Write Locks
If a write-locked resource has a non-computed property defined by
this document, the property value MUST NOT be changed by a request
unless the appropriate lock token is included in the request. Since
every method introduced in this document other than REPORT modifies
at least one property defined by this document, every versioning
method other than REPORT is affected by a write lock. In particular,
the method MUST fail with a 423 (Locked) status if the resource is
write-locked and the appropriate token is not specified in an If
request header.
2 Basic Versioning Features
Each basic versioning feature defines extensions to existing HTTP and
WebDAV methods, as well as new resource types, live properties, and
methods.
2.1 Basic Versioning Packages
A server MAY support any combination of versioning features.
However, in order to minimize the complexity of a WebDAV basic
versioning client, a WebDAV basic versioning server SHOULD support
one of the following three "packages" (feature sets):
- Core-Versioning Package: version-control
- Basic-Server-Workspace Package: version-control, workspace,
version-history, checkout
- Basic-Client-Workspace Package: version-control, working-
resource, update, label
Clemm, et al. Standards Track [Page 14]
RFC 3253 Versioning Extensions to WebDAV March 2002
The core-versioning package supports linear versioning by both
versioning-aware and versioning-unaware clients. A versioning-aware
client can use reports and properties to access previous versions of
a version-controlled resource.
The basic workspace packages support parallel development of
version-controlled resources. Each client has its own configuration
of the shared version-controlled resources, and can make changes to
its configuration without disturbing that of another client.
In the basic-server-workspace package, all persistent state is
maintained on the server. Each client has its own workspace resource
allocated on the server, where each workspace identifies a
configuration of the shared version-controlled resources. Each
client makes changes to its workspace, and can transfer changes when
appropriate from one workspace to another. The server workspace
package is appropriate for clients with no local persistent state, or
for clients that wish to expose their working configurations to other
clients.
In the basic-client-workspace package, each client maintains in local
persistent storage the state for its configuration of the shared
version-controlled resources. When a client is ready to make its
changes visible to other clients, it allocates a set of "working
resources" on the server, updates the content and dead properties of
these working resources, and then uses the set of working resources
to update the version-controlled resources. The working resources
are used, instead of directly updating the version-controlled
resources, so that sets of consistent updates can be prepared in
parallel by multiple clients. Also, a working resource allows a
client to prepare a single update that requires multiple server
requests (e.g. updating both the content and dead properties of a
resource requires both a PUT and a PROPPATCH). The client workspace
package simplifies the server implementation by requiring each client
to maintain its own namespace, but this requires that the clients
have local persistent state, and does not allow clients to expose
their working configurations to other clients.
A server that supports both basic workspace packages will
interoperate with all basic versioning clients.
Clemm, et al. Standards Track [Page 15]
RFC 3253 Versioning Extensions to WebDAV March 2002
2.2 Basic Versioning Semantics
2.2.1 Creating a Version-Controlled Resource
In order to track the history of the content and dead properties of a
versionable resource, a user can put the resource under version
control with a VERSION-CONTROL request. A VERSION-CONTROL request
performs three distinct operations:
1) It creates a new "version history resource". In basic versioning,
a version history resource is not assigned a URL, and hence is not
visible in the http scheme URL space. However, when the version-
history feature (see Section 5) is supported, this changes, and
each version history resource is assigned a new distinct and
unique server-defined URL.
2) It creates a new "version resource" and adds it to the new version
history resource. The body and dead properties of the new version
resource are a copy of those of the versionable resource.
The server assigns the new version resource a new distinct and
unique URL.
3) It converts the versionable resource into a "version-controlled
resource". The version-controlled resource continues to be
identified by the same URL that identified it as a versionable
resource. As part of this conversion, it adds a DAV:checked-in
property, whose value contains the URL of the new version
resource.
Note that a versionable resource and a version-controlled resource
are not new types of resources (i.e. they introduce no new
DAV:resourcetype), but rather they are any type of resource that
supports the methods and live properties defined for them in this
document, in addition to all the methods and live properties implied
by their DAV:resourcetype. For example, a collection (whose
DAV:resourcetype is DAV:collection) is a versionable resource if it
supports the VERSION-CONTROL method, and is a version-controlled
resource if it supports the version-controlled resource methods and
live properties.
In the following example, foo.html is a versionable resource that is
put under version control. After the VERSION-CONTROL request
succeeds, there are two additional resources: a new version history
resource and a new version resource in that version history. The
versionable resource is converted into a version-controlled resource,
whose DAV:checked-in property identifies the new version resource.
Clemm, et al. Standards Track [Page 16]
RFC 3253 Versioning Extensions to WebDAV March 2002
The content and dead properties of a resource are represented by the
symbol appearing inside the box for that resource (e.g., "S1" in the
following example).
===VERSION-CONTROL==>
| +----+ version
| version- | | history
versionable | controlled +----+ resource
resource | resource |
/foo.html | /foo.html |
| v
+----+ | +----+ checked-in +----+ version
| S1 | | | S1 |----------->| S1 | resource
+----+ | +----+ +----+ /his/73/ver/1
Thus, whereas before the VERSION-CONTROL request there was only one,
non-version-controlled resource, after VERSION-CONTROL there are
three separate, distinct resources, each containing its own state and
properties: the version-controlled resource, the version resource,
and the version history resource. Since the version-controlled
resource and the version resource are separate, distinct resources,
when a method is applied to a version-controlled resource, it is only
applied to that version-controlled resource, and is not applied to
the version resource that is currently identified by the
DAV:checked-in property of that version-controlled resource.
Although the content and dead properties of a checked-in version-
controlled resource are required to be the same as those of its
current DAV:checked-in version, its live properties may differ. An
implementation may optimize storage by retrieving the content and
dead properties of a checked-in version-controlled resource from its
current DAV:checked-in version rather than storing them in the
version-controlled resource, but this is just an implementation
optimization.
Normally, a resource is placed under version control with an explicit
VERSION-CONTROL request. A server MAY automatically place every new
versionable resource under version control. In this case, the
resulting state on the server MUST be the same as if the client had
explicitly applied a VERSION-CONTROL request to the versionable
resource.
2.2.2 Modifying a Version-Controlled Resource
In order to use methods like PUT and PROPPATCH to directly modify the
content or dead properties of a version-controlled resource, the
version-controlled resource must first be checked out. When the
checked-out resource is checked in, a new version is created in the
Clemm, et al. Standards Track [Page 17]
RFC 3253 Versioning Extensions to WebDAV March 2002
version history of that version-controlled resource. The version
that was checked out is remembered as the predecessor of the new
version.
The DAV:auto-version property (see Sections 3.2.2) of a checked-in
version-controlled resource determines how it responds to a method
that attempts to modify its content or dead properties. Possible
responses include:
- Fail the request. The resource requires an explicit CHECKOUT
request for it to be modified (see Sections 4 and 9.2.1).
- Automatically checkout the resource, perform the modification, and
automatically checkin the resource. This ensures that every state
of the resource is tracked by the server, but can result in an
excessive number of versions being created.
- Automatically checkout the resource, perform the modification, and
then if the resource is not write-locked, automatically checkin
the resource. If the resource is write-locked, it remains
checked-out until the write-lock is removed (either explicitly
through a subsequent UNLOCK request or implicitly through a time-
out of the write-lock). This helps a locking client avoid the
proliferation of versions, while still allowing a non-locking
client to update the resource.
- Automatically checkout the resource, perform the modification, and
then leave the resource checked out. If the resource is write-
locked, it will be automatically checked in when the write-lock is
removed, but an explicit CHECKIN operation (see Section 4.4) is
required for a non-write-locked resource. This minimizes the
number of new versions that will be created by a versioning
unaware client, but only a versioning aware client can create new
versions of a non-write-locked resource.
- Fail the request unless the resource is write-locked. If it is
write-locked, automatically checkout the resource and perform the
modification. The resource is automatically checked in when the
write-lock is removed. This minimizes the number of new versions
that will be created by a versioning unaware client, but never
automatically checks out a resource that will not subsequently be
automatically checked in.
Clemm, et al. Standards Track [Page 18]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates the effect of the checkout/checkin
process on a version-controlled resource and its version history.
The symbol inside a box (S1, S2, S3) represents the current content
and dead properties of the resource represented by that box. The
symbol next to a box (V1, V2, V3) represents the URL for that
resource.
===checkout==> ===PUT==> ===checkin==>
/foo.html (version-controlled resource)
+----+ | +----+ | +----+ | +----+
| S2 | | | S2 | | | S3 | | | S3 |
+----+ | +----+ | +----+ | +----+
Checked-In=V2|Checked-Out=V2|Checked-Out=V2|Checked-In=V3
/his/73 (version history for /foo.html)
+----+ | +----+ | +----+ | +----+
| S1 | V1 | | S1 | V1 | | S1 | V1 | | S1 | V1
+----+ | +----+ | +----+ | +----+
| | | | | | |
| | | | | | |
+----+ | +----+ | +----+ | +----+
| S2 | V2 | | S2 | V2 | | S2 | V2 | | S2 | V2
+----+ | +----+ | +----+ | +----+
| | | |
| | | |
| | | +----+
| | | | S3 | V3
| | | +----+
Note that a version captures only a defined subset of the state of a
resource. In particular, a version of a basic resource captures its
content and dead properties, but not its live properties.
2.2.3 Reporting
Some versioning information about a resource requires that parameters
be specified along with that request for information. Included in
basic versioning is the required support for an extensible reporting
mechanism, which includes a REPORT method as well as a live property
for determining what reports are supported by a particular resource.
The REPORT method is required by versioning, but it can be used in
non-versioning WebDAV extensions.
Clemm, et al. Standards Track [Page 19]
RFC 3253 Versioning Extensions to WebDAV March 2002
To allow a client to query the properties of all versions in the
version history of a specified version-controlled resource, basic
versioning provides the DAV:version-tree report (see Section 3.7). A
more powerful version history reporting mechanism is provided by
applying the DAV:expand-property report (see Section 3.8) to a
version history resource (see Section 5).
3 Version-Control Feature
The version-control feature provides support for putting a resource
under version control, creating an associated version-controlled
resource and version history resource as described in Section 2.2.1.
A server indicates that it supports the version-control feature by
including the string "version-control" as a field in the DAV header
in the response to an OPTIONS request. The version-control feature
MUST be supported if any other versioning feature is supported.
3.1 Additional Resource Properties
The version-control feature introduces the following REQUIRED
properties for any WebDAV resource.
3.1.1 DAV:comment
This property is used to track a brief comment about a resource that
is suitable for presentation to a user. The DAV:comment of a version
can be used to indicate why that version was created.
<!ELEMENT comment (#PCDATA)>
PCDATA value: string
3.1.2 DAV:creator-displayname
This property contains a description of the creator of the resource
that is suitable for presentation to a user. The DAV:creator-
displayname of a version can be used to indicate who created that
version.
<!ELEMENT creator-displayname (#PCDATA)>
PCDATA value: string
3.1.3 DAV:supported-method-set (protected)
This property identifies the methods that are supported by the
resource. A method is supported by a resource if there is some state
of that resource for which an application of that method will
Clemm, et al. Standards Track [Page 20]
RFC 3253 Versioning Extensions to WebDAV March 2002
successfully satisfy all postconditions of that method, including any
additional postconditions added by the features supported by that
resource.
<!ELEMENT supported-method-set (supported-method*)>
<!ELEMENT supported-method ANY>
<!ATTLIST supported-method name NMTOKEN #REQUIRED>
name value: a method name
3.1.4 DAV:supported-live-property-set (protected)
This property identifies the live properties that are supported by
the resource. A live property is supported by a resource if that
property has the semantics defined for that property. The value of
this property MUST identify all live properties defined by this
document that are supported by the resource, and SHOULD identify all
live properties that are supported by the resource.
<!ELEMENT supported-live-property-set (supported-live-property*)>
<!ELEMENT supported-live-property name>
<!ELEMENT prop ANY>
ANY value: a property element type
3.1.5 DAV:supported-report-set (protected)
This property identifies the reports that are supported by the
resource.
<!ELEMENT supported-report-set (supported-report*)>
<!ELEMENT supported-report report>
<!ELEMENT report ANY>
ANY value: a report element type
3.2 Version-Controlled Resource Properties
The version-control feature introduces the following REQUIRED
properties for a version-controlled resource.
3.2.1 DAV:checked-in (protected)
This property appears on a checked-in version-controlled resource,
and identifies a version that has the same content and dead
properties as the version-controlled resource. This property is
removed when the resource is checked out, and then added back
(identifying a new version) when the resource is checked back in.
<!ELEMENT checked-in (href)>
Clemm, et al. Standards Track [Page 21]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.2.2 DAV:auto-version
If the DAV:auto-version value is DAV:checkout-checkin, when a
modification request (such as PUT/PROPPATCH) is applied to a
checked-in version-controlled resource, the request is automatically
preceded by a checkout and followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when
a modification request is applied to a checked-in version-controlled
resource, the request is automatically preceded by a checkout
operation. If the resource is not write-locked, the request is
automatically followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout, when a modification
request is applied to a checked-in version-controlled resource, the
request is automatically preceded by a checkout operation.
If the DAV:auto-version value is DAV:locked-checkout, when a
modification request is applied to a write-locked checked-in
version-controlled resource, the request is automatically preceded by
a checkout operation.
If an update to a write-locked checked-in resource is automatically
preceded by a checkout of that resource, the checkout is associated
with the write lock. When this write lock is removed (e.g. from an
UNLOCK or a lock timeout), if the resource has not yet been checked
in, the removal of the write lock is automatically preceded by a
checkin operation.
A server MAY refuse to allow the value of the DAV:auto-version
property to be modified, or MAY only support values from a subset of
the valid values.
<!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin
| checkout | locked-checkout)? >
<!ELEMENT checkout-checkin EMPTY>
<!ELEMENT checkout-unlocked-checkin EMPTY>
<!ELEMENT checkout EMPTY>
<!ELEMENT locked-checkout EMPTY>
3.3 Checked-Out Resource Properties
The version-control feature introduces the following REQUIRED
properties for a checked-out resource.
Clemm, et al. Standards Track [Page 22]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.3.1 DAV:checked-out (protected)
This property identifies the version that was identified by the
DAV:checked-in property at the time the resource was checked out.
This property is removed when the resource is checked in.
<!ELEMENT checked-out (href)>
3.3.2 DAV:predecessor-set
This property determines the DAV:predecessor-set property of the
version that results from checking in this resource.
A server MAY reject attempts to modify the DAV:predecessor-set of a
version-controlled resource.
<!ELEMENT predecessor-set (href+)>
3.4 Version Properties
The version-control feature introduces the following REQUIRED
properties for a version.
3.4.1 DAV:predecessor-set (protected)
This property identifies each predecessor of this version. Except
for the root version, which has no predecessors, each version has at
least one predecessor.
<!ELEMENT predecessor-set (href*)>
3.4.2 DAV:successor-set (computed)
This property identifies each version whose DAV:predecessor-set
identifies this version.
<!ELEMENT successor-set (href*)>
3.4.3 DAV:checkout-set (computed)
This property identifies each checked-out resource whose
DAV:checked-out property identifies this version.
<!ELEMENT checkout-set (href*)>
Clemm, et al. Standards Track [Page 23]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.4.4 DAV:version-name (protected)
This property contains a server-defined string that is different for
each version in a given version history. This string is intended for
display for a user, unlike the URL of a version, which is normally
only used by a client and not displayed for a user.
<!ELEMENT version-name (#PCDATA)>
PCDATA value: string
3.5 VERSION-CONTROL Method
A VERSION-CONTROL request can be used to create a version-controlled
resource at the request-URL. It can be applied to a versionable
resource or to a version-controlled resource.
If the request-URL identifies a versionable resource, a new version
history resource is created, a new version is created whose content
and dead properties are copied from the versionable resource, and the
resource is given a DAV:checked-in property that is initialized to
identify this new version.
If the request-URL identifies a version-controlled resource, the
resource just remains under version-control. This allows a client to
be unaware of whether or not a server automatically puts a resource
under version control when it is created.
If a VERSION-CONTROL request fails, the server state preceding the
request MUST be restored.
Marshalling:
If a request body is included, it MUST be a DAV:version-control
XML element.
<!ELEMENT version-control ANY>
If a response body for a successful request is included, it MUST
be a DAV:version-control-response XML element. Note that this
document does not define any elements for the VERSION-CONTROL
response body, but the DAV:version-control-response element is
defined to ensure interoperability between future extensions that
do define elements for the VERSION-CONTROL response body.
<!ELEMENT version-control-response ANY>
Clemm, et al. Standards Track [Page 24]
RFC 3253 Versioning Extensions to WebDAV March 2002
Postconditions:
(DAV:put-under-version-control): If the request-URL identified a
versionable resource at the time of the request, the request MUST
have created a new version history and MUST have created a new
version resource in that version history. The resource MUST have
a DAV:checked-in property that identifies the new version. The
content, dead properties, and DAV:resourcetype of the new version
MUST be the same as those of the resource. Note that an
implementation can choose to locate the version history and
version resources anywhere that it wishes. In particular, it
could locate them on the same host and server as the version-
controlled resource, on a different virtual host maintained by the
same server, on the same host maintained by a different server, or
on a different host maintained by a different server.
(DAV:must-not-change-existing-checked-in-out): If the request-URL
identified a resource already under version control at the time of
the request, the request MUST NOT change the DAV:checked-in or
DAV:checked-out property of that version-controlled resource.
3.5.1 Example - VERSION-CONTROL
>>REQUEST
VERSION-CONTROL /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK
In this example, /foo.html is put under version control. A new
version history is created for it, and a new version is created that
has a copy of the content and dead properties of /foo.html. The
DAV:checked-in property of /foo.html identifies this new version.
3.6 REPORT Method
A REPORT request is an extensible mechanism for obtaining information
about a resource. Unlike a resource property, which has a single
value, the value of a report can depend on additional information
specified in the REPORT request body and in the REPORT request
headers.
Clemm, et al. Standards Track [Page 25]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling:
The body of a REPORT request specifies which report is being
requested, as well as any additional information that will be used
to customize the report.
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed.
The response body for a successful request MUST contain the
requested report.
If a Depth request header is included, the response MUST be a 207
Multi-Status. The request MUST be applied separately to the
collection itself and to all members of the collection that
satisfy the Depth value. The DAV:prop element of a DAV:response
for a given resource MUST contain the requested report for that
resource.
Preconditions:
(DAV:supported-report): The specified report MUST be supported by
the resource identified by the request-URL.
Postconditions:
(DAV:no-modification): The REPORT method MUST NOT have changed the
content or dead properties of any resource.
3.7 DAV:version-tree Report
The DAV:version-tree report describes the requested properties of all
the versions in the version history of a version. If the report is
requested for a version-controlled resource, it is redirected to its
DAV:checked-in or DAV:checked-out version.
The DAV:version-tree report MUST be supported by all version
resources and all version-controlled resources.
Marshalling:
The request body MUST be a DAV:version-tree XML element.
<!ELEMENT version-tree ANY>
ANY value: a sequence of zero or more elements, with at most one
DAV:prop element.
prop: see RFC 2518, Section 12.11
Clemm, et al. Standards Track [Page 26]
RFC 3253 Versioning Extensions to WebDAV March 2002
The response body for a successful request MUST be a
DAV:multistatus XML element.
multistatus: see RFC 2518, Section 12.9
The response body for a successful DAV:version-tree REPORT request
MUST contain a DAV:response element for each version in the
version history of the version identified by the request-URL.
3.7.1 Example - DAV:version-tree Report
The version history drawn below would produce the following version
tree report.
foo.html History
+---+
| | V1
+---+
/ \
/ \
+---+ +---+
| | V2 | | V2.1.1
+---+ +---+
>>REQUEST
REPORT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:version-tree xmlns:D="DAV:">
<D:prop>
<D:version-name/>
<D:creator-displayname/>
<D:successor-set/>
</D:prop>
</D:version-tree>
Clemm, et al. Standards Track [Page 27]
RFC 3253 Versioning Extensions to WebDAV March 2002
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V1</D:href>
<D:propstat>
<D:prop>
<D:version-name>V1</D:version-name>
<D:creator-displayname>Fred</D:creator-displayname>
<D:successor-set>
<D:href>http://repo.webdav.org/his/23/ver/V2</D:href>
<D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href>
</D:successor-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V2</D:href>
<D:propstat>
<D:prop>
<D:version-name>V2</D:version-name>
<D:creator-displayname>Fred</D:creator-displayname>
<D:successor-set/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href>
<D:propstat>
<D:prop>
<D:version-name>V2.1.1</D:version-name>
<D:creator-displayname>Sally</D:creator-displayname>
<D:successor-set/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Clemm, et al. Standards Track [Page 28]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.8 DAV:expand-property Report
Many property values are defined as a DAV:href, or a set of DAV:href
elements. The DAV:expand-property report provides a mechanism for
retrieving in one request the properties from the resources
identified by those DAV:href elements. This report not only
decreases the number of requests required, but also allows the server
to minimize the number of separate read transactions required on the
underlying versioning store.
The DAV:expand-property report SHOULD be supported by all resources
that support the REPORT method.
Marshalling:
The request body MUST be a DAV:expand-property XML element.
<!ELEMENT expand-property (property*)>
<!ELEMENT property (property*)>
<!ATTLIST property name NMTOKEN #REQUIRED>
name value: a property element type
<!ATTLIST property namespace NMTOKEN "DAV:">
namespace value: an XML namespace
The response body for a successful request MUST be a
DAV:multistatus XML element.
multistatus: see RFC 2518, Section 12.9
The properties reported in the DAV:prop elements of the
DAV:multistatus element MUST be those identified by the
DAV:property elements in the DAV:expand-property element. If
there are DAV:property elements nested within a DAV:property
element, then every DAV:href in the value of the corresponding
property is replaced by a DAV:response element whose DAV:prop
elements report the values of the properties identified by the
nested DAV:property elements. The nested DAV:property elements
can in turn contain DAV:property elements, so that multiple levels
of DAV:href expansion can be requested.
Note that a validating parser MUST be aware that the DAV:expand-
property report effectively modifies the DTD of every property by
replacing every occurrence of "href" in the DTD with "href |
response".
Clemm, et al. Standards Track [Page 29]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.8.1 Example - DAV:expand-property
This example describes how to query a version-controlled resource to
determine the DAV:creator-display-name and DAV:activity-set of every
version in the version history of that version-controlled resource.
This example assumes that the server supports the version-history
feature (see Section 5).
>>REQUEST
REPORT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:expand-property xmlns:D="DAV:">
<D:property name="version-history">
<D:property name="version-set">
<D:property name="creator-displayname"/>
<D:property name="activity-set"/>
</D:property>
</D:property>
</D:expand-property>
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/foo.html</D:href>
<D:propstat>
<D:prop>
<D:version-history>
<D:response>
<D:href>http://repo.webdav.org/his/23</D:href>
<D:propstat>
<D:prop>
<D:version-set>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/1</D:href>
<D:propstat>
<D:prop>
<D:creator-displayname>Fred</D:creator-displayname>
Clemm, et al. Standards Track [Page 30]
RFC 3253 Versioning Extensions to WebDAV March 2002
<D:activity-set> <D:href>
http://www.webdav.org/ws/dev/sally
</D:href> </D:activity-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/2</D:href>
<D:propstat>
<D:prop>
<D:creator-displayname>Sally</D:creator-displayname>
<D:activity-set>
<D:href>http://repo.webdav.org/act/add-refresh-cmd</D:href>
</D:activity-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:version-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:version-history> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:multistatus>
In this example, the DAV:creator-displayname and DAV:activity-set
properties of the versions in the DAV:version-set of the
DAV:version-history of http://www.webdav.org/foo.html are reported.
3.9 Additional OPTIONS Semantics
If the server supports the version-control feature, it MUST include
"version-control" as a field in the DAV response header from an
OPTIONS request on any resource that supports any versioning
properties, reports, or methods.
3.10 Additional PUT Semantics
Additional Preconditions:
(DAV:cannot-modify-version-controlled-content): If the request-URL
identifies a resource with a DAV:checked-in property, the request
MUST fail unless DAV:auto-version semantics will automatically
check out the resource.
(DAV:cannot-modify-version): If the request-URL identifies a
version, the request MUST fail.
Clemm, et al. Standards Track [Page 31]
RFC 3253 Versioning Extensions to WebDAV March 2002
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
Additional Postconditions:
(DAV:auto-checkout): If the resource was a checked-in version-
controlled resource whose DAV:auto-version property indicates it
should be automatically checked out but not automatically checked
in for a modification request, then the server MUST have
automatically checked out the resource prior to executing the
request. In particular, the value of the DAV:checked-out property
of the resource MUST be that of the DAV:checked-in property prior
to the request, the DAV:checked-in property MUST have been
removed, and the DAV:predecessor-set property MUST be initialized
to be the same as the DAV:checked-out property. If any part of
the checkout/update sequence failed, the status from the failed
part of the request MUST be returned, and the server state
preceding the request sequence MUST be restored.
(DAV:auto-checkout-checkin): If the resource was a checked-in
version-controlled resource whose DAV:auto-version property
indicates it should be automatically checked out and automatically
checked in for a modification request, then the server MUST have
automatically checked out the resource prior to executing the
request and automatically checked it in after the request. In
particular, the DAV:checked-in property of the resource MUST
identify a new version whose content and dead properties are the
same as those of the resource. The DAV:predecessor-set of the new
version MUST identify the version identified by the DAV:checked-in
property prior to the request. If any part of the
checkout/update/checkin sequence failed, the status from the
failed part of the request MUST be returned, and the server state
preceding the request sequence MUST be restored.
If the request creates a new resource, the new resource MAY have
automatically been placed under version control, and all
postconditions for VERSION-CONTROL apply to the request.
3.11 Additional PROPFIND Semantics
A DAV:allprop PROPFIND request SHOULD NOT return any of the
properties defined by this document. This allows a versioning server
to perform efficiently when a naive client, which does not understand
the cost of asking a server to compute all possible live properties,
issues a DAV:allprop PROPFIND request.
Clemm, et al. Standards Track [Page 32]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions:
(DAV:supported-live-property): If the request attempts to access a
property defined by this document, the semantics of that property
MUST be supported by the server.
3.12 Additional PROPPATCH Semantics
Additional Preconditions:
(DAV:cannot-modify-version-controlled-property): If the request
attempts to modify a dead property, same semantics as PUT (see
Section 3.10).
(DAV:cannot-modify-version): If the request attempts to modify a
dead property, same semantics as PUT (see Section 3.10).
(DAV:cannot-modify-protected-property): An attempt to modify a
property that is defined by this document, as being protected for
that kind of resource, MUST fail.
(DAV:supported-live-property): An attempt to modify a property
defined by this document, but whose semantics are not enforced by
the server, MUST fail. This helps ensure that a client will be
notified when it is trying to use a property whose semantics are
not supported by the server.
Additional Postconditions:
(DAV:auto-checkout): If the request modified a dead property, same
semantics as PUT (see Section 3.10).
(DAV:auto-checkout-checkin): If the request modified a dead
property, same semantics as PUT (see Section 3.10).
3.13 Additional DELETE Semantics
Additional Preconditions:
(DAV:no-version-delete): A server MAY fail an attempt to DELETE a
version.
Additional Postconditions:
(DAV:update-predecessor-set): If a version was deleted, the server
MUST have replaced any reference to that version in a
DAV:predecessor-set by a copy of the DAV:predecessor-set of the
deleted version.
Clemm, et al. Standards Track [Page 33]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.14 Additional COPY Semantics
Additional Preconditions:
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
Additional Postconditions:
(DAV:must-not-copy-versioning-property): A property defined by
this document MUST NOT have been copied to the new resource
created by this request, but instead that property of the new
resource MUST have the default initial value it would have had if
the new resource had been created by a non-versioning method such
as PUT or a MKCOL.
(DAV:auto-checkout): If the destination is a version-controlled
resource, same semantics as PUT (see Section 3.10).
(DAV:auto-checkout-checkin): If the destination is a version-
controlled resource, same semantics as PUT (see Section 3.10).
(DAV:copy-creates-new-resource): If the source of a COPY is a
version-controlled resource or version, and if there is no
resource at the destination of the COPY, then the COPY creates a
new non-version-controlled resource at the destination of the
COPY. The new resource MAY automatically be put under version
control, but the resulting version-controlled resource MUST be
associated with a new version history created for that new
version-controlled resource, and all postconditions for
VERSION-CONTROL apply to the request.
3.15 Additional MOVE Semantics
Additional Preconditions:
(DAV:cannot-rename-version): If the request-URL identifies a
version, the request MUST fail.
Additional Postconditions:
(DAV:preserve-versioning-properties): When a resource is moved
from a source URL to a destination URL, a property defined by this
document MUST have the same value at the destination URL as it had
at the source URL.
Clemm, et al. Standards Track [Page 34]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.16 Additional UNLOCK Semantics
Note that these semantics apply both to an explicit UNLOCK request,
as well as to the removal of a lock because of a lock timeout. If a
precondition or postcondition cannot be satisfied, the lock timeout
MUST NOT occur.
Additional Preconditions:
(DAV:version-history-is-tree): If the request-URL identifies a
checked-out version-controlled resource that will be automatically
checked in when the lock is removed, then the versions identified
by the DAV:predecessor-set of the checked-out resource MUST be
descendants of the root version of the version history for the
DAV:checked-out version.
Additional Postconditions:
(DAV:auto-checkin): If the request-URL identified a checked-out
version-controlled resource that had been automatically checked
out because of its DAV:auto-version property, the request MUST
have created a new version in the version history of the
DAV:checked-out version. The request MUST have allocated a URL
for the version that MUST NOT have previously identified any other
resource, and MUST NOT ever identify a resource other than this
version. The content, dead properties, DAV:resourcetype, and
DAV:predecessor-set of the new version MUST be copied from the
checked-out resource. The DAV:version-name of the new version
MUST be set to a server-defined value distinct from all other
DAV:version-name values of other versions in the same version
history. The request MUST have removed the DAV:checked-out
property of the version-controlled resource, and MUST have added a
DAV:checked-in property that identifies the new version.
4 CHECKOUT-IN-PLACE FEATURE
With the version-control feature, WebDAV locking can be used to avoid
the proliferation of versions that would result if every modification
to a version-controlled resource produced a new version. The
checkout-in-place feature provides an alternative mechanism that
allows a client to explicitly check out and check in a resource to
create a new version.
4.1 Additional Version Properties
The checkout-in-place feature introduces the following REQUIRED
properties for a version.
Clemm, et al. Standards Track [Page 35]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.1.1 DAV:checkout-fork
This property controls the behavior of CHECKOUT when a version
already is checked out or has a successor. If the DAV:checkout-fork
of a version is DAV:forbidden, a CHECKOUT request MUST fail if it
would result in that version appearing in the DAV:predecessor-set or
DAV:checked-out property of more than one version or checked-out
resource. If DAV:checkout-fork is DAV:discouraged, such a CHECKOUT
request MUST fail unless DAV:fork-ok is specified in the CHECKOUT
request body.
A server MAY reject attempts to modify the DAV:checkout-fork of a
version.
<!ELEMENT checkout-fork ANY>
ANY value: A sequence of elements with at most one DAV:discouraged
or DAV:forbidden element.
<!ELEMENT discouraged EMPTY>
<!ELEMENT forbidden EMPTY>
4.1.2 DAV:checkin-fork
This property controls the behavior of CHECKIN when a version already
has a successor. If the DAV:checkin-fork of a version is
DAV:forbidden, a CHECKIN request MUST fail if it would result in that
version appearing in the DAV:predecessor-set of more than one
version. If DAV:checkin-fork is DAV:discouraged, such a CHECKIN
request MUST fail unless DAV:fork-ok is specified in the CHECKIN
request body.
A server MAY reject attempts to modify the DAV:checkout-fork of a
version.
<!ELEMENT checkin-fork ANY>
ANY value: A sequence of elements with at most one DAV:discouraged
or DAV:forbidden element.
<!ELEMENT discouraged EMPTY>
<!ELEMENT forbidden EMPTY>
4.2 Checked-Out Resource Properties
The checkout-in-place feature introduces the following REQUIRED
properties for a checked-out resource.
4.2.1 DAV:checkout-fork
This property determines the DAV:checkout-fork property of the
version that results from checking in this resource.
Clemm, et al. Standards Track [Page 36]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.2.2 DAV:checkin-fork
This property determines the DAV:checkin-fork property of the version
that results from checking in this resource.
4.3 CHECKOUT Method (applied to a version-controlled resource)
A CHECKOUT request can be applied to a checked-in version-controlled
resource to allow modifications to the content and dead properties of
that version-controlled resource.
If a CHECKOUT request fails, the server state preceding the request
MUST be restored.
Marshalling:
If a request body is included, it MUST be a DAV:checkout XML
element.
<!ELEMENT checkout ANY>
ANY value: A sequence of elements with at most one DAV:fork-ok
element.
<!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included, it MUST
be a DAV:checkout-response XML element.
<!ELEMENT checkout-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:must-be-checked-in): If a version-controlled resource is
being checked out, it MUST have a DAV:checked-in property.
(DAV:checkout-of-version-with-descendant-is-forbidden): If the
DAV:checkout-fork property of the version being checked out is
DAV:forbidden, the request MUST fail if a version identifies that
version in its DAV:predecessor-set.
(DAV:checkout-of-version-with-descendant-is-discouraged): If the
DAV:checkout-fork property of the version being checked out is
DAV:discouraged, the request MUST fail if a version identifies
that version in its DAV:predecessor-set unless DAV:fork-ok is
specified in the request body.
Clemm, et al. Standards Track [Page 37]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:checkout-of-checked-out-version-is-forbidden): If the
DAV:checkout-fork property of the version being checked out is
DAV:forbidden, the request MUST fail if a checked-out resource
identifies that version in its DAV:checked-out property.
(DAV:checkout-of-checked-out-version-is-discouraged): If the
DAV:checkout-fork property of the version being checked out is
DAV:discouraged, the request MUST fail if a checked-out resource
identifies that version in its DAV:checked-out property unless
DAV:fork-ok is specified in the request body.
Postconditions:
(DAV:is-checked-out): The checked-out resource MUST have a
DAV:checked-out property that identifies the DAV:checked-in
version preceding the checkout. The version-controlled resource
MUST NOT have a DAV:checked-in property.
(DAV:initialize-predecessor-set): The DAV:predecessor-set property
of the checked-out resource MUST be initialized to be the
DAV:checked-out version.
4.3.1 Example - CHECKOUT of a version-controlled resource
>>REQUEST
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
In this example, the version-controlled resource /foo.html is checked
out.
4.4 CHECKIN Method (applied to a version-controlled resource)
A CHECKIN request can be applied to a checked-out version-controlled
resource to produce a new version whose content and dead properties
are copied from the checked-out resource.
If a CHECKIN request fails, the server state preceding the request
MUST be restored.
Clemm, et al. Standards Track [Page 38]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling:
If a request body is included, it MUST be a DAV:checkin XML
element.
<!ELEMENT checkin ANY>
ANY value: A sequence of elements with at most one
DAV:keep-checked-out element and at most one DAV:fork-ok element.
<!ELEMENT keep-checked-out EMPTY>
<!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included, it MUST
be a DAV:checkin-response XML element.
<!ELEMENT checkin-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:must-be-checked-out): The request-URL MUST identify a
resource with a DAV:checked-out property.
(DAV:version-history-is-tree) The versions identified by the
DAV:predecessor-set of the checked-out resource MUST be
descendants of the root version of the version history for the
DAV:checked-out version.
(DAV:checkin-fork-forbidden): A CHECKIN request MUST fail if it
would cause a version whose DAV:checkin-fork is DAV:forbidden to
appear in the DAV:predecessor-set of more than one version.
(DAV:checkin-fork-discouraged): A CHECKIN request MUST fail if it
would cause a version whose DAV:checkin-fork is DAV:discouraged to
appear in the DAV:predecessor-set of more than one version, unless
DAV:fork-ok is specified in the request body.
Postconditions:
(DAV:create-version): The request MUST have created a new version
in the version history of the DAV:checked-out version. The
request MUST have allocated a distinct new URL for the new
Clemm, et al. Standards Track [Page 39]
RFC 3253 Versioning Extensions to WebDAV March 2002
version, and that URL MUST NOT ever identify any resource other
than that version. The URL for the new version MUST be returned in
a Location response header.
(DAV:initialize-version-content-and-properties): The content, dead
properties, DAV:resourcetype, and DAV:predecessor-set of the new
version MUST be copied from the checked-out resource. The
DAV:version-name of the new version MUST be set to a server-
defined value distinct from all other DAV:version-name values of
other versions in the same version history.
(DAV:checked-in): If the request-URL identifies a version-
controlled resource and DAV:keep-checked-out is not specified in
the request body, the DAV:checked-out property of the version-
controlled resource MUST have been removed and a DAV:checked-in
property that identifies the new version MUST have been added.
(DAV:keep-checked-out): If DAV:keep-checked-out is specified in
the request body, the DAV:checked-out property of the checked-out
resource MUST have been updated to identify the new version.
4.4.1 Example - CHECKIN
>>REQUEST
CHECKIN /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created
Location: http://repo.webdav.org/his/23/ver/32
Cache-Control: no-cache
In this example, version-controlled resource /foo.html is checked in,
and a new version is created at http://repo.webdav.org/his/23/ver/32.
4.5 UNCHECKOUT Method
An UNCHECKOUT request can be applied to a checked-out version-
controlled resource to cancel the CHECKOUT and restore the pre-
CHECKOUT state of the version-controlled resource.
If an UNCHECKOUT request fails, the server MUST undo any partial
effects of the UNCHECKOUT request.
Clemm, et al. Standards Track [Page 40]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling:
If a request body is included, it MUST be a DAV:uncheckout XML
element.
<!ELEMENT uncheckout ANY>
If a response body for a successful request is included, it MUST
be a DAV:uncheckout-response XML element.
<!ELEMENT uncheckout-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:must-be-checked-out-version-controlled-resource): The
request-URL MUST identify a version-controlled resource with a
DAV:checked-out property.
Postconditions:
(DAV:cancel-checked-out): The value of the DAV:checked-in property
is that of the DAV:checked-out property prior to the request, and
the DAV:checked-out property has been removed.
(DAV:restore-content-and-dead-properties): The content and dead
properties of the version-controlled resource are copies of its
DAV:checked-in version.
4.5.1 Example - UNCHECKOUT
>>REQUEST
UNCHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
In this example, the content and dead properties of the version-
controlled resource identified by http://www.webdav.org/foo.html are
restored to their values preceding the most recent CHECKOUT of that
version-controlled resource.
Clemm, et al. Standards Track [Page 41]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.6 Additional OPTIONS Semantics
If a server supports the checkout-in-place feature, it MUST include
"checkout-in-place" as a field in the DAV response header from an
OPTIONS request on any resource that supports any versioning
properties, reports, or methods.
5 Version-History Feature
It is often useful to have access to a version history even after all
version-controlled resources for that version history have been
deleted. A server can provide this functionality by supporting
version history resources. A version history resource is a resource
that exists in a server defined namespace and therefore is unaffected
by any deletion or movement of version-controlled resources. A
version history resource is an appropriate place to add a property
that logically applies to all states of a resource. The DAV:expand-
property report (see Section 3.8) can be applied to the DAV:version-
set of a version history resource to provide a variety of useful
reports on all versions in that version history.
5.1 Version History Properties
The DAV:resourcetype of a version history MUST be DAV:version-
history.
The version-history feature introduces the following REQUIRED
properties for a version history.
5.1.1 DAV:version-set (protected)
This property identifies each version of this version history.
<!ELEMENT version-set (href+)>
5.1.2 DAV:root-version (computed)
This property identifies the root version of this version history.
<!ELEMENT root-version (href)>
5.2 Additional Version-Controlled Resource Properties
The version-history feature introduces the following REQUIRED
property for a version-controlled resource.
Clemm, et al. Standards Track [Page 42]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.2.1 DAV:version-history (computed)
This property identifies the version history resource for the
DAV:checked-in or DAV:checked-out version of this version-controlled
resource.
<!ELEMENT version-history (href)>
5.3 Additional Version Properties
The version-history feature introduces the following REQUIRED
property for a version.
5.3.1 DAV:version-history (computed)
This property identifies the version history that contains this
version.
<!ELEMENT version-history (href)>
5.4 DAV:locate-by-history Report
Many properties identify a version from some version history. It is
often useful to be able to efficiently locate a version-controlled
resource for that version history. The DAV:locate-by-history report
can be applied to a collection to locate the collection member that
is a version-controlled resource for a specified version history
resource.
Marshalling:
The request body MUST be a DAV:locate-by-history XML element.
<!ELEMENT locate-by-history (version-history-set, prop)>
<!ELEMENT version-history-set (href+)>
prop: see RFC 2518, Section 12.11
The response body for a successful request MUST be a
DAV:multistatus XML element containing every version-controlled
resource that is a member of the collection identified by the
request-URL, and whose DAV:version-history property identifies one
of the version history resources identified by the request body.
The DAV:prop element in the request body identifies which
properties should be reported in the DAV:prop elements in the
response body.
Clemm, et al. Standards Track [Page 43]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
(DAV:must-be-version-history): Each member of the DAV:version-
history-set element in the request body MUST identify a version
history resource.
5.4.1 Example - DAV:locate-by-history Report
>>REQUEST
REPORT /ws/public HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:locate-by-history xmlns:D="DAV:">
<D:version-history-set>
<D:href>http://repo.webdav.org/his/23</D:href>
<D:href>http://repo.webdav.org/his/84</D:href>
<D:href>http://repo.webdav.org/his/129</D:href>
<D:version-history-set/>
<D:prop>
</D:version-history>
</D:prop>
</D:locate-by-history>
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/ws/public/x/test.html</D:href>
<D:propstat>
<D:prop>
<D:version-history>
<D:href>http://repo.webdav.org/his/23</D:href>
</D:version-history>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Clemm, et al. Standards Track [Page 44]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, there is only one version-controlled member of
/ws/public that is a version-controlled resource for one of the three
specified version history resources. In particular,
/ws/public/x/test.html is the version-controlled resource for
http://repo.webdav.org/his/23.
5.5 Additional OPTIONS Semantics
If the server supports the version-history feature, it MUST include
"version-history" as a field in the DAV response header from an
OPTIONS request on any resource that supports any versioning
properties, reports, or methods.
A DAV:version-history-collection-set element MAY be included in the
request body to identify collections that may contain version history
resources.
Additional Marshalling:
If an XML request body is included, it MUST be a DAV:options XML
element.
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:version-history-collection-set element.
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:version-history-collection-set element.
<!ELEMENT version-history-collection-set (href*)>
If DAV:version-history-collection-set is included in the request
body, the response body for a successful request MUST contain a
DAV:version-history-collection-set element identifying collections
that may contain version histories. An identified collection MAY
be the root collection of a tree of collections, all of which may
contain version histories. Since different servers can control
different parts of the URL namespace, different resources on the
same host MAY have different DAV:version-history-collection-set
values. The identified collections MAY be located on different
hosts from the resource.
Clemm, et al. Standards Track [Page 45]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.6 Additional DELETE Semantics
Additional Postconditions:
(DAV:delete-version-set): If the request deleted a version
history, the request MUST have deleted all versions in the
DAV:version-set of that version history, and MUST have satisfied
the postconditions for version deletion (see Section 3.13).
(DAV:version-history-has-root): If the request deleted the root
version of a version history, the request MUST have updated the
DAV:root-version of the version history to refer to another
version that is an ancestor of all other remaining versions in
that version history. A result of this postcondition is that
every version history will have at least one version, and the only
way to delete all versions is to delete the version history
resource.
5.7 Additional COPY Semantics
Additional Preconditions:
(DAV:cannot-copy-history): If the request-URL identifies a version
history, the request MUST fail. In order to create another
version history whose versions have the same content and dead
properties, the appropriate sequence of VERSION-CONTROL, CHECKOUT,
PUT, PROPPATCH, and CHECKIN requests must be made.
5.8 Additional MOVE Semantics
Additional Preconditions:
(DAV:cannot-rename-history): If the request-URL identifies a
version history, the request MUST fail.
5.9 Additional VERSION-CONTROL Semantics
Additional Postconditions:
(DAV:new-version-history): If the request created a new version
history, the request MUST have allocated a new server-defined URL
for that version history that MUST NOT have previously identified
any other resource, and MUST NOT ever identify a resource other
than this version history.
Clemm, et al. Standards Track [Page 46]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.10 Additional CHECKIN Semantics
Additional Postconditions:
(DAV:add-to-history): A URL for the new version resource MUST have
been added to the DAV:version-set of the version history of the
DAV:checked-out version.
6 Workspace Feature
In order to allow multiple users to work concurrently on adding
versions to the same version history, it is necessary to allocate on
the server multiple checked-out resources for the same version
history. Even if only one user is making changes to a resource, that
user will sometimes wish to create a "private" version, and then to
expose that version at a later time. One way to provide this
functionality depends on the client keeping track of its current set
of checked-out resources. This is the working-resource feature
defined in Section 8. The other way to provide this functionality
avoids the need for persistent state on the client, and instead has
the server maintain a human meaningful namespace for related sets of
checked-out resources. This is the workspace feature defined in this
section.
The workspace feature introduces a "workspace resource". A workspace
resource is a collection whose members are related version-controlled
and non-version-controlled resources. Multiple workspaces may be
used to expose different versions and configurations of a set of
version-controlled resources concurrently. In order to make changes
to a version-controlled resource in one workspace visible in another
workspace, that version-controlled resource must be checked in, and
then the corresponding version-controlled resource in the other
workspace can be updated to display the content and dead properties
of the new version.
In order to ensure unambiguous merging (see Section 11) and
baselining (see Section 12) semantics, a workspace may contain at
most one version-controlled resource for a given version history.
This is required for unambiguous merging because the MERGE method
must identify which version-controlled resource is to be the merge
target of a given version. This is required for unambiguous
baselining because a baseline can only select one version for a given
version-controlled resource.
Initially, an empty workspace can be created. Non-version-controlled
resources can then be added to the workspace with standard WebDAV
requests such as PUT and MKCOL. Version-controlled resources can be
added to the workspace with VERSION-CONTROL requests. If the
Clemm, et al. Standards Track [Page 47]
RFC 3253 Versioning Extensions to WebDAV March 2002
baseline feature is supported, collections in the workspace can be
placed under baseline control, and then initialized by existing
baselines.
6.1 Workspace Properties
The workspace feature introduces the following REQUIRED property for
a workspace.
6.1.1 DAV:workspace-checkout-set (computed)
This property identifies each checked-out resource whose
DAV:workspace property identifies this workspace.
<!ELEMENT workspace-checkout-set (href*)>
6.2 Additional Resource Properties
The workspace feature introduces the following REQUIRED property for
a WebDAV resource.
6.2.1 DAV:workspace (protected)
The DAV:workspace property of a workspace resource MUST identify
itself. The DAV:workspace property of any other type of resource
MUST be the same as the DAV:workspace of its parent collection.
<!ELEMENT workspace (href)>
6.3 MKWORKSPACE Method
A MKWORKSPACE request creates a new workspace resource. A server MAY
restrict workspace creation to particular collections, but a client
can determine the location of these collections from a
DAV:workspace-collection-set OPTIONS request (see Section 6.4).
If a MKWORKSPACE request fails, the server state preceding the
request MUST be restored.
Marshalling:
If a request body is included, it MUST be a DAV:mkworkspace XML
element.
<!ELEMENT mkworkspace ANY>
If a response body for a successful request is included, it MUST
be a DAV:mkworkspace-response XML element.
Clemm, et al. Standards Track [Page 48]
RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT mkworkspace-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:resource-must-be-null): A resource MUST NOT exist at the
request-URL.
(DAV:workspace-location-ok): The request-URL MUST identify a
location where a workspace can be created.
Postconditions:
(DAV:initialize-workspace): A new workspace exists at the
request-URL. The DAV:resourcetype of the workspace MUST be
DAV:collection. The DAV:workspace of the workspace MUST identify
the workspace.
6.3.1 Example - MKWORKSPACE
>>REQUEST
MKWORKSPACE /ws/public HTTP/1.1
Host: www.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created
Cache-Control: no-cache
In this example, a new workspace is created at
http://www.webdav.org/ws/public.
6.4 Additional OPTIONS Semantics
If a server supports the workspace feature, it MUST include
"workspace" as a field in the DAV response header from an OPTIONS
request on any resource that supports any versioning properties,
reports, or methods.
If a server supports the workspace feature, it MUST also support the
checkout-in-place feature and the version-history feature.
A DAV:workspace-collection-set element MAY be included in the request
body to identify collections that may contain workspace resources.
Clemm, et al. Standards Track [Page 49]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Marshalling:
If an XML request body is included, it MUST be a DAV:options XML
element.
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:workspace-collection-set element.
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:workspace-collection-set element.
<!ELEMENT workspace-collection-set (href*)>
If DAV:workspace-collection-set is included in the request body,
the response body for a successful request MUST contain a
DAV:workspace-collection-set element identifying collections that
may contain workspaces. An identified collection MAY be the root
collection of a tree of collections, all of which may contain
workspaces. Since different servers can control different parts
of the URL namespace, different resources on the same host MAY
have different DAV:workspace-collection-set values. The
identified collections MAY be located on different hosts from the
resource.
Clemm, et al. Standards Track [Page 50]
RFC 3253 Versioning Extensions to WebDAV March 2002
6.4.1 Example - OPTIONS
>>REQUEST
OPTIONS /doc HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:version-history-collection-set/>
<D:workspace-collection-set/>
</D:options>
>>RESPONSE
HTTP/1.1 200 OK
DAV: 1
DAV: version-control,checkout-in-place,version-history,workspace
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:options-response xmlns:D="DAV:">
<D:version-history-collection-set>
<D:href>http://repo.webdav.org/his</D:href>
</D:version-history-collection-set>
<D:workspace-collection-set>
<D:href>http://www.webdav.org/public/ws</D:href>
<D:href>http://www.webdav.org/private/ws</D:href>
</D:workspace-collection-set>
</D:options-response>
In this example, the server indicates that it provides Class 1 DAV
support and basic-server-workspace versioning support. In addition,
the server indicates the requested locations of the version history
resources and the workspace resources.
6.5 Additional DELETE Semantics
Additional Postconditions:
(DAV:delete-workspace-members): If a workspace is deleted, any
resource that identifies that workspace in its DAV:workspace
property MUST be deleted.
Clemm, et al. Standards Track [Page 51]
RFC 3253 Versioning Extensions to WebDAV March 2002
6.6 Additional MOVE Semantics
Additional Postconditions:
(DAV:workspace-member-moved): If the request-URL did not identify
a workspace, the DAV:workspace of the destination MUST have been
updated to have the same value as the DAV:workspace of the parent
collection of the destination.
(DAV:workspace-moved): If the request-URL identified a workspace,
any reference to that workspace in a DAV:workspace property MUST
have been updated to refer to the new location of that workspace.
6.7 Additional VERSION-CONTROL Semantics
A VERSION-CONTROL request can be used to create a new version-
controlled resource for an existing version history. This allows the
creation of version-controlled resources for the same version history
in multiple workspaces.
Additional Marshalling:
<!ELEMENT version-control ANY>
ANY value: A sequence of elements with at most one DAV:version
element.
<!ELEMENT version (href)>
Additional Preconditions:
(DAV:cannot-add-to-existing-history): If the DAV:version-control
request body element contains a DAV:version element, the request-
URL MUST NOT identify a resource.
(DAV:must-be-version): The DAV:href of the DAV:version element
MUST identify a version.
(DAV:one-version-controlled-resource-per-history-per-workspace):
If the DAV:version-control request body specifies a version, and
if the request-URL is a member of a workspace, then there MUST NOT
already be a version-controlled member of that workspace whose
DAV:checked-in or DAV:checked-out property identifies any version
from the version history of the version specified in the request
body.
Clemm, et al. Standards Track [Page 52]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions:
(DAV:new-version-controlled-resource): If the request-URL did NOT
identify a resource, a new version-controlled resource exists at
the request-URL whose content and dead properties are initialized
by those of the version in the request body, and whose
DAV:checked-in property identifies that version.
6.7.1 Example - VERSION-CONTROL (using an existing version history)
>>REQUEST
VERSION-CONTROL /ws/public/bar.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:version-control xmlns:D="DAV:">
<D:version>
<D:href>http://repo.webdav.org/his/12/ver/V3</D:href>
</D:version>
</D:version-control>
>>RESPONSE
HTTP/1.1 201 Created
Cache-Control: no-cache
In this example, a new version-controlled resource is created at
/ws/public/bar.html. The content and dead properties of the new
version-controlled resource are initialized to be the same as those
of the version identified by http://repo.webdav.org/his/12/ver/V3.
7 UPDATE Feature
The update feature provides a mechanism for changing the state of a
checked-in version-controlled resource to be that of another version
from the version history of that resource.
7.1 UPDATE Method
The UPDATE method modifies the content and dead properties of a
checked-in version-controlled resource (the "update target") to be
those of a specified version (the "update source") from the version
history of that version-controlled resource.
Clemm, et al. Standards Track [Page 53]
RFC 3253 Versioning Extensions to WebDAV March 2002
The response to an UPDATE request identifies the resources modified
by the request, so that a client can efficiently update any cached
state it is maintaining. Extensions to the UPDATE method allow
multiple resources to be modified from a single UPDATE request (see
Section 12.13).
Marshalling:
The request body MUST be a DAV:update element.
<!ELEMENT update ANY>
ANY value: A sequence of elements with at most one DAV:version
element and at most one DAV:prop element.
<!ELEMENT version (href)>
prop: see RFC 2518, Section 12.11
The response for a successful request MUST be a 207 Multi-Status,
where the DAV:multistatus XML element in the response body
identifies all resources that have been modified by the request.
multistatus: see RFC 2518, Section 12.9
The response MUST include a Cache-Control:no-cache header.
Postconditions:
(DAV:update-content-and-properties): If the DAV:version element in
the request body identified a version that is in the same version
history as the DAV:checked-in version of a version-controlled
resource identified by the request-URL, then the content and dead
properties of that version-controlled resource MUST be the same as
those of the version specified by the DAV:version element, and the
DAV:checked-in property of the version-controlled resource MUST
identify that version. The request-URL MUST appear in a
DAV:response element in the response body.
(DAV:report-properties): If DAV:prop is specified in the request
body, the properties specified in the DAV:prop element MUST be
reported in the DAV:response elements in the response body.
Clemm, et al. Standards Track [Page 54]
RFC 3253 Versioning Extensions to WebDAV March 2002
7.1.1 Example - UPDATE
>>REQUEST
UPDATE /foo.html HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:update xmlns:D="DAV:">
<D:version>
<D:href>http://repo.webdav.org/his/23/ver/33</D:href>
</D:version>
</D:update>
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Cache-Control: no-cache
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/foo.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
In this example, the content and dead properties of
http://repo.webdav.org/his/23/ver/33 are copied to the version-
controlled resource /foo.html, and the DAV:checked-in property of
/foo.html is updated to refer to
http://repo.webdav.org/his/23/ver/33.
7.2 Additional OPTIONS Semantics
If the server supports the update feature, it MUST include "update"
as a field in the DAV response header from an OPTIONS request on any
resource that supports any versioning properties, reports, or
methods.
Clemm, et al. Standards Track [Page 55]
RFC 3253 Versioning Extensions to WebDAV March 2002
8 Label Feature
A version "label" is a string that distinguishes one version in a
version history from all other versions in that version history. A
label can automatically be assigned by a server, or it can be
assigned by a client in order to provide a meaningful name for that
version. A given version label can be assigned to at most one
version of a given version history, but client assigned labels can be
reassigned to another version at any time. Note that although a
given label can be applied to at most one version from the same
version history, the same label can be applied to versions from
different version histories.
For certain methods, if the request-URL identifies a version-
controlled resource, a label can be specified in a Label request
header (see Section 8.3) to cause the method to be applied to the
version selected by that label from the version history of that
version-controlled resource.
8.1 Additional Version Properties
The label feature introduces the following REQUIRED property for a
version.
8.1.1 DAV:label-name-set (protected)
This property contains the labels that currently select this version.
<!ELEMENT label-name-set (label-name*)>
<!ELEMENT label-name (#PCDATA)>
PCDATA value: string
8.2 LABEL Method
A LABEL request can be applied to a version to modify the labels that
select that version. The case of a label name MUST be preserved when
it is stored and retrieved. When comparing two label names to decide
if they match or not, a server SHOULD use a case-sensitive URL-
escaped UTF-8 encoded comparison of the two label names.
If a LABEL request is applied to a checked in version-controlled
resource, the operation MUST be applied to the DAV:checked-in version
of that version-controlled resource.
Clemm, et al. Standards Track [Page 56]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling:
The request body MUST be a DAV:label element.
<!ELEMENT label ANY>
ANY value: A sequence of elements with at most one DAV:add,
DAV:set, or DAV:remove element.
<!ELEMENT add (label-name)>
<!ELEMENT set (label-name)>
<!ELEMENT remove (label-name)>
<!ELEMENT label-name (#PCDATA)>
PCDATA value: string
The request MAY include a Label header.
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed. Standard depth semantics apply, and
the request is applied to the collection identified by the
request-URL and to all members of the collection that satisfy the
Depth value. If a Depth header is included and the request fails
on any resource, the response MUST be a 207 Multi-Status that
identifies all resources for which the request has failed.
If a response body for a successful request is included, it MUST
be a DAV:label-response XML element.
<!ELEMENT label-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:must-be-checked-in): If the request-URL identifies a
version-controlled resource, the version-controlled resource MUST
be checked in.
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:add-must-be-new-label): If DAV:add is specified in the
request body, the specified label MUST NOT appear in the
DAV:label-name-set of any version in the version history of that
version-controlled resource.
Clemm, et al. Standards Track [Page 57]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:label-must-exist): If DAV:remove is specified in the request
body, the specified label MUST appear in the DAV:label-name-set of
that version.
Postconditions:
(DAV:add-or-set-label): If DAV:add or DAV:set is specified in the
request body, the specified label MUST appear in the DAV:label-
name-set of the specified version, and MUST NOT appear in the
DAV:label-name-set of any other version in the version history of
that version.
(DAV:remove-label): If DAV:remove is specified in the request
body, the specified label MUST NOT appear in the DAV:label-name-
set of any version in the version history of that version.
8.2.1 Example - Setting a label
>>REQUEST
LABEL /foo.html HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:label xmlns:D="DAV:">
<D:set>
<D:label-name>default</D:label-name>
</D:set>
</D:label>
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
In this example, the label "default" is applied to the DAV:checked-in
version of /foo.html.
8.3 Label Header
For certain methods (e.g. GET, PROPFIND), if the request-URL
identifies a version-controlled resource, a label can be specified in
a Label request header to cause the method to be applied to the
version selected by that label from the version history of that
version-controlled resource.
Clemm, et al. Standards Track [Page 58]
RFC 3253 Versioning Extensions to WebDAV March 2002
The value of a label header is the name of a label, encoded using
URL-escaped UTF-8. For example, the label "release B.3" is
identified by the following header:
Label: release%20B.3
A Label header MUST have no effect on a request whose request-URL
does not identify a version-controlled resource. In particular, it
MUST have no effect on a request whose request-URL identifies a
version or a version history.
A server MUST return an HTTP-1.1 Vary header containing Label in a
successful response to a cacheable request (e.g., GET) that includes
a Label header.
8.4 Additional OPTIONS Semantics
If the server supports the label feature, it MUST include "label" as
a field in the DAV response header from an OPTIONS request on any
resource that supports any versioning properties, reports, or
methods.
8.5 Additional GET Semantics
Additional Marshalling:
The request MAY include a Label header.
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the response MUST contain the content of the
specified version rather than that of the version-controlled
resource.
8.6 Additional PROPFIND Semantics
Additional Marshalling:
The request MAY include a Label header.
Clemm, et al. Standards Track [Page 59]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the response MUST contain the properties of
the specified version rather than that of the version-controlled
resource.
8.7 Additional COPY Semantics
Additional Marshalling:
The request MAY include a Label header.
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the request MUST have copied the properties
and content of the specified version rather than that of the
version-controlled resource.
8.8 Additional CHECKOUT Semantics
If the server supports the working-resource option, a LABEL header
may be included to check out the version selected by the specified
label.
Additional Marshalling:
The request MAY include a Label header.
Clemm, et al. Standards Track [Page 60]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-not-have-label-and-apply-to-version): If a Label request
header is included, the request body MUST NOT contain a
DAV:apply-to-version element.
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a checked-in version-controlled resource, and a Label
request header is included, the CHECKOUT MUST have been applied to
the version selected by the specified label, and not to the
version-controlled resource itself.
8.9 Additional UPDATE Semantics
If the request body of an UPDATE request contains a DAV:label-name
element, the update target is the resource identified by the
request-URL, and the update source is the version selected by the
specified label from the version history of the update target.
Additional Marshalling:
<!ELEMENT update ANY>
ANY value: A sequence of elements with at most one DAV:label-name
or DAV:version element (but not both).
<!ELEMENT label-name (#PCDATA)>
PCDATA value: string
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed. Standard depth semantics apply, and
the request is applied to the collection identified by the
request-URL and to all members of the collection that satisfy the
Depth value. If a Depth header is included and the request fails
on any resource, the response MUST be a 207 Multi-Status that
identifies all resources for which the request has failed.
Additional Preconditions:
(DAV:must-select-version-in-history): If the request includes a
DAV:label-name element in the request body, the label MUST select
a version in the version history of the version-controlled
resource identified by the request-URL.
Clemm, et al. Standards Track [Page 61]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:depth-update): If the request includes a Depth header,
standard depth semantics apply, and the request is applied to the
collection identified by the request-URL and to all members of the
collection that satisfy the Depth value. The request MUST be
applied to a collection before being applied to any members of
that collection, since an update of a version-controlled
collection might change the membership of that collection.
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If a DAV:label-name
element appears in the request body, the content and dead
properties of the version-controlled resource must have been
updated to be those of the version selected by that label.
9 Working-Resource Feature
The working-resource feature provides an alternative to the workspace
feature for supporting parallel development. Unlike the workspace
feature, where the desired configuration of versions and checked-out
resources is maintained on the server, the working-resource feature
maintains the configuration on the client. This simplifies the
server implementation, but does not allow a user to access the
configuration from clients in different physical locations, such as
from another office, from home, or while traveling. Another
difference is that the workspace feature isolates clients from a
logical change that involves renaming shared resources, until that
logical change is complete and tested; with the working resource
feature, all clients use a common set of shared version-controlled
resources and every client sees the result of a MOVE as soon as it
occurs.
If a server supports the working-resource feature but not the
checkout-in-place feature, a CHECKOUT request can only be used to
create a working resource, and cannot be used to check out a
version-controlled resource. If a server supports the checkout-in-
place feature, but not the working-resource feature, a CHECKOUT can
only be used to change the state of a version-controlled resource
from checked-in to checked-out.
9.1 Additional Version Properties
The working-resource feature introduces the following REQUIRED
properties for a version.
9.1.1 DAV:checkout-fork
This property is defined in Section 4.1.1.
Clemm, et al. Standards Track [Page 62]
RFC 3253 Versioning Extensions to WebDAV March 2002
9.1.2 DAV:checkin-fork
This property is defined in Section 4.1.2.
9.2 Working Resource Properties
The working-resource feature introduces the following REQUIRED
properties for a working resource. Since a working resource is a
checked-out resource, it also has any property defined in this
document for a checked-out resource.
9.2.1 DAV:auto-update (protected)
This property identifies the version-controlled resource that will be
updated when the working resource is checked in.
<!ELEMENT auto-update (href)>
9.2.2 DAV:checkout-fork
This property is defined in Section 4.2.1.
9.2.3 DAV:checkin-fork
This property is defined in Section 4.2.2.
9.3 CHECKOUT Method (applied to a version)
A CHECKOUT request can be applied to a version to create a new
working resource. The content and dead properties of the working
resource are a copy of the version that was checked out.
Marshalling:
If a request body is included, it MUST be a DAV:checkout XML
element.
<!ELEMENT checkout ANY>
ANY value: A sequence of elements with at most one DAV:apply-to-
version and at most one DAV:fork-ok element.
<!ELEMENT apply-to-version EMPTY>
<!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included,
it MUST be a DAV:checkout-response XML element.
Clemm, et al. Standards Track [Page 63]
RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT checkout-response ANY>
The response MUST include a Location header.
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:checkout-of-version-with-descendant-is-forbidden): See
Section 4.3.
(DAV:checkout-of-version-with-descendant-is-discouraged): See
Section 4.3.
(DAV:checkout-of-checked-out-version-is-forbidden): See Section
4.3.
(DAV:checkout-of-checked-out-version-is-discouraged): See Section
4.3.
Postconditions:
(DAV:create-working-resource): If the request-URL identified a
version, the Location response header MUST contain the URL of a
new working resource. The DAV:checked-out property of the new
working resource MUST identify the version that was checked out.
The content and dead properties of the working resource MUST be
copies of the content and dead properties of the DAV:checked-out
version. The DAV:predecessor-set property of the working resource
MUST be initialized to be the version identified by the request-
URL. The DAV:auto-update property of the working resource MUST
NOT exist.
(DAV:create-working-resource-from-checked-in-version): If the
request-URL identified a version-controlled resource, and
DAV:apply-to-version is specified in the request body, the
CHECKOUT is applied to the DAV:checked-in version of the version-
controlled resource, and not the version-controlled resource
itself. A new working resource is created and the version-
controlled resource remains checked-in. The DAV:auto-update
property of the working resource MUST identify the version-
controlled resource.
Clemm, et al. Standards Track [Page 64]
RFC 3253 Versioning Extensions to WebDAV March 2002
9.3.1 Example - CHECKOUT of a version
>>REQUEST
CHECKOUT /his/12/ver/V3 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created
Location: http://repo.webdav.org/wr/157
Cache-Control: no-cache
In this example, the version identified by
http://repo.webdav.org/his/12/ver/V3 is checked out, and the new
working resource is located at http://repo.webdav.org/wr/157.
9.4 CHECKIN Method (applied to a working resource)
A CHECKIN request can be applied to a working resource to produce a
new version whose content and dead properties are a copy of those of
the working resource. If the DAV:auto-update property of the working
resource was set because the working resource was created by applying
a CHECKOUT with the DAV:apply-to-version flag to a version-controlled
resource, the CHECKIN request will also update the content and dead
properties of that version-controlled resource to be those of the new
version.
Marshalling:
If a request body is included, it MUST be a DAV:checkin XML
element.
<!ELEMENT checkin ANY>
ANY value: A sequence of elements with at most one DAV:fork-ok
element.
<!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included, it MUST
be a DAV:checkin-response XML element.
<!ELEMENT checkin-response ANY>
The response MUST include a Cache-Control:no-cache header.
Clemm, et al. Standards Track [Page 65]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
(DAV:must-be-checked-out): See Section 4.4.
(DAV:version-history-is-tree) See Section 4.4.
(DAV:checkin-fork-forbidden): See Section 4.4.
(DAV:checkin-fork-discouraged): See Section 4.4.
(DAV:no-overwrite-by-auto-update): If the DAV:auto-update property
for the checked-out resource identifies a version-controlled
resource, at least one of the versions identified by the
DAV:predecessor-set property of the checked-out resource MUST
identify a version that is either the same as or a descendant of
the version identified by the DAV:checked-in property of that
version-controlled resource.
Postconditions:
(DAV:create-version): See Section 4.4.
(DAV:initialize-version-content-and-properties): See Section 4.4.
(DAV:auto-update): If the DAV:auto-update property of the
checked-out resource identified a version-controlled resource, an
UPDATE request with the new version MUST have been applied to that
version-controlled resource.
(DAV:delete-working-resource): If the request-URL identifies a
working resource and if DAV:keep-checked-out is not specified in
the request body, the working resource is deleted.
9.4.1 Example - CHECKIN of a working resource
>>REQUEST
CHECKIN /wr/157 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created
Location: http://repo.webdav.org/his/23/ver/15
Cache-Control: no-cache
Clemm, et al. Standards Track [Page 66]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the working resource /wr/157 checked in, and a new
version is created at http://repo.webdav.org/his/23/ver/15.
9.5 Additional OPTIONS Semantics
If the server supports the working-resource feature, it MUST include
"working-resource" as a field in the DAV response header from an
OPTIONS request on any resource that supports any versioning
properties, reports, or methods.
9.6 Additional COPY Semantics
Additional Postconditions:
(DAV:copy-creates-new-resource): The result of copying a working
resource is a new non-version-controlled resource at the
destination of the COPY. The new resource MAY automatically be
put under version control, but the resulting version-controlled
resource MUST be associated with a new version history created for
that new version-controlled resource.
9.7 Additional MOVE Semantics
Additional Preconditions:
(DAV:cannot-rename-working-resource): If the request-URL
identifies a working resource, the request MUST fail.
Additional Postconditions:
(DAV:update-auto-update): If the request-URL identified a
version-controlled resource, any DAV:auto-update properties that
identified that version-controlled resource MUST have been updated
to contain the new location of that version-controlled resource.
10 Advanced Versioning Features
Advanced versioning addresses the problems of parallel development
and configuration management of multiple sets of interrelated
resources. Traditionally, artifacts of software development,
including requirements, design documents, code, and test cases, have
been a focus of configuration management. Web sites, comprising
multiple inter-linked resources (HTML, graphics, sound, CGI, and
others), are another class of complex information artifacts that
benefit from the application of configuration management. The
advanced versioning capabilities for coordinating concurrent change
provide the infrastructure for efficient and controlled management of
large evolving web sites.
Clemm, et al. Standards Track [Page 67]
RFC 3253 Versioning Extensions to WebDAV March 2002
10.1 Advanced Versioning Packages
Although a server MAY support any combination of advanced versioning
features, in order to minimize the complexity of a WebDAV advanced
versioning client, a WebDAV advanced versioning server SHOULD support
one of the following packages:
Advanced-Server-Workspace Package: basic-server-workspace package
plus all advanced features
Advanced-Client-Workspace Package: basic-client-workspace package
plus all advanced features
The advanced-server-workspace package supports advanced versioning
capabilities for a client with no persistent state. The advanced-
client-workspace package supports advanced versioning capabilities
for a client that maintains configuration state on the client. A
server that supports both advanced workspace packages will
interoperate with all versioning clients.
10.2 Advanced Versioning Terms
The following additional terms are used by the advanced versioning
features.
Collection
A "collection" is a resource whose state consists of not only
content and properties, but also a set of named "bindings", where
a binding identifies what RFC 2518 calls an "internal member" of
the collection. Note that a binding is not a resource, but rather
is a part of the state of a collection that defines a mapping from
a binding name (a URL segment) to a resource (an internal member
of the collection).
Collection Version Resource
A "collection version resource", or simply "collection version",
captures the dead properties of a version-controlled collection,
as well as the names of its version-controlled bindings (see
Section 14). A version-controlled binding is a binding to a
version-controlled resource. If the checkout-in-place feature is
supported, a collection version can be created by checking out and
then checking in a version-controlled collection. If the
working-resource feature is supported, a collection version can be
created by checking out a collection version (to create a "working
collection") and then checking in the working collection.
Clemm, et al. Standards Track [Page 68]
RFC 3253 Versioning Extensions to WebDAV March 2002
Configuration
A "configuration" is a set of resources that consists of a root
collection and all members (not just internal members) of that
root collection that are not members of another configuration.
The root collection is called the "configuration root", and the
members of this set are called the "members of the configuration".
Note that a collection (which is a single resource) is very
different from a configuration (which is a set of resources).
Baseline Resource
A "baseline resource", or simply "baseline", of a collection is a
version of the configuration that is rooted at that collection
(see Section 12). In particular, a baseline captures the
DAV:checked-in version of every version-controlled member of that
configuration. Note that a collection version (which captures the
state of a single resource) is very different from a collection
baseline (which captures the state of a set of resources).
Baseline-Controlled Collection
A "baseline-controlled collection" is a collection from which
baselines can be created (see Section 12).
Version-Controlled Configuration Resource
A "version-controlled configuration resource", or simply
"version-controlled configuration", is a special kind of version-
controlled resource that is associated with a baseline-controlled
collection, and is used to create and access baselines of that
collection (see Section 12). When a collection is both version-
controlled and baseline-controlled, a client can create a new
version of the collection by checking out and checking in that
collection, and it can create a new baseline of that collection by
checking out and checking in the version-controlled configuration
of that collection.
Activity Resource
An "activity resource", or simply "activity", is a resource that
selects a set of versions that correspond to a single logical
change, where the versions selected from a given version history
form a single line of descent through that version history (see
Section 13).
Clemm, et al. Standards Track [Page 69]
RFC 3253 Versioning Extensions to WebDAV March 2002
11 Merge Feature
When a user wants to accept the changes (new versions) created by
someone else, it is important not just to update the version-
controlled resources in the user's workspace with those new versions,
since this could result in "backing out" changes the user has made to
those version-controlled resources. Instead, the versions created in
another workspace should be "merged" into the user's version-
controlled resources.
The version history of a version-controlled resource provides the
information needed to determine the result of the merge. In
particular, the merge should select whichever version is later in the
line of descent from the root version. In case the versions to be
merged are on different lines of descent (neither version is a
descendant of the other), neither version should be selected, but
instead, a new version should be created that contains the logical
merge of the content and dead properties of those versions. The
MERGE request can be used to check out each version-controlled
resource that requires such a merge, and set the DAV:merge-set
property of each checked-out resource to identify the version to be
merged. The user is responsible for modifying the content and dead
properties of the checked-out resource so that it represents the
logical merge of that version, and then adding that version to the
DAV:predecessor-set of the checked-out resource.
If the server is capable of automatically performing the merge, it
MAY update the content, dead properties, and DAV:predecessor-set of
the checked-out resource itself. Before checking in the
automatically merged resource, the user is responsible for verifying
that the automatic merge is correct.
11.1 Additional Checked-Out Resource Properties
The merge feature introduces the following REQUIRED properties for a
checked-out resource.
11.1.1 DAV:merge-set
This property identifies each version that is to be merged into this
checked-out resource.
<!ELEMENT merge-set (href*)>
Clemm, et al. Standards Track [Page 70]
RFC 3253 Versioning Extensions to WebDAV March 2002
11.1.2 DAV:auto-merge-set
This property identifies each version that the server has merged into
this checked-out resource. The client should confirm that the merge
has been performed correctly before moving a URL from the DAV:auto-
merge-set to the DAV:predecessor-set of a checked-out resource.
<!ELEMENT auto-merge-set (href*)>
11.2 MERGE Method
The MERGE method performs the logical merge of a specified version
(the "merge source") into a specified version-controlled resource
(the "merge target"). If the merge source is neither an ancestor nor
a descendant of the DAV:checked-in or DAV:checked-out version of the
merge target, the MERGE checks out the merge target (if it is not
already checked out) and adds the URL of the merge source to the
DAV:merge-set of the merge target. It is then the client's
responsibility to update the content and dead properties of the
checked-out merge target so that it reflects the logical merge of the
merge source into the current state of the merge target. The client
indicates that it has completed the update of the merge target, by
deleting the merge source URL from the DAV:merge-set of the checked-
out merge target, and adding it to the DAV:predecessor-set. As an
error check for a client forgetting to complete a merge, the server
MUST fail an attempt to CHECKIN a version-controlled resource with a
non-empty DAV:merge-set.
When a server has the ability to automatically update the content and
dead properties of the merge target to reflect the logical merge of
the merge source, it may do so unless DAV:no-auto-merge is specified
in the MERGE request body. In order to notify the client that a
merge source has been automatically merged, the MERGE request MUST
add the URL of the auto-merged source to the DAV:auto-merge-set
property of the merge target, and not to the DAV:merge-set property.
The client indicates that it has verified that the auto-merge is
valid, by deleting the merge source URL from the DAV:auto-merge-set,
and adding it to the DAV:predecessor-set.
Multiple merge sources can be specified in a single MERGE request.
The set of merge sources for a MERGE request is determined from the
DAV:source element of the MERGE request body as follows:
- If DAV:source identifies a version, that version is a merge
source.
- If DAV:source identifies a version-controlled resource, the
DAV:checked-in version of that version-controlled resource is a
merge source.
Clemm, et al. Standards Track [Page 71]
RFC 3253 Versioning Extensions to WebDAV March 2002
- If DAV:source identifies a collection, the DAV:checked-in version
of each version-controlled resource that is a member of that
collection is a merge source.
The request-URL identifies the set of possible merge targets. If the
request-URL identifies a collection, any member of the configuration
rooted at the request-URL is a possible merge target. The merge
target of a particular merge source is the version-controlled or
checked-out resource whose DAV:checked-in or DAV:checked-out version
is from the same version history as the merge source. If a merge
source has no merge target, that merge source is ignored.
The MERGE response identifies the resources that a client must modify
to complete the merge. It also identifies the resources modified by
the request, so that a client can efficiently update any cached state
it is maintaining.
Marshalling:
The request body MUST be a DAV:merge element.
The set of merge sources is determined by the DAV:source element
in the request body.
<!ELEMENT merge ANY>
ANY value: A sequence of elements with one DAV:source element, at
most one DAV:no-auto-merge element, at most one DAV:no-checkout
element, at most one DAV:prop element, and any legal set of
elements that can occur in a DAV:checkout element.
<!ELEMENT source (href+)>
<!ELEMENT no-auto-merge EMPTY>
<!ELEMENT no-checkout EMPTY>
prop: see RFC 2518, Section 12.11
The response for a successful request MUST be a 207 Multi-Status,
where the DAV:multistatus XML element in the response body
identifies all resources that have been modified by the request.
multistatus: see RFC 2518, Section 12.9
The response to a successful request MUST include a Location
header containing the URL for the new version created by the
checkin.
The response MUST include a Cache-Control:no-cache header.
Clemm, et al. Standards Track [Page 72]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
(DAV:cannot-merge-checked-out-resource): The DAV:source element
MUST NOT identify a checked-out resource. If the DAV:source
element identifies a collection, the collection MUST NOT have a
member that is a checked-out resource.
(DAV:checkout-not-allowed): If DAV:no-checkout is specified in the
request body, it MUST be possible to perform the merge without
checking out any of the merge targets.
All preconditions of the CHECKOUT operation apply to the checkouts
performed by the request.
Postconditions:
(DAV:ancestor-version): If a merge target is a version-controlled
or checked-out resource whose DAV:checked-in version or
DAV:checked-out version is the merge source or is a descendant of
the merge source, the merge target MUST NOT have been modified by
the MERGE.
(DAV:descendant-version): If the merge target was a checked-in
version-controlled resource whose DAV:checked-in version was an
ancestor of the merge source, an UPDATE operation MUST have been
applied to the merge target to set its content and dead properties
to be those of the merge source. If the UPDATE method is not
supported, the merge target MUST have been checked out, the
content and dead properties of the merge target MUST have been set
to those of the merge source, and the merge source MUST have been
added to the DAV:auto-merge-set of the merge target. The merge
target MUST appear in a DAV:response XML element in the response
body.
(DAV:checked-out-for-merge): If the merge target was a checked-in
version-controlled resource whose DAV:checked-in version was
neither a descendant nor an ancestor of the merge source, a
CHECKOUT MUST have been applied to the merge target. All XML
elements in the DAV:merge XML element that could appear in a
DAV:checkout XML element MUST have been used as arguments to the
CHECKOUT request. The merge target MUST appear in a DAV:response
XML element in the response body.
(DAV:update-merge-set): If the DAV:checked-out version of the
merge target is neither equal to nor a descendant of the merge
source, the merge source MUST be added to either the DAV:merge-set
or the DAV:auto-merge-set of the merge target. The merge target
MUST appear in a DAV:response XML element in the response body.
Clemm, et al. Standards Track [Page 73]
RFC 3253 Versioning Extensions to WebDAV March 2002
If a merge source has been added to the DAV:auto-merge-set, the
content and dead properties of the merge target MUST have been
modified by the server to reflect the result of a logical merge of
the merge source and the merge target. If a merge source has been
added to the DAV:merge-set, the content and dead properties of the
merge target MUST NOT have been modified by the server. If
DAV:no-auto-merge is specified in the request body, the merge
source MUST NOT have been added to the DAV:auto-merge-set.
(DAV:report-properties): If DAV:prop is specified in the request
body, the properties specified in the DAV:prop element MUST be
reported in the DAV:response elements in the response body.
11.2.1 Example - MERGE
>>REQUEST
MERGE /ws/public HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge xmlns:D="DAV:">
<D:source>
<D:href>http://www.webdav.org/ws/dev/sally</D:href>
</D:source>
</D:merge>
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Cache-Control: no-cache
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/ws/public/src/parse.c</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.webdav.org/ws/public/doc/parse.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
Clemm, et al. Standards Track [Page 74]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the DAV:checked-in versions from the workspace
http://www.webdav.org/ws/dev/sally are merged into the version-
controlled resources in the workspace
http://www.webdav.org/ws/public. The resources
/ws/public/src/parse.c and /ws/public/doc/parse.html were modified by
the request.
11.3 DAV:merge-preview Report
A merge preview describes the changes that would result if the
versions specified by the DAV:source element in the request body were
to be merged into the resource identified by the request-URL
(commonly, a collection).
Marshalling:
The request body MUST be a DAV:merge-preview XML element.
<!ELEMENT merge-preview (source)>
<!ELEMENT source (href)>
The response body for a successful request MUST be a
DAV:merge-preview-report XML element.
<!ELEMENT merge-preview-report
(update-preview | conflict-preview | ignore-preview)*>
A DAV:update-preview element identifies a merge target whose
DAV:checked-in property would change as a result of the MERGE, and
identifies the merge source for that merge target.
<!ELEMENT update-preview (target, version)>
<!ELEMENT target (href)>
<!ELEMENT version (href)>
A DAV:conflict-preview element identifies a merge target that
requires a merge.
<!ELEMENT conflict-preview (target, common-ancestor, version)>
A DAV:common-ancestor element identifies the version that is a
common ancestor of both the merge source and the DAV:checked-in or
DAV:checked-out version of the merge target.
<!ELEMENT common-ancestor (href)>
A DAV:ignore-preview element identifies a version that has no
merge target and therefore would be ignored by the merge.
Clemm, et al. Standards Track [Page 75]
RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT ignore-preview (version)>
11.3.1 Example - DAV:merge-preview Report
>>REQUEST
REPORT /ws/public HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge-preview xmlns:D="DAV:">
<D:source>
<D:href>http://www.webdav.org/ws/dev/fred</D:href>
</D:source>
</D:merge-preview>
>>RESPONSE
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge-preview-report xmlns:D="DAV:">
<D:conflict-preview>
<D:target>
<D:href>http://www.webdav.org/ws/public/foo.html</D:href>
</D:target>
<D:common-ancestor>
<D:href>http://repo.webdav.org/his/23/ver/18</D:href>
</D:common-ancestor>
<D:version>
<D:href>http://repo.webdav.org/his/23/ver/42</D:href>
</D:version>
</D:conflict-preview>
<D:update-preview>
<D:target>
<D:href>http://www.webdav.org/ws/public/bar.html</D:href>
</D:target>
<D:version>
<D:href>http://www.repo/his/42/ver/3</D:href>
</D:version>
</D:update-preview>
</D:merge-preview-report>
Clemm, et al. Standards Track [Page 76]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the merge preview report indicates that version
/his/23/ver/42 would be merged in /ws/public/foo.html, and version
/his/42/ver/3 would update /ws/public/bar.html if the workspace
http://www.webdav.org/ws/dev/fred was merged into the workspace
http://www.webdav.org/ws/public.
11.4 Additional OPTIONS Semantics
If the server supports the merge feature, it MUST include "merge" as
a field in the DAV response header from an OPTIONS request on any
resource that supports any versioning properties, reports, or
methods.
11.5 Additional DELETE Semantics
Additional Postconditions:
(DAV:delete-version-reference): If a version is deleted, any
reference to that version in a DAV:merge-set or DAV:auto-merge-set
property MUST be removed.
11.6 Additional CHECKIN Semantics
Additional Preconditions:
(DAV:merge-must-be-complete): The DAV:merge-set and DAV:auto-
merge-set of the checked-out resource MUST be empty or not exist.
12 Baseline Feature
A configuration is a set of resources that consists of a root
collection and all members of that root collection except those
resources that are members of another configuration. A configuration
that contains a large number of resources can consume a large amount
of space on a server. This can make it prohibitively expensive to
remember the state of an existing configuration by creating a
Depth:infinity copy of its root collection.
A baseline is a version resource that captures the state of each
version-controlled member of a configuration. A baseline history is
a version history whose versions are baselines. New baselines are
created by checking out and then checking in a special kind of
version-controlled resource called a version-controlled
configuration.
A collection that is under baseline control is called a baseline-
controlled collection. In order to allow efficient baseline
implementation, the state of a baseline of a collection is limited to
Clemm, et al. Standards Track [Page 77]
RFC 3253 Versioning Extensions to WebDAV March 2002
be a set of versions and their names relative to the collection, and
the operations on a baseline are limited to the creation of a
baseline from a collection, and restoring or merging the baseline
back into a collection. A server MAY automatically put a collection
under baseline control when it is created, or a client can use the
BASELINE-CONTROL method to put a specified collection under baseline
control.
As a configuration gets large, it is often useful to break it up into
a set of smaller configurations that form the logical "components" of
that configuration. In order to capture the fact that a baseline of
a configuration is logically extended by a component configuration
baseline, the component configuration baseline is captured as a
"subbaseline" of the baseline.
The root collection of a configuration is unconstrained with respect
to its relationship to the root collection of any of its components.
In particular, the root collection of a configuration can have a
member that is the root collection of one of its components (e.g.,
configuration /sys/x can have a component /sys/x/foo), can be a
member of the root collection of one of its components (e.g.,
configuration /sys/y/z can have a component /sys/y), or neither
(e.g., configuration /sys/x can have a component /comp/bar).
12.1 Version-Controlled Configuration Properties
Since a version-controlled configuration is a version-controlled
resource, it has all the properties of a version-controlled resource.
In addition, the baseline feature introduces the following REQUIRED
property for a version-controlled configuration.
12.1.1 DAV:baseline-controlled-collection (protected)
This property identifies the collection that contains the version-
controlled resources whose DAV:checked-in versions are being tracked
by this version-controlled configuration. The DAV:version-
controlled-configuration of the DAV:baseline-controlled-collection of
a version-controlled configuration MUST identify that version-
controlled configuration.
<!ELEMENT baseline-controlled-collection (href)>
12.2 Checked-Out Configuration Properties
Since a checked-out configuration is a checked-out resource, it has
all the properties of a checked-out resource. In addition, the
baseline feature introduces the following REQUIRED property for a
checked-out configuration.
Clemm, et al. Standards Track [Page 78]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.2.1 DAV:subbaseline-set
This property determines the DAV:subbaseline-set property of the
baseline that results from checking in this resource.
A server MAY reject attempts to modify the DAV:subbaseline-set of a
checked-out configuration.
<!ELEMENT subbaseline-set (href*)>
12.3 Baseline Properties
The DAV:resourcetype of a baseline MUST be DAV:baseline. Since a
baseline is a version resource, it has all the properties of a
version resource. In addition, the baseline feature introduces the
following REQUIRED properties for a baseline.
12.3.1 DAV:baseline-collection (protected)
This property contains a server-defined URL for a collection, where
each member of this collection MUST either be a version-controlled
resource with the same DAV:checked-in version and relative name as a
version-controlled member of the baseline-controlled collection at
the time the baseline was created, or be a collection needed to
provide the relative name for a version-controlled resource.
<!ELEMENT baseline-collection (href)>
12.3.2 DAV:subbaseline-set (protected)
The URLs in the DAV:subbaseline-set property MUST identify a set of
other baselines. The subbaselines of a baseline are the baselines
identified by its DAV:subbaseline-set and all subbaselines of the
baselines identified by its DAV:subbaseline-set.
<!ELEMENT subbaseline-set (href*)>
12.4 Additional Resource Properties
The baseline feature introduces the following REQUIRED property for a
resource.
12.4.1 DAV:version-controlled-configuration (computed)
If the resource is a member of a version-controlled configuration
(i.e. the resource is a collection under baseline control or is a
member of a collection under baseline control), this property
identifies that version-controlled configuration.
Clemm, et al. Standards Track [Page 79]
RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT version-controlled-configuration (href)>
12.5 Additional Workspace Properties
The baseline feature introduces the following REQUIRED property for a
workspace.
12.5.1 DAV:baseline-controlled-collection-set (computed)
This property identifies each member of the workspace that is a
collection under baseline control (as well as the workspace itself,
if it is under baseline control).
<!ELEMENT baseline-controlled-collection-set (href*)>
12.6 BASELINE-CONTROL Method
A collection can be placed under baseline control with a
BASELINE-CONTROL request. When a collection is placed under baseline
control, the DAV:version-controlled-configuration property of the
collection is set to identify a new version-controlled configuration.
This version-controlled configuration can be checked out and then
checked in to create a new baseline for that collection.
If a baseline is specified in the request body, the DAV:checked-in
version of the new version-controlled configuration will be that
baseline, and the collection is initialized to contain version-
controlled members whose DAV:checked-in versions and relative names
are determined by the specified baseline.
If no baseline is specified, a new baseline history is created
containing a baseline that captures the state of the version-
controlled members of the collection, and the DAV:checked-in version
of the version-controlled configuration will be that baseline.
Marshalling:
If a request body is included, it MUST be a DAV:baseline-control
XML element.
<!ELEMENT baseline-control ANY>
ANY value: A sequence of elements with at most one DAV:baseline
element.
<!ELEMENT baseline (href)>
If a response body for a successful request is included, it MUST
be a DAV:baseline-control-response XML element.
Clemm, et al. Standards Track [Page 80]
RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT baseline-control-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:version-controlled-configuration-must-not-exist): The
DAV:version-controlled-configuration property of the collection
identified by the request-URL MUST not exist.
(DAV:must-be-baseline): The DAV:href of the DAV:baseline element
in the request body MUST identify a baseline.
(DAV:must-have-no-version-controlled-members): If a DAV:baseline
element is specified in the request body, the collection
identified by the request-URL MUST have no version-controlled
members.
(DAV:one-baseline-controlled-collection-per-history-per-
workspace): If the request-URL identifies a workspace or a member
of a workspace, and if a baseline is specified in a DAV:baseline
element in the request body, then there MUST NOT be another
collection in that workspace whose DAV:version-controlled-
configuration property identifies a version-controlled
configuration for the baseline history of that baseline.
Postconditions:
(DAV:create-version-controlled-configuration): A new version-
controlled configuration is created, whose DAV:baseline-
controlled-collection property identifies the collection.
(DAV:reference-version-controlled-configuration): The
DAV:version-controlled-configuration of the collection identifies
the new version-controlled configuration.
(DAV:select-existing-baseline): If the request body specifies a
baseline, the DAV:checked-in property of the new version-
controlled configuration MUST have been set to identify this
baseline. A version-controlled member of the collection will be
created for each version in the baseline, where the version-
controlled member will have the content and dead properties of
that version, and will have the same name relative to the
collection as the corresponding version-controlled resource had
when the baseline was created. Any nested collections that are
needed to provide the appropriate name for a version-controlled
member will be created.
Clemm, et al. Standards Track [Page 81]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:create-new-baseline): If no baseline is specified in the
request body, the request MUST have created a new baseline history
at a server-defined URL, and MUST have created a new baseline in
that baseline history. The DAV:baseline-collection of the new
baseline MUST identify a collection whose members have the same
relative name and DAV:checked-in version as the version-controlled
members of the request collection. The DAV:checked-in property of
the new version-controlled configuration MUST identify the new
baseline.
12.6.1 Example - BASELINE-CONTROL
>>REQUEST
BASELINE-CONTROL /src HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:baseline-control xmlns:D="DAV:">
<D:href>http://www.webdav.org/repo/blh/13/ver/8</D:href>
</D:baseline-control>
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 0
Clemm, et al. Standards Track [Page 82]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the collection /src is placed under baseline
control, and is populated with members from an existing baseline. A
new version-controlled configuration (/repo/vcc/128) is created and
associated with /src, and /src is initialized with version-controlled
members whose DAV:checked-in versions are those selected by the
DAV:baseline-collection (/repo/bc/15) of the specified baseline
(/repo/blh/13/ver/8). The following diagram illustrates the
resulting state on the server.
+-------------------------------------+
|Baseline-Controlled Collection |<------+
|/src | |
|-------------------------------------| |
|DAV:version-controlled-configuration +---+ |
+-------------------------------------+ | |
| |
| |
+-------------------------------------+ | |
|Version-Controlled Configuration |<--+ |
|/repo/vcc/128 | |
|-------------------------------------| |
|DAV:baseline-controlled-collection +-------+
|-------------------------------------|
|DAV:checked-in +-------+
+-------------------------------------+ |
|DAV:version-history +---+ |
+-------------------------------------+ | |
| |
| |
+------------------------+ | |
|Baseline History |<---------------+ |
|/repo/blh/13 | |
|------------------------+ |
|DAV:version-set +----------------+ |
+------------------------+ | | | | |
v | v v |
| |
+------------------------+ | |
|Baseline |<-------+-----------+
|/repo/blh/13/ver/8 |
|------------------------+ +--------------+
|DAV:baseline-collection +---->|Collection |
+------------------------+ |/repo/bc/15 |
+--------------+
Clemm, et al. Standards Track [Page 83]
RFC 3253 Versioning Extensions to WebDAV March 2002
In order to create new baselines of /src, /repo/vcc/128 can be
checked out, new versions can be created or selected by the version-
controlled members of /src, and then /repo/vcc/128 can be checked in
to capture the current state of those version-controlled members.
12.7 DAV:compare-baseline Report
A DAV:compare-baseline report contains the differences between the
baseline identified by the request-URL (the "request baseline") and
the baseline specified in the request body (the "compare baseline").
Marshalling:
The request body MUST be a DAV:compare-baseline XML element.
<!ELEMENT compare-baseline (href)>
The response body for a successful request MUST be a DAV:compare-
baseline-report XML element.
<!ELEMENT compare-baseline-report
(added-version | deleted-version | changed-version)*>
A DAV:added-version element identifies a version that is the
DAV:checked-in version of a member of the DAV:baseline-collection
of the compare baseline, but no version in the version history of
that version is the DAV:checked-in version of a member of the
DAV:baseline-collection of the request baseline.
<!ELEMENT added-version (href)>
A DAV:deleted-version element identifies a version that is the
DAV:checked-in version of a member of the DAV:baseline-collection
of the request baseline, but no version in the version history of
that version is the DAV:checked-in version of a member of the
DAV:baseline-collection of the compare baseline.
<!ELEMENT deleted-version (href)>
A DAV:changed-version element identifies two different versions
from the same version history that are the DAV:checked-in version
of the DAV:baseline-collection of the request baseline and the
compare baseline, respectively.
<!ELEMENT changed-version (href, href)>
Clemm, et al. Standards Track [Page 84]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
(DAV:must-be-baseline): The DAV:href in the request body MUST
identify a baseline.
(DAV:baselines-from-same-history): A server MAY require that the
baselines being compared be from the same baseline history.
12.7.1 Example - DAV:compare-baseline Report
>>REQUEST
REPORT /bl-his/12/bl/14 HTTP/1.1
Host: repo.webdav.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:compare-baseline xmlns:D="DAV:">
<D:href>http://repo.webdav.org/bl-his/12/bl/15</D:href>
</D:compare-baseline>
>>RESPONSE
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:compare-baseline-report xmlns:D="DAV:">
<D:added-version>
<D:href>http://repo.webdav.org/his/23/ver/8</D:href>
</D:added-version>
<D:changed-version>
<D:href>http://repo.webdav.org/his/29/ver/12</D:href>
<D:href>http://repo.webdav.org/his/29/ver/19</D:href>
</D:changed-version>
<D:deleted-version>
<D:href>http://repo.webdav.org/his/12/ver/4</D:href>
</D:deleted-version>
</D:compare-baseline-report>
In this example, the differences between baseline 14 and baseline 15
of http://repo.webdav.org/bl-his/12 are identified.
Clemm, et al. Standards Track [Page 85]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.8 Additional OPTIONS Semantics
If a server supports the baseline feature, it MUST include "baseline"
as a field in the DAV response header from an OPTIONS request on any
resource that supports any versioning properties, reports, or
methods.
12.9 Additional MKCOL Semantics
Additional Postconditions:
If a server automatically puts a newly created collection under
baseline control, all postconditions for BASELINE-CONTROL apply to
the MKCOL.
12.10 Additional COPY Semantics
Additional Postconditions:
If the request creates a new collection at the Destination, and a
server automatically puts a newly created collection under
baseline control, all postconditions for BASELINE-CONTROL apply to
the COPY.
12.11 Additional CHECKOUT Semantics
Additional Preconditions:
(DAV:must-not-update-baseline-collection): If the request-URL
identifies a member of the configuration rooted at the
DAV:baseline-collection of a baseline, the request MUST fail.
12.12 Additional CHECKIN Semantics
Additional Preconditions:
(DAV:no-checked-out-baseline-controlled-collection-members): If
the request-URL identifies a version-controlled configuration, all
version-controlled members of the DAV:baseline-controlled-
collection of the version-controlled configuration MUST be
checked-in.
(DAV:one-version-per-history-per-baseline): If the request-URL
identifies a version-controlled configuration, the set of versions
selected by that version-controlled configuration MUST contain at
most one version from any version history, where a version is
selected by a version-controlled configuration if the version is
identified by the DAV:checked-in property of any member of the
Clemm, et al. Standards Track [Page 86]
RFC 3253 Versioning Extensions to WebDAV March 2002
configuration rooted at the DAV:baseline-controlled collection of
that version-controlled configuration, or is identified by the
DAV:checked-in property of any member of the configuration rooted
at the DAV:baseline-collection of any subbaseline of that
version-controlled configuration.
(DAV:cannot-modify-version-controlled-configuration): If the
request-URL identifies a version-controlled member of a baseline-
controlled collection whose version-controlled configuration is
checked-in, the request MUST fail unless the DAV:auto-version
property of the version-controlled configuration will
automatically check out that version-controlled configuration when
it is modified.
Additional Postconditions:
(DAV:create-baseline-collection): If the request-URL identifies a
version-controlled configuration, the DAV:baseline-collection of
the new baseline identifies a collection whose members have the
same relative name and DAV:checked-in version as the members of
the DAV:baseline-controlled-collection of the version-controlled
configuration at the time of the request.
(DAV:modify-configuration): If the request-URL identifies a
version-controlled member of a baseline-controlled collection,
this is a modification to the version-controlled configuration of
that baseline-controlled collection, and standard auto-versioning
semantics apply.
12.13 Additional UPDATE Semantics
Additional Preconditions:
(DAV:baseline-controlled-members-must-be-checked-in): If the
request-URL identifies a version-controlled configuration, then
all version-controlled members of the DAV:baseline-controlled-
collection of that version-controlled configuration MUST be
checked-in.
(DAV:must-not-update-baseline-collection): If the request-URL
identifies a member of the configuration rooted at the
DAV:baseline-collection of a baseline, the request MUST fail.
(DAV:cannot-modify-version-controlled-configuration): If the
request updates the DAV:checked-in property of any version-
controlled member of a baseline-controlled collection whose
version-controlled configuration is checked-in, the request MUST
Clemm, et al. Standards Track [Page 87]
RFC 3253 Versioning Extensions to WebDAV March 2002
fail unless the DAV:auto-version property of the version-
controlled configuration will automatically check out that
version-controlled configuration when it is modified.
Additional Postconditions:
(DAV:set-baseline-controlled-collection-members): If the request
updated the DAV:checked-in property of a version-controlled
configuration, then the version-controlled members of the
DAV:baseline-controlled-collection of that version-controlled
configuration MUST have been updated so that they have the same
relative name, content, and dead properties as the members of the
DAV:baseline-collection of the baseline. In particular:
- A version-controlled member for a given version history MUST
have been deleted if there is no version-controlled member for
that version history in the DAV:baseline-collection of the
baseline.
- A version-controlled member for a given version history MUST
have been renamed if its name relative to the baseline-
controlled collection is different from that of the version-
controlled member for that version history in the
DAV:baseline-collection of the baseline.
- A new version-controlled member MUST have been created for each
member of the DAV:baseline-collection of the baseline for which
there is no corresponding version-controlled member in the
baseline-controlled collection.
- An UPDATE request MUST have been applied to each version-
controlled member for a given version history whose
DAV:checked-in version is not the same as that of the version-
controlled member for that version history in the
DAV:baseline-collection of the baseline.
(DAV:update-subbaselines): If the request updated a version-
controlled configuration whose DAV:baseline-controlled-collection
contains a baseline-controlled member for one of the subbaselines
of the request baseline, then the DAV:checked-in property of the
version-controlled configuration of that baseline-controlled
member MUST have been updated to be that subbaseline. If the
request updated a version-controlled configuration whose
DAV:baseline-controlled-collection is a member of a workspace that
contains a baseline-controlled member for one of the subbaselines
of the request baseline, then the DAV:checked-in property of the
version-controlled configuration of that baseline-controlled
member MUST have been updated to be that subbaseline.
Clemm, et al. Standards Track [Page 88]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:modify-configuration): If the request updated the
DAV:checked-in property of any version-controlled member of a
baseline-controlled collection, and if this DAV:checked-in
property differs from the DAV:checked-in property of the
corresponding version-controlled member of the DAV:baseline-
collection of the DAV:checked-in baseline of the DAV:version-
controlled-configuration of the baseline-controlled collection,
then this is a modification to that version-controlled
configuration, and standard auto-versioning semantics apply.
12.14 Additional MERGE Semantics
If the merge source is a baseline, the merge target is a version-
controlled configuration for the baseline history of that baseline,
where the baseline-controlled collection of that version-controlled
configuration is a member of the collection identified by the
request-URL.
Additional Preconditions:
(DAV:must-not-update-baseline-collection): Same semantics as
UPDATE (see Section 12.13).
(DAV:cannot-modify-version-controlled-configuration): Same
semantics as UPDATE (see Section 12.13).
Additional Postconditions:
(DAV:merge-baseline): If the merge target is a version-controlled
configuration whose DAV:checked-out baseline is not a descendant
of the merge baseline, then the merge baseline MUST have been
added to the DAV:auto-merge-set of a version-controlled
configuration. The DAV:checked-in version of each member of the
DAV:baseline-collection of that baseline MUST have been merged
into the DAV:baseline-controlled-collection of that version-
controlled configuration.
(DAV:merge-subbaselines): If the merge target is a version-
controlled configuration whose DAV:baseline-controlled-collection
contains a baseline-controlled member for one of the subbaselines
of the merge baseline, then that subbaseline MUST have been merged
into the version-controlled configuration of that baseline-
controlled member. If the merge target is a version-controlled
configuration whose DAV:baseline-controlled-collection is a member
of a workspace that contains a baseline-controlled member for one
of the subbaselines of the merge baseline, then that subbaseline
MUST have been merged into the version-controlled configuration of
that baseline-controlled member.
Clemm, et al. Standards Track [Page 89]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:set-baseline-controlled-collection-members): Same semantics
as UPDATE (see Section 12.13).
(DAV:modify-configuration): Same semantics as UPDATE (see Section
12.13).
13 Activity Feature
An activity is a resource that selects a set of versions that are on
a single "line of descent", where a line of descent is a sequence of
versions connected by successor relationships. If an activity
selects versions from multiple version histories, the versions
selected in each version history must be on a single line of descent.
A common problem that motivates the use of activities is that it is
often desirable to perform several different logical changes in a
single workspace, and then selectively merge a subset of those
logical changes to other workspaces. An activity can be used to
represent a single logical change, where an activity tracks all the
resources that were modified to effect that single logical change.
When a version-controlled resource is checked out, the user specifies
which activity should be associated with a new version that will be
created when that version-controlled resource is checked in. It is
then possible to select a particular logical change for merging into
another workspace, by specifying the appropriate activity in a MERGE
request.
Another common problem is that although a version-controlled resource
may need to have multiple lines of descent, all work done by members
of a given team must be on a single line of descent (to avoid merging
between team members). An activity resource provides the mechanism
for addressing this problem. When a version-controlled resource is
checked out, a client can request that an existing activity be used
or that a new activity be created. Activity semantics then ensure
that all versions in a given version history that are associated with
an activity are on a single line of descent. If all members of a
team share a common activity (or sub-activities of a common
activity), then all changes made by members of that team will be on a
single line of descent.
Clemm, et al. Standards Track [Page 90]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates activities. Version V5 is the
latest version of foo.html selected by activity Act-2, and version V8
is the latest version of bar.html selected by activity Act-2.
foo.html History bar.html History
+---+ +---+
Act-1| |V1 Act-1| |V6
+---+ +---+
| |
| |
+---+ +---+
Act-1| |V2 Act-2| |V7
+---+ +---+
/ \ |
/ \ |
+---+ +---+ +---+
Act-1| |V3 Act-2| |V4 Act-2| |V8
+---+ +---+ +---+
| |
| |
+---+ +---+
Act-2| |V5 Act-3| |V9
+---+ +---+
Activities appear under a variety of names in existing versioning
systems. When an activity is used to capture a logical change, it is
commonly called a "change set". When an activity is used to capture
a line of descent, it is commonly called a "branch". When a system
supports both branches and change sets, it is often useful to require
that a particular change set occur on a particular branch. This
relationship can be captured by making the change set activity be a
"subactivity" of the branch activity.
13.1 Activity Properties
The DAV:resourcetype of an activity MUST be DAV:activity.
The activity feature introduces the following REQUIRED properties for
an activity.
13.1.1 DAV:activity-version-set (computed)
This property identifies each version whose DAV:activity-set property
identifies this activity. Multiple versions of a single version
history can be selected by an activity's DAV:activity-version-set
Clemm, et al. Standards Track [Page 91]
RFC 3253 Versioning Extensions to WebDAV March 2002
property, but all DAV:activity-version-set versions from a given
version history must be on a single line of descent from the root
version of that version history.
<!ELEMENT activity-version-set (href*)>
13.1.2 DAV:activity-checkout-set (computed)
This property identifies each checked-out resource whose
DAV:activity-set identifies this activity.
<!ELEMENT activity-checkout-set (href*)>
13.1.3 DAV:subactivity-set
This property identifies each activity that forms a part of the
logical change being captured by this activity. An activity behaves
as if its DAV:activity-version-set is extended by the DAV:activity-
version-set of each activity identified in the DAV:subactivity-set.
In particular, the versions in this extended set MUST be on a single
line of descent, and when an activity selects a version for merging,
the latest version in this extended set is the one that will be
merged.
A server MAY reject attempts to modify the DAV:subactivity-set of an
activity.
<!ELEMENT subactivity-set (href*)>
13.1.4 DAV:current-workspace-set (computed)
This property identifies each workspace whose DAV:current-activity-
set identifies this activity.
<!ELEMENT current-workspace-set (href*)>
13.2 Additional Version Properties
The activity feature introduces the following REQUIRED property for a
version.
Clemm, et al. Standards Track [Page 92]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.2.1 DAV:activity-set
This property identifies the activities that determine to which
logical changes this version contributes, and on which lines of
descent this version appears. A server MAY restrict the
DAV:activity-set to identify a single activity. A server MAY refuse
to allow the value of the DAV:activity-set property of a version to
be modified.
<!ELEMENT activity-set (href*)>
13.3 Additional Checked-Out Resource Properties
The activity feature introduces the following REQUIRED properties for
a checked-out resource.
13.3.1 DAV:unreserved
This property of a checked-out resource indicates whether the
DAV:activity-set of another checked-out resource associated with the
version history of this version-controlled resource can have an
activity that is in the DAV:activity-set property of this checked-out
resource.
A result of the requirement that an activity must form a single line
of descent through a given version history is that if multiple
checked-out resources for a given version history are checked out
unreserved into a single activity, only the first CHECKIN will
succeed. Before another of these checked-out resources can be
checked in, the user will first have to merge into that checked-out
resource the latest version selected by that activity from that
version history, and then modify the DAV:predecessor-set of that
checked-out resource to identify that version.
<!ELEMENT unreserved (#PCDATA)>
PCDATA value: boolean
13.3.2 DAV:activity-set
This property of a checked-out resource determines the DAV:activity-
set property of the version that results from checking in this
resource.
13.4 Additional Workspace Properties
The activity feature introduces the following REQUIRED property for a
workspace.
Clemm, et al. Standards Track [Page 93]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.4.1 DAV:current-activity-set
This property identifies the activities that currently are being
performed in this workspace. When a member of this workspace is
checked out, if no activity is specified in the checkout request, the
DAV:current-activity-set will be used. This allows an activity-
unaware client to update a workspace in which activity tracking is
required. The DAV:current-activity-set MAY be restricted to identify
at most one activity.
<!ELEMENT current-activity-set (href*)>
13.5 MKACTIVITY Method
A MKACTIVITY request creates a new activity resource. A server MAY
restrict activity creation to particular collections, but a client
can determine the location of these collections from a DAV:activity-
collection-set OPTIONS request.
Marshalling:
If a request body is included, it MUST be a DAV:mkactivity XML
element.
<!ELEMENT mkactivity ANY>
If a response body for a successful request is included, it MUST
be a DAV:mkactivity-response XML element.
<!ELEMENT mkactivity-response ANY>
The response MUST include a Cache-Control:no-cache header.
Preconditions:
(DAV:resource-must-be-null): A resource MUST NOT exist at the
request-URL.
(DAV:activity-location-ok): The request-URL MUST identify a
location where an activity can be created.
Postconditions:
(DAV:initialize-activity): A new activity exists at the request-
URL. The DAV:resourcetype of the activity MUST be DAV:activity.
Clemm, et al. Standards Track [Page 94]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.5.1 Example - MKACTIVITY
>>REQUEST
MKACTIVITY /act/test-23 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created
Cache-Control: no-cache
In this example, a new activity is created at
http://repo.webdav.org/act/test-23.
13.6 DAV:latest-activity-version Report
The DAV:latest-activity-version report can be applied to a version
history to identify the latest version that is selected from that
version history by a given activity.
Marshalling:
The request body MUST be a DAV:latest-activity-version XML
element.
<!ELEMENT latest-activity-version (href)>
The response body for a successful request MUST be a DAV:latest-
activity-version-report XML element.
<!ELEMENT latest-activity-version-report (href)>
The DAV:href of the response body MUST identify the version of the
given version history that is a member of the DAV:activity-
version-set of the given activity and has no descendant that is a
member of the DAV:activity-version-set of that activity.
Preconditions:
(DAV:must-be-activity): The DAV:href in the request body MUST
identify an activity.
Clemm, et al. Standards Track [Page 95]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.7 Additional OPTIONS Semantics
If the server supports the activity feature, it MUST include
"activity" as a field in the DAV response header from an OPTIONS
request on any resource that supports any versioning properties,
reports, or methods.
A DAV:activity-collection-set element MAY be included in the request
body to identify collections that may contain activity resources.
Additional Marshalling:
If an XML request body is included, it MUST be a DAV:options XML
element.
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:activity-collection-set element.
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:activity-collection-set element.
<!ELEMENT activity-collection-set (href*)>
If DAV:activity-collection-set is included in the request body,
the response body for a successful request MUST contain a
DAV:activity-collection-set element identifying collections that
may contain activities. An identified collection MAY be the root
collection of a tree of collections, all of which may contain
activities. Since different servers can control different parts
of the URL namespace, different resources on the same host MAY
have different DAV:activity-collection-set values. The identified
collections MAY be located on different hosts from the resource.
13.8 Additional DELETE Semantics
Additional Postconditions:
(DAV:delete-activity-reference): If an activity is deleted, any
reference to that activity in a DAV:activity-set,
DAV:subactivity-set, or DAV:current-activity-set MUST be removed.
Clemm, et al. Standards Track [Page 96]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.9 Additional MOVE Semantics
Additional Postconditions:
(DAV:update-checked-out-reference): If a checked-out resource is
moved, any reference to that resource in a DAV:activity-checkout-
set property MUST be updated to refer to the new location of that
resource.
(DAV:update-activity-reference): If the request-URL identifies an
activity, any reference to that activity in a DAV:activity-set,
DAV:subactivity-set, or DAV:current-activity-set MUST be updated
to refer to the new location of that activity.
(DAV:update-workspace-reference): If the request-URL identifies a
workspace, any reference to that workspace in a DAV:current-
workspace-set property MUST be updated to refer to the new
location of that workspace.
13.10 Additional CHECKOUT Semantics
A CHECKOUT request MAY specify the DAV:activity-set for the checked-
out resource.
Additional Marshalling:
<!ELEMENT checkout ANY> ANY value: A sequence of elements with at
most one DAV:activity-set and at most one DAV:unreserved.
<!ELEMENT activity-set (href+ | new)>
<!ELEMENT new EMPTY>
<!ELEMENT unreserved EMPTY>
Additional Preconditions:
(DAV:one-checkout-per-activity-per-history): If there is a request
activity set, unless DAV:unreserved is specified, another checkout
from a version of that version history MUST NOT select an activity
in that activity set.
(DAV:linear-activity): If there is a request activity set, unless
DAV:unreserved is specified, the selected version MUST be a
descendant of all other versions of that version history that
select that activity.
Clemm, et al. Standards Track [Page 97]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions:
(DAV:initialize-activity-set): The DAV:activity-set of the
checked-out resource is set as follows:
- If DAV:new is specified as the DAV:activity-set in the request
body, then a new activity created by the server is used.
- Otherwise, if activities are specified in the request body,
then those activities are used.
- Otherwise, if the version-controlled resource is a member of a
workspace and the DAV:current-activity-set of the workspace is
set, then those activities are used.
- Otherwise, the DAV:activity-set of the DAV:checked-out version
is used.
(DAV:initialize-unreserved): If DAV:unreserved was specified in
the request body, then the DAV:unreserved property of the
checked-out resource MUST be "true".
13.10.1 Example - CHECKOUT with an activity
>>REQUEST
CHECKOUT /ws/public/foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:checkout xmlns:D="DAV:">
<D:activity-set>
<D:href>http://repo.webdav.org/act/fix-bug-23</D:href>
</D:activity-set>
</D:checkout>
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
In this example, the CHECKOUT is being performed in the
http://repo.webdav.org/act/fix-bug-23 activity.
Clemm, et al. Standards Track [Page 98]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.11 Additional CHECKIN Semantics
Additional Preconditions:
(DAV:linear-activity): Any version which is in the version history
of the checked-out resource and whose DAV:activity-set identifies
an activity from the DAV:activity-set of the checked-out resource
MUST be an ancestor of the checked-out resource.
(DAV:atomic-activity-checkin): If the request-URL identifies an
activity, the server MAY fail the request if any of the checked-
out resources in the DAV:activity-checkout-set of either that
activity or any subactivity of that activity cannot be checked in.
Additional Postconditions:
(DAV:initialize-activity-set): The DAV:activity-set of the new
version MUST have been initialized to be the same as the
DAV:activity-set of the checked-out resource.
(DAV:activity-checkin): If the request-URL identified an activity,
the server MUST have successfully applied the CHECKIN request to
each checked-out resource in the DAV:activity-checkout-set of both
that activity and any subactivity of that activity.
13.12 Additional MERGE Semantics
If the DAV:source element of the request body identifies an activity,
then for each version history containing a version selected by that
activity, the latest version selected by that activity is a merge
source. Note that the versions selected by an activity are the
versions in its DAV:activity-version-set unioned with the versions
selected by the activities in its DAV:subactivity-set.
Additional Marshalling:
<!ELEMENT checkin-activity EMPTY>
Additional Postconditions:
(DAV:checkin-activity): If DAV:checkin-activity is specified in
the request body, and if the DAV:source element in the request
body identifies an activity, a CHECKIN request MUST have been
successfully applied to that activity before the merge sources
were determined.
Clemm, et al. Standards Track [Page 99]
RFC 3253 Versioning Extensions to WebDAV March 2002
14 Version-Controlled-Collection Feature
As with any versionable resource, when a collection is put under
version control, a version history resource is created to contain
versions for that version-controlled collection. In order to
preserve standard versioning semantics (a version of a collection
should not be modifiable), a collection version only records
information about the version-controlled bindings of that collection.
In order to cleanly separate a modification to the namespace from a
modification to content or dead properties, a version of a collection
has no members, but instead records in its DAV:version-controlled-
binding-set property the binding name and version history resource of
each version-controlled internal member of that collection. If,
instead, a collection version contained bindings to other versions,
creating a new version of a resource would require creating a new
version of all the collection versions that contain that resource,
which would cause activities to become entangled. For example,
suppose a "feature-12" activity created a new version of /x/y/a.html.
If a collection version contained bindings to versions of its
members, a new version of /x/y would have to be created to contain
the new version of /x/y/a.html, and a new version of /x would have to
be created to contain the new version of /x/y. Now suppose a
"bugfix-47" activity created a new version of /x/z/b.html. Again, a
new version of /x/z and a new version of /x would have to be created
to contain the new version of /x/y/b.html. But now it is impossible
to merge just "bugfix-47" into another workspace without "feature-
12", because the version of /x that contains the desired version of
/x/z/b.html also contains version of /x/y/a.html created for
"feature-12". If, instead, a collection version just records the
binding name and version history resource of each version-controlled
internal member, changing the version selected by a member of that
collection would not require a new version of the collection. The
new version is still in the same version history so no new collection
version is required, and "feature-12" and "bugfix-47" would not
become entangled.
In the following example, there are three version histories, named
VH14, VH19, and VH24, where VH14 contains versions of a collection.
The version-controlled collection /x has version V2 of version
history VH14 as its DAV:checked-in version. Since V2 has recorded
two version controlled bindings, one with binding name "a" to version
history VH19, and the other with binding name "b" to version history
VH24, /x MUST have two version-controlled bindings, one named "a" to
a version-controlled resource for history VH19, and the other named
"b" to a version-controlled resource for history VH24. The version-
Clemm, et al. Standards Track [Page 100]
RFC 3253 Versioning Extensions to WebDAV March 2002
controlled resource /x/a currently has V4 of VH19 as its
DAV:checked-in version, while /x/b has V8 of VH24 as its
DAV:checked-in version.
VH19
+---------+
| +---+ |
| | |V4 |
| +---+ |
| | |
| | |
| +---+ |
| | |V5 |
VH14 | +---+ |
+---------+ | | |
| +---+ | | | |
a +---+ | | |V1 | | +---+ |
---->| |checked-in=V4 | +---+ | a | | |V6 |
/ +---+ | | ------>| +---+ |
/ | | / | +---------+
+---+ | +---+ |
/x | |checked-in=V2 | | |V2 |
+---+ | +---+ | VH24
\ | | \ | b +---------+
\ b +---+ | | ------>| +---+ |
---->| |checked-in=V8 | +---+ | | | |V7 |
+---+ | | |V3 | | +---+ |
| +---+ | | | |
+---------+ | | |
| +---+ |
| | |V8 |
| +---+ |
| | |
| | |
| +---+ |
| | |V9 |
| +---+ |
+---------+
For any request (e.g., DELETE, MOVE, COPY) that modifies a version-
controlled binding of a checked-in version-controlled collection, the
request MUST fail unless the version-controlled collection has a
DAV:auto-version property that will automatically check out the
version-controlled collection when it is modified.
Although a collection version only records the version-controlled
bindings of a collection, a version-controlled collection MAY contain
both version-controlled and non-version-controlled bindings. Non-
Clemm, et al. Standards Track [Page 101]
RFC 3253 Versioning Extensions to WebDAV March 2002
version-controlled bindings are not under version control, and
therefore can be added or deleted without checking out the version-
controlled collection.
Note that a collection version captures only a defined subset of the
state of a collection. In particular, a version of a collection
captures its dead properties and its bindings to version-controlled
resources, but not its live properties or bindings to non-version-
controlled resources.
When a server supports the working-resource feature, a client can
check out a collection version to create a working collection.
Unlike a version-controlled collection, which contains bindings to
version-controlled resources and non-version-controlled resources, a
working collection contains bindings to version history resources and
non-version-controlled resources. In particular, a working
collection is initialized to contain bindings to the version history
resources specified by the DAV:version-controlled-binding-set of the
checked out collection version. The members of a working collection
can then be deleted or moved to another working collection. Non-
version-controlled resources can be added to a working collection
with methods such as PUT, COPY, and MKCOL. When a working collection
is checked in, a VERSION-CONTROL request is automatically applied to
every non-version-controlled member of the working collection, and
each non-version-controlled member is replaced by its newly created
version history. The DAV:version-controlled-binding-set of the new
version resulting from checking in a working collection contains the
binding name and version history URL for each member of the working
collection.
14.1 Version-Controlled Collection Properties
A version-controlled collection has all the properties of a
collection and of a version-controlled resource. In addition, the
version-controlled-collection feature introduces the following
REQUIRED property for a version-controlled collection.
14.1.1 DAV:eclipsed-set (computed)
This property identifies the non-version-controlled internal members
of the collection that currently are eclipsing a version-controlled
internal member of the collection.
!ELEMENT eclipsed-set (binding-name*)>
<!ELEMENT binding-name (#PCDATA)>
PCDATA value: URL segment
Clemm, et al. Standards Track [Page 102]
RFC 3253 Versioning Extensions to WebDAV March 2002
An UPDATE or MERGE request can give a version-controlled collection a
version-controlled internal member that has the same name as an
existing non-version-controlled internal member. In this case, the
non-version-controlled internal member takes precedence and is said
to "eclipse" the new versioned-controlled internal member. If the
non-version-controlled internal member is removed (e.g., by a DELETE
or MOVE), the version-controlled internal member is exposed.
14.2 Collection Version Properties
A collection version has all the properties of a version. In
addition, the version-controlled-collection feature introduces the
following REQUIRED property for a collection version.
14.2.1 DAV:version-controlled-binding-set (protected)
This property captures the name and version-history of each version-
controlled internal member of a collection.
<!ELEMENT version-controlled-binding-set
(version-controlled-binding*)>
<!ELEMENT version-controlled-binding
(binding-name, version-history)>
<!ELEMENT binding-name (#PCDATA)>
PCDATA value: URL segment
<!ELEMENT version-history (href)>
14.3 Additional OPTIONS Semantics
If the server supports the version-controlled-collection feature, it
MUST include "version-controlled-collection" as a field in the DAV
response header from an OPTIONS request on any resource that supports
any versioning properties, reports, or methods.
14.4 Additional DELETE Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the request-URL
identifies a version-controlled resource, the DELETE MUST fail
when the collection containing the version-controlled resource is
a checked-in version-controlled collection, unless DAV:auto-
version semantics will automatically check out the version-
controlled collection.
Clemm, et al. Standards Track [Page 103]
RFC 3253 Versioning Extensions to WebDAV March 2002
14.5 Additional MKCOL Semantics
Additional Preconditions:
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
Additional Postconditions:
If the new collection is automatically put under version control,
all postconditions for VERSION-CONTROL apply to the request.
14.6 Additional COPY Semantics
Additional Preconditions:
(DAV:cannot-copy-collection-version): If the source of the request
is a collection version, the request MUST fail.
14.7 Additional MOVE Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the source of the
request is a version-controlled resource, the request MUST fail
when the collection containing the source is a checked-in
version-controlled collection, unless DAV:auto-version semantics
will automatically check out that version-controlled collection.
(DAV:cannot-modify-destination-checked-in-parent): If the source
of the request is a version-controlled resource, the request MUST
fail when the collection containing the destination is a checked-
in version-controlled collection, unless DAV:auto-version
semantics will automatically check out that version-controlled
collection.
14.8 Additional VERSION-CONTROL Semantics
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the parent of the
request-URL is a checked-in version-controlled collection, the
request MUST fail unless DAV:auto-version semantics will
automatically check out that version-controlled collection.
Clemm, et al. Standards Track [Page 104]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions:
(DAV:new-version-controlled-collection): If the request body
identified a collection version, the collection at the request-URL
MUST contain a version-controlled internal member for each
DAV:version-controlled-binding specified in the DAV:version-
controlled-binding-set of the collection version, where the name
and DAV:version-history of the internal member MUST be the
DAV:binding-name and the DAV:version-history specified by the
DAV:version-controlled-binding. If the internal member is a
member of a workspace, and there is another member of the
workspace for the same version history, those two members MUST
identify the same version-controlled resource; otherwise, a
VERSION-CONTROL request with a server selected version of the
version history MUST have been applied to the URL for that
internal member.
14.9 Additional CHECKOUT Semantics
Additional Postconditions:
(DAV:initialize-version-history-bindings): If the request has been
applied to a collection version, the new working collection MUST
be initialized to contain a binding to each of the history
resources identified in the DAV:version-controlled-binding-set of
that collection version.
14.10 Additional CHECKIN Semantics
Additional Postconditions:
(DAV:initialize-version-controlled-bindings): If the request-URL
identified a version-controlled collection, then the DAV:version-
controlled-binding-set of the new collection version MUST contain
a DAV:version-controlled-binding that identifies the binding name
and version history for each version-controlled binding of the
version- controlled collection.
(DAV:version-control-working-collection-members): If the request-
URL identified a working collection, a VERSION-CONTROL request
MUST have been automatically applied to every non-version-
controlled member of the working collection, and each non-
version-controlled member MUST have been replaced by its newly
created version history. If a working collection member was a
non-version-controlled collection, every member of the non-
version-controlled collection MUST have been placed under version
Clemm, et al. Standards Track [Page 105]
RFC 3253 Versioning Extensions to WebDAV March 2002
control before the non-version-controlled collection was placed
under version control. The DAV:version-controlled-binding-set of
the new collection version MUST contain a DAV:version-controlled-
binding that identifies the binding name and the version history
URL for each member of the working collection.
14.11 Additional UPDATE and MERGE Semantics
Additional Postconditions:
(DAV:update-version-controlled-collection-members): If the request
modified the DAV:checked-in version of a version-controlled
collection, then the version-controlled members of that version-
controlled collection MUST have been updated. In particular:
- A version-controlled internal member MUST have been deleted if
its version history is not identified by the DAV:version-
controlled-binding-set of the new DAV:checked-in version.
- A version-controlled internal member for a given version
history MUST have been renamed if its binding name differs from
the DAV:binding-name for that version history in the
DAV:version-controlled-binding-set of the new DAV:checked-in
version.
- A new version-controlled internal member MUST have been created
when a version history is identified by the DAV:version-
controlled-binding-set of the DAV:checked-in version, but there
was no member of the version-controlled collection for that
version history. If a new version-controlled member is in a
workspace that already has a version-controlled resource for
that version history, then the new version-controlled member
MUST be just a binding (i.e., another name for) that existing
version-controlled resource. Otherwise, the content and dead
properties of the new version-controlled member MUST have been
initialized to be those of the version specified for that
version history by the request. If no version is specified for
that version history by the request, the version selected is
server defined.
15 Internationalization Considerations
This specification has been designed to be compliant with the IETF
Policy on Character Sets and Languages [RFC2277]. Specifically,
where human-readable strings exist in the protocol, either their
charset is explicitly stated, or XML mechanisms are used to specify
the charset used. Additionally, these human-readable strings all
have the ability to express the natural language of the string.
Clemm, et al. Standards Track [Page 106]
RFC 3253 Versioning Extensions to WebDAV March 2002
Most of the human-readable strings in this protocol appear in
properties, such as DAV:creator-displayname. As defined by RFC 2518,
properties have their values marshaled as XML. XML has explicit
provisions for character set tagging and encoding, and requires that
XML processors read XML elements encoded, at minimum, using the UTF-8
[RFC2279] encoding of the ISO 10646 multilingual plane. The charset
parameter of the Content-Type header, together with the XML
"encoding" attribute, provide charset identification information for
MIME and XML processors. Proper use of the charset header with XML
is described in RFC 3023. XML also provides a language tagging
capability for specifying the language of the contents of a
particular XML element. XML uses either IANA registered language
tags (see RFC 3066) or ISO 639 language tags in the "xml:lang"
attribute of an XML element to identify the language of its content
and attributes.
DeltaV applications, since they build upon WebDAV, are subject to the
internationalization requirements specified in RFC 2518, Section 16.
In brief, these requirements mandate the use of XML character set
tagging, character set encoding, and language tagging capabilities.
Additionally, they strongly recommend reading RFC 3023 for
instruction on the use of MIME media types for XML transport and the
use of the charset header.
Within this specification, a label is a human-readable string that is
marshaled in the Label header and as XML in request entity bodies.
When used in the Label header, the value of the label is URL-escaped
and encoded using UTF-8.
16 Security Considerations
All of the security considerations of WebDAV discussed in RFC 2518,
Section 17 also apply to WebDAV versioning. Some aspects of the
versioning protocol help address security risks introduced by WebDAV,
but other aspects can increase these security risks. These issues
are detailed below.
16.1 Auditing and Traceability
WebDAV increases the ease with which a remote client can modify
resources on a web site, but this also increases the risk of
important information being overwritten and lost, either through user
error or user maliciousness. The use of WebDAV versioning can help
address this problem by guaranteeing that previous information is
saved in the form of immutable versions, and therefore is easily
available for retrieval or restoration. In addition, the version
history provides a log of when changes were made, and by whom. When
requests are appropriately authenticated, the history mechanism
Clemm, et al. Standards Track [Page 107]
RFC 3253 Versioning Extensions to WebDAV March 2002
provides a clear audit trail for changes to web resources. This can
often significantly improve the ability to identify the source of the
security problem, and thereby help guard against it in the future.
16.2 Increased Need for Access Control
WebDAV versioning provides a variety of links between related pieces
of information. This can increase the risk that authentication or
authorization errors allow a client to locate sensitive information.
For example, if version history is not appropriately protected by
access control, a client can use the version history of a public
resource to identify later versions of that resource that the user
intended to keep private. This increases the need for reliable
authentication and accurate authorization.
A WebDAV versioning client should be designed to handle a mixture of
200 (OK) and 403 (Forbidden) responses on attempts to access the
properties and reports that are supported by a resource. For
example, a particular user may be authorized to access the content
and dead properties of a version-controlled resource, but not be
authorized to access the DAV:checked-in, DAV:checked-out, or
DAV:version-history properties of that resource.
16.3 Security Through Obscurity
While it is acknowledged that "obscurity" is not an effective means
of security, it is often a good technique to keep honest people
honest. Within this protocol, version URLs, version history URLs,
and working resource URLs are generated by the server and can be
properly obfuscated so as not to draw attention to them. For
example, a version of "http://foobar.com/reviews/salaries.html" might
be assigned a URL such as "http://foobar.com/repo/4934943".
16.4 Denial of Service
The auto-versioning mechanism provided by WebDAV can result in a
large number of resources being created on the server, since each
update to a resource could potentially result in the creation of a
new version resource. This increases the risk of a denial of service
attack that exhausts the storage capability of a server. This risk
is especially significant because it can be an unintentional result
of something like an aggressive auto-save feature provided by an
editing client. A server can decrease this risk by using delta
storage techniques to minimize the cost of additional versions, and
by limiting auto-versioning to a locking client, and thereby
decreasing the number of inadvertent version creations.
Clemm, et al. Standards Track [Page 108]
RFC 3253 Versioning Extensions to WebDAV March 2002
17 IANA Considerations
This document uses the namespace defined by RFC 2518 for XML
elements. All other IANA considerations from RFC 2518 are also
applicable to WebDAV Versioning.
18 Intellectual Property
The following notice is copied from RFC 2026, Section 10.4, and
describes the position of the IETF concerning intellectual property
claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
procedures of the IETF with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
19 Acknowledgements
This protocol is the collaborative product of the authors and the
rest of the DeltaV design team: Boris Bokowski, Bruce Cragun
(Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa
Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale
(Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI),
Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric
Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta
(Rational). We would like to acknowledge the foundation laid for us
by the authors of the WebDAV and HTTP protocols upon which this
protocol is layered, and the invaluable feedback from the WebDAV and
DeltaV working groups.
Clemm, et al. Standards Track [Page 109]
RFC 3253 Versioning Extensions to WebDAV March 2002
20 References
[ISO639] ISO, "Code for the representation of names of languages",
ISO 639:1988, 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring -
WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T.Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
Clemm, et al. Standards Track [Page 110]
RFC 3253 Versioning Extensions to WebDAV March 2002
Appendix A - Resource Classification
This document introduces several different kinds of versioning
resources, such as version-controlled resources, versions, checked-
out resources, and version history resources. As clients discover
resources on a server, they may find it useful to classify those
resources (for example, to make UI decisions on choice of icon and
menu options).
Clients should classify a resource by examining the values of the
DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live-
property-set (see Section 3.1.4) properties of that resource.
The following list shows the supported live properties and methods
for each kind of versioning resource. Where an optional feature
introduces a new kind of versioning resource, that feature is noted
in parentheses following the name of that kind of versioning
resource. If a live property or method is optional for a kind of
versioning resource, the feature that introduces that live property
or method is noted in parentheses following the live property or
method name.
A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)
Supported methods:
- PUT [RFC2616]
- MKCOL [RFC2518]
- MKACTIVITY (activity)
- VERSION-CONTROL (workspace)
- MKWORKSPACE (workspace)
A.2 DeltaV-Compliant Resource
Supported live properties:
- DAV:comment
- DAV:creator-displayname
- DAV:supported-method-set
- DAV:supported-live-property-set
- DAV:supported-report-set
- all properties defined in WebDAV [RFC2518].
Clemm, et al. Standards Track [Page 111]
RFC 3253 Versioning Extensions to WebDAV March 2002
Supported methods:
- REPORT
- all methods defined in WebDAV [RFC2518]
- all methods defined in HTTP/1.1 [RFC2616].
A.3 DeltaV-Compliant Collection
Supported live properties:
- all DeltaV-compliant resource properties.
Supported methods:
- BASELINE-CONTROL (baseline)
- all DeltaV-compliant resource methods.
A.4 Versionable Resource
Supported live properties:
- DAV:workspace (workspace)
- DAV:version-controlled-configuration (baseline)
- all DeltaV-compliant resource properties.
Supported methods:
- VERSION-CONTROL
- all DeltaV-compliant resource methods.
A.5 Version-Controlled Resource
Supported live properties:
- DAV:auto-version
- DAV:version-history (version-history)
- DAV:workspace (workspace)
- DAV:version-controlled-configuration (baseline)
- all DeltaV-compliant resource properties.
Supported methods:
- VERSION-CONTROL
- MERGE (merge)
- all DeltaV-compliant resource methods.
Clemm, et al. Standards Track [Page 112]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.6 Version
Supported live properties:
- DAV:predecessor-set
- DAV:successor-set
- DAV:checkout-set
- DAV:version-name
- DAV:checkout-fork (in-place-checkout or working resource)
- DAV:checkin-fork (in-place-checkout or working resource)
- DAV:version-history (version-history)
- DAV:label-name-set (label)
- DAV:activity-set (activity)
- all DeltaV-compliant resource properties.
Supported methods:
- LABEL (label)
- CHECKOUT (working-resource)
- all DeltaV-compliant resource methods.
A.7 Checked-In Version-Controlled Resource
Supported live properties:
- DAV:checked-in
- all version-controlled resource properties.
Supported methods:
- CHECKOUT (checkout-in-place)
- UPDATE (update)
- all version-controlled resource methods.
A.8 Checked-Out Resource
Supported live properties:
- DAV:checked-out
- DAV:predecessor-set
- DAV:checkout-fork (in-place-checkout or working resource)
- DAV:checkin-fork (in-place-checkout or working resource)
- DAV:merge-set (merge)
- DAV:auto-merge-set (merge)
- DAV:unreserved (activity)
- DAV:activity-set (activity)
Clemm, et al. Standards Track [Page 113]
RFC 3253 Versioning Extensions to WebDAV March 2002
Supported methods:
- CHECKIN (checkout-in-place or working-resource)
- all DeltaV-compliant resource methods.
A.9 Checked-Out Version-Controlled Resource (checkout-in-place)
Supported live properties:
- all version-controlled resource properties.
- all checked-out resource properties.
Supported methods:
- UNCHECKOUT
- all version-controlled resource methods.
- all checked-out resource methods.
A.10 Working Resource (working-resource)
Supported live properties:
- all DeltaV-compliant resource properties
- all checked-out resource properties
- DAV:auto-update.
Supported methods:
- all checked-out resource methods.
A.11 Version History (version-history)
Supported live properties:
- DAV:version-set
- DAV:root-version
- all DeltaV-compliant resource properties.
Supported methods:
- all DeltaV-compliant resource methods.
Clemm, et al. Standards Track [Page 114]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.12 Workspace (workspace)
Supported live properties:
- DAV:workspace-checkout-set
- DAV:baseline-controlled-collection-set (baseline)
- DAV:current-activity-set (activity)
- all DeltaV-compliant collection properties.
Supported methods:
- all DeltaV-compliant collection methods.
A.13 Activity (activity)
Supported live properties:
- DAV:activity-version-set
- DAV:activity-checkout-set
- DAV:subactivity-set
- DAV:current-workspace-set
- all DeltaV-compliant resource properties.
Supported methods:
- all DeltaV-compliant resource methods.
A.14 Version-Controlled Collection (version-controlled-collection)
Supported live properties:
- DAV:eclipsed-set
- all version-controlled resource properties.
Supported methods:
- all version-controlled resource methods.
A.15 Collection Version (version-controlled-collection)
Supported live properties:
- DAV:version-controlled-binding-set
- all version properties.
Supported methods:
- all version methods.
Clemm, et al. Standards Track [Page 115]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.16 Version-Controlled Configuration (baseline)
Supported live properties:
- DAV:baseline-controlled-collection
- all version-controlled resource properties.
Supported methods:
- all version-controlled resource methods.
A.17 Baseline (baseline)
Supported live properties:
- DAV:baseline-collection
- DAV:subbaseline-set
- all version properties.
Supported methods:
- all version methods.
A.18 Checked-Out Version-Controlled Configuration (baseline)
Supported live properties:
- DAV:subbaseline-set
- all version-controlled configuration properties.
Supported methods:
- all version-controlled configuration methods.
Clemm, et al. Standards Track [Page 116]
RFC 3253 Versioning Extensions to WebDAV March 2002
Authors' Addresses
Geoffrey Clemm
Rational Software
20 Maguire Road, Lexington, MA 02421
EMail: geoffrey.clemm@rational.com
Jim Amsden
IBM
3039 Cornwallis, Research Triangle Park, NC 27709
EMail: jamsden@us.ibm.com
Tim Ellison
IBM
Hursley Park, Winchester, UK S021 2JN
EMail: tim_ellison@uk.ibm.com
Christopher Kaler
Microsoft
One Microsoft Way, Redmond, WA 90852
EMail: ckaler@microsoft.com
Jim Whitehead
UC Santa Cruz, Dept. of Computer Science
1156 High Street, Santa Cruz, CA 95064
EMail: ejw@cse.ucsc.edu
Clemm, et al. Standards Track [Page 117]
RFC 3253 Versioning Extensions to WebDAV March 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Clemm, et al. Standards Track [Page 118]
|