Internet Engineering Task Force (IETF) G. Clemm
Request for Comments: 5842 IBM
Category: Experimental J. Crawford
ISSN: 2070-1721 IBM Research
J. Reschke, Ed.
greenbytes
J. Whitehead
U.C. Santa Cruz
April 2010
Binding Extensions to
Web Distributed Authoring and Versioning (WebDAV)
Abstract
抽象
This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.
この仕様は、バインディングを定義し、同じリソースに複数のバインディングを作成するためのBINDの方法。リソースへの新しいバインディングを作成すると、少なくとも1つの新しいURIはそのリソースにマッピングされるようにします。サーバは、彼らが作成できるようにする任意のバインディングの整合性を確保するために必要とされています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5842.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5842で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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 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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Method Preconditions and Postconditions ....................6
2. Overview of Bindings ............................................7
2.1. Bindings to Collections ....................................7
2.1.1. Bind Loops ..........................................8
2.2. URI Mappings Created by a New Binding ......................8
2.3. COPY and Bindings ..........................................9
2.3.1. Example: COPY with "Depth: infinity" in
Presence of Bind Loops .............................11
2.3.2. Example: COPY Updating Multiple Bindings ...........13
2.3.3. Example: COPY with "Depth: infinity" with
Multiple Bindings to a Leaf Resource ...............14
2.4. DELETE and Bindings .......................................15
2.5. MOVE and Bindings .........................................15
2.5.1. Example: Simple MOVE ...............................16
2.5.2. Example: MOVE Request Causing a Bind Loop ..........16
2.6. PROPFIND and Bindings .....................................18
2.7. Determining Whether Two Bindings Are to the Same
Resource ..................................................18
2.8. Discovering the Bindings to a Resource ....................19
3. Properties .....................................................19
3.1. DAV:resource-id Property ..................................20
3.2. DAV:parent-set Property ...................................20
3.2.1. Example for DAV:parent-set Property ................20
4. BIND Method ....................................................21
4.1. Example: BIND .............................................24
5. UNBIND Method ..................................................24
5.1. Example: UNBIND ...........................................26
6. REBIND Method ..................................................26
6.1. Example: REBIND ...........................................28
6.2. Example: REBIND in Presence of Locks and Bind Loops .......29
7. Additional Status Codes ........................................31
7.1. 208 Already Reported ......................................31
7.1.1. Example: PROPFIND by Bind-Aware Client .............32
7.1.2. Example: PROPFIND by Non-Bind-Aware Client .........34
7.2. 508 Loop Detected .........................................34
8. Capability Discovery ...........................................34
8.1. OPTIONS Method ............................................34
8.2. 'DAV' Request Header ......................................34
9. Relationship to Locking in WebDAV ..............................35
9.1. Example: Locking and Multiple Bindings ....................36
10. Relationship to WebDAV Access Control Protocol ................37
11. Relationship to Versioning Extensions to WebDAV ...............37
12. Security Considerations .......................................40
12.1. Privacy Concerns .........................................40
12.2. Bind Loops ...............................................40
12.3. Bindings and Denial of Service ...........................40
12.4. Private Locations May Be Revealed ........................40
12.5. DAV:parent-set and Denial of Service .....................41
13. Internationalization Considerations ...........................41
14. IANA Considerations ...........................................41
15. Acknowledgements ..............................................41
16. References ....................................................41
16.1. Normative References .....................................41
16.2. Informative References ...................................42
Index .............................................................42
This specification extends the WebDAV Distributed Authoring Protocol ([RFC4918]) to enable clients to create new access paths to existing resources. This capability is useful for several reasons:
この仕様は既存のリソースへの新しいアクセス・パスを作成するには、クライアントを有効にするには、オーサリングプロトコル（[RFC4918]）分散WebDAVを拡張します。この機能は、いくつかの理由のために有用です：
URIs of WebDAV-compliant resources are hierarchical and correspond to a hierarchy of collections in resource space. The WebDAV Distributed Authoring Protocol makes it possible to organize these resources into hierarchies, placing them into groupings, known as collections, which are more easily browsed and manipulated than a single flat collection. However, hierarchies require categorization decisions that locate resources at a single location in the hierarchy, a drawback when a resource has multiple valid categories. For example, in a hierarchy of vehicle descriptions containing collections for cars and boats, a description of a combination car/boat vehicle could belong in either collection. Ideally, the description should be accessible from both. Allowing clients to create new URIs that access the existing resource lets them put that resource into multiple collections.
WebDAVの準拠リソースのURIは階層構造になっているとリソース空間内のコレクションの階層に対応しています。オーサリングプロトコル分散WebDAVは、より簡単に、単一のフラットコレクションより閲覧、操作されているコレクションとして知られているグループ、にそれらを配置し、階層にこれらのリソースを整理することが可能となります。しかし、階層は、リソースが複数の有効なカテゴリを持っている場合、階層内の単一の場所で欠点がリソースを見つけ分類の決定を必要とします。例えば、車やボートのためのコレクションを含む車両記述の階層に、組み合わせの車/ボート車両の説明は、コレクションのいずれかに属している可能性があります。理想的には、説明は両方からアクセスできる必要があります。クライアントは、既存のリソースにアクセスする新しいURIを作成できるようにすると、それらが複数のコレクションにそのリソースを置くことができます。
Hierarchies also make resource sharing more difficult, since resources that have utility across many collections are still forced into a single collection. For example, the mathematics department at one university might create a collection of information on fractals that contains bindings to some local resources but also provides access to some resources at other universities. For many reasons, it may be undesirable to make physical copies of the shared resources on the local server, for example, to conserve disk space, to respect copyright constraints, or to make any changes in the shared resources visible automatically. Being able to create new access paths to existing resources in other collections or even on other servers is useful for this sort of case.
多くのコレクション全体の有用性を持っているリソースがまだシングルコレクションに強制されるので、階層はまた、リソース共有をより困難にします。例えば、ある大学で数学部門では、いくつかのローカルリソースへのバインディングが含まれているだけでなく、他の大学でいくつかのリソースへのアクセスを提供フラクタル上の情報の収集を作成することがあります。多くの理由から、ディスクスペースを節約するために著作権の制約を尊重する、または自動的に表示、共有リソースの変更を行うために、例えば、ローカルサーバー上の共有リソースの物理的なコピーを作成するために望ましくないかもしれません。他のコレクションで、あるいは他のサーバー上の既存のリソースへの新しいアクセス・パスを作成できることは、例、この種のために有用です。
The BIND method, defined here, provides a mechanism for allowing clients to create alternative access paths to existing WebDAV resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to work because there are mappings between URIs and resources. A method is addressed to a URI, and the server follows the mapping from that URI to a resource, applying the method to that resource. Multiple URIs may be mapped to the same resource, but until now, there has been no way for clients to create additional URIs mapped to existing resources.
ここで定義されたBINDの方法は、クライアントは既存のWebDAVリソースへの代替アクセス・パスを作成することを可能にするためのメカニズムを提供します。 HTTP [RFC2616]とWebDAV [RFC4918]の方法はURIとリソースの間のマッピングがあるので仕事することができます。この方法は、URIに宛てて、サーバはそのリソースへの方法を適用する、リソースにそのURIからのマッピングに従います。複数のURIが同じリソースにマッピングすることができるが、今までは、クライアントは既存のリソースにマッピングされた追加のURIを作成するための手立てがなかったです。
BIND lets clients associate a new URI with an existing WebDAV resource, and this URI can then be used to submit requests to the resource. Since URIs of WebDAV resources are hierarchical, and correspond to a hierarchy of collections in resource space, the BIND method also has the effect of adding the resource to a collection. As new URIs are associated with the resource, it appears in additional collections.
BINDは、クライアントが既存のWebDAVリソースに新しいURIを関連付けることができますし、このURIはそのリソースへの要求を提出するために使用することができます。 WebDAVのリソースのURIは階層的であり、リソース空間におけるコレクションの階層に対応するので、BINDの方法はまた、コレクションにリソースを追加する効果を有します。新しいURIは、リソースに関連付けられているとして、それは追加のコレクションに表示されます。
A BIND request does not create a new resource, but simply makes a new URI for submitting requests to an existing resource available. The new URI is indistinguishable from any other URI when submitting a request to a resource. Only one round trip is needed to submit a request to the intended target. Servers are required to enforce the integrity of the relationships between the new URIs and the resources associated with them. Consequently, it may be very costly for servers to support BIND requests that cross server boundaries.
BIND要求は、新しいリソースを作成するのではなく、単純に利用できる既存のリソースに要求を提出するための新しいURIを作成しません。リソースへの要求を提出するときに、新しいURIは、他のURIと区別がつきません。一つだけのラウンドトリップが目的のターゲットに要求を提出することが必要とされています。サーバは新しいURIとそれらに関連付けられているリソース間の関係の整合性を適用する必要があります。サーバーは、サーバーの境界を越えBIND要求をサポートするために結果的に、それは非常にコストがかかる可能性があります。
This specification is organized as follows. Section 1.1 defines terminology used in the rest of the specification, while Section 2 overviews bindings. Section 3 defines the new properties needed to support multiple bindings to the same resource. Section 4 specifies the BIND method, used to create multiple bindings to the same resource. Section 5 specifies the UNBIND method, used to remove a binding to a resource. Section 6 specifies the REBIND method, used to move a binding to another collection.
次のようにこの仕様は構成されています。セクション1.1は、セクション2概要バインディングながら、本明細書の残りの部分で使用される用語を定義します。第3節では、同じリソースに複数のバインディングをサポートするために必要な新しいプロパティを定義します。セクション4は、同じリソースに複数のバインディングを作成するために使用されるBIND方式を指定します。第5節では、リソースへの結合を除去するために使用されるUNBIND方法を指定します。第6節は、別のコレクションへの結合を移動するために使用さREBIND方法を指定します。
The terminology used here follows and extends that in the WebDAV Distributed Authoring Protocol 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 notational convention, using the rules defined in Section 17 of [RFC4918].
このドキュメントは[RFC4918]のセクション17で定義されたルールを使用して、表記規則としてXML DTD断片（[XML]）を使用します。
URI Mapping
URIマッピング
A relation between an absolute URI and a resource. For an absolute URI U and the resource it identifies R, the URI mapping can be thought of as (U => R). Since a resource can represent items that are not network retrievable as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http"-scheme URI makes it possible to submit HTTP requests to the resource using the URI.
絶対URIとリソースの間の関係。絶対URI UとそれがRを識別するリソースは、URIマッピングはとして（U => R）と考えることができます。リソースが同様であるものとして回収ネットワークされていないアイテムを表すことができるので、リソースは0個、1個、または多数のURIマッピングを持っているため、それが可能です。 「http」をリソースマッピング-scheme URIは、それが可能なURIを使用してリソースへのHTTPリクエストを提出することができます。
Path Segment
パスセグメント
Informally, the characters found between slashes ("/") in a URI. Formally, as defined in Section 3.3 of [RFC3986].
非公式に、文字はURIにスラッシュ（「/」）との間に見られます。正式には、[RFC3986]のセクション3.3で定義された通りです。
Binding
バインディング
A relation between a single path segment (in a collection) and a resource. A binding is part of the state of a collection. If two different collections contain a binding between the same path segment and the same resource, these are two distinct bindings. So for a collection C, a path segment S, and a resource R, the binding can be thought of as C:(S -> R). Bindings create URI mappings, and hence allow requests to be sent to a single resource from multiple locations in a URI namespace. For example, given a collection C (accessible through the URI http://www.example.com/CollX), a path segment S (equal to "foo.html"), and a resource R, then creating the binding C: (S -> R) makes it possible to use the URI http://www.example.com/CollX/foo.html to access R.
（コレクション内の）単一パスセグメントとリソースの間の関係。バインディングは、コレクションの状態の一部です。二つの異なるコレクションが同一の経路セグメントと同一のリソースとの間の結合を含む場合、これらは、2つの別個の結合です。 （ - > R S）：そう収集Cのために、経路セグメントS、およびリソースR、結合はCと考えることができます。バインディングは、URIのマッピングを作成し、ひいては要求はURI名前空間の複数の場所から単一のリソースに送信することを可能にします。例えば、その後、結合Cを作成収集C（URI http://www.example.com/CollXを介してアクセス可能）、パスセグメントS（「foo.htmlという」に等しい）、及びリソースRを、与えられました： （S - > R）がRをアクセスするためのURI http://www.example.com/CollX/foo.htmlを使用することができます
Collection
コレクション
A resource that contains, as part of its state, a set of bindings that identify internal member resources.
その状態の一部として含むリソース、内部部材のリソースを識別するバインディングのセット。
Internal Member URI
内部メンバーURI
The URI that identifies an internal member of a collection and that consists of the URI for the collection, followed by a slash character ('/'), followed by the path segment of the binding for that internal member.
コレクションの内部メンバを識別し、それはその内部メンバーの結合のパスセグメントに続くスラッシュ（「/」）、続いて収集のためURIから成るURI。
Binding Integrity
バインディングの整合性
The property of a binding that says that:
言う結合のプロパティ：
* the binding continues to exist, and
*存在し続け、および結合
* the identity of the resource identified by that binding does not change,
*その結合することによって識別されるリソースのアイデンティティは変更されません、
unless an explicit request is executed that is defined to delete that binding (examples of requests that delete a binding are DELETE, MOVE, and -- defined later on -- UNBIND and REBIND).
（ - 後で定義 - アンバインドし、REBINDれる結合DELETE、MOVEを削除し、要求の一例）を明示的な要求が実行されない限り、それが結合することを削除するように定義されます。
See Section 16 of [RFC4918] for the definitions of "precondition" and "postcondition".
「前提条件」と「事後条件」の定義については、[RFC4918]のセクション16を参照してください。
Bindings are part of the state of a collection. They define the internal members of the collection and the names of those internal members.
バインディングは、コレクションの状態の一部です。彼らは、コレクションの内部メンバーとそれらの内部のメンバーの名前を定義します。
Bindings are added and removed by a variety of existing HTTP methods. A method that creates a new resource, such as PUT, COPY, and MKCOL, adds a binding. A method that deletes a resource, such as DELETE, removes a binding. A method that moves a resource (e.g., MOVE) both adds a binding (in the destination collection) and removes a binding (in the source collection). The BIND method introduced here provides a mechanism for adding a second binding to an existing resource. There is no difference between an initial binding added by PUT, COPY, or MKCOL and additional bindings added with BIND.
バインディングを加え、既存のHTTPの様々な方法によって除去されます。このようPUT、COPY、およびMKCOLとして、新しいリソースを作成する方法は、バインディングを追加します。 DELETEなど、リソースを削除する方法は、結合を除去します。リソース（例えば、MOVE）の両方の移動方法は、（先のコレクションに）結合および結合（ソースコレクション）を除去する追加します。ここで導入されたBINDの方法は、第2の既存のリソースへの結合を追加するためのメカニズムを提供します。 PUT、COPY、またはMKCOLおよびBINDに追加された追加のバインディングによって追加バインディング初期の間に違いはありません。
It would be very undesirable if one binding could be destroyed as a side effect of operating on the resource through a different binding. In particular, the removal of one binding to a resource (e.g., with a DELETE or a MOVE) MUST NOT disrupt another binding to that resource, e.g., by turning that binding into a dangling path segment. The server MUST NOT reclaim system resources after removing one binding, while other bindings to the resource remain. In other words, the server MUST maintain the integrity of a binding. It is permissible, however, for future method definitions (e.g., a DESTROY method) to have semantics that explicitly remove all bindings and/or immediately reclaim system resources.
1の結合が異なる結合を通じてリソース上で動作の副作用として破壊することができれば、それは非常に望ましくないであろう。具体的には、（DELETEまたはMOVEと例えば、）リソースに結合する一方の除去は別のダングリング経路セグメントに結合することを回すことにより、例えば、そのリソースへの結合を破壊してはいけません。リソースへの他のバインディングが残っている間、サーバーは、結合1つを取り外した後、システムリソースを再利用してはなりません。つまり、サーバーは、結合の完全性を維持しなければなりません。これは、明示的にすべてのバインディングを削除し、および/または直後にシステムリソースを再利用意味を持つように、将来のメソッドの定義（例えば、destroyメソッド）のために、しかし、許容されます。
Note: the collection model described herein is not compatible with systems in which resources inherit properties based solely on the access path, as the ability to create additional bindings will cause a single resource to appear as member of several different collections at the same time.
注意：ここに記載さコレクション・モデルは、リソースは単一のリソースは、同時に複数の異なるコレクションのメンバーとして表示される場合があります追加のバインディングを作成する機能として、アクセスパスのみに基づいてプロパティを継承するシステムと互換性がありません。
Creating a new binding to a collection makes each resource associated with a binding in that collection accessible via a new URI, and thus creates new URI mappings to those resources but no new bindings.
コレクションに新しいバインディングを作成すると、新しいURIを経由して、そのコレクションに結合アクセスに関連した各リソースになりますので、それらのリソースへの新しいURIのマッピングが、新しいバインディングを作成します。
For example, suppose a new binding CollY is created for collection C1 in the figure below. It immediately becomes possible to access resource R1 using the URI /CollY/x.gif and to access resource R2 using the URI /CollY/y.jpg, but no new bindings for these child resources were created. This is because bindings are part of the state of a collection, and they associate a URI that is relative to that collection with its target resource. No change to the bindings in Collection C1 is needed to make its children accessible using /CollY/x.gif and /CollY/y.jpg.
たとえば、新しい結合CollYは下図のコレクションC1のために作成されているとします。それはすぐにURI /CollY/x.gifを使用してリソースR1にアクセスし、URI /CollY/y.jpgを使用してリソースR2にアクセスすることが可能となるが、これらの子リソースのための新たなバインディングが作成されませんでした。バインディングは、コレクションの状態の一部であるので、これはある、と彼らはそのターゲット・リソースとそのコレクションに対する相対URIを関連付けます。コレクションC1でのバインディングへの変更は/CollY/x.gifと/CollY/y.jpgを使用して、その子供たちがアクセスできるようにする必要はありません。
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+------------------+
| Collection C1 |
| bindings: |
| x.gif y.jpg |
+------------------+
| \
| \
| \
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
Bindings to collections can result in loops ("cycles"), which servers MUST detect when processing "Depth: infinity" requests. It is sometimes possible to complete an operation in spite of the presence of a loop. For instance, a PROPFIND can still succeed if the server uses the new status code 208 (Already Reported) defined in Section 7.1.
リクエスト：コレクションへのバインディングは、「無限の深さ」を処理するときにサーバーが検出しなければならないループ（「サイクル」）をもたらすことができます。ループの存在にもかかわらず、操作を完了できる場合があります。サーバはセクション7.1で定義された新しいステータスコード208（すでに報告されている）を使用している場合たとえば、PROPFINDはまだ成功することができます。
However, the 508 (Loop Detected) status code is defined in Section 7.2 for use in contexts where an operation is terminated because a loop was encountered.
しかし、508（ループ検出）のステータスコードは、ループが発生したため、操作が終了した状況での使用については、セクション7.2で定義されています。
Support for loops is OPTIONAL: servers MAY reject requests that would lead to the creation of a bind loop (see DAV:cycle-allowed precondition defined in Section 4).
ループのサポートはオプションです：バインドループの創出につながる要求を拒否するかもしれサーバは（：セクション4で定義されたサイクル-許可の前提条件DAVを参照してください）。
Suppose a binding from "Binding-Name" to resource R is to be added to a collection, C. Then if C-MAP is the set of URIs that were mapped to C before the BIND request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following the BIND request.
C-MAPは、BIND要求の前にCにマッピングされたURIの設定された場合C.は、各URI「C-URIために、そして、R資源に「バインディング名」から結合がコレクションに追加されると仮定します「C-MAPで、URI "C-URI /結合名は" BIND要求次のRリソースにマッピングされます。
For example, if a binding from "foo.html" to R is added to a collection C, and if the following URIs are mapped to C:
例えば、Rに「foo.htmlという」からバインディング収集Cに追加された場合、および以下のURIをCにマッピングされている場合：
http://www.example.com/A/1/ http://example.com/A/one/
ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ ｈっｔｐ：／／えぁｍｐぇ。こｍ／あ／おね／
then the following new mappings to R are introduced:
その後、Rへ次の新しいマッピングが導入されています。
http://www.example.com/A/1/foo.html http://example.com/A/one/foo.html
ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ふぉお。ｈｔｍｌ ｈっｔｐ：／／えぁｍｐぇ。こｍ／あ／おね／ふぉお。ｈｔｍｌ
Note that if R is a collection, additional URI mappings are created to the descendents of R. Also, note that if a binding is made in collection C to C itself (or to a parent of C), an infinite number of mappings are introduced.
Rがコレクションである場合、追加のURIマッピングもR.の子孫に作成されることに注意し、結合がC自身に収集Cで行われた場合（またはCの親に）、マッピングの無限数が導入されることに注意してください。
For example, if a binding from "myself" to C is then added to C, the following infinite number of additional mappings to C are introduced:
Cに「自分」の結合は、その後Cに追加された場合、例えば、Cに追加のマッピングの次の無限数が導入されます。
http://www.example.com/A/1/myself http://www.example.com/A/1/myself/myself ...
ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ｍｙせｌｆ ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ｍｙせｌｆ／ｍｙせｌｆ 。。。
and the following infinite number of additional mappings to R are introduced:
そしてRへの追加のマッピングの次無限数が導入されています。
http://www.example.com/A/1/myself/foo.html http://www.example.com/A/1/myself/myself/foo.html ...
ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ｍｙせｌｆ／ふぉお。ｈｔｍｌ ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／あ／１／ｍｙせｌｆ／ｍｙせｌｆ／ふぉお。ｈｔｍｌ 。。。
As defined in Section 9.8 of [RFC4918], COPY causes the resource identified by the Request-URI to be duplicated and makes the new resource accessible using the URI specified in the Destination header. Upon successful completion of a COPY, a new binding is created between the last path segment of the Destination header and the destination resource. The new binding is added to its parent collection, identified by the Destination header minus its final segment.
[RFC4918]のセクション9.8で定義されているように、COPYは、Request-URIによって識別されたリソースが重複させると宛先ヘッダで指定されたURIを使用して、新しいリソースにアクセスできるようになります。コピーが正常に完了すると、新しいバインディングは、宛先ヘッダの最後のパスセグメントと宛先リソース間で作成されます。新しいバインディングは、宛先ヘッダマイナス最終的なセグメントによって識別親コレクションに追加されます。
The following figure shows an example: suppose that a COPY is issued to URI-3 for resource R (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the COPY operation, resource R is duplicated to create resource R', and a new binding has been created that creates at least the URI mapping between URI-X and the new resource (although other URI mappings may also have been created).
次の図は一例を示している：コピーがURI-Xに設定された宛先ヘッダと、URI-3リソースRのために（また、URI-1及びURI-2にマッピングされている）に発行されていると仮定する。 COPY動作が正常に完了した後に、リソースRは、リソースR」を作成するために複製され、新たな結合は、他のURIマッピングも作成されているかもしれないが（少なくともURI-Xと新しいリソースとの間のURIマッピングを作成し、その作成されています）。
URI-1 URI-2 URI-3 URI-X
| | | |
| | | <---- URI Mappings ----> |
| | | |
+---------------------+ +------------------------+
| Resource R | | Resource R' |
+---------------------+ +------------------------+
It might be thought that a COPY request with "Depth: 0" on a collection would duplicate its bindings, since bindings are part of the collection's state. This is not the case, however. The definition of Depth in [RFC4918] makes it clear that a "Depth: 0" request does not apply to a collection's members. Consequently, a COPY with "Depth: 0" does not duplicate the bindings contained by the collection.
バインディングは、コレクションの状態の一部なので、コレクションに、そのバインディングを複製します：「0深さ」とのコピー要求をすることを考えている可能性があります。しかし、これはそうではありません。 「：0深さ」要求コレクションのメンバーには適用されません[RFC4918]で深さの定義は、それが明確であることになります。その結果、「深さ：0」とのCOPYは、コレクションに含まれるバインディングを複製しません。
If a COPY request causes an existing resource to be updated, the bindings to that resource MUST be unaffected by the COPY request. Using the preceding example, suppose that a COPY request is issued to URI-X for resource R', with the Destination header set to URI-2. The content and dead properties of resource R would be updated to be a copy of those of resource R', but the mappings from URI-1, URI-2, and URI-3 to resource R remain unaffected. If, because of multiple bindings to a resource, more than one source resource updates a single destination resource, the order of the updates is server defined (see Section 2.3.2 for an example).
COPY要求を更新する既存のリソースが発生した場合は、そのリソースへのバインディングがCOPY要求による影響を受けなければなりません。前述の例を使用して、COPY要求がURI-2に設定された宛先ヘッダと、リソースR」のURI-Xに発行されたとします。リソースRの内容とデッドプロパティは、リソースR」のそれらのコピーに更新されますが、リソースRへのURI-1、URI-2、およびURI-3からのマッピングは影響を受けません。 、なぜなら、リソースへの複数のバインディングの、複数のソースリソースが単一の宛先リソースを更新する場合、更新の順序が定義されたサーバ（例えば、セクション2.3.2を参照します）。
If a COPY request would cause a new resource to be created as a copy of an existing resource, and that COPY request has already created a copy of that existing resource, the COPY request instead creates another binding to the previous copy, instead of creating a new resource (see Section 2.3.3 for an example).
COPY要求は既存のリソースのコピーとして作成される新しいリソースを引き起こす、そのCOPY要求が既に既存のリソースのコピーを作成している場合、COPY要求ではなく、代わりに作成するのではなく、以前のコピーに別の結合を作成します新しいリソース（例えば2.3.3項を参照してください）。
As an example of how COPY with "Depth: infinity" would work in the presence of bindings, consider the following collection:
COPY方法の例として、「深さ：無限大は」バインディングの存在下で働くだろう、次のコレクションを考慮してください。
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
+-------------------------------+
| Collection C1 |<-------+
| bindings: | |
| x.gif CollY | |
+-------------------------------+ |
| \ (creates loop) |
| \ |
+-------------+ +------------------+ |
| Resource R1 | | Collection C2 | |
+-------------+ | bindings: | |
| y.gif CollZ | |
+------------------+ |
| | |
| +--------+
|
+-------------+
| Resource R2 |
+-------------+
If a COPY request with "Depth: infinity" is submitted to /CollX, with a destination of /CollA, the outcome of the copy operation is that a copy of the tree is replicated to the target /CollA:
「深さ：無限大」とCOPY要求をした場合/ CollXに提出され、コラ/の先に、コピー操作の結果は、ツリーのコピーがターゲット/コラに複製されていることです。
+------------------+
| Root Collection |
| bindings: |
| CollX CollA |
+------------------+
| |
| +---------------------------+
| |
+-------------------+ |
| Collection C1 |<------------------+ |
| bindings: | | |
| x.gif CollY | | |
+-------------------+ | |
| \ (creates loop) | |
| \ | |
+-------------+ +-----------------+ | |
| Resource R1 | | Collection C2 | | |
+-------------+ | bindings: | | |
| y.gif CollZ | | |
+-----------------+ | |
| | | |
| +-------+ |
| |
+-------------+ |
| Resource R2 | |
+-------------+ |
|
+-------------------------------+
|
+-------------------+
| Collection C3 |<------------------+
| bindings: | |
| x.gif CollY | |
+-------------------+ |
| \ (creates loop) |
| \ |
+-------------+ +-----------------+ |
| Resource R3 | | Collection C4 | |
+-------------+ | bindings: | |
| y.gif CollZ | |
+-----------------+ |
| | |
| +-------+
|
+-------------+
| Resource R4 |
+-------------+
Note that the same would apply for more complex loops.
同じことが、より複雑なループに適用されることに注意してください。
Given the following collection hierarchy:
次のコレクションの階層を考えます：
+------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+------------------+
/ \
/ \
/ \
+--------------------------+ +-----------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| x.gif y.gif | | x.gif y.gif |
+--------------------------+ +-----------------+
| | | |
| | | |
+-------------+ +-------------+ +-------------+
| Resource R1 | | Resource R2 | | Resource R3 |
+-------------+ +-------------+ +-------------+
A COPY of /CollX with "Depth: infinity" to /CollY will not result in a changed hierarchy, and Resource R3 will be updated with the content of either Resource R1 or Resource R2.
/ CollXのCOPY：/ CollYに「深さ無限大は」変更された階層にはなりませんし、リソースR3は、リソースR1またはリソースR2のいずれかの内容で更新されます。
2.3.3. Example: COPY with "Depth: infinity" with Multiple Bindings to a Leaf Resource
2.3.3. 葉のリソースへの複数のバインディングを持つ例：「無限の深さ」とCOPY
Given the following collection hierarchy:
次のコレクションの階層を考えます：
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
|
+----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+----------------+
| |
| |
+-------------+
| Resource R1 |
+-------------+
A COPY of /CollX with "Depth: infinity" to /CollY results in the following collection hierarchy:
以下のコレクション階層内/ CollY結果へ：「無限の深さ」と/ CollXのCOPY：
+------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+------------------+
| \
| \
| \
+----------------+ +-----------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| x.gif y.gif | | x.gif y.gif |
+----------------+ +-----------------+
| | | |
| | | |
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
When there are multiple bindings to a resource, a DELETE applied to that resource MUST NOT remove any bindings to that resource other than the one identified by the Request-URI. For example, suppose the collection identified by the URI "/a" has a binding named "x" to a resource R, and another collection identified by "/b" has a binding named "y" to the same resource R. Then, a DELETE applied to "/a/x" removes the binding named "x" from "/a" but MUST NOT remove the binding named "y" from "/b" (i.e., after the DELETE, "/y/b" continues to identify the resource R).
リソースに複数のバインディングが存在する場合、そのリソースに適用されるDELETEは、Request-URIによって識別されるもの以外のそのリソースに任意のバインディングを削除してはいけません。例えば、そして、URIによって識別されるコレクションは、「/」リソースRへの結合という名前の「X」を有し、「/ B」で識別別のコレクションが同じリソースRに結合するという名前の「Y」を有すると仮定"/ A / X" ではなく "/ B" からの結合という名前の "Y"（つまり、DELETEの後に、 "/ Y / B" を削除してはならない "/" からの結合という名前の "x" を削除するために適用されるDELETEリソースR）を識別し続けます。
When DELETE is applied to a collection, it MUST NOT modify the membership of any other collection that is not itself a member of the collection being deleted. For example, if both "/a/.../x" and "/b/.../y" identify the same collection, C, then applying DELETE to "/a" must not delete an internal member from C or from any other collection that is a member of C, because that would modify the membership of "/b".
DELETEは、コレクションに適用されると、それは削除されるコレクションのメンバーそのものではない、他のコレクションのメンバシップを変更してはいけません。例えば、「/a/.../x」および「/b/.../y」同じコレクションを特定両方場合、適用Cは、「/」Cから内部メンバーを削除してはならないためにDELETEまたはそれは、「/ B」のメンバーシップを変更になるので、Cのメンバーである他のコレクションから。
If a collection supports the UNBIND method (see Section 5), a DELETE of an internal member of a collection MAY be implemented as an UNBIND request. In this case, applying DELETE to a Request-URI has the effect of removing the binding identified by the final segment of the Request-URI from the collection identified by the Request-URI minus its final segment. Although [RFC4918] allows a DELETE to be a non-atomic operation, when the DELETE operation is implemented as an UNBIND, the operation is atomic. In particular, a DELETE on a hierarchy of resources is simply the removal of a binding to the collection identified by the Request-URI.
コレクションはUNBINDメソッドをサポートしている場合（第5節を参照）、コレクションの内部メンバーのDELETEはUNBIND要求として実装することができます。この場合、DELETEに適用するのRequest-URIがRequest-URIマイナス最終的なセグメントによって識別コレクションからのRequest-URIの最後のセグメントによって同定された結合を除去する効果を有します。 [RFC4918]はDELETEは削除操作がUNBINDとして実装されている非アトミック動作にすることができるが、操作がアトミックです。具体的には、リソースの階層上のDELETEは単に、Request-URIによって識別されるコレクションへの結合を除去することです。
When MOVE is applied to a resource, the other bindings to that resource MUST be unaffected; and if the resource being moved is a collection, the bindings to any members of that collection MUST be unaffected. Also, if MOVE is used with Overwrite:T to delete an existing resource, the constraints specified for DELETE apply.
MOVEがリソースに適用されるとき、そのリソースへの他の結合は影響を受けなければなりません。移動中のリソースがコレクションである場合と、そのコレクションのすべてのメンバーへのバインディングは影響を受けなければなりません。 MOVEを上書きして使用されている場合も、：Tは既存のリソースを削除するには、DELETEのために指定された制約が適用されます。
If the destination collection of a MOVE request supports the REBIND method (see Section 6), a MOVE of a resource into that collection MAY be implemented as a REBIND request. Although [RFC4918] allows a MOVE to be a non-atomic operation, when the MOVE operation is implemented as a REBIND, the operation is atomic. In particular, applying a MOVE to a Request-URI and a Destination URI has the effect of removing a binding to a resource (at the Request-URI) and creating a new binding to that resource (at the Destination URI). Even when the Request-URI identifies a collection, the MOVE operation involves only removing one binding to that collection and adding another.
MOVE要求の宛先コレクション（セクション6を参照）REBIND方法をサポートしている場合は、そのコレクション内のリソースのMOVEはREBIND要求として実現されてもよいです。 [RFC4918]はMOVE非アトミック操作することを可能にするがMOVE動作がREBINDとして実装されている場合、操作はアトミックです。具体的には、リクエストURIと宛先への移行を適用するURIは、（要求URIで）リソースに結合し、（先URIで）そのリソースに対する新しいバインディングの作成を除去する効果を有します。リクエストURIは、コレクションを識別した場合であっても、MOVE動作は、そのコレクションに結合するものを除去し、別のものを追加することを含みます。
As an example, suppose that a MOVE is issued to URI-3 for resource R below (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the MOVE operation, a new binding has been created that creates the URI mapping between URI-X and resource R. The binding corresponding to the final segment of URI-3 has been removed, which also causes the URI mapping between URI-3 and R to be removed. If resource R were a collection, old URI-3-based mappings to members of R would have been removed, and new URI-X-based mappings to members of R would have been created.
一例として、MOVEは、URI-Xに設定された宛先ヘッダと、（また、URI-1及びURI-2にマッピングされている）以下リソースRのURI-3に対して発行されると仮定する。 MOVE動作が正常に完了した後に、新しいバインディングはURI-3の最終セグメントに対応することもURIとの間のURIマッピングを引き起こす、除去されたバインディングURI-XおよびリソースR.ザ間のURIマッピングを作成し、その作成されています-3およびRは除去されます。リソースRは、収集した場合には、Rのメンバーに古いURI-3ベースのマッピングが削除されていたであろう、とRのメンバーに新しいURI-Xベースのマッピングが作成されていたであろう。
>> Before Request:
>>要求の前に：
URI-1 URI-2 URI-3
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
>> After Request:
>>リクエストの後に：
URI-1 URI-2 URI-X
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
Note that in the presence of collection bindings, a MOVE request can cause the creation of a bind loop.
コレクションバインディングの存在下で、MOVE要求がバインドループの作成を引き起こす可能性があることに注意してください。
Consider the top-level collections C1 and C2 with URIs "/CollW/" and "/CollX/". C1 also contains an additional binding named "CollY" to C2:
「/ CollW /」および「/ CollX /」URIを持つトップレベルのコレクションC1及びC2を考えます。 C1もC2に「CollY」という名前の追加の結合が含まれています。
+------------------+
| Root Collection |
| bindings: |
| CollW CollX |
+------------------+
| |
| |
+------------------+ |
| Collection C1 | |
| bindings: | |
| CollY | |
+------------------+ |
| |
| |
+------------------+
| Collection C2 |
| |
| |
+------------------+
In this case, the MOVE request below would cause a bind loop:
この場合、以下のMOVE要求がバインドループが発生します：
>> Request:
>>リクエスト：
MOVE /CollW HTTP/1.1 Host: example.com Destination: /CollX/CollZ
MOVE / CollW HTTP / 1.1ホスト：example.com先：/ CollX / CollZ
If the request succeeded, the resulting state would be:
リクエストが成功した場合、結果の状態は次のようになります。
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
+------------------+ |
| Collection C1 | |
+----> | bindings: | |
| | CollY | |
| +------------------+ |
| | |
| | |
| +------------------+
| | Collection C2 |
| | bindings: |
| | CollZ |
| +------------------+
| |
| |
+-------------------+
Consistent with [RFC4918], the value of a dead property MUST be independent of the number of bindings to its host resource or of the path submitted to PROPFIND. On the other hand, the behavior for each live property depends on its individual definition (for example, see [RFC3744], Section 5, Paragraph 2 for a case where the value is independent of its path and bindings, and [RFC4918], Section 8.8 for a discussion about the live properties DAV:getetag and DAV: getlastmodified, which may behave differently).
[RFC4918]と一致して、死者のプロパティの値は、そのホストのリソースまたはPROPFINDに提出パスのバインディングの数の独立していなければなりません。一方、各ライブプロパティの動作は、（例えば、[RFC3744]、セクション5、値はそのパスとバインディングから独立している場合のパラグラフ2、及び[RFC4918]、セクションを参照その個々の定義に依存しますライブプロパティについての議論のための8.8は、DAV：getetagとDAV：getlastmodifiedを、異なる挙動を示す可能性があります）。
It is useful to have some way of determining whether two bindings are to the same resource. Two resources might have identical contents and properties, but not be the same resource (e.g., an update to one resource does not affect the other resource).
2つのバインディングが同じリソースにあるかどうかを決定するいくつかの方法があると便利です。 2つのリソースは、同一の内容や性質を持っていますが、（例えば、一つのリソースへの更新が他のリソースに影響を与えません）同じリソースではないかもしれません。
The REQUIRED DAV:resource-id property defined in Section 3.1 is a resource identifier, which MUST be unique across all resources for all time. If the values of DAV:resource-id returned by PROPFIND requests through two bindings are identical character by character, the client can be assured that the two bindings are to the same resource.
REQUIRED DAV：3.1節で定義されたリソース-idプロパティは、すべての時間のためにすべてのリソース間で一意でなければならないリソース識別子、です。 DAVの値場合：2つのバインディングを通じてPROPFINDリクエストによって返されたリソース-idは文字によって同一の文字が、クライアントは2つのバインディングが同じリソースにあることを保証することができます。
The DAV:resource-id property is created, and its value assigned, when the resource is created. The value of DAV:resource-id MUST NOT be changed. Even after the resource is no longer accessible through any URI, that value MUST NOT be reassigned to another resource's DAV: resource-id property.
DAV：リソースが作成されたときに、リソース-idプロパティは、作成され、その値が割り当てられます。 DAVの値：リソース-IDを変更してはいけません。リソースは任意のURIを通じてアクセスできなくなった後も、その値は、別のリソースのDAVに再割り当てないしてはならない：リソース-idプロパティ。
Any method that creates a new resource MUST assign a new, unique value to its DAV:resource-id property. For example, a PUT applied to a null resource, COPY (when not overwriting an existing target) and CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value to the DAV:resource-id property of the new resource they create.
リソース-idプロパティ：新しいリソースを作成し、任意の方法は、そのDAVに新しい、ユニークな値を割り当てる必要があります。例えば、ヌルリソース、COPY（既存のターゲットを上書きしない場合）とCHECKINに適用PUTは、DAVに新しい、一意の値を割り当てる必要があります（[RFC3253]、セクション4.4を参照）：新しいリソースのリソースIDプロパティを彼らが作成します。
On the other hand, any method that affects an existing resource must not change the value of its DAV:resource-id property. Specifically, a PUT or a COPY that updates an existing resource must not change the value of its DAV:resource-id property. A REBIND, since it does not create a new resource, but only changes the location of an existing resource, must not change the value of the DAV:resource-id property.
リソース-idプロパティ：一方、既存のリソースに影響を与える方法は、そのDAVの値を変更しないでください。リソース-idプロパティ：具体的には、既存のリソースを更新PUTまたはCOPYは、そのDAVの値を変更しないでください。リソース-idプロパティ：それは新しいリソースを作成しますが、唯一の既存のリソースの場所を変更していないので、REBINDは、DAVの値を変更しないでください。
An OPTIONAL DAV:parent-set property on a resource provides a list of the bindings that associate a collection and a URI segment with that resource. If the DAV:parent-set property exists on a given resource, it MUST contain a complete list of all bindings to that resource that the client is authorized to see. When deciding whether to support the DAV:parent-set property, server implementers / administrators should balance the benefits it provides against the cost of maintaining the property and the security risks enumerated in Sections 12.4 and 12.5.
オプションDAV：親設定プロパティリソースには、そのリソースを収集し、URIセグメントを関連付けるバインディングのリストを提供します。 DAV場合：親設定プロパティは、与えられたリソース上に存在する、それはクライアントが参照を許可されているリソースへのすべてのバインディングの完全なリストを含まなければなりません。 DAVをサポートするかどうかを決定するときは：親設定プロパティを、サーバーの実装者/管理者は、それが財産を維持するためのコストとセクション12.4と12.5で列挙セキュリティリスクに対して提供ベネフィットのバランスをとる必要があります。
The bind feature introduces the properties defined below.
バインド機能は、次に定義する特性を紹介します。
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a binding server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request.
DAV：allprop PROPFIND要求は、この文書で定義されたプロパティのいずれかを返すべきではありません。 allprop PROPFIND要求：これは、すべての可能なライブのプロパティを計算するために、サーバーを尋ねるのコストを理解していない素朴なクライアントは、DAVを発行したときに結合サーバーが効率的に実行することができます。
The DAV:resource-id property is a REQUIRED property that enables clients to determine whether two bindings are to the same resource. The value of DAV:resource-id is a URI, and may use any registered URI scheme that guarantees the uniqueness of the value across all resources for all time (e.g., the urn:uuid: URN namespace defined in [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]).
DAV：リソースIDプロパティは、2つのバインディングが同じリソースにあるかどうかを決定するためにクライアントを有効に必要なプロパティです。 DAVの値：リソースIDはURIであり、すべての時間（例えば、骨壷のためにすべてのリソースを横切る値の一意性を保証する任意の登録URIスキームを使用することができる：UUID：URN名前空間は[RFC4122]またはopaquelocktokenで定義されて[RFC4918]で定義されたURIスキーム）。
<!ELEMENT resource-id (href)>
<！ELEMENTリソース-ID（HREF）>
The DAV:parent-set property is an OPTIONAL property that enables clients to discover what collections contain a binding to this resource (i.e., what collections have that resource as an internal member). It contains an href/segment pair for each collection that has a binding to the resource. The href identifies the collection, and the segment identifies the binding name of that resource in that collection.
DAV：親設定プロパティは、このリソースへの結合のコレクションが含まれているものを発見するためにクライアントを可能オプションのプロパティです（すなわち、内部のメンバーとして、そのリソース持っているもののコレクション）。これは、リソースへの結合を有し、各コレクションのHREF /セグメント対を含んでいます。 HREFは、コレクションを識別し、セグメントがそのコレクション内のそのリソースのバインディング名を識別する。
A given collection MUST appear only once in the DAV:parent-set for any given binding, even if there are multiple URI mappings to that collection.
指定されたコレクションは、DAVに一度だけ現れなければならない：そのコレクションに複数のURIのマッピングがある場合でも、バインディング与えられたいずれかの親がセット。
<!ELEMENT parent-set (parent)*> <!ELEMENT parent (href, segment)> <!ELEMENT segment (#PCDATA)> <!-- PCDATA value: segment, as defined in Section 3.3 of [RFC3986] -->
<！ELEMENT親セット（親）*> <ELEMENT親（HREF、セグメント）> <！ELEMENTセグメント（#PCDATA）> <！ - PCDATA値：セグメント、セクション3.3で定義されるように[RFC3986] - >
For example, if collection C1 is mapped to both /CollX and /CollY, and C1 contains a binding named "x.gif" to a resource R1, then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set of R1, but not both. But if C1 also had a binding named "y.gif" to R1, then there would be two entries for C1 in the DAV:parent-set of R1 (i.e., both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
例えば、収集C1は/ CollX及び/ CollY両方にマッピングされ、C1は、リソースR1、その後のいずれか[/ CollX、x.gif]または[/ CollY、x.gifに結合名前 "x.gif" が含まれる場合両方のR1の親セットではなく：] DAVに表示することができます。 R1（すなわち、両方の[/ CollX、x.gif]と[/ CollX、親のセット：C1はまた、R1との結合という名前の「y.gif」を持っていた場合でも、その後、DAVでC1の2つのエントリが存在することになりますy.gif]、あるいは、両方の[/ CollY、x.gif]および[/ CollY、y.gif]）。
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+-----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+-----------------+
| |
| |
| |
+-------------+
| Resource R1 |
+-------------+
In this case, one possible value for the DAV:parent-set property on "/CollX/x.gif" would be:
この場合は、DAVのための1つの可能な値：「/CollX/x.gif」の親設定プロパティは、次のようになります。
<parent-set xmlns="DAV:"> <parent> <href>/CollX</href> <segment>x.gif</segment> </parent> <parent> <href>/CollX</href> <segment>y.gif</segment> </parent> </parent-set>
<親セットのxmlns = "DAV："> <親> <HREF> / CollX </ HREF> <セグメント> x.gif </セグメント> </親> <親> <HREF> / CollX </ HREF> <セグメント> y.gif </セグメント> </親> </親セット>
The BIND method modifies the collection identified by the Request-URI, by adding a new binding from the segment specified in the BIND body to the resource identified in the BIND body.
BIND法は、BIND本体に識別されたリソースに結合体で指定されたセグメントから新しいバインディングを追加することによって、リクエストURIによって識別されるコレクションを修正します。
If a server cannot guarantee the integrity of the binding, the BIND request MUST fail. Note that it is especially difficult to maintain the integrity of cross-server bindings. Unless the server where the resource resides knows about all bindings on all servers to that resource, it may unwittingly destroy the resource or make it inaccessible without notifying another server that manages a binding to the resource. For example, if server A permits the creation of a binding to a resource on server B, server A must notify server B about its binding and must have an agreement with B that B will not destroy the resource while A's binding exists. Otherwise, server B may receive a DELETE request that it thinks removes the last binding to the resource and destroy the resource while A's binding still exists. The precondition DAV:cross-server-binding is defined below for cases where servers fail cross-server BIND requests because they cannot guarantee the integrity of cross-server bindings.
サーバーは、結合の完全性を保証することはできません場合は、BIND要求が失敗しなければなりません。クロスサーババインディングの整合性を維持することが特に困難であることに注意してください。リソースが存在するサーバーがそのリソースへのすべてのサーバー上に関するすべてのバインディングを知っている場合を除き、それは無意識のうちに資源を破壊したり、リソースへの結合を管理し、別のサーバーに通知することなく、それはアクセスできないことがあります。サーバーAがサーバーB上のリソースへの結合の作成を許可する場合、例えば、サーバAは、その結合およびAの結合が存在している間Bがリソースを破壊しないであろうBとの契約を持っている必要がありますについては、サーバBに通知しなければなりません。そうでない場合は、サーバBは、それがリソースへの最後のバインディングを削除し、Aの結合がまだ存在している間、リソースを破壊すると考えDELETE要求を受信することができます。前提条件のDAV：クロスサーバ結合は、それらがクロスサーババインディングの整合性を保証できませんので、サーバがクロスサーバBIND要求を失敗する例については、以下に定義されます。
By default, if there already is a binding for the specified segment in the collection, the new binding replaces the existing binding. This default binding replacement behavior can be overridden using the Overwrite header defined in Section 10.6 of [RFC4918].
すでに存在している場合、デフォルトでは、コレクション内の指定されたセグメントのバインディング、新しいバインディングは、既存の結合に置き換えられます。このデフォルトバインディング交換挙動は[RFC4918]のセクション10.6で定義された上書きヘッダを使用してオーバーライドすることができます。
If a BIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
BIND要求が失敗した場合は、リクエストの前にサーバの状態を復元する必要があります。この方法は、（[RFC2616]、セクション9.1を参照）危険と冪等です。
Marshalling:
マーシャリング：
The request MAY include an Overwrite header.
要求が上書きヘッダーを含むかもしれません。
The request body MUST be a DAV:bind XML element.
バインドXML要素：リクエストボディは、DAVでなければなりません。
<!ELEMENT bind (segment, href)>
<！ELEMENTバインド（セグメント、HREF）>
If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced.
リクエストが成功すると、サーバーは、既存のバインディングが交換された新しいバインディングが作成された（作成者）201および200（OK）または204（コンテンツなし）を返さなければなりません。
If a response body for a successful request is included, it MUST be a DAV:bind-response XML element. Note that this document does not define any elements for the BIND response body, but the DAV: bind-response element is defined to ensure interoperability between future extensions that do define elements for the BIND response body.
成功した要求に対するレスポンスボディが含まれている場合は、DAVでなければならない：バインド応答XML要素。この文書はBINDのレスポンスボディのための任意の要素を定義していないことに注意してください、しかし、DAV：バインド応答エレメントは、BINDのレスポンスボディのための要素を定義行い、将来の拡張の間の相互運用性を確保するために定義されています。
<!ELEMENT bind-response ANY>
<！ELEMENTバインド応答ANY>
Preconditions:
前提条件：
(DAV:bind-into-collection): The Request-URI MUST identify a collection.
（DAV：バインドに-コレクション）：Request-URIがコレクションを特定しなければなりません。
(DAV:bind-source-exists): The DAV:href element MUST identify a resource.
（DAV：バインドソースが-存在）：DAV：hrefの要素は、リソースを識別しなければなりません。
(DAV:binding-allowed): The resource identified by the DAV:href supports multiple bindings to it.
（DAV：-許可バインディング）：DAVで識別されるリソース：HREFがそれに複数のバインディングをサポートしています。
(DAV:cross-server-binding): If the resource identified by the DAV: href element in the request body is on another server from the collection identified by the Request-URI, the server MUST support cross-server bindings (servers that do not support cross-server bindings can use this condition code to signal the client exactly why the request failed).
（DAV：クロスサーバ結合）：DAVで識別されるリソース場合：リクエストボディのhref要素が要求URIで識別されるコレクションから別のサーバー上にある、サーバはクロスサーバのバインディング（実行するサーバをサポートしなければなりませんないサポートクロスサーバのバインディングは、要求が失敗した理由）正確にクライアントを知らせるために、この条件コードを使用することができます。
(DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name.
（DAV：名可）：DAVによって指定された名前：セグメントは新しいバインディング名として使用可能です。
(DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T".
（DAV：CAN-上書き）：コレクションは、すでに指定されたパスのセグメントとの結合を含み、上書きヘッダが含まれている場合、上書きヘッダの値が「T」でなければならない場合。
(DAV:cycle-allowed): If the DAV:href element identifies a collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace (servers that do not support cycles can use this condition code to signal the client exactly why the request failed).
（DAV：サイクル-許可）：hrefの要素のコレクションを識別し、要求URIは、そのコレクションのメンバーであるコレクションを識別した場合、サーバがサポートしていないURI名前空間（サーバ内のサイクルをサポートしなければならない：DAVの場合サイクル）は、要求が失敗した理由を正確にクライアントを知らせるために、この条件コードを使用することができます。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV：ロック更新可）：のRequest-URIによって識別されるコレクションは書き込みロックされている場合、適切なトークンがあれば要求ヘッダーで指定されなければなりません。
(DAV:locked-overwrite-allowed): If the collection already contains a binding with the specified path segment, and if that binding is protected by a write lock, then the appropriate token MUST be specified in an If request header.
（DAV：ロック上書き可）：コレクションは、すでに指定されたパスのセグメントとの結合を含む場合、その結合は、書き込みロックによって保護されている場合、次いで適切なトークンがあれば要求ヘッダーで指定されなければなりません。
Postconditions:
事後条件：
(DAV:new-binding): The collection MUST have a binding that maps the segment specified in the DAV:segment element in the request body to the resource identified by the DAV:href element in the request body.
（DAV：新しい結合）：DAVで識別されるリソースにリクエストボディ内のセグメントの要素：リクエストボディのhref要素コレクションが結合すなわちDAVで指定されたセグメントをマッピングしなければなりません。
>> Request:
>>リクエスト：
BIND /CollY HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: 172
BIND / CollY HTTP / 1.1ホスト：www.example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：172
<?xml version="1.0" encoding="utf-8" ?> <D:bind xmlns:D="DAV:"> <D:segment>bar.html</D:segment> <D:href>http://www.example.com/CollX/foo.html</D:href> </D:bind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：バインドのxmlns：D = "DAV："> <D：セグメント>内容でbar.html </ D：セグメント> <D：HREF> HTTP ：//www.example.com/CollX/foo.html </ D：HREF> </ D：バインド>
>> Response:
>>回答：
HTTP/1.1 201 Created Location: http://www.example.com/CollY/bar.html
HTTP / 1.1 201作成された場所：http://www.example.com/CollY/bar.html
The server added a new binding to the collection, "http://www.example.com/CollY", associating "bar.html" with the resource identified by the URI "http://www.example.com/CollX/foo.html". Clients can now use the URI "http://www.example.com/CollY/bar.html" to submit requests to that resource.
サーバは「http://www.example.com/CollY」、コレクションに新しいバインディングを追加し、URIで識別されるリソースで「内容でbar.htmlを」関連付ける「http://www.example.com/CollX/ foo.htmlという」。クライアントは、今、そのリソースに要求を提出するURI「http://www.example.com/CollY/bar.html」を使用することができます。
The UNBIND method modifies the collection identified by the Request-URI by removing the binding identified by the segment specified in the UNBIND body.
UNBIND方法は、結合UNBIND体で指定されたセグメントによって識別さを除去することにより、リクエストURIによって識別されるコレクションを修正します。
Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If UNBIND removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource.
リソースは任意のURIマッピングによって到達不能になると、サーバーはそのリソースに関連付けられたシステムリソースを再利用するかもしれません。 UNBINDがリソースへのバインディングを削除しますが、URIのマッピングは、そのリソースに残っている場合、サーバーはリソースに関連付けられたシステムリソースを再利用してはなりません。
If an UNBIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
UNBIND要求が失敗した場合は、リクエストの前にサーバの状態を復元する必要があります。この方法は、（[RFC2616]、セクション9.1を参照）危険と冪等です。
Marshalling:
マーシャリング：
The request body MUST be a DAV:unbind XML element.
アンバインドXML要素：リクエストボディは、DAVでなければなりません。
<!ELEMENT unbind (segment)>
<！ELEMENTのアンバインド（セグメント）>
If the request succeeds, the server MUST return 200 (OK) or 204 (No Content) when the binding was successfully deleted.
リクエストが成功すると、サーバーは、バインドが正常に削除された200（OK）または204（コンテンツなし）を返さなければなりません。
If a response body for a successful request is included, it MUST be a DAV:unbind-response XML element. Note that this document does not define any elements for the UNBIND response body, but the DAV:unbind-response element is defined to ensure interoperability between future extensions that do define elements for the UNBIND response body.
成功した要求に対するレスポンスボディが含まれている場合は、DAVでなければならない：アンバインド応答XML要素。この文書はUNBINDレスポンスボディのための任意の要素を定義していないことに注意してください、しかし、DAV：アンバインド応答要素がUNBINDレスポンスボディのための要素を定義行い、将来の拡張の間の相互運用性を確保するために定義されています。
<!ELEMENT unbind-response ANY>
<！ELEMENTアンバインド応答ANY>
Preconditions:
前提条件：
(DAV:unbind-from-collection): The Request-URI MUST identify a collection.
（DAV：アンバインド-から収集）：のRequest-URIは、コレクションを識別しなければなりません。
(DAV:unbind-source-exists): The DAV:segment element MUST identify a binding in the collection identified by the Request-URI.
（DAV：アンバインドソースが-存在）：DAV：セグメント要素がRequest-URIによって識別されるコレクション内のバインディングを識別しなければなりません。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV：ロック更新可）：のRequest-URIによって識別されるコレクションは書き込みロックされている場合、適切なトークンは、要求で指定されなければなりません。
(DAV:protected-url-deletion-allowed): If the binding identified by the segment is protected by a write lock, then the appropriate token MUST be specified in the request.
（DAV：保護されたURL欠失許容）：セグメントによって同定された結合は、書き込みロックで保護されている場合、次いで適切なトークンは、要求で指定されなければなりません。
Postconditions:
事後条件：
(DAV:binding-deleted): The collection MUST NOT have a binding for the segment specified in the DAV:segment element in the request body.
（DAV：欠失バインディング）：リクエストボディ内のセグメントの要素：コレクションは、DAVで指定されたセグメントに結合してはなりません。
(DAV:lock-deleted): If the internal member URI of the binding specified by the Request-URI and the DAV:segment element in the request body was protected by a write lock at the time of the request, that write lock must have been deleted by the request.
Request-URIおよびDAVで指定結合の内部メンバーURI場合：（DAV：ロック削除）リクエストボディ内のセグメント要素は要求時の書込ロックで保護された、その書き込みロックを持っている必要があります要求によって削除されて。
>> Request:
>>リクエスト：
UNBIND /CollX HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: 117
UNBIND / CollX HTTP / 1.1ホスト：www.example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：117
<?xml version="1.0" encoding="utf-8" ?> <D:unbind xmlns:D="DAV:"> <D:segment>foo.html</D:segment> </D:unbind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：アンバインドのxmlns：D = "DAV："> <D：セグメント> foo.htmlという</ D：セグメント> </ D：アンバインド>
>> Response:
>>回答：
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
The server removed the binding named "foo.html" from the collection, "http://www.example.com/CollX". A request to the resource named "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) response.
サーバーは、コレクションからの結合という名前の「foo.htmlという」、「http://www.example.com/CollX」を削除しました。名前のリソースへの要求は「http://www.example.com/CollX/foo.html」404（Not Found）応答を返します。
The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request, and MUST be treated the same way as MOVE for the purpose of determining access permissions.
REBINDメソッドは、コレクションからリソースへの結合を除去し、そして、Request-URIによって識別されるコレクションにそのリソースへの結合が追加されます。リクエストボディは、（セグメント）を添加する結合、古いバインディングを除去する（HREF）を指定します。これは、効果的に移動要求の原子の形であり、アクセス権を決定する目的のためにMOVEと同じように扱われなければなりません。
If a REBIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
REBIND要求に失敗した場合は、リクエストの前にサーバの状態を復元する必要があります。この方法は、（[RFC2616]、セクション9.1を参照）危険と冪等です。
Marshalling:
マーシャリング：
The request MAY include an Overwrite header.
要求が上書きヘッダーを含むかもしれません。
The request body MUST be a DAV:rebind XML element.
リクエストボディは、DAVでなければならない：XML要素を再バインドします。
<!ELEMENT rebind (segment, href)>
<！ELEMENT再バインド（セグメント、HREF）>
If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced.
リクエストが成功すると、サーバーは、既存のバインディングが交換された新しいバインディングが作成された（作成者）201および200（OK）または204（コンテンツなし）を返さなければなりません。
If a response body for a successful request is included, it MUST be a DAV:rebind-response XML element. Note that this document does not define any elements for the REBIND response body, but the DAV:rebind-response element is defined to ensure interoperability between future extensions that do define elements for the REBIND response body.
再バインド応答XML要素：成功したリクエストのレスポンスボディが含まれている場合は、DAVでなければなりません。この文書はREBINDのレスポンスボディのための任意の要素を定義していないことに注意してください、しかし、DAV：再バインド応答要素は、REBINDのレスポンスボディのための要素を定義行い、将来の拡張の間の相互運用性を確保するために定義されています。
<!ELEMENT rebind-response ANY>
<！ELEMENT再バインド応答ANY>
Preconditions:
前提条件：
(DAV:rebind-into-collection): The Request-URI MUST identify a collection.
（DAV：再バインド-にコレクション）：のRequest-URIは、コレクションを識別しなければなりません。
(DAV:rebind-source-exists): The DAV:href element MUST identify a resource.
（DAV：再バインド・ソースは、存在）：DAV：hrefの要素は、リソースを識別しなければなりません。
(DAV:cross-server-binding): If the resource identified by the DAV: href element in the request body is on another server from the collection identified by the Request-URI, the server MUST support cross-server bindings (servers that do not support cross-server bindings can use this condition code to signal the client exactly why the request failed).
（DAV：クロスサーバ結合）：DAVで識別されるリソース場合：リクエストボディのhref要素が要求URIで識別されるコレクションから別のサーバー上にある、サーバはクロスサーバのバインディング（実行するサーバをサポートしなければなりませんないサポートクロスサーバのバインディングは、要求が失敗した理由）正確にクライアントを知らせるために、この条件コードを使用することができます。
(DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name.
（DAV：名可）：DAVによって指定された名前：セグメントは新しいバインディング名として使用可能です。
(DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T".
（DAV：CAN-上書き）：コレクションは、すでに指定されたパスのセグメントとの結合を含み、上書きヘッダが含まれている場合、上書きヘッダの値が「T」でなければならない場合。
(DAV:cycle-allowed): If the DAV:href element identifies a collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace (servers that do not support cycles can use this condition code to signal the client exactly why the request failed).
（DAV：サイクル-許可）：hrefの要素のコレクションを識別し、要求URIは、そのコレクションのメンバーであるコレクションを識別した場合、サーバがサポートしていないURI名前空間（サーバ内のサイクルをサポートしなければならない：DAVの場合サイクル）は、要求が失敗した理由を正確にクライアントを知らせるために、この条件コードを使用することができます。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV：ロック更新可）：のRequest-URIによって識別されるコレクションは書き込みロックされている場合、適切なトークンは、要求で指定されなければなりません。
(DAV:protected-url-modification-allowed): If the collection identified by the Request-URI already contains a binding with the specified path segment, and if that binding is protected by a write lock, then the appropriate token MUST be specified in the request.
（DAV：保護されたURL修飾許容）のRequest-URIによって識別されるコレクションは、すでに指定されたパスのセグメントとの結合を含み、その結合は、書き込みロックによって保護されている場合、次いで適切なトークンは、で指定する必要がある場合リクエスト。
(DAV:locked-source-collection-update-allowed): If the collection identified by the parent collection prefix of the DAV:href URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV：ロック・ソース・コレクション・更新許可）：コレクションは、DAVの親コレクションプレフィックスによって識別される場合：hrefのURIが書き込みロックされ、次いで適切なトークンは、要求で指定されなければなりません。
(DAV:protected-source-url-deletion-allowed): If the DAV:href URI is protected by a write lock, then the appropriate token MUST be specified in the request.
DAV場合：（DAV：保護されたソースURL欠失許容）HREF URIが書き込みロックによって保護され、次いで適切なトークンは、要求で指定されなければなりません。
Postconditions:
事後条件：
(DAV:new-binding): The collection MUST have a binding that maps the segment specified in the DAV:segment element in the request body, to the resource that was identified by the DAV:href element in the request body.
（DAV：新しい結合）：リクエストボディ内のセグメント要素、DAVにより同定されたリソースへ：リクエストボディのhref要素のコレクションは、DAVで指定されたセグメントをマッピングすること結合を持たなければなりません。
(DAV:binding-deleted): The URL specified in the DAV:href element in the request body MUST NOT be mapped to a resource.
（DAV：欠失結合）：DAVで指定されたURL：リクエストボディのhref要素がリソースにマッピングされてはいけません。
(DAV:lock-deleted): If the URL specified in the DAV:href element in the request body was protected by a write lock at the time of the request, that write lock must have been deleted by the request.
（DAV：ロックは-削除）：DAVに指定されたURL場合：リクエストボディのhref要素は、要求時に書き込みロックによって保護されていた、その書き込みロックが要求によって削除されている必要があります。
>> Request:
>>リクエスト：
REBIND /CollX HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: 176
REBIND / CollX HTTP / 1.1ホスト：www.example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：176
<?xml version="1.0" encoding="utf-8" ?> <D:rebind xmlns:D="DAV:"> <D:segment>foo.html</D:segment> <D:href>http://www.example.com/CollY/bar.html</D:href> </D:rebind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlnsを再バインド：D = "DAV："> <D：セグメント> foo.htmlという</ D：セグメント> <D：HREF> HTTP ：//www.example.com/CollY/bar.html </ D：HREF> </ D：再バインド>
>> Response:
>>回答：
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
The server added a new binding to the collection, "http://www.example.com/CollX", associating "foo.html" with the resource identified by the URI "http://www.example.com/CollY/bar.html" and removes the binding named "bar.html" from the collection identified by the URI
サーバは「http://www.example.com/CollX」、コレクションに新しいバインディングを追加し、URIで識別されるリソースで「foo.htmlという」を関連付ける「http://www.example.com/CollY/内容でbar.html」と結合という名前の削除 『URIで識別されるコレクションから内容でbar.htmlを』
"http://www.example.com/CollY". Clients can now use the URI "http://www.example.com/CollX/foo.html" to submit requests to that resource, and requests on the URI "http://www.example.com/CollY/bar.html" will fail with a 404 (Not Found) response.
"http://www.example.com/CollY"。クライアントは、今URI「http://www.example.com/CollY/barにそのリソースへの要求、および要求を提出するURI「http://www.example.com/CollX/foo.html」を使用することができます。 htmlの」404（見つかりません）応答で失敗します。
To illustrate the effects of locks and bind loops on a REBIND operation, consider the following collection:
ロックの影響を説明し、再バインド操作上のループをバインドするには、次のコレクションを考慮してください。
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |<--------+
| LOCKED infinity | |
| (lock token L1) | |
| bindings: | |
| CollX CollY | |
+-------------------------------+ |
| | |
| | (creates loop) |
| | |
+-----------------+ +------------------+ |
| Collection C2 | | Collection C3 | |
| (inherit lock) | | (inherit lock) | |
| (lock token L1) | | (lock token L1) | |
| bindings: | | bindings: | |
| {none} | | y.gif CollZ | |
+-----------------+ +------------------+ |
| | |
| +-----+
|
+---------------------------+
| Resource R2 |
| (lock inherited from C1) |
| (lock token L1) |
+---------------------------+
(where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9").
（ここで、L1は、 "：UUID：f92d4fae-7012-11ab-a765-00c0ca1f6bf9 URN" です）。
Note that the binding between CollZ and C1 creates a loop in the containment hierarchy. Servers are not required to support such loops, though the server in this example does.
CollZとC1の間の結合が包含階層のループを作成することに留意されたいです。この例では、サーバーがないのにサーバーは、このようなループをサポートする必要はありません。
The REBIND request below will remove the segment "CollZ" from C3 and add a new binding from "CollA" to the collection C2.
REBIND要求は、以下のC3からセグメント「CollZ」を削除し、収集C2に「コラ」から新しいバインディングを追加します。
REBIND /CollW/CollX HTTP/1.1 Host: www.example.com If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>) Content-Type: application/xml; charset="utf-8" Content-Length: 152
REBIND / CollW / CollX HTTP / 1.1ホスト：www.example.comの場合：（<URN：UUID：f92d4fae-7012-11ab-a765-00c0ca1f6bf9>）のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：152
<?xml version="1.0" encoding="utf-8" ?> <D:rebind xmlns:D="DAV:"> <D:segment>CollA</D:segment> <D:href>/CollW/CollY/CollZ</D:href> </D:rebind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlnsを再バインド：D = "DAV："> <D：セグメント>コラが</ D：セグメント> <D：HREF> / CollW / CollY / CollZ </ D：HREF> </ D：再バインド>
The outcome of the REBIND operation is:
REBIND操作の結果は次のとおりです。
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |
| LOCKED infinity |
| (lock token L1) |
| bindings: |
| CollX CollY |
+-------------------------------+
| ^ |
| | |
+-----------------+ | +------------------+
| Collection C2 | | | Collection C3 |
|(inherited lock) | | | (inherited lock) |
|(lock token L1) | | | (lock token L1) |
| bindings: | | | bindings: |
| CollA | | | y.gif |
+-----------------+ | +------------------+
| | |
+---------------+ |
(creates loop) |
+---------------------------+
| Resource R2 |
| (inherited lock from C1) |
| (lock token L1) |
+---------------------------+
The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly. For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.
繰り返し同じコレクションに複数のバインディングの内部メンバーを列挙避けるためpropstat応答エレメント：208（既に報告）ステータスコードがDAV内で使用することができます。他のすべてのバインディングの応答エレメント208個の状態が使用され、およびNO DAV：その子孫の応答要素が含まれていない後続のDAVはながら、各リクエストのスコープ内コレクションに結合するために、一つだけは、200のステータスで報告されます。
Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop as discussed in Section 2.2.
208のステータスが唯一の「深さ：無限」のために発生することに注意してくださいリクエスト、および2.2節で述べたように、複数のコレクションバインディングがバインドループが発生するとき、それは特に重要であること。
A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource.
クライアントは、DAVを要求することができます：リソース-idプロパティをPROPFIND要求に、彼らは正確に単一のリソースに複数のバインディングのコレクションの結合構造を再構築できることを保証します。
For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request header (see Section 8.2). Instead, a 508 status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response.
クライアントが「DAV」リクエストヘッダを使用して、この仕様のサポートを合図していない限り、multistatusレスポンスボディに登場する208のステータスコードを認識していないクライアントとの後方互換性のために、それを使用すべきでない（8.2節を参照してください）。結合ループが発見されたときに代わりに、508のステータスが返されるべきです。それが応答を開始する前に、それはmultistatus応答を行うストリーミングの途中でそれを発見した場合、それは、それを発見し、またはmultistatusの途中で場合、これは、サーバはトップレベルのリターン・ステータスとして508を返すことができます。
For example, consider a PROPFIND request on /Coll (bound to collection C), where the members of /Coll are /Coll/Foo (bound to resource R) and /Coll/Bar (bound to collection C).
例えば、/コルのメンバーは/コル/ Fooの（R資源にバインド）と（回収Cに結合している）/コル/バーです（収集Cに結合している）/コル、上のPROPFIND要求を検討してください。
>> Request:
>>リクエスト：
PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity DAV: bind Content-Type: application/xml; charset="utf-8" Content-Length: 152
PROPFIND /コル/ HTTP / 1.1ホスト：www.example.com深さ：無限DAV：バインドのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：152
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:displayname/> <D:resource-id/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：のdisplayName /> <D：リソース-ID /> < / D：プロップ> </ D：PROPFIND>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: 1241
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：1241
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.example.com/Coll/</D:href> <D:propstat> <D:prop> <D:displayname>Loop Demo</D:displayname> <D:resource-id> <D:href >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href> </D:resource-id> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://www.example.com/Coll/Foo</D:href> <D:propstat> <D:prop> <D:displayname>Bird Inventory</D:displayname> <D:resource-id> <D:href >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href> </D:resource-id> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://www.example.com/Coll/Bar</D:href> <D:propstat> <D:prop> <D:displayname>Loop Demo</D:displayname> <D:resource-id> <D:href >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href> </D:resource-id> </D:prop> <D:status>HTTP/1.1 208 Already Reported</D:status> </D:propstat> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/コル/ </ D：HREF> <D：propstat> <D：プロペラ> <D：のDisplayName>ループデモ</ D：表示名> <D：リソースID> <D：HREF> URN：UUID：f81d4fae-7dec -11d0-a765-00a0c91e6bf8 </ D：HREF> </ D：リソースID> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> http://www.example.com/Coll/Foo </ D：HREF> <D：propstat> <D：プロペラ> <D：のDisplayName>鳥インベントリ</ D：表示名> <D：リソースID> <D：HREF> URN：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf9 </ D：HREF> </ D：リソースID> </ D：小道具> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> http://www.example.com/Coll /バー</ D：HREF> <D：propstat> <D：プロペラ> <D：のDisplayName>ループデモ</ D：表示名> <D：リソースID> <D：HREF> URN：UUID：f81d4fae-7dec -11d0-a765-00a0c91e6bf8 </ D：HREF> </ D：リソースID> </ D：プロペラ> <D：ステータス> HTTP / 1.1 208すでに報告</ D：状態> </ D：propstat> < / D：レスポンス> </ D：multistatus>
In this example, the client isn't aware of the 208 status code introduced by this specification. As the "Depth: infinity" PROPFIND request would cause a loop condition, the whole request is rejected with a 508 status.
この例では、クライアントは、本明細書によって導入208のステータスコードを認識しません。 「深さ：無限大」とPROPFIND要求がループ状態を引き起こす、全体の要求は508のステータスで拒否されます。
>> Request:
>>リクエスト：
PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity Content-Type: application/xml; charset="utf-8" Content-Length: 125
PROPFIND /コル/ HTTP / 1.1ホスト：www.example.com深さ：無限のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：125
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:displayname/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：のdisplayName /> </ D：プロップ> </ D ：PROPFIND>
>> Response:
>>回答：
HTTP/1.1 508 Loop Detected
HTTP / 1.1 508ループ検出
The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed.
508（ループ検出）のステータスコードが「：無限深さ」の要求を処理しつつ、無限ループが発生したため、サーバが動作を終了したことを示しています。このステータスは、全体の操作が失敗したことを示しています。
If the server supports bindings, it MUST return the compliance class name "bind" as a field in the "DAV" response header (see [RFC4918], Section 10.1) from an OPTIONS request on any resource implemented by that server. A value of "bind" in the "DAV" header MUST indicate that the server supports all MUST-level requirements and REQUIRED features specified in this document.
サーバーがバインディングをサポートしている場合、それは、そのサーバによって実装任意のリソース上のOPTIONS要求から（[RFC4918]、10.1節を参照してください）「DAV」レスポンスヘッダ内のフィールドとして「バインド」準拠のクラス名を返さなければなりません。 「DAV」ヘッダ内の「バインド」の値は、サーバがすべてのMUSTレベルの要件をサポートし、REQUIREDは、この文書で指定されていますことを示す必要があります。
Clients SHOULD signal support for all MUST-level requirements and REQUIRED features by submitting a "DAV" request header containing the compliance class name "bind". In particular, the client MUST understand the 208 status code defined in Section 7.1.
クライアントは、コンプライアンス・クラス名「バインド」を含む「DAV」リクエストヘッダを提出することにより、すべてのMUSTレベルの要件と必要な機能のサポートを通知すべきです。具体的には、クライアントはセクション7.1で定義された208のステータスコードを理解する必要があります。
Locking is an optional feature of WebDAV ([RFC4918]). The base WebDAV specification and this protocol extension have been designed in parallel, making sure that all features of WebDAV can be implemented on a server that implements this protocol as well.
ロックは、WebDAV（[RFC4918]）のオプション機能です。基本WebDAV仕様と、このプロトコル拡張は、WebDAVのすべての機能は、同様に、このプロトコルを実装して、サーバー上で実施することができることを確認しながら、並行して設計されています。
Unfortunately, WebDAV uses the term "lock-root" inconsistently. It is introduced in Section 6.1 of [RFC4918], point 2, as:
残念ながら、WebDAVは「ロック・ルートを」矛盾用語を使用しています。それは次のように、[RFC4918]の6.1節、ポイント2で導入されています。
2. A resource becomes directly locked when a LOCK request to a URL of that resource creates a new lock. The "lock-root" of the new lock is that URL. If at the time of the request, the URL is not mapped to a resource, a new empty resource is created and directly locked.
そのリソースのURLにLOCK要求が新しいロックを作成するとき2.リソースを直接ロックされます。新しいロックの「ロック・ルート」は、URLです。要求時に、URLがリソースにマッピングされていない場合は、新しい空のリソースが作成され、直接ロックされています。
On the other hand, [RFC4918], Section 9.10.1 states:
一方、[RFC4918]、セクション9.10.1の状態：
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock.
既存のリソースへのLOCK要求は、すでに競合ロックでロックされていないリソースを提供Request-URIによって識別されるリソースのロックを、作成します。リクエスト-URIで識別されるリソースは、ロックのルートになります。
Servers that implement both WebDAV locking and support for multiple bindings MUST use the first interpretation: the lock-root is the URI through which the lock was created, not a resource. This URI, and potential aliases of this URI ([RFC4918], Section 5), are said to be "protected" by the lock.
複数のバインディングのためのWebDAVロックとサポートの両方を実装するサーバは最初の解釈を使用しなければならない：ロックルートはロックが作成された通過URI、ない資源です。このURI、このURI（[RFC4918]、セクション5）の潜在的なエイリアスは、ロックによって「保護」されると言われます。
As defined in the introduction to Section 7 of [RFC4918], write operations that modify the state of a locked resource require that the lock token is submitted with the request. Consistent with WebDAV, the state of the resource consists of the content ("any variant"), dead properties, lockable live properties (item 1), plus, for a collection, all its bindings (item 2). Note that this, by definition, does not depend on the Request-URI to which the write operation is applied (the locked state is a property of the resource, not its URI).
[RFC4918]のセクション7の導入部で定義されているように、ロックされたリソースの状態を変更する操作は、ロック・トークンを要求して提出されることを必要と書きます。 WebDAVのと一致して、リソースの状態は、コンテンツ（「任意の変異体」）、死者の特性、ロック可能なライブプロパティ（項目1）、プラス、コレクションのために、そのすべてのバインディング（項目2）から構成されています。これは、定義により、書き込み動作が適用されるのRequest-URI（ロック状態がリソースではなく、そのURIの特性である）に依存しないことに留意されたいです。
However, the lock-root is the URI through which the lock was requested. Thus, the protection defined in item 3 of the list does not apply to additional URIs that may be mapped to the same resource due to the existence of multiple bindings.
しかし、ロック・ルートは、ロックが要求されたURIています。したがって、リストの項目3で定義された保護は、複数のバインディングの存在に起因する同じリソースにマッピングすることができる追加のURIに適用されません。
Consider a root collection "/", containing the two collections C1 and C2, named "/CollX" and "/CollY", and a child resource R, bound to C1 as "/CollX/test" and bound to C2 as "/CollY/test":
/」としてルート「/ CollX」という名前の2つのコレクションC1とC2を含むコレクション「/」、および「/ CollY」、および「/ CollX /テスト」として、C1に結合している子リソースR、及びC2に結合を考えてみましょうCollY /テスト "：
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
Given a host name of "www.example.com", applying a depth-zero write lock to "/CollX/test" will lock the resource R, and the lock-root of this lock will be "http://www.example.com/CollX/test".
「/ CollX /テスト」に深さゼロの書き込みロックを適用し、「www.example.com」のホスト名を与えられたリソースRをロックし、このロックのロック・ルートは、「HTTPになります：// WWW。 example.com/CollX/test」。
Thus, the following operations will require that the associated lock token is submitted with the "If" request header ([RFC4918], Section 10.4):
従って、以下の動作は、関連するロックトークンが「IF」要求ヘッダ（[RFC4918]、セクション10.4）で提出されることを必要とするであろう。
o a PUT or PROPPATCH request modifying the content or lockable properties of resource R (as R is locked) -- no matter which URI is used as request target, and
O（Rがロックされているように）リソースRのコンテンツまたはロック可能なプロパティを変更しないPUTまたはPROPPATCH要求 - URIは、要求の対象として使用されるに関係なく、および
o a MOVE, REBIND, UNBIND, or DELETE request causing "/CollX/test" not to be mapped to resource R anymore (be it addressed to "/CollX" or "/CollX/test").
O MOVEは、UNBINDを再バインド、または要求原因の削除「/ CollX /試験」はもうRリソースにマッピングされるべきではない（それが対処する「/ CollX」または「/ CollX /試験」）。
The following operations will not require submission of the lock token:
以下の操作は、ロック・トークンの提出を必要としません。
o a DELETE request addressed to "/CollY" or "/CollY/test", as it does not affect the resource R, nor the lock-root,
O DELETE要求は、それが資源Rには影響を与えないように「/ CollY」または「/ CollY /テスト」を取り上げ、またロック・ルート、
o for the same reason, an UNBIND request removing the binding "test" from collection C2, or the binding "CollY" from the root collection, and
同じ理由で、コレクションC2から結合「試験」、またはルートコレクションから結合「CollY」を除去UNBIND要求のO、及び
o similarly, a MOVE or REBIND request causing "/CollY/test" not being mapped to resource R anymore.
O同様に、MOVEまたは原因要求を再バインドを「/ CollY /試験」もうRリソースにマッピングされていません。
Note that despite the lock-root being "http://www.example.com/CollX/test", an UNLOCK request can be addressed through any URI mapped to resource R, as UNLOCK operates on the resource identified by the Request-URI, not that URI (see [RFC4918], Section 9.11).
任意のURIがUNLOCKがRequest-URIで識別されるリソースで動作するように、Rリソースにマッピングを通じてロックルートがあるにもかかわらず「http://www.example.com/CollX/test」、アンロック要求に対処することができることに注意してください、URIは（セクション9.11を[RFC4918]を参照）ではないこと。
Note that the WebDAV Access Control Protocol has been designed for compatibility with systems that allow multiple URIs to map to the same resource (see [RFC3744], Section 5):
WebDAVのアクセス制御プロトコルは、複数のURIが同じリソース（[RFC3744]、セクション5を参照）にマッピングすることを可能にするシステムとの互換性のために設計されていることに注意してください。
Access control properties (especially DAV:acl and DAV:inherited-acl-set) are defined on the resource identified by the Request-URI of a PROPFIND request. A direct consequence is that if the resource is accessible via multiple URI, the value of access control properties is the same across these URI.
アクセス制御特性（特にDAV：ACLおよびDAV：継承-ACL-セット）PROPFIND要求のRequest-URIによって識別されるリソース上で定義されています。直接の結果は、リソースが複数のURIを介してアクセスされた場合、アクセス制御プロパティの値は、これらのURI全体で同じであるということです。
Furthermore, note that BIND and REBIND behave the same as MOVE with respect to the DAV:acl property (see [RFC3744], Section 7.3).
さらに、そのBINDに注意し、DAVに対して移動と同じように振る舞うREBIND：ACLプロパティ（[RFC3744]セクション7.3を参照）。
Servers that implement Workspaces ([RFC3253], Section 6) and Version-Controlled Collections ([RFC3253], Section 14) already need to implement BIND-like behavior in order to handle UPDATE and UNCHECKOUT semantics.
ワークスペース（[RFC3253]、セクション6）とバージョン管理されたコレクション（[RFC3253]、セクション14）を実装するサーバは、既にUPDATEとUNCHECKOUTセマンティクスを処理するために、BINDのような動作を実装する必要があります。
Consider a workspace "/ws1/", containing the version-controlled, checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ CollY", and a version-controlled resource R, bound to C1 as "/ws1/ CollX/test":
バージョン管理を含む、「/ / WS1」ワークスペースを考慮し、チェックアウトのコレクションC1とC2、「/ WS1 / CollX」という名前で、「/ WS1 / CollY」、およびとしてC1に結合されたバージョン管理されたリソースのR、 "/ WS1 / CollX /テスト"：
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | |
| test | | |
+---------------+ +---------------+
|
|
|
+------------------+
| Resource R |
+------------------+
Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but undoing the checkout on C1 will undo part of the MOVE request, thus restoring the binding from C1 to R, but keeping the new binding from C2 to R:
こうしてC1からRへの結合を復元するが、より新しいバインディングを維持、「/ WS1 / CollY」に「/ WS1 / CollX /テストを」移動C2にチェックが、移動要求の一部を取り消しますC1にチェックアウトを元に戻しますRへのC2：
>> Request:
>>リクエスト：
MOVE /ws1/CollX/test HTTP/1.1 Host: www.example.com Destination: /ws1/CollY/test
MOVE / WS1 / CollX /テストHTTP / 1.1ホスト：www.example.com先：/ WS1 / CollY /テスト
>> Response:
>>回答：
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
>> Request:
>>リクエスト：
CHECKIN /ws1/CollY/ HTTP/1.1 Host: www.example.com
CHECKIN / WS1 / CollY / HTTP / 1.1ホスト：www.example.com
>> Response:
>>回答：
HTTP/1.1 201 Created Cache-Control: no-cache Location: http://repo.example.com/his/17/ver/42
HTTP / 1.1 201作成されたのCache-Control：キャッシュなし所在地：http://repo.example.com/his/17/ver/42
>> Request:
>>リクエスト：
UNCHECKOUT /ws1/CollX/ HTTP/1.1 Host: www.example.com
UNCHECKOUT / WS1 / CollX / HTTP / 1.1ホスト：www.example.com
>> Response:
>>回答：
HTTP/1.1 200 OK Cache-Control: no-cache
HTTP / 1.1 200 OKのCache-Control：キャッシュなし
As a result, both C1 and C2 would have a binding to R:
結果として、C1とC2の両方がRへの結合を有するであろう。
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
The MOVE semantics defined in Section 3.15 of [RFC3253] already require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the same version history (as exposed in the DAV:version-history property). Furthermore, the UNCHECKOUT semantics (which in this case is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
[RFC3253]のセクション3.15で定義されたMOVEセマンティクスが既に（：バージョン履歴性DAVに露出されるように）「/ WS1 / CollX /試験」および「/ WS1 / CollY /テスト」は、同じバージョン履歴を有することを必要とします。また、UNCHECKOUTセマンティクス（この場合における更新と同様である、[RFC3253]のセクション14.11を参照）が必要です。
If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource.
新しいバージョンの制御部材は、既にそのバージョン履歴のバージョン管理されたリソースを持っている作業領域にある場合は、新しいバージョンの制御部材は、既存のバージョン管理されたリソースことだけ結合（即ちため、別の名前）でなければなりません。
Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the same resource R, and have identical DAV:resource-id properties.
したがって、「/ WS1 / CollX /試験」および「/ WS1 / CollY /試験」は、同じリソースRに結合すること、および同じDAVを有するであろう：リソースIDプロパティ。
This section is provided to make WebDAV implementers aware of the security implications of this protocol.
このセクションでは、このプロトコルのセキュリティへの影響のWebDAVの実装者に認識させるために提供されます。
All of the security considerations of HTTP/1.1 ([RFC2616], Section 15) and the WebDAV Distributed Authoring Protocol specification ([RFC4918], Section 20) also apply to this protocol specification. In addition, bindings introduce several new security concerns and increase the risk of some existing threats. These issues are detailed below.
HTTP / 1.1のセキュリティ上の考慮事項のすべて（[RFC2616]、セクション15）とWebDAVの分散オーサリングプロトコル仕様（[RFC4918]、セクション20）も、このプロトコル仕様に適用されます。また、バインディングは、いくつかの新しいセキュリティ上の問題を紹介し、いくつかの既存の脅威のリスクを高めます。これらの問題は以下に詳述されています。
In a context where cross-server bindings are supported, creating bindings on a trusted server may make it possible for a hostile agent to induce users to send private information to a target on a different server.
クロスサーババインディングは敵対的なエージェントが別のサーバー上のターゲットに個人情報を送信するためにユーザーを誘導することが可能になることがあり、信頼できるサーバー上のバインディングを作成し、サポートされている文脈で。
Although bind loops were already possible in HTTP 1.1, the introduction of the BIND method creates a new avenue for clients to create loops accidentally or maliciously. If the binding and its target are on the same server, the server may be able to detect BIND requests that would create loops. Servers are required to detect loops that are caused by bindings to collections during the processing of any requests with "Depth: infinity".
バインドループはHTTP 1.1で既に可能でしたが、BIND方式の導入は、クライアントが誤って、または悪意を持ってループを作成するための新しい道を作成します。結合し、そのターゲットが同じサーバー上にある場合、サーバーは、ループを作成しBIND要求を検出することができます。サーバは「：無限の深さ」を持つすべてのリクエストの処理中にコレクションにバインディングによって引き起こされるループを検出するために必要とされています。
Denial-of-service attacks were already possible by posting URIs that were intended for limited use at heavily used Web sites. The introduction of BIND creates a new avenue for similar denial-of-service attacks. If cross-server bindings are supported, clients can now create bindings at heavily used sites to target locations that were not designed for heavy usage.
DoS攻撃は、使用頻度の高いWebサイトで限定された使用のために意図されたURIを掲載することにより、既に可能でした。 BINDの導入は、類似したサービス拒否攻撃のための新しい道を作成します。クロスサーバのバインディングがサポートされている場合、クライアントは現在、大量使用のために設計されていない場所をターゲットに使用頻度の高いサイトでバインディングを作成することができます。
If the DAV:parent-set property is maintained on a resource, the owners of the bindings risk revealing private locations. The directory structures where bindings are located are available to anyone who has access to the DAV:parent-set property on the resource. Moving a binding may reveal its new location to anyone with access to DAV:parent-set on its resource.
DAV場合：親プロパティセットがリソース上で維持され、バインディングの所有者は、プライベートの場所を明らかに危険性があります。リソースの親設定プロパティ：バインディングが配置されているディレクトリ構造は、DAVへのアクセス権を持つすべてのユーザーが利用できます。バインディングを移動すると、DAVへのアクセス権を持つ人には、新しい場所を明らかにすることがあります。そのリソース上の親セット。
If the server maintains the DAV:parent-set property in response to bindings created in other administrative domains, it is exposed to hostile attempts to make it devote resources to adding bindings to the list.
サーバはDAVを維持した場合：親設定プロパティを、他の管理ドメインで作成されたバインディングに応じて、それがリストにバインディングを追加することにリソースを割く作るために敵対的な試みにさらされています。
All internationalization considerations mentioned in Section 19 of [RFC4918] also apply to this document.
[RFC4918]のセクション19で述べたすべての国際化の考慮も、この文書に適用されます。
Section 7 defines the HTTP status codes 208 (Already Reported) and 508 (Loop Detected), which have been added to the HTTP Status Code Registry.
セクション7は、HTTPステータスコードレジストリに追加されたHTTPステータスコード208（既に報告）と508（ループ検出）定義します。
This document is the collaborative product of the authors and Tyson Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited from thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and other members of the concluded WebDAV working group.
この文書では、著者とタイソン千早、ジム・デイビス、チャック・フェイとジュディスSleinのコラボレーティブな製品です。それはジム・Amsden、ピーター・カールソン、スティーブ・カーター、ケン・コアー、エリス・コーエン、ダン・コノリー、ブルースCragun、サイラスDaboo、スペンサードーキンス、マーク・デイ、ヴェルナー・ダン、ラジブDulepet、デビッド・デュラン、リサDusseault、ステファンで思慮深い議論から恩恵を受けていますEissing、ロイ・フィールディング、ヤロンGoland、ジョー・ヒルデブラント、フレッドHITT、アレックスHopmann、ジェームス・ハント、マーカス・イェーガー、クリスKaler、ManojさんKasichainula、ロフィット・クヘア、ブライアン・コーバー、ダニエル・リベルテ、スティーブ・マーティン、ラリーMasinter、ジェフMcAffer氏、アレクセイ・メルニコフ、スレンドラKoduruレディ、マックスRible、サムルビー、ブラッドリー軍曹、ニックShelness、ジョンStracke、ジョンTigue、ジョン・ターナー、ケビン・Wiggen、と結論付けたのWebDAVワーキンググループの他のメンバー。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[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/>。
[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月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]リーチ、P.、Mealling、M.、およびR. Salzの、 "汎用一意識別子（UUID）URN名前空間"、RFC 4122、2005年7月。
Index
指数
2 208 Already Reported (status code) 31, 41
2 208すでに報告（状態コード）31、41
5 508 Loop Detected (status code) 34, 41
5 508ループ検出（ステータスコード）34、41
B BIND method 21 Marshalling 22 Postconditions 23 Preconditions 22 Binding 6 Binding Integrity 6-7, 21
6結合整合6-7、21バインディングBのBIND法21のマーシャリング22事後条件23の前提条件22
C Collection 6 Condition Names DAV:bind-into-collection (pre) 22 DAV:bind-source-exists (pre) 22 DAV:binding-allowed (pre) 23 DAV:binding-deleted (post) 25, 28 DAV:can-overwrite (pre) 23, 27 DAV:cross-server-binding (pre) 23, 27
Cコレクション6条件名DAV：バインドに-コレクション（前）22 DAV：バインド・ソースが存在する（前）22 DAV：結合-許可（前）23 DAV：-削除バインディング（ポスト）25、28 DAV：CAN -overwrite（予備）23、27 DAV：クロスサーバ結合（予備）23、27
DAV:cycle-allowed (pre) 23, 27
DAV:lock-deleted (post) 25, 28
DAV:locked-overwrite-allowed (pre) 23
DAV:locked-source-collection-update-allowed (pre) 28
DAV:locked-update-allowed (pre) 23, 25, 27
DAV:name-allowed (pre) 23, 27
DAV:new-binding (post) 23, 28
DAV:protected-source-url-deletion-allowed (pre) 28
DAV:protected-url-deletion-allowed (pre) 25
DAV:protected-url-modification-allowed (pre) 27
DAV:rebind-into-collection (pre) 27
DAV:rebind-source-exists (pre) 27
DAV:unbind-from-collection (pre) 25
DAV:unbind-source-exists (pre) 25
D DAV header compliance class 'bind' 34 DAV:bind-into-collection precondition 22 DAV:bind-source-exists precondition 22 DAV:binding-allowed precondition 23 DAV:binding-deleted postcondition 25, 28 DAV:can-overwrite precondition 23, 27 DAV:cross-server-binding precondition 23, 27 DAV:cycle-allowed precondition 23, 27 DAV:lock-deleted postcondition 25, 28 DAV:locked-overwrite-allowed precondition 23 DAV:locked-source-collection-update-allowed precondition 28 DAV:locked-update-allowed precondition 23, 25, 27 DAV:name-allowed precondition 23, 27 DAV:new-binding postcondition 23, 28 DAV:parent-set property 20 DAV:protected-source-url-deletion-allowed precondition 28 DAV:protected-url-deletion-allowed precondition 25 DAV:protected-url-modification-allowed precondition 27 DAV:rebind-into-collection precondition 27 DAV:rebind-source-exists precondition 27 DAV:resource-id property 19 DAV:unbind-from-collection precondition 25 DAV:unbind-source-exists precondition 25
D DAVヘッダコンプライアンスクラス 'バインド' 34 DAV：バインドに収集前提条件22 DAV：結合せ前提条件23 DAV：結合削除事後25、28 DAV：CAN-上書き前提条件23前提条件22 DAVをバインドソースは、存在します、27 DAV：クロスサーバ結合前提23、27 DAV：サイクル許容前提23、27 DAV：ロック削除事後25、28 DAV：ロック上書き許容前提23 DAV：ロック・ソース・コレクションupdate-許可の前提条件28 DAV：ロック・更新許可の前提条件23、25、27 DAV：名前、許可の前提条件23、27 DAV：新結合事後条件23、28 DAV：親設定プロパティ20 DAV：保護された-source-urlに、削除-allowed前提条件28 DAV：保護されたURL-削除-許可の前提条件25 DAV：保護されたURL - 修正 - 許可の前提条件27 DAV：再バインド-に収集前提条件27 DAV：リソース-idプロパティ：前提条件27 DAVを再バインド・ソースは、存在します19 DAV：アンバインド-から収集前提25 DAV：前提条件25をアンバインド・ソースは、存在
I Internal Member URI 6
I内部メンバーURI 6
L Locking 35
L 35のロック
M Methods BIND 21 REBIND 26 UNBIND 24
M方法BIND 21 REBIND 26 UNBIND 24
P Path Segment 5 Properties DAV:parent-set 20 DAV:resource-id 19
Pパスセグメント5プロパティDAV：親セット20 DAV：リソース-ID 19
R REBIND method 26 Marshalling 26 Postconditions 28 Preconditions 27
R再バインド方法26マーシャリング26の事後条件28前提条件27
S Status Codes 208 Already Reported 31, 41 508 Loop Detected 34, 41
208はすでに31、41 508ループ34、41を検出し報告Sステータスコード
U UNBIND method 24 Marshalling 24 Postconditions 25 Preconditions 25 URI Mapping 5
U UNBIND方法24マーシャリング24の事後条件25の前提25 URIマッピング5
Authors' Addresses
著者のアドレス
Geoffrey Clemm IBM 550 King Street Littleton, MA 01460
ジェフリー・Clemm IBM 550キングストリートリトルトン、MA 01460
EMail: geoffrey.clemm@us.ibm.com
メールアドレス：geoffrey.clemm@us.ibm.com
Jason Crawford IBM Research P.O. Box 704 Yorktown Heights, NY 10598
ジェイソン・クロフォードIBMリサーチ私書箱ボックス704ヨークタウンハイツ、NY 10598
EMail: ccjason@us.ibm.com
メールアドレス：ccjason@us.ibm.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
ジュリアンF. Reschke（エディタ）greenbytes社Hafenweg 16ミュンスター、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
メールアドレス：julian.reschke@greenbytes.de
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064
ジム・ホワイトヘッドUCサンタクルス、コンピュータサイエンス学科1156ハイストリートサンタクルス、CA 95064
EMail: ejw@cse.ucsc.edu
メールアドレス：ejw@cse.ucsc.edu