[要約] RFC 5995は、WebDAVコレクションにメンバーを追加するためにPOSTを使用する方法について説明しています。このRFCの目的は、WebDAVプロトコルを使用してコレクションにメンバーを効果的に追加するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 5995 greenbytes
Category: Standards Track September 2010
ISSN: 2070-1721
Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections
投稿を使用してメンバーをWeb分散オーサリングおよびバージョン（webdav）コレクションに追加する
Abstract
概要
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".
Web分散オーサリングおよびバージョン化（WebDAV）のハイパーテキスト転送プロトコル（HTTP）拡張は、コレクションに適用されたときに「Post」メソッドの動作を定義しません。"役職"。
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.
これにより、多くのWebDAVサーバーがコレクションの投稿をまったく実装しない状況につながりましたが、新しいメンバーをコレクションに追加する目的で使用されるのに適しています。実際、Atom Publishing Protocol（Atompub）は、その目的のために正確にPostを使用しています。一方、WebDAV（CalDAV）へのカレンダー拡張機能などのWebDAVベースのプロトコルは、頻繁にクライアントに一意のURLを選択する必要がありますが、サーバーはそのタスクを簡単に実行できます。
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.
この仕様は、前述の「コレクションメンバーを追加する」セマンティクスで、サーバーがポストリクエストのサポートを宣伝できる発見メカニズムを定義します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
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/rfc5995.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5995で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Protocol Extension ..............................................4
3.1. Definition of "Add-Member" URI .............................5
3.2. Discovery ..................................................6
3.2.1. DAV:add-member Property (Protected) .................6
3.2.2. Example .............................................6
3.3. Relation to AtomPub's "Slug" Header Field ..................7
3.4. Example Operation ..........................................7
4. Additional Semantics for Existing Methods .......................8
4.1. Additional Preconditions ...................................8
4.2. Example: Failed PUT Request ................................8
5. Relationship to WebDAV Access Control Protocol ..................9
6. Internationalization Considerations .............................9
7. Security Considerations .........................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Index .............................................................11
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) ([RFC4918], Section 9.5) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST":
Web分散オーサリングおよびバージョン化（webdav）（[RFC4918]、セクション9.5）のハイパーテキスト転送プロトコル（HTTP）拡張は、ベース仕様（HTTP）が残すように、コレクションに適用されるときの「ポスト」メソッドの動作を定義しません。「ポスト」のセマンティクスのための多くの自由を実装する
9.5 POST for Collections
9.5 コレクションの投稿
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
定義上、POSTによって実行される実際の関数はサーバーによって決定され、多くの場合特定のリソースに依存するため、コレクションに適用された場合のPOSTの動作は、大部分が定義されていないため、有意義に変更できません。したがって、ポストのセマンティクスは、コレクションに適用されると修正されていません。
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose ([RFC5023], Section 9.2):
これにより、多くのWebDAVサーバーがコレクションの投稿をまったく実装しない状況につながりましたが、新しいメンバーをコレクションに追加する目的で使用されるのに適しています。実際、Atom Publishing Protocol（Atompub）は、その目的のために正確に投稿を使用しています（[RFC5023]、セクション9.2）：
9.2 Creating Resources with POST
9.2 投稿でリソースを作成します
To add members to a Collection, clients send POST requests to the URI of the Collection.
メンバーをコレクションに追加するために、クライアントはコレクションのURIに投稿リクエストを送信します。
On the other hand, WebDAV-based protocols, such as Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task ([RFC4791], Section 5.3.2):
一方、WebDAVベースのプロトコルは、WebDAV（CalDAV）への拡張機能をカレンダーするなど、クライアントに一意のURLを選択することを頻繁に要求しますが、サーバーはそのタスクを簡単に実行できます（[RFC4791]、セクション5.3.2）：
5.3.2 Creating Calendar Object Resources
5.3.2 カレンダーオブジェクトリソースの作成
...
...
When servers create new resources, it's not hard for the server to choose an unmapped URI. It's slightly tougher for clients, because a client might not want to examine all resources in the collection and might not want to lock the entire collection to ensure that a new resource isn't created with a name collision. (...)
サーバーが新しいリソースを作成するとき、サーバーがマッピングされていないURIを選択するのは難しくありません。クライアントは、クライアントがコレクション内のすべてのリソースを調査したくない場合があり、コレクション全体をロックして、新しいリソースが名前の衝突で作成されないようにしたくないためです。（...）
Letting the server choose the member URI not only is a simplification for certain types of clients, but can also reduce the complexity of the server (in that it doesn't need to persist an additional client-supplied identifier where it already has an internal one like a Universally Unique Identifier (UUID) or a primary key).
サーバーにメンバーを選択させるURIは、特定のタイプのクライアントの単純化であるだけでなく、サーバーの複雑さを減らすこともできます（追加のクライアントがサプチャした識別子を既に持っている場合は、追加のクライアントがサプチャした識別子を維持する必要はありません。普遍的に一意の識別子（UUID）または主キーのように）。
Note: The vCard Extensions to WebDAV (CardDAV) ([CARDDAV]) suffer from the same issue, and may be able to take advantage of this specification.
注：webdav（carddav）（[carddav]）へのvcard拡張は同じ問題に苦しんでおり、この仕様を活用できる場合があります。
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.
この仕様は、前述の「コレクションメンバーを追加する」セマンティクスで、サーバーがポストリクエストのサポートを宣伝できる発見メカニズムを定義します。
This specification deliberately only addresses the use case of creating new non-collection resources. It was not a goal for this specification to supply the same functionality for creating collection resources (MKCOL) or for other operations that require the client to specify a new URL (LOCK, MOVE, or COPY).
この仕様は、意図的に新しい非収集リソースを作成するユースケースのみに対処します。この仕様が、収集リソース（MKCOL）を作成するための同じ機能を提供すること、またはクライアントが新しいURL（ロック、移動、またはコピー）を指定する必要がある他の操作のための目標ではありませんでした。
Note: The author previously proposed a new HTTP method for exactly this purpose ([ADDMEMBER]), but quite a few reviewers pointed out that this would duplicate the original semantics of POST. Thus, this proposal, which avoids adding a new HTTP method, is made.
注：著者は以前にこの目的のために新しいHTTPメソッドを提案していました（[ADDMEMBER]）が、かなりの数のレビュアーは、これがポストの元のセマンティクスを複製すると指摘しました。したがって、新しいHTTPメソッドの追加を避けるこの提案が作成されます。
The terminology used here follows that in the WebDAV specification ([RFC4918]).
ここで使用される用語は、WebDAV仕様（[RFC4918]）でそれに続きます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses XML DTD fragments ([XML]) as a purely notational convention. In particular:
このドキュメントでは、XML DTDフラグメント（[XML]）を純粋に表記規則として使用しています。特に：
o Element ordering is irrelevant.
o 要素の順序は無関係です。
o Extension elements/attributes (elements/attributes not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise.
o 拡張要素/属性（有効な子要素としてまだ定義されていない要素/属性）は、明示的に明示的に記載されている場合を除き、どこにでも追加される場合があります。
Note: This specification defines new properties and precondition names in the "DAV:" namespace, which the WebDAV specification reserves for use by the IETF ([RFC4918], Section 21.1). However, there was rough consensus in the WebDAV community that the specification is of general applicability to other WebDAV-related standards efforts, and thus deserves inclusion into the base namespace.
注：この仕様では、「DAV：」という名前の新しいプロパティと前処理名を定義します。WebDAV仕様は、IETF（[RFC4918]、セクション21.1）で使用するために予約しています。ただし、WebDAVコミュニティでは、この仕様は他のWebDAV関連の標準努力に一般的な適用可能性であるため、基本名に含めるに値するという大まかなコンセンサスがありました。
Due to the reasons stated in Section 1, clients cannot rely on a specific server behavior when POST is applied to a collection. This problem is addressed by this specification by allowing servers to advertise a URI that has the desired "add member" semantics.
セクション1に記載されている理由により、クライアントはポストがコレクションに適用された場合、特定のサーバーの動作に依存することはできません。この問題は、サーバーが目的の「メンバーを追加する」セマンティクスを持つURIを宣伝できるようにすることにより、この仕様によって対処されます。
Servers that already use POST for a different purpose can just expose a separate URI. Other servers can just advertise the collection's own URI, thus avoiding minting another URI for a limited purpose.
すでに別の目的で投稿を使用しているサーバーは、別のURIを公開するだけです。他のサーバーは、コレクション独自のURIを宣伝するだけで、限られた目的で別のURIをミントすることを避けることができます。
The "Add-Member" URI of a WebDAV collection is a URI that will accept HTTP POST requests, and will interpret these as requests to store the enclosed entity as a new internal member of the collection (see Section 3 of [RFC4918] for the definition of "internal member"). It MUST identify a resource on the same server as the WebDAV collection (the host and port components ([RFC2616], Section 3.2.2) of the URIs must match).
WebDavコレクションの「追加メンバー」URIは、HTTPの投稿リクエストを受け入れるURIであり、これらをコレクションの新しい内部メンバーとして保存するリクエストとしてこれらを解釈します（[RFC4918]のセクション3を参照してください。「内部メンバー」の定義）。URIのWebDAVコレクション（ホストおよびポートコンポーネント（[RFC2616]、セクション3.2.2）と同じサーバー上のリソースを識別する必要があります。
If there are preconditions related to creating a resource in the collection using a PUT request, then those same preconditions apply to the new POST request behavior, and the same HTTP response body will be returned on failure.
Putリクエストを使用してコレクションにリソースの作成に関連する前提条件がある場合、これらの同じ前提条件が新しいPOSTリクエスト動作に適用され、同じHTTP応答ボディが障害時に返されます。
The URI of the newly created resource is returned in the HTTP Location response header field ([RFC2616], Section 14.30).
新しく作成されたリソースのURIは、HTTP位置応答ヘッダーフィールド（[RFC2616]、セクション14.30）に返されます。
Note: The fact that a server advertises an "Add-Member" URI does not imply any special semantics of the collection itself. For instance, member URIs assigned by the server are not necessarily unique over time (a member URI may be assigned again to a new resource when it previously was removed).
注：サーバーが「追加メンバー」を宣伝するという事実は、コレクション自体の特別なセマンティクスを意味するものではありません。たとえば、サーバーによって割り当てられたメンバーのurisは、必ずしも時間の経過とともに一意ではありません（メンバーURIは、以前に削除されたときに再び新しいリソースに割り当てることができます）。
Note: The "Add-Member" URI can be identical to the collection's URI (in which case the server just advertises the fact that POST to the WebDAV collection's URI is supported as defined within this specification). But it can also be different from it, in which case it doesn't need to have any relation to the collection's URI.
注：「ADDメンバー」URIは、コレクションのURIと同じである可能性があります（この場合、サーバーは、この仕様内で定義されているようにWebDavコレクションのURIへの投稿がサポートされているという事実を宣伝しています）。しかし、それはそれとは異なる場合があります。その場合、コレクションのURIとの関係を持つ必要はありません。
Given a collection URI of
のコレクションURIが与えられました
/docs/collection/
/docs/collection/
any of the URIs below might occur as "Add-Member" URIs:
以下のurisは、「addmember」urisとして発生する可能性があります。
/docs/collection/
/docs/collection/;post
/docs/collection;post/
/docs/collection/&post
/post-service?path=/collection/
The remainder of the document uses the same format just for
reasons of consistency; any other HTTP URI on the same server
would do as well.
DAV:add-member is a protected property (see [RFC4918], Section 15) defined on WebDAV collections, and contains the "Add-Member" URI for that collection (embedded inside a DAV:href element).
DAV：ADDメンバーは、WebDAVコレクションで定義されている保護されたプロパティ（[RFC4918]、セクション15を参照）であり、そのコレクションに「ADDメンバー」URIが含まれています（DAV：HREF要素に埋め込まれています）。
<!ELEMENT add-member (href)>
<!-- href: defined in [RFC4918], Section 14.7 -->
A PROPFIND/allprop request SHOULD NOT return this property (see [RFC4918], Section 9.1). Servers MUST implement the DAV:supported-live-property-set property defined in Section 3.1.4 of [RFC3253], and report the property DAV:add-member as a supported live property.
Propfind/AllPropリクエストは、このプロパティを返さないでください（[RFC4918]、セクション9.1を参照）。サーバーは、[RFC3253]のセクション3.1.4で定義されているDAV：サポートLive-Property-Setプロパティを実装し、サポートされているライブプロパティとしてプロパティDAV：追加メンバーを報告する必要があります。
>>Request
>>リクエスト
PROPFIND /collection/ HTTP/1.1
Host: example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 118
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<prop>
<add-member/>
</prop>
</propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 340
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/collection/</href>
<propstat>
<prop>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this case, the server has minted a separate URI for the purpose of adding new content.
この場合、サーバーは、新しいコンテンツを追加する目的で、別のURIを鋳造しました。
In the AtomPub protocol, clients can use the entity header field "Slug" to suggest parts of the URI to be created (see [RFC5023], Section 9.7). Note that servers are free to ignore this suggestion, or to use whatever algorithm makes sense to generate the new URI.
ATOMPUBプロトコルでは、クライアントはエンティティヘッダーフィールド「スラグ」を使用して、URIの一部を作成することを提案できます（[RFC5023]、セクション9.7を参照）。サーバーはこの提案を自由に無視したり、新しいURIを生成するために理にかなっているすべてのアルゴリズムを使用することができます。
The same applies to the extension defined here: clients can use the "Slug" header field, as by definition it is a generic HTTP header field. Servers should process it exactly in the way defined by AtomPub.
同じことがここで定義されている拡張機能にも当てはまります。クライアントは「スラグ」ヘッダーフィールドを使用できます。定義上、一般的なHTTPヘッダーフィールドであるためです。サーバーは、Atompubによって定義された方法で正確に処理する必要があります。
>>Request
>>リクエスト
POST /collection;add-member/ HTTP/1.1
Host: example.com
Content-Type: text/plain
Slug: Sample Title
Content-Length: 12
Sample text.
サンプルテキスト。
>>Response
>>応答
HTTP/1.1 201 Created Location: http://example.com/collection/sample%20title
http/1.1 201の作成場所：http：//example.com/collection/sample%20title
One important use case for this specification is collections that act as WebDAV collections for the purpose of read access (PROPFIND Depth 1/Infinity), but which only support internal member URIs assigned by the server. These collections will not allow a client to create a new member using methods like PUT, MKCOL, LOCK, COPY, or MOVE. Therefore, this specification defines a new precondition name ([RFC4918], Section 16) that can be used to provide the client with additional information regarding exactly why the request failed.
この仕様の重要なユースケースの1つは、読み取りアクセス（Propfind Depth 1/Infinity）を目的としてWebDavコレクションとして機能するコレクションですが、サーバーによって割り当てられた内部メンバーのURIのみをサポートします。これらのコレクションでは、クライアントがPut、Mkcol、ロック、コピー、移動などの方法を使用して新しいメンバーを作成することはできません。したがって、この仕様は、リクエストが失敗した理由に関する正確な情報をクライアントに提供するために使用できる新しい前提条件名（[RFC4918]、セクション16）を定義します。
Note: Although the precondition defined below can be used for methods other than PUT, the "Add-Member" mechanism defined by this specification deliberately is restricted to PUT.
注：以下に定義されている前提条件は、PUT以外の方法で使用できますが、この仕様で定義された「追加メンバー」メカニズムは、意図的にPUTに制限されています。
(DAV:allow-client-defined-URI): the server allows clients to specify the last path segment for newly created resources.
（DAV：Allow-Client-Defined-URI）：サーバーにより、クライアントは新しく作成されたリソースの最後のパスセグメントを指定できます。
The precondition element MAY contain an add-member-uri XML element specifying the "Add-Member" URI associated with the collection, on which the creation of a new child resource was attempted:
前処理要素には、コレクションに関連付けられた「追加メンバー」URIを指定するADDメンバー-URI XML要素が含まれている場合があります。
<!ELEMENT allow-client-defined-uri (add-member?)>
In this example, the client tries to use PUT to create a new internal member of /collection/.
この例では、クライアントはPUTを使用して /Collection /の新しい内部メンバーを作成しようとします。
>>Request
>>リクエスト
PUT /collection/new.txt HTTP/1.1
Host: example.com
Content-Type: text/plain
Content-Length: 12
Sample text.
サンプルテキスト。
>>Response
>>応答
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, TRACE, PROPFIND, COPY, MOVE
Content-Type: application/xml; charset=UTF-8
Content-Length: 172
<error xmlns="DAV:">
<allow-client-defined-uri>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</allow-client-defined-uri>
</error>
The request fails with a 405 (Method Not Allowed) status, but also provides the reason, and a pointer to the "Add-Member" URI in the response body.
リクエストは405（メソッドが許可されていない）ステータスで失敗しますが、理由を提供し、応答本体の「追加メンバー」URIへのポインターも提供します。
The WebDAV Access Control Protocol specification requires the DAV: bind privilege to be granted on a collection for the client to be able to add new collection members ([RFC3744], Section 3.9). Consistent with that, a server MUST reject a POST request to the Add-Member URI of a collection, unless the principal executing the request is granted DAV:bind privilege on the associated WebDAV collection resource.
WebDAV Access Controlプロトコルの仕様には、Client：Bind Privilegeが新しいコレクションメンバー（[RFC3744]、セクション3.9）を追加できるように、クライアントのコレクションに付与される必要があります。それと一致して、サーバーは、リクエストを実行する元本がDAV：Bind Privilegeに関連するWebDavコレクションリソースを付与されない限り、コレクションのADDメンバーURIへのPOSTリクエストを拒否する必要があります。
This document does not introduce any new internationalization considerations beyond those discussed in Section 19 of [RFC4918].
このドキュメントでは、[RFC4918]のセクション19で説明したものを超えた新しい国際化に関する考慮事項は導入されていません。
Security considerations applicable to HTTP [RFC2616], WebDAV [RFC4918], and XML [XML] apply for this specification as well, namely, Section 20 of [RFC4918] and Section 7 of [RFC3470].
HTTP [RFC2616]、WebDAV [RFC4918]、およびXML [XML]に適用されるセキュリティ上の考慮事項は、この仕様、つまり[RFC4918]のセクション20および[RFC3470]のセクション7にも適用されます。
Furthermore, servers should be aware that deriving the member path from the data being stored in the resource could potentially expose confidential information. This could even be the case when only a hash code of the content is used.
さらに、サーバーは、リソースに保存されているデータからメンバーパスを導き出すと、機密情報を露出させる可能性があることに注意する必要があります。これは、コンテンツのハッシュコードのみが使用される場合でもそうかもしれません。
In addition, on servers that do not support this specification, a malevolent user could set the DAV:add-member URI as a custom property, tricking other users to post content to an entirely different URI. Clients can protect themselves against this scenario by
さらに、この仕様をサポートしていないサーバーでは、悪意のあるユーザーがDAV：Add-Member URIをカスタムプロパティとして設定し、他のユーザーをトリックしてコンテンツをまったく異なるURIに投稿します。クライアントは、このシナリオから身を守ることができます
o not following DAV:add-member URIs to different servers, and/or
o DAVをフォローしていません：異なるサーバーにメンバーを追加します。
o verifying that the DAV:add-member property is indeed a live property (this can be achieved by testing the DAV:supported-live-property-set property, or by checking whether DAV:add-member is returned upon PROPFIND/allprop).
o DAV：ADDメンバーのプロパティが実際にライブプロパティであることを確認します（これは、DAV：Support-Live-Property-Setプロパティをテストするか、DAV：AddメンバーがPropfind/AllPropで返されるかどうかを確認することで実現できます）。
This document has benefited from thoughtful discussion by Cyrus Daboo and Bernard Desruisseaux.
この文書は、Cyrus DabooとBernard Desruisseauxによる思慮深い議論の恩恵を受けています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、Ellison、T.、Kaler、C。、およびJ. Whitehead、「WebDavへのバージョン拡張機能（Web分散オーサリングとバージョン）」、RFC 3253、2002年3月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744] Clemm、G.、Reschke、J.、Sedlar、E。、およびJ. Whitehead、「Web分散オーサリングおよびバージョン（WebDAV）アクセス制御プロトコル」、RFC 3744、2004年5月。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L.、ed。、「Web分散オーサリングとバージョン（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第5版）」、W3C REC-XML-20081126、2008年11月、<http://www.w3.org/tr/2008/rec-xml-20081126/>。
[ADDMEMBER] Reschke, J., "The HTTP ADDMEMBER Method", Work in Progress, February 2005.
[AddMember] Reschke、J。、「HTTP AddMemberメソッド」、2005年2月に進行中の作業。
[CARDDAV] Daboo, C., "vCard Extensions to WebDAV (CardDAV)", Work in Progress, November 2009.
[carddav] Daboo、C。、「vcard extensions to webdav（carddav）」、2009年11月、進行中の作業。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[RFC4791] Daboo、C.、Desruisseaux、B。、およびL. Dusseault、「webdav（caldav）への拡張カレンダー」、RFC 4791、2007年3月。
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023] Gregorio、J.、ed。およびB. de Hora、ed。、「The Atom Publishing Protocol」、RFC 5023、2007年10月。
Index
索引
A Add-Member URI 5
追加メンバーのURI 5
C Condition Names DAV:allow-client-defined-URI (pre) 8 COPY method Additional Preconditions 8
c条件名DAV：Allod-client-defined-uri（pre）8コピー方法追加前処理8
D DAV:allow-client-defined-URI 8
D DAV：Allod-client-defined-uri 8
L LOCK method Additional Preconditions 8
Lロック方法追加の前提条件8
M MKCOL method Additional Preconditions 8 MOVE method Additional Preconditions 8
m mkcolメソッド追加の前提条件8移動方法追加の前提条件8
P PUT method Additional Preconditions 8
P Put Method追加の前提条件8
Author's Address
著者の連絡先
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke Greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/