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
POSTを使用すると、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）の拡張機能は、の意味の自由の実装の多くを残し基本仕様として（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.
サーバーが新たに割り当てられたURLのコントロールに残ってコレクションに新しいメンバーを追加する目的のために使用されるのに適しているが、多くのWebDAVサーバは、全くのコレクションのためにPOSTを実装していない状況につながっています。実際には、Atom出版プロトコル（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.
この仕様では、サーバは、前述の「コレクション・メンバーを追加する」の意味を持つPOSTリクエストをサポートすることを通知することができ、それを通して検出メカニズムを定義します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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":
ハイパーテキスト転送プロトコル（HTTP）基本仕様（HTTP）の葉のように、コレクションに適用されたときにWeb分散オーサリングとバージョン管理（WebDAV）（[RFC4918]、セクション9.5）のための拡張機能は、「POST」メソッドの振る舞いを定義していません「POST」の意味の自由の実装ロット：
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の挙動が有意変更することができません。コレクションに適用されたときにこのように、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):
サーバーが新たに割り当てられたURLのコントロールに残ってコレクションに新しいメンバーを追加する目的のために使用されるのに適しているが、多くのWebDAVサーバは、全くのコレクションのためにPOSTを実装していない状況につながっています。実際には、Atom出版プロトコル（AtomPubのは）まさにその目的（[RFC5023]、セクション9.2）のためにPOSTを使用しています。
To add members to a Collection, clients send POST requests to the URI of the Collection.
コレクションにメンバーを追加するには、クライアントはコレクションのURIにPOSTリクエストを送信します。
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):
サーバーは簡単にそのタスク（[RFC4791]、セクション5.3.2）を行う可能性があるが一方で、このようなWebDAVのにカレンダーの拡張機能として、WebDAVのベースのプロトコル、（CalDAVに）、しばしば、ユニークなURLを選択するためにクライアントが必要です。
...
。。。
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.
この仕様では、サーバは、前述の「コレクション・メンバーを追加する」の意味を持つPOSTリクエストをサポートすることを通知することができ、それを通して検出メカニズムを定義します。
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（LOCK、MOVE、またはCOPY）を指定するには、クライアントが必要な他の操作のために同じ機能を提供するために、この仕様の目標ではありませんでした。
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]）を提案したが、かなりの数のレビューアは、これはPOSTの本来の意味を複製するだろうと指摘しました。このように、新しい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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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：」名前空間、IETF（[RFC4918]、セクション21.1）で使用するためのWebDAV仕様埋蔵。しかし、仕様が他の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.
POSTがコレクションに適用されたときに第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.
すでに別の目的のためにPOSTを使用するサーバーは、ちょうど別の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がために（[RFC4918]のセクション3を参照してくださいHTTPのPOST要求を受け入れる、とコレクションの新しい内部メンバーとして同封の実体を格納するための要求としてこれらを解釈することURIであります「内部部材」の定義）。 WebDAVコレクション（URIのホストとポートコンポーネント（[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).
注：サーバーは、「アドオンメンバー」URIは、コレクション自体の特別な意味を意味するものではありませんアドバタイズという事実を。例えば、サーバによって割り当てられたメンバーURIは経時必ずしも一意ではない（それが以前に削除されたときに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.
注意：URIは、コレクションのURIと同一であることができる「 - メンバーの追加」（この場合、サーバは、ちょうどこの仕様内で定義されているようPOSTがWebDAVコレクションのURIに支持されているという事実をアドバタイズ）。しかし、それはまた、その場合には、コレクションのURIに何らかの関係を持っている必要はありません、それは異なる可能性があります。
Given a collection URI of
コレクションのURIを考えます
/docs/collection/
/ドキュメント/コレクション/
any of the URIs below might occur as "Add-Member" URIs:
以下のURIのいずれかが「アドオンメンバー」のURIとして発生する可能性があります：
/docs/collection/ /docs/collection/;post /docs/collection;post/ /docs/collection/&post /post-service?path=/collection/
/ドキュメント/コレクション/ /ドキュメント/コレクション/;ポスト/ DOCの/コレクション;？ポスドク/コレクション/＆ポスト/ポスト・サービスパス= /コレクション/
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.
文書の残りは単に一貫性の理由で同じフォーマットを使用します。同じサーバー上の他のHTTP URIも同様に行うだろう。
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：追加メンバーは、WebDAVコレクションに定義されている（第15条、[RFC4918]を参照）保護特性であり、かつ（DAV内部に埋め込ま：hrefの要素）は、そのコレクションの「アドオンのメンバーを」URIが含まれています。
<!ELEMENT add-member (href)> <!-- href: defined in [RFC4918], Section 14.7 -->
<！ELEMENTは追加メンバー（HREF）> < - HREF：！[RFC4918]で定義され、セクション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を報告：サーバーはDAVを実装しなければならない追加メンバーをサポートするライブプロパティとして。
>>Request
>>リクエスト
PROPFIND /collection/ HTTP/1.1 Host: example.com Content-Type: application/xml; charset="utf-8" Content-Length: 118
PROPFIND /コレクション/ HTTP / 1.1ホスト：example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：118
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <prop> <add-member/> </prop> </propfind>
<？xml version = "1.0" エンコーディング= "UTF-8"？> <PROPFINDのxmlns = "DAV："> <プロパ> <アドイン部材/> </小道具> </ PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: 340
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <multistatusのxmlns = "DAV："> <応答> <HREF> /コレクション/ </ HREF> <propstat> <小道具>の<add-メンバー> <HREF> /コレクション;アドオン部材/ </ HREF> </アドオン部材> </小道具> <状態> HTTP / 1.1 200 OK </ステータス> </ propstat> </レスポンス> </ 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のプロトコルでは、クライアントは、（[RFC5023]、セクション9.7を参照）を作成するURIの部分を提案するエンティティヘッダフィールド「スラグ」を使用することができます。サーバはこの提案を無視する、または新しい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
POST /コレクション、追加メンバー/ HTTP / 1.1ホスト：example.comのContent-Type：text / plainのスラッグ：サンプルタイトルの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深度1 /インフィニティ）の目的のためのWebDAVコレクションとして機能しますが、これだけサーバによって割り当てられた内部メンバーURIをサポートするコレクションです。これらのコレクションは、クライアントがPUT、MKCOL、LOCK、COPY、またはMOVEのようなメソッドを使用して新しいメンバーを作成することはできません。したがって、本明細書は、要求が失敗した理由を正確に関する追加情報をクライアントに提供するために使用することができる新たな前提条件名（[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以外の方法に使用することができますが、この仕様で定義された「アドオンメンバー」メカニズムが故意に置くために制限されています。
(DAV:allow-client-defined-URI): the server allows clients to specify the last path segment for newly created resources.
（DAV：許可 - クライアント定義-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を指定するアドオンメンバー-URI XML要素が含まれる場合があります。
<!ELEMENT allow-client-defined-uri (add-member?)>
<！ELEMENT許可-クライアントに定義されたURI（アドオンメンバー？）>
In this example, the client tries to use PUT to create a new internal member of /collection/.
この例では、クライアントは/収集/の新しい内部メンバーを作成するために、PUTを使用しようとします。
>>Request
>>リクエスト
PUT /collection/new.txt HTTP/1.1 Host: example.com Content-Type: text/plain Content-Length: 12
PUT /collection/new.txt HTTP / 1.1ホスト：example.comのContent-Type：text / plainのコンテンツの長さ：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
GET、HEAD、TRACE、PROPFIND、COPY、MOVE用のContent-Type：許可許可されていないHTTP / 1.1 405メソッドアプリケーション/ XMLを。文字セット= 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>
<エラーのxmlns = "DAV："> <許可-クライアント定義-URI>の<add-メンバーを> <HREF> /コレクション;アドオンメンバー/ </ HREF> </アドオンメンバー> </許可するクライアントは、定義されました-uri> </エラー>
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のアクセス制御プロトコルの仕様では、DAVが必要ですBIND特権は、新しいコレクションのメンバー（[RFC3744]、セクション3.9）を追加できるように、クライアントのために、コレクションに付与します。関連するWebDAVコレクションのリソースにバインド特権：要求を実行するプリンシパルがDAVを付与されない限り、それと一致して、サーバは、コレクションの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]及び[RFC3470]のセクション7のセクション20。
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を設定できます。完全に異なるURIにコンテンツを投稿するために、他のユーザーをだまし、カスタムプロパティとしてURI-メンバーを追加します。クライアントは、このシナリオによるから身を守ることができます
o not following DAV:add-member URIs to different servers, and/or
O以下でないDAV：追加メンバーのURIを別のサーバーに、および/または
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：アドイン部材性がライブプロパティ確かである（これはDAV試験することによって達成することができる：サポートされているライブ・プロパティ・セットプロパティ、またはDAVか否かをチェックすることにより：アドイン部材はPROPFIND / allprop時に戻されます） 。
This document has benefited from thoughtful discussion by Cyrus Daboo and Bernard Desruisseaux.
この文書では、サイラスDabooとバーナードDesruisseauxで思慮深い議論の恩恵を受けています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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.、エリソン、T.、Kaler、C.、およびJ.ホワイトヘッド "の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.ホワイトヘッド、 "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.、エド。、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能"。
[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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、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.、 "WebDAVのにvCardの拡張機能（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]ホレンベック、S.、ローズ、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]グレゴリオ、J.、エド。そしてB.デ・ホラ、エド。、 "Atom出版プロトコル"、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：許可 - クライアント定義-URI（前）8 COPYメソッドの追加前提条件8
D DAV:allow-client-defined-URI 8
D DAV：許可 - クライアント定義-URI 8
L LOCK method Additional Preconditions 8
L LOCKメソッドの追加前提条件8
M MKCOL method Additional Preconditions 8 MOVE method Additional Preconditions 8
M MKCOLメソッドの追加前提条件8 MOVEメソッドの追加前提条件8
P PUT method Additional Preconditions 8
P PUTメソッドの追加前提条件8
Author's Address
著者のアドレス
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
ジュリアン・F. Reschke greenbytes社Hafenweg 16ミュンスター、NW 48155ドイツ
Phone: +49 251 2807760 EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/
電話：+49 251 2807760 Eメール：julian.reschke@greenbytes.de URI：http://greenbytes.de/tech/webdav/