[要約] RFC 4918は、HTTPプロトコルを拡張し、ウェブ上での共同編集やファイル管理を可能にする「WebDAV」の仕様を統合・整理した決定版の文書です。プロパティ管理、コレクション（フォルダ）操作、および排他制御（ロッキング）などの基本機能を規定し、異なるベンダーのクライアントとサーバー間での高度なファイル操作の相互運用性を保証します（RFC 2518の後継）。
Network Working Group L. Dusseault, Ed.
Request for Comments: 4918 CommerceNet
Obsoletes: 2518 June 2007
Category: Standards Track
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Web Distributed Authoring and Versioning (WebDAV) のための HTTP 拡張
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
Web分散オーサリングおよびバージョン化（WebDAV）は、リソースプロパティの管理、URLネームスペース操作、およびリソースロック（衝突回避の管理と管理のためのHTTP/1.1のメソッド、ヘッダー、コンテンツタイプのセットで構成されています。）。
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.
RFC 2518は1999年2月に公開され、この仕様は廃止されたRFC 2518で、主に相互運用性の経験が原因で軽微な改訂があります。
Table of Contents
目次
1. Introduction ....................................................7
2. Notational Conventions ..........................................8
3. Terminology .....................................................8
4. Data Model for Resource Properties .............................10
4.1. The Resource Property Model ...............................10
4.2. Properties and HTTP Headers ...............................10
4.3. Property Values ...........................................10
4.3.1. Example - Property with Mixed Content ..............12
4.4. Property Names ............................................14
4.5. Source Resources and Output Resources .....................14
5. Collections of Web Resources ...................................14
5.1. HTTP URL Namespace Model ..................................15
5.2. Collection Resources ......................................15
6. Locking ........................................................17
6.1. Lock Model ................................................18
6.2. Exclusive vs. Shared Locks ................................19
6.3. Required Support ..........................................20
6.4. Lock Creator and Privileges ...............................20
6.5. Lock Tokens ...............................................21
6.6. Lock Timeout ..............................................21
6.7. Lock Capability Discovery .................................22
6.8. Active Lock Discovery .....................................22
7. Write Lock .....................................................23
7.1. Write Locks and Properties ................................24
7.2. Avoiding Lost Updates .....................................24
7.3. Write Locks and Unmapped URLs .............................25
7.4. Write Locks and Collections ...............................26
7.5. Write Locks and the If Request Header .....................28
7.5.1. Example - Write Lock and COPY ......................28
7.5.2. Example - Deleting a Member of a Locked
Collection .........................................29
7.6. Write Locks and COPY/MOVE .................................30
7.7. Refreshing Write Locks ....................................30
8. General Request and Response Handling ..........................31
8.1. Precedence in Error Handling ..............................31
8.2. Use of XML ................................................31
8.3. URL Handling ..............................................32
8.3.1. Example - Correct URL Handling .....................32
8.4. Required Bodies in Requests ...............................33
8.5. HTTP Headers for Use in WebDAV ............................33
8.6. ETag ......................................................33
8.7. Including Error Response Bodies ...........................34
8.8. Impact of Namespace Operations on Cache Validators ........34
9. HTTP Methods for Distributed Authoring .........................35
9.1. PROPFIND Method ...........................................35
9.1.1. PROPFIND Status Codes ..............................37
9.1.2. Status Codes for Use in 'propstat' Element .........37
9.1.3. Example - Retrieving Named Properties ..............38
9.1.4. Example - Using 'propname' to Retrieve All
Property Names .....................................39
9.1.5. Example - Using So-called 'allprop' ................41
9.1.6. Example - Using 'allprop' with 'include' ...........43
9.2. PROPPATCH Method ..........................................44
9.2.1. Status Codes for Use in 'propstat' Element .........44
9.2.2. Example - PROPPATCH ................................45
9.3. MKCOL Method ..............................................46
9.3.1. MKCOL Status Codes .................................47
9.3.2. Example - MKCOL ....................................47
9.4. GET, HEAD for Collections .................................48
9.5. POST for Collections ......................................48
9.6. DELETE Requirements .......................................48
9.6.1. DELETE for Collections .............................49
9.6.2. Example - DELETE ...................................49
9.7. PUT Requirements ..........................................50
9.7.1. PUT for Non-Collection Resources ...................50
9.7.2. PUT for Collections ................................51
9.8. COPY Method ...............................................51
9.8.1. COPY for Non-collection Resources ..................51
9.8.2. COPY for Properties ................................52
9.8.3. COPY for Collections ...............................52
9.8.4. COPY and Overwriting Destination Resources .........53
9.8.5. Status Codes .......................................54
9.8.6. Example - COPY with Overwrite ......................55
9.8.7. Example - COPY with No Overwrite ...................55
9.8.8. Example - COPY of a Collection .....................56
9.9. MOVE Method ...............................................56
9.9.1. MOVE for Properties ................................57
9.9.2. MOVE for Collections ...............................57
9.9.3. MOVE and the Overwrite Header ......................58
9.9.4. Status Codes .......................................59
9.9.5. Example - MOVE of a Non-Collection .................60
9.9.6. Example - MOVE of a Collection .....................60
9.10. LOCK Method ..............................................61
9.10.1. Creating a Lock on an Existing Resource ...........61
9.10.2. Refreshing Locks ..................................62
9.10.3. Depth and Locking .................................62
9.10.4. Locking Unmapped URLs .............................63
9.10.5. Lock Compatibility Table ..........................63
9.10.6. LOCK Responses ....................................63
9.10.7. Example - Simple Lock Request .....................64
9.10.8. Example - Refreshing a Write Lock .................65
9.10.9. Example - Multi-Resource Lock Request .............66
9.11. UNLOCK Method ............................................68
9.11.1. Status Codes ......................................68
9.11.2. Example - UNLOCK ..................................69
10. HTTP Headers for Distributed Authoring ........................69
10.1. DAV Header ...............................................69
10.2. Depth Header .............................................70
10.3. Destination Header .......................................71
10.4. If Header ................................................72
10.4.1. Purpose ...........................................72
10.4.2. Syntax ............................................72
10.4.3. List Evaluation ...................................73
10.4.4. Matching State Tokens and ETags ...................74
10.4.5. If Header and Non-DAV-Aware Proxies ...............74
10.4.6. Example - No-tag Production .......................75
10.4.7. Example - Using "Not" with No-tag Production ......75
10.4.8. Example - Causing a Condition to Always
Evaluate to True ..................................75
10.4.9. Example - Tagged List If Header in COPY ...........76
10.4.10. Example - Matching Lock Tokens with
Collection Locks .................................76
10.4.11. Example - Matching ETags on Unmapped URLs ........76
10.5. Lock-Token Header ........................................77
10.6. Overwrite Header .........................................77
10.7. Timeout Request Header ...................................78
11. Status Code Extensions to HTTP/1.1 ............................78
11.1. 207 Multi-Status .........................................78
11.2. 422 Unprocessable Entity .................................78
11.3. 423 Locked ...............................................78
11.4. 424 Failed Dependency ....................................79
11.5. 507 Insufficient Storage .................................79
12. Use of HTTP Status Codes ......................................79
12.1. 412 Precondition Failed ..................................79
12.2. 414 Request-URI Too Long .................................79
13. Multi-Status Response .........................................80
13.1. Response Headers .........................................80
13.2. Handling Redirected Child Resources ......................81
13.3. Internal Status Codes ....................................81
14. XML Element Definitions .......................................81
14.1. activelock XML Element ...................................81
14.2. allprop XML Element ......................................82
14.3. collection XML Element ...................................82
14.4. depth XML Element ........................................82
14.5. error XML Element ........................................82
14.6. exclusive XML Element ....................................83
14.7. href XML Element .........................................83
14.8. include XML Element ......................................83
14.9. location XML Element .....................................83
14.10. lockentry XML Element ...................................84
14.11. lockinfo XML Element ....................................84
14.12. lockroot XML Element ....................................84
14.13. lockscope XML Element ...................................84
14.14. locktoken XML Element ...................................85
14.15. locktype XML Element ....................................85
14.16. multistatus XML Element .................................85
14.17. owner XML Element .......................................85
14.18. prop XML Element ........................................86
14.19. propertyupdate XML Element ..............................86
14.20. propfind XML Element ....................................86
14.21. propname XML Element ....................................87
14.22. propstat XML Element ....................................87
14.23. remove XML Element ......................................87
14.24. response XML Element ....................................88
14.25. responsedescription XML Element .........................88
14.26. set XML Element .........................................88
14.27. shared XML Element ......................................89
14.28. status XML Element ......................................89
14.29. timeout XML Element .....................................89
14.30. write XML Element .......................................89
15. DAV Properties ................................................90
16. Precondition/Postcondition XML Elements .......................98
17. XML Extensibility in DAV .....................................101
18. DAV Compliance Classes .......................................103
18.1. Class 1 .................................................103
18.2. Class 2 .................................................103
18.3. Class 3 .................................................103
19. Internationalization Considerations ..........................104
20. Security Considerations ......................................105
20.1. Authentication of Clients ...............................105
20.2. Denial of Service .......................................106
20.3. Security through Obscurity ..............................106
20.4. Privacy Issues Connected to Locks .......................106
20.5. Privacy Issues Connected to Properties ..................107
20.6. Implications of XML Entities ............................107
20.7. Risks Connected with Lock Tokens ........................108
20.8. Hosting Malicious Content ...............................108
21. IANA Considerations ..........................................109
21.1. New URI Schemes .........................................109
21.2. XML Namespaces ..........................................109
21.3. Message Header Fields ...................................109
21.3.1. DAV ..............................................109
21.3.2. Depth ............................................110
21.3.3. Destination ......................................110
21.3.4. If ...............................................110
21.3.5. Lock-Token .......................................110
21.3.6. Overwrite ........................................111
21.3.7. Timeout ..........................................111
21.4. HTTP Status Codes .......................................111
22. Acknowledgements .............................................112
23. Contributors to This Specification ...........................113
24. Authors of RFC 2518 ..........................................113
25. References ...................................................114
25.1. Normative References.....................................114
25.2. Informative References ..................................115
Appendix A. Notes on Processing XML Elements ....................117
A.1. Notes on Empty XML Elements ..............................117
A.2. Notes on Illegal XML Processing ..........................117
A.3. Example - XML Syntax Error ...............................117
A.4. Example - Unexpected XML Element .........................118
Appendix B. Notes on HTTP Client Compatibility ...................119
Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
Appendix D. Lock-null Resources ..................................120
D.1. Guidance for Clients Using LOCK to Create Resources ......121
Appendix E. Guidance for Clients Desiring to Authenticate ........121
Appendix F. Summary of Changes from RFC 2518 .....................123
F.1. Changes for Both Client and Server Implementations .......123
F.2. Changes for Server Implementations .......................125
F.3. Other Changes ............................................126
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote Web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for:
このドキュメントでは、クライアントがリモートWebコンテンツオーサリング操作を実行できるようにするHTTP/1.1プロトコルの拡張機能について説明します。この拡張機能は、次の操作を提供するメソッド、ヘッダー、リクエストエンティティボディフォーマット、および応答エンティティボディフォーマットのコヒーレントセットを提供します。
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc.
プロパティ：著者、作成日など、Webページに関する情報を作成、削除、照会する機能。
Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system).
コレクション：ドキュメントのセットを作成し、階層メンバーシップリストを取得する機能（ファイルシステムのディレクトリリストなど）。
Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author, then another, writes changes without merging the other author's changes.
ロック：複数の人がドキュメントに同時に作業するのを防ぐ能力。これにより、「Lost Updateの問題」が防止されます。この著者は、最初の1人の著者として変更され、次に別の著者が他の著者の変更を統合せずに変更を書き込みます。
Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources.
名前空間操作：サーバーにWebリソースをコピーして移動するよう指示する機能、マッピングをURLからリソースに変更する操作。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作の要件と根拠は、コンパニオンドキュメント「World Wide Webの分散オーサリングおよびバージョンプロトコルの要件」[RFC2291]に記載されています。
This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253].
このドキュメントでは、[RFC2291]で提案されたバージョン操作は指定されていません。その作業は、「WebDAVへの拡張機能」[RFC3253] [rfc3253]という別のドキュメントで行われました。
The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general, and write locks (Section 7) specifically.
以下のセクションでは、さまざまなWebDAV抽象化の詳細な紹介を示します。リソースプロパティ（セクション4）、リソースのコレクション（セクション5）、ロック（セクション6）一般的に、具体的に書き込みロック（セクション7）。
These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8.
これらの抽象化は、WebDAV固有のHTTPメソッド（セクション9）とWebDAVメソッドで使用される追加のHTTPヘッダー（セクション10）によって操作されます。WebDAVのHTTP要求と応答を処理するための一般的な考慮事項は、セクション8にあります。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies.
HTTP/1.1によって提供されるステータスコードは、WebDAVメソッドで遭遇するほとんどのエラー条件を記述するのに十分ですが、既存のカテゴリにきちんと該当しないエラーがいくつかあります。この仕様では、WebDAVメソッド用に開発された追加のステータスコード（セクション11）を定義し、WebDAVで使用されている既存のHTTPステータスコード（セクション12）について説明します。一部のWebDAVメソッドは多くのリソースで動作する可能性があるため、複数のリソースのステータス情報を返すためにマルチステータス応答（セクション13）が導入されています。最後に、このバージョンのWebDAVは、エラー応答ボディで前提条件と事後条件（セクション16）XML要素を導入します。
WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17).
WebDAVは、プロパティ名といくつかの値にXML（[Rec-XML]）を使用し、XMLを使用して複雑なリクエストと応答をマーシャルします。この仕様には、マーシャリングで使用されるすべてのプロパティ（セクション15）および他のすべてのXML要素（セクション14）のDTDおよびテキスト定義が含まれています。WebDAVには、WebDAV XMLの拡張に関するいくつかの特別なルールが後方互換性のある方法でマーシャリングされています（セクション17）。
Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 18), on internationalization support (Section 19), and on security (Section 20).
仕様の仕上げは、この仕様（セクション18）、国際化のサポート（セクション19）、およびセキュリティ（セクション20）に準拠することの意味に関するセクションです。
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616], including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs.
このドキュメントでは、HTTP/1.1プロトコルの一連の拡張機能について説明されているため、ここでプロトコル要素を説明するために使用される拡張BNFは、[RFC2616]のセクション2.1で説明されているものとまったく同じです。この拡張されたBNFは、[RFC2616]のセクション2.2で提供される基本的な生産ルールを使用しているため、これらのルールもこのドキュメントにも適用されます。これは、他のRFCで使用される標準のBNF構文ではありません。
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"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.
自然言語では、「dav：」の「creationdate」プロパティのようなプロパティは、XMLネームスペースが「dav：creationdate」と呼ばれることもあります。
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC3986].
URI/URL-それぞれ均一なリソース識別子と均一なリソースロケーター。これらの用語（およびそれらの区別）は[RFC3986]で定義されています。
URI/URL Mapping - A relation between an absolute URI and a resource. 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 protocol requests to the resource using the URI.
URI/URLマッピング - 絶対URIとリソースの関係。リソースは、ネットワークを取得できないアイテムと、その場合のアイテムを表すことができるため、リソースがゼロ、1つ、または多くのURIマッピングを持つことができます。リソースを「HTTP」スキームにマッピングすると、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で定義されています。
Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements defined in Section 5.
コレクション - 非公式には、児童資源への参照のコンテナとしても機能するリソース。正式には、パスセグメントとリソースの間に一連のマッピングを含み、セクション5で定義されている要件を満たすリソース。
Internal Member (of a Collection) - Informally, a child resource of a collection. Formally, a resource referenced by a path segment mapping contained in the collection.
（コレクションの）内部メンバー - 非公式に、コレクションの子リソース。正式には、コレクションに含まれるパスセグメントマッピングによって参照されるリソース。
Internal Member URL (of a Collection) - A URL of an internal member, consisting of the URL of the collection (including trailing slash) plus the path segment identifying the internal member.
内部メンバーURL（コレクションの） - コレクションのURL（トレーリングスラッシュを含む）と内部メンバーを識別するパスセグメントで構成される内部メンバーのURL。
Member (of a Collection) - Informally, a "descendant" of a collection. Formally, an internal member of the collection, or, recursively, a member of an internal member.
メンバー（コレクションの） - 非公式に、コレクションの「子孫」。正式には、コレクションの内部メンバー、または再帰的に内部メンバーのメンバーです。
Member URL (of a Collection) - A URL that is either an internal member URL of the collection itself, or is an internal member URL of a member of that collection.
メンバーURL（コレクションの） - コレクション自体の内部メンバーURLである、またはそのコレクションのメンバーの内部メンバーURLであるURL。
Property - A name/value pair that contains descriptive information about a resource.
プロパティ - リソースに関する記述情報を含む名前/値ペア。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server.
ライブプロパティ - セマンティクスと構文がサーバーによって実施されるプロパティ。たとえば、Live Property DAV：getContentLengthの値は、サーバーによって自動的に計算されたGETリクエストによって返されるエンティティの長さです。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
Deadプロパティ - サーバーによってセマンティクスと構文が施行されていないプロパティ。サーバーは、死んだプロパティの値のみを記録します。クライアントは、死んだプロパティの構文とセマンティクスの一貫性を維持する責任があります。
Principal - A distinct human or computational actor that initiates access to network resources.
プリンシパル - ネットワークリソースへのアクセスを開始する明確な人間または計算アクター。
State Token - A URI that represents a state of a resource. Lock tokens are the only state tokens defined in this specification.
状態トークン - リソースの状態を表すURI。ロックトークンは、この仕様で定義されている唯一の状態トークンです。
Properties are pieces of data that describe the state of a resource. Properties are data about data.
プロパティは、リソースの状態を記述するデータの部分です。プロパティはデータに関するデータです。
Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.
プロパティは、リソースの効率的な発見と管理を提供するために、分散オーサリング環境で使用されます。たとえば、「サブジェクト」プロパティは、被験者によるすべてのリソースのインデックス作成を可能にする場合があり、「著者」プロパティは、著者がどの文書を書いたかを発見することを可能にする場合があります。
The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.
DAVプロパティモデルは、名前/値のペアで構成されています。プロパティの名前は、プロパティの構文とセマンティクスを識別し、その構文とセマンティクスを参照するアドレスを提供します。
There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
プロパティには、"live"と"dead"の2種類があります。live propertyでは、サーバーがその構文と意味を強制します。live propertyには、a) プロパティ値をサーバーが保護および維持する場合と、b) プロパティ値をクライアントが維持する一方で、送信された値の構文をサーバーが検査する場合があります。あるlive propertyのすべてのインスタンスは、そのプロパティ名に対応する定義に準拠しなければなりません (MUST)。dead propertyでは、クライアントがその構文と意味を強制し、サーバーはプロパティ値をそのまま記録するだけです。
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments, a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus, a mechanism is needed that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
HTTPメッセージヘッダーには、限られた意味で、プロパティがすでに存在しています。ただし、分散したオーサリング環境では、リソースの状態を記述するために比較的多数のプロパティが必要であり、HTTPヘッダーを通じてそれらをすべて設定/返信することは非効率的です。したがって、プリンシパルが関心のある一連のプロパティを識別し、それらのプロパティのみを設定または取得できるようにするメカニズムが必要です。
The value of a property is always a (well-formed) XML fragment.
プロパティの値は、常に（よく形成された）XMLフラグメントです。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.
XMLは、柔軟で自己記述的な構造化データ形式であり、豊富なスキーマ定義と複数の文字セットをサポートするため採用されています。XMLの自己記述性により、任意のプロパティ値へ要素を追加して拡張できます。クライアントは、拡張に遭遇しても元のスキーマで規定されたデータを引き続き利用でき、理解できない要素を無視しなければならない (MUST) ため、動作しなくなることはありません。
XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.
XMLは複数の文字セットをサポートしているため、人間が読めるプロパティをユーザーになじみのある文字セットで符号化し、読むことができます。また、"xml:lang"属性によって複数の自然言語をサポートし、同じ文字セットを複数の自然言語で使用する場合にも対応できます。xml:langのスコープは再帰的であるため、プロパティ名要素を含む要素に指定されたxml:lang属性は、より内側のスコープの属性で上書きされない限り、そのプロパティ値に適用されます。プロパティが持つ値は1つの言語による1つの値だけです（言語は未定義のままでもよい (MAY)）。異なる言語による複数の値や、複数の言語による1つの値を持つことはありません。
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
プロパティは、「プロパティ名要素」と呼ばれるプロパティ名で構成されるXML要素で常に表されます。最も単純な例は空のプロパティで、存在しないプロパティとは異なります。
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:
プロパティ値は、プロパティ名要素の内部に現れます。この値には、テキストのみの内容と混合内容の両方を含む、整形式の任意のXML内容を使用できます。サーバーは、dead propertyを格納および転送する際に、次のXML Information Item（[REC-XML-INFOSET]の用語）を保持しなければなりません (MUST)：
For the property name Element Information Item itself:
プロパティ名要素情報アイテム自体の場合：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes] named "xml:lang" or any such attribute in scope
[属性]「xml：lang」またはそのような属性の範囲の名前
[children] of type element or character
[子供]タイプの要素またはキャラクターの
On all Element Information Items in the property value:
プロパティ値のすべての要素情報項目について：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes]
[属性]
[children] of type element or character
[子供]タイプの要素またはキャラクターの
On Attribute Information Items in the property value:
プロパティ値の属性情報項目について：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[normalized value]
[正規化された値]
On Character Information Items in the property value:
プロパティ値の文字情報項目について：
[character code]
[文字コード]
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
一部のXML語彙（XPathやXML Schemaなど）では接頭辞が使用されるため、サーバーは、値に含まれる各Information Itemについて次の情報を保持すべきです (SHOULD)：
[prefix]
[プレフィックス]
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
サーバーは、上記に列挙されていないXML Infoset属性を保持してもよい (MAY) ですが、クライアントはそれらが保持されることに依存してはなりません (MUST NOT)。別途定義されていない限り、上記の規則はデフォルトでlive propertyにも適用されます。
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
サーバーは、XML属性xml:spaceが存在する場合にはこれを無視し、空白の処理を変更するために使用してはなりません (MUST)。プロパティ値に含まれる空白は意味を持ちます。
Consider a dead property 'author' created by the client as follows:
クライアントが作成した「著者」を次のように考えてみましょう。
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
When this property is requested, a server might return:
このプロパティが要求されると、サーバーが返される場合があります。
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
</D:prop>
Note in this example:
この例に注意してください：
o The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
o プロパティ名自体の[プレフィックス]は保存されておらず、有意ではありませんが、他のすべての[プレフィックス]値は保存されています。
o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
o 属性値は、単一の引用符の代わりに二重引用符で書き直されています（引用符は重要ではありません）、属性順序は保持されていません。
o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
o XML：Lang属性はプロパティ名要素自体に返されました（プロパティが設定されたときは範囲でしたが、応答の正確な位置は、範囲内にある限り有意とは見なされません）、
o whitespace between tags has been preserved everywhere (whitespace between attributes not so),
o タグ間のホワイトスペースはどこにでも保存されています（属性間ではない属性間の白い空間）、
o CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
o CDATAのカプセル化は、キャラクターの脱出に置き換えられました（逆も合法です）、
o the comment item was stripped (as would have been a processing instruction item).
o コメント項目は剥がされました（処理命令項目であったように）。
Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.
実装注：クライアントがXMLコンテンツが文字ごとに保存された文字（属性の順序付けや引用スタイルなど）を要求する場合がある場合、シナリオの編集などのケースがあります。この場合、クライアントは、XML解析で特別な意味を持つすべてのキャラクターを逃れることにより、テキストのみのプロパティ値を使用することを検討する必要があります。
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.
プロパティ名は、プロパティの構文とセマンティクスに関する情報を提供するスキーマに関連付けられた普遍的に一意の識別子です。
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
プロパティの名前は普遍的に一意であるため、クライアントは、問題のリソースでそのプロパティが「ライブ」である限り、複数のリソース、同じ、および異なるサーバーにわたる特定のプロパティの一貫した動作に依存できます。生きている財産はその定義に忠実です。
The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
uris（[rfc3986]）に基づいたXMLネームスペースメカニズムは、名前空間の衝突を防ぎ、さまざまな程度の管理制御を提供するため、プロパティの名前を付けるために使用されます。
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.
プロパティネームスペースはフラットです。つまり、プロパティの階層は明示的に認識されていません。したがって、プロパティAとプロパティA/Bがリソースに存在する場合、2つのプロパティ間の関係の認識はありません。最終的には、階層特性に関連する問題に対処する別の仕様が生成されることが予想されます。
Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
最後に、単一のリソースで同じプロパティを2回定義することはできません。これにより、リソースのプロパティネームスペースに衝突が発生するためです。
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
一部のHTTPリソースは、サーバーによって動的に生成されます。これらのリソースについては、おそらくそのリソースがどのように生成されるかを管理するどこかにソースコードが存在すると思われます。ソースファイルとHTTPリソースの出力との関係は、1対1、多く、多く、または多くの関係である場合があります。HTTPには、リソースが動的であるかどうかを判断するメカニズムはありません。ソースファイルがどこに存在するか、どのように作成するかはもちろんです。この問題は有用に解決されますが、相互運用可能なWebDAV実装は、静的リソースのみを扱うことにより、実際にこの問題を解決することなく広く展開されています。したがって、ソースと出力の問題はこの仕様では解決されず、別のドキュメントに延期されています。
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
このセクションでは、Webリソースの種類、コレクションの説明を提供し、HTTP URLネームスペースとHTTPメソッドとの相互作用について説明します。コレクションリソースの目的は、サーバーの名前空間内でコレクションのようなオブジェクト（ファイルシステムディレクトリなど）をモデル化することです。
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.
DAV準拠のすべてのリソースは、ここで規定するHTTP URL名前空間モデルをサポートしなければなりません (MUST)。
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
HTTP URLネームスペースは、階層が「/」文字で区切られている階層名空間です。
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...)
HTTP URLネームスペースは、次の条件を満たしている場合に一貫していると言われています。HTTP階層内のすべてのURLに、そのURLが内部メンバーURLとして含まれるコレクションが存在します。検討中の名前空間のルートまたはトップレベルのコレクションは、前のルールから免除されます。検討中の名前空間のトップレベルのコレクションは、必ずしも絶対パス '/'によって識別されるコレクションではありません - 1つ以上のパスセグメント（例：/servlets/webdav/...）によって識別される場合があります。
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
HTTP/1.1もWebDAVも、HTTP URLネームスペース全体が一貫している必要はありません。WebDAV互換リソースには親コレクションがない場合があります。ただし、特定のWebDAVメソッドは、名前空間の矛盾を引き起こす結果を生成することを禁止されています。
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
[RFC2616]および[RFC3986]で暗黙に示されているように、collectionリソースを含む任意のリソースは、複数のURIで識別してもよい (MAY)。たとえば、1つのリソースを複数のHTTP URLで識別できます。
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
収集リソースは、コンテナとしても機能するという点で、他のリソースとは異なります。一部のHTTPメソッドはコレクションにのみ適用されますが、一部はコレクションで定義されているコンテナ内のリソースの一部またはすべてに適用されます。メソッドの範囲が明確でない場合、クライアントは適用する深さを指定できます。深さは、ゼロレベル（コレクションのみ）、1つのレベル（コレクションと直接含まれるリソース）、または無限レベル（コレクションとすべてが再帰的に含まれているリソースを含む）のいずれかです。
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
collectionの状態は、少なくともパスセグメントとリソースとのマッピングの集合、およびcollection自体のプロパティの集合から構成されます。本書では、Bに対応するパスセグメントのマッピングがAに含まれる場合、リソースBはcollectionリソースAに含まれるといいます。collectionは、あるパスセグメントについて最大1つのマッピングだけを含まなければなりません (MUST)。すなわち、同じパスセグメントを複数のリソースへマッピングすることは不正です。
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
collectionに定義されたプロパティは、非collectionリソースのプロパティとまったく同様に動作します。collectionは、GETで返されるentity bodyなどの追加状態を持ってもよい (MAY)。
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
それぞれURL "U"および"V"で識別され、"V"が"U/SEGMENT"に等しいWebDAV準拠リソースAおよびBについて、Aは"SEGMENT"からBへのマッピングを含むcollectionでなければなりません (MUST)。したがって、URL "http://example.com/bar/blah"のリソースBがWebDAV準拠であり、URL "http://example.com/bar/"のリソースAもWebDAV準拠である場合、リソースAはcollectionである必要があり、"blah"からBへのマッピングをちょうど1つ含む必要があります。
Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.
一般に、マッピングは単一のセグメントとリソースで構成されていますが、一般に、マッピングはセグメントのセットとリソースで構成されます。これにより、サーバーは一連のセグメントを同等のものとして扱うことができます（つまり、すべてのセグメントが同じリソースにマッピングされるか、セグメントのいずれもリソースにマッピングされません）。たとえば、セグメントでケース折りたたみを実行するサーバーは、セグメント「AB」、「AB」、「AB」、および「AB」を同等のものとして扱います。クライアントは、これらのセグメントのいずれかを使用してリソースを識別できます。Propfind Resultは、これらの同等のセグメントのいずれかを選択してマッピングを識別するため、マッピングごとに1つのPropfind Response要素があり、マッピングの1つのペグメントは1つではありません。
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
collectionリソースは、HTTP URL名前空間階層内のWebDAV非準拠リソースへのマッピングを持ってもよい (MAY) ですが、持つことは要求されません。たとえば、URL "http://example.com/bar/blah"のリソースXがWebDAV非準拠で、"URL http://example.com/bar/"のリソースAがWebDAV collectionを識別する場合、Aは"blah"からXへのマッピングを持つ場合も持たない場合もあります。
If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV-compliant resource is not required to be a collection.
WebDAVに準拠したリソースにHTTP URLネームスペース階層にWebDAV準拠の内部メンバーがない場合、WebDAVに準拠したリソースはコレクションである必要はありません。
There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case, it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general, clients SHOULD use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response. Clients will find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection.
末尾のスラッシュを付けずにcollection名が参照された場合、サーバーは末尾のスラッシュがあるものとしてリクエストを処理してもよい (MAY)、という慣例があります。この場合、レスポンスでは、"/"で終わるURLを指すContent-Locationヘッダーを返すべきです (SHOULD)。たとえば、クライアントがhttp://example.com/blah（末尾のスラッシュなし）に対してメソッドを呼び出した場合、サーバーはhttp://example.com/blah/（末尾のスラッシュあり）に対して操作が呼び出されたものとして応答でき、値がhttp://example.com/blah/のContent-Locationヘッダーを返すことが望まれます。サーバーがcollectionを参照するURLを生成する場合は常に、末尾のスラッシュを含めるべきです (SHOULD)。一般に、クライアントはcollection名を末尾のスラッシュ付き形式で使用すべきです (SHOULD)。この形式を使用しないクライアントは、リダイレクトレスポンスを受け取る可能性に備える必要があります。リソースがcollectionかどうかを判定するには、URLよりもDAV:resourcetypeプロパティの方が信頼できます。
Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
クライアントは、WebDAVリソースがWebDAV非準拠リソースの内部に含まれる場合をサポートできなければなりません (MUST)。たとえば、"http://example.com/servlet/dav/collection"からのOPTIONSレスポンスがWebDAV対応を示していても、クライアントは"http://example.com/servlet/dav/"またはその親が必ずWebDAV collectionであるとは仮定できません。
A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link"; thus, the URL "/col/link" would indeed be mapped. Similarly, a dynamically-generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/".
マッピングされたURLが親コレクションのメンバーとして表示されない典型的なシナリオは、サーバーが非WebDAVリソースにリンクまたはリダイレクトを許可する場合です。たとえば、「/col/link」は「/col/」のメンバーとして表示されない場合がありますが、サーバーは「/col/link」へのgetリクエストに302ステータスで応答します。したがって、URL「/col/link」が実際にマッピングされます。同様に、動的に生成されたページには、 "/col/index.html"からのURLマッピングがある可能性があるため、このリソースは200 OKでgetリクエストに応答しますが、「/col/」のメンバーとして表示されない場合があります。
Some mappings to even WebDAV-compliant resources might not appear in the parent collection. An example for this case are servers that support multiple alias URLs for each WebDAV-compliant resource. A server may implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the same resource, yet only either "a" or "A" is reported upon listing the members of "/col". In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
WebDAV準拠リソースへのマッピングであっても、親collectionに現れない場合があります。その例は、WebDAV準拠リソースごとに複数の別名URLをサポートするサーバーです。サーバーが大文字と小文字を区別しないURLを実装している場合、"/col/a"と"/col/A"は同じリソースを識別しますが、"/col"のメンバーを列挙すると"a"または"A"の一方だけが報告されます。サーバーが一組のセグメントを同等として扱う場合、PROPFINDレスポンスでは、一貫した方法で選択した優先セグメントをマッピングごとに1つだけ公開しなければなりません (MUST)。
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.
リソースをロックする機能は、そのリソースへのアクセスをシリアル化するメカニズムを提供します。オーサリングクライアントは、ロックを使用して、別のプリンシパルが編集中にリソースを変更しないという合理的な保証を提供できます。このようにして、クライアントは「紛失した更新」の問題を防ぐことができます。
This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
この仕様により、ロックは、2つのクライアント指定パラメーター、関与するプリンシパルの数（排他的対共有）、および許可されるアクセスの種類を変化させることができます。このドキュメントでは、1つのアクセスタイプのみのロックを定義します。ただし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を可能にします。
This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK method handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here.
このセクションでは、ロックの動作方法に関する簡潔なモデルを提供します。後のセクションでは、いくつかの概念の詳細を説明し、これらのモデルステートメントを参照してください。ロックおよびロック解除方法の処理に関連する規範的なステートメントは、これらの方法のセクションに記載されていますが、任意の方法をカバーする規範的なステートメントはここに収集されます。
1. A lock either directly or indirectly locks a resource.
1. ロックは、直接または間接的にリソースをロックします。
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.
2. そのリソースのURLへのロック要求が新しいロックを作成すると、リソースが直接ロックされます。新しいロックの「ロックルート」はそのURLです。リクエストの時点で、URLがリソースにマッピングされていない場合、新しい空のリソースが作成され、直接ロックされます。
3. An exclusive lock (Section 6.2) conflicts with any other kind of lock on the same resource, whether either lock is direct or indirect. A server MUST NOT create conflicting locks on a resource.
3. 排他ロック（セクション6.2）は、いずれかのロックが直接か間接かを問わず、同じリソース上の他の種類のロックと競合します。サーバーは、リソース上に競合するロックを作成してはなりません (MUST NOT)。
4. For a collection that is locked with a depth-infinity lock L, all member resources are indirectly locked. Changes in membership of such a collection affect the set of indirectly locked resources:
4. 深さの装備ロックLでロックされているコレクションの場合、すべてのメンバーリソースは間接的にロックされています。このようなコレクションのメンバーシップの変更は、間接的にロックされたリソースのセットに影響します。
* If a member resource is added to the collection, the new member resource MUST NOT already have a conflicting lock, because the new resource MUST become indirectly locked by L.
* memberリソースをcollectionに追加する場合、その新しいmemberリソースに競合するロックが既に存在していてはなりません (MUST NOT)。新しいリソースはLによって間接的にロックされなければならない (MUST) ためです。
* If a member resource stops being a member of the collection, then the resource MUST no longer be indirectly locked by L.
* memberリソースがcollectionのmemberでなくなった場合、そのリソースに対するLの間接ロックを解除しなければなりません (MUST)。
5. Each lock is identified by a single globally unique lock token (Section 6.5).
5. 各ロックは、単一のグローバルに一意のロックトークン（セクション6.5）によって識別されます。
6. An UNLOCK request deletes the lock with the specified lock token. After a lock is deleted, no resource is locked by that lock.
6. ロック解除要求は、指定されたロックトークンでロックを削除します。ロックが削除された後、そのロックによってロックされたリソースはありません。
7. A lock token is "submitted" in a request when it appears in an "If" header (Section 7, "Write Lock", discusses when token submission is required for write locks).
7. ロックトークンは、「セクション7、「書き込みロック」」の「if」ヘッダーに表示されると、リクエストで「送信」され、書き込みロックにトークンの提出が必要な時期について説明します）。
8. If a request causes the lock-root of any lock to become an unmapped URL, then the lock MUST also be deleted by that request.
8. リクエストによっていずれかのロックのlock-rootがマッピングされていないURLになる場合、そのリクエストによって当該ロックも削除しなければなりません (MUST)。
The most basic form of lock is an exclusive lock. Exclusive locks avoid having to deal with content change conflicts, without requiring any coordination other than the methods described in this specification.
ロックの最も基本的な形式は、排他的なロックです。排他的なロックは、この仕様に記載されている方法以外の調整を必要とせずに、コンテンツの変更競合に対処する必要がありません。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal that has both access privileges and a valid lock can use the locked resource.
ただし、ロックの目標は、他の人がアクセス権を行使することを排除するのではなく、校長がアクセス権を行使するつもりであることを示すメカニズムを提供することである場合があります。このケースには共有ロックが提供されます。共有ロックにより、複数のプリンシパルがロックを受信できます。したがって、アクセス権限と有効なロックの両方を備えたプリンシパルは、ロックされたリソースを使用できます。
With shared locks, there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
共有ロックを使用すると、リソースに影響を与える2つの信頼セットがあります。最初の信頼セットは、アクセス許可によって作成されます。たとえば、信頼できるプリンシパルは、リソースに書き込む許可を持っている場合があります。リソースに書き込むアクセス許可を持つ人々のうち、共有ロックを取り出したプリンシパルのセットもお互いを信頼し、アクセス許可書書き込みセット内に（通常）より小さな信頼セットを作成する必要があります。
Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource.
インターネット上のすべての可能なプリンシパルから始めて、ほとんどの場合、これらのプリンシパルの大部分は特定のリソースへの書き込みアクセスを持っていません。書き込みアクセスを持っている少数の人のうち、一部のプリンシパルは、独占的な書き込みロックを使用して、編集が競合を上書きできないことを保証することを決定する場合があります。他の人は、協力者が自分の仕事を上書きしないことを信頼していると判断する場合があります（協力者の潜在的なセットは、許可を書く校長のセットです）。共有ロックを使用してください。
The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out-of-band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.
httpへのWebDAV拡張機能は、校長がアクティビティを調整するために必要なすべての通信パスを提供する必要はありません。共有ロックを使用する場合、プリンシパルは帯域外の通信チャネルを使用して作業を調整することができます（例：対面の相互作用、書面によるメモ、画面に関するポストイットメモ、電話での会話、電子メールなど）共有ロックの意図は、コラボレーターに他の人がリソースに取り組んでいる可能性があることを知らせることです。
Shared locks are included because experience from Web-distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example, when a program crashes or when a lock creator leaves without unlocking a resource. While both timeouts (Section 6.6) and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
Web-Distributed Authorling Systemsの経験により、排他的なロックが硬すぎることが多すぎることが示されているため、共有ロックが含まれています。特定の編集プロセスを実施するために排他的ロックを使用します。排他的ロックを取り出し、リソースの読み取り、編集、リソースの書き込み、ロックを解放します。この編集プロセスには、ロックが常に適切にリリースされるとは限らないという問題があります。たとえば、プログラムがクラッシュしたとき、またはロック作成者がリソースのロックを解除せずに離れるときです。タイムアウト（セクション6.6）と管理アクションの両方を使用して、問題のあるロックを削除することができますが、どちらのメカニズムも必要なときに利用できない場合があります。タイムアウトが長い場合があるか、管理者が利用できない場合があります。
A successful request for a new shared lock MUST result in the generation of a unique lock associated with the requesting principal. Thus, if five principals have taken out shared write locks on the same resource, there will be five locks and five lock tokens, one for each principal.
新しい共有ロックのリクエストが成功した場合、リクエストしたprincipalに関連付けられた一意のロックを生成しなければなりません (MUST)。したがって、5つのprincipalが同じリソースに共有書き込みロックを取得すると、principalごとに1つずつ、5つのロックと5つのlock tokenが存在します。
A WebDAV-compliant resource is not required to support locking in any form. If the resource does support locking, it may choose to support any combination of exclusive and shared locks for any access types.
WebDAVに準拠したリソースは、いかなる形式でもロックをサポートする必要はありません。リソースがロックをサポートしている場合、アクセスタイプの排他的ロックと共有ロックの任意の組み合わせをサポートすることを選択できます。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks, while others only provide support for exclusive write locks, while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
この柔軟性の理由は、ポリシーのロックが、さまざまなストレージリポジトリで採用されているリソース管理およびバージョンシステムのまさに中心に衝突するためです。これらのリポジトリには、どのようなロックが利用可能になるかを制御する必要があります。たとえば、一部のリポジトリは共有の書き込みロックのみをサポートしていますが、他のリポジトリは排他的な書き込みロックのみをサポートしますが、他のリポジトリはロックをまったく使用していません。各システムは特定のロック機能を除外するのに役立つほど十分に異なるため、この仕様はWebDAV内の交渉の唯一の軸としてロックを残します。
The creator of a lock has special privileges to use the lock to modify the resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission).
ロックの作成者には、そのロックを使用してリソースを変更する特別な権限があります。ロックされたリソースを変更するとき、サーバーは、有効なlock tokenが送信されたことの確認に加え、認証済みprincipalがロック作成者と一致することを確認しなければなりません (MUST)。
The server MAY allow privileged users other than the lock creator to destroy a lock (for example, the resource owner or an administrator). The 'unlock' privilege in [RFC3744] was defined to provide that permission.
サーバーは、ロック作成者以外の特権ユーザー（たとえば、リソース所有者や管理者）にロックの破棄を許可してもよい (MAY)。[RFC3744]の'unlock'権限は、その許可を与えるために定義されています。
There is no requirement for servers to accept LOCK requests from all users or from anonymous users.
サーバーがすべてのユーザーまたは匿名ユーザーからロック要求を受け入れる必要はありません。
Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.
ロックを保持していても、ロックされたリソースを変更する完全な権限が与えられるわけではないことに注意してください。書き込みアクセス権およびその他の権限は、lock token値が推測しにくい可能性に依存せず、通常の権限管理または認証機構によって強制しなければなりません (MUST)。
A lock token is a type of state token that identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way.
lock tokenは、特定のロックを識別するstate tokenの一種です。各ロックには、サーバーが生成した一意のlock tokenがちょうど1つあります。クライアントは、lock tokenをいかなる方法でも解釈しようとしてはなりません (MUST NOT)。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it.
lock token URIは、すべてのリソースにわたって永久に一意でなければなりません (MUST)。この一意性制約により、混同を懸念せずにリソースやサーバーをまたいでlock tokenを送信できます。lock tokenは一意であるため、クライアントは、そのtokenを返したリソースとは別のリソースに対するIfヘッダーでlock tokenを送信してもよい (MAY)。
When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in Section 10.5, and also in the body of the response.
ロック操作が新しいロックを作成すると、新しいロックトークンは、セクション10.5で定義されたロックトークン応答ヘッダーと、応答の本文で返されます。
Servers MAY make lock tokens publicly readable (e.g., in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock token created by another client instance.
サーバーは、lock tokenを一般から読み取れるようにしてもよい (MAY)（たとえば、DAV:lockdiscoveryプロパティで公開します）。lock tokenを読み取り可能にする用途の1つは、長期間存続するロックをリソース所有者が解除できるようにすることです（ロックを取得したクライアントが、ロックを後始末する前にクラッシュまたは切断した可能性があります）。ユーザーの指示のもとでUNLOCKを使用する場合を除き、クライアントは別のクライアントインスタンスが作成したlock tokenを使用すべきではありません (SHOULD NOT)。
This specification encourages servers to create Universally Unique Identifiers (UUIDs) for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]). However, servers are free to use any URI (e.g., from another scheme) so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in Appendix C.
この仕様により、サーバーはロックトークン用の普遍的に一意の識別子（UUIDS）を作成し、「普遍的に一意の識別子（UUID）urnネームスペース」（[RFC4122]）で定義されたURIフォームを使用することを奨励しています。ただし、サーバーは、ユニークネス要件を満たしている限り、URI（例えば、別のスキームから）を無料で使用できます。たとえば、付録Cで定義されている「Opaquelocktoken」スキームを使用して、有効なロックトークンを構築することができます。
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
A lock MAY have a limited lifetime. The lifetime is suggested by the client when creating or refreshing the lock, but the server ultimately chooses the timeout value. Timeout is measured in seconds remaining until lock expiration.
ロックの有効期間は有限でもよい (MAY)。ロックを作成または更新するときにクライアントが有効期間を提案しますが、最終的なtimeout値はサーバーが選択します。Timeoutは、ロックが期限切れになるまでの残り秒数で表します。
The timeout counter MUST be restarted if a refresh lock request is successful (see Section 9.10.2). The timeout counter SHOULD NOT be restarted at any other time.
ロック更新リクエストが成功した場合、timeoutカウンターを再始動しなければなりません (MUST)（セクション9.10.2を参照）。それ以外の時点では、timeoutカウンターを再始動すべきではありません (SHOULD NOT)。
If the timeout expires, then the lock SHOULD be removed. In this case the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority.
timeoutが満了した場合、ロックを削除すべきです (SHOULD)。この場合、サーバーは、自身のoverride権限を使い、timeoutしたロックのlock tokenによって当該リソースにUNLOCKメソッドを実行したかのように動作すべきです (SHOULD)。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going offline.
サーバーは、クライアントが実行しようとするアクティビティのタイプを示すため、クライアントが提出した値に細心の注意を払うことをお勧めします。たとえば、ブラウザで実行されているアプレットはリソースをロックする必要がある場合がありますが、アプレットが実行されている環境の不安定性のため、警告なしにアプレットをオフにすることができます。その結果、アプレットは比較的小さなタイムアウト値を要求する可能性が高いため、アプレットが死んだ場合、ロックをすばやく収集できるようになります。ただし、ドキュメント管理システムは、ユーザーがオフラインになることを計画している可能性があるため、非常に長いタイムアウトを要求する可能性があります。
A client MUST NOT assume that just because the timeout has expired, the lock has immediately been removed.
クライアントは、timeoutが満了したという理由だけで、ロックが直ちに削除されたと仮定してはなりません (MUST NOT)。
Likewise, a client MUST NOT assume that just because the timeout has not expired, the lock still exists. Clients MUST assume that locks can arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time, or the system may crash in such a way that it loses the record of the lock's existence.
同様に、クライアントは、timeoutが満了していないという理由だけでロックがまだ存在すると仮定してはなりません (MUST NOT)。クライアントは、Timeoutヘッダーで指定された値にかかわらず、ロックがいつでも任意に消失し得ると仮定しなければなりません (MUST)。Timeoutヘッダーは、異常事態が発生しない場合のサーバー動作だけを示します。たとえば、十分な権限を持つユーザーはいつでもロックを削除でき、システムがクラッシュしてロックの存在記録を失う場合もあります。
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the DAV:supportedlock property.
サーバーロックサポートはオプションであるため、サーバー上のリソースをロックしようとするクライアントは、ロックを試して最善を希望するか、サーバーがサポートするロック機能を決定するために何らかの形のディスカバリーを実行できます。これは、ロック機能ディスカバリーとして知られています。クライアントは、DAV：SupportEdLockプロパティを取得することにより、サーバーがサポートするロックタイプを決定できます。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
LOCKメソッドをサポートするDAV準拠リソースは、DAV:supportedlockプロパティをサポートしなければなりません (MUST)。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and MAY even provide the lock tokens.
あるprincipalがアクセスしようとするリソースを別のprincipalがロックしている場合、前者が後者の身元を確認できると有用です。この目的でDAV:lockdiscoveryプロパティが用意されています。このプロパティは、存続中のすべてのロックを列挙してその種類を記述し、lock tokenまで提供してもよい (MAY)。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
LOCKメソッドをサポートするDAV準拠リソースは、DAV:lockdiscoveryプロパティをサポートしなければなりません (MUST)。
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
このセクションでは、書き込みロックタイプに固有のセマンティクスについて説明します。書き込みロックは、ロックタイプの特定のインスタンスであり、この仕様で説明されている唯一のロックタイプです。
An exclusive write lock protects a resource: it prevents changes by any principal other than the lock creator and in any case where the lock token is not submitted (e.g., by a client process other than the one holding the lock).
排他的な書き込みロックはリソースを保護します。ロッククリエーター以外のプリンシパルによる変更を防ぎ、ロックトークンが提出されない場合（たとえば、ロックを保持しているもの以外のクライアントプロセスによって）。
Clients MUST submit a lock-token they are authorized to use in any request that modifies a write-locked resource. The list of modifications covered by a write-lock include:
クライアントは、書き込みロックされたリソースを変更するすべてのリクエストで、自身に使用権限があるlock tokenを送信しなければなりません (MUST)。書き込みロックの対象となる変更は次のとおりです。
1. A change to any of the following aspects of any write-locked resource:
1. 書き込みロックされたリソースの次の側面のいずれかに変更します。
* any variant,
* 任意のバリアント、
* any dead property,
* 死んだ財産、
* any live property that is lockable (a live property is lockable unless otherwise defined.)
* ロック可能なライブプロパティ（特に定義されていない限り、ライブプロパティはロック可能です。）
2. For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. More discussion on write locks and collections is found in Section 7.4.
2. コレクションの場合、内部メンバーURIの変更。コレクションの内部メンバーURIは、別のリソースを追加、削除、または識別すると、変更されると見なされます。書き込みロックとコレクションの詳細については、セクション7.4に記載されています。
3. A modification of the mapping of the root of the write lock, either to another resource or to no resource (e.g., DELETE).
3. 他のリソースまたはリソースなし（削除）のいずれかに、書き込みロックのルートのマッピングの変更。
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are affected by write locks. All other HTTP/WebDAV methods defined so far -- GET in particular -- function independently of a write lock.
HTTPとWebDAV、Put、Pos、Proppatch、Lock、Rock、Move、Copy（宛先リソース用）、削除、およびMKCOLで定義されているメソッドは、書き込みロックの影響を受けます。これまでに定義された他のすべてのHTTP/WebDAVメソッド - 特に入手 - 書き込みロックとは無関係に機能します。
The next few sections describe in more specific terms how write locks interact with various operations.
次のいくつかのセクションでは、書き込みロックがさまざまな操作とどのように相互作用するかをより具体的に説明しています。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked.
書き込みロックのない人は、リソース上のプロパティを変更しない場合がありますが、スキーマの要件により、ロックされていても、ライブプロパティの値が変更される可能性があります。ロック可能として定義されたデッドプロパティとライブプロパティのみが、書き込みのロック中に変更されないように保証されます。
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
書き込みロックは、紛失した更新を防ぐための助けを提供しますが、更新が失われないことを保証することはできません。次のシナリオを検討してください。
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
2人のクライアントAとBは、リソース「index.html」の編集に関心があります。クライアントAは、WebDAVクライアントではなくHTTPクライアントであるため、ロックを実行する方法がわかりません。
Client A doesn't lock the document, but does a GET, and begins editing.
クライアントAはドキュメントをロックしませんが、getを実行し、編集を開始します。
Client B does LOCK, performs a GET and begins editing.
クライアントBはロックし、GETを実行し、編集を開始します。
Client B finishes editing, performs a PUT, then an UNLOCK.
クライアントBは編集を終了し、プットを実行し、ロックを解除します。
Client A performs a PUT, overwriting and losing all of B's changes.
クライアントAは、Bの変更のすべてを実行し、上書きし、失うことを実行します。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAVプロトコル自体がこの状況を防ぐことができない理由はいくつかあります。まず、ロックを理解していないHTTPクライアントと互換性がなければならないため、すべてのクライアントにロックを使用するように強制することはできません。第二に、リポジトリの実装の多様性のため、サーバーにロックをサポートする必要はありません。その一部は、ロックではなく予約とマージに依存しています。最後に、ステートレスであるため、Lock / Get / Put /ロック解除などの一連の操作を実施することはできません。
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.
ロックをサポートするWebDAVサーバーは、クライアントがリソースを変更する前にリソースをロックすることを要求することにより、クライアントが誤って互いの変更を上書きする可能性を減らすことができます。このようなサーバーは、HTTP 1.0およびHTTP 1.1クライアントがリソースを変更することを効果的に防止します。
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.
WebDAVクライアントは、ロックをサポートするWebDAVサーバーと対話するたびに、ロック /取得 /書き込み /ロック解除の操作を使用することで、優秀な市民になることができます（少なくともデフォルトでは）。
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.
HTTP 1.1クライアントは、リソースを変更するリクエストでIFマッチヘッダーのエンティティタグを使用することにより、他のクライアントの変更を上書きすることを避けて、優秀な市民になる可能性があります。
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
情報マネージャーは、WebDAVリソースを変更する前にロックを必要とするクライアント側の手順を実装することにより、上書きを防ぐことができます。
WebDAV provides the ability to send a LOCK request to an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in Section 14.26 of [RFC2616]). It has the side benefit of locking the new resource immediately for use of the creator.
WebDAVは、使用のために名前を予約するために、マップされていないURLにロックリクエストを送信する機能を提供します。これは、新しいリソースの作成に関する損失の問題を回避する簡単な方法です（もう1つの方法は、[RFC2616]のセクション14.26で指定されたIF-Noneマッチヘッダーを使用することです）。作成者を使用するために、新しいリソースをすぐにロックするという補足の利点があります。
Note that the lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. When trying to lock a collection upon creation, clients can attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation, there's no guarantee this will work).
MKCOLは既存のコレクションを上書きするのではなく、コレクションの作成にのみ使用できるため、コレクションの損失の問題はコレクションの問題ではないことに注意してください。作成時にコレクションをロックしようとすると、クライアントはMKCOLとロックリクエストを一緒にパイプラインすることでロックを取得する可能性を高めようとします（ただし、2つの個別の操作を1つの原子動作に変換しないため、これが機能する保証はありません）。
A successful lock request to an unmapped URL MUST result in the creation of a locked (non-collection) resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource. Note that the LOCK request has no mechanism for the client to provide Content-Type or Content-Language, thus the server will use defaults or empty values and rely on the subsequent PUT request for correct values.
マッピングされていないURLに対するロックリクエストが成功した場合、内容が空の、ロックされた非collectionリソースを作成しなければなりません (MUST)。その後、正しいlock tokenを伴うPUTリクエストが成功すると、そのリソースに内容が与えられます。LOCKリクエストにはクライアントがContent-TypeまたはContent-Languageを指定する仕組みがないため、サーバーはデフォルト値または空の値を使用し、後続のPUTリクエストによって正しい値が与えられることに依存します。
A resource created with a LOCK is empty but otherwise behaves in every way as a normal resource. It behaves the same way as a resource created by a PUT request with an empty body (and where a Content-Type and Content-Language was not specified), followed by a LOCK request to the same resource. Following from this model, a locked empty resource:
ロックで作成されたリソースは空ですが、それ以外の場合は通常のリソースとしてあらゆる方法で動作します。空のボディ（およびコンテンツタイプとコンテンツ言語が指定されていない場合）のプットリクエストによって作成されたリソースと同じように動作し、その後、同じリソースへのロックリクエストが続きます。このモデルから、ロックされた空のリソース：
o Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.
o 読み取り、削除、移動、コピーすることができ、あらゆる方法で通常の非収集リソースとして動作します。
o Appears as a member of its parent collection.
o 親コレクションのメンバーとして登場します。
o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource).
o ロックが消失しても、このリソースは消失すべきではありません (SHOULD NOT)（したがって、他の操作や空でないリソースの場合と同様に、クライアントは自らが残したものを後始末する責任を負います）。
o MAY NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.
o クライアントがまだ指定していないDAV:getcontentlanguageなどのプロパティについては、値を持たなくてもよい (MAY)。
o Can be updated (have content added) with a PUT request.
o プットリクエストで更新（コンテンツを追加します）。
o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).
o collectionへ変換してはなりません (MUST NOT)。サーバーは、既存の非collectionリソースに対する他のMKCOLリクエストと同様に、このリソースに対するMKCOLリクエストを失敗させなければなりません (MUST)。
o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties.
o DAV:lockdiscoveryプロパティおよびDAV:supportedlockプロパティの値が定義されていなければなりません (MUST)。
o The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource.
o レスポンスは、"201 Created"レスポンスコードを使用してリソースが作成されたことを示さなければなりません (MUST)（既存リソースに対するLOCKリクエストでは、代わりに200 OKになります）。既存リソースに対するLOCKリクエストの場合と同様に、bodyには引き続きDAV:lockdiscoveryプロパティを含める必要があります。
The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.
クライアントは、ロックされたロックされたリソースをロックしてすぐに更新し、Putと場合によってはプロップパッチを使用していることが期待されています。
Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs.
代替として、また[RFC2518]との後方互換性のため、サーバーはLock-Null Resource（LNR。付録Dの定義を参照）を実装してもよい (MAY)。クライアントは、マッピングされていないURLにLOCKした後はMKCOLやGETではなくPUTだけを試み、LNR固有のプロパティに依存しないことで、旧モデルのLNRをサポートするサーバーとも、推奨モデルである"locked empty resource"をサポートするサーバーとも容易に相互運用できます。
There are two kinds of collection write locks. A depth-0 write lock on a collection protects the collection properties plus the internal member URLs of that one collection, while not protecting the content or properties of member resources (if the collection itself has any entity bodies, those are also protected). A depth-infinity write lock on a collection provides the same protection on that collection and also provides write lock protection on every member resource.
コレクション書き込みロックには2種類あります。コレクションの深さ0の書き込みロックは、コレクションプロパティとその1つのコレクションの内部メンバーURLを保護し、メンバーリソースのコンテンツまたはプロパティを保護しません（コレクション自体にエンティティボディがある場合、それらも保護されています）。コレクションの深さの内容の書き込みロックは、そのコレクションで同じ保護を提供し、すべてのメンバーリソースに書き込みロック保護を提供します。
Expressed otherwise, a write lock of either kind protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the segment name of any internal member.
それ以外の場合、どちらの種類の書き込みロックが、書き込みロックコレクションに新しいリソースを作成するリクエスト、書き込みロックコレクションの内部メンバーURLを削除するリクエスト、および任意のセグメント名を変更するリクエストを保護します。内部メンバー。
Thus, a collection write lock protects all the following actions:
したがって、コレクション書き込みロックは、次のすべてのアクションを保護します。
o DELETE a collection's direct internal member, o MOVE an internal member out of the collection,
o コレクションの直接的な内部メンバーを削除して、内部メンバーをコレクションから移動させます。
o MOVE an internal member into the collection,
o 内部メンバーをコレクションに移動し、
o MOVE to rename an internal member within a collection,
o コレクション内の内部メンバーの名前を変更するために移動し、
o COPY an internal member into a collection, and
o 内部メンバーをコレクションにコピーします
o PUT or MKCOL request that would create a new internal member.
o 新しい内部メンバーを作成するPutまたはMKCOLリクエスト。
The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately.
コレクションのロックトークンは、個別にロックされている場合、内部メンバー自体のロックトークンに加えて必要です。
In addition, a depth-infinity lock affects all write operations to all members of the locked collection. With a depth-infinity lock, the resource identified by the root of the lock is directly locked, and all its members are indirectly locked.
さらに、深さの内容ロックは、ロックされたコレクションのすべてのメンバーに対するすべての書き込み操作に影響します。深さの内容ロックを使用すると、ロックのルートで識別されるリソースが直接ロックされ、そのメンバーはすべて間接的にロックされています。
o Any new resource added as a descendant of a depth-infinity locked collection becomes indirectly locked.
o 深さの内容ロックされたコレクションの子孫として追加された新しいリソースは、間接的にロックされます。
o Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked.
o ロックされたコレクションからロック解除されたコレクションに移動した間、間接的にロックされたリソースは、その後ロック解除されます。
o Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now protected by the lock on the target collection (the target collection's lock token will thereafter be required to make further changes).
o 間接的にロックされたリソースは、ロックされたソースコレクションから深さの内容ロックされたターゲットコレクションに移動しましたが、間接的にロックされたままですが、ターゲットコレクションのロックによって保護されています（ターゲットコレクションのロックトークンは、その後、さらなる変更を行う必要があります）。
If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner that conflicts with the new lock (see Section 6.1, point 3), the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'no-conflicting-lock' precondition.
新しいロックと競合する形で現在ロックされているリソースを識別するmember URLを含むcollectionに対して、depth-infinityの書き込みLOCKリクエストを発行した場合（セクション6.1の項目3を参照）、そのリクエストは423 (Locked)ステータスコードで失敗しなければなりません (MUST)。また、レスポンスには'no-conflicting-lock'事前条件を含めるべきです (SHOULD)。
If a lock request causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection, then the new resource MUST be automatically protected by the lock. For example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c, then resource /a/b/c will be added to the write lock.
ロックリクエストによって、リソースのURLがdepth-infinityロックされたcollectionのinternal member URLとして追加される場合、新しいリソースはそのロックによって自動的に保護されなければなりません (MUST)。たとえば、collection /a/b/が書き込みロックされていて、リソース/cを/a/b/cへ移動すると、リソース/a/b/cはその書き込みロックに追加されます。
A user agent has to demonstrate knowledge of a lock when requesting an operation on a locked resource. Otherwise, the following scenario might occur. In the scenario, program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
ユーザーエージェントは、ロックされたリソースで操作を要求するときに、ロックの知識を示す必要があります。それ以外の場合、次のシナリオが発生する可能性があります。シナリオでは、ユーザーAが実行するプログラムAは、リソースの書き込みロックを取り出します。また、ユーザーAが実行するプログラムBは、プログラムAによって撮影されたロックに関する知識はありませんが、ロックされたリソースにPutを実行します。このシナリオでは、ロックはプログラムではなくプリンシパルに関連付けられているため、プリンシップBはプリンシパルAの資格情報で作用しているため、Putを実行することが許可されているため、Putは成功します。ただし、プログラムBがロックについて知っていた場合、リソースを上書きしていなかったため、代わりにユーザーへの競合を説明するダイアログボックスを提示することを好みます。このシナリオのため、同じ許可を持つ他のプログラムによって撮影されたロックを誤って無視しないように、さまざまなプログラムを防ぐためにメカニズムが必要です。
In order to prevent these collisions, a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked, then two lock tokens must be submitted in the If header, one for the source and the other for the destination.
これらの衝突を防ぐため、メソッドが変更する可能性のあるすべてのロック済みリソースについて、認可されたprincipalがlock tokenを送信しなければなりません (MUST)。そうしなければ、そのメソッドは失敗しなければなりません (MUST)。lock tokenは、Ifヘッダー内に現れることで送信されたことになります。たとえば、リソースを移動するときに移動元と移動先の両方がロックされている場合、Ifヘッダーで2つのlock token（移動元用と移動先用を1つずつ）を送信する必要があります。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
If: <http://www.example.com/users/f/fielding/index.html>
(<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, even though both the source and destination are locked, only one lock token must be submitted (the one for the lock on the destination). This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
この例では、ソースと宛先の両方がロックされていても、1つのロックトークンのみを提出する必要があります（宛先のロック用）。これは、ソースリソースがコピーによって変更されておらず、したがって書き込みロックの影響を受けないためです。この例では、ユーザーエージェント認証は、基礎となる輸送層内のHTTPプロトコルの範囲外のメカニズムを介して以前に発生しています。
Consider a collection "/locked" with an exclusive, depth-infinity write lock, and an attempt to delete an internal member "/locked/ member":
排他的で深さの深度書き込みロックを備えた「/ロック」と、内部メンバーを削除する試み "/locked/member"を含むコレクションを検討してください。
>>Request
>>リクエスト
DELETE /locked/member HTTP/1.1 Host: example.com
削除/ロックされた/メンバーHTTP/1.1ホスト：example.com
>>Response
>>応答
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/locked/</D:href>
</D:lock-token-submitted>
</D:error>
Thus, the client would need to submit the lock token with the request to make it succeed. To do that, various forms of the If header (see Section 10.4) could be used.
したがって、クライアントは、それを成功させるための要求でロックトークンを送信する必要があります。そのためには、IFヘッダーのさまざまな形式（セクション10.4を参照）を使用できます。
"No-Tag-List" format:
「ノータグリスト」形式：
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/":
「http://example.com/locked/」の「タグ付きリスト」形式：
If: <http://example.com/locked/>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/member":
「http://example.com/locked/member」の「タグ付きリスト」形式：
If: <http://example.com/locked/member>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
Note that, for the purpose of submitting the lock token, the actual form doesn't matter; what's relevant is that the lock token appears in the If header, and that the If header itself evaluates to true.
ロックトークンを送信する目的では、実際のフォームは重要ではないことに注意してください。関連するのは、ロックトークンがIFヘッダーに表示され、IFヘッダー自体がTrueに評価されることです。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with a depth-infinity lock, then the resource will be added to the lock.
COPYメソッドの呼び出しでは、移動元で有効な書き込みロックを複製してはなりません (MUST NOT)。ただし、前述のとおり、COPYによってdepth-infinityロックされたcollectionへリソースをコピーした場合、そのリソースは当該ロックに追加されます。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, if there is an existing lock at the destination, the server MUST add the moved resource to the destination lock scope. For example, if the MOVE makes the resource a child of a collection that has a depth-infinity lock, then the resource will be added to that collection's lock. Additionally, if a resource with a depth-infinity lock is moved to a destination that is within the scope of the same lock (e.g., within the URL namespace tree covered by the lock), the moved resource will again be added to the lock. In both these examples, as specified in Section 7.5, an If header must be submitted containing a lock token for both the source and destination.
書き込みロックされたリソースに対するMOVEリクエストが成功しても、そのリソースとともに書き込みロックを移動してはなりません (MUST NOT)。ただし、移動先に既存のロックがある場合、サーバーは移動したリソースを移動先のロックスコープへ追加しなければなりません (MUST)。たとえば、MOVEによってリソースがdepth-infinityロックされたcollectionの子になる場合、そのリソースは当該collectionのロックに追加されます。また、depth-infinityロックを持つリソースを同じロックのスコープ内（たとえば、そのロックが対象とするURL名前空間ツリー内）の移動先へ移動すると、移動したリソースは再びロックに追加されます。どちらの例でも、セクション7.5の規定どおり、移動元と移動先の両方のlock tokenを含むIfヘッダーを送信する必要があります。
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.
クライアントは、同じ書き込みロックリクエストを2回送信してはなりません (MUST NOT)。既にロックされているリソースへリクエストするにはIfヘッダーにlock tokenを含める必要があるため、クライアントは同じロックリクエストを再送信していることを必ず認識できます。
However, a client may submit a LOCK request with an If header but without a body. A server receiving a LOCK request with no body MUST NOT create a new lock -- this form of the LOCK request is only to be used to "refresh" an existing lock (meaning, at minimum, that any timers associated with the lock MUST be reset).
ただし、クライアントは、Ifヘッダーを含みbodyを含まないLOCKリクエストを送信できます。bodyのないLOCKリクエストを受信したサーバーは、新しいロックを作成してはなりません (MUST NOT)。この形式のLOCKリクエストは、既存のロックを"refresh"するためだけに使用します（少なくとも、そのロックに関連付けられたすべてのtimerをリセットしなければなりません (MUST)）。
Clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client, and a server MAY refresh a lock with a timeout period that is different than the previous timeout period used for the lock, provided it advertises the new value in the LOCK refresh response.
クライアントは、ロック更新リクエストで任意の値のTimeoutヘッダーを送信できます。従来どおり、サーバーはクライアントが送信したTimeoutヘッダーを無視できます。また、LOCK更新レスポンスで新しい値を通知することを条件に、以前そのロックに使用していたtimeout期間とは異なる期間でロックを更新してもよい (MAY)。
If an error is received in response to a refresh LOCK request, the client MUST NOT assume that the lock was refreshed.
更新用のLOCKリクエストに対してエラーを受信した場合、クライアントはロックが更新されたと仮定してはなりません (MUST NOT)。
Servers MUST return authorization errors in preference to other errors. This avoids leaking information about protected resources (e.g., a client that finds that a hidden resource exists by seeing a 423 Locked response to an anonymous request to the resource).
サーバーは、他のエラーよりも優先して認可エラーを返さなければなりません (MUST)。これにより、保護されたリソースに関する情報の漏えいを防ぎます（たとえば、リソースへの匿名リクエストに対する423 Lockedレスポンスから、隠されたリソースの存在をクライアントが知ることを防ぎます）。
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an XML ([REC-XML]) request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support.
HTTP/1.1では、メソッドパラメーター情報はHTTPヘッダーでのみエンコードされました。HTTP/1.1とは異なり、WebDAVはXML（[rec-xml]）要求エンティティボディ、またはHTTPヘッダーのいずれかでメソッドパラメーター情報をエンコードします。メソッドパラメーターをエンコードするためにXMLを使用することは、既存の構造に追加のXML要素を追加し、拡張性を提供する機能によって動機付けられました。また、ISO 10646文字セットで情報をエンコードするXMLの能力により、国際化のサポートを提供します。
In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input.
メソッドパラメーターをエンコードすることに加えて、XMLはWebDAVで使用され、メソッドからの応答をエンコードし、メソッド出力のXMLの拡張性と国際化の利点を提供し、入力を提供します。
When XML is used for a request or response body, the Content-Type type SHOULD be application/xml. Implementations MUST accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.
リクエストまたはレスポンスのbodyにXMLを使用する場合、Content-Typeはapplication/xmlとすべきです (SHOULD)。実装は、リクエストおよびレスポンスのbodyでtext/xmlとapplication/xmlの両方を受け入れなければなりません (MUST)。text/xmlの使用は非推奨です。
All DAV-compliant clients and resources MUST use XML parsers that are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well-formed, then the server MUST reject the entire request with a 400 (Bad Request). If a client receives XML that is not well-formed in a response, then the client MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
DAV準拠のすべてのクライアントおよびリソースは、[REC-XML]と[REC-XML-NAMES]に準拠したXML parserを使用しなければなりません (MUST)。リクエストまたはレスポンスで使用するすべてのXMLは、少なくとも整形式であり、名前空間を正しく使用しなければなりません (MUST)。サーバーが整形式でないXMLを受信した場合、400 (Bad Request)でリクエスト全体を拒否しなければなりません (MUST)。クライアントがレスポンスで整形式でないXMLを受信した場合、実行されたメソッドの結果について何も仮定してはならず (MUST NOT)、サーバーが誤動作しているものとして扱うべきです (SHOULD)。
Note that processing XML submitted by an untrusted source may cause risks connected to privacy, security, and service quality (see Section 20). Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance, with a 400 (Bad Request) status code and an optional response body explaining the problem.
信頼できない送信元から送られたXMLを処理すると、プライバシー、セキュリティ、およびサービス品質に関するリスクが生じる場合があります（セクション20を参照）。サーバーは、整形式のXMLで構成されていても、疑わしいリクエストを拒否してもよい (MAY)。たとえば、400 (Bad Request)ステータスコードと、問題を説明する任意のレスポンスbodyを使用できます。
URLs appear in many places in requests and responses. Interoperability experience with [RFC2518] showed that many clients parsing Multi-Status responses did not fully implement the full Reference Resolution defined in Section 5 of [RFC3986]. Thus, servers in particular need to be careful in handling URLs in responses, to ensure that clients have enough context to be able to interpret all the URLs. The rules in this section apply not only to resource URLs in the 'href' element in Multi-Status responses, but also to the Destination and If header resource URLs.
URLは、リクエストと応答で多くの場所に表示されます。[RFC2518]との相互運用性の経験は、マルチステータス応答を解析する多くのクライアントが[RFC3986]のセクション5で定義された完全な参照解像度を完全に実装しなかったことを示しました。したがって、特にサーバーは、クライアントがすべてのURLを解釈できるように十分なコンテキストを確保するために、応答のURLを処理する際に注意する必要があります。このセクションのルールは、マルチステータス応答の「HREF」要素のリソースURLだけでなく、宛先とヘッダーリソースURLにも適用されます。
The sender has a choice between two approaches: using a relative reference, which is resolved against the Request-URI, or a full URI. A server MUST ensure that every 'href' value within a Multi-Status response uses the same format.
送信者は、Request-URIを基準に解決される相対参照を使用する方法と、完全なURIを使用する方法の2つから選択できます。サーバーは、Multi-Statusレスポンス内のすべての'href'値が同じ形式を使用するよう保証しなければなりません (MUST)。
WebDAV only uses one form of relative reference in its extensions, the absolute path.
WebDAVは、その拡張機能である絶対パスで1つの形式の相対参照のみを使用します。
Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
simple-ref = absolute-uri |（path-absolute ["？" query]）
The absolute-URI, path-absolute and query productions are defined in Sections 4.3, 3.3, and 3.4 of [RFC3986].
[RFC3986]のセクション4.3、3.3、および3.4で、絶対尿、パスアブソリュート、クエリ作品は定義されています。
Within Simple-ref productions, senders MUST NOT:
Simple-ref生成規則内では、送信者は次のことを行ってはなりません (MUST NOT)：
o use dot-segments ("." or ".."), or
o dot-segments（ "。"または ".."）を使用するか
o have prefixes that do not match the Request-URI (using the comparison rules defined in Section 3.2.3 of [RFC2616]).
o リクエスト-URIと一致しないプレフィックスがあります（[RFC2616]のセクション3.2.3で定義されている比較ルールを使用）。
Identifiers for collections SHOULD end in a '/' character.
collectionの識別子は'/'文字で終えるべきです (SHOULD)。
Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below:
コレクションhttp://example.com/sample/内部メンバーのurl url http://example.com/sample/a%20testと以下のPropfindリクエストを検討してください。
>>Request:
>>リクエスト：
PROPFIND /sample/ HTTP/1.1 Host: example.com Depth: 1
propfind/sample/http/1.1ホスト：example.com深さ：1
In this case, the server should return two 'href' elements containing either
この場合、サーバーはどちらを含む2つの「HREF」要素を返す必要があります
o 'http://example.com/sample/' and 'http://example.com/sample/a%20test', or
o 'http://example.com/sample/'および 'http://example.com/sample/a%20test'、または
o '/sample/' and '/sample/a%20test'
o '/sample/' and '/sample/a％20test'
Note that even though the server may be storing the member resource internally as 'a test', it has to be percent-encoded when used inside a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character.
サーバーがメンバーリソースを「テスト」として内部的に保存している場合でも、URIリファレンス内で使用する場合はパーセントエンコードする必要があることに注意してください（[RFC3986]のセクション2.1を参照）。また、合法的なURIには、アンパサンド文字などのXML文字データ内で逃げる必要がある文字がまだ含まれている場合があることに注意してください。
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as the client intended.
これらの新しいメソッドの一部は、bodyを定義していません。サーバーは、bodyが想定されていない場合でも、すべてのリクエストにbodyがあるかどうかを調べなければなりません (MUST)。リクエストbodyが存在するもののサーバーが無視することになる場合、サーバーは415 (Unsupported Media Type)でリクエストを拒否しなければなりません (MUST)。これにより、拡張を使用しようとしていた可能性のあるクライアントに、その意図どおりにはbodyを処理できなかったことを通知します。
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see Section 14.18, [RFC2616]).
HTTPは、WebDAVリクエストと応答で使用できる多くのヘッダーを定義します。これらすべてがすべての状況で適切であるわけではなく、いくつかの相互作用が未定義になる可能性があります。HTTP 1.1には、可能であればすべての応答で日付ヘッダーが必要であることに注意してください（セクション14.18、[RFC2616]を参照）。
The server MUST do authorization checks before checking any HTTP conditional header.
サーバーは、HTTP条件ヘッダーを確認する前に認可検査を行わなければなりません (MUST)。
HTTP 1.1 recommends the use of ETags rather than modification dates, for cache control, and there are even stronger reasons to prefer ETags for authoring. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example, when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user if it has changed. Timestamps do not solve this problem nearly as well as ETags.
HTTP 1.1は、キャッシュコントロールのために変更された日付ではなくETAGSの使用を推奨しており、オーサリングにETAGを好む理由はさらに強い理由があります。分散したオーサリング環境では、ETAGSの正しい使用がさらに重要です。これは、Updateの失われた問題を回避するためにLocksとともにETAGが必要であるためです。たとえば、ロックがタイムアウトし、クライアントが誤ってオフラインまたは長いアップロードの真ん中にある場合、クライアントはロックの更新に失敗する可能性があります。クライアントがロックの更新に失敗した場合、その間に変更が行われない限り、リソースを再ロックし、ユーザーが編集に進むことができる可能性があります。クライアントがこのケースを区別できるようにするには、ETAGが必要です。それ以外の場合、クライアントは、ユーザーが変更されたかどうかを通知することなく、サーバー上のリソースを上書きするかどうかをユーザーに尋ねることを余儀なくされます。タイムスタンプは、この問題をETAGとほぼ同じように解決しません。
Strong ETags are much more useful for authoring use cases than weak ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be a useful concept but that depends on the document type and the application type, and interoperability might require some agreement or standard outside the scope of this specification and HTTP. Note also that weak ETags have certain restrictions in HTTP, e.g., these cannot be used in If-Match headers.
強いETAGは、弱いETAGよりもユースケースを作成するのにはるかに有用です（[RFC2616]のセクション13.3.3を参照）。セマンティックの等価性は有用な概念になる可能性がありますが、ドキュメントタイプとアプリケーションタイプに依存し、相互運用性がこの仕様とHTTPの範囲外で何らかの一致または標準を必要とする場合があります。また、弱いETAGにはHTTPに特定の制限があることに注意してください。たとえば、これらはIFマッチヘッダーでは使用できません。
Note that the meaning of an ETag in a PUT response is not clearly defined either in this document or in RFC 2616 (i.e., whether the ETag means that the resource is octet-for-octet equivalent to the body of the PUT request, or whether the server could have made minor changes in the formatting or content of the document upon storage). This is an HTTP issue, not purely a WebDAV issue.
PUT応答のETAGの意味は、このドキュメントまたはRFC 2616で明確に定義されていないことに注意してください（つまり、ETAGがリソースがプットリクエストの本体に相当するオクテットに相当することを意味するかどうか、またはサーバーは、ストレージ時にドキュメントの書式設定またはコンテンツを軽微な変更した可能性があります）。これはHTTPの問題であり、純粋にWebDAVの問題ではありません。
Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
ETagが変わると、クライアントはユーザーに確認を求めたり、変更済みの内容を破棄したりせざるを得ない場合があります。そのためWebDAVサーバーは、bodyとlocationが変わっていないリソースのETag（またはLast-Modified時刻）を変更すべきではありません (SHOULD NOT)。ETagは、リソースのbodyまたは内容の状態を表します。プロパティが変更されたかどうかを示す同様の手段はありません。
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until the specification for Versioning Extensions to WebDAV introduced a mechanism to include more specific information in the body of an error response (Section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16.
HTTPとWebDAVは、WebDAVへのバージョン拡張機能の仕様がエラー応答の本文により具体的な情報を含めるメカニズムを導入するまで、機械型情報のほとんどのエラー応答のボディを使用しませんでした（[RFC3253]のセクション1.6）。エラーボディメカニズムは、ボディを取る可能性のあるエラー応答で使用するのに適していますが、ボディはまだ定義されていません。メカニズムは、ステータスコードが多くのことを意味する場合に特に適切です（たとえば、400の悪いリクエストは、必要なヘッダーが欠落していること、ヘッダーが誤ってフォーマットされていることを意味します）。このエラーボディメカニズムは、セクション16でカバーされています。
Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing any operation that affects the URL namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve their semantics, in particular: o For any given URL, the "Last-Modified" value MUST increment every time the representation returned upon GET changes (within the limits of timestamp resolution).
HTTPレスポンスヘッダー"Etag"および"Last-Modified"（[RFC2616]のセクション14.19および14.29を参照）は、リソース単位ではなくURL単位で定義され、クライアントがキャッシュに使用することに注意してください。したがってサーバーは、COPY、MOVE、DELETE、PUT、MKCOLなど、URL名前空間に影響する操作を実行しても両ヘッダーの意味が維持されるようにする必要があります。特に、次の規則が適用されます。o 各URLについて、GETで返されるrepresentationが変化するたびに、"Last-Modified"値を、timestampの分解能の範囲内で増加させなければなりません (MUST)。
o For any given URL, an "ETag" value MUST NOT be reused for different representations returned by GET.
o 各URLについて、GETで返される異なるrepresentationに同じ"ETag"値を再利用してはなりません (MUST NOT)。
In practice this means that servers
実際には、これはサーバーを意味します
o might have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation unless it can do so more selectively, and
o より選択的に行うことができない限り、名前空間操作の宛先ネームスペース内のすべてのリソースの「ラスト変更された」タイムスタンプをインクリメントする必要があるかもしれません。
o similarly, might have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server).
o 同様に、これらのリソースの「ETAG」値を再割り当てする必要がある場合があります（サーバーがエンティティを方法で割り当てて、サーバーが管理するURLネームスペース全体で一意にすることができない限り）。
Note that these considerations also apply to specific use cases, such as using PUT to create a new resource at a URL that has been mapped before, but has been deleted since then.
これらの考慮事項は、Putを使用して以前にマッピングされたが削除されているURLで新しいリソースを作成するなど、特定のユースケースにも適用されることに注意してください。
Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly.
最後に、HTTPヘッダーからセマンティクスを継承するWebDAVプロパティ（DAV：getEtagおよびdav：getLastModifiedなど）は、それに応じて動作する必要があります。
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element (Section 14.20) along with all XML elements defined for use with that element.
PROPFINDメソッドは、Request-URIで識別されるリソースにinternal memberがない場合はそのリソースに定義されたプロパティを取得し、そのリソースがinternal member URLを持つcollectionである場合は、Request-URIで識別されるリソースと、場合によってはそのmemberリソースに定義されたプロパティを取得します。DAV準拠のすべてのリソースは、PROPFINDメソッド、propfind XML要素（セクション14.20）、およびその要素とともに使用するものとして定義されたすべてのXML要素をサポートしなければなりません (MUST)。
A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite-depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. Servers SHOULD treat a request without a Depth header as if a "Depth: infinity" header was included.
クライアントは、PROPFINDリクエストで値が"0"、"1"、または"infinity"のDepthヘッダーを送信しなければなりません (MUST)。サーバーは、WebDAV準拠リソースに対するdepth "0"および"1"のリクエストをサポートしなければならず (MUST)、"infinity"のリクエストもサポートすべきです (SHOULD)。実際には、この動作に伴う性能およびセキュリティ上の懸念から、無限depthリクエストのサポートを無効にしてもよい (MAY)。サーバーは、Depthヘッダーのないリクエストを、"Depth: infinity"ヘッダーが含まれていたものとして扱うべきです (SHOULD)。
A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to:
クライアントは、リクエストメソッドの本文に「Propfind」XML要素を提出することができます。可能です：
o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server),
o 'prop'要素内で取得対象のプロパティ名を指定して、特定のプロパティ値を要求します（サーバーは、ここでのプロパティの順序を無視してもよい (MAY)）。
o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise),
o この仕様で定義されているプロパティの値（最低では）と死んだプロパティの要素「AllProp」要素（「含まれる」要素は「AllProp」で使用できます。それ以外の場合は返されなかったかもしれません）、
o Request a list of names of all the properties defined on the resource, by using the 'propname' element.
o 「Propname」要素を使用して、リソースに定義されているすべてのプロパティの名前のリストをリクエストします。
A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request.
クライアントは、リクエストbodyを送信しないことも選択できます。空のPROPFINDリクエストbodyは、'allprop'リクエストであるものとして扱わなければなりません (MUST)。
Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests.
「AllProp」はすべてのライブプロパティの値を返さないことに注意してください。WebDAVサーバーは、ますます高価に計算されている、または長いプロパティがあり（[RFC3253]および[RFC3744]を参照）、すべてのプロパティを既に返していません。代わりに、WebDAVクライアントはPropnameリクエストを使用して、ライブプロパティが存在するものを発見し、値を取得するときに名前付きプロパティを要求できます。他の場所で定義されているライブプロパティの場合、その定義は、そのライブプロパティが「AllProp」リクエストで返されるかどうかを指定できます。
All servers MUST support returning a response of content type text/ xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
すべてのサーバーは、各種プロパティの取得を試みた結果を記述するmultistatus XML要素を含む、content typeがtext/xmlまたはapplication/xmlのレスポンスを返す機能をサポートしなければなりません (MUST)。
If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value.
プロパティの取得中にエラーが発生した場合、適切なエラー結果をレスポンスに含めなければなりません (MUST)。存在しないプロパティ値の取得要求はエラーであり、404 (Not Found)ステータス値を含む'response' XML要素で示さなければなりません (MUST)。
Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses.
したがって、collectionリソースの'multistatus' XML要素には、要求されたdepthまでのcollectionの各member URLについて'response' XML要素を含めなければなりません (MUST)。WebDAV非準拠リソースの'response'要素は含めるべきではありません (SHOULD NOT)。各'response'要素には、prop XML要素内のプロパティが定義されているリソースのURLを格納する'href'要素を含めなければなりません (MUST)。collectionリソースに対するPROPFINDの結果は、要素順に意味のない平坦なリストとして返されます。リソースがある名前のプロパティについて持てる値は1つだけなので、そのプロパティがPROPFINDレスポンスに現れるのも1回だけです。
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
プロパティにはアクセス制御が適用される場合があります。'allprop'および'propname'リクエストで、特定のプロパティが存在するかどうかを知る権限をprincipalが持たない場合、そのプロパティを通知なしにレスポンスから除外してもよい (MAY)。
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
ほとんどのプロパティにはcache validation機構がないため、一部のPROPFIND結果は注意したうえでキャッシュしてもよい (MAY)。このメソッドはsafeかつidempotentです（[RFC2616]のセクション9.1を参照）。
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
このセクションは、他のメソッドの同様のセクションと同様に、エラーコードと前提条件または事後条件（セクション16で定義）に関するガイダンスを提供します。
403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body.
403 Forbidden - サーバーは、Depthヘッダーが"Infinity"のcollectionに対するPROPFINDリクエストを拒否してもよい (MAY)。その場合、error body内に'propfind-finite-depth'事前条件コードを指定して、このエラーを使用すべきです (SHOULD)。
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
Propfind Responseでは、個々のプロパティに関する情報は、「Propstat」要素内（セクション14.22を参照）内に返されます。それぞれが、その中に表示されるプロパティに関する情報を含む個々の「ステータス」要素を含みます。以下のリストは、「Propstat」内で使用される最も一般的なステータスコードをまとめたものです。ただし、クライアントは、他の2/3/4/5xxシリーズステータスコードを処理する準備をする必要があります。
200 OK - A property exists and/or its value is successfully returned.
200 OK-プロパティが存在し、その値が正常に返されます。
401 Unauthorized - The property cannot be viewed without appropriate authorization.
401許可されていない - 適切な承認なしにプロパティを表示することはできません。
403 Forbidden - The property cannot be viewed regardless of authentication.
403禁止 - 認証に関係なく、プロパティを表示できません。
404 Not Found - The property does not exist.
404見つかりません - プロパティは存在しません。
>>Request
>>リクエスト
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the
DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case, only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
この例では、Propfindは非収集リソースhttp://www.example.com/fileで実行されます。Propfind XML要素は、値が要求されている4つのプロパティの名前を指定します。この場合、リクエストを発行する元本が3番目と4番目のプロパティを見るのに十分なアクセス権を持っていなかったため、2つのプロパティのみが返されました。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.example.com/container/</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.example.com/container/front.html</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendants should be returned.
この例では、Propfindはコレクションリソースhttp://www.example.com/container/に呼び出されます。深さヘッダーが存在しないため、「無限」のデフォルト値を想定しています。つまり、コレクションのプロパティの名前とそのすべての子孫を返す必要があります。
Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://ns.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace.
前の例と一致して、Resource http://www.example.com/container/には、「http://ns.example.com/boxschema/」という名前のbigboxと著者の6つのプロパティが定義されています。"dav：" namespaceのDisplayName、ResourceType、およびSupportEdLock。
The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://ns.example.com/boxschema/" namespace and creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace.
リソースhttp://www.example.com/container/index.htmlは、「コンテナ」コレクションのメンバーである「http://ns.example.com/boxschema/」のBigboxで定義されている9つのプロパティが定義されています。「名前空間とcreationdate、displayName、getContentLength、getContentType、getEtag、getLastModified、ResourceType、およびsupportedLock in "dav：" namespace。
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
この例は、XMLネームスペーススコーピングとデフォルトの名前空間の使用も示しています。「XMLNS」属性にはプレフィックスが含まれていないため、名前空間はデフォルトですべての囲まれた要素に適用されます。したがって、それらが属する名前空間を明示的に明示的に述べていないすべての要素は、「dav： "namespaceのメンバーです。
Note that 'allprop', despite its name, which remains for backward-compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
「AllProp」は、その名前にもかかわらず、後方互換性のために残っているにもかかわらず、すべてのプロパティを返すのではなく、この仕様で定義されているデッドプロパティとライブプロパティのみを返すことに注意してください。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
<R:author><R:Name>Hadrian</R:Name></R:author>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type B</R:BoxType>
</R:bigbox>
<D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
<D:displayname>Example HTML resource</D:displayname>
<D:getcontentlength>4525</D:getcontentlength>
<D:getcontenttype>text/html</D:getcontenttype>
<D:getetag>"zzyzx"</D:getetag>
<D:getlastmodified
>Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, PROPFIND was invoked on the resource http://www.example.com/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all the dead properties defined on the resources, plus the name and value of all the properties defined in this specification. This example illustrates the use of relative references in the 'href' elements of the response.
この例では、Propfindはリソースhttp://www.example.com/container/ 1の深さヘッダーで呼び出されました。、つまり、リクエストは、リソースで定義されているすべての死んだプロパティの名前と値に加えて、この仕様で定義されているすべてのプロパティの名前と値を返す必要があります。この例は、応答の「HREF」要素での相対的な参照の使用を示しています。
The resource http://www.example.com/container/ has six properties defined on it: 'bigbox' and 'author in the "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV: displayname, DAV:resourcetype, and DAV:supportedlock.
リソースhttp://www.example.com/container/には、「http://ns.example.com/boxschema/ "namespace、dav：creationdate、davの「bigbox」と '著者の6つのプロパティが定義されています。：displayName、dav：resourceType、およびdav：supportedlock。
The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The WebDAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example collection" (DAV: displayname), a collection resource type (DAV:resourcetype), and supports exclusive write and shared write locks (DAV:supportedlock).
最後の4つのプロパティは、セクション15で定義されているWebDAV固有です。GETはこのリソースでサポートされていないため、GET*プロパティ（DAV：GetContentLength）はこのリソースで定義されていません。WebDAV固有のプロパティは、「コンテナ」が1997年12月1日午後5時42分21分に、GMT（DAV：CreationDate）の西8時間のタイムゾーンで「COMPERY COLLECTION」の名前を持っていると主張しています（DAV」：displayName）、コレクションリソースタイプ（DAV：ResourceType）、および排他的な書き込みロック（DAV：supportedLock）をサポートします。
The resource http://www.example.com/container/front.html has nine properties defined on it:
リソースhttp://www.example.com/container/front.htmlには、9つのプロパティが定義されています。
'bigbox' in the "http://ns.example.com/boxschema/" namespace (another instance of the "bigbox" property type), DAV:creationdate, DAV: displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
「http://ns.example.com/boxschema/ "namespace（「bigbox」プロパティタイプの別のインスタンス）、dav：creationdate、dav：displayname、dav：getcontentlength、dav：getcontenttype、dav：GetEtag、DAV：GetLastModified、DAV：ResourceType、およびDAV：SupportEdLock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example HTML resource" (DAV: displayname), a content length of 4525 bytes (DAV:getcontentlength), a MIME type of "text/html" (DAV:getcontenttype), an entity tag of "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type, meaning that it is not a collection (DAV:resourcetype), and supports both exclusive write and shared write locks (DAV:supportedlock).
DAV固有のプロパティは、「front.html」が1997年12月1日午後6時27分21分に、GMTの西8時間のタイムゾーン（DAV：CreationDate）に作成されたと主張しています。"（dav：displayName）、コンテンツ長の4525バイト（dav：getContentLength）、「Zzyzx」（dav：geteTag）のエンティティタグである「text/html」（dav：getContentType）のMIMEタイプが最後に変更されました。1998年1月12日月曜日、09：25：56 GMT（dav：getLastModified）は、空のリソースタイプを持っています。つまり、コレクション（DAV：ResourceType）ではなく、排他的な書き込みロックと共有の両方のロック（DAV：supportedlock）。
>>Request
>>リクエスト
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
In this example, PROPFIND is executed on the resource http://www.example.com/mycol/ and its internal member resources. The client requests the values of all live properties defined in this specification, plus all dead properties, plus two more live properties defined in [RFC3253]. The response is not shown.
この例では、Propfindはリソースhttp://www.example.com/mycol/およびその内部メンバーリソースで実行されます。クライアントは、この仕様で定義されているすべてのライブプロパティの値に加えて、すべての死んだプロパティに加えて、[RFC3253]で定義されている2つのライブプロパティを要求します。応答は表示されません。
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.
プロップパッチメソッドは、リクエスト本文で指定された命令を処理し、リクエスト-URIによって識別されたリソースで定義されたプロパティを設定および/または削除します。
All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties.
DAV準拠のすべてのリソースはPROPPATCHメソッドをサポートしなければならず (MUST)、propertyupdate、set、およびremove XML要素を使用して指定された命令を処理しなければなりません (MUST)。このメソッドの指示を実行できるかどうかは、当然ながらアクセス制御上の制約に従います。DAV準拠リソースは、任意のdead propertyを設定する機能をサポートすべきです (SHOULD)。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element.
PROPPATCHメソッドのリクエストメッセージbodyには、propertyupdate XML要素を含めなければなりません (MUST)。
Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26.
サーバーは、文書内の順序どおりにPROPPATCH命令を処理しなければなりません (MUST)（順序に意味がないという通常の規則の例外です）。命令はすべて実行するか、1つも実行しないかのいずれかでなければなりません (MUST)。したがって、処理中に何らかのエラーが発生した場合、それまでに実行したすべての命令を取り消し (MUST)、適切なエラー結果を返さなければなりません。命令処理の詳細は、セクション14.23および14.26のset命令とremove命令の定義にあります。
If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi-Status response as described in Section 9.2.1.
サーバーがPROPPATCHリクエスト内のいずれかのプロパティ変更を試みる場合（すなわち、bodyの処理前に上位レベルのエラーでリクエストを拒否しなかった場合）、レスポンスはセクション9.2.1に記載するMulti-Statusレスポンスでなければなりません (MUST)。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentですが、safeではありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
プロップパッチの応答では、個々のプロパティに関する情報は、「PropStat」要素内（セクション14.22を参照）内に返され、それぞれに表示されるプロパティに関する情報を含む個々の「ステータス」要素が含まれています。以下のリストは、「Propstat」内で使用される最も一般的なステータスコードをまとめたものです。ただし、クライアントは、他の2/3/4/5xxシリーズステータスコードを処理する準備をする必要があります。
200 (OK) - The property set or change succeeded. Note that if this appears for one property, it appears for every property in the response, due to the atomicity of PROPPATCH.
200（OK） - プロパティセットまたは変更が成功しました。これが1つのプロパティに表示される場合、プロップパッチの原子性により、応答内のすべてのプロパティに対して表示されることに注意してください。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（FORBIDDEN） - クライアントは、サーバーが指定しないことを選択した理由で、プロパティのいずれかを変更できません。
403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body.
403 (Forbidden)：クライアントがDAV:getetagなどの保護されたプロパティを設定しようとしました。このエラーを返す場合、サーバーはレスポンスbody内で'cannot-modify-protected-property'事前条件コードを使用すべきです (SHOULD)。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.
409（競合） - クライアントは、セマンティクスがプロパティに適していない値を提供しました。
424 (Failed Dependency) - The property change could not be made because of another property change that failed.
424（依存の失敗） - 失敗した別のプロパティの変更のために、プロパティの変更を行うことはできませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（ストレージが不十分） - サーバーには、プロパティを記録するのに十分なスペースがありませんでした。
>>Request
>>リクエスト
PROPPATCH /bar.html HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:Authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:response>
<D:href>http://www.example.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner cannot be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
In this example, the client requests the server to set the value of the "Authors" property in the "http://ns.example.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the same namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
この例では、クライアントはサーバーに「http://ns.example.com/standards/z39.50/」の「著者」プロパティの値を設定し、名前空間を削除するように要求し、プロパティを削除します。「同じ名前空間で。著作権所有者のプロパティを削除できないため、プロパティの変更は発生しません。著者のプロパティの424（失敗した依存関係）ステータスコードは、著作権所有者のプロパティの削除と競合がなければ、このアクションが成功したことを示しています。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail.
MKCOLは、Request-URIで指定された場所に新しいcollectionリソースを作成します。Request-URIが既にリソースへマッピングされている場合、MKCOLは失敗しなければなりません (MUST)。MKCOLの処理中、Request-URIが"/"でない限り、サーバーはRequest-URIをその親collectionのinternal memberにしなければなりません (MUST)。そのようなancestorが存在しなければ、このメソッドは失敗しなければなりません (MUST)。MKCOL操作で新しいcollectionリソースを作成するときは、すべてのancestorが既に存在していなければならず (MUST)、存在しない場合は409 (Conflict)ステータスコードで失敗しなければなりません (MUST)。たとえば、collection /a/b/c/d/を作成するリクエストを行ったときに/a/b/c/が存在しなければ、そのリクエストは失敗する必要があります。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
リクエストbodyなしでMKCOLを呼び出した場合、新しく作成されるcollectionにはmemberが存在しないようにすべきです (SHOULD)。
A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members, and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand, it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
MKCOLリクエストメッセージにはmessage bodyを含めることができます。bodyがある場合のMKCOLリクエストの厳密な動作は未定義ですが、collection、collectionのmember、memberのbody、およびcollectionまたはmemberのプロパティの作成に限定されます。サーバーがサポートも理解もしていないentity typeのMKCOLリクエストを受信した場合、415 (Unsupported Media Type)ステータスコードで応答しなければなりません (MUST)。entityの存在または種類を理由にリクエストを拒否する場合、サーバーは415 (Unsupported Media Type)ステータスコードを使用するのが望まれます。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentですが、safeではありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
In addition to the general status codes possible, the following status codes have specific applicability to MKCOL:
可能な一般的なステータスコードに加えて、次のステータスコードには、MKCOLに特定の適用可能性があります。
201 (Created) - The collection was created.
201（作成） - コレクションが作成されました。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止） - これは、2つの条件の少なくとも1つを示します。1）サーバーは、そのURLネームスペースの特定の場所でコレクションを作成することを許可していません。。
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
405（メソッドは許可されていない）-MKCOLは、マップされていないURLでのみ実行できます。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409 (Conflict) - 1つ以上の中間collectionを作成するまで、Request-URIにcollectionを作成できません。サーバーは、それらの中間collectionを自動的に作成してはなりません (MUST NOT)。
415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type).
415（サポートされていないメディアタイプ） - サーバーはリクエストボディタイプをサポートしていません（ただし、この仕様は定義されていないため、サーバーは特定のボディタイプをサポートしない可能性が高いため）。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - リソースには、この方法の実行後にリソースの状態を記録するのに十分なスペースがありません。
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
この例では、サーバーwww.example.comに/webdisc/xfiles/というコレクションを作成します。
>>Request
>>リクエスト
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com
mkcol/webdisc/xfiles/http/1.1ホスト：www.example.com
>>Response
>>応答
HTTP/1.1 201 Created
HTTP/1.1 201が作成しました
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
GETは「（エンティティの形式で）すべての情報がリクエスト-URIによって識別される」[RFC2616]であると定義されるため、コレクションに適用される場合、GETのセマンティクスは変更されません。コレクションに適用された場合、「index.html」リソースの内容、コレクションの内容の人間が読み取る可能性のあるビュー、または完全に何かを返すことができます。したがって、コレクションの取得の結果は、コレクションのメンバーシップとの相関関係がない可能性があります。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
同様に、ヘッドの定義は応答メッセージ本文のないGETであるため、収集リソースに適用すると、ヘッドのセマンティクスは修正されません。
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
定義上、POSTによって実行される実際の関数はサーバーによって決定され、多くの場合特定のリソースに依存するため、コレクションに適用される場合のPOSTの動作は、大部分が定義されているため、有意義に変更できません。したがって、ポストのセマンティクスは、コレクションに適用されると修正されていません。
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.
削除は[RFC2616]、セクション9.7で定義されており、「リクエスト-URIによって識別されたリソースを削除します」。ただし、WebDAVは、いくつかの削除処理要件を変更します。
A server processing a successful DELETE request:
サーバーの処理成功した削除要求：
MUST destroy locks rooted on the deleted resource
削除されたリソースをlock-rootとするロックを破棄しなければなりません (MUST)
MUST remove the mapping from the Request-URI to any resource.
Request-URIから任意のリソースへのマッピングを削除しなければなりません (MUST)。
Thus, after a successful DELETE operation (and in the absence of other actions), a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
したがって、DELETE操作が成功した後、ほかの操作がない限り、対象のRequest-URIに対する後続のGET/HEAD/PROPFINDリクエストは404 (Not Found)を返さなければなりません (MUST)。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
collectionに対するDELETEメソッドは、"Depth: infinity"ヘッダーが使用されたものとして動作しなければなりません (MUST)。クライアントは、collectionに対するDELETEで、infinity以外の値を持つDepthヘッダーを送信してはなりません (MUST NOT)。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted.
削除は、リクエスト-URIで指定されたコレクションと、内部メンバーURLによって識別されたすべてのリソースが削除されることを指示します。
If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency.
member URLで識別されるリソースを削除できない場合、URL名前空間の一貫性を維持するため、そのmemberのすべてのancestorを削除してはなりません (MUST NOT)。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
DELETEに含まれるすべてのヘッダーを、削除対象となる各リソースの処理に適用しなければなりません (MUST)。
When the DELETE method has completed processing, it MUST result in a consistent URL namespace.
DELETEメソッドの処理が完了した時点で、一貫したURL名前空間になっていなければなりません (MUST)。
If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked.
メンバーリソース（リクエスト-URIで識別されたリソース以外のリソース）を削除するエラーが発生した場合、応答は207（マルチステータス）になります。ここでは、エラーコードを含む内部リソースを削除できないことを示すためにマルチステータスが使用されています。たとえば、マルチステータス本体には、内部リソースがロックされている場合、ステータス423（ロック）の応答を含めることができます。
The server MAY return a 4xx status response, rather than a 207, if the request failed completely.
リクエストが完全に失敗した場合、サーバーは207ではなく4xxステータスレスポンスを返してもよい (MAY)。
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally, 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
DELETEに対する207 (Multi-Status)レスポンスには、424 (Failed Dependency)ステータスコードを含めるべきではありません (SHOULD NOT)。ancestorの子孫についてエラーを受信すれば、そのancestorも削除できなかったことをクライアントが認識できるため、このステータスコードは安全に省略できます。また、207 (Multi-Status)では204 (No Content)エラーを返すべきではありません (SHOULD NOT)。これは、204 (No Content)がデフォルトの成功コードだからです。
>>Request
>>リクエスト
DELETE /container/ HTTP/1.1 Host: www.example.com
削除/コンテナ/HTTP/1.1ホスト：www.example.com
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus, the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent cannot be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
この例では、http：//www.example.com/container/resource3を削除しようとする試みは、ロックされており、ロックトークンはリクエストで提出されていませんでした。その結果、http：//www.example.com/container/を削除しようとする試みも失敗しました。したがって、クライアントは、http://www.example.com/container/を削除しようとする試みも、子供が削除されない限り、親を削除できないため故障したに違いないことを知っています。深度ヘッダーは含まれていませんが、メソッドがコレクションにあるため、無限の深さが想定されています。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソースで実行されたプットは、リソースのGET応答エンティティに取って代わります。リソースで定義されているプロパティは、処理中に再計算される場合がありますが、それ以外の場合は影響を受けません。たとえば、サーバーが要求本体のコンテンツタイプを認識している場合、プロパティとして有益に公開される可能性のある情報を自動的に抽出できる場合があります。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
適切なスコープの親collectionがない状態でリソースを作成することになるPUTは、409 (Conflict)で失敗しなければなりません (MUST)。
A PUT request allows a client to indicate what media type an entity body has, and whether it should change if overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a Content-Type.
PUTリクエストによって、クライアントはエンティティボディが持つメディアタイプと、それが上書き時に変更されるべきかどうかを示すことができます。したがって、既知のメディアタイプがあれば、クライアントは新しいリソースにContent-Typeを付与すべきです (SHOULD)。クライアントが新しいリソースにContent-Typeを付与しない場合、サーバーはContent-Typeを割り当てないままリソースを作成してもよく (MAY)、あるいはContent-Typeの割り当てを試みてもよい (MAY)。
Note that although a recipient ought generally to treat metadata supplied with an HTTP request as authoritative, in practice there's no guarantee that a server will accept client-supplied metadata (e.g., any request header beginning with "Content-"). Many servers do not allow configuring the Content-Type on a per-resource basis in the first place. Thus, clients can't always rely on the ability to directly influence the content type by including a Content-Type request header.
受信者は一般にHTTPリクエストを権威あるメタデータを処理する必要がありますが、実際には、サーバーがクライアントがサプリしたメタデータを受け入れるという保証はありません（例：「コンテンツ」から始まるリクエストヘッダー）。多くのサーバーでは、最初にリソースごとにコンテンツタイプを構成することはできません。したがって、クライアントは、コンテンツタイプのリクエストヘッダーを含めることにより、コンテンツタイプに直接影響を与える機能に常に依存することはできません。
This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
本仕様は、既存のcollectionに対するPUTメソッドの動作を定義しません。既存のcollectionに対するPUTリクエストは、エラー（405 Method Not Allowed）として扱ってもよい (MAY)。
The MKCOL method is defined to create collections.
MKCOLメソッドは、コレクションを作成するために定義されています。
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
COPYメソッドは、Request-URIで識別されるsourceリソースの複製を、Destinationヘッダー内のURIで識別されるdestinationリソースに作成します。Destinationヘッダーを含めなければなりません (MUST)。COPYメソッドの厳密な動作は、sourceリソースの種類によって異なります。
All WebDAV-compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
WebDAV準拠のすべてのリソースは、COPYメソッドをサポートしなければなりません (MUST)。ただし、COPYメソッドのサポートは、リソースを実際にコピーできることを保証しません。たとえば、同じサーバー上のリソースを別々のプログラムが管理している場合があります。そのため、同じサーバー上に見えるlocationへリソースをコピーできない場合があります。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentですが、safeではありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
ソースリソースがコレクションではない場合、コピー方法の結果は、宛先に新しいリソースの作成であり、その状態と行動はソースリソースのそれと可能な限り密接に一致します。適切な動作に必要なリソースがないなど、サーバーの制御範囲外の要因により、目的地の環境はソースの環境とは異なる場合があるため、リソースの動作をで完全に複製することはできない場合があります。目的地。その後の宛先リソースの変更は、ソースリソースを変更しません。ソースリソースのその後の変更は、宛先リソースを変更しません。
After a successful COPY invocation, all dead properties on the source resource SHOULD be duplicated on the destination resource. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. Servers SHOULD NOT convert live properties into dead properties on the destination resource, because clients may then draw incorrect conclusions about the state or functionality of a resource. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful COPY might result in the property being reported as "Not Found" in subsequent requests.
COPYの呼び出しが成功した後、sourceリソース上のすべてのdead propertyをdestinationリソースへ複製すべきです (SHOULD)。本書に記載するlive propertyは、値まで同じである必要はありませんが、destinationリソースで同じように動作するlive propertyとして複製すべきです (SHOULD)。クライアントがリソースの状態や機能について誤った結論を導く可能性があるため、サーバーはlive propertyをdestinationリソース上のdead propertyへ変換すべきではありません (SHOULD NOT)。一部のlive propertyでは、不在であること自体に特定の意味があります（たとえば、存在時と不在時で反対の意味を持つflag）。その場合、COPYが成功しても、後続リクエストでそのプロパティが"Not Found"と報告されることがあります。
When the destination is an unmapped URL, a COPY operation creates a new resource much like a PUT operation does. Live properties that are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
宛先がマップされていないURLである場合、コピー操作は、プット操作と同じように新しいリソースを作成します。リソース作成（DAV：CreationDateなど）に関連するライブプロパティは、それに応じて値を設定する必要があります。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.
Depthヘッダーのないcollectionに対するCOPYメソッドは、値が"infinity"のDepthヘッダーが含まれていたものとして動作しなければなりません (MUST)。クライアントは、collectionに対するCOPYで値が"0"または"infinity"のDepthヘッダーを送信できます。サーバーは、WebDAV準拠リソースについて、Depthヘッダーの"0"と"infinity"の両方の動作をサポートしなければなりません (MUST)。
An infinite-depth COPY instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Note that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite recursion if not handled correctly.
無限の詳細なコピーは、リクエスト-URIによって識別されたコレクションリソースが宛先ヘッダーのURIによって識別された場所にコピーされることを指示し、そのすべての内部メンバーリソースは、再帰的にそれに関連する場所にコピーされることを指示します。コレクション階層のすべてのレベルを通じて。/a/into/a/b/の無限の詳細なコピーは、正しく処理されないと無限の再帰につながる可能性があることに注意してください。
A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied.
「深さ：0」のコピーは、コレクションとそのプロパティのみを指示しますが、内部メンバーURLによって識別されるリソースはコピーされます。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
COPYに含まれるすべてのヘッダーは、Destinationヘッダーを除き、コピー対象となる各リソースの処理に適用しなければなりません (MUST)。
The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI, the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the Destination is http://example.com/b/, then when http://example.com/a/c/d is processed, it must use a Destination of http://example.com/b/c/d.
宛先ヘッダーは、リクエスト-URIの宛先URIのみを指定します。リクエストURIによって識別されたコレクションのメンバーに適用される場合、宛先の価値は、階層内の現在の場所を反映するように変更されます。したがって、ホストヘッダー値http://example.com/を使用している場合、リクエスト-uriが/a/である場合、宛先はhttp://example.com/b/、http：//example.com/a/の場合C/Dは処理され、http：//example.com/b/c/dの宛先を使用する必要があります。
When the COPY method has completed processing, it MUST have created a consistent URL namespace at the destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members that are not descendants of an error-causing collection).
COPYメソッドの処理が完了した時点で、destinationに一貫したURL名前空間を作成していなければなりません (MUST)（名前空間の一貫性の定義はセクション5.1を参照）。ただし、内部collectionのコピー中にエラーが発生した場合、このcollectionのmemberで識別されるリソースをサーバーがコピーしてはなりません (MUST NOT)（すなわち、このsubtreeをスキップする必要があります）。エラー検出後も、COPY操作は元のコピー操作を可能な限り完了するよう試みるべきです (SHOULD)（すなわち、エラーの原因となったcollectionの子孫でない他のsubtreeとそのmemberについては、引き続きコピーを試みるのが望まれます）。
So, for example, if an infinite-depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite-depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
たとえば、collection /a/b/と/a/c/を含むcollection /a/に対してinfinite-depthのコピー操作を行い、/a/b/のコピー中にエラーが発生しても、/a/c/のコピーは引き続き試みるのが望まれます。同様に、infinite-depthコピーの一部として非collectionリソースをコピー中にエラーが発生した後も、サーバーは元のコピー操作を可能な限り完了するよう試みるべきです (SHOULD)。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error.
Request-URIで識別されるリソース以外のリソースについてCOPYメソッドの実行エラーが発生した場合、レスポンスは207 (Multi-Status)でなければならず (MUST)、失敗の原因となったリソースのURLを、その具体的なエラーとともに示さなければなりません (MUST)。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
COPYメソッドからの207 (Multi-Status)レスポンスでは、424 (Failed Dependency)ステータスコードを返すべきではありません (SHOULD NOT)。親についてエラーを受信すれば、そのリソースの子孫もコピーできなかったことをクライアントが認識できるため、これらのレスポンスは安全に省略できます。また、COPYメソッドからの207 (Multi-Status)レスポンスの値として、201 (Created)または204 (No Content)ステータスコードを返すべきではありません (SHOULD NOT)。これらもデフォルトの成功コードなので、安全に省略できます。
If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request.
COPYリクエストに値が"F"のOverwriteヘッダーがあり、Destination URLにリソースが存在する場合、サーバーはそのリクエストを失敗させなければなりません (MUST)。
When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties.
サーバーがCOPYリクエストを実行してdestinationリソースを上書きする場合、厳密な動作は、WebDAV拡張機能を含む多くの要因に依存してもよい (MAY)（特に[RFC3253]を参照）。たとえば、通常のリソースを上書きする場合、サーバーはコピー前にtargetリソースを削除することも、live propertyを保持するために同じ場所で上書きすることもできます。
When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior.
collectionを上書きする場合、COPYリクエスト成功後のdestination collectionのmembershipは、COPY直前のsource collectionと同じmembershipでなければなりません (MUST)。したがって、source collectionとdestination collectionのmembershipをdestinationで併合する動作は準拠していません。
In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g., to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset.
一般に、クライアントがコピーの前に宛先URLの状態を必要とする場合（例えば、ライブプロパティをリセットするように強制するため）、クライアントはコピーリクエストの前に宛先に削除を送信して、このリセットを確認することができます。。
In addition to the general status codes possible, the following status codes have specific applicability to COPY:
可能な一般的なステータスコードに加えて、次のステータスコードには、コピーするための特定の適用性があります。
201 (Created) - The source resource was successfully copied. The COPY operation resulted in the creation of a new resource.
201（作成） - ソースリソースが正常にコピーされました。コピー操作により、新しいリソースが作成されました。
204 (No Content) - The source resource was successfully copied to a preexisting destination resource.
204（コンテンツなし） - ソースリソースは、既存の宛先リソースに正常にコピーされました。
207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status.
207（Multi -Status） - 複数のリソースがコピーの影響を受けることになっていましたが、それらのいくつかのエラーは操作が行われないようにしました。特定のエラーメッセージは、ソースおよび宛先URLの最も適切なものとともに、マルチステータス応答の本体に表示されます。たとえば、宛先リソースがロックされていて上書きできなかった場合、宛先リソースURLは423（ロック）ステータスで表示されます。
403 (Forbidden) - The operation is forbidden. A special case for COPY could be that the source and destination resources are the same resource.
403（禁止） - 操作は禁止されています。コピーの特別なケースは、ソースと宛先のリソースが同じリソースであることです。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409 (Conflict) - 1つ以上の中間collectionを作成するまで、destinationにリソースを作成できません。サーバーは、それらの中間collectionを自動的に作成してはなりません (MUST NOT)。
412 (Precondition Failed) - A precondition header check failed, e.g., the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件に失敗しました） - 前提条件のヘッダーチェックが失敗しました。たとえば、上書きヘッダーは「F」であり、宛先URLはすでにリソースにマッピングされています。
423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423 (Locked) - destinationリソース、またはdestination collection内のリソースがロックされています。このレスポンスには'lock-token-submitted'事前条件要素を含めるべきです (SHOULD)。
502 (Bad Gateway) - This may occur when the destination is on another server, repository, or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead.
502（悪いゲートウェイ） - これは、宛先が別のサーバー、リポジトリ、またはURLネームスペース上にあるときに発生する可能性があります。ソースネームスペースが宛先名空間へのコピーをサポートしていないか、宛先名前スペースがリソースを受け入れることを拒否します。クライアントは、代わりにGET/PUTとPROPFIND/PROPPATCHを試してみたい場合があります。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - 宛先リソースには、この方法の実行後にリソースの状態を記録するのに十分なスペースがありません。
This example shows resource http://www.example.com/~fielding/index.html being copied to the location http://www.example.com/users/f/fielding/index.html. The 204 (No Content) status code indicates that the existing resource at the destination was overwritten.
この例は、リソースhttp://www.example.com/~fielding/index.htmlが場所http://www.example.com/users/f/fielding/index.htmlにコピーされていることを示しています。204（コンテンツなし）ステータスコードは、宛先の既存のリソースが上書きされたことを示しています。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination URL is already mapped to a resource.
次の例は、同じコピー操作が実行されていることを示していますが、上書きヘッダーが「F」に設定されています。宛先URLがすでにリソースにマッピングされているため、412（前提条件が失敗した）の応答が返されます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
Overwrite: F
>>Response
>>応答
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前提条件は失敗しました
>>Request
>>リクエスト
COPY /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Depth: infinity
コピー/コンテナ/HTTP/1.1ホスト：www.example.com宛先：http：//www.example.com/othercontainer/深さ：インフィニティ
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example, most of the resources, along with the collection, were copied successfully. However, the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However, no errors were listed for those members due to the error minimization rules.
コレクションのコピーのデフォルトの動作は、「深さ：無限」ヘッダーが提出されたかのように行動することであるため、深さヘッダーは不要です。この例では、ほとんどのリソースはコレクションとともに正常にコピーされました。ただし、宛先R2がロックされているため、コレクションR2は失敗しました。R2をコピーするエラーがあったため、R2のメンバーはどれもコピーされませんでした。ただし、エラーの最小化ルールのため、これらのメンバーのエラーはリストされていません。
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource.
非収集リソースの移動操作は、コピー（コピー）に相当する論理的なものであり、その後に一貫性メンテナンス処理が続き、その後にソースが削除され、3つのアクションすべてが単一の操作で実行されます。一貫性メンテナンスステップにより、ソースリソースを識別するリクエスト-URI以外のすべてのURLを更新するなど、新しい宛先リソースを指すように、サーバーが移動によって引き起こされる更新を実行できます。
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.
すべてのMOVEメソッドでDestinationヘッダーを指定しなければならず (MUST)、MOVEメソッドのCOPY部分についてCOPYのすべての要件に従わなければなりません (MUST)。WebDAV準拠のすべてのリソースは、MOVEメソッドをサポートしなければなりません (MUST)。
Support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
MOVEメソッドのサポートは、リソースを特定の宛先に移動する能力を保証するものではありません。たとえば、個別のプログラムは、実際に同じサーバー上の異なるリソースセットを制御する場合があります。したがって、同じサーバーに属していると思われる名前空間内でリソースを移動することはできない場合があります。
If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
宛先にリソースが存在する場合、宛先リソースは、上書きヘッダーの制限を条件として、移動操作の副作用として削除されます。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentですが、safeではありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
Live properties described in this document SHOULD be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful MOVE might result in the property being reported as "Not Found" in subsequent requests. If the live properties will not work the same way at the destination, the server MAY fail the request.
本書に記載するlive propertyはリソースとともに移動し、値まで同じである必要はないものの、destinationリソースで同じように動作するようにすべきです (SHOULD)。一部のlive propertyでは、不在であること自体に特定の意味があります（たとえば、存在時と不在時で反対の意味を持つflag）。その場合、MOVEが成功しても、後続リクエストでそのプロパティが"Not Found"と報告されることがあります。live propertyがdestinationで同じように動作しない場合、サーバーはリクエストを失敗させてもよい (MAY)。
MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties that are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE.
MOVEは、親collectionを変えずにファイル名を変更するためにクライアントが頻繁に使用するので、リソース作成時に設定されたすべてのlive propertyをリセットするのは適切ではありません。たとえば、DAV:creationdateプロパティ値はMOVE後も同じ値を維持すべきです (SHOULD)。
Dead properties MUST be moved along with the resource.
dead propertyは、リソースとともに移動しなければなりません (MUST)。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
「深さ：Infinity」の動きは、リクエスト-URIによって識別されたコレクションを宛先ヘッダーで指定されたアドレスに移動することを指示し、その内部メンバーURLによって識別されるすべてのリソースは、それに関連する場所に移動し、再帰的に移動します。コレクション階層のすべてのレベル。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
collectionに対するMOVEメソッドは、"Depth: infinity"ヘッダーが使用されたものとして動作しなければなりません (MUST)。クライアントは、collectionに対するMOVEで、"infinity"以外の値を持つDepthヘッダーを送信してはなりません (MUST NOT)。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections.
MOVEに含まれるすべてのヘッダーは、Destinationヘッダーを除き、移動対象となる各リソースの処理に適用しなければなりません (MUST)。Destinationヘッダーの動作は、collectionに対するCOPYで示した動作と同じです。
When the MOVE method has completed processing, it MUST have created a consistent URL namespace at both the source and destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members that are not descendants of an error-causing collection). So, for example, if an infinite-depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite-depth move, the server SHOULD try to finish as much of the original move operation as possible.
MOVEメソッドの処理が完了した時点で、sourceとdestinationの両方に一貫したURL名前空間を作成していなければなりません (MUST)（名前空間の一貫性の定義はセクション5.1を参照）。ただし、内部collectionの移動中にエラーが発生した場合、失敗したcollectionのmemberで識別されるリソースをサーバーが移動してはなりません (MUST NOT)（すなわち、エラーの原因となったsubtreeをスキップする必要があります）。移動すれば一貫性のない名前空間になるためです。この場合、エラー検出後も、MOVE操作は元の移動を可能な限り完了するよう試みるべきです (SHOULD)（すなわち、エラーの原因となったcollectionの子孫でない他のsubtreeと、そのmemberで識別されるリソースについては、引き続き移動を試みるのが望まれます）。たとえば、collection /a/b/と/a/c/を含むcollection /a/に対してinfinite-depthの移動を行い、/a/b/の移動中にエラーが発生しても、/a/c/の移動は引き続き試みるのが望まれます。同様に、infinite-depth移動の一部として非collectionリソースを移動中にエラーが発生した後も、サーバーは元の移動操作を可能な限り完了するよう試みるべきです (SHOULD)。
If an error occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error.
Request-URIで識別されるリソース以外のリソースでエラーが発生した場合、レスポンスは207 (Multi-Status)でなければならず (MUST)、エラーが発生したリソースのURLを、その具体的なエラーとともに示さなければなりません (MUST)。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
MOVEメソッドからの207 (Multi-Status)レスポンスでは、424 (Failed Dependency)ステータスコードを返すべきではありません (SHOULD NOT)。親についてエラーを受信すれば、そのリソースの子孫も移動できなかったことをクライアントが認識できるため、これらのエラーは安全に省略できます。また、MOVEからの207 (Multi-Status)レスポンスの値として、201 (Created)または204 (No Content)レスポンスを返すべきではありません (SHOULD NOT)。これらはデフォルトの成功コードなので、安全に省略できます。
If a resource exists at the destination and the Overwrite header is "T", then prior to performing the move, the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F", then the operation will fail.
destinationにリソースが存在し、Overwriteヘッダーが"T"の場合、サーバーは移動の実行前にdestinationリソースへ"Depth: infinity"を指定したDELETEを実行しなければなりません (MUST)。Overwriteヘッダーが"F"に設定されている場合、この操作は失敗します。
In addition to the general status codes possible, the following status codes have specific applicability to MOVE:
可能な一般的なステータスコードに加えて、次のステータスコードには、移動するための特定の適用性があります。
201 (Created) - The source resource was successfully moved, and a new URL mapping was created at the destination.
201（作成） - ソースリソースが正常に移動され、目的地で新しいURLマッピングが作成されました。
204 (No Content) - The source resource was successfully moved to a URL that was already mapped.
204（コンテンツなし） - ソースリソースは、すでにマッピングされているURLに正常に移動されました。
207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status.
207（Multi -Status） - 複数のリソースが移動の影響を受けましたが、それらのいくつかのエラーは操作が行われないようにしました。特定のエラーメッセージは、ソースおよび宛先URLの最も適切なものとともに、マルチステータス応答の本体に表示されます。たとえば、ソースリソースがロックされて移動できなかった場合、ソースリソースURLは423（ロックされた）ステータスで表示されます。
403 (Forbidden) - Among many possible reasons for forbidding a MOVE operation, this status code is recommended for use when the source and destination resources are the same.
403（禁止） - 移動操作を禁止する多くの考えられる理由の中で、このステータスコードは、ソースと宛先のリソースが同じ場合に使用することをお勧めします。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'preserved-live-properties' postcondition).
409 (Conflict) - 1つ以上の中間collectionを作成するまで、destinationにリソースを作成できません。サーバーは、それらの中間collectionを自動的に作成してはなりません (MUST NOT)。または、live propertyの動作を保持しつつリソースをdestinationへ移動することがサーバーにできませんでした（'preserved-live-properties'事後条件を参照）。
412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件に失敗した） - 条件ヘッダーが失敗しました。移動するために、これは上書きヘッダーが「F」であり、宛先URLがすでにリソースにマッピングされていることを意味します。
423 (Locked) - The source or the destination resource, the source or destination resource parent, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423 (Locked) - sourceまたはdestinationのリソース、その親リソース、あるいはsourceまたはdestinationのcollection内のいずれかのリソースがロックされています。このレスポンスには'lock-token-submitted'事前条件要素を含めるべきです (SHOULD)。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
502（悪いゲートウェイ） - これは、宛先が別のサーバー上にあり、宛先サーバーがリソースの受け入れを拒否したときに発生する可能性があります。これは、宛先が同じサーバー名空間の別のサブセクションにある場合にも発生する可能性があります。
This example shows resource http://www.example.com/~fielding/index.html being moved to the location http://www.example.com/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination URL was already mapped to a resource. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例は、リソースhttp://www.example.com/~fielding/index.htmlが場所http://www.example.com/users/f/fielding/index.htmlに移動することを示しています。宛先URLがすでにリソースにマッピングされている場合、宛先リソースの内容は上書きされていました。この場合、宛先リソースには何もなかったため、応答コードは201（作成）です。
>>Request
>>リクエスト
MOVE /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 201 Created Location: http://www.example.com/users/f/fielding/index.html
HTTP/1.1 201の作成場所：http：//www.example.com/users/f/fielding/index.html
>>Request
>>リクエスト
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.example.com/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case, the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However, no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
この例では、クライアントはリクエストで多数のロックトークンを提出しました。ロックトークンは、ソースと宛先の両方のリソース、メソッドの範囲内のどこでもロックされているすべてのリソースに提出する必要があります。この場合、適切なロックトークンは宛先http://www.example.com/othercontainer/c2/に提出されませんでした。これは、リソース/コンテナ/C2/を移動できなかったことを意味します。エラー移動/container/c2/があったため、/container/c2のメンバーはいずれも移動しませんでした。ただし、エラーの最小化ルールのため、これらのメンバーのエラーはリストされていません。ユーザーエージェント認証は、基礎となる輸送層で、HTTPプロトコルの範囲外のメカニズムを介して以前に発生しています。
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
次のセクションでは、ロック方法について説明します。これは、アクセスタイプのロックを取り出し、既存のロックを更新するために使用されます。ロックメソッドのこれらのセクションは、ロックメソッドに固有のセマンティクスのみを説明し、要求されているロックのアクセスタイプとは無関係です。
Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
LOCKメソッドをサポートするすべてのリソースは、少なくとも、ここで定義するXMLリクエスト形式とレスポンス形式をサポートしなければなりません (MUST)。
This method is neither idempotent nor safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentでもsafeでもありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
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 method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
既存リソースへのLOCKリクエストでは、そのリソースが競合するロックで既にロックされていないことを条件として、Request-URIで識別されるリソースにロックを作成します。Request-URIで識別されるリソースがlock-rootになります。新しいロックを作成するLOCKメソッドリクエストには、XML request bodyがなければなりません (MUST)。サーバーは、LOCKリクエストの'owner'要素でクライアントから提供された情報を保持しなければなりません (MUST)。LOCKリクエストにはTimeoutヘッダーを含めてもよい (MAY)。
When a new lock is created, the LOCK response:
新しいロックが作成されると、ロック応答：
o MUST contain a body with the value of the DAV:lockdiscovery property in a prop XML element. This MUST contain the full information about the lock just granted, while information about other (shared) locks is OPTIONAL.
o prop XML要素内にDAV:lockdiscoveryプロパティ値を持つbodyを含めなければなりません (MUST)。これには、付与されたばかりのロックに関する完全な情報を含めなければなりません (MUST)。ほかの共有ロックに関する情報は含めてもよい (OPTIONAL)。
o MUST include the Lock-Token response header with the token associated with the new lock.
o 新しいロックに関連付けられたtokenを値とするLock-Tokenレスポンスヘッダーを含めなければなりません (MUST)。
A lock is refreshed by sending a LOCK request to the URL of a resource within the scope of the lock. This request MUST NOT have a body and it MUST specify which lock to refresh by using the 'If' header with a single lock token (only one lock may be refreshed at a time). The request MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh.
ロックのスコープ内にあるリソースのURLへLOCKリクエストを送信することで、ロックを更新します。このリクエストにはbodyを含めてはならず (MUST NOT)、1つのlock tokenを指定した'If'ヘッダーを使用して、更新対象のロックを指定しなければなりません (MUST)（一度に更新できるロックは1つだけです）。リクエストにはTimeoutヘッダーを含めてもよく (MAY)、サーバーはそれを受け入れ、ロックの残り時間を新しい値へ変更してもよい (MAY)。サーバーは、LOCK更新時のDepthヘッダーを無視しなければなりません (MUST)。
If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed.
リソースに他の（共有）ロックがある場合、それらのロックはロックリフレッシュの影響を受けません。さらに、これらのロックは、指定されたロックが更新されないようにしません。
The Lock-Token header is not returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the DAV:lockdiscovery property.
LOCK更新リクエストが成功した場合、そのレスポンスではLock-Tokenヘッダーを返しませんが、LOCK response bodyにはDAV:lockdiscoveryプロパティの新しい値を含めなければなりません (MUST)。
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header.
DepthヘッダーはLOCKメソッドで使用できます。LOCKメソッドのDepthヘッダーには、0またはinfinity以外の値を使用してはなりません (MUST NOT)。LOCKメソッドをサポートするすべてのリソースは、Depthヘッダーをサポートしなければなりません (MUST)。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
値0の深度ヘッダーは、リクエスト-URIによって指定されたリソースをロックすることを意味します。
If the Depth header is set to infinity, then the resource specified in the Request-URI along with all its members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token. Similarly, if an UNLOCK is successfully executed on this token, all associated resources are unlocked. Hence, partial success is not an option for LOCK or UNLOCK. Either the entire hierarchy is locked or no resources are locked.
Depthヘッダーがinfinityに設定されている場合、Request-URIで指定されたリソースと、その階層下のすべてのmemberがロック対象になります。成功時には、1つのlock tokenを返さなければなりません (MUST)。同様に、このtokenに対するUNLOCKが成功すると、関連するすべてのリソースのロックが解除されます。したがって、LOCKまたはUNLOCKでは部分的な成功を選択できません。階層全体がロックされるか、1つのリソースもロックされないかのいずれかです。
If the lock cannot be granted to all resources, the server MUST return a Multi-Status response with a 'response' element for at least one resource that prevented the lock from being granted, along with a suitable status code for that failure (e.g., 403 (Forbidden) or 423 (Locked)). Additionally, if the resource causing the failure was not the resource requested, then the server SHOULD include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency.
すべてのリソースにロックを付与できない場合、サーバーは、ロック付与を妨げた少なくとも1つのリソースに対する'response'要素と、その失敗に適したステータスコード（たとえば403 (Forbidden)または423 (Locked)）を含むMulti-Statusレスポンスを返さなければなりません (MUST)。さらに、失敗の原因となったリソースがリクエスト対象のリソースでない場合、サーバーはRequest-URIに対する'response'要素も含め、その中の'status'要素で424 Failed Dependencyを示すべきです (SHOULD)。
If no Depth header is submitted on a LOCK request, then the request MUST act as if a "Depth:infinity" had been submitted.
LOCKリクエストでDepthヘッダーが送信されない場合、そのリクエストは"Depth:infinity"が送信されたものとして動作しなければなりません (MUST)。
A successful LOCK method MUST result in the creation of an empty resource that is locked (and that is not a collection) when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length
そのURLにリソースがそれまで存在しなかった場合、LOCKメソッドの成功によって、ロックされた空の非collectionリソースを作成しなければなりません (MUST)。その後ロックが消失しても、空のリソースは残ります。このような空のリソースは、そのURLをレスポンススコープに含むPROPFINDレスポンスへ表示しなければなりません (MUST)。サーバーは、204 No Contentレスポンスを使用するか、長さ0を示すContent-Lengthヘッダーを伴う200 OKを使用して、空のリソースに対するGETリクエストへ正常に応答しなければなりません (MUST)。
The table below describes the behavior that occurs when a lock request is made on a resource.
以下の表は、リソースにロックリクエストが行われたときに発生する動作について説明しています。
+--------------------------+----------------+-------------------+
| Current State | Shared Lock OK | Exclusive Lock OK |
+--------------------------+----------------+-------------------+
| None | True | True |
| Shared Lock | True | False |
| Exclusive Lock | False | False* |
+--------------------------+----------------+-------------------+
Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
凡例：True = ロックを付与してよい。False = ロックを付与してはなりません (MUST NOT)。*=同じプリンシパルが同一のロックを2回要求することは認められません。
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating that the lock must not be granted.
リソースの現在のロック状態は左端の列に記載されており、ロックリクエストは最初の行にリストされています。行と列の交差点は、ロックリクエストの結果を示します。たとえば、共有ロックがリソースに保持され、排他的ロックが要求された場合、テーブルエントリは「false」であり、ロックを許可してはならないことを示します。
In addition to the general status codes possible, the following status codes have specific applicability to LOCK:
可能な一般的なステータスコードに加えて、次のステータスコードには、ロックするための特定の適用性があります。
200 (OK) - The LOCK request succeeded and the value of the DAV: lockdiscovery property is included in the response body.
200（OK） - ロック要求が成功し、DAVの値：Lock -Discoveryプロパティが応答ボディに含まれています。
201 (Created) - The LOCK request was to an unmapped URL, the request succeeded and resulted in the creation of a new resource, and the value of the DAV:lockdiscovery property is included in the response body.
201（作成） - ロック要求はマップされていないURLに対するものであり、リクエストは成功し、新しいリソースの作成になり、DAV：Lock -Discoveryプロパティの値が応答ボディに含まれています。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409 (Conflict) - 1つ以上の中間collectionを作成するまで、destinationにリソースを作成できません。サーバーは、それらの中間collectionを自動的に作成してはなりません (MUST NOT)。
423 (Locked), potentially with 'no-conflicting-lock' precondition code - There is already a lock on the resource that is not compatible with the requested lock (see lock compatibility table above).
423（ロック）、潜在的に「紛争なしロック」前処理コード - リクエストされたロックと互換性がないリソースにロックが既にあります（上のロック互換性テーブルを参照）。
412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with an If header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
412（前提条件が失敗しました）、「ロックトークンマッチ - リクエスト-URI」前処理コード - ロック要求はIFヘッダーで行われ、クライアントが指定されたロックを更新したいことを示しています。ただし、リクエスト-URIは、トークンによって識別されたロックの範囲に該当しませんでした。ロックには、リクエスト-URIが含まれていないスコープがあるか、ロックが消えた可能性があるか、トークンが無効になる可能性があります。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://example.org/~ejw/contact.html contains contact information for the creator of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例は、リソースhttp://example.com/workspace/webdav/proposal.docでの排他的な書き込みロックの作成の成功を示しています。リソースhttp://example.org/~ejw/contact.htmlには、ロックの作成者の連絡先情報が含まれています。サーバーには、このリソースにアクティビティベースのタイムアウトポリシーがあり、1週間後（604800秒）後にロックが自動的に削除されます。NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていないことに注意してください。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
このリクエストはロックを更新し、タイムアウトヘッダーで指定された新しい値にタイムアウトをリセットしようとします。クライアントは無限のタイムアウトを求めたが、サーバーはリクエストを無視することを選択したことに注意してください。この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
>>Request
>>リクエスト
LOCK /webdav/ HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://example.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://example.com/webdav/</D:href>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:response>
</D:multistatus>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite-length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock -- in this case, a Web page URL.
この例は、コレクションとそのすべての子供に排他的な書き込みロックのリクエストを示しています。このリクエストでは、クライアントは、利用可能な場合は、無限の長さのロックが必要であることを指定しています。リクエストエンティティボディには、ロックを取り出すプリンシパルの連絡先情報が含まれています。この場合、WebページURLが含まれています。
The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the a 'response' element for the Request-URI itself has been included as required.
エラーは、リソースhttp://example.com/webdav/secretの403（禁止）応答です。このリソースをロックできなかったため、リソースはいずれもロックされていません。また、リクエスト-URI自体の「応答」要素が必要に応じて含まれていることにも注意してください。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.
UNLOCKメソッドは、Lock-Tokenリクエストヘッダー内のlock tokenで識別されるロックを削除します。Request-URIは、そのロックのスコープ内にあるリソースを識別しなければなりません (MUST)。
Note that use of the Lock-Token header to provide the lock token is not consistent with other state-changing methods, which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally, when the If header is present, it has its normal meaning as a conditional header.
ロックトークンを提供するためにロックトークンヘッダーを使用することは、すべての状態変化する方法と一致しないことに注意してください。したがって、ロックトークンを提供するためにヘッダーが必要ありません。当然、ヘッダーが存在する場合、条件付きヘッダーとしての通常の意味があります。
For a successful response to this method, the server MUST delete the lock entirely.
このメソッドへのレスポンスを成功とする場合、サーバーはロック全体を削除しなければなりません (MUST)。
If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request MUST fail.
送信されたlock tokenによってロックされているすべてのリソースをロック解除できない場合、UNLOCKリクエストは失敗しなければなりません (MUST)。
A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists.
ロック解除方法に対する成功した応答は、リソースが必ずしもロック解除されていることを意味しません。これは、指定されたトークンに対応する特定のロックが存在しなくなることを意味します。
Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method.
LOCKメソッドをサポートするDAV準拠リソースは、UNLOCKメソッドをサポートしなければなりません (MUST)。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドはidempotentですが、safeではありません（[RFC2616]のセクション9.1を参照）。このメソッドへのレスポンスをキャッシュしてはなりません (MUST NOT)。
In addition to the general status codes possible, the following status codes have specific applicability to UNLOCK:
可能な一般的なステータスコードに加えて、次のステータスコードには、ロックを解除するための特定の適用性があります。
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body).
204（コンテンツなし） - 通常の成功応答（200 OKではなく、200 OKは応答本体を意味し、ロック解除成功応答には通常ボディが含まれていません）。
400 (Bad Request) - No lock token was provided.
400（悪いリクエスト） - ロックトークンは提供されていません。
403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock.
403（禁止） - 現在認証されているプリンシパルには、ロックを削除する許可がありません。
409 (Conflict), with 'lock-token-matches-request-uri' precondition - The resource was not locked, or the request was made to a Request-URI that was not within the scope of the lock.
409（競合）、「ロックトークンマッチ - リクエスト-uri」の前提条件 - リソースはロックされていないか、ロックの範囲内ではないリクエスト-URIにリクエストが行われました。
>>Request
>>リクエスト
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw"
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock.
この例では、ロックトークン「URN：UUID：A515CFA4-5DA4-22E1-F5B5-00A0451E6BF7」によって識別されたロックは、リソースhttp://example.com/workspace/webdav/info.docから正常に削除されます。このロックには1つ以上のリソースが含まれている場合、ロックはロックに含まれるすべてのリソースから削除されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
すべてのDAVヘッダーは、HTTPヘッダーと同じ基本フォーマットルールに従います。これには、ラインの継続などのルールが含まれ、コンマを使用して同じヘッダーの複数のインスタンスを組み合わせる（または分離する）方法が含まれます。
WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.
WebDAVは、HTTPで定義されているセットに2つの新しい条件付きヘッダーを追加します。IFおよび上書きヘッダー。
DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token
; token is defined in RFC 2616, Section 2.2
Coded-URL = "<" absolute-URI ">"
; No linear whitespace (LWS) allowed in Coded-URL
; absolute-URI defined in RFC 3986, Section 4.3
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV-compliant resources MUST return the DAV header with compliance-class "1" on all OPTIONS responses. In cases where WebDAV is only supported in part of the server namespace, an OPTIONS request to non-WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
レスポンスに現れるこのgeneral-headerは、リソースが規定のDAV schemaおよびprotocolをサポートすることを示します。DAV準拠のすべてのリソースは、すべてのOPTIONSレスポンスでcompliance-class "1"を指定したDAVヘッダーを返さなければなりません (MUST)。サーバー名前空間の一部だけでWebDAVをサポートする場合、"/"を含むWebDAV非対応リソースに対するOPTIONSリクエストでは、WebDAV対応を通知すべきではありません (SHOULD NOT)。
The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness.
値は、リソースがサポートするすべてのcompliance class識別子をコンマで区切ったリストです。class識別子には、Coded-URLまたは[RFC2616]で定義されるtokenを使用できます。識別子の順序は任意です。IETF RFCプロセスで標準化された識別子はtokenですが、それ以外の識別子は一意性を促すためCoded-URLとすべきです (SHOULD)。
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
クラス2または3のコンプライアンスが表示される場合、リソースはクラス1のコンプライアンスを表示する必要があります。一般に、1つのコンプライアンスクラスのサポートには、他のコンプライアンスクラスのサポートは必要ありません。特に、コンプライアンスクラス3のサポートには、コンプライアンスクラス2のサポートは必要ありません。この仕様で定義されているコンプライアンスクラスの詳細については、セクション18を参照してください。
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
多くのWebDAVサーバーは、「オプション *」に応じてWebDAVサポートを宣伝していないことに注意してください。
As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.
リクエストヘッダーとして使用すると、このヘッダーにより、サーバーが情報を必要とする場合に、クライアントは名前付き機能への準拠を通知できます。standards track仕様で要求されない限り、クライアントはこのヘッダーを送信すべきではありません (SHOULD NOT)。これをリクエストヘッダーとして使用する拡張では、キャッシュへの影響を慎重に検討する必要があります。
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its internal members only ("Depth: 1"), or the resource and all its members ("Depth: infinity").
深度要求ヘッダーは、メソッドがリソース（「深さ：0」）にのみ適用されるかどうかを示すために内部メンバーを潜在的に持つ可能性のあるリソースで実行されたメソッドで使用されます。1 "）、またはリソースとそのすべてのメンバー（「深さ：無限」）。
The Depth header is only supported if a method's definition explicitly provides for such support.
深度ヘッダーは、メソッドの定義がそのようなサポートを明示的に提供する場合にのみサポートされます。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
次のルールは、深度ヘッダーをサポートする任意の方法のデフォルトの動作です。メソッドは、その定義で異なる動作を定義することにより、これらのデフォルトをオーバーライドする場合があります。
Methods that support the Depth header may choose not to support all of the header's values and may define, on a case-by-case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity", and if a Depth header is not present, it will act as if a "Depth: infinity" header had been applied.
深度ヘッダーをサポートする方法は、ヘッダーのすべての値をサポートしないように選択し、深さヘッダーが存在しない場合のメソッドの動作をケースごとに定義する場合があります。たとえば、移動方法は「深さ：無限」のみをサポートし、深さヘッダーが存在しない場合、「深さ：無限」ヘッダーが適用されているかのように機能します。
Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees.
特定のメソッドが明示的に保証しない限り、クライアントは、階層のmemberに対してメソッドが特定の順序で実行されることにも、実行がatomicであることにも依存してはなりません (MUST NOT)。
Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do.
実行されると、深さヘッダーを備えたメソッドは、割り当てられたタスクをできるだけ多く実行し、達成できるものと何ができなかったかを指定する応答を返します。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
したがって、たとえば、階層をコピーしようとすると、一部のメンバーがコピーされ、一部が存在しない場合があります。
By default, the Depth header does not interact with other headers. That is, each header on a request with a Depth header MUST be applied only to the Request-URI if it applies to any resource, unless specific Depth behavior is defined for that header.
デフォルトでは、Depthヘッダーは他のヘッダーと相互作用しません。すなわち、あるヘッダーについてDepth固有の動作が定義されていない限り、Depthヘッダーを持つリクエストの各ヘッダーは、何らかのリソースに適用される場合でもRequest-URIだけに適用しなければなりません (MUST)。
If a source or destination resource within the scope of the Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
Depthヘッダーのスコープ内にあるsourceまたはdestinationリソースが、メソッドの正常な実行を妨げる形でロックされている場合、そのリソースのlock tokenをリクエストのIfヘッダーで送信しなければなりません (MUST)。
The Depth header only specifies the behavior of the method with regards to internal members. If a resource does not have internal members, then the Depth header MUST be ignored.
Depthヘッダーは、internal memberに関するメソッドの動作だけを指定します。リソースにinternal memberがなければ、Depthヘッダーを無視しなければなりません (MUST)。
The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters.
宛先要求ヘッダーは、2つのURIをパラメーターとして使用するコピーアンドモーブなどのメソッドの宛先リソースを識別するURIを指定します。
Destination = "Destination" ":" Simple-ref
If the Destination value is an absolute-URI (Section 4.3 of [RFC3986]), it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g., specific error conditions).
Destination値がabsolute-URI（[RFC3986]のセクション4.3）の場合、別のサーバー（または別のportやscheme）を指定できます。sourceサーバーがremoteサーバーへのコピーを試みられない場合、そのリクエストを失敗させなければなりません (MUST)。remoteサーバーへのリソースのコピーおよび移動は、本仕様では完全に定義されていないことに注意してください（たとえば、具体的なエラー条件などです）。
If the Destination value is too long or otherwise unacceptable, the server SHOULD return 400 (Bad Request), ideally with helpful information in an error body.
Destination値が長すぎる場合、またはほかの理由で受け入れられない場合、サーバーは400 (Bad Request)を返すべきです (SHOULD)。error bodyに有用な情報を含めることが理想的です。
The If request header is intended to have similar functionality to the If-Match header defined in Section 14.24 of [RFC2616]. However, the If header handles any state token as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
IF要求ヘッダーは、[RFC2616]のセクション14.24で定義されているIFマッチヘッダーと同様の機能を持つことを目的としています。ただし、ヘッダーは任意の状態トークンとetagsを処理します。状態トークンの典型的な例はロックトークンであり、ロックトークンは、この仕様で定義されている唯一の状態トークンです。
The If header has two distinct purposes:
ヘッダーには2つの異なる目的があります。
o The first purpose is to make a request conditional by supplying a series of state lists with conditions that match tokens and ETags to a specific resource. If this header is evaluated and all state lists fail, then the request MUST fail with a 412 (Precondition Failed) status. On the other hand, the request can succeed only if one of the described state lists succeeds. The success criteria for state lists and matching functions are defined in Sections 10.4.3 and 10.4.4.
o 第1の目的は、tokenおよびETagを特定のリソースと照合する条件を持つ一連のstate listを指定し、リクエストを条件付きにすることです。このヘッダーを評価してすべてのstate listが失敗した場合、リクエストは412 (Precondition Failed)ステータスで失敗しなければなりません (MUST)。一方、記述されたstate listのいずれかが成功した場合に限り、リクエストは成功できます。state listおよびmatching functionの成功条件は、セクション10.4.3と10.4.4で定義します。
o Additionally, the mere fact that a state token appears in an If header means that it has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The semantics for submitting a state token depend on its type (for lock tokens, please refer to Section 6).
o さらに、状態トークンがIFヘッダーに表示されるという事実は、リクエストで「提出」されたことを意味します。一般に、これはクライアントがその状態トークンの知識を持っていることを示すために使用されます。状態トークンを送信するためのセマンティクスは、そのタイプに依存します（ロックトークンについては、セクション6を参照してください）。
Note that these two purposes need to be treated distinctly: a state token counts as being submitted independently of whether the server actually has evaluated the state list it appears in, and also independently of whether or not the condition it expressed was found to be true.
これらの2つの目的は明確に扱う必要があることに注意してください。状態トークンは、サーバーが実際に表示される状態リストを実際に評価したかどうかとは無関係に提出されているとカウントされます。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
No-tag-list = List
Tagged-list = Resource-Tag 1*List
List = "(" 1*Condition ")"
Condition = ["Not"] (State-token | "[" entity-tag "]")
; entity-tag: see Section 3.11 of [RFC2616]
; No LWS allowed between "[", entity-tag and "]"
State-token = Coded-URL
Resource-Tag = "<" Simple-ref ">"
; Simple-ref: see Section 8.3
; No LWS allowed in Resource-Tag
The syntax distinguishes between untagged lists ("No-tag-list") and tagged lists ("Tagged-list"). Untagged lists apply to the resource identified by the Request-URI, while tagged lists apply to the resource identified by the preceding Resource-Tag.
構文は、タグ付きリスト（「ノータグリスト」）とタグ付きリスト（「タグ付きリスト」）を区別します。未積載リストは、リクエスト-URIによって識別されたリソースに適用され、タグ付きリストは前のリソースタグによって識別されたリソースに適用されます。
A Resource-Tag applies to all subsequent Lists, up to the next Resource-Tag.
次のリソースタグまで、リソースタグが後続のすべてのリストに適用されます。
Note that the two list types cannot be mixed within an If header. This is not a functional restriction because the No-tag-list syntax is just a shorthand notation for a Tagged-list production with a Resource-Tag referring to the Request-URI.
2つのリストタイプは、IFヘッダー内で混合できないことに注意してください。これは機能的な制限ではありません。なぜなら、ノータグリストの構文は、Request-URIを参照するリソースタグを備えたタグ付きリストの生成の略歴表記にすぎないためです。
Each List consists of one or more Conditions. Each Condition is defined in terms of an entity-tag or state-token, potentially negated by the prefix "Not".
各リストは、1つ以上の条件で構成されています。各条件は、エンティティタグまたは状態トークンに関して定義され、潜在的にプレフィックス「not」によって否定されます。
Note that the If header syntax does not allow multiple instances of If headers in a single request. However, the HTTP header syntax allows extending single header values across multiple lines, by inserting a line break followed by whitespace (see [RFC2616], Section 4.2).
IF Header構文では、単一のリクエストでヘッダーの複数のインスタンスを許可しないことに注意してください。ただし、HTTPヘッダー構文により、複数の行に単一のヘッダー値を拡張できます。これに続いて、その後の白人が続くラインブレークを挿入します（[RFC2616]、セクション4.2を参照）。
A Condition that consists of a single entity-tag or state-token evaluates to true if the resource matches the described state (where the individual matching functions are defined below in Section 10.4.4). Prefixing it with "Not" reverses the result of the evaluation (thus, the "Not" applies only to the subsequent entity-tag or state-token).
単一のエンティティタグまたは状態のトークンで構成される条件は、リソースが説明された状態と一致する場合に真の評価を評価します（個々の一致関数は、セクション10.4.4で以下に定義されています）。「not」で接頭すると、評価の結果が逆転します（したがって、「not」は後続のエンティティタグまたは州のトークンにのみ適用されます）。
Each List production describes a series of conditions. The whole list evaluates to true if and only if each condition evaluates to true (that is, the list represents a logical conjunction of Conditions).
各リスト生産は、一連の条件について説明します。リスト全体は、各条件がtrueに評価された場合にのみTrueに評価されます（つまり、リストは条件の論理的接続性を表します）。
Each No-tag-list and Tagged-list production may contain one or more Lists. They evaluate to true if and only if any of the contained lists evaluates to true (that is, if there's more than one List, that List sequence represents a logical disjunction of the Lists).
各ノータグリストとタグ付きリストの生成には、1つ以上のリストが含まれる場合があります。含まれているリストのいずれかがTrueに評価された場合にのみTrueを評価します（つまり、複数のリストがある場合、そのリストシーケンスはリストの論理的な分離を表します）。
Finally, the whole If header evaluates to true if and only if at least one of the No-tag-list or Tagged-list productions evaluates to true. If the header evaluates to false, the server MUST reject the request with a 412 (Precondition Failed) status. Otherwise, execution of the request can proceed as if the header wasn't present.
最後に、Ifヘッダー全体がtrueと評価されるのは、No-tag-listまたはTagged-list生成規則の少なくとも1つがtrueと評価される場合に限ります。ヘッダーがfalseと評価された場合、サーバーは412 (Precondition Failed)ステータスでリクエストを拒否しなければなりません (MUST)。それ以外の場合は、ヘッダーが存在しなかったものとしてリクエストの実行を続行できます。
When performing If header processing, the definition of a matching state token or entity tag is as follows:
ヘッダー処理を実行する場合、一致する状態トークンまたはエンティティタグの定義は次のとおりです。
Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production.
リソースの識別：リソースは、URIとトークン、タグ付きリストの生産、または未編集リストの生産のリクエストURIによって識別されます。
Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Servers MUST use either the weak or the strong comparison function defined in Section 13.3.3 of [RFC2616].
Matching entity tag：entity tagが、識別されたリソースに関連付けられたentity tagと一致する場合です。サーバーは、[RFC2616]のセクション13.3.3で定義されるweak比較関数またはstrong比較関数のいずれかを使用しなければなりません (MUST)。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
一致する状態トークン：IFヘッダーの状態トークンと特定されたリソースの任意の状態トークンの間に正確な一致があります。ロック状態トークンは、リソースがロックの範囲内のどこにでもある場合に一致すると見なされます。
Handling unmapped URLs: For both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state.
マップされていないURLの処理：ETAGSと状態トークンの両方について、URLが存在するが指定された状態を持たないリソースを識別したかのように扱います。
Non-DAV-aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the client MUST use the "Cache-Control: no-cache" request header so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no-cache" request header MUST be used for the same reason.
DAVを認識しないproxyはIfヘッダーを理解せず、HTTPでは理解できないヘッダーを無視することが要求されているため、Ifヘッダーに従いません。HTTP/1.1 proxyと通信する場合、proxyがキャッシュから不適切にリクエストへ応答するのを防ぐため、クライアントは"Cache-Control: no-cache"リクエストヘッダーを使用しなければなりません (MUST)。HTTP/1.0 proxyを扱う場合も、同じ理由で"Pragma: no-cache"リクエストヘッダーを使用しなければなりません (MUST)。
Because in general clients may not be able to reliably detect non-DAV-aware intermediates, they are advised to always prevent caching using the request directives mentioned above.
一般的には、クライアントは非davに認識されていない中間体を確実に検出できない可能性があるため、上記のリクエストディレクティブを使用して常にキャッシュを防ぐことをお勧めします。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"])
(["I am another ETag"])
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and be in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag".
前のヘッダーは、リクエスト-URIで識別されたリソースを指定されたロックトークンでロックし、「私はETAG」ETAGによって識別される状態であるか、2番目のETAGによって識別された状態であることを要求します。「。
To put the matter more plainly one can think of the previous If header as expressing the condition below:
この問題をより明確に置くために、以前のヘッダーが以下の条件を表現すると考えることができます。
( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") )
（is-locked-with（urn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2）およびmatches-etag（ "i a etag"））
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a lock having the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a lock with the lock token urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
これは、リソースをロックトークンurn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2を持つロックでリソースをロックしないことを要求し、ロックトークンurn：uuid：uuid：58f202ac-22cf-でロックする必要があります。11D1-B12D-002035B29092。
There may be cases where a client wishes to submit state tokens, but doesn't want the request to fail just because the state token isn't current anymore. One simple way to do this is to include a Condition that is known to always evaluate to true, such as in:
クライアントが州のトークンを提出したい場合がありますが、状態トークンがもう最新ではないという理由だけで、リクエストを失敗させたくない場合があります。これを行う簡単な方法の1つは、以下のように、常に真であることを評価することが知られている条件を含めることです。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
(Not <DAV:no-lock>)
"DAV:no-lock" is known to never represent a current lock token. Lock tokens are assigned by the server, following the uniqueness requirements described in Section 6.5, therefore cannot use the "DAV:" scheme. Thus, by applying "Not" to a state token that is known not to be current, the Condition always evaluates to true. Consequently, the whole If header will always evaluate to true, and the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in any case.
「Dav：No-Lock」は、現在のロックトークンを表していないことが知られています。ロックトークンは、セクション6.5で説明されている一意性要件に従って、サーバーによって割り当てられます。したがって、「DAV：」スキームを使用できません。したがって、最新ではないことが知られている状態トークンに「NOT」を適用することにより、条件は常に真であると評価します。その結果、ヘッダー全体が常にtrueに評価され、ロックトークンurn：uuid：181D4FAE-7D8C-11D0-A765-00A0C91E6BF2が提出されます。
>>Request
>>リクエスト
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: /resource2
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
In this example, http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])". That is, either it must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
この例では、http：//www.example.com/resource1がhttp://www.example.com/resource2にコピーされています。メソッドが最初にhttp://www.example.com/resource1に適用された場合、Resource1は「（<urn：uuid：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2>」によって指定された状態にある必要があります。etag "]）（[" strong etag "]）"。つまり、「urn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf22」のロックトークンでロックする必要があり、「弱いエタグ」w/「弱いエンティティタグが必要です」強いetag」。
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked by a lock with the specified lock token, the request MUST fail. Otherwise, this request could succeed, because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been submitted.
この例では、lock tokenを識別対象のリソースと比較する必要があります。そのリソースは、Tagged-list生成規則内のURLで識別される'specs' collectionです。指定されたlock tokenを持つロックによって'specs' collectionがロックされていない場合、リクエストは失敗しなければなりません (MUST)。それ以外の場合は、Ifヘッダーがtrueと評価され、対象リソースに影響するロックのlock tokenが送信されているため、このリクエストは成功し得ます。
Consider a collection "/specs" that does not contain the member "/specs/rfc2518.doc". In this case, the If header
メンバー「/specs/rfc2518.doc」を含まないコレクション「/仕様」を検討してください。この場合、IFヘッダー
If: </specs/rfc2518.doc> (["4217"])
will evaluate to false (the URI isn't mapped, thus the resource identified by the URI doesn't have an entity matching the ETag "4217").
falseに評価されます（URIはマッピングされていないため、URIによって識別されるリソースには、ETAG「4217」と一致するエンティティがありません）。
On the other hand, an If header of
一方、ヘッダー
If: </specs/rfc2518.doc> (Not ["4217"])
will consequently evaluate to true.
したがって、trueに評価します。
Note that, as defined above in Section 10.4.4, the same considerations apply to matching state tokens.
上記のセクション10.4.4で定義されているように、同じ考慮事項が一致する状態トークンにも当てはまることに注意してください。
Lock-Token = "Lock-Token" ":" Coded-URL
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.
Lock-Tokenリクエストヘッダーは、UNLOCKメソッドで削除対象のロックを識別するために使用します。Lock-Tokenリクエストヘッダー内のlock tokenは、Request-URIで識別されるリソースをmemberとして含むロックを識別しなければなりません (MUST)。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
ロックトークン応答ヘッダーは、ロックメソッドとともに使用され、新しいロックを作成するためのロック要求が成功した結果として作成されたロックトークンを示します。
Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the destination URL does map to a resource. If the overwrite header is not included in a COPY or MOVE request, then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of using an "If-Match: *" header (see [RFC2616]), If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
Overwriteリクエストヘッダーは、COPYまたはMOVEの際に、destination URLへマッピングされたリソースをサーバーが上書きするかどうかを指定します。値"F"は、destination URLがリソースへマッピングされている場合、サーバーがCOPYまたはMOVE操作を実行してはならないことを示します。COPYまたはMOVEリクエストにOverwriteヘッダーが含まれていない場合、リソースは、値が"T"のOverwriteヘッダーがあるものとしてリクエストを扱わなければなりません (MUST)。Overwriteヘッダーは"If-Match: *"ヘッダー（[RFC2616]を参照）の機能と重複しているように見えますが、If-Matchが適用されるのはRequest-URIだけであり、COPYまたはMOVEのDestinationには適用されません。
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this or any conditional header.
Overwriteヘッダーの値が原因でCOPYまたはMOVEを実行しない場合、メソッドは412 (Precondition Failed)ステータスコードで失敗しなければなりません (MUST)。サーバーは、このヘッダーまたは他の条件ヘッダーを確認する前に認可検査を行わなければなりません (MUST)。
All DAV-compliant resources MUST support the Overwrite header.
DAV準拠のすべてのリソースは、Overwriteヘッダーをサポートしなければなりません (MUST)。
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT
Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
クライアントは、LOCKリクエストにTimeoutリクエストヘッダーを含めてもよい (MAY)。ただし、サーバーには、その要求に従うことも考慮することも要求されません。クライアントは、LOCKメソッド以外のメソッドでTimeoutリクエストヘッダーを送信してはなりません (MUST NOT)。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
"Second" TimeTypeは、サーバーがロックを付与してから、そのロックを自動的に削除するまでに経過する秒数を指定します。TimeType "Second"のtimeout値は2^32-1を超えてはなりません (MUST NOT)。
See Section 6.6 for a description of lock timeout behavior.
ロックタイムアウト動作の説明については、セクション6.6を参照してください。
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
次のステータスコードは、HTTP/1.1 [RFC2616]で定義されているものに追加されます。
The 207 (Multi-Status) status code provides status for multiple independent operations (see Section 13 for more information).
207（マルチステータス）ステータスコードは、複数の独立操作のステータスを提供します（詳細についてはセクション13を参照）。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
422（処理不可能なエンティティ）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解することを意味します（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切です）。）ステータスコードは不適切です）が、含まれている命令を処理できませんでした。たとえば、XMLリクエスト本体によく形成された（つまり、構文的に正しい）が、意味的に誤ったXML命令が含まれている場合、このエラー条件が発生する場合があります。
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
423 (Locked)ステータスコードは、メソッドのsourceまたはdestinationリソースがロックされていることを意味します。このレスポンスには、'lock-token-submitted'や'no-conflicting-lock'など、適切な事前条件または事後条件コードを含めるべきです (SHOULD)。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失敗した依存関係）ステータスコードは、要求されたアクションが別のアクションに依存し、そのアクションが失敗したため、メソッドをリソース上で実行できなかったことを意味します。たとえば、プロップパッチメソッドのコマンドが失敗した場合、少なくとも、残りのコマンドも424で失敗します（依存関係の失敗）。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507 (Insufficient Storage)ステータスコードは、リクエストを正常に完了するために必要なrepresentationをサーバーが格納できず、リソースに対してメソッドを実行できなかったことを意味します。この状態は一時的なものと見なされます。このステータスコードを受信したリクエストがユーザー操作によるものであった場合、別のユーザー操作で要求されるまで、そのリクエストを再実行してはなりません (MUST NOT)。
These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.
これらのHTTPコードは再定義されませんが、その用途はWebDAVのメソッドおよび要件によって多少拡張されます。一般に、多くのHTTPステータスコードは、本書で説明する場合に限らず、任意のリクエストへのレスポンスに使用できます。WebDAVサーバーが300番台のリダイレクトレスポンスを使用することも知られています（初期の相互運用性試験では、そのようなレスポンスに対応できないクライアントが見つかりました）。サーバーがリクエストに応じて新しいリソースを作成した場合、300番台のレスポンスを使用してはなりません (MUST NOT)。
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.
任意のリクエストに、HTTPで定義された条件ヘッダー（If-Match、If-Modified-Sinceなど）、または本仕様で定義する"If"や"Overwrite"条件ヘッダーを含めることができます。サーバーが条件ヘッダーを評価し、その条件が成立しなかった場合、このエラーコードを返さなければなりません (MUST)。一方、クライアントがリクエストに条件ヘッダーを含めていなければ、サーバーはこのステータスコードを使用してはなりません (MUST NOT)。
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
このステータスコードは、他の場所のurisではなく、リクエスト-urisに対してのみHTTP 1.1で使用されます。
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.
Multi-Statusレスポンスは、複数のステータスコードが適切となり得る状況で、複数のリソースに関する情報を伝えます。デフォルトのMulti-Status response bodyは、'multistatus'ルート要素を持つtext/xmlまたはapplication/xmlのHTTP entityです。後続の要素には、メソッド呼び出し中に生成された200番台、300番台、400番台、および500番台のステータスコードが含まれます。100番台のステータスコードを'response' XML要素に記録すべきではありません (SHOULD NOT)。
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.
全体のレスポンスステータスコードには'207'を使用しますが、メソッド実行の成功または失敗に関する詳細情報を得るには、受信者がmultistatus response bodyの内容を確認する必要があります。このレスポンスは、成功、部分的成功、および失敗の各状況で使用してもよい (MAY)。
The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.
'multistatus'ルート要素は、任意の順序で0個以上の'response'要素を保持し、各要素には個々のリソースに関する情報が含まれます。各'response'要素は、リソースを識別する'href'要素を持たなければなりません (MUST)。
A Multi-Status response uses one out of two distinct formats for representing the status:
マルチステータス応答は、ステータスを表すために2つの異なる形式のうち1つを使用します。
1. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616].
1. 'response'要素の子である'status'要素は、識別されたリソース全体について、メッセージ実行のステータスを示します（たとえば、セクション9.6.2を参照）。一部のメソッド定義では、クライアントがレスポンスで受け取る可能性に備えるべき特定のステータスコードを示しています。ただし、クライアントは、[RFC2616]のセクション10で定義される一般規則を使用して、ほかのステータスコードも処理できなければなりません (MUST)。
2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.
2. PropfindおよびProppatchの場合、形式は「ステータス」ではなく「PropStat」要素を使用して拡張され、リソースの個々のプロパティに関する情報を提供します。この形式は、PropfindおよびProppatchに固有のものであり、セクション9.1および9.2で詳細に説明されています。
HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g., in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined.
HTTPは、リクエスト-URIで対処されたリソースの優先URLを示すための位置ヘッダーを定義します（たとえば、パットリクエストの成功に応じて、またはリダイレクト応答）。ただし、このヘッダーの使用は、マルチスタタスと同様に、応答の本体にURLがある場合に曖昧さを生み出します。したがって、マルチステータス応答を使用したロケーションヘッダーの使用は、意図的に定義されていません。
Redirect responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in [RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status.
HTTP 1.1で定義されるリダイレクトレスポンス（300～303、305、および307）は通常、Request-URIからリダイレクトされた1つのリソースについて、新しいURIを示すLocationヘッダーを伴います。Multi-Statusレスポンスには多数のリソースアドレスが含まれますが、[RFC2518]の元の定義には、リダイレクトされたリソースの新しいURIをサーバーが示す場所がありませんでした。本仕様は、この情報のために'location'要素を定義します（セクション14.9を参照）。サーバーは、Multi-Status内のリダイレクトレスポンスでこの新しい要素を使用しなければなりません (MUST)。
Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI.
Multi-Status内でリダイレクトされたリソースに遭遇したクライアントは、新しいURIを伴う'location'要素が存在することに依存してはなりません (MUST NOT)。その要素がない場合、個別にリダイレクトされたリソースへリクエストを再送すると、そのレスポンスを新しいURIを含むLocationヘッダーでリダイレクトできるため、クライアントはリクエストを再送してもよい (MAY)。
Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
セクション9.2.1、9.1.2、9.6.1、9.8.3、および9.9.2は、マルチステータス応答で使用されるさまざまなステータスコードを定義します。この仕様は、これらの応答に表示される可能性のある他のステータスコードの意味を定義しません。
In this section, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that all of the elements defined here may be extended according to the rules defined in Section 17. All elements defined here are in the "DAV:" namespace.
このセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容される内容のさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。ここで定義されているすべての要素は、セクション17で定義されているルールに従って拡張される可能性があることに注意してください。ここで定義されているすべての要素は「DAV：」名前空間にあります。
Name: activelock
名前：ActiveLock
Purpose: Describes a lock on a resource.
目的：リソースのロックについて説明します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?, lockroot)>
<！要素activelock（lockscope、locktype、depth、owner？、timeout？、locktoken？、lockroot）>
Name: allprop
名前：AllProp
Purpose: Specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned.
目的：リソースに存在するこのドキュメントで定義されているデッドプロパティのすべての名前と値と、返されることを指定します。
<!ELEMENT allprop EMPTY >
Name: collection
名前：コレクション
Purpose: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements.
目的：関連付けられたリソースをcollectionとして識別します。collectionリソースのDAV:resourcetypeプロパティは、この要素を含まなければなりません (MUST)。通常は空ですが、拡張によって子要素を追加できます。
<!ELEMENT collection EMPTY >
Name: depth
名前：深さ
Purpose: Used for representing depth values in XML content (e.g., in lock information).
目的：XMLコンテンツの深さ値を表すために使用されます（例：ロック情報）。
Value: "0" | "1" | "infinity"
<!ELEMENT depth (#PCDATA) >
Name: error
名前：エラー
Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. In these cases, servers MAY return an XML response body with a document element of 'error', containing child elements identifying particular condition codes.
目的：エラーレスポンス、特に403 Forbiddenおよび409 Conflictでは、何が問題だったかを示すために追加情報が必要な場合があります。この場合、サーバーは、特定のcondition codeを識別する子要素を格納した'error'文書要素を持つXML response bodyを返してもよい (MAY)。
Description: Contains at least one XML element, and MUST NOT contain text or mixed content. Any element that is a child of the 'error' element is considered to be a precondition or postcondition code. Unrecognized elements MUST be ignored.
説明：少なくとも1つのXML要素を含み、text contentまたはmixed contentを含めてはなりません (MUST NOT)。'error'要素の子であるすべての要素を、事前条件または事後条件コードと見なします。認識できない要素は無視しなければなりません (MUST)。
<!ELEMENT error ANY >
Name: exclusive
名前：排他的
Purpose: Specifies an exclusive lock.
目的：排他的ロックを指定します。
<!ELEMENT exclusive EMPTY >
Name: href
名前：href
Purpose: MUST contain a URI or a relative reference.
目的：URIまたは相対参照を含めなければなりません (MUST)。
Description: There may be limits on the value of 'href' depending on the context of its use. Refer to the specification text where 'href' is used to see what limitations apply in each case.
説明：使用のコンテキストに応じて、「HREF」の価値に制限がある場合があります。「HREF」が使用されて、それぞれの場合にどのような制限が適用されるかを確認する仕様テキストを参照してください。
Value: Simple-ref
値：simple-ref
<!ELEMENT href (#PCDATA)>
Name: include
名前：include
Purpose: Any child element represents the name of a property to be included in the PROPFIND response. All elements inside an 'include' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
目的：各子要素は、PROPFINDレスポンスに含めるプロパティの名前を表します。'include' XML要素内のすべての要素は、リソースに関連するプロパティを定義しなければなりません (MUST)。ただし、指定可能なプロパティ名は、本書や他の標準で定義される名前に一切限定されません。この要素にはtext contentまたはmixed contentを含めてはなりません (MUST NOT)。
<!ELEMENT include ANY >
Name: location
名前：場所
Purpose: HTTP defines the "Location" header (see [RFC2616], Section 14.30) for use with some status codes (such as 201 and the 300 series codes). When these codes are used inside a 'multistatus' element, the 'location' element can be used to provide the accompanying Location header value.
目的：HTTPは、一部のステータスコード（201や300シリーズコードなど）で使用するために「場所」ヘッダー（[RFC2616]、セクション14.30を参照）を定義します。これらのコードが「Multistatus」要素内で使用される場合、「位置」要素を使用して、添付のロケーションヘッダー値を提供できます。
Description: Contains a single href element with the same value that would be used in a Location header.
説明：ロケーションヘッダーで使用される同じ値を持つ単一のHREF要素が含まれています。
<!ELEMENT location (href)>
Name: lockentry
名前：Lockentry
Purpose: Defines the types of locks that can be used with the resource.
目的：リソースで使用できるロックの種類を定義します。
<!ELEMENT lockentry (lockscope, locktype) >
Name: lockinfo
名前：lockinfo
Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
目的：「lockinfo」XML要素は、クライアントが作成したいロックのタイプを指定するためにロックメソッドで使用されます。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
Name: lockroot
名前：Lockroot
Purpose: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.
目的：ロックのルートURLが含まれています。これは、ロックリクエストでリソースがアドレス指定されたURLです。
Description: The href element contains the root of the lock. The server SHOULD include this in all DAV:lockdiscovery property values and the response to LOCK requests.
説明：href要素にはlock-rootが含まれます。サーバーは、すべてのDAV:lockdiscoveryプロパティ値とLOCKリクエストへのレスポンスに、この要素を含めるべきです (SHOULD)。
<!ELEMENT lockroot (href) >
Name: lockscope
名前：Lockscope
Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
目的：ロックが排他的ロックなのか、共有ロックなのかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
Name: locktoken
名前：LockToken
Purpose: The lock token associated with a lock.
目的：ロックに関連付けられたロックトークン。
Description: The href contains a single lock token URI, which refers to the lock.
説明：HREFには、ロックを指す単一のロックトークンURIが含まれています。
<!ELEMENT locktoken (href) >
Name: locktype
名前：LockType
Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
目的：ロックのアクセスタイプを指定します。現在、この仕様では、1つのロックタイプ、つまり書き込みロックのみを定義しています。
<!ELEMENT locktype (write) >
Name: multistatus
名前：Multistatus
Purpose: Contains multiple response messages.
目的：複数の応答メッセージが含まれます。
Description: The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available, an application may use it instead of presenting the individual response descriptions contained within the responses.
説明：上部レベルの「ressiondesscription」要素は、応答の包括的な性質を説明する一般的なメッセージを提供するために使用されます。この値が利用可能な場合、応答内に含まれる個々の応答の説明を提示する代わりに、アプリケーションが使用する場合があります。
<!ELEMENT multistatus (response*, responsedescription?) >
Name: owner
名前：所有者
Purpose: Holds client-supplied information about the creator of a lock.
目的：ロックの作成者に関するクライアントが提供する情報を保持します。
Description: Allows a client to provide information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who created a lock. The value provided MUST be treated as a dead property in terms of XML Information Item preservation. The server MUST NOT alter the value unless the owner value provided by the client is empty. For a certain amount of interoperability between different client implementations, if clients have URI-formatted contact information for the lock creator suitable for user display, then clients SHOULD put those URIs in 'href' child elements of the 'owner' element.
説明：ロックを作成したprincipalへ直接連絡するための情報（電話番号やEmail URIなど）、またはそのprincipalを発見するための情報（ホームページのURLなど）を、クライアントが提供できるようにします。提供された値は、XML Information Itemの保持に関してdead propertyとして扱わなければなりません (MUST)。クライアントが指定したowner値が空でない限り、サーバーはその値を変更してはなりません (MUST NOT)。異なるクライアント実装間で一定の相互運用性を確保するため、ロック作成者についてユーザー表示に適したURI形式の連絡先情報がある場合、クライアントはそれらのURIを'owner'要素の'href'子要素に格納すべきです (SHOULD)。
Extensibility: MAY be extended with child elements, mixed content, text content or attributes.
拡張性：子要素、mixed content、text content、または属性によって拡張してもよい (MAY)。
<!ELEMENT owner ANY >
Name: prop
名前：小道具
Purpose: Contains properties related to a resource.
目的：リソースに関連するプロパティが含まれています。
Description: A generic container for properties defined on resources. All elements inside a 'prop' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
説明：リソースに定義されたプロパティの汎用containerです。'prop' XML要素内のすべての要素は、リソースに関連するプロパティを定義しなければなりません (MUST)。ただし、指定可能なプロパティ名は、本書や他の標準で定義される名前に一切限定されません。この要素にはtext contentまたはmixed contentを含めてはなりません (MUST NOT)。
<!ELEMENT prop ANY >
Name: propertyupdate
名前：PropertyUpDate
Purpose: Contains a request to alter the properties on a resource.
目的：リソース上のプロパティを変更するリクエストが含まれています。
Description: This XML element is a container for the information required to modify the properties on the resource.
説明：このXML要素は、リソース上のプロパティを変更するために必要な情報のコンテナです。
<!ELEMENT propertyupdate (remove | set)+ >
Name: propfind
Purpose: Specifies the properties to be returned from a PROPFIND
method. Four special elements are specified for use with
'propfind': 'prop', 'allprop', 'include', and 'propname'. If
'prop' is used inside 'propfind', it MUST NOT contain property
values.
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
Name: propname
名前：Propname
Purpose: Specifies that only a list of property names on the resource is to be returned.
目的：リソース上のプロパティ名のリストのみが返されることを指定します。
<!ELEMENT propname EMPTY >
Name: propstat
名前：Propstat
Purpose: Groups together a prop and status element that is associated with a particular 'href' element.
目的：特定の「HREF」要素に関連付けられているプロップとステータス要素をグループ化します。
Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. The optional precondition/ postcondition element and 'responsedescription' text also apply to the properties named in 'prop'.
説明：propstat XML要素は、prop XML要素を1つとstatus XML要素を1つ含まなければなりません (MUST)。prop XML要素の内容には、status要素内の結果が適用されるプロパティ名だけを列挙しなければなりません (MUST)。任意のprecondition/postcondition要素および'responsedescription'テキストも、'prop'内で指定されたプロパティに適用されます。
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
Name: remove
名前：削除します
Purpose: Lists the properties to be removed from a resource.
目的：リソースから削除するプロパティをリストします。
Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a 'prop' XML element inside of a 'remove' XML element MUST be empty, as only the names of properties to be removed are required.
説明：removeは、propで指定されたプロパティを削除するよう指示します。存在しないプロパティの削除を指定してもエラーではありません。削除するプロパティ名だけが必要なので、'remove' XML要素内の'prop' XML要素にあるすべてのXML要素は空でなければなりません (MUST)。
<!ELEMENT remove (prop) >
Name: response
名前：応答
Purpose: Holds a single response describing the effect of a method on resource and/or its properties.
目的：リソースおよび/またはそのプロパティに対するメソッドの効果を説明する単一の応答を保持します。
Description: The 'href' element contains an HTTP URL pointing to a WebDAV resource when used in the 'response' container. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by 'href'. There are, however, no requirements regarding ordering based on 'href' values. The optional precondition/postcondition element and 'responsedescription' text can provide additional information about this resource relative to the request or result.
説明：'response' container内で使用する場合、'href'要素にはWebDAVリソースを指すHTTP URLが含まれます。ある'href'値は、'multistatus' XML要素の下にある'response' XML要素の子として複数回現れてはなりません (MUST NOT)。この要件は、レスポンスの処理コストを線形時間に保つために必要です。つまり、'href'ごとにすべてのレスポンスをまとめるための検索が不要になります。ただし、'href'値に基づく順序について要件はありません。任意のprecondition/postcondition要素および'responsedescription'テキストは、リクエストまたは結果に関連する当該リソースの追加情報を提供できます。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) >
Name: responsedescription
名前：ressionedescription
Purpose: Contains information about a status response within a Multi-Status.
目的：マルチステータス内のステータス応答に関する情報が含まれています。
Description: Provides information suitable to be presented to a user.
説明：ユーザーに提示するのに適した情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
Name: set
名前：セット
Purpose: Lists the property values to be set for a resource.
目的：リソースに設定するプロパティ値をリストします。
Description: The 'set' element MUST contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists, then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
説明：'set'要素は、'prop'要素だけを含まなければなりません (MUST)。'set'要素内の'prop'要素に含まれる各要素は、Request-URIで識別されるリソースに設定するプロパティの名前と値を指定しなければなりません (MUST)。プロパティが既に存在する場合、その値を置き換えます。'prop'要素のスコープ内に現れる言語tag情報（存在する場合は"xml:lang"属性）を、プロパティとともに永続的に格納しなければならず (MUST)、その後PROPFINDで取得できなければなりません (MUST)。
<!ELEMENT set (prop) >
Name: shared
名前：共有
Purpose: Specifies a shared lock.
目的：共有ロックを指定します。
<!ELEMENT shared EMPTY >
Name: status
名前：ステータス
Purpose: Holds a single HTTP status-line.
目的：単一のHTTPステータスラインを保持します。
Value: status-line (defined in Section 6.1 of [RFC2616])
値：ステータスライン（[RFC2616]のセクション6.1で定義）
<!ELEMENT status (#PCDATA) >
Name: timeout
名前：タイムアウト
Purpose: The number of seconds remaining before a lock expires.
目的：ロックが切れる前に残っている秒数。
Value: TimeType (defined in Section 10.7)
値：タイムタイプ（セクション10.7で定義）
<!ELEMENT timeout (#PCDATA) >
Name: write
名前：書き込み
Purpose: Specifies a write lock.
目的：書き込みロックを指定します。
<!ELEMENT write EMPTY >
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
DAVプロパティの場合、プロパティの名前は、その値を含むXML要素の名前と同じです。以下のセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容される内容のさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。
A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource.
保護されたプロパティは、プロップパッチリクエストで変更できないプロパティです。保護されたプロパティに変更される他の要求がある場合があります（ロック要求がDAVの値に影響する場合：Lock -Discovery）。特定のプロパティは、あるタイプのリソースで保護できますが、別のタイプのリソースでは保護されていないことに注意してください。
A computed property is one with a value defined in terms of a computation (based on the content and other properties of that resource, or even of some other resource). A computed property is always a protected property.
計算されたプロパティは、計算の観点から定義された値を持つものです（そのリソースのコンテンツやその他のプロパティ、さらには他のリソースに基づいています）。計算されたプロパティは常に保護されたプロパティです。
COPY and MOVE behavior refers to local COPY and MOVE operations.
動作をコピーして移動すると、ローカルコピーと移動操作を指します。
For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in [RFC2616], Section 4.2. Server implementors SHOULD strip LWS from these values before using as WebDAV property values.
HTTP GETレスポンスヘッダーに基づいて定義されるプロパティ（DAV:get*）では、ヘッダー値に[RFC2616]のセクション4.2で定義されるLWSが含まれる場合があります。サーバー実装者は、WebDAVプロパティ値として使用する前に、これらの値からLWSを除去すべきです (SHOULD)。
Name: creationdate
名前：CreationDate
Purpose: Records the time and date the resource was created.
目的：リソースが作成された時刻と日付を記録します。
Value: date-time (defined in [RFC3339], see the ABNF in Section 5.6.)
値：日付時間（[RFC3339]で定義され、セクション5.6のABNFを参照してください。）
Protected: MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead).
保護：保護してもよい (MAY)。一部のサーバーでは、アップロード時刻より文書の作成時刻の方がユーザーにとって意味がある場合、その時刻を反映するようDAV:creationdateを変更できます。したがって、クライアントはこのプロパティを同期処理に使用すべきではありません (SHOULD NOT)（代わりにDAV:getetagを使用します）。
COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY.
COPY/MOVE時の動作：このプロパティ値はMOVE操作中に保持すべきです (SHOULD) が、COPYによってリソースを作成するときは通常再初期化します。COPYでは設定しないことが望まれます。
Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found").
説明：DAV:creationdateプロパティは、DAV準拠のすべてのリソースに定義すべきです (SHOULD)。存在する場合、リソースを作成した時点のtimestampを含みます。作成日時を永続的に記録できないサーバーは、代わりに未定義のままとすべきです (SHOULD)（すなわち、"Not Found"と報告します）。
<!ELEMENT creationdate (#PCDATA) >
Name: displayname
名前：displayName
Purpose: Provides a name for the resource that is suitable for presentation to a user.
目的：ユーザーへのプレゼンテーションに適したリソースの名前を提供します。
Value: Any text.
値：任意のテキスト。
Protected: SHOULD NOT be protected. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護：保護すべきではありません (SHOULD NOT)。これは新しい要件であるため、[RFC2518]を実装したサーバーでは保護されたプロパティになっている場合があることに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVE時の動作：このプロパティ値は、COPY操作およびMOVE操作で保持すべきです (SHOULD)。
Description: Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV: displayname value even within the same collection.
説明：ユーザーへの提示に適したリソースの説明を含みます。このプロパティはリソース上で定義されるため、取得に使用したRequest-URIにかかわらず同じ値を持つべきです (SHOULD)（したがって、Request-URIに基づいてこのプロパティを計算する方法は非推奨です）。汎用クライアントがプロパティ値をエンドユーザーに表示する場合もありますが、クライアントUIの設計者は、リソースを識別する手段が引き続きURLであることを理解する必要があります。DAV:displaynameを変更してもサーバーへのMOVEやCOPYは発行されず、個々のリソースのmetadataが変更されるだけです。同じcollection内であっても、2つのリソースが同じDAV:displayname値を持つことができます。
<!ELEMENT displayname (#PCDATA) >
Name: getcontentlanguage
名前：GetContentLanguage
Purpose: Contains the Content-Language header value (from Section 14.12 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：コンテンツ言語ヘッダー値（[RFC2616]のセクション14.12から）が含まれています。
Value: language-tag (language-tag is defined in Section 3.10 of [RFC2616])
値：言語タグ（言語タグは[RFC2616]のセクション3.10で定義されています）
Protected: SHOULD NOT be protected, so that clients can reset the language. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護：クライアントが言語を再設定できるよう、保護すべきではありません (SHOULD NOT)。これは新しい要件であるため、[RFC2518]を実装したサーバーでは保護されたプロパティになっている場合があることに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVE時の動作：このプロパティ値は、COPY操作およびMOVE操作で保持すべきです (SHOULD)。
Description: The DAV:getcontentlanguage property MUST be defined on any DAV-compliant resource that returns the Content-Language header on a GET.
説明：DAV:getcontentlanguageプロパティは、GETでContent-Languageヘッダーを返すDAV準拠リソースに定義しなければなりません (MUST)。
<!ELEMENT getcontentlanguage (#PCDATA) >
Name: getcontentlength
名前：getContentLength
Purpose: Contains the Content-Length header returned by a GET without accept headers.
目的：Get Accept Headerによって返されるコンテンツ長ヘッダーが含まれています。
Value: See Section 14.13 of [RFC2616].
値：[RFC2616]のセクション14.13を参照してください。
Protected: This property is computed, therefore protected.
保護：このプロパティは計算されるため、保護されています。
Description: The DAV:getcontentlength property MUST be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET.
説明：DAV:getcontentlengthプロパティは、GETへのレスポンスでContent-Lengthヘッダーを返すDAV準拠リソースに定義しなければなりません (MUST)。
COPY/MOVE behavior: This property value is dependent on the size of the destination resource, not the value of the property on the source resource.
動作のコピー/移動：このプロパティ値は、ソースリソース上のプロパティの値ではなく、宛先リソースのサイズに依存します。
<!ELEMENT getcontentlength (#PCDATA) >
Name: getcontenttype
名前：getContentType
Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：コンテンツタイプのヘッダー値（[RFC2616]のセクション14.17から）が含まれています。
Value: media-type (defined in Section 3.7 of [RFC2616])
値：メディアタイプ（[RFC2616]のセクション3.7で定義）
Protected: Potentially protected if the server prefers to assign content types on its own (see also discussion in Section 9.7.1).
保護：サーバーが独自のコンテンツタイプを割り当てることを好む場合、潜在的に保護されています（セクション9.7.1の説明も参照）。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVE時の動作：このプロパティ値は、COPY操作およびMOVE操作で保持すべきです (SHOULD)。
Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.
説明：このプロパティは、GETへのレスポンスでContent-Typeヘッダーを返すDAV準拠リソースに定義しなければなりません (MUST)。
<!ELEMENT getcontenttype (#PCDATA) >
Name: getetag
名前：geteTag
Purpose: Contains the ETag header value (from Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：ETAGヘッダー値（[RFC2616]のセクション14.19から）が含まれています。
Value: entity-tag (defined in Section 3.11 of [RFC2616])
値：エンティティタグ（[RFC2616]のセクション3.11で定義）
Protected: MUST be protected because this value is created and controlled by the server.
保護：この値はサーバーが作成して制御するため、保護しなければなりません (MUST)。
COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the considerations in Section 8.8.
動作のコピー/移動：このプロパティ値は、ソースリソース上のプロパティの値ではなく、宛先リソースの最終的な状態に依存します。セクション8.8の考慮事項にも注意してください。
Description: The getetag property MUST be defined on any DAV-compliant resource that returns the Etag header. Refer to Section 3.11 of RFC 2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
説明：getetagプロパティは、Etagヘッダーを返すDAV準拠リソースに定義しなければなりません (MUST)。ETagの意味の完全な定義はRFC 2616のセクション3.11を、WebDAVにおけるETagの考察はセクション8.6を参照してください。
<!ELEMENT getetag (#PCDATA) >
Name: getlastmodified
名前：getLastModified
Purpose: Contains the Last-Modified header value (from Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers.
目的：Last修正ヘッダー値（[RFC2616]のセクション14.29から）が含まれています。
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
値：RFC1123-DATE（[RFC2616]のセクション3.3.1で定義）
Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
保護：一部のクライアントは、適切なキャッシュ動作のためにこの値、またはこのプロパティと対応するLast-Modifiedヘッダー値に依存する場合があるため、保護すべきです (SHOULD)。
COPY/MOVE behavior: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that since [RFC2616] requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. Also note the considerations in Section 8.8.
COPY/MOVE時の動作：このプロパティ値はsourceリソース上の値ではなく、destinationリソースの最終更新日時によって決まります。一部のサーバー実装では、DAV:getlastmodified値にfilesystemの更新日時を使用しており、HTTP Last-Modified値を変更すべき場合 (SHOULD) でも、MOVE時にその値が保持されることがあります。[RFC2616]ではETagが提供されている場合にクライアントがETagを使用するよう求めているため、ETagを実装するサーバーは、offline同期やcache controlにおいて、更新日時よりはるかに優れた仕組みをクライアントが使用すると見込めます。セクション8.8の考慮事項にも注意してください。
Description: The last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV: getlastmodified property MUST be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET.
説明：リソースのlast-modified日時には、そのリソースのbody（GETレスポンス）の変更だけを反映すべきです (SHOULD)。プロパティだけの変更によってlast-modified日時を変更すべきではありません (SHOULD NOT)。クライアントがlast-modified日時を基に既存のbodyを上書きする時期を判断してもよい (MAY) ためです。DAV:getlastmodifiedプロパティは、GETへのレスポンスでLast-Modifiedヘッダーを返すDAV準拠リソースに定義しなければなりません (MUST)。
<!ELEMENT getlastmodified (#PCDATA) >
Name: lockdiscovery
名前：Lock -Discovery
Purpose: Describes the active locks on a resource
目的：リソース上のアクティブロックについて説明します
Protected: MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.
保護：保護しなければなりません (MUST)。クライアントは、PROPPATCHではなくLOCKおよびUNLOCKを使用してロックのリストを変更します。
COPY/MOVE behavior: The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation.
動作のコピー/移動：このプロパティの値は、ソースリソースのロックではなく、宛先のロック状態によって異なります。移動操作でロックが移動されないことを思い出してください。
Description: Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. Owner information MAY be omitted if it is considered sensitive. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there are one or more locks, an 'activelock' element appears for each lock on the resource. This property is NOT lockable with respect to write locks (Section 7).
説明：ロック保持者、ロックの種類、timeoutの種類と残り時間、および関連するlock tokenの一覧を返します。owner情報が機微情報と見なされる場合は、省略してもよい (MAY)。ロックがなくてもサーバーがロックをサポートしている場合、このプロパティは存在しますが、'activelock'要素を1つも含みません。ロックが1つ以上ある場合、リソース上の各ロックについて'activelock'要素が現れます。このプロパティは、書き込みロックに関してlockableではありません（セクション7）。
<!ELEMENT lockdiscovery (activelock)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
このリソースには、無限のタイムアウトを備えた単一の排他的な書き込みロックがあります。
Name: resourcetype
名前：ResourceType
Purpose: Specifies the nature of the resource.
目的：リソースの性質を指定します。
Protected: SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH.
保護：保護すべきです (SHOULD)。resource typeは通常、PROPPATCHではなく、リソースを作成する操作（MKCOLまたはPUT）によって決定されます。
COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in the same type of resource at the destination.
動作のコピー/移動：通常、リソースのコピー/移動により、目的地の同じタイプのリソースが得られます。
Description: MUST be defined on all DAV-compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by this specification (see Section 14.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. This element MUST NOT contain text or mixed content. Any custom child element is considered to be an identifier for a resource type.
説明：DAV準拠のすべてのリソースに定義しなければなりません (MUST)。各子要素は、'collection'など、そのリソースが属する特定の型を識別します。'collection'は、本仕様が定義する唯一のresource typeです（セクション14.3を参照）。要素が'collection'子要素と認識できない追加要素を含む場合、通常はcollectionとして扱うのが望まれます。認識できる子要素を含まない場合は、非collectionリソースとして扱うのが望まれます。デフォルト値は空です。この要素にはtext contentまたはmixed contentを含めてはなりません (MUST NOT)。独自の子要素は、resource typeの識別子と見なします。
Example: (fictional example to show extensibility)
例：（拡張性を示す架空の例）
<x:resourcetype xmlns:x="DAV:">
<x:collection/>
<f:search-results xmlns:f="http://www.example.com/ns"/>
</x:resourcetype>
Name: supportedlock
名前：supportedlock
Purpose: To provide a listing of the lock capabilities supported by the resource.
目的：リソースでサポートされているロック機能のリストを提供する。
Protected: MUST be protected. Servers, not clients, determine what lock mechanisms are supported.
保護：保護しなければなりません (MUST)。どのロック機構をサポートするかは、クライアントではなくサーバーが決定します。
COPY/MOVE behavior: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination.
動作のコピー/移動：このプロパティ値は、ソースリソースのプロパティの値ではなく、目的地でサポートされるロックの種類に依存します。目的地にコピーしようとするサーバーは、このプロパティを目的地に設定しようとしないでください。
Description: Returns a listing of the combinations of scope and access types that may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls, so a server is not required to provide information the client is not authorized to see. This property is NOT lockable with respect to write locks (Section 7).
説明：リソースのロックリクエストで指定される可能性のあるスコープとアクセスタイプの組み合わせのリストを返します。実際のコンテンツ自体はアクセス制御によって制御されているため、サーバーはクライアントが確認する権限を与えられていない情報を提供する必要はありません。このプロパティは、書き込みロックに関してロックできません（セクション7）。
<!ELEMENT supportedlock (lockentry)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
As introduced in Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes.
セクション8.7で導入されているように、エラー条件に関する追加情報は、多くのステータス応答の本体に含めることができます。このセクションでは、エラーボディメカニズムの使用に関する要件を作成し、多くの前提条件と事後コードを導入します。
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed.
メソッドの「前提条件」は、そのメソッドを実行するために真でなければならないサーバーの状態を説明します。メソッドの「条件」は、そのメソッドが完了した後に真でなければならないサーバーの状態を説明しています。
Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses where this specification's 'error' body is used, the precondition/postcondition XML element MUST be returned as the child of a top-level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements.
各事前条件および事後条件には、一意のXML要素が対応付けられています。207 Multi-Statusレスポンスでは、その条件が1つ以上のプロパティに適用されるか、リソース全体に適用されるかに応じて、適切な'propstat'または'response'要素の'error'要素内にXML要素を置かなければなりません (MUST)。本仕様の'error' bodyを使用するそれ以外のすべてのエラーレスポンスでは、リクエストによって別途取り決められていない限り、適切なレスポンスステータスとともに、事前条件または事後条件のXML要素をresponse body内の最上位'error'要素の子として返さなければなりません (MUST)。最も一般的なレスポンスステータスコードは、常に失敗するためリクエストを繰り返すべきでない場合の403 (Forbidden)と、ユーザーが競合を解消してリクエストを再送できると見込まれる場合の409 (Conflict)です。'error'要素は、具体的なエラー情報を持つ子要素を含んでもよく (MAY)、任意の独自子要素で拡張してもよい (MAY)。
This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
このメカニズムは、ここまたはHTTPで定義されている正しい数値ステータスコードを使用することに代わりはありません。クライアントは、数値コードのみに基づいて常に合理的なアクションコースを取得できる必要があるためです。ただし、新しい数値コードを定義する必要性は削除されます。この目的に使用される新しいマシン読み取り可能なコードは、前提条件と事後条件として分類されるXML要素であるため、当然、新しい条件コードを定義するグループは独自の名前空間を使用できます。いつものように、「DAV：」名前空間は、IETFチャーター付きWebDAVワーキンググループが使用するために予約されています。
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging.
本仕様をサポートするサーバーは、本書で定義する事前条件または事後条件に違反した場合は常にXML errorを使用すべきです (SHOULD)。本書に規定されていないエラー条件については、サーバーは適切な数値statusを選択し、response bodyを空のままにしてもよい (MAY)。ただし、独自のcondition codeと補足テキストを代わりに使用してもよい (MAY)。クライアントがcondition codeを自動認識しない場合でも、相互運用性試験やdebugに非常に役立つためです。
Example - Response with precondition code
例-Preconditionコードを使用した応答
>>Response
>>応答
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/workspace/webdav/</D:href>
</D:lock-token-submitted>
</D:error>
In this example, a client unaware of a depth-infinity lock on the parent collection "/workspace/webdav/" attempted to modify the collection member "/workspace/webdav/proposal.doc".
この例では、クライアントは、親コレクション「/workspace/webdav/「コレクションメンバー」を変更しようとした「/workspace/webdav/proposal.doc」の[/workspace/webdav/"の深さの内容ロックに気付いていません。
Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648].
[RFC3744]（特にセクション7.1.1を参照）、[RFC3253]、[RFC3648]など、WebDAVを拡張する他の仕様では、他の有用な前提条件と事後条件が定義されています。
All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty.
これらの要素はすべて「DAV：」名前空間にあります。特に指定されていない場合、各条件のXML要素のコンテンツは空であると定義されています。
Name: lock-token-matches-request-uri
名前：Lock-Token-Matches-Request-Uri
Use with: 409 Conflict
使用：409競合
Purpose: (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
目的：（事前条件）UNLOCKメソッドのロックを識別するため、リクエストにLock-Tokenヘッダーを含める場合があります。ただし、Request-URIがtokenで識別されるロックのスコープ内にない場合、サーバーはこのエラーを使用すべきです (SHOULD)。ロックのスコープにRequest-URIが含まれない場合、ロックが消失している場合、またはtokenが無効な場合があります。
Name: lock-token-submitted (precondition)
名前：ロックトークンサブミット（前提条件）
Use with: 423 Locked
使用：423ロックされています
Purpose: The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
目的：lock tokenを送信すべきだったため、リクエストが成功しませんでした。この要素が存在する場合、リクエストを妨げたロック済みリソースのURLを少なくとも1つ含めなければなりません (MUST)。collectionのロックが関係するMOVE、COPY、DELETEでは、どのロック済みリソースが失敗の原因かをクライアントが特定するのは困難ですが、サーバーが返す責任を負うのは、そのようなリソースのうち1つだけです。失敗を引き起こしたロック済みリソースをすべて把握している場合、サーバーはそれらをすべて返してもよい (MAY)。
<!ELEMENT lock-token-submitted (href+) >
Name: no-conflicting-lock (precondition)
名前：紛争なし（前提条件）
Use with: Typically 423 Locked
使用：通常423ロックされています
Purpose: A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property.
目的：既存の矛盾するロックが存在するため、ロック要求が失敗しました。要求が指示されたリソースは間接的にロックされているだけですが、ロックは競合する可能性があることに注意してください。この場合、前提条件コードを使用して、「ロックディスコビリー」プロパティの個別の検索を回避して、競合するロックのルートであるリソースについてクライアントに通知できます。
<!ELEMENT no-conflicting-lock (href)* >
Name: no-external-entities
名前：external-entitiesなし
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
目的：（事前条件）request bodyにexternal entityが含まれることを理由にサーバーがクライアントリクエストを拒否する場合、このエラーを使用すべきです (SHOULD)。
Name: preserved-live-properties
名前：保存されたlive-properties
Use with: 409 Conflict
使用：409競合
Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
目的：（ポストコンディション） - サーバーは、それ以外の場合はValid Moveまたはコピーリクエストを受信しましたが、宛先で同じ動作でライブプロパティを維持することはできません。サーバーは、リポジトリの一部の一部のライブプロパティのみをサポートするか、単に内部エラーがある場合があります。
Name: propfind-finite-depth
名前：Propfind-finite-Depth
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
目的：（前提条件） - このサーバーでは、コレクションに関する無限のプロップファインドリクエストが許可されていません。
Name: cannot-modify-protected-property
名前：Modify-Modify-Propertyできません
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12.
目的：（前提条件） - クライアントは、保護されたプロパティをプロップパッチに設定しようとしました（DAV：getEtagなど）。[RFC3253]、セクション3.12も参照してください。
The XML namespace extension ([REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group.
XML namespace拡張（[REC-XML-NAMES]）は、他の要素名との衝突を懸念せずに新しいXML要素を追加できるようにするため、本仕様で使用されています。WebDAVのrequest bodyおよびresponse bodyは任意のXML要素で拡張でき、メッセージの受信者はそれらを無視できます。ただし、WebDAV working groupによるレビューを受けたIETF RFCでXML要素が明示的に定義されていない限り、"DAV:" namespaceのXML要素をrequest bodyまたはresponse bodyで使用すべきではありません (SHOULD NOT)。
For WebDAV to be both extensible and backwards-compatible, both clients and servers need to know how to behave when unexpected or unrecognized command extensions are received. For XML processing, this means that clients and servers MUST process received XML documents as if unexpected elements and attributes (and all children of unrecognized elements) were not there. An unexpected element or attribute includes one that may be used in another context but is not expected here. Ignoring such items for purposes of processing can of course be consistent with logging all information or presenting for debugging.
WebDAVを拡張可能かつ後方互換にするには、予期しない、または認識できないcommand拡張を受信した際の動作を、クライアントとサーバーの双方が把握する必要があります。XML処理では、予期しない要素と属性、および認識できない要素のすべての子が存在しなかったものとして、クライアントとサーバーが受信XML文書を処理しなければならない (MUST) ことを意味します。予期しない要素または属性には、別の文脈では使用できても、ここでは想定されていないものも含まれます。処理上このような項目を無視しても、すべての情報をlogに記録したりdebug用に提示したりすることとは両立します。
This restriction also applies to the processing, by clients, of DAV property values where unexpected XML elements SHOULD be ignored unless the property's schema declares otherwise.
この制約は、クライアントによるDAVプロパティ値の処理にも適用されます。プロパティのschemaで別途宣言されていない限り、予期しないXML要素を無視すべきです (SHOULD)。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record all XML elements.
この制約は、サーバー上のdead DAV propertyを設定する場合には適用されません。その場合、サーバーはすべてのXML要素を記録しなければなりません (MUST)。
Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT.
さらに、この制限はXMLの使用には適用されません。たとえば、XMLがエンティティボディのコンテンツタイプである場合、たとえば、プットの本体として使用する場合です。
Processing instructions in XML SHOULD be ignored by recipients. Thus, specifications extending WebDAV SHOULD NOT use processing instructions to define normative behavior.
XMLのprocessing instructionは、受信者が無視すべきです (SHOULD)。したがって、WebDAVを拡張する仕様では、規範的動作を定義するためにprocessing instructionを使用すべきではありません (SHOULD NOT)。
XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular:
XML DTDフラグメントは、この仕様で定義されているすべてのXML要素に含まれています。ただし、名前空間の使用法と拡張ルールのため、正しいXMLはDTDに従って有効ではありません。特に：
o Elements (from this specification) are in the "DAV:" namespace,
o 要素（この仕様から）は「dav：」の名前空間にあります。
o Element ordering is irrelevant unless otherwise stated,
o 特に明記しない限り、要素の順序付けは無関係です、
o Extension attributes MAY be added,
o 拡張属性を追加してもよい (MAY)。
o For element type definitions of "ANY", the normative text definition for that element defines what can be in it and what that means.
o 要素タイプの「any」の定義の場合、その要素の規範的なテキスト定義は、その要素に何ができるか、それが何を意味するかを定義します。
o For element type definitions of "#PCDATA", extension elements MUST NOT be added.
o "#PCDATA"のelement type定義には、拡張要素を追加してはなりません (MUST NOT)。
o For other element type definitions, including "EMPTY", extension elements MAY be added.
o "EMPTY"を含む、それ以外のelement type定義には、拡張要素を追加してもよい (MAY)。
Note that this means that elements containing elements cannot be extended to contain text, and vice versa.
これは、要素を含む要素をテキストに含めるように拡張できないことを意味することに注意してください。
With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
上記の規則によってDTD検証を緩和しても、DTD fragmentで記述される制約は規範的です（たとえば、付録Aを参照）。XML bodyを持つWebDAVメッセージの受信者は、hard-codedまたは動的に宣言されたDTDに従ってXML文書を検証してはなりません (MUST NOT)。
Note that this section describes backwards-compatible extensibility rules. There might also be times when an extension is designed not to be backwards-compatible, for example, defining an extension that reuses an XML element defined in this document but omitting one of the child elements required by the DTDs in this specification.
このセクションでは、逆互換の拡張性ルールについて説明していることに注意してください。また、このドキュメントで定義されているXML要素を再利用するが、この仕様でDTDに必要な子要素の1つを省略する拡張機能を定義するなど、拡張機能が後方互換ではないように設計されている場合もあります。
A DAV-compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource and examining the "DAV" header which is returned. Note particularly that resources, rather than servers, are spoken of as being compliant. That is because theoretically some resources on a server could support different feature sets. For example, a server could have a sub-repository where an advanced feature like versioning was supported, even if that feature was not supported on all sub-repositories.
DAVに準拠したリソースは、複数のクラスのコンプライアンスを宣伝できます。クライアントは、リソース上のオプションを実行し、返される「DAV」ヘッダーを調べることにより、リソースのコンプライアンスクラスを発見できます。特に、サーバーではなくリソースが準拠していると話されていることに注意してください。それは、理論的にはサーバー上の一部のリソースがさまざまな機能セットをサポートできるためです。たとえば、サーバーには、すべてのサブレポジトリーでその機能がサポートされていなくても、バージョンのような高度な機能がサポートされているサブレポジトリを持つことができます。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies MUST be compliant with [RFC2616].
本書はHTTP/1.1 protocolの拡張を記述するため、最低限、DAV準拠のすべてのリソース、クライアント、およびproxyは[RFC2616]に準拠しなければなりません (MUST)。
A resource that is class 2 or class 3 compliant must also be class 1 compliant.
クラス2またはクラス3に準拠したリソースも、クラス1に準拠している必要があります。
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
class 1準拠リソースは、本書のすべてのセクションにあるすべての"MUST"要件を満たさなければなりません (MUST)。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
class 1準拠リソースは、OPTIONSメソッドへのすべてのレスポンスで、DAVヘッダーに少なくとも値"1"を返さなければなりません (MUST)。
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV: lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class 2 compliant resource SHOULD also support the Timeout request header and the 'owner' XML element.
class 2準拠リソースは、class 1のすべての要件を満たし、LOCKメソッド、DAV:supportedlockプロパティ、DAV:lockdiscoveryプロパティ、Time-Outレスポンスヘッダー、およびLock-Tokenリクエストヘッダーをサポートしなければなりません (MUST)。class 2準拠リソースは、Timeoutリクエストヘッダーと'owner' XML要素もサポートすべきです (SHOULD)。
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
class 2準拠リソースは、OPTIONSメソッドへのすべてのレスポンスで、DAVヘッダーに少なくとも値"1"および"2"を返さなければなりません (MUST)。
A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
リソースは、本書による[RFC2518]の改訂への対応を明示的に通知できます。class 1もサポートしなければなりません (MUST)。class 2はサポートしてもよい (MAY)。class 1および2に加えてclass 3への対応を通知することは、サーバーが本仕様のすべての要件をサポートすることを意味します。class 2を除きclass 3とclass 1への対応を通知することは、ロック対応に関するものを除いて、サーバーが本仕様のすべての要件をサポートすることを意味します。
Example:
例：
DAV: 1, 3
DAV：1、3
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations.
国際化の領域では、この仕様はIETF文字セットポリシー[RFC2277]に準拠しています。この仕様では、プロパティの値のいずれか、または応答エンティティボディで返されるエラーメッセージのいずれかに人間が読めるフィールドを見つけることができます。どちらの場合も、人間の読み取り可能なコンテンツはXMLを使用してエンコードされます。XMLは、文字セットのタグ付けとエンコードの明示的な規定があり、XMLプロセッサがUTF-8 [RFC3629]およびUTF-16を使用して、少なくともエンコードされたXML要素を読み取る必要があります。[RFC2781] ISO 10646多言語面のエンコーディング。この仕様のXML例は、コンテンツタイプのヘッダー（[RFC3023]で定義）のcharsetパラメーターの使用とXML charset宣言を示しています。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping.
XMLは、特定のXML要素の内容の言語を指定するための言語タグ機能も提供します。「XML：Lang」属性はXML要素に表示され、そのコンテンツと属性の言語を識別します。値とスコープの定義については、[rec-xml]を参照してください。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVアプリケーションは、XML仕様の文字セットtag、文字セット符号化、および言語tagの機能をサポートしなければなりません (MUST)。WebDAVアプリケーションの実装者には、XML転送に使用するMIME media type、およびContent-Typeヘッダーのcharset parameterの使い方について、"XML Media Types" [RFC3023]を読むことを強く推奨します。
Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in US-ASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages.
この仕様内で使用される名前は、メソッドとヘッダーなどのプロトコル要素の名前、XML要素の名前、プロパティの名前、条件の名前の4つのカテゴリに分類されます。プロトコル要素の命名は、HTTPの先例に続き、メソッドとヘッダーのためにUS-ASCIIでエンコードされた英語名を使用します。これらのプロトコル要素はユーザーには見えず、単に長いトークン識別子であるため、複数の言語をサポートする必要はありません。同様に、この仕様で使用されているXML要素の名前はユーザーには表示されないため、複数の言語をサポートする必要はありません。
WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name to a user. We recommend that applications provide human-readable property names wherever feasible.
WebDAVプロパティ名は、適格なXML名（XMLネームスペース名とローカル名のペア）です。一部のアプリケーション（たとえば、一般的なプロパティビューア）はプロパティ名をユーザーに直接表示しますが、典型的なアプリケーションは固定されたプロパティセットを使用し、プロパティ名と名前空間から人間へのマッピングを提供することが期待されます。ユーザーにプロパティ名を表示するときの読み取り可能なフィールド。プロパティのセットが事前に知られていない場合にのみ、アプリケーションがユーザーにプロパティ名を表示する必要があることが必要です。アプリケーションは、実行可能な場所に人間の読み取り可能なプロパティ名を提供することをお勧めします。
For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
エラーレポートの場合、各ステータスコードを含むHTTP/1.1ステータスコードの慣習に従って、コードの短い英語説明（423（ロック）など）に従います。作成されていないユーザーエージェントがこのメッセージをユーザーに表示する可能性は存在しますが、国際化されたアプリケーションはこのメッセージを無視し、ユーザーの言語とキャラクターセットに適切なメッセージを表示します。
Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
クライアントとサーバーの相互操作はロケール情報を必要としないため、この仕様ではこの情報の送信のメカニズムは指定されていません。
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
このセクションは、WebDAVアプリケーションが注意する必要があるセキュリティの意味に関する詳細な問題について提供されています。
All of the security considerations of HTTP/1.1 (discussed in [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
HTTP/1.1（[RFC2616]で説明）およびXML（[RFC3023]で説明）のセキュリティに関するすべての考慮事項もWebDAVに適用されます。さらに、リモートオーサリングに固有のセキュリティリスクは、より強力な認証テクノロジーを必要とし、いくつかの新しいプライバシーの懸念を導入し、サーバーの設計が不十分であるための危険性を高める可能性があります。これらの問題については、以下に詳しく説明しています。
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication.
オーサリングに重点が置かれているため、WebDAVサーバーは認証テクノロジーを使用して、ネットワークリソースへのアクセスだけでなく、リソースの整合性も保護する必要があります。さらに、ロック機能の導入には、認証をサポートする必要があります。
A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
安全でないchannelを平文で送信するpasswordは傍受される可能性があるため、リソースのaccessibilityおよびintegrityを保護する手段として不十分です。HTTP/1.1のBasic認証は実質的にpasswordを平文で送信するため、接続が安全でない限り、WebDAVクライアントをサーバーへ認証するためにBasic認証を使用してはなりません (MUST NOT)。さらに、接続が安全でない限り、WebDAVサーバーはWWW-AuthenticateヘッダーでBasic認証challengeを送信してはなりません (MUST NOT)。安全な接続の例として、強力なcipher suiteとサーバー認証を使用するTransport Layer Security（TLS）接続があります。
WebDAV applications MUST support the Digest authentication scheme [RFC2617]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication that is useful in a wide range of scenarios.
WebDAVアプリケーションは、Digest認証方式[RFC2617]をサポートしなければなりません (MUST)。Digest認証は、共有秘密であるpasswordを平文で送信せずに、通信する双方がその秘密を知っていることを検証します。そのため、Basic認証に固有のセキュリティ問題を回避しながら、幅広い状況で有用な水準の認証を提供します。
Denial-of-service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial-of-service attacks on every part of a system's resources.
サービス拒否攻撃は、WebDAVサーバーにとって特別な懸念事項です。WebDAV Plus HTTPは、システムのリソースのあらゆる部分に対するサービス拒否攻撃を可能にします。
o The underlying storage can be attacked by PUTting extremely large files.
o 基礎となるストレージは、非常に大きなファイルを配置することで攻撃できます。
o Asking for recursive operations on large collections can attack processing time.
o 大規模なコレクションで再帰的な操作を要求すると、処理時間を攻撃できます。
o Making multiple pipelined requests on multiple connections can attack network connections.
o 複数の接続で複数のパイプラインリクエストを作成すると、ネットワーク接続を攻撃できます。
WebDAV servers need to be aware of the possibility of a denial-of-service attack at all levels. The proper response to such an attack MAY be to simply drop the connection. Or, if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500- level status response would indicate that the problem is with the server, whereas unintentional DoS attacks are something the client is capable of remedying).
WebDAVサーバーは、あらゆる層でdenial-of-service攻撃が起こり得ることを認識する必要があります。このような攻撃への適切な対応として、単に接続を切断してもよい (MAY)。また、サーバーがレスポンスを返せる場合は、400 (Bad Request)などの400番台statusを使用してもよく (MAY)、リクエストを拒否した理由を示せます（500番台のstatus responseは問題がサーバー側にあることを示しますが、意図しないDoS攻撃はクライアント側で修正可能です）。
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
WebDAVは、Propfindメソッドを通じて、コレクションのメンバーリソースをリストするメカニズムを提供します。これにより、ネットワークリソースの名前を発見することの難しさのみに依存するセキュリティまたはプライバシーテクニックの有効性が大幅に低下します。WebDAVサーバーのユーザーは、リソース名の相対的な不明瞭さに依存するのではなく、リソースへの不要なアクセスを防ぐために、アクセス制御手法を使用することをお勧めします。
When submitting a lock request, a user agent may also submit an 'owner' XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a DAV: lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases, this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
ロックリクエストを送信する際、user agentは、ロックを取得する者の連絡先情報を示す'owner' XML fieldも送信できます（robotではなく人がロックを取得する場合です）。この連絡先情報はリソースのDAV:lockdiscoveryプロパティに格納され、他の共同作業者がリソースへのアクセスについて交渉を始めるために利用できます。ただし、多くの場合、この連絡先情報は非常に私的であり、広く公開しないことが望まれます。サーバーは、必要に応じてDAV:lockdiscoveryプロパティへのread accessを制限すべきです (SHOULD)。さらにuser agentは、連絡先情報を送信するかどうか、送信する場合は具体的にどの情報を送るかを制御できるようにすべきです (SHOULD)。
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
プロパティ値は通常、ドキュメントの著者などの情報を保持するために使用されるため、プライバシーの懸念がリソースのプロパティデータへの広範なアクセスに起因する可能性があります。プロパティを介して個人情報の不注意なリリースのリスクを減らすために、サーバーは、リソースボディへの読み取りアクセスを分離し、リソースのプロパティへのアクセスを読み取るアクセス制御メカニズムを開発することをお勧めします。これにより、ユーザーはリソースのコンテンツへのアクセスを過度に制限することなく、プロパティデータの普及を制御できます。
XML supports a facility known as "external entities", defined in Section 4.2.2 of [REC-XML], which instructs an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity.
XMLは、[Rec-XML]のセクション4.2.2で定義されている「外部エンティティ」と呼ばれる施設をサポートしており、XMLプロセッサに追加のXMLを取得して含めるよう指示します。外部XMLエンティティを使用して、XMLドキュメントに関連付けられたドキュメントタイプ宣言（DTD）を追加または変更できます。外部XMLエンティティを使用して、XMLドキュメントのコンテンツ内にXMLを含めることもできます。外部XMLエンティティを含むこの仕様で使用されるXMLなど、非検証XMLの場合、XMLでは必要ありません。ただし、XMLは、XMLプロセッサには、その裁量により、外部XMLエンティティが含まれる場合があると述べています。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case, significantly modifying its semantics or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the 'no-external-entities' condition code.
external XML entityは本質的に信頼できず、あらゆるHTTP GETリクエストに伴う攻撃の対象になります。さらに、external XML entityはDTDを変更できるため、XML文書の最終的な形に影響し、最悪の場合にはその意味を大幅に変えたり、XML processorを[RFC3023]で論じるセキュリティリスクにさらしたりする可能性があります。したがって実装者は、external XML entityを信頼できないものとして扱う必要があることを認識しなければなりません。サーバーがexternal XML entityを処理しない場合、external entityを含むリクエストには'no-external-entities' condition codeで応答すべきです (SHOULD)。
There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server that fields requests for the resource containing the external XML entity.
また、外部XMLエンティティを使用した広く展開されたアプリケーションに伴うスケーラビリティリスクもあります。この状況では、1つの外部XMLエンティティに対してかなりの数のリクエストがあり、外部XMLエンティティを含むリソースのリクエストをフィールドにリクエストするサーバーを過負荷にする可能性があります。
Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in Section 4.2.2 of [REC-XML]. A small, carefully crafted request using nested internal entities may require enormous amounts of memory and/or processing time to process. Server implementers should be aware of this risk and configure their XML parsers so that requests like these can be detected and rejected as early as possible.
さらに、[Rec-XML]のセクション4.2.2で定義されている「内部エンティティ」の評価に基づくリスクもあります。ネストされた内部エンティティを使用した小規模で慎重に作成されたリクエストには、処理するために膨大な量のメモリおよび/または処理時間が必要になる場合があります。サーバーの実装者は、このリスクを認識し、XMLパーサーを構成して、このような要求をできるだけ早く検出および拒否できるようにする必要があります。
This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens (Section 6.5), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address.
本仕様では、lock token（セクション6.5）の空間的・時間的一意性を保証するため、"A Universally Unique Identifier (UUID) URN Namespace"（[RFC4122]）の使用を推奨します。version 1 UUID（セクション4で定義）は、"通常はhost addressであるIEEE 802 MAC addressで構成され、複数のIEEE addressを持つシステムでは利用可能なものをどれでも使用できる"node fieldを含んでもよい (MAY)。WebDAVサーバーは稼働期間中に多数のロックを発行するため、自身のIEEE 802 addressを公開することにもなり得ます。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE 802アドレスの曝露に関連するいくつかのリスクがあります。IEEE 802アドレスの使用：
o It is possible to track the movement of hardware from subnet to subnet.
o サブネットからサブネットへのハードウェアの動きを追跡することができます。
o It may be possible to identify the manufacturer of the hardware running a WebDAV server.
o WebDAVサーバーを実行しているハードウェアのメーカーを識別することが可能かもしれません。
o It may be possible to determine the number of each type of computer running WebDAV.
o WebDAVを実行している各タイプのコンピューターの数を決定することが可能かもしれません。
This risk only applies to host-address-based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do not involve the host address and therefore do not suffer from this risk.
このリスクは、ホストアドレスベースのUUIDバージョンにのみ適用されます。[RFC4122]のセクション4では、ホストアドレスを伴わないため、このリスクに悩まされないUUIDを生成するための他のいくつかのメカニズムについて説明します。
HTTP has the ability to host programs that are executed on client machines. These programs can take many forms including Web scripts, executables, plug-in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs, yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close trust relationship with the author that is publishing the document. Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server.
HTTPには、クライアントマシンで実行されるプログラムをホストする機能があります。これらのプログラムは、ドキュメントにWebスクリプト、実行可能ファイル、プラグインモジュール、マクロなど、さまざまなフォームを使用できます。WebDAVは、これらのプログラムに関するセキュリティの懸念事項を変更しませんが、多くの場合、WebDAVは、幅広いユーザーがサーバーにドキュメントを公開できるコンテキストで使用されます。サーバーは、ドキュメントを公開している著者との密接な信頼関係を持たない場合があります。クライアントが任意のコンテンツを公開できるようにするサーバーは、サーバーに公開されたコンテンツが他のクライアントに有害ではないことを確認するために予防策を有用に実装できます。サーバーは、公開されているコンテンツの種類を制限し、公開されたコンテンツでウイルスとマルウェア検出ソフトウェアを実行するなどの手法によってこれを行うことができます。サーバーは、コンテンツをサーバーに公開することが許可されているユーザーの適切なアクセス制限と認証を持つことにより、リスクを軽減することもできます。
This specification defines two URI schemes:
この仕様では、2つのURIスキームが定義されています。
1. the "opaquelocktoken" scheme defined in Appendix C, and
1. 付録Cで定義されている「Opaquelocktoken」スキームと
2. the "DAV" URI scheme, which historically was used in [RFC2518] to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF.
2. [RFC2518]で歴史的に使用されていた「DAV」URIスキームは、WebDAVプロパティとXML要素名を明確にし、この仕様やその他のWebDAVを拡張する他の目的で使用され続けています。「dav：」という名前の識別子の作成は、IETFによって制御されます。
Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.
XMLネームスペースの新しいURIスキームを定義することは、今では落胆していることに注意してください。「DAV：」は、標準的なベストプラクティスが登場する前に定義されました。
XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.
XML NameSpacesは、WebDAVプロパティ名とXML要素を微分します。WebDAVユーザーまたはアプリケーションは、カスタムプロパティを作成したり、WebDAV XML構文を拡張したりするために、新しい名前空間を定義できます。IANAは、そのような名前空間、プロパティ名、または要素名を管理する必要はありません。
The message header fields below should be added to the permanent registry (see [RFC3864]).
以下のメッセージヘッダーフィールドは、永続的なレジストリに追加する必要があります（[RFC3864]を参照）。
Header field name: DAV
ヘッダーフィールド名：Dav
Applicable protocol: http
該当するプロトコル：http
Status: standard Author/Change controller: IETF
ステータス：標準著者/変更コントローラー：IETF
Specification document: this specification (Section 10.1)
仕様文書：この仕様（セクション10.1）
Header field name: Depth
ヘッダーフィールド名：深さ
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.2)
仕様文書：この仕様（セクション10.2）
Header field name: Destination
ヘッダーフィールド名：目的地
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.3)
仕様文書：この仕様（セクション10.3）
Header field name: If
ヘッダーフィールド名：if
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.4)
仕様文書：この仕様（セクション10.4）
Header field name: Lock-Token
ヘッダーフィールド名：ロックトークン
Applicable protocol: http
該当するプロトコル：http
Status: standard Author/Change controller: IETF
ステータス：標準著者/変更コントローラー：IETF
Specification document: this specification (Section 10.5)
仕様文書：この仕様（セクション10.5）
Header field name: Overwrite
ヘッダーフィールド名：上書き
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.6)
仕様文書：この仕様（セクション10.6）
Header field name: Timeout
ヘッダーフィールド名：タイムアウト
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.7)
仕様文書：この仕様（セクション10.7）
This specification defines the HTTP status codes
この仕様では、HTTPステータスコードを定義します
o 207 Multi-Status (Section 11.1)
o 207マルチステータス（セクション11.1）
o 422 Unprocessable Entity (Section 11.2),
o 422処理不可能なエンティティ（セクション11.2）、
o 423 Locked (Section 11.3),
o 423ロック（セクション11.3）、
o 424 Failed Dependency (Section 11.4) and
o 424依存の失敗（セクション11.4）および
o 507 Insufficient Storage (Section 11.5),
o 507ストレージ不足（セクション11.5）、
to be updated in the registry at <http://www.iana.org/assignments/http-status-codes>.
レジストリで<http://www.iana.org/assignments/http-status-codes>で更新されます。
Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
注：HTTPステータスコード102（処理）は、この仕様で削除されました。そのIANA登録は、引き続きRFC 2518を参照する必要があります。
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
このような仕様は、批判的なレビューを刺すことと、無関心な怠慢からの枯れに繁栄します。著者は、私たちの仕事のあらゆる段階で洞察が非常に価値がある次の人々の貢献に感謝しています。
Contributors to RFC 2518
RFC 2518への貢献者
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
テリー・アレン、ハラルド・アルベスランド、ジム・アムスデン、ベッキー・アンダーソン、アラン・バビッチ、サンフォード・バー、ディラン・バレル、バーナード・チェスター、ティム・バーナーズ・リー、ダン・コノリー、ジム・カニンガム、ロン・ダニエル、ジュニア、ジム・デイビス、キース・ドーソン、マーク・デイ、ブライアン・ディーン、マーティン・ドゥースト、デビッド・デュランド、リー・ファレル、チャック・フェイ、ウェスリー・フェルター、ロイ・フィールディング、マーク・フィッシャー、アラン・フライアー、ジョージ・フィレンツィーヌ、ジム・ゲッティズ、フィル・ハラム・ベーカー、デニス・ハミルトン、スティーブ・ヘニング、ミード・ヒメルシュタイン、アレックス・ホップマン、アンドレ・ファン・デル・ホーク、ベン・ローリー、ポール・リーチ、オラ・ラシラ、カレン・マッカーサー、スティーブン・マーティン、ラリー・マシン留め、マイケル・ミーリング、キース・ムーア、トーマス・ナルテン、ヘンリック・ニールセン、ケンジ・オタ、ボブ・パーカー、グレン・ピーターソン、ジョン・ラドフ、セーブ・レディ、ヘンリー・サンダース、クリストファー・セウワルド、ジュディス・スリーイン、マイク・スプレッツァー、アイナー・ステフェルード、グレッグ・スタイン、ラルフ・スウィック、ケンジ・タカハシ、リチャード・N・テイラー、ロバート・タウ、ジョン・ターナー、サンカール・ヴァルハグリスワラン、ファビオ・ヴィタリ、グレゴリー・ウッドハウス、ラウレン・ウッド。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable; he both helped the formation of the working group and patiently coached the authors along the way. In so many ways he has set high standards that we have toiled to meet. The contributions of Judith Slein were also invaluable; by clarifying the requirements and in patiently reviewing version after version, she both improved this specification and expanded our minds on document management.
このリストの2人は特別な言及に値します。Larry Masinterの貢献は非常に貴重でした。彼は両方ともワーキンググループの形成を助け、途中で著者を辛抱強く指導しました。非常に多くの点で彼は高い基準を設定しているので、私たちは会うために苦労しました。ジュディス・スリーインの貢献も非常に貴重でした。要件を明確にし、バージョン後に辛抱強くレビューすることで、彼女はこの仕様を改善し、ドキュメント管理に関する私たちの心を拡大しました。
We would also like to thank John Turner for developing the XML DTD.
また、XML DTDを開発してくれたJohn Turnerに感謝します。
The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV.
RFC 2518の著者は、ヤロンゴーランド、ジムホワイトヘッド、A。ファイジ、スティーブカーター、およびD.ジェンセンでした。IETFの著者数の制限のために名前を削除する必要がありましたが、WebDAVの設計の大部分を信用することができます。
Additional Acknowledgements for This Specification
この仕様の追加の謝辞
Significant contributors of text for this specification are listed as contributors in the section below. We must also gratefully acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing out specific text on the list or in meetings. Joe Hildebrand and Cullen Jennings helped close many issues. Barry Lind described an additional security consideration and Cullen Jennings provided text for that consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
この仕様のテキストの重要な貢献者は、以下のセクションに貢献者としてリストされています。また、Geoff Clemm、Joel Soderberg、およびDan Brotskyに、リストまたは会議で特定のテキストをかけてくれたことに感謝しなければなりません。Joe HildebrandとCullen Jenningsは、多くの問題を埋めるのを助けました。Barry Lindは、追加のセキュリティに関する考慮事項を説明し、Cullen Jenningsはその考慮のためにテキストを提供しました。ジェイソン・クロフォードは、この文書の問題ステータスを何年も追跡し、エリアス・シンダーソンがそれに続きました。
Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: julian.reschke@greenbytes.de
Julian Reschke <Green/> Bytes GmbH Hafenweg 16、48155 Muenster、ドイツメール：julian.reschke@greenbytes.de
Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu
カリフォルニア州エリアスシンダーソン大学サンタクルス1156ハイストリート、サンタクルス、カリフォルニア州95064メール：elias@cse.ucsc.edu
Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu
ジムホワイトヘッドカリフォルニア大学、サンタクルーズ1156ハイストリート、カリフォルニア州サンタクルス95064メール：ejw@soe.ucsc.edu
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399メール：yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu
E. J.ホワイトヘッド、Jr。カリフォルニア州情報およびコンピューターサイエンス大学、アーバインアーバイン、CA 92697-3425メール：ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com
A. Faizi Netscape 685 East Middlefield Road Mountain View、CA 94043メール：asad@netscape.com S. R. Carter Novell 1555 N. Technology Way M/S orm F111 Orem、UT 84097-2399メール：srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com
D. Jensen Novell 1555 N. Technology Way M/S Orm F111 Orem、UT 84097-2399メール：dcjensen@novell.com
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[Rec-Xml] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E.、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、W3C Rec-Xml-20060816、2006年8月、<http://www.w3.org/tr/2006/rec-xml-20060816/>。
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>.
[rec-xml-infoset] Cowan、J。and R. Tobin、「XML Information Set（第2版）」、W3C REC-XML-INFOSET-20040204、2004年2月、<http://www.w3.org/tr/2004/rec-xml-infoset-20040204/>。
[REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C REC-xml-names-20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-names-20060816/>.
[Rec-XML-Names] Bray、T.、Hollander、D.、Layman、A。、およびR. Tobin、「XML 1.0の名前空間（第2版）」、W3C REC-XML-NAMES-20060816、2006年8月、<http：// www.w3.org/tr/2006/rec-xml-names-names-20060816/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.、ed。C.ニューマン、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、2005年7月。
[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291] Slein、J.、Vitali、F.、Whitehead、E。、およびD. Durand、「World Wide Webの分散オーサリングおよびバージョンプロトコルの要件」、RFC 2291、1998年2月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、Ellison、T.、Kaler、C。、およびJ. Whitehead、「WebDAVへのバージョン化拡張機能（Web分散オーサリングとバージョン化）」、RFC 3253、2002年3月。
[RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003.
[RFC3648] Whitehead、J。and J. Reschke、ed。、「Web分散オーサリングとバージョン（WebDAV）注文コレクションプロトコル」、RFC 3648、2003年12月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744] Clemm、G.、Reschke、J.、Sedlar、E。、およびJ. Whitehead、「Web分散オーサリングおよびバージョン（WebDAV）アクセス制御プロトコル」、RFC 3744、2004年5月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XMLは、XML要素にコンテンツがないことを示すための2つのメカニズムをサポートしています。1つ目は、フォーム<a> </a>のXML要素を宣言することです。2つ目は、フォーム<a/>のXML要素を宣言することです。2つのXML要素は意味的に同一です。
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of whitespace, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XMLは、合法であると思われるが実際にはそうではないデータを簡単に送信できる柔軟なデータ形式です。「あなたが受け入れるものに柔軟になり、送信するものに厳格になる」という哲学はまだ適用されますが、不適切に適用してはなりません。XMLは、白人の問題、要素の順序付け、新しい要素の挿入などの問題に非常に柔軟に対処できます。この柔軟性は、特に要素の意味の領域では拡張を必要としません。
There is no kindness in accepting illegal combinations of XML elements. At best, it will cause an unwanted result and at worst it can cause real damage.
XML要素の違法な組み合わせを受け入れることには優しさはありません。せいぜい、それは望ましくない結果を引き起こし、最悪の場合は本当の損傷を引き起こす可能性があります。
The following request body for a PROPFIND method is illegal.
Propfindメソッドの次の要求本体は違法です。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus, the above is an error and must be responded to with a 400 (Bad Request).
Propfind要素の定義は、両方ではなく、AllPropまたはPropname要素のみを許可します。したがって、上記はエラーであり、400（悪い要求）で応答する必要があります。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
ただし、サーバーが「親切」になりたいと思っていて、AllProp要素を真の要素として選択して応答することを決めたと想像してください。サーバーがコマンドをAllPropとして扱った場合、プロップ名を実行することを意図した帯域幅の限定行を越えて走っているクライアントは、大きな驚きになります。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
さらに、サーバーが寛容でこのリクエストに返信することを決定した場合、結果はサーバーごとにランダムに異なり、一部のサーバーはAllPropディレクティブを実行し、他のサーバーがPropnameディレクティブを実行します。これにより、相互運用性が向上するのではなく、相互運用性が低下します。
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
前の例は、プロップファインド要素に一緒に表示されることを明示的に禁止された2つの要素が含まれていたため、違法でした。ただし、XMLは拡張可能な言語であるため、Propfindで使用するために新しい要素が定義されていると想像できます。以下は、Propfindの要求本体であり、前の例と同様に、期限切れのプロップス要素を理解していないサーバーによって400（悪い要求）で拒否する必要があります。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<E:expired-props/>
</D:propfind>
To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it.
400（悪いリクエスト）が返される理由を理解するために、期限切れのプロップに不慣れなサーバーがそれを見ているので、リクエスト本体を見てみましょう。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
</D:propfind>
As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in Section 17, it must process the request as if the element were not there. Thus, the server sees an empty propfind, which by the definition of the propfind element is illegal.
サーバーは、セクション17で指定されたWebDAV固有のXML処理ルールによれば、「期限切れのプロップ」要素を理解していないため、要素がそこにないかのようにリクエストを処理する必要があります。したがって、サーバーには空の推定が表示されます。これは、Propfind Elementの定義により違法です。
Please note that had the extension been additive, it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
拡張機能が加算性であった場合、必ずしも400（悪い要求）になるとは限りません。たとえば、次の要求本体を想像してください。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
前の例には、架空の要素の休暇が含まれています。その目的は、名前が提出されたパターンと一致するプロパティの返品を防ぐことです。前の例が「残り」に不慣れなサーバーに送信された場合、唯一の結果は「除外」要素が無視され、プロップ名が実行されることです。
WebDAV was designed to be, and has been found to be, backward-compatible with HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients as well as WebDAV-aware clients, but the responses to PUT and DELETE have been extended in this specification in ways that only a WebDAV client would be entirely prepared for. Some theoretical concerns were raised about whether those responses would cause interoperability problems with HTTP-only clients, and this section addresses those concerns.
WebDAVは、HTTP 1.1と後方互換であるように設計されており、発見されています。PUTおよび削除メソッドはHTTPで定義されているため、HTTPクライアントとWebDAVを認識するクライアントによって使用される場合がありますが、Put and Deleteへの応答は、WebDAVクライアントのみが完全に準備される方法でこの仕様に拡張されています。。これらの応答がHTTPのみのクライアントと相互運用性の問題を引き起こすかどうかについて、いくつかの理論的懸念が提起され、このセクションではこれらの懸念について説明します。
Since any HTTP client ought to handle unrecognized 400-level and 500- level status codes as errors, the following new status codes should not present any issues: 422, 423, and 507 (424 is also a new status code but it appears only in the body of a Multistatus response.) So, for example, if an HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user.
HTTPクライアントは、エラーとして認識されていない400レベルおよび500レベルのステータスコードを処理する必要があるため、次の新しいステータスコードは422、423、および507（424も新しいステータスコードですが、にのみ表示されますが、たとえば、HTTPクライアントがロックされたリソースを配置または削除しようとした場合、423ロックされた応答がユーザーに提示される一般的なエラーになるはずです。
The 207 Multistatus response is interesting because an HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. That interpretation isn't entirely justified, because a 200-level response indicates that the server "received, understood, and accepted" the request, not that the request resulted in complete success.
207 MultiStatusの応答は興味深いです。なぜなら、リソースがコレクションであることを認識しておらず、削除操作が完全である可能性があることを理解できない場合でも、コレクションに削除リクエストを発行するHTTPクライアントが207の応答を成功と解釈する可能性があるため、興味深いです。部分的な障害。200レベルの応答は、サーバーがリクエストを「受信、理解し、受け入れた」ことを示しているため、その解釈は完全に正当化されるわけではありません。
One option is that a server could treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) for an error. This approach would indeed maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern is more theoretical than practical. Thus, servers are likely to be completely successful at interoperating with HTTP clients even if they treat any collection DELETE request as a WebDAV request and send a 207 Multi-Status response.
1つのオプションは、サーバーがコレクションの削除をアトミック操作として扱い、成功した場合に204個のコンテンツを使用するか、エラーのために適切なエラー応答（400レベルまたは500レベル）を使用できることです。このアプローチは、実際に後方互換性を最大化するでしょう。ただし、相互運用性テストとワーキンググループディスカッションは、WebDAVコレクションに対して削除リクエストを発行するHTTPクライアントのインスタンスを表示していないため、この懸念は実用的よりも理論的です。したがって、サーバーは、Collection削除要求をWebDAVリクエストとして扱い、207のマルチステータス応答を送信した場合でも、HTTPクライアントとの相互運用に完全に成功する可能性があります。
In general, server implementations are encouraged to use the detailed responses and other mechanisms defined in this document rather than make changes for theoretical interoperability concerns.
一般に、サーバーの実装は、理論的相互運用性の懸念の変更を加えるのではなく、このドキュメントで定義されている詳細な応答やその他のメカニズムを使用することをお勧めします。
The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time.
「Opaquelocktoken」URIスキームは、[RFC2518]（およびIANAによって登録されています）で定義され、構文的に正しい、uuidsから生成しやすいURIを作成し、ロックトークンとして使用することを目的としており、すべてのリソースでユニークであることを目的としています。いつも。
An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID.
opaquelocktoken URIは、'opaquelocktoken' schemeとUUIDを、任意のextensionとともに連結して構成します。サーバーは、新しいlock tokenごとに新しいUUIDを作成できます。サーバーがUUIDを再利用する場合はextensionを追加しなければならず (MUST)、そのextensionを生成するalgorithmは、同じextensionが対応するUUIDとともに2回使用されないことを保証しなければなりません (MUST)。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; is not allowed between elements of
; this production.
Extension = path ; path is defined in Section 3.3 of [RFC3986]
extension = path;パスは[RFC3986]のセクション3.3で定義されています
The original WebDAV model for locking unmapped URLs created "lock-null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs (see Section 7.3) creates "locked empty resources". Lock-null resources are deprecated. This section discusses the original model briefly because clients MUST be able to handle either model.
マッピングされていないURLをロックする従来のWebDAVモデルでは、"lock-null resource"を作成していました。このモデルは複雑すぎたため、相互運用性および実装上の問題がいくつか見つかりました。マッピングされていないURLをロックする新しいWebDAVモデル（セクション7.3を参照）では、"locked empty resource"を作成します。lock-null resourceは非推奨です。クライアントはどちらのモデルも処理できなければならない (MUST) ため、本節では従来のモデルについて簡潔に説明します。
In the original "lock-null resource" model, which is no longer recommended for implementation:
元の「ロックヌルリソース」モデルでは、実装には推奨されなくなりました。
o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o ロックヌルのリソースは、「見つからない」と表示されることがありました。サーバーは、put、mkcol、options、propfind、lock、lockを除く任意の方法に404または405で応答します。
o A lock-null resource does however show up as a member of its parent collection.
o ただし、ロックヌルリソースは、その親コレクションのメンバーとして表示されます。
o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlocked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved.
o サーバーは、通常のリソースに変換される前にロックがなくなると、ロックヌルリソースを完全に削除します（URIはマップされていません）。ロックは、有効期限が切れたりロック解除されている場合だけでなく、リソースの名前が変更または移動された場合、または親コレクションが変更または移動された場合にも削除されることを思い出してください。
o The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful.
o サーバーは、URLへのリクエストが成功した場合、ロックヌルリソースを通常のリソースに変換します。
o The server converts the lock-null resource into a collection if a MKCOL request to the URL is successful (though interoperability experience showed that not all servers followed this requirement).
o サーバーは、URLへのMKCOL要求が成功した場合、ロックヌルリソースをコレクションに変換します（ただし、相互運用性エクスペリエンスは、すべてのサーバーがこの要件に従っているわけではないことを示しました）。
o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype.
o プロパティ値は、DAV：Lock -DiscoveryおよびDAV：SupportEdLockプロパティで定義されましたが、DAV：GetContentTypeのような他のプロパティでは必ずしもそうではありません。
Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
クライアントは、古いモデルの「ロックヌルリソース」をサポートするサーバーと、MKCOLまたはGETではなくマップされていないURLへのロックの後にプットを試みることにより、「ロックされた空のリソース」の推奨モデルと簡単に相互運用できます。
A WebDAV client implemented to this specification might find servers that create lock-null resources (implemented before this specification using [RFC2518]) as well as servers that create locked empty resources. The response to the LOCK request will not indicate what kind of resource was created. There are a few techniques that help the client deal with either type.
この仕様に実装されたWebDAVクライアントは、ロックナルリソースを作成するサーバー（[RFC2518]を使用してこの仕様の前に実装された）と、ロックされた空のリソースを作成するサーバーを見つける場合があります。ロックリクエストへの応答は、どのようなリソースが作成されたかを示しません。クライアントがいずれかのタイプに対処するのに役立ついくつかの手法があります。
If the client wishes to avoid accidentally creating either lock-null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource.
クライアントがロックヌルまたは空のロックされたリソースのいずれかを誤って作成しないようにしたい場合、「if-match： *」ヘッダーをロックリクエストに含めることができ、サーバーが新しいリソースの作成を防ぐことができます。
If a LOCK request creates a resource and the client subsequently wants to overwrite that resource using a COPY or MOVE request, the client should include an "Overwrite: T" header.
ロックリクエストがリソースを作成し、その後、クライアントがコピーまたは移動要求を使用してそのリソースを上書きしたい場合、クライアントには「上書き：t」ヘッダーを含める必要があります。
If a LOCK request creates a resource and the client then decides to get rid of that resource, a DELETE request is supposed to fail on a lock-null resource and UNLOCK should be used instead. But with a locked empty resource, UNLOCK doesn't make the resource disappear. Therefore, the client might have to try both requests and ignore an error in one of the two requests.
ロック要求がリソースを作成し、クライアントがそのリソースを削除することを決定した場合、削除要求はロックヌルリソースで失敗することになっており、代わりにロックを解除する必要があります。しかし、ロックされた空のリソースを使用すると、ロックを解除してもリソースが消えません。したがって、クライアントは両方のリクエストを試して、2つのリクエストのいずれかでエラーを無視する必要がある場合があります。
Many WebDAV clients that have already been implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name, nonce, and other challenge information. Note that the results of some requests might vary according to whether or not the client is authenticated -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous.
すでに実装されている多くのWebDAVクライアントには、アカウント設定があります（電子メールクライアントがIMAPアカウント設定を保存する方法と同様）。したがって、WebDAVクライアントは、サーバーの名前、NONCE、およびその他のチャレンジ情報を使用してサーバーから認証チャレンジを取得する方法があれば、サーバーへの最初のカップルリクエストで認証することができます。一部のリクエストの結果は、クライアントが認証されているかどうかによって異なる場合があることに注意してください。クライアントが認証されている場合は、より目に見えるリソースを返す可能性がありますが、クライアントが匿名である場合は失敗しない可能性があります。
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
クライアントがサーバーをトリガーして認証チャレンジを提供する方法はいくつかあります。この付録では、特に機能する可能性が高いと思われるいくつかのアプローチについて説明しています。
The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe, the client could add a conditional header to ensure that even if the request passes permissions checks, it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.5), or if the server does not need to test authorization.
最初のアプローチは、認証が必要なリクエストを実行することです。ただし、認証がなくてもサーバーがリクエストを処理する可能性があるため、完全に安全であるために、クライアントは条件付きヘッダーを追加して、要求がアクセス許可チェックに合格しても、実際にはサーバーによって処理されないことを確認できます。このアプローチに従う例は、メイクアップされたETAG値を持つ「if-match」ヘッダーを持つPutリクエストを使用することです。このアプローチは、必要に応じて条件をテストする前にサーバーが承認をテストしない場合（セクション8.5を参照）、またはサーバーが認証をテストする必要がない場合、認証チャレンジに失敗する可能性があります。
Example - forcing auth challenge with write request
例 - 書き込みリクエストを使用したAuth Challengeを強制します
>>Request
>>リクエスト
PUT /forceauth.txt HTTP/1.1
Host: www.example.com
If-Match: "xxx"
Content-Type: text/plain
Content-Length: 0
The second approach is to use an Authorization header (defined in [RFC2617]), which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials. This approach relies on the server responding with a "401 Unauthorized" along with a challenge if it receives an Authorization header with an unrecognized username, invalid password, or if it doesn't even handle Basic authentication. This seems likely to work because of the requirements of RFC 2617:
2番目のアプローチは、承認ヘッダー（[RFC2617]で定義されている）を使用することです。これは、サーバーによって拒否される可能性が高いが、適切な認証チャレンジを促します。たとえば、クライアントは、構成された基本ユーザーIDを含む認証ヘッダーを含むPropfindリクエスト（パスワード文字列または実際のもっともらしい資格情報）から始めることができます。このアプローチは、認識されていないユーザー名、無効なパスワード、または基本的な認証さえ処理しない場合、「401の不正」で応答する「401の不正」で応答し、チャレンジに依存しています。これは、RFC 2617の要件のために機能する可能性が高いようです。
"If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource."
"origin serverがリクエストとともに送信されたcredentialを受け入れない場合、401 (Unauthorized)レスポンスを返すべきです (SHOULD)。レスポンスには、リクエスト対象のリソースに適用可能なchallengeを少なくとも1つ（新しいchallengeでもよい）含むWWW-Authenticateヘッダーフィールドを含めなければなりません (MUST)。"
There's a slight problem with implementing that recommendation in some cases, because some servers do not even have challenge information for certain resources. Thus, when there's no way to authenticate to a resource or the resource is entirely publicly available over all accepted methods, the server MAY ignore the Authorization header, and the client will presumably try again later.
一部のサーバーは特定のリソースについてchallenge情報自体を持たないため、場合によってはこの推奨事項の実装にわずかな問題があります。そのため、リソースへ認証する手段がない場合、または許可されるすべてのメソッドを通じてリソースが完全に公開されている場合、サーバーはAuthorizationヘッダーを無視してもよい (MAY)。クライアントは、おそらく後で再試行します。
Example - forcing auth challenge with Authorization header
例 - 認証ヘッダーを使用してAUTHチャレンジを強制します
>>Request
>>リクエスト
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
[body omitted]
[ボディ省略]
This section lists major changes between this document and RFC 2518, starting with those that are likely to result in implementation changes. Servers will advertise support for all changes in this specification by returning the compliance class "3" in the DAV response header (see Sections 10.1 and 18.3).
このセクションでは、このドキュメントとRFC 2518の間の大きな変更をリストし、実装の変更をもたらす可能性が高いものから始めます。サーバーは、DAV応答ヘッダーのコンプライアンスクラス「3」を返すことにより、この仕様のすべての変更のサポートを宣伝します（セクション10.1および18.3を参照）。
Collections and Namespace Operations
コレクションと名前空間操作
o The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed so that servers return results including, at a minimum, the live properties defined in this specification, but not necessarily return other live properties. The 'allprop' directive therefore means something more like "return all properties that are supposed to be returned when 'allprop' is requested" -- a set of properties that may include custom properties and properties defined in other specifications if those other specifications so require. Related to this, 'allprop' requests can now be extended with the 'include' syntax to include specific named properties, thereby avoiding additional requests due to changed 'allprop' semantics.
o Propfind 'AllProp'（セクション9.1）のセマンティクスは緩和されているため、サーバーはこの仕様で定義されているライブプロパティを最小限に抑えますが、必ずしも他のライブプロパティを返すわけではありません。したがって、「AllProp」ディレクティブは、「AllProp」が要求されたときに返されるはずのすべてのプロパティを返すすべてのプロパティ」 - 他の仕様が必要な場合に他の仕様で定義されたカスタムプロパティとプロパティを含むプロパティのセットのようなものを意味します。。これに関連して、「AllProp」要求を「含める」構文を使用して拡張して特定の名前のプロパティを含めることができるため、「AllProp」セマンティクスを変更するための追加のリクエストを回避できます。
o Servers are now allowed to reject PROPFIND requests with Depth: Infinity. Clients that used this will need to be able to do a series of Depth:1 requests instead.
o サーバーは、深さ：InfinityでPropfindリクエストを拒否できるようになりました。これを使用したクライアントは、代わりに一連の深さを実行できる必要があります。
o Multi-Status response bodies now can transport the value of HTTP's Location response header in the new 'location' element. Clients may use this to avoid additional roundtrips to the server when there is a 'response' element with a 3xx status (see Section 14.24).
o マルチステータス応答本体は、新しい「位置」要素でHTTPの位置応答ヘッダーの値を輸送できるようになりました。クライアントはこれを使用して、3xxステータスの「応答」要素がある場合にサーバーへの追加のラウンドトリップを回避できます（セクション14.24を参照）。
o The definition of COPY has been relaxed so that it doesn't require servers to first delete the target resources anymore (this was a known incompatibility with [RFC3253]). See Section 9.8.
o コピーの定義は緩和されているため、最初にターゲットリソースを削除するためにサーバーを必要としなくなりました（これは[RFC3253]との既知の非互換性でした）。セクション9.8を参照してください。
Headers and Marshalling
ヘッダーとマーシャリング
o The Destination and If request headers now allow absolute paths in addition to full URIs (see Section 8.3). This may be useful for clients operating through a reverse proxy that does rewrite the Host request header, but not WebDAV-specific headers.
o 宛先とリクエストヘッダーが完全なURIに加えて絶対パスを許可する場合（セクション8.3を参照）。これは、WebDAV固有のヘッダーではなく、ホストリクエストヘッダーを書き換える逆プロキシを介して動作するクライアントに役立つ場合があります。
o This specification adopts the error marshalling extensions and the "precondition/postcondition" terminology defined in [RFC3253] (see Section 16). Related to that, it adds the "error" XML element inside multistatus response bodies (see Section 14.5, however note that it uses a format different from the one recommended in RFC 3253).
o この仕様では、[RFC3253]で定義されている「拡張機能と「前提条件/事後条件」という用語をマーシャリングするエラーが採用されています（セクション16を参照）。それに関連して、Multistatus応答ボディ内に「エラー」XML要素を追加します（セクション14.5を参照してくださいが、RFC 3253で推奨される形式とは異なる形式を使用していることに注意してください）。
o Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see Section 19).
o 現在、送信者と受信者は、XMLメッセージ本文でエンコードするUTF-16文字をサポートする必要があります（セクション19を参照）。
o Clients are now required to send the Depth header on PROPFIND requests, although servers are still encouraged to support clients that don't.
o クライアントは現在、Propfindリクエストで深度ヘッダーを送信する必要がありますが、サーバーはまだそうでないクライアントをサポートするように奨励されています。
Locking
ロック
o RFC 2518's concept of "lock-null resources" (LNRs) has been replaced by a simplified approach, the "locked empty resources" (see Section 7.3). There are some aspects of lock-null resources clients cannot rely on anymore, namely, the ability to use them to create a locked collection or the fact that they disappear upon UNLOCK when no PUT or MKCOL request was issued. Note that servers are still allowed to implement LNRs as per RFC 2518.
o RFC 2518の「ロックヌルリソース」（LNRS）の概念は、単純化されたアプローチである「ロックされた空のリソース」に置き換えられました（セクション7.3を参照）。クライアントがもう頼ることができないロックヌルリソースには、ロックされたコレクションを作成するためにそれらを使用する能力、またはPutまたはMKCOLリクエストが発行されたときにロック解除時に消えるという事実には、いくつかの側面があります。RFC 2518に従って、サーバーは引き続きLNRを実装できることに注意してください。
o There is no implicit refresh of locks anymore. Locks are only refreshed upon explicit request (see Section 9.10.2).
o ロックの暗黙の更新はもうありません。ロックは、明示的なリクエストでのみ更新されます（セクション9.10.2を参照）。
o Clarified that the DAV:owner value supplied in the LOCK request must be preserved by the server just like a dead property (Section 14.17). Also added the DAV:lockroot element (Section 14.12), which allows clients to discover the root of lock.
o DAV：ロックリクエストで提供される所有者の価値は、死んだプロパティのようにサーバーによって保存されなければならないことを明らかにしました（セクション14.17）。また、DAV：Lockroot要素（セクション14.12）を追加しました。これにより、クライアントはロックのルートを発見できます。
Collections and Namespace Operations
コレクションと名前空間操作
o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3).
o 相互運用性の問題により、マルチスタッツ応答の「HREF」要素の内容の許容形式は限られています（セクション8.3を参照）。
o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9).
o 実装が不足しているため、コピーと移動の「プロパティベハビオール」要求本文のサポートが削除されました。代わりに、資産保存の要件が明確にされています（セクション9.8および9.9を参照）。
Properties
プロパティ
o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3).
o プロパティ値のストレージ、特に言語情報（XML：LANG）、Whitespace、およびXML NameSpace情報の持続性のためのサーバー要件の強化（セクション4.3を参照）。
o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15).
o クライアントがどのプロパティを書くべきかについての要件を明確にしました。特に、「DAV：DisplayName」の設定は、サーバーによってサポートされる必要があります（セクション15を参照）。
o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7).
o 「RFC1123-DATE」プロダクションのみが、DAV：GetLastModifiedの価値として合法です（セクション15.7を参照）。
Headers and Marshalling
ヘッダーとマーシャリング
o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5).
o サーバーは、条件付きヘッダーを処理する前に、承認チェックを行う必要があります（セクション8.5を参照）。
Locking
ロック
o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
o ロックされたリソースにアクセスするときにロック作成者のIDを確認するための強化要件（セクション6.4を参照）。クライアントは、ロックトークンが他のプリンシパルに戻っていることを使用して、もしあったとしてもロックを破るためにのみ使用できることに注意する必要があります。
o Section 8.10.4 of [RFC2518] incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (Section 9.10).
o [RFC2518]のセクション8.10.4は、207ステータスが本当に適切である409ステータスを返すためにサーバーを誤って要求しました。これは修正されました（セクション9.10）。
The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see Section 5.2).
コレクション状態の定義は修正されているため、リクエスト-URIによって異なることはもうありません（セクション5.2を参照）。
The DAV:source property introduced in Section 4.6 of [RFC2518] was removed due to lack of implementation experience.
[RFC2518]のセクション4.6で導入されたDAV：ソースプロパティは、実装の経験がないため削除されました。
The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1).
DAVヘッダーは、コンプライアンスクラスのトークンに加えて、URIを介して非拡張機能を許可します。この仕様では、ここで定義されているコンプライアンスクラスの関連するセマンティクスを定義するものではありませんが、リクエストでも使用できます（セクション10.1を参照）。
In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2).
RFC 2518では、深度ヘッダーの定義（セクション9.2）では、デフォルトでは、リクエストヘッダーが各リソースに範囲内の各リソースに適用される必要がありました。実装エクスペリエンスに基づいて、デフォルトが逆転しました（セクション10.2を参照）。
The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and the Status-URI response header (Section 9.7) have been removed due to lack of implementation.
HTTPステータスコード102（[RFC2518]、セクション10.1）およびステータス-URI応答ヘッダー（セクション9.7）の定義は、実装の欠如により削除されました。
The TimeType format used in the Timeout request header and the "timeout" XML element used to be extensible. Now, only the two formats defined by this specification are allowed (see Section 10.7).
タイムアウトリクエストヘッダーで使用されるタイムタイプ形式と「タイムアウト」XML要素は拡張可能でした。これで、この仕様で定義された2つの形式のみが許可されます（セクション10.7を参照）。
Author's Address
著者の連絡先
Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US
Lisa Dusseault（編集者）CommerceNet 2064 Edgewood Dr. Palo Alto、CA 94303 US
EMail: ldusseault@commerce.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。