Browse Source

Update SabreDAV from 1.8.9 to 1.8.10.

Klaus Weidenbach 5 years ago
parent
commit
03b31d113e
100 changed files with 235 additions and 115089 deletions
  1. 1 1
      vendor/autoload.php
  2. 4 3
      vendor/composer/ClassLoader.php
  3. 0 1
      vendor/composer/autoload_namespaces.php
  4. 4 7
      vendor/composer/autoload_real.php
  5. 8 54
      vendor/composer/installed.json
  6. 1 0
      vendor/sabre/dav/.travis.yml
  7. 24 0
      vendor/sabre/dav/ChangeLog
  8. 137 0
      vendor/sabre/dav/bin/build.php
  9. 0 72
      vendor/sabre/dav/build.xml
  10. 0 336
      vendor/sabre/dav/docs/caldav-ctag.txt
  11. 0 1568
      vendor/sabre/dav/docs/caldav-notifications.txt
  12. 0 560
      vendor/sabre/dav/docs/caldav-proxy.txt
  13. 0 1624
      vendor/sabre/dav/docs/caldav-sharing.txt
  14. 0 560
      vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt
  15. 0 5544
      vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt
  16. 0 5152
      vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt
  17. 0 1512
      vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
  18. 0 1512
      vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
  19. 0 2352
      vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
  20. 0 560
      vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt
  21. 0 1851
      vendor/sabre/dav/docs/rfc2425.txt
  22. 0 2355
      vendor/sabre/dav/docs/rfc2426.txt
  23. 0 5267
      vendor/sabre/dav/docs/rfc2518.txt
  24. 0 9859
      vendor/sabre/dav/docs/rfc2616.txt
  25. 0 1907
      vendor/sabre/dav/docs/rfc2617.txt
  26. 0 10329
      vendor/sabre/dav/docs/rfc3253.pdf
  27. 0 6295
      vendor/sabre/dav/docs/rfc3744.pdf
  28. 0 3127
      vendor/sabre/dav/docs/rfc4437.pdf
  29. 0 1459
      vendor/sabre/dav/docs/rfc4790.txt
  30. 0 5995
      vendor/sabre/dav/docs/rfc4791.txt
  31. 0 13609
      vendor/sabre/dav/docs/rfc4918.pdf
  32. 0 395
      vendor/sabre/dav/docs/rfc5051.txt
  33. 0 281
      vendor/sabre/dav/docs/rfc5397.txt
  34. 0 9411
      vendor/sabre/dav/docs/rfc5545.txt
  35. 0 7451
      vendor/sabre/dav/docs/rfc5546.txt
  36. 0 675
      vendor/sabre/dav/docs/rfc5689.txt
  37. 0 451
      vendor/sabre/dav/docs/rfc5785.txt
  38. 0 563
      vendor/sabre/dav/docs/rfc5789.txt
  39. 0 1235
      vendor/sabre/dav/docs/rfc6047.txt
  40. 0 3027
      vendor/sabre/dav/docs/rfc6321.txt
  41. 0 4147
      vendor/sabre/dav/docs/rfc6350.txt
  42. 0 1235
      vendor/sabre/dav/docs/rfc6351.txt
  43. 0 2691
      vendor/sabre/dav/docs/rfc6352.txt
  44. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Backend/AbstractBackend.php
  45. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Backend/BackendInterface.php
  46. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Backend/NotificationSupport.php
  47. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Backend/PDO.php
  48. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Backend/SharingSupport.php
  49. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Calendar.php
  50. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/CalendarObject.php
  51. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/CalendarQueryParser.php
  52. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/CalendarQueryValidator.php
  53. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/CalendarRootNode.php
  54. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Exception/InvalidComponentType.php
  55. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/ICSExportPlugin.php
  56. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/ICalendar.php
  57. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/ICalendarObject.php
  58. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/IShareableCalendar.php
  59. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/ISharedCalendar.php
  60. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Collection.php
  61. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/ICollection.php
  62. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/INode.php
  63. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/INotificationType.php
  64. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Node.php
  65. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/Invite.php
  66. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/InviteReply.php
  67. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/SystemStatus.php
  68. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Plugin.php
  69. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/Collection.php
  70. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/IProxyRead.php
  71. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/IProxyWrite.php
  72. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/ProxyRead.php
  73. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/ProxyWrite.php
  74. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Principal/User.php
  75. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/AllowedSharingModes.php
  76. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/Invite.php
  77. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/ScheduleCalendarTransp.php
  78. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCalendarComponentSet.php
  79. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCalendarData.php
  80. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCollationSet.php
  81. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/IMip.php
  82. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/IOutbox.php
  83. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/Outbox.php
  84. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/ShareableCalendar.php
  85. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/SharedCalendar.php
  86. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/SharingPlugin.php
  87. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/UserCalendars.php
  88. 1 1
      vendor/sabre/dav/lib/Sabre/CalDAV/Version.php
  89. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/AddressBook.php
  90. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/AddressBookQueryParser.php
  91. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/AddressBookRoot.php
  92. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/Backend/AbstractBackend.php
  93. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/Backend/BackendInterface.php
  94. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/Backend/PDO.php
  95. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/Card.php
  96. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/IAddressBook.php
  97. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/ICard.php
  98. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/IDirectory.php
  99. 1 1
      vendor/sabre/dav/lib/Sabre/CardDAV/Plugin.php
  100. 0 0
      vendor/sabre/dav/lib/Sabre/CardDAV/Property/SupportedAddressData.php

+ 1 - 1
vendor/autoload.php

@@ -4,4 +4,4 @@
 
 require_once __DIR__ . '/composer' . '/autoload_real.php';
 
-return ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf::getLoader();
+return ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d::getLoader();

+ 4 - 3
vendor/composer/ClassLoader.php

@@ -202,10 +202,11 @@ class ClassLoader
      * Registers a set of PSR-4 directories for a given namespace,
      * replacing any others previously set for this namespace.
      *
-     * @param string       $prefix  The prefix/namespace, with trailing '\\'
-     * @param array|string $paths   The PSR-4 base directories
+     * @param string       $prefix The prefix/namespace, with trailing '\\'
+     * @param array|string $paths  The PSR-4 base directories
      */
-    public function setPsr4($prefix, $paths) {
+    public function setPsr4($prefix, $paths)
+    {
         if (!$prefix) {
             $this->fallbackDirsPsr4 = (array) $paths;
         } else {

+ 0 - 1
vendor/composer/autoload_namespaces.php

@@ -12,5 +12,4 @@ return array(
     'Sabre\\DAV' => array($vendorDir . '/sabre/dav/lib'),
     'Sabre\\CardDAV' => array($vendorDir . '/sabre/dav/lib'),
     'Sabre\\CalDAV' => array($vendorDir . '/sabre/dav/lib'),
-    'Monolog' => array($vendorDir . '/monolog/monolog/src'),
 );

+ 4 - 7
vendor/composer/autoload_real.php

@@ -2,7 +2,7 @@
 
 // autoload_real.php @generated by Composer
 
-class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
+class ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d
 {
     private static $loader;
 
@@ -19,12 +19,9 @@ class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
             return self::$loader;
         }
 
-        spl_autoload_register(array('ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf', 'loadClassLoader'), true, true);
+        spl_autoload_register(array('ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d', 'loadClassLoader'), true, true);
         self::$loader = $loader = new \Composer\Autoload\ClassLoader();
-        spl_autoload_unregister(array('ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf', 'loadClassLoader'));
-
-        $vendorDir = dirname(__DIR__);
-        $baseDir = dirname($vendorDir);
+        spl_autoload_unregister(array('ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d', 'loadClassLoader'));
 
         $map = require __DIR__ . '/autoload_namespaces.php';
         foreach ($map as $namespace => $path) {
@@ -47,7 +44,7 @@ class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
     }
 }
 
-function composerRequired0f40897631bfac5572c9d06d82344bf($file)
+function composerRequirea478c0bdc9041edcc4f485e8fb39b90d($file)
 {
     require $file;
 }

+ 8 - 54
vendor/composer/installed.json

@@ -1,49 +1,4 @@
 [
-    {
-        "name": "monolog/monolog",
-        "version": "1.0.2",
-        "version_normalized": "1.0.2.0",
-        "source": {
-            "type": "git",
-            "url": "https://github.com/Seldaek/monolog.git",
-            "reference": "b704c49a3051536f67f2d39f13568f74615b9922"
-        },
-        "dist": {
-            "type": "zip",
-            "url": "https://api.github.com/repos/Seldaek/monolog/zipball/b704c49a3051536f67f2d39f13568f74615b9922",
-            "reference": "b704c49a3051536f67f2d39f13568f74615b9922",
-            "shasum": ""
-        },
-        "require": {
-            "php": ">=5.3.0"
-        },
-        "time": "2011-10-24 09:39:02",
-        "type": "library",
-        "installation-source": "dist",
-        "autoload": {
-            "psr-0": {
-                "Monolog": "src/"
-            }
-        },
-        "notification-url": "https://packagist.org/downloads/",
-        "license": [
-            "MIT"
-        ],
-        "authors": [
-            {
-                "name": "Jordi Boggiano",
-                "email": "j.boggiano@seld.be",
-                "homepage": "http://seld.be",
-                "role": "Developer"
-            }
-        ],
-        "description": "Logging for PHP 5.3",
-        "homepage": "http://github.com/Seldaek/monolog",
-        "keywords": [
-            "log",
-            "logging"
-        ]
-    },
     {
         "name": "sabre/vobject",
         "version": "2.1.4",
@@ -96,17 +51,17 @@
     },
     {
         "name": "sabre/dav",
-        "version": "1.8.9",
-        "version_normalized": "1.8.9.0",
+        "version": "1.8.10",
+        "version_normalized": "1.8.10.0",
         "source": {
             "type": "git",
             "url": "https://github.com/fruux/sabre-dav.git",
-            "reference": "25e095469e44d195cd255bdce55ce473224558bc"
+            "reference": "0d064536ed3c7974e486b6ebb5b17ad7a974fe18"
         },
         "dist": {
             "type": "zip",
-            "url": "https://api.github.com/repos/fruux/sabre-dav/zipball/25e095469e44d195cd255bdce55ce473224558bc",
-            "reference": "25e095469e44d195cd255bdce55ce473224558bc",
+            "url": "https://api.github.com/repos/fruux/sabre-dav/zipball/0d064536ed3c7974e486b6ebb5b17ad7a974fe18",
+            "reference": "0d064536ed3c7974e486b6ebb5b17ad7a974fe18",
             "shasum": ""
         },
         "require": {
@@ -127,15 +82,14 @@
         },
         "require-dev": {
             "evert/phpdoc-md": "~0.0.7",
-            "phing/phing": "2.4.14",
-            "phpunit/phpunit": "3.7.*"
+            "phpunit/phpunit": "~4.0.0"
         },
         "suggest": {
             "ext-apc": "*",
             "ext-curl": "*",
             "ext-pdo": "*"
         },
-        "time": "2014-02-26 22:17:11",
+        "time": "2014-05-16 00:14:02",
         "bin": [
             "bin/sabredav"
         ],
@@ -157,7 +111,7 @@
         "authors": [
             {
                 "name": "Evert Pot",
-                "email": "evert@rooftopsolutions.nl",
+                "email": "me@evertpot.com",
                 "homepage": "http://evertpot.com/",
                 "role": "Developer"
             }

+ 1 - 0
vendor/sabre/dav/.travis.yml

@@ -17,6 +17,7 @@ services:
 
 before_script:
   - mysql -e 'create database sabredav'
+  - composer self-update
   - composer install --prefer-source
 #  - echo "zend.enable_gc=0" >> `php --ini | grep "Loaded Configuration" | sed -e "s|.*:\s*||"`
 

+ 24 - 0
vendor/sabre/dav/ChangeLog

@@ -1,3 +1,7 @@
+1.8.10-stable (2014-05-15)
+	* The zip release ships with sabre/vobject 2.1.4.
+	* includes changes from version 1.7.12.
+
 1.8.9-stable (2014-02-26)
 	* The zip release ships with sabre/vobject 2.1.3.
 	* includes changes from version 1.7.11.
@@ -57,6 +61,26 @@
 	* Added: The Proxy principal classes now both implement an interface, for
 	  greater flexiblity.
 
+1.7.13-stable (????-??-??)
+	* Changed: Removed phing and went with a custom build script for now.
+
+1.7.12-stable (2014-05-15)
+	* The zip release ships with sabre/vobject 2.1.4.
+	* Updated: Issue #439. Lots of updates in PATCH support. The
+	  Sabre_DAV_PartialUpdate_IFile interface is now deprecated and will be
+	  removed in a future version.
+	* Fixed: Restoring old setting after changing
+	  libxml_disable_entity_loader.
+	* Fixed: Issue #422: Preconditions were not being set on PUT on non-
+	  existant files. Not really a chance for data-loss, but incorrect
+	  nevertheless.
+	* Fixed: Issue #427: Now checking preconditions on DELETE requests.
+	* Fixed: Issue #428: Etag check with If: fails if the target is a
+	  collection.
+	* Fixed: Issue #393: PATCH request with missing end-range was handled
+	  incorrectly.
+	* Added: Sabre_DAV_Exception_LengthRequired to omit 411 errors.
+
 1.7.11-stable (2014-02-26)
 	* The zip release ships with sabre/vobject 2.1.3.
 	* Fixed: Issue #407: large downloads failed.

+ 137 - 0
vendor/sabre/dav/bin/build.php

@@ -0,0 +1,137 @@
+<?php
+
+$tasks = [
+
+    'buildzip' => [
+        'init', 'test', 'clean',
+    ],
+    'markrelease' => [
+        'init', 'test', 'clean',
+    ],
+    'clean' => [],
+    'test' => [
+        'composerupdate',
+    ],
+    'init' => [],
+    'composerupdate' => [],
+ ];
+
+$default = 'buildzip';
+
+$baseDir = __DIR__ . '/../';
+chdir($baseDir);
+
+$currentTask = $default;
+if ($argc > 1) $currentTask = $argv[1];
+$version = null;
+if ($argc > 2) $version = $argv[2];
+
+if (!isset($tasks[$currentTask])) {
+    echo "Task not found: ",  $currentTask, "\n";
+    die(1);
+}
+
+// Creating the dependency graph
+$newTaskList = [];
+$oldTaskList = [$currentTask => true];
+
+while(count($oldTaskList)>0) {
+
+    foreach($oldTaskList as $task=>$foo) {
+
+        if (!isset($tasks[$task])) {
+            echo "Dependency not found: " . $task, "\n";
+            die(1);
+        }
+        $dependencies = $tasks[$task];
+
+        $fullFilled = true;
+        foreach($dependencies as $dependency) {
+            if (isset($newTaskList[$dependency])) {
+                // Already in the fulfilled task list.
+                continue;
+            } else {
+                $oldTaskList[$dependency] = true;
+                $fullFilled = false;
+            }
+           
+        }
+        if ($fullFilled) {
+            unset($oldTaskList[$task]);
+            $newTaskList[$task] = 1;
+        }
+
+    }
+
+}
+
+foreach(array_keys($newTaskList) as $task) {
+
+    echo "task: " . $task, "\n";
+    call_user_func($task);
+    echo "\n";
+
+}
+
+function init() {
+
+    global $version;
+    if (!$version) {
+        include __DIR__ . '/../vendor/autoload.php';
+        $version = Sabre\DAV\Version::VERSION;
+    }
+
+    echo "  Building sabre/dav " . $version, "\n";
+
+}
+
+function clean() {
+
+    global $baseDir;
+    echo "  Removing build files\n";
+    $outputDir = $baseDir . '/build/SabreDAV';
+    if (is_dir($outputDir)) {
+        system('rm -r ' . $baseDir . '/build/SabreDAV');
+    }
+
+}
+
+function composerupdate() {
+
+    global $baseDir;
+    echo "  Updating composer packages to latest version\n\n";
+    system('cd ' . $baseDir . '; composer update --dev');
+}
+
+function test() {
+
+    global $baseDir;
+
+    echo "  Running all unittests.\n";
+    echo "  This may take a while.\n\n";
+    system(__DIR__ . '/phpunit --configuration ' . $baseDir . '/tests/phpunit.xml --stop-on-failure', $code);
+    if ($code != 0) {
+        echo "PHPUnit reported error code $code\n";
+        die(1);
+    }
+   
+}
+
+function buildzip() {
+
+    global $baseDir, $version;
+    echo "  Asking composer to download sabre/dav $version\n\n";
+    system("composer create-project --no-dev sabre/dav build/SabreDAV $version", $code);
+    if ($code!==0) {
+        echo "Composer reported error code $code\n";
+        die(1);
+    }
+    // <zip destfile="build/SabreDAV-${sabredav.version}.zip" basedir="build/SabreDAV" prefix="SabreDAV/" />
+
+    echo "\n";
+    echo "Zipping the sabredav distribution\n\n";
+    system('cd build; zip -qr sabredav-' . $version . '.zip SabreDAV');
+
+    echo "Done.";
+
+}

+ 0 - 72
vendor/sabre/dav/build.xml

@@ -1,72 +0,0 @@
-<?xml version="1.0"?>
-<project name="SabreDAV" default="buildzip" basedir=".">
-
-    <!-- Any default properties -->
-    <property file="build.properties" />
-
-    <!-- Where to write api documentation -->
-    <property name="sabredav.apidocspath" value="docs/api" />
-
-    <target name="buildzip" depends="init, test, clean">
-        <mkdir dir="build" />
-        <echo>Running composer</echo>
-        <exec command="composer create-project --no-dev sabre/dav build/SabreDAV ${sabredav.version}" checkreturn="false" passthru="1" />
-        <zip destfile="build/SabreDAV-${sabredav.version}.zip" basedir="build/SabreDAV" prefix="SabreDAV/" />
-    </target>
-
-    <target name="clean" depends="init">
-        <echo msg="Removing build files (cleaning up distribution)" />
-        <delete dir="docs/api" />
-        <delete dir="build" />
-    </target>
-
-    <target name="markrelease" depends="init,clean,test">
-        <echo>Creating Git release tag</echo>
-        <exec command="git tag ${sabredav.version}" checkreturn="false" passthru="1" />
-    </target>
-
-    <target name="test">
-        <phpunit haltonfailure="1" haltonerror="1" bootstrap="tests/bootstrap.php" haltonskipped="1" printsummary="1">
-          <batchtest>
-            <fileset dir="tests">
-              <include name="**/*.php"/>
-            </fileset>
-          </batchtest>
-        </phpunit>
-    </target>
-
-    <target name="apidocs" depends="init">
-
-        <echo>Creating api documentation using PHP documentor</echo>
-        <echo>Writing to ${sabredav.apidocspath}</echo>
-        <exec command="phpdoc parse -t ${sabredav.apidocspath} -d lib/" passthru="1" />
-        <exec command="bin/phpdocmd ${sabredav.apidocspath}/structure.xml ${sabredav.apidocspath} --lt %c" passthru="1" />
-        <!--<delete file="${sabredav.apidocspath}/structure.xml" />-->
-
-    </target>
-
-    <target name="init">
-
-        <!-- This sets SabreDAV version information -->
-        <adhoc-task name="sabredav-version"><![CDATA[
-
-            class SabreDAV_VersionTask extends Task {
-
-                public function main() {
-
-                    include_once 'lib/Sabre/DAV/Version.php';
-                    $this->getProject()->setNewProperty('sabredav.version',\Sabre\DAV\Version::VERSION);
-                    $this->getProject()->setNewProperty('sabredav.stability',\Sabre\DAV\Version::STABILITY);
-                    $this->getProject()->setNewProperty('sabredav.ucstability',ucwords(Sabre\DAV\Version::STABILITY));
-
-                }
-
-            }
-
-        ]]></adhoc-task>
-        <sabredav-version />
-        <echo>SabreDAV version ${sabredav.version}</echo>
-
-    </target>
-
-</project>

+ 0 - 336
vendor/sabre/dav/docs/caldav-ctag.txt

@@ -1,336 +0,0 @@
-
-
-
-Calendar Server Extension                                       C. Daboo
-                                                                   Apple
-                                                             May 3, 2007
-
-
-            Calendar Collection Entity Tag (CTag) in CalDAV
-                             caldav-ctag-02
-
-Abstract
-
-   This specification defines an extension to CalDAV that provides a
-   fast way for a client to determine whether the contents of a calendar
-   collection may have changed.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
-   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     3.1.  Server  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     3.2.  Client  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   4.  New features in CalDAV  . . . . . . . . . . . . . . . . . . . . 3
-     4.1.  getctag WebDAV Property . . . . . . . . . . . . . . . . . . 4
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
-   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 5
-   Appendix B.  Change History . . . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                                                           [Page 1]
-
-                              CalDAV Proxy                      May 2007
-
-
-1.  Introduction
-
-   In CalDAV [RFC4791] calendar data is stored in calendar collection
-   resources.  Clients need to "poll" calendar collections in order to
-   find out what has changed since the last time they examined it.
-   Currently that involves having to do a PROPFIND Depth:1 HTTP request,
-   or a CALDAV:calendar-query REPORT request.  When a calendar
-   collection contains a large number of calendar resources those
-   operations become expensive on the server.
-
-   Calendar users often configure their clients to poll at short time
-   intervals.  So polling traffic to the server will be high, even
-   though the frequency at which changes actually occur to a calendar is
-   typically low.
-
-   To improve on performance, this specification defines a new "calendar
-   collection entity tag" (CTag) WebDAV property that is defined on
-   calendar collections.  When the calendar collection changes, the CTag
-   value changes.  Thus a client can cache the CTag at some point in
-   time, then poll the collection only (i.e.  PROPFIND Depth:0 HTTP
-   requests) and determine if a change has happened based on the
-   returned CTag value.  If there is a change, it can then fall back to
-   doing the full (Depth:1) poll of the collection to actually determine
-   which resources in the collection changed.
-
-   This extension also defines CTag's on CalDAV scheduling
-   [I-D.desruisseaux-caldav-sched] Inbox and Outbox collections.
-
-
-2.  Conventions Used in This Document
-
-   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 [RFC2119].
-
-   When XML element types in the namespaces "DAV:" and
-   "urn:ietf:params:xml:ns:caldav" are referenced in this document
-   outside of the context of an XML fragment, the string "DAV:" and
-   "CALDAV:" will be prefixed to the element type names respectively.
-
-   The namespace "http://calendarserver.org/ns/" is used for XML
-   elements defined in this specification.  When XML element types in
-   this namespace are referenced in this document outside of the context
-   of an XML fragment, the string "CS:" will be prefixed to the element
-   type names respectively.
-
-
-
-
-
-
-Daboo                                                           [Page 2]
-
-                              CalDAV Proxy                      May 2007
-
-
-3.  Overview
-
-3.1.  Server
-
-   For each calendar or scheduling Inbox or Outbox collection on the
-   server, a new CS:getctag WebDAV property is present.
-
-   The property value is an "opaque" token whose value is guaranteed to
-   be unique over the lifetime of any calendar or scheduling Inbox or
-   Outbox collection at a specific URI.
-
-   Whenever a calendar resource is added to, modified or deleted from
-   the calendar collection, the value of the CS:getctag property MUST
-   change.  Typically this change will occur when the DAV:getetag
-   property on a child resource changes due to some protocol action.  It
-   could be the result of a change to the body or properties of the
-   resource.
-
-3.2.  Client
-
-   The client starts off with an empty string as the initial value for
-   the cached CTag of a calendar or scheduling Inbox or Outbox
-   collection that it intends to synchronize with.
-
-   When polling a calendar or scheduling Inbox or Outbox collection, the
-   client issues a PROPFIND Depth:0 HTTP request, asking for the CS:
-   getctag property to be returned.
-
-   If the returned value of CS:getctag property matches the one
-   currently cached for the calendar or scheduling Inbox or Outbox
-   collection, then the collection contents have not changed and no
-   further action is required until the next poll.
-
-   If the returned value of CS:getctag property does not match the one
-   found previously, then the contents of the calendar or scheduling
-   Inbox or Outbox collection have changed.  At that point the client
-   should re-issue the PROPFIND Depth:1 request to get the collection
-   changes in detail and the CS:getctag property value corresponding to
-   the new state.  The new CSgetctag property value should replace the
-   one currently cached for that calendar or scheduling Inbox or Outbox
-   collection.
-
-
-4.  New features in CalDAV
-
-
-
-
-
-
-
-Daboo                                                           [Page 3]
-
-                              CalDAV Proxy                      May 2007
-
-
-4.1.  getctag WebDAV Property
-
-   Name:  getctag
-
-   Namespace:  http://calendarserver.org/ns/
-
-   Purpose:  Specifies a "synchronization" token used to indicate when
-      the contents of a calendar or scheduling Inbox or Outbox
-      collection have changed.
-
-   Conformance:  This property MUST be defined on a calendar or
-      scheduling Inbox or Outbox collection resource.  It MUST be
-      protected and SHOULD be returned by a PROPFIND DAV:allprop request
-      (as defined in Section 12.14.1 of [RFC2518]).
-
-   Description:  The CS:getctag property allows clients to quickly
-      determine if the contents of a calendar or scheduling Inbox or
-      Outbox collection have changed since the last time a
-      "synchronization" operation was done.  The CS:getctag property
-      value MUST change each time the contents of the calendar or
-      scheduling Inbox or Outbox collection change, and each change MUST
-      result in a value that is different from any other used with that
-      collection URI.
-
-   Definition:
-
-       <!ELEMENT getctag #PCDATA>
-
-   Example:
-
-       <T:getctag xmlns:T="http://calendarserver.org/ns/"
-       >ABCD-GUID-IN-THIS-COLLECTION-20070228T122324010340</T:getctag>
-
-
-5.  Security Considerations
-
-   The CS:getctag property value changes whenever any resource in the
-   collection or scheduling Inbox or Outbox changes.  Thus a change to a
-   resource that a user does not have read access to will result in a
-   change in the CTag and the user will know that a change occurred.
-   However, that user will not able to get additional details about
-   exactly what changed as WebDAV ACLs [RFC3744] will prevent that.  So
-   this does expose the fact that there are potentially "hidden"
-   resources in a calendar collection, but it does not expose any
-   details about them.
-
-
-
-
-
-
-Daboo                                                           [Page 4]
-
-                              CalDAV Proxy                      May 2007
-
-
-6.  IANA Considerations
-
-   This document does not require any actions on the part of IANA.
-
-
-7.  Normative References
-
-   [I-D.desruisseaux-caldav-sched]
-              Desruisseaux, B., "Scheduling Extensions to CalDAV",
-              draft-desruisseaux-caldav-sched-03 (work in progress),
-              January 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
-              Jensen, "HTTP Extensions for Distributed Authoring --
-              WEBDAV", RFC 2518, February 1999.
-
-   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
-              Distributed Authoring and Versioning (WebDAV) Access
-              Control Protocol", RFC 3744, May 2004.
-
-   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
-              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
-              March 2007.
-
-
-Appendix A.  Acknowledgments
-
-   This specification is the result of discussions between the Apple
-   calendar server and client teams.
-
-
-Appendix B.  Change History
-
-   Changes from -01:
-
-   1.  Updated to RFC4791 reference.
-
-   2.  Added text indicating that ctag applies to schedule Inbox and
-       Outbox as well.
-
-   Changes from -00:
-
-   1.  Relaxed requirement so that any type of change to a child
-       resource can trigger a CTag change (similar behavior to ETag).
-
-
-
-
-Daboo                                                           [Page 5]
-
-                              CalDAV Proxy                      May 2007
-
-
-Author's Address
-
-   Cyrus Daboo
-   Apple Inc.
-   1 Infinite Loop
-   Cupertino, CA  95014
-   USA
-
-   Email: cyrus@daboo.name
-   URI:   http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                                                           [Page 6]
-

File diff suppressed because it is too large
+ 0 - 1568
vendor/sabre/dav/docs/caldav-notifications.txt


+ 0 - 560
vendor/sabre/dav/docs/caldav-proxy.txt

@@ -1,560 +0,0 @@
-
-
-
-Calendar Server Extension                                       C. Daboo
-                                                          Apple Computer
-                                                             May 3, 2007
-
-
-              Calendar User Proxy Functionality in CalDAV
-                           caldav-cu-proxy-02
-
-Abstract
-
-   This specification defines an extension to CalDAV that makes it easy
-   for clients to setup and manage calendar user proxies, using the
-   WebDAV Access Control List extension as a basis.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  2
-   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  Server . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   5.  New features in CalDAV . . . . . . . . . . . . . . . . . . . .  4
-     5.1.  Proxy Principal Resource . . . . . . . . . . . . . . . . .  4
-     5.2.  Privilege Provisioning . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   8.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  9
-   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                                                           [Page 1]
-
-                              CalDAV Proxy                      May 2007
-
-
-1.  Introduction
-
-   CalDAV [RFC4791] provides a way for calendar users to store calendar
-   data and exchange this data via scheduling operations.  Based on the
-   WebDAV protocol [RFC2518], it also includes the ability to manage
-   access to calendar data via the WebDAV ACL extension [RFC3744].
-
-   It is often common for a calendar user to delegate some form of
-   responsibility for their calendar and schedules to another calendar
-   user (e.g., a boss allows an assistant to check a calendar or to send
-   and accept scheduling invites on his behalf).  The user handling the
-   calendar data on behalf of someone else is often referred to as a
-   "calendar user proxy".
-
-   Whilst CalDAV does have fine-grained access control features that can
-   be used to setup complex sharing and management of calendars, often
-   the proxy behavior required is an "all-or-nothing" approach - i.e.
-   the proxy has access to all the calendars or to no calendars (in
-   which case they are of course not a proxy).  So a simple way to
-   manage access to an entire set of calendars and scheduling ability
-   would be handy.
-
-   In addition, calendar user agents will often want to display to a
-   user who has proxy access to their calendars, or to whom they are
-   acting as a proxy.  Again, CalDAV's access control discovery and
-   report features can be used to do that, but with fine-grained control
-   that exists, it can be hard to tell who is a "real" proxy as opposed
-   to someone just granted rights to some subset of calendars.  Again, a
-   simple way to discover proxy information would be handy.
-
-
-2.  Conventions Used in This Document
-
-   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 [RFC2119].
-
-   When XML element types in the namespace "DAV:" are referenced in this
-   document outside of the context of an XML fragment, the string "DAV:"
-   will be prefixed to the element type names.
-
-   When XML element types in the namespaces "DAV:" and
-   "urn:ietf:params:xml:ns:caldav" are referenced in this document
-   outside of the context of an XML fragment, the string "DAV:" and
-   "CALDAV:" will be prefixed to the element type names respectively.
-
-   The namespace "http://calendarserver.org/ns/" is used for XML
-   elements defined in this specification.  When XML element types in
-
-
-
-Daboo                                                           [Page 2]
-
-                              CalDAV Proxy                      May 2007
-
-
-   this namespace are referenced in this document outside of the context
-   of an XML fragment, the string "CS:" will be prefixed to the element
-   type names respectively.
-
-
-3.  Overview
-
-3.1.  Server
-
-   For each calendar user principal on the server, the server will
-   generate two group principals - "proxy groups".  One is used to hold
-   the list of principals who have read-only proxy access to the main
-   principal's calendars, the other holds the list of principals who
-   have read-write and scheduling proxy access.  NB these new group
-   principals would have no equivalent in Open Directory.
-
-   Privileges on each "proxy group" principal will be set so that the
-   "owner" has the ability to change property values.
-
-   The "proxy group" principals will be child resources of the user
-   principal resource with specific resource types and thus are easy to
-   discover.  As a result the user principal resources will also be
-   collection resources.
-
-   When provisioning the calendar user home collection, the server will:
-
-   a.  Add an ACE to the calendar home collection giving the read-only
-       "proxy group" inheritable read access.
-
-   b.  Add an ACE to the calendar home collection giving the read-write
-       "proxy group" inheritable read-write access.
-
-   c.  Add an ACE to each of the calendar Inbox and Outbox collections
-       giving the CALDAV:schedule privilege
-       [I-D.desruisseaux-caldav-sched] to the read-write "proxy group".
-
-3.2.  Client
-
-   A client can see who the proxies are for the current principal by
-   examining the principal resource for the two "proxy group" properties
-   and then looking at the DAV:group-member-set property of each.
-
-   The client can edit the list of proxies for the current principal by
-   editing the DAV:group-member-set property on the relevant "proxy
-   group" principal resource.
-
-   The client can find out who the current principal is a proxy for by
-   running a DAV:principal-match REPORT on the principal collection.
-
-
-
-Daboo                                                           [Page 3]
-
-                              CalDAV Proxy                      May 2007
-
-
-   Alternatively, the client can find out who the current principal is a
-   proxy for by examining the DAV:group-membership property on the
-   current principal resource looking for membership in other users'
-   "proxy groups".
-
-
-4.  Open Issues
-
-   1.  Do we want to separate read-write access to calendars vs the
-       ability to schedule as a proxy?
-
-   2.  We may want to restrict changing properties on the proxy group
-       collections to just the DAV:group-member-set property?
-
-   3.  There is no way for a proxy to be able to manage the list of
-       proxies.  We could allow the main calendar user DAV:write-acl on
-       their "proxy group" principals, in which case they could grant
-       others the right to modify the group membership.
-
-   4.  Should the "proxy group" principals also be collections given
-       that the regular principal resources will be?
-
-
-5.  New features in CalDAV
-
-5.1.  Proxy Principal Resource
-
-   Each "regular" principal resource that needs to allow calendar user
-   proxy support MUST be a collection resource. i.e. in addition to
-   including the DAV:principal XML element in the DAV:resourcetype
-   property on the resource, it MUST also include the DAV:collection XML
-   element.
-
-   Each "regular" principal resource MUST contain two child resources
-   with names "calendar-proxy-read" and "calendar-proxy-write" (note
-   that these are only suggested names - the server could choose any
-   unique name for these).  These resources are themselves principal
-   resources that are groups contain the list of principals for calendar
-   users who can act as a read-only or read-write proxy respectively.
-
-   The server MUST include the CS:calendar-proxy-read or CS:calendar-
-   proxy-write XML elements in the DAV:resourcetype property of the
-   child resources, respectively.  This allows clients to discover the
-   "proxy group" principals by using a PROPFIND, Depth:1 request on the
-   current user's principal resource and requesting the DAV:resourcetype
-   property be returned.  The element type declarations are:
-
-
-
-
-
-Daboo                                                           [Page 4]
-
-                              CalDAV Proxy                      May 2007
-
-
-   <!ELEMENT calendar-proxy-read EMPTY>
-
-   <!ELEMENT calendar-proxy-write EMPTY>
-
-   The server MUST allow the "parent" principal to change the DAV:group-
-   member-set property on each of the "child" "proxy group" principal
-   resources.  When a principal is listed as a member of the "child"
-   resource, the server MUST include the "child" resource URI in the
-   DAV:group-membership property on the included principal resource.
-   Note that this is just "normal" behavior for a group principal.
-
-   An example principal resource layout might be:
-
-           + /
-             + principals/
-               + users/
-                 + cyrus/
-                     calendar-proxy-read
-                     calendar-proxy-write
-                 + red/
-                     calendar-proxy-read
-                     calendar-proxy-write
-                 + wilfredo/
-                     calendar-proxy-read
-                     calendar-proxy-write
-
-   If the principal "cyrus" wishes to have the principal "red" act as a
-   calendar user proxy on his behalf and have the ability to change
-   items on his calendar or schedule meetings on his behalf, then he
-   would add the principal resource URI for "red" to the DAV:group-
-   member-set property of the principal resource /principals/users/
-   cyrus/calendar-proxy-write, giving:
-
-   <DAV:group-member-set>
-     <DAV:href>/principals/users/red/</DAV:href>
-   </DAV:group-member-set>
-
-   The DAV:group-membership property on the resource /principals/users/
-   red/ would be:
-
-   <DAV:group-membership>
-     <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
-   </DAV:group-membership>
-
-   If the principal "red" was also a read-only proxy for the principal
-   "wilfredo", then the DA:group-membership property on the resource
-   /principals/users/red/ would be:
-
-
-
-
-Daboo                                                           [Page 5]
-
-                              CalDAV Proxy                      May 2007
-
-
-   <DAV:group-membership>
-     <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
-     <DAV:href>/principals/users/wilfredo/calendar-proxy-read</DAV:href>
-   </DAV:group-membership>
-
-   Thus a client can discover to which principals a particular principal
-   is acting as a calendar user proxy for by examining the DAV:group-
-   membership property.
-
-   An alternative to discovering which principals a user can proxy as is
-   to use the WebDAV ACL principal-match report, targeted at the
-   principal collections available on the server.
-
-   Example:
-
-   >> Request <<
-
-   REPORT /principals/ HTTP/1.1
-   Host: cal.example.com
-   Depth: 0
-   Content-Type: application/xml; charset="utf-8"
-   Content-Length: xxxx
-   Authorization: Digest username="red",
-    realm="cal.example.com", nonce="...",
-    uri="/principals/", response="...", opaque="..."
-
-   <?xml version="1.0" encoding="utf-8" ?>
-   <D:principal-match xmlns:D="DAV:">
-     <D:self/>
-     <D:prop>
-       <D:resourcetype/>
-     </D:prop>
-   </D:principal-match>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                                                           [Page 6]
-
-                              CalDAV Proxy                      May 2007
-
-
-   >> Response <<
-
-   HTTP/1.1 207 Multi-Status
-   Date: Fri, 10 Nov 2006 09:32:12 GMT
-   Content-Type: application/xml; charset="utf-8"
-   Content-Length: xxxx
-
-   <?xml version="1.0" encoding="utf-8" ?>
-   <D:multistatus xmlns:D="DAV:"
-                  xmlns:A="http://calendarserver.org/ns/">
-     <D:response>
-       <D:href>/principals/users/red/</D:href>
-       <D:propstat>
-         <D:prop>
-           <D:resourcetype>
-             <D:principal/>
-             <D:collection/>
-           </D:resourcetype>
-         </D:prop>
-         <D:status>HTTP/1.1 200 OK</D:status>
-       </D:propstat>
-     </D:response>
-     <D:response>
-       <D:href>/principals/users/cyrus/calendar-proxy-write</D:href>
-       <D:propstat>
-         <D:prop>
-           <D:resourcetype>
-             <D:principal/>
-             <A:calendar-proxy-write/>
-           </D:resourcetype>
-         </D:prop>
-         <D:status>HTTP/1.1 200 OK</D:status>
-       </D:propstat>
-     </D:response>
-     <D:response>
-       <D:href>/principals/users/wilfredo/calendar-proxy-read</D:href>
-       <D:propstat>
-         <D:prop>
-           <D:resourcetype>
-             <D:principal/>
-             <A:calendar-proxy-read/>
-           </D:resourcetype>
-         </D:prop>
-         <D:status>HTTP/1.1 200 OK</D:status>
-       </D:propstat>
-     </D:response>
-   </D:multistatus>
-
-
-
-
-Daboo                                                           [Page 7]
-
-                              CalDAV Proxy                      May 2007
-
-
-5.2.  Privilege Provisioning
-
-   In order for a calendar user proxy to be able to access the calendars
-   of the user they are proxying for the server MUST ensure that the
-   privileges on the relevant calendars are setup accordingly:
-
-      The DAV:read privilege MUST be granted for read-only and read-
-      write calendar user proxy principals
-
-      The DAV:write privilege MUST be granted for read-write calendar
-      user proxy principals.
-
-   Additionally, the CalDAV scheduling Inbox and Outbox calendar
-   collections for the user allowing proxy access, MUST have the CALDAV:
-   schedule privilege [I-D.desruisseaux-caldav-sched] granted for read-
-   write calendar user proxy principals.
-
-   Note that with a suitable repository layout, a server may be able to
-   grant the appropriate privileges on a parent collection and ensure
-   that all the contained collections and resources inherit that.  For
-   example, given the following repository layout:
-
-           + /
-             + calendars/
-               + users/
-                 + cyrus/
-                     inbox
-                     outbox
-                     home
-                     work
-                 + red/
-                     inbox
-                     outbox
-                     work
-                     soccer
-                 + wilfredo/
-                     inbox
-                     outbox
-                     home
-                     work
-                     flying
-
-   In order for the principal "red" to act as a read-write proxy for the
-   principal "cyrus", the following WebDAV ACE will need to be granted
-   on the resource /calendars/users/cyrus/ and all children of that
-   resource:
-
-
-
-
-
-Daboo                                                           [Page 8]
-
-                              CalDAV Proxy                      May 2007
-
-
-   <DAV:ace>
-     <DAV:principal>
-       <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
-     </DAV:principal>
-     <DAV:privileges>
-       <DAV:grant><DAV:read/><DAV:write/></DAV:grant>
-     </DAV:privileges>
-   </DAV:ace>
-
-
-6.  Security Considerations
-
-   TBD
-
-
-7.  IANA Considerations
-
-   This document does not require any actions on the part of IANA.
-
-
-8.  Normative References
-
-   [I-D.desruisseaux-caldav-sched]
-              Desruisseaux, B., "Scheduling Extensions to CalDAV",
-              draft-desruisseaux-caldav-sched-03 (work in progress),
-              January 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
-              Jensen, "HTTP Extensions for Distributed Authoring --
-              WEBDAV", RFC 2518, February 1999.
-
-   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
-              Distributed Authoring and Versioning (WebDAV) Access
-              Control Protocol", RFC 3744, May 2004.
-
-   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
-              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
-              March 2007.
-
-
-Appendix A.  Acknowledgments
-
-   This specification is the result of discussions between the Apple
-   calendar server and client teams.
-
-
-
-
-Daboo                                                           [Page 9]
-
-                              CalDAV Proxy                      May 2007
-
-
-Appendix B.  Change History
-
-   Changes from -00:
-
-   1.  Updated to RFC 4791 reference.
-
-   Changes from -00:
-
-   1.  Added more details on actual CalDAV protocol changes.
-
-   2.  Changed namespace from http://apple.com/ns/calendarserver/ to
-       http://calendarserver.org/ns/.
-
-   3.  Made "proxy group" principals child resources of their "owner"
-       principals.
-
-   4.  The "proxy group" principals now have their own resourcetype.
-
-
-Author's Address
-
-   Cyrus Daboo
-   Apple Computer, Inc.
-   1 Infinite Loop
-   Cupertino, CA  95014
-   USA
-
-   Email: cyrus@daboo.name
-   URI:   http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                                                          [Page 10]
-

File diff suppressed because it is too large
+ 0 - 1624
vendor/sabre/dav/docs/caldav-sharing.txt


+ 0 - 560
vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt

@@ -1,560 +0,0 @@
-
-
-
-Network Working Group                                           C. Daboo
-Internet-Draft                                                Apple Inc.
-Updates: XXXX-CardDAV                                    August 24, 2010
-(if approved)
-Intended status: Standards Track
-Expires: February 25, 2011
-
-
-                  CardDAV Directory Gateway Extension
-                draft-daboo-carddav-directory-gateway-02
-
-Abstract
-
-   This document defines an extension to the vCard Extensions to WebDAV
-   (CardDAV) protocol that allows a server to expose a directory as a
-   read-only address book collection.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on February 25, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-Daboo                   Expires February 25, 2011               [Page 1]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-Table of Contents
-
-   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  CARDDAV:directory-gateway Property . . . . . . . . . . . . . .  4
-   4.  XML Element Definitions  . . . . . . . . . . . . . . . . . . .  5
-     4.1.  CARDDAV:directory  . . . . . . . . . . . . . . . . . . . .  5
-   5.  Client Guidelines  . . . . . . . . . . . . . . . . . . . . . .  5
-   6.  Server Guidelines  . . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . .  8
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     10.1. Normative References . . . . . . . . . . . . . . . . . . .  8
-     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
-   Appendix A.  Change History (to be removed prior to
-                publication as an RFC)  . . . . . . . . . . . . . . .  9
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                   Expires February 25, 2011               [Page 2]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-1.  Introduction and Overview
-
-   The CardDAV [I-D.ietf-vcarddav-carddav] protocol defines a standard
-   way of accessing, managing, and sharing contact information based on
-   the vCard [RFC2426] format.  Often, in an enterprise or service
-   provider environment, a directory of all users hosted on the server
-   (or elsewhere) is available (for example via Lightweight Directory
-   Access Protocol (LDAP) [RFC4510] or some direct database access).  It
-   would be convenient for CardDAV clients if this directory were
-   exposed as a "global" address book on the CardDAV server so it could
-   be searched in the same way as personal address books are.  This
-   specification defines a "directory gateway" feature extension to
-   CardDAV to enable this.
-
-   This specification adds one new WebDAV property to principal
-   resources that contains the URL to one or more directory gateway
-   address book collection resources.  It is important for clients to be
-   able to distinguish this address book collection from others because
-   there are specific limitations involved in using it as described
-   below.  To aid that, this specification defines an XML element that
-   can be included as a child element of the DAV:resourcetype property
-   of address book collections to identify them as directory gateways.
-
-   Note that this feature is in no way intended to replace full
-   directory access - it is meant to simply provide a convenient way for
-   CardDAV clients to query contact-related attributes in directory
-   records.
-
-
-2.  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 [RFC2119].
-
-   The term "protected" is used in the Conformance field of property
-   definitions as defined in Section 15 of [RFC4918].
-
-   This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section
-   3.2) as a purely notational convention.  WebDAV request and response
-   bodies cannot be validated by a DTD due to the specific extensibility
-   rules defined in Section 17 of [RFC4918] and due to the fact that all
-   XML elements defined by this specification use the XML namespace name
-   "DAV:".  In particular:
-
-   1.  element names use the "DAV:" namespace,
-
-
-
-
-
-Daboo                   Expires February 25, 2011               [Page 3]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-   2.  element ordering is irrelevant unless explicitly stated,
-
-   3.  extension elements (elements not already defined as valid child
-       elements) may be added anywhere, except when explicitly stated
-       otherwise,
-
-   4.  extension attributes (attributes not already defined as valid for
-       this element) may be added anywhere, except when explicitly
-       stated otherwise.
-
-   When XML element types in the namespaces "DAV:" and
-   "urn:ietf:params:xml:ns:carddav" are referenced in this document
-   outside of the context of an XML fragment, the strings "DAV:" and
-   "CARDDAV:" will be prefixed to the element types, respectively.
-
-
-3.  CARDDAV:directory-gateway Property
-
-   Name:  directory-gateway
-
-   Namespace:  urn:ietf:params:xml:ns:carddav
-
-   Purpose:  Identifies URLs of CardDAV address book collections acting
-      as a directory gateway for the server.
-
-   Protected:  MUST be protected.
-
-   allprop behavior:  SHOULD NOT be returned by a PROPFIND DAV:allprop
-      request.
-
-   Description:  The CARDDAV:directory-gateway identifies address book
-      collection resources that are directory gateway address books for
-      the server.
-
-   Definition:
-
-       <!ELEMENT directory-gateway (DAV:href*)>
-
-   Example:
-
-       <C:directory-gateway xmlns:D="DAV:"
-          xmlns:C="urn:ietf:params:xml:ns:carddav">
-         <D:href>/directory</D:href>
-       </C:directory-gateway>
-
-
-
-
-
-
-
-Daboo                   Expires February 25, 2011               [Page 4]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-4.  XML Element Definitions
-
-4.1.  CARDDAV:directory
-
-   Name:  directory
-
-   Namespace:  urn:ietf:params:xml:ns:carddav
-
-   Purpose:  Used to indicate that an address book collection is a
-      directory gateway.
-
-   Description:  This element appears in the DAV:resourcetype property
-      on a address book collection resources that are directory
-      gateways.  Clients can use the presence of this element to
-      identify directory gateway collections when doing PROPFINDs to
-      list collection contents.
-
-   Definition:
-
-   <!ELEMENT directory EMPTY>
-
-   Example:
-
-       <D:resourcetype xmlns:D="DAV:"
-          xmlns:C="urn:ietf:params:xml:ns:carddav">
-         <D:collection/>
-         <C:addressbook/>
-         <C:directory/>
-       </D:resourcetype>
-
-
-5.  Client Guidelines
-
-   Clients wishing to make use of directory gateway address books can
-   request the CARDDAV:directory-gateway property (Section 3) when
-   examining other properties on the principal resource for the user.
-   If the property is not present, then the directory gateway feature is
-   not supported by the server at that time.
-
-   Clients can also detect the presence of directory gateway address
-   book collections by retrieving the DAV:resourcetype property on
-   collections that it lists, and look for the presence of the CARDDAV:
-   directory element (Section 4.1).
-
-   Since the directory being exposed via a directory gateway address
-   book collection could be large, clients SHOULD limit the number of
-   results returned in an CARDDAV:addressbook-query REPORT as defined in
-   Section 8.6.1 of [I-D.ietf-vcarddav-carddav].
-
-
-
-Daboo                   Expires February 25, 2011               [Page 5]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-   Clients MUST treat the directory gateway address book collection as a
-   read-only collection, so HTTP methods that modify resource data or
-   properties in the address book collection MUST NOT be used.
-
-   Clients SHOULD NOT attempt to cache the entire contents of the
-   directory gateway address book collection resource by retrieving all
-   resources, or trying to examine all the properties of all resources
-   (e.g., via a PROPFIND Depth:1 request).  Instead, CARDDAV:
-   addressbook-query REPORTs are used to search for specific address
-   book object resources, and CARDDAV:multiget REPORTs and individual
-   GET requests can be made to retrieve the actual vCard data for
-   address book object resources found via a query.
-
-   When presenting directory gateway collections to the user, clients
-   SHOULD use the DAV:displayname property on the corresponding address
-   book collections as the name of the directory gateway.  This is
-   important in the case where more than one directory gateway is
-   available.  Clients MAY also provide descriptive information about
-   each directory gateway by examining the CARDDAV:addressbook-
-   description property (see Section 6.2.1 of
-   [I-D.ietf-vcarddav-carddav]) on the resource.
-
-
-6.  Server Guidelines
-
-   Servers wishing to expose a directory gateway as an address book
-   collection MUST include the CARDDAV:directory-gateway property on all
-   principal resources of users expected to use the feature.
-
-   Since the directory being exposed via the directory gateway address
-   book collection could be large, servers SHOULD truncate the number of
-   results returned in an CARDDAV:addressbook-query REPORT as defined in
-   Section 8.6.2 of [I-D.ietf-vcarddav-carddav].  In addition, servers
-   SHOULD disallow requests that effectively enumerate the collection
-   contents (e.g., PROPFIND Depth:1, trivial CARDDAV:addressbook-query,
-   DAV:sync-collection REPORT).
-
-   Servers need to expose the directory information as a set of address
-   book object resources in the directory gateway address book
-   collection resource.  To do that, a mapping between the directory
-   record format and the vCard data has to be applied.  In general, only
-   directory record attributes that have a direct equivalent in vCard
-   SHOULD be mapped.  It is up to individual implementations to
-   determine which attributes to map.  But in all cases servers MUST
-   generate valid vCard data as returned to the client.  In addition, as
-   required by CardDAV, the UID vCard property MUST be present in the
-   vCard data, and this value MUST be persistent from query to query for
-   the same directory record.
-
-
-
-Daboo                   Expires February 25, 2011               [Page 6]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-   Multiple directory sources could be available to the server.  The
-   server MAY use a single directory gateway resource to aggregate
-   results from each directory source.  When doing so care is needed
-   when dealing with potential records that refer to the same entity.
-   Servers MAY suppress any duplicates that they are able to determine
-   themselves.  Alternatively, multiple directory sources can be exposed
-   as separate directory gateway resources.
-
-   For any directory source, a server MAY expose multiple directory
-   gateway resources where each represents a different query "scope" for
-   the directory.  Different scopes MAY be offered to different
-   principals on the server.  For example, the server might expose an
-   entire company directory for searching as the resource "/directory-
-   all" to all principals, but then provide "/directory-department-XYZ"
-   as another directory gateway that has a search scope that implicitly
-   limits the search results to just the "XYZ" department.  Users in
-   that department would then have a CARDDAV:directory-gateway property
-   on their principal resource that included the "/directory-department-
-   XYZ" resource.  Users in other departments would have corresponding
-   directory gateway resources available to them.
-
-   Records in a directory can include data for more than just people,
-   e.g, resources such as rooms or projectors, groups, computer systems
-   etc.  It is up to individual implementations to determine the most
-   appropriate "scope" for the data returned via the directory gateway
-   by filtering the appropriate record types.  As above, servers could
-   choose to expose people and resources under different directory
-   gateway resources by implicitly limiting the search "scope" for each
-   of those.
-
-   Servers MAY apply implementation defined access rules to determine,
-   on a per-user basis, what records are returned to a particularly user
-   and the content of those records exposed via vCard data.  This per-
-   user behavior is in addition to the general security requirements
-   detailed below.
-
-   When multiple directory gateway collections are present, servers
-   SHOULD provide a DAV:displayname property on each that disambiguates
-   them.  Servers MAY include a CARDDAV:addressbook-description property
-   (see Section 6.2.1 of [I-D.ietf-vcarddav-carddav]) on each directory
-   gateway resource to provide a description of the directory and any
-   search "scope" that might be used, or any other useful information
-   for users.
-
-
-7.  Security Considerations
-
-   Servers MUST ensure that client requests against the directory
-
-
-
-Daboo                   Expires February 25, 2011               [Page 7]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-   gateway address book collection cannot use excessive resources (CPU,
-   memory, network bandwidth etc), given that the directory could be
-   large.
-
-   Servers MUST take care not to expose sensitive directory record
-   attributes in the vCard data via the directory gateway address book.
-   In general only those properties that have direct correspondence in
-   vCard SHOULD be exposed.
-
-   Servers need to determine whether it is appropriate for the directory
-   information to be available via CardDAV to unauthenticated users.  If
-   not, servers MUST ensure that unauthenticated users do not have
-   access to the directory gateway address book object resource and its
-   contents.  If unauthenticated access is allowed, servers MAY choose
-   to limit the set of vCard properties that are searchable or returned
-   in the address book object resources when unauthenticated requests
-   are made.
-
-
-8.  IANA Consideration
-
-   This document does not require any actions on the part of IANA.
-
-
-9.  Acknowledgments
-
-
-10.  References
-
-10.1.  Normative References
-
-   [I-D.ietf-vcarddav-carddav]
-              Daboo, C., "vCard Extensions to WebDAV (CardDAV)",
-              draft-ietf-vcarddav-carddav-10 (work in progress),
-              November 2009.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
-              RFC 2426, September 1998.
-
-   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
-              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
-   [W3C.REC-xml-20081126]
-              Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
-              and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
-
-
-
-Daboo                   Expires February 25, 2011               [Page 8]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-              Edition)", World Wide Web Consortium Recommendation REC-
-              xml-20081126, November 2008,
-              <http://www.w3.org/TR/2008/REC-xml-20081126>.
-
-10.2.  Informative References
-
-   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510,
-              June 2006.
-
-
-Appendix A.  Change History (to be removed prior to publication as an
-             RFC)
-
-   Changes in -02
-
-   1.  Added CARDDAV:directory element for use in DAV:resourcetype
-
-   2.  Allow CARDDAV:directory-gateway to be multi-valued
-
-   3.  Explain how a server could implicit "scope" queries on different
-       directory gateway resources
-
-   Changes in -01
-
-   1.  Remove duplicated text in a couple of sections
-
-   2.  Add example of LDAP/generic database as possible directory
-       "sources"
-
-   3.  Add text to explain why the client needs to treat this as special
-       and thus the need for a property
-
-   4.  Added text to server guidelines indicating requirements for
-       handling vCard UID properties
-
-   5.  Added text to server guidelines explain that different record
-       "types" may exist in the directory and the server is free to
-       filter those as appropriate
-
-   6.  Added text to server guidelines indicating that server are free
-       to aggregate directory records from multiple sources
-
-   7.  Added text to server guidelines indicating that servers are free
-       to apply implementation defined access control to the returned
-       data on a per-user basis
-
-
-
-
-
-Daboo                   Expires February 25, 2011               [Page 9]
-
-Internet-Draft     CardDAV Directory Gateway Extension       August 2010
-
-
-Author's Address
-
-   Cyrus Daboo
-   Apple Inc.
-   1 Infinite Loop
-   Cupertino, CA  95014
-   USA
-
-   Email: cyrus@daboo.name
-   URI:   http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo                   Expires February 25, 2011              [Page 10]
-

File diff suppressed because it is too large
+ 0 - 5544
vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt


File diff suppressed because it is too large
+ 0 - 5152
vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt


File diff suppressed because it is too large
+ 0 - 1512
vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt


File diff suppressed because it is too large
+ 0 - 1512
vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt


File diff suppressed because it is too large
+ 0 - 2352
vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt


+ 0 - 560
vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt

@@ -1,560 +0,0 @@
-
-
-
-Network Working Group                                      M. Nottingham
-Internet-Draft                                                 Rackspace
-Updates: 2616 (if approved)                                  R. Fielding
-Intended status: Standards Track                                   Adobe
-Expires: August 7, 2012                                 February 4, 2012
-
-
-                      Additional HTTP Status Codes
-                  draft-nottingham-http-new-status-04
-
-Abstract
-
-   This document specifies additional HyperText Transfer Protocol (HTTP)
-   status codes for a variety of common situations.
-
-Editorial Note (To be removed by RFC Editor before publication)
-
-   Distribution of this document is unlimited.  Although this is not a
-   work item of the HTTPbis Working Group, comments should be sent to
-   the Hypertext Transfer Protocol (HTTP) mailing list at
-   ietf-http-wg@w3.org [1], which may be joined by sending a message
-   with subject "subscribe" to ietf-http-wg-request@w3.org [2].
-
-   Discussions of the HTTPbis Working Group are archived at
-   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on August 7, 2012.
-
-Copyright Notice
-
-   Copyright (c) 2012 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 1]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   3.  428 Precondition Required . . . . . . . . . . . . . . . . . . . 3
-   4.  429 Too Many Requests . . . . . . . . . . . . . . . . . . . . . 4
-   5.  431 Request Header Fields Too Large . . . . . . . . . . . . . . 4
-   6.  511 Network Authentication Required . . . . . . . . . . . . . . 5
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
-   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 8
-   Appendix B.  Issues Raised by Captive Portals . . . . . . . . . . . 8
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 2]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-1.  Introduction
-
-   This document specifies additional HTTP [RFC2616] status codes for a
-   variety of common situations, to improve interoperability and avoid
-   confusion when other, less precise status codes are used.
-
-   Note that these status codes are optional; servers cannot be required
-   to support them.  However, because clients will treat unknown status
-   codes as a generic error of the same class (e.g., 499 is treated as
-   400 if it is not recognized), they can be safely deployed by existing
-   servers (see [RFC2616] Section 6.1.1 for more information).
-
-
-2.  Requirements
-
-   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 [RFC2119].
-
-
-3.  428 Precondition Required
-
-   The 428 status code indicates that the origin server requires the
-   request to be conditional.
-
-   Its typical use is to avoid the "lost update" problem, where a client
-   GETs a resource's state, modifies it, and PUTs it back to the server,
-   when meanwhile a third party has modified the state on the server,
-   leading to a conflict.  By requiring requests to be conditional, the
-   server can assure that clients are working with the correct copies.
-
-   Responses using this status code SHOULD explain how to resubmit the
-   request successfully.  For example:
-
-   HTTP/1.1 428 Precondition Required
-   Content-Type: text/html
-
-   <html>
-    <head>
-     <title>Precondition Required</title>
-    </head>
-    <body>
-     <h1>Precondition Required</h1>
-      <p>This request is required to be conditional;
-         try using "If-Match".</p>
-    </body>
-   </html>
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 3]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   Responses with the 428 status code MUST NOT be stored by a cache.
-
-
-4.  429 Too Many Requests
-
-   The 429 status code indicates that the user has sent too many
-   requests in a given amount of time ("rate limiting").
-
-   The response representations SHOULD include details explaining the
-   condition, and MAY include a Retry-After header indicating how long
-   to wait before making a new request.
-
-   For example:
-
-   HTTP/1.1 429 Too Many Requests
-   Content-Type: text/html
-   Retry-After: 3600
-
-   <html>
-      <head>
-         <title>Too Many Requests</title>
-      </head>
-      <body>
-         <h1>Too Many Requests</h1>
-         <p>I only allow 50 requests per hour to this Web site per
-            logged in user. Try again soon.</p>
-      </body>
-   </html>
-
-   Note that this specification does not define how the origin server
-   identifies the user, nor how it counts requests.  For example, an
-   origin server that is limiting request rates can do so based upon
-   counts of requests on a per-resource basis, across the entire server,
-   or even among a set of servers.  Likewise, it might identify the user
-   by its authentication credentials, or a stateful cookie.
-
-   Responses with the 429 status code MUST NOT be stored by a cache.
-
-
-5.  431 Request Header Fields Too Large
-
-   The 431 status code indicates that the server is unwilling to process
-   the request because its header fields are too large.  The request MAY
-   be resubmitted after reducing the size of the request header fields.
-
-   It can be used both when the set of request header fields in total
-   are too large, and when a single header field is at fault.  In the
-   latter case, the response representation SHOULD specify which header
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 4]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   field was too large.
-
-   For example:
-
-   HTTP/1.1 431 Request Header Fields Too Large
-   Content-Type: text/html
-
-   <html>
-      <head>
-         <title>Request Header Fields Too Large</title>
-      </head>
-      <body>
-         <h1>Request Header Fields Too Large</h1>
-         <p>The "Example" header was too large.</p>
-      </body>
-   </html>
-
-   Responses with the 431 status code MUST NOT be stored by a cache.
-
-
-6.  511 Network Authentication Required
-
-   The 511 status code indicates that the client needs to authenticate
-   to gain network access.
-
-   The response representation SHOULD contain a link to a resource that
-   allows the user to submit credentials (e.g. with a HTML form).
-
-   Note that the 511 response SHOULD NOT contain a challenge or the
-   login interface itself, because browsers would show the login
-   interface as being associated with the originally requested URL,
-   which may cause confusion.
-
-   The 511 status SHOULD NOT be generated by origin servers; it is
-   intended for use by intercepting proxies that are interposed as a
-   means of controlling access to the network.
-
-   Responses with the 511 status code MUST NOT be stored by a cache.
-
-6.1.  The 511 Status Code and Captive Portals
-
-   The 511 status code is designed to mitigate problems caused by
-   "captive portals" to software (especially non-browser agents) that is
-   expecting a response from the server that a request was made to, not
-   the intervening network infrastructure.  It is not intended to
-   encouraged deployment of captive portals, only to limit the damage
-   caused by them.
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 5]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   A network operator wishing to require some authentication, acceptance
-   of terms or other user interaction before granting access usually
-   does so by identifing clients who have not done so ("unknown
-   clients") using their MAC addresses.
-
-   Unknown clients then have all traffic blocked, except for that on TCP
-   port 80, which is sent to a HTTP server (the "login server")
-   dedicated to "logging in" unknown clients, and of course traffic to
-   the login server itself.
-
-   For example, a user agent might connect to a network and make the
-   following HTTP request on TCP port 80:
-
-   GET /index.htm HTTP/1.1
-   Host: www.example.com
-
-   Upon receiving such a request, the login server would generate a 511
-   response:
-
-   HTTP/1.1 511 Network Authentication Required
-   Content-Type: text/html
-
-   <html>
-      <head>
-         <title>Network Authentication Required</title>
-         <meta http-equiv="refresh"
-               content="0; url=https://login.example.net/">
-      </head>
-      <body>
-         <p>You need to <a href="https://login.example.net/">
-         authenticate with the local network</a> in order to gain
-         access.</p>
-      </body>
-   </html>
-
-   Here, the 511 status code assures that non-browser clients will not
-   interpret the response as being from the origin server, and the META
-   HTML element redirects the user agent to the login server.
-
-
-7.  Security Considerations
-
-7.1.  428 Precondition Required
-
-   The 428 status code is optional; clients cannot rely upon its use to
-   prevent "lost update" conflicts.
-
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 6]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-7.2.  429 Too Many Requests
-
-   When a server is under attack or just receiving a very large number
-   of requests from a single party, responding to each with a 429 status
-   code will consume resources.
-
-   Therefore, servers are not required to use the 429 status code; when
-   limiting resource usage, it may be more appropriate to just drop
-   connections, or take other steps.
-
-7.3.  431 Request Header Fields Too Large
-
-   Servers are not required to use the 431 status code; when under
-   attack, it may be more appropriate to just drop connections, or take
-   other steps.
-
-7.4.  511 Network Authentication Required
-
-   In common use, a response carrying the 511 status code will not come
-   from the origin server indicated in the request's URL.  This presents
-   many security issues; e.g., an attacking intermediary may be
-   inserting cookies into the original domain's name space, may be
-   observing cookies or HTTP authentication credentials sent from the
-   user agent, and so on.
-
-   However, these risks are not unique to the 511 status code; in other
-   words, a captive portal that is not using this status code introduces
-   the same issues.
-
-   Also, note that captive portals using this status code on an SSL or
-   TLS connection (commonly, port 443) will generate a certificate error
-   on the client.
-
-
-8.  IANA Considerations
-
-   The HTTP Status Codes Registry should be updated with the following
-   entries:
-
-   o  Code: 428
-   o  Description: Precondition Required
-   o  Specification: [ this document ]
-
-   o  Code: 429
-   o  Description: Too Many Requests
-   o  Specification: [ this document ]
-
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 7]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   o  Code: 431
-   o  Description: Request Header Fields Too Large
-   o  Specification: [ this document ]
-
-   o  Code: 511
-   o  Description: Network Authentication Required
-   o  Specification: [ this document ]
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [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.
-
-9.2.  Informative References
-
-   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
-              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
-              March 2007.
-
-   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
-              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
-URIs
-
-   [1]  <mailto:ietf-http-wg@w3.org>
-
-   [2]  <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
-
-
-Appendix A.  Acknowledgements
-
-   Thanks to Jan Algermissen and Julian Reschke for their suggestions
-   and feedback.
-
-
-Appendix B.  Issues Raised by Captive Portals
-
-   Since clients cannot differentiate between a portal's response and
-   that of the HTTP server that they intended to communicate with, a
-   number of issues arise.  The 511 status code is intended to help
-   mitigate some of them.
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 8]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   One example is the "favicon.ico"
-   <http://en.wikipedia.org/wiki/Favicon> commonly used by browsers to
-   identify the site being accessed.  If the favicon for a given site is
-   fetched from a captive portal instead of the intended site (e.g.,
-   because the user is unauthenticated), it will often "stick" in the
-   browser's cache (most implementations cache favicons aggressively)
-   beyond the portal session, so that it seems as if the portal's
-   favicon has "taken over" the legitimate site.
-
-   Another browser-based issue comes about when P3P
-   <http://www.w3.org/TR/P3P/> is supported.  Depending on how it is
-   implemented, it's possible a browser might interpret a portal's
-   response for the p3p.xml file as the server's, resulting in the
-   privacy policy (or lack thereof) advertised by the portal being
-   interpreted as applying to the intended site.  Other Web-based
-   protocols such as WebFinger
-   <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>, CORS
-   <http://www.w3.org/TR/cors/> and OAuth
-   <http://tools.ietf.org/html/draft-ietf-oauth-v2> may also be
-   vulnerable to such issues.
-
-   Although HTTP is most widely used with Web browsers, a growing number
-   of non-browsing applications use it as a substrate protocol.  For
-   example, WebDAV [RFC4918] and CalDAV [RFC4791] both use HTTP as the
-   basis (for remote authoring and calendaring, respectively).  Using
-   these applications from behind a captive portal can result in
-   spurious errors being presented to the user, and might result in
-   content corruption, in extreme cases.
-
-   Similarly, other non-browser applications using HTTP can be affected
-   as well; e.g., widgets <http://www.w3.org/TR/widgets/>, software
-   updates, and other specialised software such as Twitter clients and
-   the iTunes Music Store.
-
-   It should be noted that it's sometimes believed that using HTTP
-   redirection to direct traffic to the portal addresses these issues.
-   However, since many of these uses "follow" redirects, this is not a
-   good solution.
-
-
-Authors' Addresses
-
-   Mark Nottingham
-   Rackspace
-
-   Email: mnot@mnot.net
-   URI:   http://www.mnot.net/
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                 [Page 9]
-
-Internet-Draft        Additional HTTP Status Codes         February 2012
-
-
-   Roy T. Fielding
-   Adobe Systems Incorporated
-   345 Park Ave
-   San Jose, CA  95110
-   USA
-
-   Email: fielding@gbiv.com
-   URI:   http://roy.gbiv.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nottingham & Fielding    Expires August 7, 2012                [Page 10]
-

File diff suppressed because it is too large
+ 0 - 1851
vendor/sabre/dav/docs/rfc2425.txt


File diff suppressed because it is too large
+ 0 - 2355
vendor/sabre/dav/docs/rfc2426.txt


File diff suppressed because it is too large
+ 0 - 5267
vendor/sabre/dav/docs/rfc2518.txt


File diff suppressed because it is too large
+ 0 - 9859
vendor/sabre/dav/docs/rfc2616.txt


File diff suppressed because it is too large
+ 0 - 1907
vendor/sabre/dav/docs/rfc2617.txt


File diff suppressed because it is too large
+ 0 - 10329
vendor/sabre/dav/docs/rfc3253.pdf


File diff suppressed because it is too large
+ 0 - 6295
vendor/sabre/dav/docs/rfc3744.pdf


File diff suppressed because it is too large
+ 0 - 3127
vendor/sabre/dav/docs/rfc4437.pdf


File diff suppressed because it is too large
+ 0 - 1459
vendor/sabre/dav/docs/rfc4790.txt


File diff suppressed because it is too large
+ 0 - 5995
vendor/sabre/dav/docs/rfc4791.txt


File diff suppressed because it is too large
+ 0 - 13609
vendor/sabre/dav/docs/rfc4918.pdf


+ 0 - 395
vendor/sabre/dav/docs/rfc5051.txt

@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 5051                      University of Washington
-Category: Standards Track                                   October 2007
-
-
-         i;unicode-casemap - Simple Unicode Collation Algorithm
-
-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.
-
-Abstract
-
-   This document describes "i;unicode-casemap", a simple case-
-   insensitive collation for Unicode strings.  It provides equality,
-   substring, and ordering operations.
-
-1.  Introduction
-
-   The "i;ascii-casemap" collation described in [COMPARATOR] is quite
-   simple to implement and provides case-independent comparisons for the
-   26 Latin alphabetics.  It is specified as the default and/or baseline
-   comparator in some application protocols, e.g., [IMAP-SORT].
-
-   However, the "i;ascii-casemap" collation does not produce
-   satisfactory results with non-ASCII characters.  It is possible, with
-   a modest extension, to provide a more sophisticated collation with
-   greater multilingual applicability than "i;ascii-casemap".  This
-   extension provides case-independent comparisons for a much greater
-   number of characters.  It also collates characters with diacriticals
-   with the non-diacritical character forms.
-
-   This collation, "i;unicode-casemap", is intended to be an alternative
-   to, and preferred over, "i;ascii-casemap".  It does not replace the
-   "i;basic" collation described in [BASIC].
-
-2.  Unicode Casemap Collation Description
-
-   The "i;unicode-casemap" collation is a simple collation which is
-   case-insensitive in its treatment of characters.  It provides
-   equality, substring, and ordering operations.  The validity test
-   operation returns "valid" for any input.
-
-
-
-
-
-Crispin                     Standards Track                     [Page 1]
-
-RFC 5051                   i;unicode-casemap                October 2007
-
-
-   This collation allows strings in arbitrary (and mixed) character
-   sets, as long as the character set for each string is identified and
-   it is possible to convert the string to Unicode.  Strings which have
-   an unidentified character set and/or cannot be converted to Unicode
-   are not rejected, but are treated as binary.
-
-   Each input string is prepared by converting it to a "titlecased
-   canonicalized UTF-8" string according to the following steps, using
-   UnicodeData.txt ([UNICODE-DATA]):
-
-      (1) A Unicode codepoint is obtained from the input string.
-
-          (a) If the input string is in a known charset that can be
-              converted to Unicode, a sequence in the string's charset
-              is read and checked for validity according to the rules of
-              that charset.  If the sequence is valid, it is converted
-              to a Unicode codepoint.  Note that for input strings in
-              UTF-8, the UTF-8 sequence must be valid according to the
-              rules of [UTF-8]; e.g., overlong UTF-8 sequences are
-              invalid.
-
-          (b) If the input string is in an unknown charset, or an
-              invalid sequence occurs in step (1)(a), conversion ceases.
-              No further preparation is performed, and any partial
-              preparation results are discarded.  The original string is
-              used unchanged with the i;octet comparator.
-
-      (2) The following steps, using UnicodeData.txt ([UNICODE-DATA]),
-          are performed on the resulting codepoint from step (1)(a).
-
-          (a) If the codepoint has a titlecase property in
-              UnicodeData.txt (this is normally the same as the
-              uppercase property), the codepoint is converted to the
-              codepoints in the titlecase property.
-
-          (b) If the resulting codepoint from (2)(a) has a decomposition
-              property of any type in UnicodeData.txt, the codepoint is
-              converted to the codepoints in the decomposition property.
-              This step is recursively applied to each of the resulting
-              codepoints until no more decomposition is possible
-              (effectively Normalization Form KD).
-
-          Example: codepoint U+01C4 (LATIN CAPITAL LETTER DZ WITH CARON)
-          has a titlecase property of U+01C5 (LATIN CAPITAL LETTER D
-          WITH SMALL LETTER Z WITH CARON).  Codepoint U+01C5 has a
-          decomposition property of U+0044 (LATIN CAPITAL LETTER D)
-          U+017E (LATIN SMALL LETTER Z WITH CARON).  U+017E has a
-          decomposition property of U+007A (LATIN SMALL LETTER Z) U+030c
-
-
-
-Crispin                     Standards Track                     [Page 2]
-
-RFC 5051                   i;unicode-casemap                October 2007
-
-
-          (COMBINING CARON).  Neither U+0044, U+007A, nor U+030C have
-          any decomposition properties.  Therefore, U+01C4 is converted
-          to U+0044 U+007A U+030C by this step.
-
-      (3) The resulting codepoint(s) from step (2) is/are appended, in
-          UTF-8 format, to the "titlecased canonicalized UTF-8" string.
-
-      (4) Repeat from step (1) until there is no more data in the input
-          string.
-
-   Following the above preparation process on each string, the equality,
-   ordering, and substring operations are as for i;octet.
-
-   It is permitted to use an alternative implementation of the above
-   preparation process if it produces the same results.  For example, it
-   may be more convenient for an implementation to convert all input
-   strings to a sequence of UTF-16 or UTF-32 values prior to performing
-   any of the step (2) actions.  Similarly, if all input strings are (or
-   are convertible to) Unicode, it may be possible to use UTF-32 as an
-   alternative to UTF-8 in step (3).
-
-      Note: UTF-16 is unsuitable as an alternative to UTF-8 in step (3),
-      because UTF-16 surrogates will cause i;octet to collate codepoints
-      U+E0000 through U+FFFF after non-BMP codepoints.
-
-   This collation is not locale sensitive.  Consequently, care should be
-   taken when using OS-supplied functions to implement this collation.
-   Functions such as strcasecmp and toupper are sometimes locale
-   sensitive and may inconsistently casemap letters.
-
-   The i;unicode-casemap collation is well suited to use with many
-   Internet protocols and computer languages.  Use with natural language
-   is often inappropriate; even though the collation apparently supports
-   languages such as Swahili and English, in real-world use it tends to
-   mis-sort a number of types of string:
-
-   o  people and place names containing scripts that are not collated
-      according to "alphabetical order".
-   o  words with characters that have diacriticals.  However,
-      i;unicode-casemap generally does a better job than i;ascii-casemap
-      for most (but not all) languages.  For example, German umlaut
-      letters will sort correctly, but some Scandinavian letters will
-      not.
-   o  names such as "Lloyd" (which in Welsh sorts after "Lyon", unlike
-      in English),
-   o  strings containing other non-letter symbols; e.g., euro and pound
-      sterling symbols, quotation marks other than '"', dashes/hyphens,
-      etc.
-
-
-
-Crispin                     Standards Track                     [Page 3]
-
-RFC 5051                   i;unicode-casemap                October 2007
-
-
-3.  Unicode Casemap Collation Registration
-
-   <?xml version='1.0'?>
-   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
-   <collation rfc="5051" scope="global" intendedUse="common">
-   <identifier>i;unicode-casemap</identifier>
-   <title>Unicode Casemap</title>
-   <operations>equality order substring</operations>
-   <specification>RFC 5051</specification>
-   <owner>IETF</owner>
-   <submitter>mrc@cac.washington.edu</submitter>
-   </collation>
-
-4.  Security Considerations
-
-   The security considerations for [UTF-8], [STRINGPREP], and [UNICODE-
-   SECURITY] apply and are normative to this specification.
-
-   The results from this comparator will vary depending upon the
-   implementation for several reasons.  Implementations MUST consider
-   whether these possibilities are a problem for their use case:
-
-   1) New characters added in Unicode may have decomposition or
-      titlecase properties that will not be known to an implementation
-      based upon an older revision of Unicode.  This impacts step (2).
-
-   2) Step (2)(b) defines a subset of Normalization Form KD (NFKD) that
-      does not require normalization of out-of-order diacriticals.
-      However, an implementation MAY use an NFKD library routine that
-      does such normalization.  This impacts step (2)(b) and possibly
-      also step (1)(a), and is an issue only with ill-formed UTF-8
-      input.
-
-   3) The set of charsets handled in step (1)(a) is open-ended.  UTF-8
-      (and, by extension, US-ASCII) are the only mandatory-to-implement
-      charsets.  This impacts step (1)(a).
-
-      Implementations SHOULD, as far as feasible, support all the
-      charsets they are likely to encounter in the input data, in order
-      to avoid poor collation caused by the fall through to the (1)(b)
-      rule.
-
-   4) Other charsets may have revisions which add new characters that
-      are not known to an implementation based upon an older revision.
-      This impacts step (1)(a) and possibly also step (1)(b).
-
-
-
-
-
-
-Crispin                     Standards Track                     [Page 4]
-
-RFC 5051                   i;unicode-casemap                October 2007
-
-
-   An attacker may create input that is ill-formed or in an unknown
-   charset, with the intention of impacting the results of this
-   comparator or exploiting other parts of the system which process this
-   input in different ways.  Note, however, that even well-formed data
-   in a known charset can impact the result of this comparator in
-   unexpected ways.  For example, an attacker can substitute U+0041
-   (LATIN CAPITAL LETTER A) with U+0391 (GREEK CAPITAL LETTER ALPHA) or
-   U+0410 (CYRILLIC CAPITAL LETTER A) in the intention of causing a
-   non-match of strings which visually appear the same and/or causing
-   the string to appear elsewhere in a sort.
-
-5.  IANA Considerations
-
-   The i;unicode-casemap collation defined in section 2 has been added
-   to the registry of collations defined in [COMPARATOR].
-
-6.  Normative References
-
-   [COMPARATOR]          Newman, C., Duerst, M., and A. Gulbrandsen,
-                         "Internet Application Protocol Collation
-                         Registry", RFC 4790, February 2007.
-
-   [STRINGPREP]          Hoffman, P. and M. Blanchet, "Preparation of
-                         Internationalized Strings ("stringprep")", RFC
-                         3454, December 2002.
-
-   [UTF-8]               Yergeau, F., "UTF-8, a transformatio