harukin/core
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update SabreDAV from 1.8.9 to 1.8.10.

Browse Source
This commit is contained in:
Klaus Weidenbach 2014-06-28 22:28:08 +02:00
parent f49b74c5f6
commit 03b31d113e
239 changed files with 1509 additions and 115478 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
vendor/autoload.php vendored
View File

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

7
vendor/composer/ClassLoader.php vendored
View File

@ -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 {

1
vendor/composer/autoload_namespaces.php vendored
View File

@ -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'),
);

11
vendor/composer/autoload_real.php vendored
View File

@ -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;
}

62
vendor/composer/installed.json vendored
View File

@ -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
vendor/sabre/dav/.travis.yml vendored
View File

@ -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
vendor/sabre/dav/ChangeLog vendored
View File

@ -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
vendor/sabre/dav/bin/build.php vendored Normal file
View File

@ -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.";
}

72
vendor/sabre/dav/build.xml vendored
View File

@ -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>

336
vendor/sabre/dav/docs/caldav-ctag.txt vendored
View File

@ -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]

1568
vendor/sabre/dav/docs/caldav-notifications.txt vendored
View File

File diff suppressed because it is too large Load Diff

560
vendor/sabre/dav/docs/caldav-proxy.txt vendored
View File

@ -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]

1624
vendor/sabre/dav/docs/caldav-sharing.txt vendored
View File

File diff suppressed because it is too large Load Diff

560
vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt vendored
View File

@ -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]

5544
vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt vendored
View File

File diff suppressed because it is too large Load Diff

5152
vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt vendored
View File

File diff suppressed because it is too large Load Diff

1512
vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt vendored
View File

File diff suppressed because it is too large Load Diff

1512
vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt vendored
View File

File diff suppressed because it is too large Load Diff

2352
vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt vendored
View File

File diff suppressed because it is too large Load Diff

560
vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt vendored
View File

@ -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]

1851
vendor/sabre/dav/docs/rfc2425.txt vendored
View File

File diff suppressed because it is too large Load Diff

2355
vendor/sabre/dav/docs/rfc2426.txt vendored
View File

File diff suppressed because it is too large Load Diff

5267
vendor/sabre/dav/docs/rfc2518.txt vendored
View File

File diff suppressed because it is too large Load Diff

9859
vendor/sabre/dav/docs/rfc2616.txt vendored
View File

File diff suppressed because it is too large Load Diff

1907
vendor/sabre/dav/docs/rfc2617.txt vendored
View File

File diff suppressed because it is too large Load Diff

10329
vendor/sabre/dav/docs/rfc3253.pdf vendored
View File

File diff suppressed because one or more lines are too long

6295
vendor/sabre/dav/docs/rfc3744.pdf vendored
View File

File diff suppressed because one or more lines are too long

3127
vendor/sabre/dav/docs/rfc4437.pdf vendored
View File

File diff suppressed because one or more lines are too long

1459
vendor/sabre/dav/docs/rfc4790.txt vendored
View File

File diff suppressed because it is too large Load Diff

5995
vendor/sabre/dav/docs/rfc4791.txt vendored
View File

File diff suppressed because it is too large Load Diff

13609
vendor/sabre/dav/docs/rfc4918.pdf vendored
View File

File diff suppressed because one or more lines are too long

395
vendor/sabre/dav/docs/rfc5051.txt vendored
View File

@ -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 transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[UNICODE-DATA] <http://www.unicode.org/Public/UNIDATA/
UnicodeData.txt>
Although the UnicodeData.txt file referenced
here is part of the Unicode standard, it is
subject to change as new characters are added
to Unicode and errors are corrected in Unicode
revisions. As a result, it may be less stable
than might otherwise be implied by the
standards status of this specification.
[UNICODE-SECURITY] Davis, M. and M. Suignard, "Unicode Security
Considerations", February 2006,
<http://www.unicode.org/reports/tr36/>.
Crispin Standards Track [Page 5]
RFC 5051 i;unicode-casemap October 2007
7. Informative References
[BASIC] Newman, C., Duerst, M., and A. Gulbrandsen,
"i;basic - the Unicode Collation Algorithm",
Work in Progress, March 2007.
[IMAP-SORT] Crispin, M. and K. Murchison, "Internet Message
Access Protocol - SORT and THREAD Extensions",
Work in Progress, September 2007.
Author's Address
Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Avenue NE
Seattle, WA 98105-4527
Phone: +1 (206) 543-5762
EMail: MRC@CAC.Washington.EDU
Crispin Standards Track [Page 6]
RFC 5051 i;unicode-casemap October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Crispin Standards Track [Page 7]

281
vendor/sabre/dav/docs/rfc5397.txt vendored
View File

@ -1,281 +0,0 @@
Network Working Group W. Sanchez
Request for Comments: 5397 C. Daboo
Category: Standards Track Apple Inc.
December 2008
WebDAV Current Principal Extension
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2008 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.
Abstract
This specification defines a new WebDAV property that allows clients
to quickly determine the principal corresponding to the current
authenticated user.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. DAV:current-user-principal . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Sanchez & Daboo Standards Track [Page 1]
RFC 5397 WebDAV Current Principal December 2008
1. Introduction
WebDAV [RFC4918] is an extension to HTTP [RFC2616] to support
improved document authoring capabilities. The WebDAV Access Control
Protocol ("WebDAV ACL") [RFC3744] extension adds access control
capabilities to WebDAV. It introduces the concept of a "principal"
resource, which is used to represent information about authenticated
entities on the system.
Some clients have a need to determine which [RFC3744] principal a
server is associating with the currently authenticated HTTP user.
While [RFC3744] defines a DAV:current-user-privilege-set property for
retrieving the privileges granted to that principal, there is no
recommended way to identify the principal in question, which is
necessary to perform other useful operations. For example, a client
may wish to determine which groups the current user is a member of,
or modify a property of the principal resource associated with the
current user.
The DAV:principal-match REPORT provides some useful functionality,
but there are common situations where the results from that query can
be ambiguous. For example, not only is an individual user principal
returned, but also every group principal that the user is a member
of, and there is no clear way to distinguish which is which.
This specification proposes an extension to WebDAV ACL that adds a
DAV:current-user-principal property to resources under access control
on the server. This property provides a URL to a principal resource
corresponding to the currently authenticated user. This allows a
client to "bootstrap" itself by performing additional queries on the
principal resource to obtain additional information from that
resource, which is the purpose of this extension. Note that while it
is possible for multiple URLs to refer to the same principal
resource, or for multiple principal resources to correspond to a
single principal, this specification only allows for a single http(s)
URL in the DAV:current-user-principal property. If a client wishes
to obtain alternate URLs for the principal, it can query the
principal resource for this information; it is not the purpose of
this extension to provide a complete list of such URLs, but simply to
provide a means to locate a resource which contains that (and other)
information.
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].
Sanchez & Daboo Standards Track [Page 2]
RFC 5397 WebDAV Current Principal December 2008
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.
Processing of XML by clients and servers MUST follow the rules
defined in Section 17 of WebDAV [RFC4918].
Some of the declarations refer to XML elements defined by WebDAV
[RFC4918].
3. DAV:current-user-principal
Name: current-user-principal
Namespace: DAV:
Purpose: Indicates a URL for the currently authenticated user's
principal resource on the server.
Value: A single DAV:href or DAV:unauthenticated element.
Protected: This property is computed on a per-request basis, and
therefore is protected.
Description: The DAV:current-user-principal property contains either
a DAV:href or DAV:unauthenticated XML element. The DAV:href
element contains a URL to a principal resource corresponding to
the currently authenticated user. That URL MUST be one of the
URLs in the DAV:principal-URL or DAV:alternate-URI-set properties
defined on the principal resource and MUST be an http(s) scheme
URL. When authentication has not been done or has failed, this
property MUST contain the DAV:unauthenticated pseudo-principal.
In some cases, there may be multiple principal resources
corresponding to the same authenticated principal. In that case,
the server is free to choose any one of the principal resource
URIs for the value of the DAV:current-user-principal property.
However, servers SHOULD be consistent and use the same principal
resource URI for each authenticated principal.
COPY/MOVE behavior: This property is computed on a per-request
basis, and is thus never copied or moved.
Definition:
<!ELEMENT current-user-principal (unauthenticated | href)>
<!-- href value: a URL to a principal resource -->
Sanchez & Daboo Standards Track [Page 3]
RFC 5397 WebDAV Current Principal December 2008
Example:
<D:current-user-principal xmlns:D="DAV:">
<D:href>/principals/users/cdaboo</D:href>
</D:current-user-principal>
4. Security Considerations
This specification does not introduce any additional security issues
beyond those defined for HTTP [RFC2616], WebDAV [RFC4918], and WebDAV
ACL [RFC3744].
5. Acknowledgments
This specification is based on discussions that took place within the
Calendaring and Scheduling Consortium's CalDAV Technical Committee.
The authors thank the participants of that group for their input.
The authors thank Julian Reschke for his valuable input via the
WebDAV working group mailing list.
6. 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.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
Authors' Addresses
Wilfredo Sanchez
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: wsanchez@wsanchez.net
URI: http://www.apple.com/
Sanchez & Daboo Standards Track [Page 4]
RFC 5397 WebDAV Current Principal December 2008
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Sanchez & Daboo Standards Track [Page 5]

9411
vendor/sabre/dav/docs/rfc5545.txt vendored
View File

File diff suppressed because it is too large Load Diff

7451
vendor/sabre/dav/docs/rfc5546.txt vendored
View File

File diff suppressed because it is too large Load Diff

675
vendor/sabre/dav/docs/rfc5689.txt vendored
View File

@ -1,675 +0,0 @@
Network Working Group C. Daboo
Request for Comments: 5689 Apple Inc.
Updates: 4791, 4918 September 2009
Category: Standards Track
Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)
Abstract
This specification extends the Web Distributed Authoring and
Versioning (WebDAV) MKCOL (Make Collection) method to allow
collections of arbitrary resourcetype to be created and to allow
properties to be set at the same time.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
Daboo Standards Track [Page 1]
RFC 5689 Extended MKCOL for WebDAV September 2009
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. WebDAV Extended MKCOL . . . . . . . . . . . . . . . . . . . . 4
3.1. Extended MKCOL Support . . . . . . . . . . . . . . . . . . 5
3.1.1. Example: Using OPTIONS for the Discovery of
Support for Extended MKCOL . . . . . . . . . . . . . . 5
3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Additional Precondition for Extended MKCOL . . . . . . . . 5
3.4. Example: Successful Extended MKCOL Request . . . . . . . . 6
3.5. Example: Unsuccessful Extended MKCOL Request . . . . . . . 6
4. Using Extended MKCOL as an Alternative for MKxxx Methods . . . 8
4.1. MKCALENDAR Alternative . . . . . . . . . . . . . . . . . . 8
4.1.1. Example: Using MKCOL Instead of MKCALENDAR . . . . . . 8
5. XML Element Definitions . . . . . . . . . . . . . . . . . . . 10
5.1. mkcol XML Element . . . . . . . . . . . . . . . . . . . . 10
5.2. mkcol-response XML Element . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Daboo Standards Track [Page 2]
RFC 5689 Extended MKCOL for WebDAV September 2009
1. Introduction
WebDAV [RFC4918] defines the HTTP [RFC2616] method MKCOL. This
method is used to create WebDAV collections on the server. However,
several WebDAV-based specifications (e.g., CalDAV [RFC4791]) define
"special" collections -- ones that are identified by additional
values in the DAV:resourcetype property assigned to the collection
resource or by other means. These "special" collections are created
by new methods (e.g., MKCALENDAR). The addition of a new MKxxx
method for each new "special" collection adds to server complexity
and is detrimental to overall reliability due to the need to make
sure intermediaries are aware of these methods.
This specification defines an extension to the WebDAV MKCOL method
that adds a request body allowing a client to specify WebDAV
properties to be set on the newly created collection or resource. In
particular, the DAV:resourcetype property can be used to create a
"special" collection; alternatively, other properties can be used to
create a "special" resource. This avoids the need to invent new
MKxxx methods.
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].
This document uses XML DTD fragments (Section 3.2 of
[W3C.REC-xml-20081126]) 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.
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.
Daboo Standards Track [Page 3]
RFC 5689 Extended MKCOL for WebDAV September 2009
When an XML element type in the "DAV:" namespace is referenced in
this document outside of the context of an XML fragment, the string
"DAV:" will be prefixed to the element type.
This document inherits, and sometimes extends, DTD productions from
Section 14 of [RFC4918].
3. WebDAV Extended MKCOL
The WebDAV MKCOL request is extended to allow the inclusion of a
request body. The request body is an XML document containing a
single DAV:mkcol XML element as the root element. The Content-Type
request header MUST be set appropriately for an XML body (e.g., set
to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL
request that do not have DAV:mkcol as the root element are reserved
for future usage.
One or more DAV:set XML elements may be included in the DAV:mkcol XML
element to allow setting properties on the collection as it is
created. In particular, to create a collection of a particular type,
the DAV:resourcetype XML element MUST be included in a DAV:set XML
element and MUST specify the expected resource type elements for the
new resource, which MUST include the DAV:collection element that
needs to be present for any WebDAV collection.
As per the PROPPATCH method (Section 9.2 of [RFC4918]), servers MUST
process any DAV:set instructions in document order (an exception to
the normal rule that ordering is irrelevant). If any one instruction
fails to execute successfully, all instructions MUST fail (i.e.,
either all succeed or all fail). Thus, if any error occurs during
processing, all executed instructions MUST be undone and a proper
error result returned. Failure to set a property value on the
collection MUST result in a failure of the overall MKCOL request --
i.e., the collection is not created.
The response to an extended MKCOL request MUST be an XML document
containing a single DAV:mkcol-response XML element, which MUST
contain DAV:propstat XML elements with the status of each property
when the request fails due to a failure to set one or more of the
properties specified in the request body. The server MAY return a
response body in the case where the request is successful, indicating
success for setting each property specified in the request body.
When an empty response body is returned with a success request status
code, the client can assume that all properties were set.
In all other respects, the behavior of the extended MKCOL request
follows that of the standard MKCOL request.
Daboo Standards Track [Page 4]
RFC 5689 Extended MKCOL for WebDAV September 2009
3.1. Extended MKCOL Support
A server supporting the features described in this document MUST
include "extended-mkcol" as a field in the DAV response header from
an OPTIONS request on any URI that supports use of the extended MKCOL
method.
3.1.1. Example: Using OPTIONS for the Discovery of Support for Extended
MKCOL
>> Request <<
OPTIONS /addressbooks/users/ HTTP/1.1
Host: addressbook.example.com
>> Response <<
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, extended-mkcol
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Length: 0
3.2. Status Codes
As per Section 9.3.1 of [RFC4918].
3.3. Additional Precondition for Extended MKCOL
WebDAV ([RFC4918], Section 16) defines preconditions and
postconditions for request behavior. This specification adds the
following precondition for the extended MKCOL request.
Name: valid-resourcetype
Namespace: DAV:
Use with: Typically 403 (Forbidden)
Purpose: (precondition) -- The server MUST support the specified
resourcetype value for the specified collection.
Daboo Standards Track [Page 5]
RFC 5689 Extended MKCOL for WebDAV September 2009
3.4. Example: Successful Extended MKCOL Request
This example shows how the extended MKCOL request is used to create a
collection of a fictitious type "special-resource". The response
body is empty as the request completed successfully.
>> Request <<
MKCOL /home/special/ HTTP/1.1
Host: special.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol xmlns:D="DAV:"
xmlns:E="http://example.com/ns/">
<D:set>
<D:prop>
<D:resourcetype>
<D:collection/>
<E:special-resource/>
</D:resourcetype>
<D:displayname>Special Resource</D:displayname>
</D:prop>
</D:set>
</D:mkcol>
>> Response <<
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
3.5. Example: Unsuccessful Extended MKCOL Request
This example shows an attempt to use the extended MKCOL request to
create a collection of a fictitious type "special-resource", which is
not actually supported by the server. The response body shows that
an error occurred specifically with the DAV:resourcetype property.
Daboo Standards Track [Page 6]
RFC 5689 Extended MKCOL for WebDAV September 2009
>> Request <<
MKCOL /home/special/ HTTP/1.1
Host: special.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol xmlns:D="DAV:"
xmlns:E="http://example.com/ns/">
<D:set>
<D:prop>
<D:resourcetype>
<D:collection/>
<E:special-resource/>
</D:resourcetype>
<D:displayname>Special Resource</D:displayname>
</D:prop>
</D:set>
</D:mkcol>
>> Response <<
HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol-response xmlns:D="DAV:">
<D:propstat>
<D:prop>
<D:resourcetype/>
</D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:error><D:valid-resourcetype /></D:error>
<D:responsedescription>Resource type is not
supported by this server</D:responsedescription>
</D:propstat>
<D:propstat>
<D:prop>
<D:displayname/>
</D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</D:mkcol-response>
Daboo Standards Track [Page 7]
RFC 5689 Extended MKCOL for WebDAV September 2009
4. Using Extended MKCOL as an Alternative for MKxxx Methods
One of the goals of this extension is to eliminate the need for other
extensions to define their own variant of MKCOL to create the special
collections they need. This extension can be used as an alternative
to existing MKxxx methods in other extensions as detailed below. If
a server supports this extension and the other extension listed, then
the server MUST support use of the extended MKCOL method to achieve
the same result as the MKxxx method of the other extension.
4.1. MKCALENDAR Alternative
CalDAV defines the MKCALENDAR method to create a calendar collection
as well as to set properties during creation (Section 5.3.1 of
[RFC4791]).
The extended MKCOL method can be used instead by specifying both DAV:
collection and CALDAV:calendar-collection XML elements in the DAV:
resourcetype property, set during the extended MKCOL request.
4.1.1. Example: Using MKCOL Instead of MKCALENDAR
The first example below shows an MKCALENDAR request containing a
CALDAV:mkcalendar XML element in the request body and returning a
CALDAV:mkcalendar-response XML element in the response body.
>> MKCALENDAR Request <<
MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:mkcalendar xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:set>
<D:prop>
<D:displayname>Lisa's Events</D:displayname>
</D:prop>
</D:set>
</C:mkcalendar>
Daboo Standards Track [Page 8]
RFC 5689 Extended MKCOL for WebDAV September 2009
>> MKCALENDAR Response <<
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:mkcalendar-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:propstat>
<D:prop>
<D:displayname/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</C:mkcalendar-response>
The second example shows the equivalent extended MKCOL request with
the same request and response XML elements.
>> MKCOL Request <<
MKCOL /home/lisa/calendars/events/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:set>
<D:prop>
<D:resourcetype>
<D:collection/>
<C:calendar/>
</D:resourcetype>
<D:displayname>Lisa's Events</D:displayname>
</D:prop>
</D:set>
</D:mkcol>
Daboo Standards Track [Page 9]
RFC 5689 Extended MKCOL for WebDAV September 2009
>> MKCOL Response <<
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:propstat>
<D:prop>
<D:resourcetype/>
<D:displayname/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:mkcol-response>
5. XML Element Definitions
5.1. mkcol XML Element
Name: mkcol
Namespace: DAV:
Purpose: Used in a request to specify properties to be set in an
extended MKCOL request, as well as any additional information
needed when creating the resource.
Description: This XML element is a container for the information
required to modify the properties on a collection resource as it
is created in an extended MKCOL request.
Definition:
<!ELEMENT mkcol (set+)>
5.2. mkcol-response XML Element
Name: mkcol-response
Namespace: DAV:
Daboo Standards Track [Page 10]
RFC 5689 Extended MKCOL for WebDAV September 2009
Purpose: Used in a response to indicate the status of properties
that were set or failed to be set during an extended MKCOL
request.
Description: This XML element is a container for the information
returned about a resource that has been created in an extended
MKCOL request.
Definition:
<!ELEMENT mkcol-response (propstat+)>
6. Security Considerations
This extension does not introduce any new security concerns beyond
those already described in HTTP [RFC2616] and WebDAV [RFC4918].
7. Acknowledgments
Thanks to Bernard Desruisseaux, Mike Douglass, Alexey Melnikov,
Julian Reschke, and Simon Vaillancourt.
8. 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.
[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.
[W3C.REC-xml-20081126]
Maler, E., Yergeau, F., Paoli, J., Bray, T., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web Consortium
Recommendation REC-xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
Daboo Standards Track [Page 11]
RFC 5689 Extended MKCOL for WebDAV September 2009
Author's Address
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Daboo Standards Track [Page 12]

451
vendor/sabre/dav/docs/rfc5785.txt vendored
View File

@ -1,451 +0,0 @@
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 5785 E. Hammer-Lahav
Updates: 2616, 2818 April 2010
Category: Standards Track
ISSN: 2070-1721
Defining Well-Known Uniform Resource Identifiers (URIs)
Abstract
This memo defines a path prefix for "well-known locations",
"/.well-known/", in selected Uniform Resource Identifier (URI)
schemes.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5785.
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.
Nottingham & Hammer-Lahav Standards Track [Page 1]
RFC 5785 Defining Well-Known URIs April 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Appropriate Use of Well-Known URIs . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 7
1. Introduction
It is increasingly common for Web-based protocols to require the
discovery of policy or other information about a host ("site-wide
metadata") before making a request. For example, the Robots
Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
automated processes to obtain permission to access resources;
likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
tells user-agents how to discover privacy policy beforehand.
While there are several ways to access per-resource metadata (e.g.,
HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
(either in terms of client-perceived latency and/or deployment
difficulties) associated with them often precludes their use in these
scenarios.
When this happens, it is common to designate a "well-known location"
for such data, so that it can be easily located. However, this
approach has the drawback of risking collisions, both with other such
designated "well-known locations" and with pre-existing resources.
To address this, this memo defines a path prefix in HTTP(S) URIs for
these "well-known locations", "/.well-known/". Future specifications
that need to define a resource for such site-wide metadata can
register their use to avoid collisions and minimise impingement upon
sites' URI space.
Nottingham & Hammer-Lahav Standards Track [Page 2]
RFC 5785 Defining Well-Known URIs April 2010
1.1. Appropriate Use of Well-Known URIs
There are a number of possible ways that applications could use Well-
known URIs. However, in keeping with the Architecture of the World-
Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
for general information retrieval or establishment of large URI
namespaces on the Web. Rather, they are designed to facilitate
discovery of information on a site when it isn't practical to use
other mechanisms; for example, when discovering policy that needs to
be evaluated before a resource is accessed, or when using multiple
round-trips is judged detrimental to performance.
As such, the well-known URI space was created with the expectation
that it will be used to make site-wide policy information and other
metadata available directly (if sufficiently concise), or provide
references to other URIs that provide such metadata.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Well-Known URIs
A well-known URI is a URI [RFC3986] whose path component begins with
the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
or another scheme that has explicitly been specified to use well-
known URIs.
Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1.
For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'.
Registered names MUST conform to the segment-nz production in
[RFC3986].
Note that this specification defines neither how to determine the
authority to use for a particular context, nor the scope of the
metadata discovered by dereferencing the well-known URI; both should
be defined by the application itself.
Typically, a registration will reference a specification that defines
the format and associated media type to be obtained by dereferencing
the well-known URI.
Nottingham & Hammer-Lahav Standards Track [Page 3]
RFC 5785 Defining Well-Known URIs April 2010
It MAY also contain additional information, such as the syntax of
additional path components, query strings and/or fragment identifiers
to be appended to the well-known URI, or protocol-specific details
(e.g., HTTP [RFC2616] method handling).
Note that this specification does not define a format or media-type
for the resource located at "/.well-known/" and clients should not
expect a resource to exist at that location.
4. Security Considerations
This memo does not specify the scope of applicability of metadata or
policy obtained from a well-known URI, and does not specify how to
discover a well-known URI for a particular application. Individual
applications using this mechanism must define both aspects.
Applications minting new well-known URIs, as well as administrators
deploying them, will need to consider several security-related
issues, including (but not limited to) exposure of sensitive data,
denial-of-service attacks (in addition to normal load issues), server
and client authentication, vulnerability to DNS rebinding attacks,
and attacks where limited access to a server grants the ability to
affect how well-known URIs are served.
5. IANA Considerations
5.1. The Well-Known URI Registry
This document establishes the well-known URI registry.
Well-known URIs are registered on the advice of one or more
Designated Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]). However,
to allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied
that such a specification will be published.
Registration requests should be sent to the
wellknown-uri-review@ietf.org mailing list for review and comment,
with an appropriate subject (e.g., "Request for well-known URI:
example").
Before a period of 14 days has passed, the Designated Expert(s) will
either approve or deny the registration request, communicating this
decision both to the review list and to IANA. Denials should include
an explanation and, if applicable, suggestions as to how to make the
Nottingham & Hammer-Lahav Standards Track [Page 4]
RFC 5785 Defining Well-Known URIs April 2010
request successful. Registration requests that are undetermined for
a period longer than 21 days can be brought to the IESG's attention
(using the iesg@iesg.org mailing list) for resolution.
5.1.1. Registration Template
URI suffix: The name requested for the well-known URI, relative to
"/.well-known/"; e.g., "example".
Change controller: For Standards-Track RFCs, state "IETF". For
others, give the name of the responsible party. Other details
(e.g., postal address, e-mail address, home page URI) may also be
included.
Specification document(s): Reference to the document that specifies
the field, preferably including a URI that can be used to retrieve
a copy of the document. An indication of the relevant sections
may also be included, but is not required.
Related information: Optionally, citations to additional documents
containing further relevant information.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
6.2. Informative References
[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.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
Nottingham & Hammer-Lahav Standards Track [Page 5]
RFC 5785 Defining Well-Known URIs April 2010
[W3C.REC-P3P-20020416]
Marchiori, M., "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", World Wide Web Consortium
Recommendation REC-P3P-20020416, April 2002,
<http://www.w3.org/TR/2002/ REC-P3P-20020416>.
[W3C.REC-webarch-20041215]
Jacobs, I. and N. Walsh, "Architecture of the World Wide
Web, Volume One", World Wide Web Consortium
Recommendation REC- webarch-20041215, December 2004,
<http:// www.w3.org/TR/2004/REC-webarch-20041215>.
Nottingham & Hammer-Lahav Standards Track [Page 6]
RFC 5785 Defining Well-Known URIs April 2010
Appendix A. Acknowledgements
We would like to acknowledge the contributions of everyone who
provided feedback and use cases for this document; in particular,
Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
not responsible for errors and omissions.
Appendix B. Frequently Asked Questions
1. Aren't well-known locations bad for the Web?
They are, but for various reasons -- both technical and social --
they are commonly used and their use is increasing. This memo
defines a "sandbox" for them, to reduce the risks of collision and
to minimise the impact upon pre-existing URIs on sites.
2. Why /.well-known?
It's short, descriptive, and according to search indices, not
widely used.
3. What impact does this have on existing mechanisms, such as P3P and
robots.txt?
None, until they choose to use this mechanism.
4. Why aren't per-directory well-known locations defined?
Allowing every URI path segment to have a well-known location
(e.g., "/images/.well-known/") would increase the risks of
colliding with a pre-existing URI on a site, and generally these
solutions are found not to scale well, because they're too
"chatty".
Nottingham & Hammer-Lahav Standards Track [Page 7]
RFC 5785 Defining Well-Known URIs April 2010
Authors' Addresses
Mark Nottingham
EMail: mnot@mnot.net
URI: http://www.mnot.net/
Eran Hammer-Lahav
EMail: eran@hueniverse.com
URI: http://hueniverse.com/
Nottingham & Hammer-Lahav Standards Track [Page 8]

563
vendor/sabre/dav/docs/rfc5789.txt vendored
View File

@ -1,563 +0,0 @@
Internet Engineering Task Force (IETF) L. Dusseault
Request for Comments: 5789 Linden Lab
Category: Standards Track J. Snell
ISSN: 2070-1721 March 2010
PATCH Method for HTTP
Abstract
Several applications extending the Hypertext Transfer Protocol (HTTP)
require a feature to do partial resource modification. The existing
HTTP PUT method only allows a complete replacement of a document.
This proposal adds a new HTTP method, PATCH, to modify an existing
HTTP resource.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5789.
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.
Dusseault & Snell Standards Track [Page 1]
RFC 5789 HTTP PATCH March 2010
Table of Contents
1. Introduction ....................................................2
2. The PATCH Method ................................................2
2.1. A Simple PATCH Example .....................................4
2.2. Error Handling .............................................5
3. Advertising Support in OPTIONS ..................................7
3.1. The Accept-Patch Header ....................................7
3.2. Example OPTIONS Request and Response .......................7
4. IANA Considerations .............................................8
4.1. The Accept-Patch Response Header ...........................8
5. Security Considerations .........................................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Appendix A. Acknowledgements .....................................10
1. Introduction
This specification defines the new HTTP/1.1 [RFC2616] method, PATCH,
which is used to apply partial modifications to a resource.
A new method is necessary to improve interoperability and prevent
errors. The PUT method is already defined to overwrite a resource
with a complete new body, and cannot be reused to do partial changes.
Otherwise, proxies and caches, and even clients and servers, may get
confused as to the result of the operation. POST is already used but
without broad interoperability (for one, there is no standard way to
discover patch format support). PATCH was mentioned in earlier HTTP
specifications, but not completely defined.
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in [RFC2119].
Furthermore, this document uses the ABNF syntax defined in Section
2.1 of [RFC2616].
2. The PATCH Method
The PATCH method requests that a set of changes described in the
request entity be applied to the resource identified by the Request-
URI. The set of changes is represented in a format called a "patch
document" identified by a media type. If the Request-URI does not
point to an existing resource, the server MAY create a new resource,
depending on the patch document type (whether it can logically modify
a null resource) and permissions, etc.
Dusseault & Snell Standards Track [Page 2]
RFC 5789 HTTP PATCH March 2010
The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version
be replaced. With PATCH, however, the enclosed entity contains a set
of instructions describing how a resource currently residing on the
origin server should be modified to produce a new version. The PATCH
method affects the resource identified by the Request-URI, and it
also MAY have side effects on other resources; i.e., new resources
may be created, or existing ones modified, by the application of a
PATCH.
PATCH is neither safe nor idempotent as defined by [RFC2616], Section
9.1.
A PATCH request can be issued in such a way as to be idempotent,
which also helps prevent bad outcomes from collisions between two
PATCH requests on the same resource in a similar time frame.
Collisions from multiple PATCH requests may be more dangerous than
PUT collisions because some patch formats need to operate from a
known base-point or else they will corrupt the resource. Clients
using this kind of patch application SHOULD use a conditional request
such that the request will fail if the resource has been updated
since the client last accessed the resource. For example, the client
can use a strong ETag [RFC2616] in an If-Match header on the PATCH
request.
There are also cases where patch formats do not need to operate from
a known base-point (e.g., appending text lines to log files, or non-
colliding rows to database tables), in which case the same care in
client requests is not needed.
The server MUST apply the entire set of changes atomically and never
provide (e.g., in response to a GET during this operation) a
partially modified representation. If the entire patch document
cannot be successfully applied, then the server MUST NOT apply any of
the changes. The determination of what constitutes a successful
PATCH can vary depending on the patch document and the type of
resource(s) being modified. For example, the common 'diff' utility
can generate a patch document that applies to multiple files in a
directory hierarchy. The atomicity requirement holds for all
directly affected files. See "Error Handling", Section 2.2, for
details on status codes and possible error conditions.
If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be
treated as stale. A response to this method is only cacheable if it
Dusseault & Snell Standards Track [Page 3]
RFC 5789 HTTP PATCH March 2010
contains explicit freshness information (such as an Expires header or
"Cache-Control: max-age" directive) as well as the Content-Location
header matching the Request-URI, indicating that the PATCH response
body is a resource representation. A cached PATCH response can only
be used to respond to subsequent GET and HEAD requests; it MUST NOT
be used to respond to other methods (in particular, PATCH).
Note that entity-headers contained in the request apply only to the
contained patch document and MUST NOT be applied to the resource
being modified. Thus, a Content-Language header could be present on
the request, but it would only mean (for whatever that's worth) that
the patch document had a language. Servers SHOULD NOT store such
headers except as trace information, and SHOULD NOT use such header
values the same way they might be used on PUT requests. Therefore,
this document does not specify a way to modify a document's Content-
Type or Content-Language value through headers, though a mechanism
could well be designed to achieve this goal through a patch document.
There is no guarantee that a resource can be modified with PATCH.
Further, it is expected that different patch document formats will be
appropriate for different types of resources and that no single
format will be appropriate for all types of resources. Therefore,
there is no single default patch document format that implementations
are required to support. Servers MUST ensure that a received patch
document is appropriate for the type of resource identified by the
Request-URI.
Clients need to choose when to use PATCH rather than PUT. For
example, if the patch document size is larger than the size of the
new resource data that would be used in a PUT, then it might make
sense to use PUT instead of PATCH. A comparison to POST is even more
difficult, because POST is used in widely varying ways and can
encompass PUT and PATCH-like operations if the server chooses. If
the operation does not modify the resource identified by the Request-
URI in a predictable way, POST should be considered instead of PATCH
or PUT.
2.1. A Simple PATCH Example
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
Dusseault & Snell Standards Track [Page 4]
RFC 5789 HTTP PATCH March 2010
This example illustrates use of a hypothetical patch document on an
existing resource.
Successful PATCH response to existing text file:
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
The 204 response code is used because the response does not carry a
message body (which a response with the 200 code would have). Note
that other success codes could be used as well.
Furthermore, the ETag response header field contains the ETag for the
entity created by applying the PATCH, available at
http://www.example.com/file.txt, as indicated by the Content-Location
response header field.
2.2. Error Handling
There are several known conditions under which a PATCH request can
fail.
Malformed patch document: When the server determines that the patch
document provided by the client is not properly formatted, it
SHOULD return a 400 (Bad Request) response. The definition of
badly formatted depends on the patch document chosen.
Unsupported patch document: Can be specified using a 415
(Unsupported Media Type) response when the client sends a patch
document format that the server does not support for the resource
identified by the Request-URI. Such a response SHOULD include an
Accept-Patch response header as described in Section 3.1 to notify
the client what patch document media types are supported.
Unprocessable request: Can be specified with a 422 (Unprocessable
Entity) response ([RFC4918], Section 11.2) when the server
understands the patch document and the syntax of the patch
document appears to be valid, but the server is incapable of
processing the request. This might include attempts to modify a
resource in a way that would cause the resource to become invalid;
for instance, a modification to a well-formed XML document that
would cause it to no longer be well-formed. There may also be
more specific errors like "Conflicting State" that could be
signaled with this status code, but the more specific error would
generally be more helpful.
Dusseault & Snell Standards Track [Page 5]
RFC 5789 HTTP PATCH March 2010
Resource not found: Can be specified with a 404 (Not Found) status
code when the client attempted to apply a patch document to a non-
existent resource, but the patch document chosen cannot be applied
to a non-existent resource.
Conflicting state: Can be specified with a 409 (Conflict) status
code when the request cannot be applied given the state of the
resource. For example, if the client attempted to apply a
structural modification and the structures assumed to exist did
not exist (with XML, a patch might specify changing element 'foo'
to element 'bar' but element 'foo' might not exist).
Conflicting modification: When a client uses either the If-Match or
If-Unmodified-Since header to define a precondition, and that
precondition failed, then the 412 (Precondition Failed) error is
most helpful to the client. However, that response makes no sense
if there was no precondition on the request. In cases when the
server detects a possible conflicting modification and no
precondition was defined in the request, the server can return a
409 (Conflict) response.
Concurrent modification: Some applications of PATCH might require
the server to process requests in the order in which they are
received. If a server is operating under those restrictions, and
it receives concurrent requests to modify the same resource, but
is unable to queue those requests, the server can usefully
indicate this error by using a 409 (Conflict) response.
Note that the 409 Conflict response gives reasonably consistent
information to clients. Depending on the application and the nature
of the patch format, the client might be able to reissue the request
as is (e.g., an instruction to append a line to a log file), have to
retrieve the resource content to recalculate a patch, or have to fail
the operation.
Other HTTP status codes can also be used under the appropriate
circumstances.
The entity body of error responses SHOULD contain enough information
to communicate the nature of the error to the client. The content-
type of the response entity can vary across implementations.
Dusseault & Snell Standards Track [Page 6]
RFC 5789 HTTP PATCH March 2010
3. Advertising Support in OPTIONS
A server can advertise its support for the PATCH method by adding it
to the listing of allowed methods in the "Allow" OPTIONS response
header defined in HTTP/1.1. The PATCH method MAY appear in the
"Allow" header even if the Accept-Patch header is absent, in which
case the list of allowed patch documents is not advertised.
3.1. The Accept-Patch Header
This specification introduces a new response header Accept-Patch used
to specify the patch document formats accepted by the server.
Accept-Patch SHOULD appear in the OPTIONS response for any resource
that supports the use of the PATCH method. The presence of the
Accept-Patch header in response to any method is an implicit
indication that PATCH is allowed on the resource identified by the
Request-URI. The presence of a specific patch document format in
this header indicates that that specific format is allowed on the
resource identified by the Request-URI.
Accept-Patch = "Accept-Patch" ":" 1#media-type
The Accept-Patch header specifies a comma-separated listing of media-
types (with optional parameters) as defined by [RFC2616], Section
3.7.
Example:
Accept-Patch: text/example;charset=utf-8
3.2. Example OPTIONS Request and Response
[request]
OPTIONS /example/buddies.xml HTTP/1.1
Host: www.example.com
[response]
HTTP/1.1 200 OK
Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
Accept-Patch: application/example, text/example
The examples show a server that supports PATCH generally using two
hypothetical patch document formats.
Dusseault & Snell Standards Track [Page 7]
RFC 5789 HTTP PATCH March 2010
4. IANA Considerations
4.1. The Accept-Patch Response Header
The Accept-Patch response header has been added to the permanent
registry (see [RFC3864]).
Header field name: Accept-Patch
Applicable Protocol: HTTP
Author/Change controller: IETF
Specification document: this specification
5. Security Considerations
The security considerations for PATCH are nearly identical to the
security considerations for PUT ([RFC2616], Section 9.6). These
include authorizing requests (possibly through access control and/or
authentication) and ensuring that data is not corrupted through
transport errors or through accidental overwrites. Whatever
mechanisms are used for PUT can be used for PATCH as well. The
following considerations apply especially to PATCH.
A document that is patched might be more likely to be corrupted than
a document that is overridden in entirety, but that concern can be
addressed through the use of mechanisms such as conditional requests
using ETags and the If-Match request header as described in
Section 2. If a PATCH request fails, the client can issue a GET
request to the resource to see what state it is in. In some cases,
the client might be able to check the contents of the resource to see
if the PATCH request can be resent, but in other cases, the attempt
will just fail and/or a user will have to verify intent. In the case
of a failure of the underlying transport channel, where a PATCH
response is not received before the channel fails or some other
timeout happens, the client might have to issue a GET request to see
whether the request was applied. The client might want to ensure
that the GET request bypasses caches using mechanisms described in
HTTP specifications (see, for example, Section 13.1.6 of [RFC2616]).
Sometimes an HTTP intermediary might try to detect viruses being sent
via HTTP by checking the body of the PUT/POST request or GET
response. The PATCH method complicates such watch-keeping because
neither the source document nor the patch document might be a virus,
yet the result could be. This security consideration is not
Dusseault & Snell Standards Track [Page 8]
RFC 5789 HTTP PATCH March 2010
materially different from those already introduced by byte-range
downloads, downloading patch documents, uploading zipped (compressed)
files, and so on.
Individual patch documents will have their own specific security
considerations that will likely vary depending on the types of
resources being patched. The considerations for patched binary
resources, for instance, will be different than those for patched XML
documents. Servers MUST take adequate precautions to ensure that
malicious clients cannot consume excessive server resources (e.g.,
CPU, disk I/O) through the client's use of PATCH.
6. References
6.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.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
6.2. Informative References
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
Dusseault & Snell Standards Track [Page 9]
RFC 5789 HTTP PATCH March 2010
Appendix A. Acknowledgements
PATCH is not a new concept, it first appeared in HTTP in drafts of
version 1.1 written by Roy Fielding and Henrik Frystyk and also
appears in Section 19.6.1.1 of RFC 2068.
Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott
Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex
Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham, Michael
Balloni, Cyrus Daboo, Brian Carpenter, John Klensin, Eliot Lear, SM,
and Bernie Hoeneisen for review and advice on this document. In
particular, Julian Reschke did repeated reviews, made many useful
suggestions, and was critical to the publication of this document.
Authors' Addresses
Lisa Dusseault
Linden Lab
945 Battery Street
San Francisco, CA 94111
USA
EMail: lisa.dusseault@gmail.com
James M. Snell
EMail: jasnell@gmail.com
URI: http://www.snellspace.com
Dusseault & Snell Standards Track [Page 10]

1235
vendor/sabre/dav/docs/rfc6047.txt vendored
View File

File diff suppressed because it is too large Load Diff

3027
vendor/sabre/dav/docs/rfc6321.txt vendored
View File

File diff suppressed because it is too large Load Diff

4147
vendor/sabre/dav/docs/rfc6350.txt vendored
View File

File diff suppressed because it is too large Load Diff

1235
vendor/sabre/dav/docs/rfc6351.txt vendored
View File

File diff suppressed because it is too large Load Diff

2691
vendor/sabre/dav/docs/rfc6352.txt vendored
View File

File diff suppressed because it is too large Load Diff

2
vendor/sabre/dav/lib/Sabre/CalDAV/Backend/AbstractBackend.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
abstract class AbstractBackend implements BackendInterface {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Backend/BackendInterface.php vendored
View File

@ -7,7 +7,7 @@ namespace Sabre\CalDAV\Backend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface BackendInterface {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Backend/NotificationSupport.php vendored
View File

@ -18,7 +18,7 @@ namespace Sabre\CalDAV\Backend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface NotificationSupport extends BackendInterface {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Backend/PDO.php vendored
View File

@ -14,7 +14,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class PDO extends AbstractBackend {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Backend/SharingSupport.php vendored
View File

@ -167,7 +167,7 @@ namespace Sabre\CalDAV\Backend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface SharingSupport extends NotificationSupport {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Calendar.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Calendar implements ICalendar, DAV\IProperties, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/CalendarObject.php vendored
View File

@ -7,7 +7,7 @@ namespace Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class CalendarObject extends \Sabre\DAV\File implements ICalendarObject, \Sabre\DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/CalendarQueryParser.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\VObject;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class CalendarQueryParser {

2
vendor/sabre/dav/lib/Sabre/CalDAV/CalendarQueryValidator.php vendored
View File

@ -16,7 +16,7 @@ use DateTime;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class CalendarQueryValidator {

2
vendor/sabre/dav/lib/Sabre/CalDAV/CalendarRootNode.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAVACL\PrincipalBackend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class CalendarRootNode extends \Sabre\DAVACL\AbstractPrincipalCollection {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Exception/InvalidComponentType.php vendored
View File

@ -10,7 +10,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class InvalidComponentType extends DAV\Exception\Forbidden {

2
vendor/sabre/dav/lib/Sabre/CalDAV/ICSExportPlugin.php vendored
View File

@ -14,7 +14,7 @@ use Sabre\VObject;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class ICSExportPlugin extends DAV\ServerPlugin {

2
vendor/sabre/dav/lib/Sabre/CalDAV/ICalendar.php vendored
View File

@ -10,7 +10,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface ICalendar extends DAV\ICollection {

2
vendor/sabre/dav/lib/Sabre/CalDAV/ICalendarObject.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface ICalendarObject extends DAV\IFile {

2
vendor/sabre/dav/lib/Sabre/CalDAV/IShareableCalendar.php vendored
View File

@ -7,7 +7,7 @@ namespace Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IShareableCalendar extends ICalendar {

2
vendor/sabre/dav/lib/Sabre/CalDAV/ISharedCalendar.php vendored
View File

@ -7,7 +7,7 @@ namespace Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface ISharedCalendar extends ICalendar {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Collection.php vendored
View File

@ -18,7 +18,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Collection extends DAV\Collection implements ICollection, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/ICollection.php vendored
View File

@ -16,7 +16,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface ICollection extends DAV\ICollection {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/INode.php vendored
View File

@ -14,7 +14,7 @@ namespace Sabre\CalDAV\Notifications;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface INode {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/INotificationType.php vendored
View File

@ -8,7 +8,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface INotificationType extends DAV\PropertyInterface {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Node.php vendored
View File

@ -15,7 +15,7 @@ use Sabre\DAVACL;
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Node extends DAV\File implements INode, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/Invite.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Invite extends DAV\Property implements CalDAV\Notifications\INotificationType {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/InviteReply.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class InviteReply extends DAV\Property implements CalDAV\Notifications\INotificationType {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Notifications/Notification/SystemStatus.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SystemStatus extends DAV\Property implements CalDAV\Notifications\INotificationType {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Plugin.php vendored
View File

@ -14,7 +14,7 @@ use Sabre\VObject;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Plugin extends DAV\ServerPlugin {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/Collection.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Collection extends DAVACL\AbstractPrincipalCollection {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/IProxyRead.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IProxyRead extends DAVACL\IPrincipal {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/IProxyWrite.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IProxyWrite extends DAVACL\IPrincipal {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/ProxyRead.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class ProxyRead implements IProxyRead {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/ProxyWrite.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class ProxyWrite implements IProxyWrite {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Principal/User.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class User extends DAVACL\Principal implements DAV\ICollection {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/AllowedSharingModes.php vendored
View File

@ -18,7 +18,7 @@ use Sabre\DAV;
* @see https://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Extensions/caldav-sharing-02.txt
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class AllowedSharingModes extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/Invite.php vendored
View File

@ -16,7 +16,7 @@ use Sabre\CalDAV;
* @see https://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Extensions/caldav-sharing-02.txt
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Invite extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/ScheduleCalendarTransp.php vendored
View File

@ -17,7 +17,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class ScheduleCalendarTransp extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCalendarComponentSet.php vendored
View File

@ -14,7 +14,7 @@ use Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SupportedCalendarComponentSet extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCalendarData.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\CalDAV\Plugin;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SupportedCalendarData extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Property/SupportedCollationSet.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SupportedCollationSet extends DAV\Property {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/IMip.php vendored
View File

@ -17,7 +17,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class IMip {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/IOutbox.php vendored
View File

@ -8,7 +8,7 @@ namespace Sabre\CalDAV\Schedule;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IOutbox extends \Sabre\DAV\ICollection, \Sabre\DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Schedule/Outbox.php vendored
View File

@ -14,7 +14,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Outbox extends DAV\Collection implements IOutbox {

2
vendor/sabre/dav/lib/Sabre/CalDAV/ShareableCalendar.php vendored
View File

@ -8,7 +8,7 @@ namespace Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class ShareableCalendar extends Calendar implements IShareableCalendar {

2
vendor/sabre/dav/lib/Sabre/CalDAV/SharedCalendar.php vendored
View File

@ -9,7 +9,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SharedCalendar extends Calendar implements ISharedCalendar {

2
vendor/sabre/dav/lib/Sabre/CalDAV/SharingPlugin.php vendored
View File

@ -18,7 +18,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SharingPlugin extends DAV\ServerPlugin {

2
vendor/sabre/dav/lib/Sabre/CalDAV/UserCalendars.php vendored
View File

@ -10,7 +10,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class UserCalendars implements DAV\IExtendedCollection, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CalDAV/Version.php vendored
View File

@ -7,7 +7,7 @@ namespace Sabre\CalDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Version {

2
vendor/sabre/dav/lib/Sabre/CardDAV/AddressBook.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class AddressBook extends DAV\Collection implements IAddressBook, DAV\IProperties, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CardDAV/AddressBookQueryParser.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class AddressBookQueryParser {

2
vendor/sabre/dav/lib/Sabre/CardDAV/AddressBookRoot.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\DAVACL;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class AddressBookRoot extends DAVACL\AbstractPrincipalCollection {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Backend/AbstractBackend.php vendored
View File

@ -11,7 +11,7 @@ namespace Sabre\CardDAV\Backend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
abstract class AbstractBackend implements BackendInterface {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Backend/BackendInterface.php vendored
View File

@ -13,7 +13,7 @@ namespace Sabre\CardDAV\Backend;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface BackendInterface {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Backend/PDO.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class PDO extends AbstractBackend {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Card.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Card extends DAV\File implements ICard, DAVACL\IACL {

2
vendor/sabre/dav/lib/Sabre/CardDAV/IAddressBook.php vendored
View File

@ -11,7 +11,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IAddressBook extends DAV\ICollection {

2
vendor/sabre/dav/lib/Sabre/CardDAV/ICard.php vendored
View File

@ -12,7 +12,7 @@ use Sabre\DAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface ICard extends DAV\IFile {

2
vendor/sabre/dav/lib/Sabre/CardDAV/IDirectory.php vendored
View File

@ -13,7 +13,7 @@ namespace Sabre\CardDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
interface IDirectory extends IAddressBook {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Plugin.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\VObject;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class Plugin extends DAV\ServerPlugin {

2
vendor/sabre/dav/lib/Sabre/CardDAV/Property/SupportedAddressData.php vendored
View File

@ -13,7 +13,7 @@ use Sabre\CardDAV;
*
* @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
* @author Evert Pot (http://evertpot.com/)
* @license http://code.google.com/p/sabredav/wiki/License Modified BSD License
* @license http://sabre.io/license/ Modified BSD License
*/
class SupportedAddressData extends DAV\Property {

Some files were not shown because too many files have changed in this diff Show More