[要約] RFC 3744は、WebDAVアクセス制御プロトコルに関する規格であり、Webリソースへのアクセス制御を提供することを目的としています。この規格は、ユーザーがWebリソースに対して適切な権限を持つことを確保し、セキュリティとプライバシーを向上させるために使用されます。
Network Working Group G. Clemm
Request for Comments: 3744 IBM
Category: Standards Track J. Reschke
greenbytes
E. Sedlar
Oracle Corporation
J. Whitehead
U.C. Santa Cruz
May 2004
Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
Web分散オーサリングとバージョン（WebDAV）アクセス制御プロトコル
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 Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names.
このドキュメントは、WebDAV分散オーサリングプロトコルへのアクセス制御拡張機能を定義するメソッド、ヘッダー、メッセージボディ、プロパティ、およびレポートのセットを指定します。このプロトコルにより、クライアントは、特定のプリンシパルによるリソース（HyperText Transfer Protocol（HTTP）メソッドの呼び出しなど）で操作を許可または拒否するかどうかをサーバーに指示するアクセス制御リストを読み取り、変更できます。Webリソースとしてのプリンシパルの軽量表現は、幅広いユーザー管理リポジトリの統合をサポートしています。検索操作により、人間名を使用した校長の発見と操作が可能になります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terms. . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Principals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. DAV:read Privilege . . . . . . . . . . . . . . . . . . . 10
3.2. DAV:write Privilege. . . . . . . . . . . . . . . . . . . 10
3.3. DAV:write-properties Privilege . . . . . . . . . . . . . 10
3.4. DAV:write-content Privilege. . . . . . . . . . . . . . . 11
3.5. DAV:unlock Privilege . . . . . . . . . . . . . . . . . . 11
3.6. DAV:read-acl Privilege . . . . . . . . . . . . . . . . . 11
3.7. DAV:read-current-user-privilege-set Privilege. . . . . . 12
3.8. DAV:write-acl Privilege. . . . . . . . . . . . . . . . . 12
3.9. DAV:bind Privilege . . . . . . . . . . . . . . . . . . . 12
3.10. DAV:unbind Privilege . . . . . . . . . . . . . . . . . . 12
3.11. DAV:all Privilege. . . . . . . . . . . . . . . . . . . . 13
3.12. Aggregation of Predefined Privileges . . . . . . . . . . 13
4. Principal Properties . . . . . . . . . . . . . . . . . . . . . 13
4.1. DAV:alternate-URI-set. . . . . . . . . . . . . . . . . . 14
4.2. DAV:principal-URL. . . . . . . . . . . . . . . . . . . . 14
4.3. DAV:group-member-set . . . . . . . . . . . . . . . . . . 14
4.4. DAV:group-membership . . . . . . . . . . . . . . . . . . 14
5. Access Control Properties. . . . . . . . . . . . . . . . . . . 15
5.1. DAV:owner. . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Example: Retrieving DAV:owner . . . . . . . . . . 15
5.1.2. Example: An Attempt to Set DAV:owner. . . . . . . 16
5.2. DAV:group. . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. DAV:supported-privilege-set. . . . . . . . . . . . . . . 18
5.3.1. Example: Retrieving a List of Privileges
Supported on a Resource . . . . . . . . . . . . . 19
5.4. DAV:current-user-privilege-set . . . . . . . . . . . . . 21
5.4.1. Example: Retrieving the User's Current Set of
Assigned Privileges . . . . . . . . . . . . . . . 22
5.5. DAV:acl. . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5.1. ACE Principal . . . . . . . . . . . . . . . . . . 23
5.5.2. ACE Grant and Deny. . . . . . . . . . . . . . . . 25
5.5.3. ACE Protection. . . . . . . . . . . . . . . . . . 25
5.5.4. ACE Inheritance . . . . . . . . . . . . . . . . . 25
5.5.5. Example: Retrieving a Resource's Access Control
List. . . . . . . . . . . . . . . . . . . . . . . 25
5.6. DAV:acl-restrictions . . . . . . . . . . . . . . . . . . 27
5.6.1. DAV:grant-only. . . . . . . . . . . . . . . . . . 27
5.6.2. DAV:no-invert ACE Constraint. . . . . . . . . . . 28
5.6.3. DAV:deny-before-grant . . . . . . . . . . . . . . 28
5.6.4. Required Principals . . . . . . . . . . . . . . . 28
5.6.5. Example: Retrieving DAV:acl-restrictions. . . . . 28
5.7. DAV:inherited-acl-set. . . . . . . . . . . . . . . . . . 29
5.8. DAV:principal-collection-set . . . . . . . . . . . . . . 30
5.8.1. Example: Retrieving DAV:principal-collection-set. 30
5.9. Example: PROPFIND to retrieve access control properties. 32
6. ACL Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36
7. Access Control and existing methods. . . . . . . . . . . . . . 37
7.1. Any HTTP method. . . . . . . . . . . . . . . . . . . . . 37
7.1.1. Error Handling. . . . . . . . . . . . . . . . . . 37
7.2. OPTIONS. . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1. Example - OPTIONS . . . . . . . . . . . . . . . . 39
7.3. MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4. COPY . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.5. LOCK . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Access Control Methods . . . . . . . . . . . . . . . . . . . . 40
8.1. ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1.1. ACL Preconditions . . . . . . . . . . . . . . . . 40
8.1.2. Example: the ACL method . . . . . . . . . . . . . 42
8.1.3. Example: ACL method failure due to protected
ACE conflict. . . . . . . . . . . . . . . . . . . 43
8.1.4. Example: ACL method failure due to an
inherited ACE conflict. . . . . . . . . . . . . . 44
8.1.5. Example: ACL method failure due to an attempt
to set grant and deny in a single ACE . . . . . . 45
9. Access Control Reports . . . . . . . . . . . . . . . . . . . . 46
9.1. REPORT Method. . . . . . . . . . . . . . . . . . . . . . 46
9.2. DAV:acl-principal-prop-set Report. . . . . . . . . . . . 47
9.2.1. Example: DAV:acl-principal-prop-set Report. . . . 48
9.3. DAV:principal-match REPORT . . . . . . . . . . . . . . . 49
9.3.1. Example: DAV:principal-match REPORT . . . . . . . 50
9.4. DAV:principal-property-search REPORT . . . . . . . . . . 51
9.4.1. Matching. . . . . . . . . . . . . . . . . . . . . 53
9.4.2. Example: successful DAV:principal-property-search
REPORT. . . . . . . . . . . . . . . . . . . . . . 54
9.5. DAV:principal-search-property-set REPORT . . . . . . . . 56
9.5.1. Example: DAV:principal-search-property-set
REPORT. . . . . . . . . . . . . . . . . . . . . . 58
10. XML Processing . . . . . . . . . . . . . . . . . . . . . . . . 59
11. Internationalization Considerations. . . . . . . . . . . . . . 59
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 60
12.1. Increased Risk of Compromised Users. . . . . . . . . . . 60
12.2. Risks of the DAV:read-acl and
DAV:current-user-privilege-set Privileges. . . . . . . . 60
12.3. No Foreknowledge of Initial ACL. . . . . . . . . . . . . 61
13. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 61
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 62
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
16.1. Normative References . . . . . . . . . . . . . . . . . . 62
16.2. Informative References . . . . . . . . . . . . . . . . . 63
Appendices
A. WebDAV XML Document Type Definition Addendum . . . . . . . . . 64
B. WebDAV Method Privilege Table (Normative). . . . . . . . . . . 67
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 72
The goal of the WebDAV access control extensions is to provide an interoperable mechanism for handling discretionary access control for content and metadata managed by WebDAV servers. WebDAV access control can be implemented on content repositories with security as simple as that of a UNIX file system, as well as more sophisticated models. The underlying principle of access control is that who you are determines what operations you can perform on a resource. The "who you are" is defined by a "principal" identifier; users, client software, servers, and groups of the previous have principal identifiers. The "operations you can perform" are determined by a single "access control list" (ACL) associated with a resource. An ACL contains a set of "access control entries" (ACEs), where each ACE specifies a principal and a set of privileges that are either granted or denied to that principal. When a principal submits an operation (such as an HTTP or WebDAV method) to a resource for execution, the server evaluates the ACEs in the ACL to determine if the principal has permission for that operation.
WebDAV Access Control拡張機能の目標は、WebDAVサーバーが管理するコンテンツとメタデータの裁量的アクセス制御を処理するための相互運用可能なメカニズムを提供することです。WebDAVアクセス制御は、UNIXファイルシステムのセキュリティと同じくらい簡単なセキュリティを備えたコンテンツリポジトリに実装できます。アクセス制御の根本的な原則は、あなたが誰があなたがリソースで実行できる操作を決定するかということです。「WHO ARE」は、「主要な」識別子によって定義されます。ユーザー、クライアントソフトウェア、サーバー、および以前のグループには、主要な識別子があります。「実行できる操作」は、リソースに関連付けられた単一の「アクセス制御リスト」（ACL）によって決定されます。ACLには、「アクセス制御エントリ」（ACES）のセットが含まれています。各ACEは、そのプリンシパルとそのプリンシパルに付与または拒否される特権のセットを指定します。プリンシパルが実行のためのリソースに操作（HTTPやWebDAVメソッドなど）を提出すると、サーバーはACLのACEを評価して、プリンシパルがその操作の許可を持っているかどうかを判断します。
Since every ACE contains the identifier of a principal, client software operated by a human must provide a mechanism for selecting this principal. This specification uses http(s) scheme URLs to identify principals, which are represented as WebDAV-capable resources. There is no guarantee that the URLs identifying principals will be meaningful to a human. For example, http://www.example.com/u/256432 and http://www.example.com/people/Greg.Stein are both valid URLs that could be used to identify the same principal. To remedy this, every principal resource has the DAV:displayname property containing a human-readable name for the principal.
すべてのACEにはプリンシパルの識別子が含まれているため、人間が動作するクライアントソフトウェアは、このプリンシパルを選択するためのメカニズムを提供する必要があります。この仕様では、http（s）スキームURLを使用して、webdav対応リソースとして表されるプリンシパルを識別します。プリンシパルを特定するURLが人間にとって意味があるという保証はありません。たとえば、http：//www.example.com/u/256432およびhttp://www.example.com/people/greg.steinはどちらも同じプリンシパルを識別するために使用できる有効なURLです。これを改善するために、すべてのプリンシパルリソースには、校長の人間が読み取る名前を含むDAV：DisplayNameプロパティがあります。
Since a principal can be identified by multiple URLs, it raises the problem of determining exactly which principal is being referenced in a given ACE. It is impossible for a client to determine that an ACE granting the read privilege to http://www.example.com/people/ Greg.Stein also affects the principal at http://www.example.com/u/ 256432. That is, a client has no mechanism for determining that two URLs identify the same principal resource. As a result, this specification requires clients to use just one of the many possible URLs for a principal when creating ACEs. A client can discover which URL to use by retrieving the DAV:principal-URL property (Section 4.2) from a principal resource. No matter which of the principal's URLs is used with PROPFIND, the property always returns the same URL.
プリンシパルは複数のURLで識別できるため、特定のACEでどのプリンシパルが参照されているかを正確に決定する問題が発生します。クライアントが、http://www.example.com/people/ greg.steinに読み取り特権を付与するエースがhttp://www.example.com/u/ 256432にも校長に影響することを判断することは不可能です。つまり、クライアントには、2つのURLが同じ主要なリソースを識別することを決定するメカニズムがありません。その結果、この仕様では、クライアントがACEを作成するときにプリンシパルに多くの可能なURLの1つだけを使用する必要があります。クライアントは、主要なリソースからDAV：プリンシパルURLプロパティ（セクション4.2）を取得することにより、どのURLを使用するかを発見できます。プリンシパルのURLのどれがPropfindで使用されていても、プロパティは常に同じURLを返します。
With a system having hundreds to thousands of principals, the problem arises of how to allow a human operator of client software to select just one of these principals. One approach is to use broad collection hierarchies to spread the principals over a large number of collections, yielding few principals per collection. An example of this is a two level hierarchy with the first level containing 36 collections (a-z, 0-9), and the second level being another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such that a principal with last name "Stein" would appear at /s/t/Stein. In effect, this pre-computes a common query, search on last name, and encodes it into a hierarchy. The drawback with this scheme is that it handles only a small set of predefined queries, and drilling down through the collection hierarchy adds unnecessary steps (navigate down/up) when the user already knows the principal's name. While organizing principal URLs into a hierarchy is a valid namespace organization, users should not be forced to navigate this hierarchy to select a principal.
数百から数千のプリンシパルを持つシステムでは、クライアントソフトウェアの人間オペレーターがこれらのプリンシパルの1つのみを選択できるようにする方法の問題が発生します。1つのアプローチは、幅広いコレクション階層を使用して、プリンシパルを多数のコレクションに広めることであり、コレクションごとのプリンシパルはほとんど生成されません。この例は、36のコレクション（A-Z、0-9）を含む最初のレベルの2つのレベルの階層であり、2番目のレベルはさらに36で、コレクション/a/a/、/a/b/、...、/a/z/、姓「スタイン」のプリンシパルが/s/t/スタインで表示されるようにします。実際には、これは一般的なクエリを事前に互換化し、姓で検索し、それを階層にエンコードします。このスキームの欠点は、事前定義されたクエリの小さなセットのみを処理し、コレクション階層を介してドリルダウンすると、ユーザーがプリンシパルの名前を既に知っているときに不必要な手順（下にナビゲート）を追加することです。元本のURLを階層に整理することは有効な名前空間組織ですが、ユーザーはこの階層をナビゲートしてプリンシパルを選択することを余儀なくされるべきではありません。
This specification provides the capability to perform substring searches over a small set of properties on the resources representing principals. This permits searches based on last name, first name, user name, job title, etc. Two separate searches are supported, both via the REPORT method, one to search principal resources (DAV:principal-property-search, Section 9.4), the other to determine which properties may be searched at all (DAV:principal-search-property-set, Section 9.5).
この仕様は、プリンシパルを表すリソース上の小さなプロパティセットでサブストリング検索を実行する機能を提供します。これにより、姓、名、ユーザー名、役職などに基づいて検索が許可されます。レポートメソッドを介して、2つの個別の検索がサポートされています。その他は、どのプロパティを検索できるかを決定します（DAV：Principal-Search-Property-Set、セクション9.5）。
Once a principal has been identified in an ACE, a server evaluating that ACE must know the identity of the principal making a protocol request, and must validate that that principal is who they claim to be, a process known as authentication. This specification intentionally omits discussion of authentication, as the HTTP protocol already has a number of authentication mechanisms [RFC2617]. Some authentication mechanism (such as HTTP Digest Authentication, which all WebDAV compliant implementations are required to support) must be available to validate the identity of a principal.
エースでプリンシパルが特定されたら、ACEがプロトコル要求を作成するプリンシパルのIDを知っている必要があると評価するサーバーは、そのプリンシパルが認証として知られているプロセスであると主張する人であることを検証する必要があります。HTTPプロトコルにはすでに多くの認証メカニズムがあるため、この仕様は認証の議論を意図的に省略しています[RFC2617]。一部の認証メカニズム（HTTPダイジェスト認証など、すべてのWebDAV準拠の実装がサポートするために必要な）を使用できる必要があります。
The following issues are out of scope for this document:
次の問題は、このドキュメントの範囲外です。
o Access control that applies only to a particular property on a resource (excepting the access control properties DAV:acl and DAV:current-user-privilege-set), rather than the entire resource,
o リソース全体ではなく、リソース上の特定のプロパティにのみ適用されるアクセス制御（アクセス制御プロパティDAV：ACLおよびDAV：Current-User-Privilege-Set）を除く）
o Role-based security (where a role can be seen as a dynamically defined group of principals),
o 役割ベースのセキュリティ（役割が動的に定義されたプリンシパルのグループと見なすことができる場合）、
o Specification of the ways an ACL on a resource is initialized,
o リソース上のACLが初期化される方法の仕様、
o Specification of an ACL that applies globally to all resources, rather than to a particular resource.
o 特定のリソースではなく、すべてのリソースにグローバルに適用されるACLの仕様。
o Creation and maintenance of resources representing people or computational agents (principals), and groups of these.
o 人または計算エージェント（プリンシパル）、およびこれらのグループを表すリソースの作成とメンテナンス。
This specification is organized as follows. Section 1.1 defines key concepts used throughout the specification, and is followed by a more in-depth discussion of principals (Section 2), and privileges (Section 3). Properties defined on principals are specified in Section 4, and access control properties for content resources are specified in Section 5. The ways ACLs are to be evaluated is described in Section 6. Client discovery of access control capability using OPTIONS is described in Section 7.2. Interactions between access control functionality and existing HTTP and WebDAV methods are described in the remainder of Section 7. The access control setting method, ACL, is specified in Section 8. Four reports that provide limited server-side searching capabilities are described in Section 9. Sections on XML processing (Section 10), Internationalization considerations (Section 11), security considerations (Section 12), and authentication (Section 13) round out the specification. An appendix (Appendix A) provides an XML Document Type Definition (DTD) for the XML elements defined in the specification.
この仕様は次のように編成されています。セクション1.1は、仕様全体で使用される重要な概念を定義し、その後、プリンシパル（セクション2）および特権（セクション3）のより詳細な議論が続きます。プリンシパルで定義されているプロパティはセクション4で指定されており、コンテンツリソースのアクセス制御プロパティはセクション5で指定されています。ACLを評価する方法は、セクション6で説明します。アクセス制御機能と既存のHTTPおよびWebDAVメソッドとの相互作用は、セクション7の残りの部分で説明されています。アクセス制御設定方法ACLは、セクション8で指定されています。XML処理に関するセクション（セクション10）、国際化に関する考慮事項（セクション11）、セキュリティに関する考慮事項（セクション12）、および認証（セクション13）は仕様を締めくくります。付録（付録A）は、仕様で定義されているXML要素のXMLドキュメントタイプ定義（DTD）を提供します。
This document uses the terms defined in HTTP [RFC2616] and WebDAV [RFC2518]. In addition, the following terms are defined:
このドキュメントでは、HTTP [RFC2616]およびWebDAV [RFC2518]で定義されている用語を使用しています。さらに、次の用語が定義されています。
principal
主要主元本主たる校長元金重要本重重立つ重なる頭株主なる重立った主立った寄託者一枚看板
A "principal" is a distinct human or computational actor that initiates access to network resources. In this protocol, a principal is an HTTP resource that represents such an actor.
「プリンシパル」は、ネットワークリソースへのアクセスを開始する明確な人間または計算アクターです。このプロトコルでは、プリンシパルはそのようなアクターを表すHTTPリソースです。
group
グループ群族集団組系班群れ部門部類仲間群集種別種類群衆連
A "group" is a principal that represents a set of other principals.
「グループ」は、他のプリンシパルのセットを表す校長です。
privilege
特権特典権利光栄
A "privilege" controls access to a particular set of HTTP operations on a resource.
「特権」は、リソース上の特定のHTTP操作セットへのアクセスを制御します。
aggregate privilege
集約特権
An "aggregate privilege" is a privilege that contains a set of other privileges.
「集約特権」は、他の一連の特権を含む特権です。
abstract privilege
抽象的特権
The modifier "abstract", when applied to a privilege on a resource, means the privilege cannot be set in an access control element (ACE) on that resource.
修飾子「要約」は、リソースの特権に適用される場合、そのリソースのアクセス制御要素（ACE）に特権を設定できないことを意味します。
access control list (ACL)
アクセス制御リスト（ACL）
An "ACL" is a list of access control elements that define access control to a particular resource.
「ACL」は、特定のリソースへのアクセス制御を定義するアクセス制御要素のリストです。
access control element (ACE)
アクセス制御要素（ACE）
An "ACE" either grants or denies a particular set of (non-abstract) privileges for a particular principal.
「エース」は、特定のプリンシパルの特定の（非抽象的）特権セットを付与または否定するかのいずれかです。
inherited ACE
継承されたエース
An "inherited ACE" is an ACE that is dynamically shared from the ACL of another resource. When a shared ACE changes on the primary resource, it is also changed on inheriting resources.
「継承されたエース」は、別のリソースのACLから動的に共有されるエースです。共有エースが主要なリソースで変更されると、リソースを継承することでも変更されます。
protected property
保護されたプロパティ
A "protected property" is one whose value cannot be updated except by a method explicitly defined as updating that specific property. In particular, a protected property cannot be updated with a PROPPATCH request.
「保護されたプロパティ」とは、その特定のプロパティを更新すると明示的に定義された方法を除いて、値を更新できないものです。特に、保護されたプロパティをプロップパッチリクエストで更新することはできません。
The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], those rules apply to this document as well.
このドキュメントでプロトコル要素を説明するために使用される拡張BNFは、[RFC2616]のセクション2.1で説明されています。この拡張されたBNFは、[RFC2616]のセクション2.2で提供される基本的な生産ルールを使用しているため、これらのルールもこのドキュメントにも適用されます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [REC-XML]. When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element name.
このドキュメントのXML要素の定義は、XML要素型宣言（XMLドキュメントタイプ宣言に見られるように）を使用します。「DAV：」のXML要素タイプがXMLフラグメントのコンテキスト以外でこのドキュメントで参照される場合、文字列「DAV：」は要素名に付けられます。
A principal is a network resource that represents a distinct human or computational actor that initiates access to network resources. Users and groups are represented as principals in many implementations; other types of principals are also possible. A URI of any scheme MAY be used to identify a principal resource. However, servers implementing this specification MUST expose principal resources at an http(s) URL, which is a privileged scheme that points to resources that have additional properties, as described in Section 4. So, a principal resource can have multiple URIs, one of which has to be an http(s) scheme URL. Although an implementation SHOULD support PROPFIND and MAY support PROPPATCH to access and modify information about a principal, it is not required to do so.
プリンシパルは、ネットワークリソースへのアクセスを開始する明確な人間または計算アクターを表すネットワークリソースです。ユーザーとグループは、多くの実装でプリンシパルとして表されます。他のタイプのプリンシパルも可能です。スキームのURIを使用して、主要なリソースを識別することができます。ただし、この仕様を実装するサーバーは、セクション4で説明されているように、追加のプロパティを持つリソースを指す特権スキームであるHTTP（S）URLで主要なリソースを公開する必要があります。したがって、主要なリソースには複数のURIがあります。これはHTTPスキームURLでなければなりません。実装はPropfindをサポートする必要があり、Proppatchをサポートしてプリンシパルに関する情報にアクセスおよび変更する場合がありますが、そうする必要はありません。
A principal resource may be a group, where a group is a principal that represents a set of other principals, called the members of the group. If a person or computational agent matches a principal resource that is a member of a group, they also match the group. Membership in a group is recursive, so if a principal is a member of group GRPA, and GRPA is a member of group GRPB, then the principal is also a member of GRPB.
主要なリソースはグループである場合があります。グループは、グループのメンバーと呼ばれる他のプリンシパルのセットを表すプリンシパルです。個人または計算エージェントがグループのメンバーである主要なリソースと一致する場合、グループとも一致します。グループのメンバーシップは再帰的であるため、プリンシパルがGRPAのメンバーであり、GRPAがGRPBのメンバーである場合、プリンシパルはGRPBのメンバーでもあります。
Ability to perform a given method on a resource MUST be controlled by one or more privileges. Authors of protocol extensions that define new HTTP methods SHOULD specify which privileges (by defining new privileges, or mapping to ones below) are required to perform the method. A principal with no privileges to a resource MUST be denied any HTTP access to that resource, unless the principal matches an ACE constructed using the DAV:all, DAV:authenticated, or DAV:unauthenticated pseudo-principals (see Section 5.5.1). Servers MUST report a 403 "Forbidden" error if access is denied, except in the case where the privilege restricts the ability to know the resource exists, in which case 404 "Not Found" may be returned.
リソース上で特定のメソッドを実行する能力は、1つ以上の特権によって制御する必要があります。新しいHTTPメソッドを定義するプロトコル拡張の著者は、メソッドを実行するために必要な特権（または以下の特権を定義する、またはマッピングすることにより）を指定する必要があります。リソースに特権を持たないプリンシパルは、DAV：ALL、DAV：認証、またはDAV：認証されていない擬似原理を使用して構築されたACEと一致しない限り、そのリソースへのHTTPアクセスを拒否されなければなりません（セクション5.5.1を参照）。サーバーは、アクセスが拒否された場合、403の「禁止」エラーを報告する必要があります。
Privileges may be containers of other privileges, in which case they are termed "aggregate privileges". If a principal is granted or denied an aggregate privilege, it is semantically equivalent to granting or denying each of the aggregated privileges individually. For example, an implementation may define add-member and remove-member privileges that control the ability to add and remove a member of a group. Since these privileges control the ability to update the state of a group, these privileges would be aggregated by the DAV:write privilege on a group, and granting the DAV:write privilege on a group would also grant the add-member and remove-member privileges.
特権は、他の特権のコンテナである場合があります。その場合、それらは「集計特権」と呼ばれます。校長が総特権を認められたり拒否されたりした場合、それは各集約された特権を個別に許可または拒否することと同じです。たとえば、実装では、グループのメンバーを追加および削除する機能を制御するADDメンバーと削除の特権を定義する場合があります。これらの特権はグループの状態を更新する能力を制御しているため、これらの特権はDAVによって集約されます：グループに特権を書き、DAVを付与する：グループに特権を書き込むことも、追加メンバーを付与し、メンバーを削除します特権。
Privileges may be declared to be "abstract" for a given resource, in which case they cannot be set in an ACE on that resource. Aggregate and non-aggregate privileges are both capable of being abstract. Abstract privileges are useful for modeling privileges that otherwise would not be exposed via the protocol. Abstract privileges also provide server implementations with flexibility in implementing the privileges defined in this specification. For example, if a server is incapable of separating the read resource capability from the read ACL capability, it can still model the DAV:read and DAV:read-acl privileges defined in this specification by declaring them abstract, and containing them within a non-abstract aggregate privilege (say, read-all) that holds DAV:read, and DAV:read-acl. In this way, it is possible to set the aggregate privilege, read-all, thus coupling the setting of DAV:read and DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-acl individually. Since aggregate privileges can be abstract, it is also possible to use abstract privileges to group or organize non-abstract privileges. Privilege containment loops are not allowed; therefore, a privilege MUST NOT contain itself. For example, DAV:read cannot contain DAV:read.
特権は、特定のリソースの「抽象」であると宣言される場合があります。その場合、そのリソースのエースに設定することはできません。集約および非凝集特権はどちらも抽象的であることができます。抽象的特権は、それ以外の場合はプロトコルを介して公開されない特権をモデリングするのに役立ちます。抽象的特権は、この仕様で定義されている特権を実装する際の柔軟性を備えたサーバーの実装も提供します。たとえば、サーバーが読み取りリソース機能を読み取りACL機能から分離できない場合でも、dav：read and dav：read-acl特権を抽象的に宣言し、それらを非nonに含めることにより、読み取りとdav：read-acl特権をモデル化できます。-Dav：read、dav：read-aclを保持している集約特権（たとえば、すべてを読み取り）に抽出します。このようにして、集約特権、読み取りすべてを設定することが可能です。したがって、DAV：readとdav：read-aclの設定を結合することはできますが、DAV：read、またはdav：read-aclを個別に設定することはできません。集約特権は抽象的である可能性があるため、抽象的特権を使用して非抽象的特権をグループ化または整理することもできます。特権封じ込めループは許可されていません。したがって、特権にそれ自体を封じ込めてはなりません。たとえば、DAV：読み取りはDAV：読み取りを含めることはできません。
The set of privileges that apply to a particular resource may vary with the DAV:resourcetype of the resource, as well as between different server implementations. To promote interoperability, however, this specification defines a set of well-known privileges (e.g., DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-current-user-privilege-set, and DAV:all), which can at least be used to classify the other privileges defined on a particular resource. The access permissions on null resources (defined in [RFC2518], Section 3) are solely those they inherit (if any), and they are not discoverable (i.e., the access control properties specified in Section 5 are not defined on null resources). On the transition from null to stateful resource, the initial access control list is set by the server's default ACL value policy (if any).
特定のリソースに適用される特権のセットは、DAV：リソースのResourceType、および異なるサーバーの実装間で異なる場合があります。ただし、相互運用性を促進するために、この仕様ではよく知られている特権のセットを定義します（例：Dav：dav：dav：write、dav：read-acl、dav：write-acl、dav：read-urrent-user-privilege-setを定義します、およびdav：すべて）、少なくとも特定のリソースで定義されている他の特権を分類するために使用できます。ヌルリソースのアクセス権限（[RFC2518]、セクション3で定義）は、継承するものだけであり（ある場合）、発見できません（つまり、セクション5で指定されているアクセス制御プロパティは、ヌルリソースで定義されていません）。NullからStatefulリソースへの移行では、初期アクセス制御リストは、サーバーのデフォルトACL値ポリシー（ある場合）によって設定されます。
Server implementations MAY define new privileges beyond those defined in this specification. Privileges defined by individual implementations MUST NOT use the DAV: namespace, and instead should use a namespace that they control, such as an http scheme URL.
サーバーの実装は、この仕様で定義されているものを超えて新しい特権を定義する場合があります。個々の実装によって定義された特権は、dav：namespaceを使用してはなりません。代わりに、HTTPスキームURLなどの制御する名前空間を使用する必要があります。
The read privilege controls methods that return information about the state of the resource, including the resource's properties. Affected methods include GET and PROPFIND. Any implementation-defined privilege that also controls access to GET and PROPFIND must be aggregated under DAV:read - if an ACL grants access to DAV:read, the client may expect that no other privilege needs to be granted to have access to GET and PROPFIND. Additionally, the read privilege MUST control the OPTIONS method.
読み取り特権は、リソースのプロパティを含むリソースの状態に関する情報を返す方法を制御します。影響を受ける方法には、getとpropfindが含まれます。取得とプロパンドへのアクセスを制御する実装定義の特権は、DAVの下で集計する必要があります：読み取り - ACLがDAVへのアクセスを付与する場合、クライアントは、取得およびプロップにアクセスできるように他の特権を付与する必要がないことを期待するかもしれません。さらに、読み取り特権はオプション方法を制御する必要があります。
<!ELEMENT read EMPTY>
The write privilege controls methods that lock a resource or modify the content, dead properties, or (in the case of a collection) membership of the resource, such as PUT and PROPPATCH. Note that state modification is also controlled via locking (see section 5.3 of [RFC2518]), so effective write access requires that both write privileges and write locking requirements are satisfied. Any implementation-defined privilege that also controls access to methods modifying content, dead properties or collection membership must be aggregated under DAV:write, e.g., if an ACL grants access to DAV:write, the client may expect that no other privilege needs to be granted to have access to PUT and PROPPATCH.
Write Privilegeは、リソースをロックしたり、コンテンツ、デッドプロパティ、または（コレクションの場合）PutやProppatchなどのリソースのメンバーシップを変更するメソッドを制御します。状態の変更はロックを介して制御されることに注意してください（[RFC2518]のセクション5.3を参照）。コンテンツ、デッドプロパティ、またはコレクションメンバーシップを変更するメソッドへのアクセスを制御する実装定義の特権は、DAVの下で集計する必要があります。PutおよびProppatchにアクセスできることを認めています。
<!ELEMENT write EMPTY>
The DAV:write-properties privilege controls methods that modify the dead properties of the resource, such as PROPPATCH. Whether this privilege may be used to control access to any live properties is determined by the implementation. Any implementation-defined privilege that also controls access to methods modifying dead properties must be aggregated under DAV:write-properties - e.g., if an ACL grants access to DAV:write-properties, the client can safely expect that no other privilege needs to be granted to have access to PROPPATCH.
The Dav：Write-Properties Privilegeは、プロップパッチなどのリソースの死んだプロパティを変更する方法を制御します。この特権が、ライブプロパティへのアクセスを制御するために使用されるかどうかは、実装によって決定されます。死んだプロパティを変更するメソッドへのアクセスを制御する実装定義の特権は、DAV：書き込みプロパティの下で集計する必要があります。プロップパッチにアクセスできるようになりました。
<!ELEMENT write-properties EMPTY>
The DAV:write-content privilege controls methods that modify the content of an existing resource, such as PUT. Any implementation-defined privilege that also controls access to content must be aggregated under DAV:write-content - e.g., if an ACL grants access to DAV:write-content, the client can safely expect that no other privilege needs to be granted to have access to PUT. Note that PUT - when applied to an unmapped URI - creates a new resource and therefore is controlled by the DAV:bind privilege on the parent collection.
The Dav：Write-Content特権は、Putなどの既存のリソースのコンテンツを変更するメソッドを制御します。コンテンツへのアクセスを制御する実装定義の特権は、DAV：write-contentの下で集計する必要があります。プットへのアクセス。Put-マッピングされていないURIに適用されると、新しいリソースが作成されるため、DAV：Bind Privilege on the Parent Collectionによって制御されます。
<!ELEMENT write-content EMPTY>
The DAV:unlock privilege controls the use of the UNLOCK method by a principal other than the lock owner (the principal that created a lock can always perform an UNLOCK). While the set of users who may lock a resource is most commonly the same set of users who may modify a resource, servers may allow various kinds of administrators to unlock resources locked by others. Any privilege controlling access by non-lock owners to UNLOCK MUST be aggregated under DAV:unlock.
The DAV：Unlock Privilegeは、ロック所有者以外のプリンシパル（ロックを作成したプリンシパルは常にロック解除を実行できます）以外のプリンシパルによるロック解除方法の使用を制御します。リソースをロックする可能性のあるユーザーのセットは、リソースを変更する可能性のあるユーザーのセットと最も一般的ですが、サーバーはさまざまな種類の管理者が他の人によってロックされたリソースのロックを解除できるようにすることができます。ロックを解除するためにロックしない所有者によるアクセスを制御する特権は、DAV：Unlockの下で集約する必要があります。
A lock owner can always remove a lock by issuing an UNLOCK with the correct lock token and authentication credentials. That is, even if a principal does not have DAV:unlock privilege, they can still remove locks they own. Principals other than the lock owner can remove a lock only if they have DAV:unlock privilege and they issue an UNLOCK with the correct lock token. Lock timeout is not affected by the DAV:unlock privilege.
ロックの所有者は、正しいロックトークンと認証資格情報を使用してロックを解除することにより、常にロックを削除できます。つまり、プリンシパルがDAV：ロック解除特権を持っていなくても、所有しているロックを削除することができます。ロック所有者以外のプリンシパルは、DAV：ロック解除特権を持っている場合にのみロックを削除でき、正しいロックトークンでロックを解除します。ロックタイムアウトは、DAV：ロック解除特権の影響を受けません。
<!ELEMENT unlock EMPTY>
The DAV:read-acl privilege controls the use of PROPFIND to retrieve the DAV:acl property of the resource.
DAV：Read-ACL特権は、Propfindの使用を制御して、リソースのDAV：ACLプロパティを取得します。
<!ELEMENT read-acl EMPTY>
The DAV:read-current-user-privilege-set privilege controls the use of PROPFIND to retrieve the DAV:current-user-privilege-set property of the resource.
DAV：Read-Current-Current-User-Privilege-Set特権は、リソースのDAV：Current-User-Privilege-Setプロパティを取得するためのPropfindの使用を制御します。
Clients are intended to use this property to visually indicate in their UI items that are dependent on the permissions of a resource, for example, by graying out resources that are not writable.
クライアントは、このプロパティを使用して、リソースの許可に依存するUIアイテム、たとえば、書かれていないリソースをグレーアウトすることにより視覚的に示すことを目的としています。
This privilege is separate from DAV:read-acl because there is a need to allow most users access to the privileges permitted the current user (due to its use in creating the UI), while the full ACL contains information that may not be appropriate for the current authenticated user. As a result, the set of users who can view the full ACL is expected to be much smaller than those who can read the current user privilege set, and hence distinct privileges are needed for each.
この特権は、ほとんどのユーザーが現在のユーザーに許可されている特権にアクセスできるようにする必要があるため（UIの作成に使用しているため）、DAV：Read-ACLとは別にあります。現在の認証されたユーザー。その結果、完全なACLを表示できるユーザーのセットは、現在のユーザー特権セットを読み取ることができる人よりもはるかに小さいため、それぞれに明確な特権が必要です。
<!ELEMENT read-current-user-privilege-set EMPTY>
The DAV:write-acl privilege controls use of the ACL method to modify the DAV:acl property of the resource.
DAV：Write-ACL特権は、ACLメソッドの使用を制御して、リソースのDAV：ACLプロパティを変更します。
<!ELEMENT write-acl EMPTY>
The DAV:bind privilege allows a method to add a new member URL to the specified collection (for example via PUT or MKCOL). It is ignored for resources that are not collections.
The Dav：Bind Privilegeを使用すると、指定されたコレクションに新しいメンバーURLを追加できます（たとえば、PutまたはMKCOLを介して）。コレクションではないリソースについては無視されます。
<!ELEMENT bind EMPTY>
The DAV:unbind privilege allows a method to remove a member URL from the specified collection (for example via DELETE or MOVE). It is ignored for resources that are not collections.
DAV：Unbind特権により、指定されたコレクションからメンバーURLを削除する方法が許可されます（たとえば、削除または移動など）。コレクションではないリソースについては無視されます。
<!ELEMENT unbind EMPTY>
DAV:all is an aggregate privilege that contains the entire set of privileges that can be applied to the resource.
DAV：すべては、リソースに適用できる特権のセット全体を含む集約的な特権です。
<!ELEMENT all EMPTY>
Server implementations are free to aggregate the predefined privileges (defined above in Sections 3.1-3.10) subject to the following limitations:
サーバーの実装は、以下の制限を条件として、事前定義された特権（上記で上記で定義されている）を無料で集約することができます（上記で上記で定義）。
DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl, DAV:write-properties, DAV:write-content, or DAV:read-current-user-privilege-set.
DAV：read-aclはDavを含めてはなりません：read、dav：write、write-acl、dav：write-properties、dav：write-content、またはdav：read-current-user-privilege-set。
DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or DAV:read-current-user-privilege-set.
DAV：write-aclはDAVを含めてはなりません：write、dav：read、dav：read-acl、またはdav：read-current-user-privilege-set。
DAV:read-current-user-privilege-set MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or DAV:write-acl.
DAV：Read-Current-User-Privilege-SetはDav：write、dav：read、dav：read-acl、またはdav：write-aclを含めてはなりません。
DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-current-user-privilege-set.
DAV：書き込みはDAV：read、dav：read-acl、またはdav：read-current-user-privilege-setを含めてはなりません。
DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-properties, or DAV:write-content.
DAV：読み取りはDav：write、dav：write-acl、dav：write-properties、またはdav：write-contentを含めてはなりません。
DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and DAV:write-content.
DAV：書き込みはDAV：Bind、Dav：Unbind、Dav：Write-Properties and dav：write-contentを含む必要があります。
Principals are manifested to clients as a WebDAV resource, identified by a URL. A principal MUST have a non-empty DAV:displayname property (defined in Section 13.2 of [RFC2518]), and a DAV:resourcetype property (defined in Section 13.9 of [RFC2518]). Additionally, a principal MUST report the DAV:principal XML element in the value of the DAV:resourcetype property. The element type declaration for DAV:principal is:
プリンシパルは、URLによって識別されるWebDAVリソースとしてクライアントに現れます。プリンシパルには、空でないDAV：DisplayNameプロパティ（[RFC2518]のセクション13.2で定義）とDAV：ResourceTypeプロパティ（[RFC2518]のセクション13.9で定義）が必要です。さらに、プリンシパルは、DAV：DAV：ResourceTypeプロパティの値におけるDAV：プリンシパルXML要素を報告する必要があります。DAVの要素タイプ宣言：プリンシパルは次のとおりです。
<!ELEMENT principal EMPTY> This protocol defines the following additional properties for a principal. Since it can be expensive for a server to retrieve access control information, the name and value of these properties SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of [RFC2518]).
<！要素プリンシパル空>このプロトコルは、プリンシパルの次の追加プロパティを定義します。サーバーがアクセス制御情報を取得するのは高価である可能性があるため、これらのプロパティの名前と値は、[RFC2518]のセクション12.14.1で定義されているように）Propfind AllPropリクエストによって返されるべきではありません。
This protected property, if non-empty, contains the URIs of network resources with additional descriptive information about the principal. This property identifies additional network resources (i.e., it contains one or more URIs) that may be consulted by a client to gain additional knowledge concerning a principal. One expected use for this property is the storage of an LDAP [RFC2255] scheme URL. A user-agent encountering an LDAP URL could use LDAP [RFC2251] to retrieve additional machine-readable directory information about the principal, and display that information in its user interface. Support for this property is REQUIRED, and the value is empty if no alternate URI exists for the principal.
この保護されたプロパティは、空でない場合、プリンシパルに関する追加の記述情報を含むネットワークリソースのURIを含んでいます。このプロパティは、プリンシパルに関する追加の知識を得るためにクライアントが相談することができる追加のネットワークリソース（つまり、1つ以上のURIが含まれています）を識別します。このプロパティの予想される使用の1つは、LDAP [RFC2255]スキームURLのストレージです。LDAP URLに遭遇するユーザーエージェントは、LDAP [RFC2251]を使用して、プリンシパルに関する追加の機械可読ディレクトリ情報を取得し、その情報をユーザーインターフェイスに表示できます。このプロパティのサポートが必要であり、プリンシパルに代替URIが存在しない場合、値は空です。
<!ELEMENT alternate-URI-set (href*)>
A principal may have many URLs, but there must be one "principal URL" that clients can use to uniquely identify a principal. This protected property contains the URL that MUST be used to identify this principal in an ACL request. Support for this property is REQUIRED.
プリンシパルには多くのURLがある場合がありますが、クライアントがプリンシパルを一意に識別するために使用できる「プリンシパルURL」が1つある必要があります。この保護されたプロパティには、ACLリクエストでこのプリンシパルを識別するために使用する必要があるURLが含まれています。このプロパティのサポートが必要です。
<!ELEMENT principal-URL (href)>
This property of a group principal identifies the principals that are direct members of this group. Since a group may be a member of another group, a group may also have indirect members (i.e., the members of its direct members). A URL in the DAV:group-member-set for a principal MUST be the DAV:principal-URL of that principal.
グループプリンシパルのこのプロパティは、このグループの直接メンバーであるプリンシパルを識別します。グループは別のグループのメンバーである可能性があるため、グループには間接メンバー（つまり、その直接メンバーのメンバー）もいる場合があります。DAVのURL：プリンシパルのグループメンバーセットは、そのプリンシパルのプリンシパルURLでなければなりません。
<!ELEMENT group-member-set (href*)>
This protected property identifies the groups in which the principal is directly a member. Note that a server may allow a group to be a member of another group, in which case the DAV:group-membership of those other groups would need to be queried in order to determine the groups in which the principal is indirectly a member. Support for this property is REQUIRED.
この保護されたプロパティは、校長が直接メンバーであるグループを識別します。サーバーは、グループが別のグループのメンバーになることを許可する場合があることに注意してください。この場合、DAV：他のグループのグループメンバーシップは、プリンシパルが間接的にメンバーであるグループを決定するために質問する必要があります。このプロパティのサポートが必要です。
<!ELEMENT group-membership (href*)>
This specification defines a number of new properties for WebDAV resources. Access control properties may be retrieved just like other WebDAV properties, using the PROPFIND method. Since it is expensive, for many servers, to retrieve access control information, a PROPFIND allprop request (as defined in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the properties defined in this section.
この仕様は、WebDAVリソースの多くの新しいプロパティを定義しています。アクセス制御プロパティは、Propfindメソッドを使用して、他のWebDAVプロパティと同様に取得できます。多くのサーバーの場合、アクセス制御情報を取得するのは高価であるため、Propfind AllProp要求（[RFC2518]のセクション12.14.1で定義されている）は、このセクションで定義されているプロパティの名前と値を返すべきではありません。
Access control properties (especially DAV:acl and DAV:inherited-acl-set) are defined on the resource identified by the Request-URI of a PROPFIND request. A direct consequence is that if the resource is accessible via multiple URI, the value of access control properties is the same across these URI.
アクセス制御プロパティ（特にDAV：ACLおよびDAV：継承ACL-SET）は、Propfind Requestのリクエスト-URIによって識別されたリソースで定義されます。直接的な結果は、複数のURIを介してリソースにアクセスできる場合、アクセス制御プロパティの値はこれらのURI間で同じであることです。
HTTP resources that support the WebDAV Access Control Protocol MUST contain the following properties. Null resources (described in Section 3 of [RFC2518]) MUST NOT contain the following properties.
WebDAVアクセス制御プロトコルをサポートするHTTPリソースには、次のプロパティを含める必要があります。ヌルリソース（[RFC2518]のセクション3で説明）には、次のプロパティが含まれてはなりません。
This property identifies a particular principal as being the "owner" of the resource. Since the owner of a resource often has special access control capabilities (e.g., the owner frequently has permanent DAV:write-acl privilege), clients might display the resource owner in their user interface.
このプロパティは、特定のプリンシパルをリソースの「所有者」であると識別します。リソースの所有者にはしばしば特別なアクセス制御機能があるため（たとえば、所有者は頻繁に永続的なDAV：Write-ACL特権を持っていることがよくあります）、クライアントはユーザーインターフェイスにリソース所有者を表示する場合があります。
Servers MAY implement DAV:owner as protected property and MAY return an empty DAV:owner element as property value in case no owner information is available.
サーバーは、DAV：所有者を保護されたプロパティとして実装し、所有者情報が利用できない場合に備えて、空のDAV：所有者要素をプロパティ値として返すことができます。
<!ELEMENT owner (href?)>
This example shows a client request for the value of the DAV:owner property from a collection resource with URL http://www.example.com/ papers/. The principal making the request is authenticated using Digest authentication. The value of DAV:owner is the URL http:// www.example.com/acl/users/gstein, wrapped in the DAV:href XML element.
この例は、URL http://www.example.com/ Papers/を使用したコレクションリソースのDAV：所有者プロパティのクライアントリクエストを示しています。リクエストを作成する元本は、ダイジェスト認証を使用して認証されます。DAVの値：所有者はurl http：// www.example.com/acl/users/gstein、dav：href xml要素にラップされています。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="jim",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:owner/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:owner>
<D:href>http://www.example.com/acl/users/gstein</D:href>
</D:owner>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The following example shows a client request to modify the value of the DAV:owner property on the resource with URL <http:// www.example.com/papers>. Since DAV:owner is a protected property on this particular server, it responds with a 207 (Multi-Status) response that contains a 403 (Forbidden) status code for the act of setting DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status code information, Section 11 of [RFC2518] describes the Multi-Status response and Sections 1.6 and 3.12 of [RFC3253] describe additional error marshaling for PROPPATCH attempts on protected properties.
次の例は、url <http：// www.example.com/papers>を使用して、DAVの値を変更するクライアントリクエスト：リソース上の所有者プロパティを示しています。DAV：所有者はこの特定のサーバーの保護されたプロパティであるため、DAV：所有者を設定する行為の403（禁止）ステータスコードを含む207（マルチステータス）応答で応答します。[RFC2518]のセクション8.2.1は、プロップパッチステータスコード情報を説明し、[RFC2518]のセクション11では、マルチステータス応答と[RFC3253]のセクション1.6および3.12について説明します。
>> Request <<
PROPPATCH /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="jim",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<D:owner>
<D:href>http://www.example.com/acl/users/jim</D:href>
</D:owner>
</D:prop>
</D:set>
</D:propertyupdate>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop><D:owner/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription>
<D:error><D:cannot-modify-protected-property/></D:error>
Failure to set protected property (DAV:owner)
</D:responsedescription>
</D:propstat>
</D:response>
</D:multistatus>
This property identifies a particular principal as being the "group" of the resource. This property is commonly found on repositories that implement the Unix privileges model.
このプロパティは、特定のプリンシパルをリソースの「グループ」であると識別します。このプロパティは、UNIX特権モデルを実装するリポジトリによく見られます。
Servers MAY implement DAV:group as protected property and MAY return an empty DAV:group element as property value in case no group information is available.
サーバーは、DAV：Groupを保護されたプロパティとして実装でき、グループ情報が利用できない場合に備えて、空のDAV：グループ要素をプロパティ値として返すことができます。
<!ELEMENT group (href?)>
This is a protected property that identifies the privileges defined for the resource.
これは、リソースに定義されている特権を識別する保護されたプロパティです。
<!ELEMENT supported-privilege-set (supported-privilege*)>
Each privilege appears as an XML element, where aggregate privileges list as sub-elements all of the privileges that they aggregate.
各特権はXML要素として表示されます。この要素では、特権が集約されている特権が集約されているすべての特権をサブエレメントとしてリストします。
<!ELEMENT supported-privilege
(privilege, abstract?, description, supported-privilege*)>
<!ELEMENT privilege ANY>
An abstract privilege MUST NOT be used in an ACE for that resource. Servers MUST fail an attempt to set an abstract privilege.
抽象的特権は、そのリソースのACEで使用してはなりません。サーバーは、抽象的特権を設定する試みに失敗する必要があります。
<!ELEMENT abstract EMPTY>
A description is a human-readable description of what this privilege controls access to. Servers MUST indicate the human language of the description using the xml:lang attribute and SHOULD consider the HTTP Accept-Language request header when selecting one of multiple available languages.
説明とは、この特権がアクセスを制御するものの人間が読みやすい説明です。サーバーは、XML：Lang属性を使用して説明の人間言語を示す必要があり、複数の利用可能な言語のいずれかを選択するときにHTTP Accept-Language Requestヘッダーを考慮する必要があります。
<!ELEMENT description #PCDATA>
It is envisioned that a WebDAV ACL-aware administrative client would list the supported privileges in a dialog box, and allow the user to choose non-abstract privileges to apply in an ACE. The privileges tree is useful programmatically to map well-known privileges (defined by WebDAV or other standards groups) into privileges that are supported by any particular server implementation. The privilege tree also serves to hide complexity in implementations allowing large number of privileges to be defined by displaying aggregates to the user.
WebDAV ACLに認識された管理クライアントが、ダイアログボックスにサポートされている特権をリストし、ユーザーがACEに適用するために非抽象的特権を選択できるようにすることを想定しています。特権ツリーは、特定のサーバーの実装によってサポートされている特権に、よく知られている特権（WebDAVまたはその他の標準グループによって定義）をマッピングするためにプログラム的に有用です。特権ツリーは、ユーザーに集合体を表示することで多数の特権を定義できるようにするために、実装の複雑さを隠すのにも役立ちます。
This example shows a client request for the DAV:supported-privilege-set property on the resource http://www.example.com/papers/. The value of the DAV:supported-privilege-set property is a tree of supported privileges (using "[XML Namespace , localname]" to identify each privilege):
この例は、リソースhttp://www.example.com/papers/でDAV：サポートされているPrivilege-Setプロパティのクライアントリクエストを示しています。DAVの価値：サポートされているPrivilege-Setプロパティは、サポートされている特権のツリーです（各特権を識別するための「[XML Namespace、LocalName]を使用））：
[DAV:, all] (aggregate, abstract)
|
+-- [DAV:, read] (aggregate)
|
+-- [DAV:, read-acl] (abstract)
+-- [DAV:, read-current-user-privilege-set] (abstract)
|
+-- [DAV:, write] (aggregate)
|
+-- [DAV:, write-acl] (abstract)
+-- [DAV:, write-properties]
+-- [DAV:, write-content]
|
+-- [DAV:, unlock]
This privilege tree is not normative (except that it reflects the normative aggregation rules given in Section 3.12), and many possible privilege trees are possible.
この特権ツリーは規範的ではありません（セクション3.12に記載されている規範的集約ルールを反映していることを除いて）、多くの可能な特権ツリーが可能です。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="gclemm",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:supported-privilege-set/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
HTTP/1.1 207マルチステータス
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:supported-privilege-set>
<D:supported-privilege>
<D:privilege><D:all/></D:privilege>
<D:abstract/>
<D:description xml:lang="en">
Any operation
</D:description>
<D:supported-privilege>
<D:privilege><D:read/></D:privilege>
<D:description xml:lang="en">
Read any object
</D:description>
<D:supported-privilege>
<D:privilege><D:read-acl/></D:privilege>
<D:abstract/>
<D:description xml:lang="en">Read ACL</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege>
<D:read-current-user-privilege-set/>
</D:privilege>
<D:abstract/>
<D:description xml:lang="en">
Read current user privilege set property
</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write/></D:privilege>
<D:description xml:lang="en">
Write any object
</D:description>
<D:supported-privilege>
<D:privilege><D:write-acl/></D:privilege>
<D:description xml:lang="en">
Write ACL
</D:description>
<D:abstract/>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write-properties/></D:privilege>
<D:description xml:lang="en">
Write properties
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write-content/></D:privilege>
<D:description xml:lang="en">
Write resource content
</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:unlock/></D:privilege>
<D:description xml:lang="en">
Unlock resource
</D:description>
</D:supported-privilege>
</D:supported-privilege>
</D:supported-privilege-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
DAV:current-user-privilege-set is a protected property containing the exact set of privileges (as computed by the server) granted to the currently authenticated HTTP user. Aggregate privileges and their contained privileges are listed. A user-agent can use the value of this property to adjust its user interface to make actions inaccessible (e.g., by graying out a menu item or button) for which the current principal does not have permission. This property is also useful for determining what operations the current principal can perform, without having to actually execute an operation.
DAV：Current-User-Privilege-Setは、現在認証されているHTTPユーザーに付与されている正確な特権セット（サーバーによって計算される）を含む保護されたプロパティです。集約特権とその封じ込められた特権がリストされています。ユーザーエージェントは、このプロパティの値を使用して、ユーザーインターフェイスを調整して、現在のプリンシパルに許可を持たないアクション（たとえば、メニュー項目やボタンをグレーアウトすることにより）を作成できます（たとえば、メニュー項目やボタンをグレーアウトすることにより）。このプロパティは、実際に操作を実行することなく、現在のプリンシパルが実行できる操作を決定するのにも役立ちます。
<!ELEMENT current-user-privilege-set (privilege*)> <!ELEMENT privilege ANY> If the current user is granted a specific privilege, that privilege must belong to the set of privileges that may be set on this resource. Therefore, each element in the DAV:current-user-privilege-set property MUST identify a non-abstract privilege from the DAV:supported-privilege-set property.
<！要素Current-User-Privilege-Set（特権*）> <！要素特権任意の>したがって、DAV：Current-User-Privilege-Setプロパティの各要素は、DAV：サポートされているPrivilege-Setプロパティからの非抽象的特権を特定する必要があります。
Continuing the example from Section 5.3.1, this example shows a client requesting the DAV:current-user-privilege-set property from the resource with URL http://www.example.com/papers/. The username of the principal making the request is "khare", and Digest authentication is used in the request. The principal with username "khare" has been granted the DAV:read privilege. Since the DAV:read privilege contains the DAV:read-acl and DAV:read-current-user-privilege-set privileges (see Section 5.3.1), the principal with username "khare" can read the ACL property, and the DAV:current-user-privilege-set property. However, the DAV:all, DAV:read-acl, DAV:write-acl and DAV:read-current-user-privilege-set privileges are not listed in the value of DAV:current-user-privilege-set, since (for this example) they are abstract privileges. DAV:write is not listed since the principal with username "khare" is not listed in an ACE granting that principal write permission.
セクション5.3.1の例を継続して、この例は、URL http://www.example.com/papers/を使用して、リソースからDAV：Current-User-Privilege-Setプロパティを要求するクライアントを示しています。リクエストを作成する校長のユーザー名は「Khare」であり、Digest認証はリクエストで使用されます。ユーザー名「Khare」を持つ校長は、DAV：Read Privilegeに付与されています。DAV：読み取り特権にはDAV：Read-ACLとDAV：Read-Current-User-Privilege-Setの特権（セクション5.3.1を参照）が含まれているため、ユーザー名「Khare」を持つプリンシパルはACLプロパティを読み、DAVはDAVを読み取ることができます。：Current-User-Privilege-Setプロパティ。ただし、All：All、Dav：Read-Acl、Dav：Write-AclおよびDav：Read-Current-User-Privilege-Set特権は、DAVの価値に記載されていません。この例では、それらは抽象的な特権です。DAV：ユーザー名「Khare」を備えたプリンシパルがACEにリストされていないため、書き込みはリストされていません。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="khare",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:current-user-privilege-set/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:current-user-privilege-set>
<D:privilege><D:read/></D:privilege>
</D:current-user-privilege-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This is a protected property that specifies the list of access control entries (ACEs), which define what principals are to get what privileges for this resource.
これは、アクセス制御エントリ（ACES）のリストを指定する保護されたプロパティであり、このリソースの特権を取得するためのプリンシパルが何であるかを定義します。
<!ELEMENT acl (ace*) >
Each DAV:ace element specifies the set of privileges to be either granted or denied to a single principal. If the DAV:acl property is empty, no principal is granted any privilege.
各DAV：ACE要素は、1つの校長に付与または拒否される特権のセットを指定します。DAV：ACLプロパティが空の場合、特権は認められません。
<!ELEMENT ace ((principal | invert), (grant|deny), protected?,
inherited?)>
The DAV:principal element identifies the principal to which this ACE applies.
DAV：主要な要素は、このエースが適用されるプリンシパルを識別します。
<!ELEMENT principal (href | all | authenticated | unauthenticated | property | self)>
<！要素プリンシパル（HREF | ALL |認証|非認証|プロパティ|セルフ）>
The current user matches DAV:href only if that user is authenticated as being (or being a member of) the principal identified by the URL contained by that DAV:href.
現在のユーザーは、そのユーザーがそのdav：hrefに含まれるURLによって識別される校長として認証されている（またはメンバーである）として認証されている場合にのみ、DAV：HREFと一致します。
The current user always matches DAV:all.
現在のユーザーは常にDAV：すべてを一致させます。
<!ELEMENT all EMPTY>
The current user matches DAV:authenticated only if authenticated.
現在のユーザーはDAVと一致します：認証された場合にのみ認証されます。
<!ELEMENT authenticated EMPTY>
The current user matches DAV:unauthenticated only if not authenticated.
現在のユーザーはDAVと一致します：認証されていない場合にのみ認証されていません。
<!ELEMENT unauthenticated EMPTY>
DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. For a given request, the user matches either DAV:authenticated, or DAV:unauthenticated, but not both (that is, DAV:authenticated and DAV:unauthenticated are disjoint sets).
DAV：すべてがDAVの連合です：認証された、DAV：Unauthenticed。特定のリクエストの場合、ユーザーはDAV：AuthenticatedまたはDAV：UnAuthenticatedのいずれかを一致させますが、両方ではありません（つまり、Dav：AuthenticatedおよびDav：Unauthenticatedは否認セットです）。
The current user matches a DAV:property principal in a DAV:acl property of a resource only if the value of the identified property of that resource contains at most one DAV:href XML element, the URI value of DAV:href identifies a principal, and the current user is authenticated as being (or being a member of) that principal. For example, if the DAV:property element contained <DAV:owner/>, the current user would match the DAV:property principal only if the current user is authenticated as matching the principal identified by the DAV:owner property of the resource.
現在のユーザーは、そのリソースの識別されたプロパティの値が最大1つのDAVである場合にのみ、DAV：DAVのプロパティプリンシパル：ACLリソースのプロパティと一致します。そして、現在のユーザーは、その校長である（またはメンバーである）として認証されています。たとえば、DAV：プロパティ要素に<dav：所有者/>が含まれている場合、現在のユーザーは、現在のユーザーがdav：dav：所有者のリソースの所有者プロパティによって識別されるプリンシパルと一致するものとして認証されている場合にのみ、DAV：プロパティプリンシパルと一致します。
<!ELEMENT property ANY>
The current user matches DAV:self in a DAV:acl property of the resource only if that resource is a principal and that principal matches the current user or, if the principal is a group, a member of that group matches the current user.
現在のユーザーは、そのリソースがプリンシパルであり、そのプリンシパルが現在のユーザーと一致する場合、またはプリンシパルがグループである場合にのみ、DAV：self in a resourceのACLプロパティと一致します。
<!ELEMENT self EMPTY>
Some servers may support ACEs applying to those users NOT matching the current principal, e.g., all users not in a particular group. This can be done by wrapping the DAV:principal element with DAV:invert.
一部のサーバーは、現在のプリンシパルと一致していないユーザー、たとえば特定のグループにはないすべてのユーザーに適用するACEをサポートする場合があります。これは、DAV：DAV：Invertを使用してDAV：主要な要素をラッピングすることで実行できます。
<!ELEMENT invert principal>
Each DAV:grant or DAV:deny element specifies the set of privileges to be either granted or denied to the specified principal. A DAV:grant or DAV:deny element of the DAV:acl of a resource MUST only contain non-abstract elements specified in the DAV:supported-privilege-set of that resource.
各DAV：GrantまたはDAV：DENY要素は、指定されたプリンシパルに付与または拒否される特権のセットを指定します。A DAV：GrantまたはDAV：DAVの拒否要素：リソースのACLには、DAVで指定されている非アブストラクト要素のみを含む必要があります。
<!ELEMENT grant (privilege+)>
<!ELEMENT deny (privilege+)>
<!ELEMENT privilege ANY>
A server indicates an ACE is protected by including the DAV:protected element in the ACE. If the ACL of a resource contains an ACE with a DAV:protected element, an attempt to remove that ACE from the ACL MUST fail.
サーバーは、ACEがACEにDAV：保護された要素を含めることにより保護されていることを示します。リソースのACLにACLがDAV：保護された要素を含むACEが含まれている場合、ACLからそのACEを削除しようとする試みは失敗する必要があります。
<!ELEMENT protected EMPTY>
The presence of a DAV:inherited element indicates that this ACE is inherited from another resource that is identified by the URL contained in a DAV:href element. An inherited ACE cannot be modified directly, but instead the ACL on the resource from which it is inherited must be modified.
DAV：継承された要素の存在は、このエースがDAV：HREF要素に含まれるURLによって識別される別のリソースから継承されていることを示します。継承されたエースは直接変更することはできませんが、代わりに継承されるリソース上のACLを変更する必要があります。
Note that ACE inheritance is not the same as ACL initialization. ACL initialization defines the ACL that a newly created resource will use (if not specified). ACE inheritance refers to an ACE that is logically shared - where an update to the resource containing an ACE will affect the ACE of each resource that inherits that ACE. The method by which ACLs are initialized or by which ACEs are inherited is not defined by this document.
ACE継承はACL初期化と同じではないことに注意してください。ACL初期化は、新しく作成されたリソースが使用するACLを定義します（指定されていない場合）。ACE継承とは、論理的に共有されるACEを指します。エースを含むリソースの更新が、そのエースを継承する各リソースのエースに影響を与えます。ACLが初期化される方法、またはACEが継承される方法は、このドキュメントで定義されていません。
<!ELEMENT inherited (href)>
Continuing the example from Sections 5.3.1 and 5.4.1, this example shows a client requesting the DAV:acl property from the resource with URL http://www.example.com/papers/. There are two ACEs defined in this ACL: ACE #1: The group identified by URL http://www.example.com/acl/ groups/maintainers (the group of site maintainers) is granted DAV:write privilege. Since (for this example) DAV:write contains the DAV:write-acl privilege (see Section 5.3.1), this means the "maintainers" group can also modify the access control list.
セクション5.3.1および5.4.1の例を継続して、この例は、URL http://www.example.com/papers/を使用してリソースからDAV：ACLプロパティを要求するクライアントを示しています。このACLには2つのACEが定義されています。ACE＃1：URL http://www.example.com/acl/グループ/メンテナー（サイトメンテナーのグループ）によって識別されたグループには、Dav：Write Privilegeが付与されます。（この例では）dav：writeにはdav：write-acl特権（セクション5.3.1を参照）が含まれているため、これは「メンテナー」グループがアクセス制御リストを変更できることを意味します。
ACE #2: All principals (DAV:all) are granted the DAV:read privilege. Since (for this example) DAV:read contains DAV:read-acl and DAV:read-current-user-privilege-set, this means all users (including all members of the "maintainers" group) can read the DAV:acl property and the DAV:current-user-privilege-set property.
エース＃2：すべてのプリンシパル（DAV：すべて）にDAV：Read Privilegeが付与されます。（この例では）dav：read contains dav：read-acl and dav：read-current-user-privilege-setは、すべてのユーザー（「メンテナー」グループのすべてのメンバーを含む）がDAV：ACLプロパティを読むことができることを意味します。およびThe Dav：Current-User-Privilege-Setプロパティ。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="masinter",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:acl/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:acl>
<D:ace>
<D:principal>
<D:href
>http://www.example.com/acl/groups/maintainers</D:href>
</D:principal>
<D:grant>
<D:privilege><D:write/></D:privilege>
</D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:all/>
</D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
</D:grant>
</D:ace>
</D:acl>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This protected property defines the types of ACLs supported by this server, to avoid clients needlessly getting errors. When a client tries to set an ACL via the ACL method, the server may reject the attempt to set the ACL as specified. The following properties indicate the restrictions the client must observe before setting an ACL:
この保護されたプロパティは、クライアントが不必要にエラーを取得しないように、このサーバーでサポートされているACLのタイプを定義します。クライアントがACLメソッドを介してACLを設定しようとすると、サーバーは指定どおりにACLを設定する試みを拒否する場合があります。次のプロパティは、ACLを設定する前にクライアントが観察しなければならない制限を示しています。
<grant-only> Deny ACEs are not supported
<grant-only>拒否エースはサポートされていません
<no-invert> Inverted ACEs are not supported
<no-invert>逆エースはサポートされていません
<deny-before-grant> All deny ACEs must occur before any grant ACEs
<Deny-be-before-grant>すべての拒否エースは、助成金エースの前に発生する必要があります
<required-principal> Indicates which principals are required to be present
<必須プリンシパル>どのプリンシパルが存在する必要があるかを示します
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
<！要素ACL-RESTRICTIONS（Grant-Only？、No Invert？、deny-be-be-grant？、必要なprincipal？）>
This element indicates that ACEs with deny clauses are not allowed.
この要素は、拒否条項を備えたエースが許可されていないことを示しています。
<!ELEMENT grant-only EMPTY>
This element indicates that ACEs with the <invert> element are not allowed.
この要素は、<nervert>要素を持つエースが許可されていないことを示しています。
<!ELEMENT no-invert EMPTY>
This element indicates that all deny ACEs must precede all grant ACEs.
この要素は、すべての拒否エースがすべての助成金エースに先行する必要があることを示しています。
<!ELEMENT deny-before-grant EMPTY>
The required principal elements identify which principals must have an ACE defined in the ACL.
必要な主要な要素は、どのプリンシパルがACLで定義されている必要があるかを識別します。
<!ELEMENT required-principal
(all? | authenticated? | unauthenticated? | self? | href* |
property*)>
For example, the following element requires that the ACL contain a
たとえば、次の要素では、ACLに
DAV:owner property ACE:
DAV：所有者プロパティエース：
<D:required-principal xmlns:D="DAV:">
<D:property><D:owner/></D:property>
</D:required-principal>
In this example, the client requests the value of the DAV:acl-restrictions property. Digest authentication provides credentials for the principal operating the client.
この例では、クライアントはDAV：ACL-Restrictionsプロパティの値を要求します。Digest Authenticationは、クライアントを操作する元本に資格情報を提供します。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="srcarter",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:acl-restrictions/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:acl-restrictions>
<D:grant-only/>
<D:required-principal>
<D:all/>
</D:required-principal>
</D:acl-restrictions>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This protected property contains a set of URLs that identify other resources that also control the access to this resource. To have a privilege on a resource, not only must the ACL on that resource (specified in the DAV:acl property of that resource) grant the privilege, but so must the ACL of each resource identified in the DAV:inherited-acl-set property of that resource. Effectively, the privileges granted by the current ACL are ANDed with the privileges granted by each inherited ACL.
この保護されたプロパティには、このリソースへのアクセスも制御する他のリソースを識別するURLのセットが含まれています。リソースに特権を持つためには、そのリソースのACL（そのリソースのACLプロパティで指定）のACLが特権を付与する必要がありますが、DAVで識別された各リソースのACL：継承ACL-SETである必要があります。そのリソースのプロパティ。効果的に、現在のACLによって付与された特権は、各継承されたACLによって付与された特権とともにANDEDです。
<!ELEMENT inherited-acl-set (href*)>
This protected property of a resource contains a set of URLs that identify the root collections that contain the principals that are available on the server that implements this resource. A WebDAV Access Control Protocol user agent could use the contents of DAV:principal-collection-set to retrieve the DAV:displayname property (specified in Section 13.2 of [RFC2518]) of all principals on that server, thereby yielding human-readable names for each principal that could be displayed in a user interface.
このリソースの保護されたプロパティには、このリソースを実装するサーバーで利用可能なプリンシパルを含むルートコレクションを識別するURLのセットが含まれています。WebDAVアクセス制御プロトコルユーザーエージェントは、DAV：プリンシパルコレクションセットのコンテンツを使用して、そのサーバーのすべてのプリンシパルのDAV：DisplayNameプロパティ（[RFC2518]のセクション13.2で指定）を取得することができます。ユーザーインターフェイスに表示できる各プリンシパル。
<!ELEMENT principal-collection-set (href*)>
Since different servers can control different parts of the URL namespace, different resources on the same host MAY have different DAV:principal-collection-set values. The collections specified in the DAV:principal-collection-set MAY be located on different hosts from the resource. The URLs in DAV:principal-collection-set SHOULD be http or https scheme URLs. For security and scalability reasons, a server MAY report only a subset of the entire set of known principal collections, and therefore clients should not assume they have retrieved an exhaustive listing. Additionally, a server MAY elect to report none of the principal collections it knows about, in which case the property value would be empty.
異なるサーバーはURLネームスペースの異なる部分を制御できるため、同じホストの異なるリソースが異なるDAVであるプリンシパルコレクションセット値を持つ場合があります。DAV：プリンシパルコレクションセットで指定されたコレクションは、リソースのさまざまなホストに配置できます。DAVのURL：プリンシパルコレクションセットは、HTTPまたはHTTPSスキームURLである必要があります。セキュリティとスケーラビリティの理由により、サーバーは既知の主要なコレクションのセット全体のサブセットのみを報告することができるため、クライアントは徹底的なリストを取得したと仮定してはなりません。さらに、サーバーは、それが知っている主要なコレクションのいずれも報告しないことを選択する場合があります。その場合、プロパティ値は空になります。
The value of DAV:principal-collection-set gives the scope of the DAV:principal-property-search REPORT (defined in Section 9.4). Clients use the DAV:principal-property-search REPORT to populate their user interface with a list of principals. Therefore, servers that limit a client's ability to obtain principal information will interfere with the client's ability to manipulate access control lists, due to the difficulty of getting the URL of a principal for use in an ACE.
DAVの値：プリンシパルコレクションセットは、DAV：プリンシパルプロパティ検索レポートの範囲を与えます（セクション9.4で定義）。クライアントは、DAV：プリンシパルプロパティサーチレポートを使用して、ユーザーインターフェイスにプリンシパルのリストに登録されています。したがって、プリンシパル情報を取得するクライアントの能力を制限するサーバーは、ACEで使用するプリンシパルのURLを取得するのが難しいため、クライアントのアクセス制御リストを操作する能力を妨げます。
In this example, the client requests the value of the DAV:principal-collection-set property on the collection resource identified by URL http://www.example.com/papers/. The property contains the two URLs, http://www.example.com/acl/users/ and http:// www.example.com/acl/groups/, both wrapped in DAV:href XML elements. Digest authentication provides credentials for the principal operating the client.
この例では、クライアントは、url http://www.example.com/papers/で識別されたコレクションリソースのDAV：プリンシパルコレクションセットプロパティの値を要求します。プロパティには、2つのURL、http：//www.example.com/acl/acl/users/とhttp：// www.example.com/acl/groups/が含まれています。Digest Authenticationは、クライアントを操作する元本に資格情報を提供します。
The client might reasonably follow this request with two separate PROPFIND requests to retrieve the DAV:displayname property of the members of the two collections (/acl/users and /acl/groups). This information could be used when displaying a user interface for creating access control entries.
クライアントは、2つのコレクション（/ACL/ユーザーおよび/ACL/グループ）のメンバーのDAV：DisplayNameプロパティを取得するために、2つの個別のPropfindリクエストでこのリクエストに合理的に従うことができます。この情報は、アクセス制御エントリを作成するためのユーザーインターフェイスを表示するときに使用できます。
>> Request <<
PROPFIND /papers/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="yarong",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:principal-collection-set/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/papers/</D:href>
<D:propstat>
<D:prop>
<D:principal-collection-set>
<D:href>http://www.example.com/acl/users/</D:href>
<D:href>http://www.example.com/acl/groups/</D:href>
</D:principal-collection-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The following example shows how access control information can be retrieved by using the PROPFIND method to fetch the values of the DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-set, and DAV:acl properties.
次の例は、Propfindメソッドを使用してDAVの値を取得することにより、アクセス制御情報を取得する方法を示しています。
>> Request <<
PROPFIND /top/container/ HTTP/1.1
Host: www.example.com
Content-type: text/xml; charset="utf-8"
Content-Length: xxx
Depth: 0
Authorization: Digest username="ejw",
realm="users@example.com", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:owner/>
<D:supported-privilege-set/>
<D:current-user-privilege-set/>
<D:acl/>
</D:prop>
</D:propfind>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:A="http://www.example.com/acl/">
<D:response>
<D:href>http://www.example.com/top/container/</D:href>
<D:propstat>
<D:prop>
<D:owner>
<D:href>http://www.example.com/users/gclemm</D:href>
</D:owner>
<D:supported-privilege-set>
<D:supported-privilege>
<D:privilege><D:all/></D:privilege>
<D:abstract/>
<D:description xml:lang="en">
Any operation
</D:description>
<D:supported-privilege>
<D:privilege><D:read/></D:privilege>
<D:description xml:lang="en">
Read any object
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write/></D:privilege>
<D:abstract/>
<D:description xml:lang="en">
Write any object
</D:description>
<D:supported-privilege>
<D:privilege><A:create/></D:privilege>
<D:description xml:lang="en">
Create an object
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><A:update/></D:privilege>
<D:description xml:lang="en">
Update an object
</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><A:delete/></D:privilege>
<D:description xml:lang="en">
Delete an object
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:read-acl/></D:privilege>
<D:description xml:lang="en">
Read the ACL
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write-acl/></D:privilege>
<D:description xml:lang="en">
Write the ACL
</D:description>
</D:supported-privilege>
</D:supported-privilege>
</D:supported-privilege-set>
<D:current-user-privilege-set> <D:privilege><D:read/></D:privilege> <D:privilege><D:read-acl/></D:privilege> </D:current-user-privilege-set> <D:acl> <D:ace> <D:principal> <D:href>http://www.example.com/users/esedlar</D:href> </D:principal> <D:grant> <D:privilege><D:read/></D:privilege> <D:privilege><D:write/></D:privilege> <D:privilege><D:read-acl/></D:privilege> </D:grant> </D:ace> <D:ace> <D:principal> <D:href>http://www.example.com/groups/mrktng</D:href> </D:principal> <D:deny> <D:privilege><D:read/></D:privilege> </D:deny> </D:ace> <D:ace> <D:principal> <D:property><D:owner/></D:property> </D:principal> <D:grant> <D:privilege><D:read-acl/></D:privilege> <D:privilege><D:write-acl/></D:privilege> </D:grant> </D:ace> <D:ace> <D:principal><D:all/></D:principal> <D:grant> <D:privilege><D:read/></D:privilege> </D:grant> <D:inherited> <D:href>http://www.example.com/top</D:href> </D:inherited> </D:ace> </D:acl> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> The value of the DAV:owner property is a single DAV:href XML element containing the URL of the principal that owns this resource.
<d：current-user-privilege-set> <d：privilege> <d：read/> </d：privilege> <d：privilege> <d：read-acl/> </d：特権> </d：current-user-privilege-set> <d：acl> <d：ace> <d：spinital> <d：href> http://www.example.com/users/esedlar </d：href> </D：プリンシパル> <D：Grant> <D：特権> <D：Read/> </d：Privilege> <D：Privilege> <D：write/> </d：privilege> <d：privilege> <d：read-acl/>> </d：特権> </d：grant> </d：ace> <d：ace> <d：spinital> <d：href> http://www.example.com/groups/mrktng </d：href> </d：プリンシパル> <D：deny> <d：privilege> <d：read/> </d：privilege> </d：deny> </d：ace> <d：ACE> <D：校長> <D：プロパティ> <D：所有者/> </d：プロパティ> </d：プリンシパル> <D：grant> <d：privilege> <d：read-acl/> </D：特権> <D：Privilege> <D：write-acl/> </d：privilege> </d：grant> </d：ace> <d：ace> <d：プリンシパル> <D：すべて/> </d：プリンシパル> <d：grant> <d：privilege> <d：read/> </d：privilege> </d：grant> <d：継承> <d：href> http：//www.example.com/top </d：href> </d：継承> </d：ace> </d：acl> </d：prop> <d：status> http/1.1 200 ok </d：status> </d：propstat> </d：response> </d：multistatus> davの値：所有者プロパティは、このリソースを所有するプリンシパルのURLを含む単一のDAV：HREF XML要素です。
The value of the DAV:supported-privilege-set property is a tree of supported privileges (using "[XML Namespace , localname]" to identify each privilege):
DAVの価値：サポートされているPrivilege-Setプロパティは、サポートされている特権のツリーです（各特権を識別するための「[XML Namespace、LocalName]を使用））：
[DAV:, all] (aggregate, abstract)
|
+-- [DAV:, read]
+-- [DAV:, write] (aggregate, abstract)
|
+-- [http://www.example.com/acl, create]
+-- [http://www.example.com/acl, update]
+-- [http://www.example.com/acl, delete]
+-- [DAV:, read-acl]
+-- [DAV:, write-acl]
The DAV:current-user-privilege-set property contains two privileges, DAV:read, and DAV:read-acl. This indicates that the current authenticated user only has the ability to read the resource, and read the DAV:acl property on the resource. The DAV:acl property contains a set of four ACEs:
DAV：Current-User-Privilege-Setプロパティには、Dav：read、dav：read-aclの2つの特権が含まれています。これは、現在の認証されているユーザーがリソースを読み取り、DAV：ACLプロパティをリソース上の読み取り機能を持っていることを示しています。DAV：ACLプロパティには、4つのエースのセットが含まれています。
ACE #1: The principal identified by the URL http://www.example.com/ users/esedlar is granted the DAV:read, DAV:write, and DAV:read-acl privileges.
ACE＃1：URL http://www.example.com/ユーザー/esedlarによって識別されたプリンシパルは、Dav：read、dav：write、and dav：read-acl特権に付与されます。
ACE #2: The principals identified by the URL http://www.example.com/ groups/mrktng are denied the DAV:read privilege. In this example, the principal URL identifies a group.
ACE＃2：URL http://www.example.com/グループ/Mrktngによって識別されたプリンシパルは、DAV：読み取り特権を拒否されます。この例では、主要なURLがグループを識別します。
ACE #3: In this ACE, the principal is a property principal, specifically the DAV:owner property. When evaluating this ACE, the value of the DAV:owner property is retrieved, and is examined to see if it contains a DAV:href XML element. If so, the URL within the DAV:href element is read, and identifies a principal. In this ACE, the owner is granted DAV:read-acl, and DAV:write-acl privileges.
エース＃3：このエースでは、校長は不動産の校長、特にDAV：所有者のプロパティです。このエースを評価するとき、DAV：所有者プロパティの値が取得され、DAV：HREF XML要素が含まれているかどうかを確認するために調べられます。その場合、DAV：HREF要素内のURLが読み取り、プリンシパルを識別します。このエースでは、所有者にDav：read-acl、dav：write-acl特権が付与されます。
ACE #4: This ACE grants the DAV:all principal (all users) the DAV:read privilege. This ACE is inherited from the resource http:// www.example.com/top, the parent collection of this resource.
ACE＃4：このエースはDAVを付与します：すべての校長（すべてのユーザー）DAV：読み取り特権を読みます。このエースは、このリソースの親コレクションであるリソースhttp：// www.example.com/topから継承されます。
WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT and in NFSv4 [RFC3530]). An ACL is evaluated to determine whether or not access will be granted for a WebDAV request. ACEs are maintained in a particular order, and are evaluated until all of the permissions required by the current request have been granted, at which point the ACL evaluation is terminated and access is granted. If, during ACL evaluation, a <deny> ACE (matching the current user) is encountered for a privilege which has not yet been granted, the ACL evaluation is terminated and access is denied. Failure to have all required privileges granted results in access being denied.
WebDAV ACLは、Windows NTおよびNFSV4 [RFC3530]でACLSと同様の方法で評価されます。ACLが評価され、WebDAVリクエストに対してアクセスが許可されるかどうかを判断します。ACEは特定の順序で維持され、現在の要求に必要なすべてのアクセス許可が付与されるまで評価され、その時点でACL評価が終了し、アクセスが許可されます。ACL評価中に、A <deny> ACE（現在のユーザーと一致する）がまだ付与されていない特権で遭遇した場合、ACL評価は終了し、アクセスが拒否されます。すべての必要な特権が得られなかった場合、アクセスが拒否された結果が得られます。
Note that the semantics of many other existing ACL systems may be represented via this mechanism, by mixing deny and grant ACEs. For example, consider the standard "rwx" privilege scheme used by UNIX. In this scheme, if the current user is the owner of the file, access is granted if the corresponding privilege bit is set and denied if not set, regardless of the permissions set on the file's group and for the world. An ACL for UNIX permissions of "r--rw-r--" might be constructed like:
他の多くの既存のACLシステムのセマンティクスは、拒否と付与のACEを混合することにより、このメカニズムを介して表現できることに注意してください。たとえば、UNIXが使用する標準の「RWX」特権スキームを検討してください。このスキームでは、現在のユーザーがファイルの所有者である場合、ファイルのグループに設定されていても世界に設定されていても、対応する特権ビットが設定され、設定されていない場合は拒否された場合、アクセスが許可されます。「R - RW-R-」のUNIX許可のACLは、次のように構築される場合があります。
<D:acl>
<D:ace>
<D:principal>
<D:property><D:owner/></D:property>
</D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
</D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:property><D:owner/></D:property>
</D:principal>
<D:deny>
<D:privilege><D:all/></D:privilege>
</D:deny>
</D:ace>
<D:ace>
<D:principal>
<D:property><D:group/></D:property>
</D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
<D:privilege><D:write/></D:privilege>
</D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:property><D:group/></D:property>
</D:principal>
<D:deny>
<D:privilege><D:all/></D:privilege>
</D:deny>
</D:ace>
<D:ace>
<D:principal><D:all></D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
</D:grant>
</D:ace>
</D:acl>
and the <acl-restrictions> would be defined as:
<acl-restrictions>は次のように定義されます。
<D:no-invert/>
<D:required-principal>
<D:all/>
<D:property><D:owner/></D:property>
<D:property><D:group/><D:group/>
</D:required-principal>
Note that the client can still get errors from a UNIX server in spite of obeying the <acl-restrictions>, including <D:allowed-principal> (adding an ACE specifying a principal other than the ones in the ACL above) or <D:ace-conflict> (by trying to reorder the ACEs in the example above), as these particular implementation semantics are too complex to be captured with the simple (but general) declarative restrictions.
クライアントは、<D：Aldocl-Principal>（上記のACL以外のプリンシパルを指定するACEを追加する）または<Dを含む<ACL-RESTRICTIONS>に従うにもかかわらず、UNIXサーバーからエラーを取得できることに注意してください。：Ace Conflict>（上記の例のACEを再注文しようとすることにより）、これらの特定の実装セマンティクスは複雑すぎて、単純な（ただし一般的な）宣言的な制限でキャプチャされることができないためです。
This section defines the impact of access control functionality on existing methods.
このセクションでは、既存の方法に対するアクセス制御機能の影響を定義します。
The WebDAV ACL mechanism requires the usage of HTTP method "preconditions" as described in section 1.6 of RFC3253 for ALL HTTP methods. All HTTP methods have an additional precondition called DAV:need-privileges. If an HTTP method fails due to insufficient privileges, the response body to the "403 Forbidden" error MUST contain the <DAV:error> element, which in turn contains the
WebDAV ACLメカニズムには、すべてのHTTPメソッドのRFC3253のセクション1.6で説明されているように、HTTPメソッド「前処理」の使用が必要です。すべてのHTTPメソッドには、Dav：Need-Privilegesと呼ばれる追加の前提条件があります。特権が不十分なためHTTPメソッドが失敗した場合、「403禁止」エラーに対する応答本体には、<dav：error>要素が含まれている必要があります。
<DAV:need-privileges> element, which contains one or more <DAV:resource> elements indicating which resource had insufficient privileges, and what the lacking privileges were:
<DAV：Need-Privileges>要素には、1つ以上のリソースが特権が不十分であるか、特権が不足しているものを示す1つ以上の<Dav：リソース>要素が含まれています。
<!ELEMENT need-privileges (resource)* >
<!ELEMENT resource ( href , privilege ) >
Since some methods require multiple permissions on multiple resources, this information is needed to resolve any ambiguity. There is no requirement that all privilege violations be reported - for implementation reasons, some servers may only report the first privilege violation. For example:
一部の方法では、複数のリソースで複数の権限が必要なため、この情報はあいまいさを解決するために必要です。すべての特権違反が報告されるという要件はありません - 実装上の理由により、一部のサーバーは最初の特権違反のみを報告することができます。例えば：
>> Request <<
MOVE /a/b/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/c/d
移動/a/b/http/1.1ホスト：www.example.com宛先：http：//www.example.com/c/d
>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<D:error xmlns:D="DAV:">
<D:need-privileges>
<D:resource>
<D:href>/a</D:href>
<D:privilege><D:unbind/></D:privilege>
</D:resource>
<D:resource>
<D:href>/c</D:href>
<D:privilege><D:bind/></D:privilege>
</D:resource>
</D:need-privileges>
</D:error>
If the server supports access control, it MUST return "access-control" as a field in the DAV response header from an OPTIONS request on any resource implemented by that server. A value of "access-control" in the DAV header MUST indicate that the server supports all MUST level requirements and REQUIRED features specified in this document.
サーバーがアクセス制御をサポートする場合、そのサーバーが実装したリソースのオプションリクエストからDAV応答ヘッダーのフィールドとして「アクセス制御」を返す必要があります。DAVヘッダーの「アクセス制御」の値は、サーバーがすべてのレベル要件とこのドキュメントで指定された必要な機能をサポートすることを示している必要があります。
>> Request <<
OPTIONS /foo.html HTTP/1.1 Host: www.example.com Content-Length: 0
options /foo.html http /1.1ホスト：www.example.comコンテンツレングス：0
>> Response <<
HTTP/1.1 200 OK DAV: 1, 2, access-control Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
http/1.1 200 ok dav：1、2、アクセス制御許可：オプション、get、put、propfind、proppatch、acl
In this example, the OPTIONS response indicates that the server supports access control and that /foo.html can have its access control list modified by the ACL method.
この例では、オプションの応答は、サーバーがアクセス制御をサポートし、その /foo.htmlがACLメソッドによってアクセス制御リストを変更できることを示しています。
When a resource is moved from one location to another due to a MOVE request, the non-inherited and non-protected ACEs in the DAV:acl property of the resource MUST NOT be modified, or the MOVE request fails. Handling of inherited and protected ACEs is intentionally undefined to give server implementations flexibility in how they implement ACE inheritance and protection.
移動要求のためにリソースをある場所から別の場所に移動すると、DAV：ACLプロパティの不整合および保護されていないACEが変更されてはならないか、移動要求が失敗する必要はありません。継承および保護されたACEの処理は、サーバーの実装がACEの継承と保護の実装方法に柔軟性を与えるために意図的に定義されていません。
The DAV:acl property on the resource at the destination of a COPY MUST be the same as if the resource was created by an individual resource creation request (e.g., MKCOL, PUT). Clients wishing to preserve the DAV:acl property across a copy need to read the DAV:acl property prior to the COPY, then perform an ACL operation on the new resource at the destination to restore, insofar as this is possible, the original access control list.
DAV：コピーの宛先にあるリソース上のACLプロパティは、個々のリソース作成要求（MKCOL、PUT）によってリソースが作成された場合と同じでなければなりません。コピー全体でDAV：ACLプロパティを維持したいクライアントは、コピーの前にDAV：ACLプロパティを読む必要があります。その後、宛先の新しいリソースでACL操作を実行して、これが可能な限り、元のアクセスコントロールを復元しますリスト。
A lock on a resource ensures that only the lock owner can modify ACEs that are not inherited and not protected (these are the only ACEs that a client can modify with an ACL request). A lock does not protect inherited or protected ACEs, since a client cannot modify them with an ACL request on that resource.
リソースのロックは、ロック所有者のみが継承されておらず保護されていないエースを変更できることを保証します（これらは、クライアントがACL要求で変更できる唯一のACESです）。クライアントは、そのリソースのACL要求でクライアントを変更できないため、継承または保護されたACEを保護しません。
The ACL method modifies the access control list (which can be read via the DAV:acl property) of a resource. Specifically, the ACL method only permits modification to ACEs that are not inherited, and are not protected. An ACL method invocation modifies all non-inherited and non-protected ACEs in a resource's access control list to exactly match the ACEs contained within in the DAV:acl XML element (specified in Section 5.5) of the request body. An ACL request body MUST contain only one DAV:acl XML element. Unless the non-inherited and non-protected ACEs of the DAV:acl property of the resource can be updated to be exactly the value specified in the ACL request, the ACL request MUST fail.
ACLメソッドは、リソースのアクセス制御リスト（DAV：ACLプロパティを介して読み取ることができます）を変更します。具体的には、ACLメソッドは、継承されておらず、保護されていないACEの変更のみを許可します。ACLメソッドの呼び出しは、リクエストボディのDAV：ACL XML要素（セクション5.5で指定）内に含まれるACESに正確に一致するように、リソースのアクセス制御リストのすべての非依存性および非保護ACEを変更します。ACL要求本体には、ACL XML要素が1つだけ含まれている必要があります。ACL要求で正確に指定された値にするために、リソースのACLプロパティの不均一で保護されていないACES：ACLプロパティを更新できない限り、ACL要求は失敗する必要があります。
It is possible that the ACEs visible to the current user in the DAV:acl property may only be a portion of the complete set of ACEs on that resource. If this is the case, an ACL request only modifies the set of ACEs visible to the current user, and does not affect any non-visible ACE.
DAV：ACLプロパティの現在のユーザーに見えるACESが、そのリソース上のACEの完全なセットの一部にのみである可能性があります。この場合、ACLリクエストは現在のユーザーに見えるACEのセットのみを変更し、視界ではないACEには影響しません。
In order to avoid overwriting DAV:acl changes by another client, a client SHOULD acquire a WebDAV lock on the resource before retrieving the DAV:acl property of a resource that it intends on updating.
DAV：ACLの変更を避けるために、別のクライアントによるACLの変更は、クライアントがリソースのWebDavロックを取得する前に、DAV：ACLプロパティを更新することを意図しているリソースのプロパティを取得する必要があります。
Implementation Note: Two common operations are to add or remove an ACE from an existing access control list. To accomplish this, a client uses the PROPFIND method to retrieve the value of the DAV:acl property, then parses the returned access control list to remove all inherited and protected ACEs (these ACEs are tagged with the DAV:inherited and DAV:protected XML elements). In the remaining set of non-inherited, non-protected ACEs, the client can add or remove one or more ACEs before submitting the final ACE set in the request body of the ACL method.
実装注：2つの一般的な操作は、既存のアクセス制御リストからACEを追加または削除することです。これを達成するために、クライアントはPropfindメソッドを使用してDAV：ACLプロパティの値を取得し、返されたアクセス制御リストを解析して、継承されたすべての保護エースを削除します（これらのACEはDAV：継承とDAV：保護されたXMLでタグ付けされます要素）。不均一で保護されていないACEの残りのセットでは、クライアントはACLメソッドのリクエスト本文に最終的なACEセットを送信する前に、1つ以上のACEを追加または削除できます。
An implementation MUST enforce the following constraints on an ACL request. If the constraint is violated, a 403 (Forbidden) or 409 (Conflict) response MUST be returned and the indicated XML element MUST be returned as a child of a top level DAV:error element in an XML response body.
実装は、ACL要求に次の制約を実施する必要があります。制約に違反した場合、403（禁止）または409（競合）応答を返す必要があり、示されたXML要素をトップレベルのDAVの子として返す必要があります：XML応答ボディのエラー要素。
Though these status elements are generally expressed as empty XML elements (and are defined as EMPTY in the DTD), implementations MAY return additional descriptive XML elements as children of the status element. Clients MUST be able to accept children of these status elements. Clients that do not understand the additional XML elements should ignore them.
これらのステータス要素は一般に空のXML要素として表されますが（DTDで空に定義されています）、実装はステータス要素の子供として追加の記述XML要素を返す場合があります。クライアントは、これらのステータス要素の子供を受け入れることができる必要があります。追加のXML要素を理解していないクライアントは、それらを無視する必要があります。
(DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST NOT conflict with each other. This is a catchall error code indicating that an implementation-specific ACL restriction has been violated.
（DAV：no-ace-conflict）：ACL要求で提出されたACESは、相互に競合してはなりません。これは、実装固有のACL制限に違反していることを示すキャッチオールエラーコードです。
(DAV:no-protected-ace-conflict): The ACEs submitted in the ACL request MUST NOT conflict with the protected ACEs on the resource. For example, if the resource has a protected ACE granting DAV:write to a given principal, then it would not be consistent if the ACL request submitted an ACE denying DAV:write to the same principal.
（DAV：保護されていないACE紛争）：ACL要求で提出されたACESは、リソース上の保護されたACEと競合してはなりません。たとえば、リソースに保護されたACEがDAVを付与している場合、特定のプリンシパルに書き込みます。ACLリクエストがDAV：同じプリンシパルに書き込むエースを送信しても一貫しないでしょう。
(DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL request MUST NOT conflict with the inherited ACEs on the resource. For example, if the resource inherits an ACE from its parent collection granting DAV:write to a given principal, then it would not be consistent if the ACL request submitted an ACE denying DAV:write to the same principal. Note that reporting of this error will be implementation-dependent. Implementations MUST either report this error or allow the ACE to be set, and then let normal ACE evaluation rules determine whether the new ACE has any impact on the privileges available to a specific principal.
（dav：no-herited-ace-conflict）：ACL要求で提出されたACESは、リソース上の継承されたACEと競合してはなりません。たとえば、リソースがDAVを付与する親コレクションからACEを継承している場合、特定のプリンシパルに書き込みます。ACL要求がDAV：同じプリンシパルに書き込むエースを提出しても一貫性はありません。このエラーのレポートは実装依存に依存することに注意してください。実装は、このエラーを報告するか、ACEの設定を許可し、通常のACE評価ルールが新しいACEが特定のプリンシパルが利用できる特権に影響を与えるかどうかを判断する必要があります。
(DAV:limited-number-of-aces): The number of ACEs submitted in the ACL request MUST NOT exceed the number of ACEs allowed on that resource. However, ACL-compliant servers MUST support at least one ACE granting privileges to a single principal, and one ACE granting privileges to a group.
（DAV：限られた番号の数）：ACL要求で提出されたACEの数は、そのリソースで許可されているACEの数を超えてはなりません。ただし、ACLに準拠したサーバーは、単一のプリンシパルに特権を付与する少なくとも1つのACEと、グループに特権を付与する1つのACEをサポートする必要があります。
(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all non-inherited grant ACEs.
（dav：拒否前にgrant）：すべての非相続拒否エースは、すべての非he的な助成金エースに先行する必要があります。
(DAV:grant-only): The ACEs submitted in the ACL request MUST NOT include a deny ACE. This precondition applies only when the ACL restrictions of the resource include the DAV:grant-only constraint (defined in Section 5.6.1).
（DAV：Grant-Only）：ACL要求で提出されたACESには、拒否エースを含めてはなりません。この前提条件は、リソースのACL制限にDAV：Grantのみの制約が含まれている場合にのみ適用されます（セクション5.6.1で定義）。
(DAV:no-invert): The ACL request MUST NOT include a DAV:invert element. This precondition applies only when the ACL semantics of the resource includes the DAV:no-invert constraint (defined in Section 5.6.2).
（dav：no-invert）：ACLリクエストには、DAV：反転要素を含めてはなりません。この前提条件は、リソースのACLセマンティクスにDAV：非インバの制約が含まれている場合にのみ適用されます（セクション5.6.2で定義）。
(DAV:no-abstract): The ACL request MUST NOT attempt to grant or deny an abstract privilege (see Section 5.3).
（dav：abstractなし）：ACL要求は、抽象的特権を許可または拒否しようとしてはなりません（セクション5.3を参照）。
(DAV:not-supported-privilege): The ACEs submitted in the ACL request MUST be supported by the resource.
（DAV：サポートされていないPrivilege）：ACL要求で提出されたACESは、リソースによってサポートされている必要があります。
(DAV:missing-required-principal): The result of the ACL request MUST have at least one ACE for each principal identified in a DAV:required-principal XML element in the ACL semantics of that resource (see Section 5.5).
（DAV：不足しているPrincipal）：ACL要求の結果は、そのリソースのACLセマンティクスで、DAV：必須のXML要素で識別された各プリンシパルに対して少なくとも1つのACEを持たなければなりません（セクション5.5を参照）。
(DAV:recognized-principal): Every principal URL in the ACL request MUST identify a principal resource.
（DAV：認識されているPrincipal）：ACL要求のすべての主要なURLは、主要なリソースを特定する必要があります。
(DAV:allowed-principal): The principals specified in the ACEs submitted in the ACL request MUST be allowed as principals for the resource. For example, a server where only authenticated principals can access resources would not allow the DAV:all or DAV:unauthenticated principals to be used in an ACE, since these would allow unauthenticated access to resources.
（DAV：許可されているプリンシパル）：ACL要求で提出されたACESで指定されたプリンシパルは、リソースのプリンシパルとして許可されなければなりません。たとえば、認証されたプリンシパルのみがリソースにアクセスできるサーバーでは、DAV：AllまたはDAV：Unauthenticed PrincipalsをACEで使用できません。
In the following example, user "fielding", authenticated by information in the Authorization header, grants the principal identified by the URL http://www.example.com/users/esedlar (i.e., the user "esedlar") read and write privileges, grants the owner of the resource read-acl and write-acl privileges, and grants everyone read privileges.
次の例では、承認ヘッダーの情報によって認証されたユーザーの「フィールド」は、URL http://www.example.com/users/esedlar（すなわち、ユーザー「esedlar」）で識別されたプリンシパルを譲歩し、書き込みと書き込み特権は、リソースの読み取りとwrite-aclの特権の所有者を付与し、誰もが特権を読むことを許可します。
>> Request <<
ACL /top/container/ HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@example.com", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
<D:privilege><D:write/></D:privilege>
</D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:property><D:owner/></D:property>
</D:principal>
<D:grant>
<D:privilege><D:read-acl/></D:privilege>
<D:privilege><D:write-acl/></D:privilege>
</D:grant>
</D:ace>
<D:ace>
<D:principal><D:all/></D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
</D:grant>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 200 OK
HTTP/1.1 200 OK
In the following request, user "fielding", authenticated by information in the Authorization header, attempts to deny the principal identified by the URL http://www.example.com/users/esedlar (i.e., the user "esedlar") write privileges. Prior to the request, the DAV:acl property on the resource contained a protected ACE (see Section 5.5.3) granting DAV:owner the DAV:read and DAV:write privileges. The principal identified by URL http://www.example.com/ users/esedlar is the owner of the resource. The ACL method invocation fails because the submitted ACE conflicts with the protected ACE, thus violating the semantics of ACE protection.
次のリクエストでは、承認ヘッダーの情報によって認証されたユーザー「フィールド」は、URL http://www.example.com/users/esedlar（すなわち、ユーザー「esedlar」）書き込みで識別されたプリンシパルを拒否しようとします。特権。リクエストの前に、リソース上のDAV：ACLプロパティには保護されたエースが含まれていました（セクション5.5.3を参照）DAV：所有者The Dav：Read and Dav：Write Privileges。url http://www.example.com/ユーザー/esedlarによって識別された校長は、リソースの所有者です。提出されたACEが保護されたACEと競合するため、ACLメソッドの呼び出しは失敗し、したがってACE保護のセマンティクスに違反します。
>> Request <<
ACL /top/container/ HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@example.com", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/esedlar</D:href>
</D:principal>
<D:deny>
<D:privilege><D:write/></D:privilege>
</D:deny>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:no-protected-ace-conflict/>
</D:error>
In the following request, user "ejw", authenticated by information in the Authorization header, tries to change the access control list on the resource http://www.example.com/top/index.html. This resource has two inherited ACEs.
次のリクエストでは、承認ヘッダーの情報によって認証されたユーザー「EJW」は、リソースhttp://www.example.com/top/index.htmlのアクセス制御リストを変更しようとします。このリソースには、2つの継承されたエースがあります。
Inherited ACE #1 grants the principal identified by URL http:// www.example.com/users/ejw (i.e., the user "ejw") http:// www.example.com/privs/write-all and DAV:read-acl privileges. On this server, http://www.example.com/privs/write-all is an aggregate privilege containing DAV:write, and DAV:write-acl.
継承されたエース＃1は、url http：// www.example.com/users/ejw（すなわち、ユーザー "ejw"）http：// www.example.com/privs/write-all and dav：で識別されたプリンシパルを付与します。read-acl特権。このサーバーでは、http：//www.example.com/privs/write-allは、dav：write、dav：write-aclを含む集約的な特権です。
Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
継承されたエース＃2はプリンシパルDAVを付与します：All the Dav：Read Privilege。
The request attempts to set a (non-inherited) ACE, denying the principal identified by the URL http://www.example.com/users/ejw (i.e., the user "ejw") DAV:write permission. This conflicts with inherited ACE #1. Note that the decision to report an inherited ACE conflict is specific to this server implementation. Another server implementation could have allowed the new ACE to be set, and then used normal ACE evaluation rules to determine whether the new ACE has any impact on the privileges available to a principal.
リクエストは、（非相続）エースを設定しようとします。これは、URL http://www.example.com/users/ejw（すなわち、ユーザー「ejw」）dav：dav：書き込み許可を拒否します。これは、継承されたエース＃1と矛盾しています。継承されたACE競合を報告する決定は、このサーバーの実装に固有のものであることに注意してください。別のサーバーの実装では、新しいACEを設定し、通常のACE評価ルールを使用して、新しいACEがプリンシパルが利用できる特権に影響を与えるかどうかを判断する可能性があります。
>> Request <<
ACL /top/index.html HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="users@example.com", nonce="...",
uri="/top/index.html", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:" xmlns:F="http://www.example.com/privs/">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/ejw</D:href>
</D:principal>
<D:grant><D:write/></D:grant>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:no-inherited-ace-conflict/>
</D:error>
In this example, user "ygoland", authenticated by information in the Authorization header, tries to change the access control list on the resource http://www.example.com/diamond/engagement-ring.gif. The ACL request includes a single, syntactically and semantically incorrect ACE, which attempts to grant the group identified by the URL http:// www.example.com/users/friends DAV:read privilege and deny the principal identified by URL http://www.example.com/users/ygoland-so (i.e., the user "ygoland-so") DAV:read privilege. However, it is illegal to have multiple principal elements, as well as both a grant and deny element in the same ACE, so the request fails due to poor syntax.
この例では、承認ヘッダーの情報によって認証されたユーザー「Ygoland」は、リソースhttp://www.example.com/diamond/engagement-ring.gifのアクセス制御リストを変更しようとします。ACL要求には、URL http：// www.example.com/users/friends davで識別されたグループに付与を試みる単一の構文的および意味的に誤ったエースが含まれています。/www.example.com/users/ygoland-so（すなわち、ユーザー「ygoland-so "）dav：privilegeを読んでください。ただし、複数の主要な要素と同じエースに付与要素と拒否要素の両方があることは違法であるため、リクエストは構文が悪いために失敗します。
>> Request <<
ACL /diamond/engagement-ring.gif HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ygoland",
realm="users@example.com", nonce="...",
uri="/diamond/engagement-ring.gif", response="...",
opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/friends</D:href>
</D:principal>
<D:grant><D:read/></D:grant>
<D:principal>
<D:href>http://www.example.com/users/ygoland-so</D:href>
</D:principal>
<D:deny><D:read/></D:deny>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 400 Bad Request Content-Length: 0
HTTP/1.1 400悪い要求コンテンツレングス：0
Note that if the request had been divided into two ACEs, one to grant, and one to deny, the request would have been syntactically well formed.
リクエストが2つのエースに分割されていた場合、1つは付与するために、もう1つは否定するために、要求は構文的によく形成されていたであろうことに注意してください。
The REPORT method (defined in Section 3.6 of [RFC3253]) provides an extensible mechanism for obtaining information about a resource. Unlike the PROPFIND method, which returns the value of one or more named properties, the REPORT method can involve more complex processing. REPORT is valuable in cases where the server has access to all of the information needed to perform the complex request (such as a query), and where it would require multiple requests for the client to retrieve the information needed to perform the same request.
レポート方法（[RFC3253]のセクション3.6で定義）は、リソースに関する情報を取得するための拡張可能なメカニズムを提供します。1つ以上の名前付きプロパティの値を返すPropfindメソッドとは異なり、レポート方法には、より複雑な処理が含まれます。レポートは、サーバーが複雑な要求（クエリなど）を実行するために必要なすべての情報にアクセスできる場合、およびクライアントが同じリクエストを実行するために必要な情報を取得するために複数のリクエストを必要とする場合に役立ちます。
A server that supports the WebDAV Access Control Protocol MUST support the DAV:expand-property report (defined in Section 3.8 of [RFC3253]).
WebDAV Access Controlプロトコルをサポートするサーバーは、DAV：Expand-Propertyレポート（[RFC3253]のセクション3.8で定義）をサポートする必要があります。
The DAV:acl-principal-prop-set report returns, for all principals in the DAV:acl property (of the Request-URI) that are identified by http(s) URLs or by a DAV:property principal, the value of the properties specified in the REPORT request body. In the case where a principal URL appears multiple times, the DAV:acl-principal-prop-set report MUST return the properties for that principal only once. Support for this report is REQUIRED.
DAV：ACL-PRINCIPAL-PROP-SETレポートは、HTTP（S）URLまたはDAV：プロパティプリンシパルによって識別されるDAV：ACLプロパティ（リクエスト-URIの）のすべてのプリンシパルに対して返されます。レポート要求本体で指定されたプロパティ。プリンシパルURLが複数回表示される場合、DAV：ACL-PRINCIPAL-PROP-SETレポートは、そのプリンシパルのプロパティを一度だけ返す必要があります。このレポートのサポートが必要です。
One expected use of this report is to retrieve the human readable name (found in the DAV:displayname property) of each principal found in an ACL. This is useful for constructing user interfaces that show each ACE in a human readable form.
このレポートの予想される使用の1つは、ACLで見つかった各プリンシパルの人間の読み取り可能な名前（DAV：DisplayNameプロパティにある）を取得することです。これは、各ACEを人間の読み取り可能な形式で示すユーザーインターフェイスを構築するのに役立ちます。
Marshalling
マーシャリング
The request body MUST be a DAV:acl-principal-prop-set XML element.
リクエスト本体は、DAV：ACL-Principal-Prop-Set XML要素でなければなりません。
<!ELEMENT acl-principal-prop-set ANY>
ANY value: a sequence of one or more elements, with at most one
DAV:prop element.
prop: see RFC 2518, Section 12.11
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".
このレポートは、深度ヘッダーの値「0」の場合にのみ定義されます。その他の値は、400（悪い要求）エラー応答になります。[RFC3253]、セクション3.6は、深度ヘッダーが存在しない場合、デフォルトは「0」の値になることに注意してください。
The response body for a successful request MUST be a DAV:multistatus XML element (i.e., the response uses the same format as the response for PROPFIND). In the case where there are no response elements, the returned multistatus XML element is empty.
成功した要求の応答本体は、DAV：MultiStatus XML要素でなければなりません（つまり、応答はPropfindの応答と同じ形式を使用します）。応答要素がない場合、返されたMultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
Multistatus：RFC 2518、セクション12.9を参照してください
The response body for a successful DAV:acl-principal-prop-set REPORT request MUST contain a DAV:response element for each principal identified by an http(s) URL listed in a DAV:principal XML element of an ACE within the DAV:acl property of the resource identified by the Request-URI.
成功したDAVの応答本体：ACL-Principal-Prop-Setレポートリクエストには、DAV：DAV：DAV内のACEの主要なXML要素にリストされているHTTP（S）URLによって識別される各プリンシパルの応答要素を含める必要があります：Request-URIによって識別されたリソースのACLプロパティ。
Postconditions:
ポストコンディション：
(DAV:number-of-matches-within-limits): The number of matching principals must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.
（DAV：ライミットのマッチ数）：マッチングプリンシパルの数は、サーバー固有の事前定義された制限内に該当する必要があります。たとえば、検索仕様が非常に多数の応答を返すと、この条件がトリガーされる場合があります。
Resource http://www.example.com/index.html has an ACL with three ACEs:
リソースhttp://www.example.com/index.htmlには、3つのACEを備えたACLがあります。
ACE #1: All principals (DAV:all) have DAV:read and DAV:read-current-user-privilege-set access.
ACE＃1：すべてのプリンシパル（DAV：ALL）にはDAV：readとdav：read-current-user-privilege-setアクセスがあります。
ACE #2: The principal identified by http://www.example.com/people/ gstein (the user "gstein") is granted DAV:write, DAV:write-acl, DAV:read-acl privileges.
ACE＃2：http://www.example.com/people/ gstein（ユーザー "gstein"）によって識別された校長は、Dav：write、dav：write-acl、dav：read-acl特権を与えられます。
ACE #3: The group identified by http://www.example.com/groups/authors (the "authors" group) is granted DAV:write and DAV:read-acl privileges.
ACE＃3：http://www.example.com/groups/authors（「著者」グループ）によって識別されたグループは、Dav：write and dav：read-acl特権を付与されます。
The following example shows a DAV:acl-principal-prop-set report requesting the DAV:displayname property. It returns the value of DAV:displayname for resources http://www.example.com/people/gstein and http://www.example.com/groups/authors , but not for DAV:all, since this is not an http(s) URL.
次の例は、DAV：ACL-PRINCIPAL-PROP-SETレポートをDAV：DisplayNameプロパティを要求しています。リソースのdivisname：displayname http://www.example.com/people/gstein and http://www.example.com/groups/authorsの値を返しますが、davのためではありません。http（s）url。
>> Request <<
REPORT /index.html HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Depth: 0
<?xml version="1.0" encoding="utf-8" ?>
<D:acl-principal-prop-set xmlns:D="DAV:">
<D:prop>
<D:displayname/>
</D:prop>
</D:acl-principal-prop-set>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/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/people/gstein</D:href>
<D:propstat>
<D:prop>
<D:displayname>Greg Stein</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/groups/authors</D:href>
<D:propstat>
<D:prop>
<D:displayname>Site authors</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The DAV:principal-match REPORT is used to identify all members (at any depth) of the collection identified by the Request-URI that are principals and that match the current user. In particular, if the collection contains principals, the report can be used to identify all members of the collection that match the current user. Alternatively, if the collection contains resources that have a property that identifies a principal (e.g., DAV:owner), the report can be used to identify all members of the collection whose property identifies a principal that matches the current user. For example, this report can return all of the resources in a collection hierarchy that are owned by the current user. Support for this report is REQUIRED.
DAV：プリンシパルマッチレポートは、プリンシパルであり、現在のユーザーと一致するリクエスト-URIによって識別されたコレクションのすべてのメンバー（任意の深さ）を識別するために使用されます。特に、コレクションにプリンシパルが含まれている場合、レポートは現在のユーザーに一致するコレクションのすべてのメンバーを識別するために使用できます。または、コレクションにプリンシパルを識別するプロパティ（DAV：所有者など）を持つリソースが含まれている場合、レポートを使用して、現在のユーザーと一致するプリンシパルを識別するコレクションのすべてのメンバーを識別できます。たとえば、このレポートは、現在のユーザーが所有するコレクション階層内のすべてのリソースを返すことができます。このレポートのサポートが必要です。
Marshalling:
マーシャリング：
The request body MUST be a DAV:principal-match XML element.
<!ELEMENT principal-match ((principal-property | self), prop?)>
<!ELEMENT principal-property ANY>
ANY value: an element whose value identifies a property. The
expectation is the value of the named property typically contains
an href element that contains the URI of a principal
<!ELEMENT self EMPTY>
prop: see RFC 2518, Section 12.11
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0". The response body for a successful request MUST be a DAV:multistatus XML element. In the case where there are no response elements, the returned multistatus XML element is empty.
このレポートは、深度ヘッダーの値「0」の場合にのみ定義されます。その他の値は、400（悪い要求）エラー応答になります。[RFC3253]、セクション3.6は、深度ヘッダーが存在しない場合、デフォルトは「0」の値になることに注意してください。リクエストを成功させるための応答本体は、DAV：MultiStatus XML要素でなければなりません。応答要素がない場合、返されたMultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
Multistatus：RFC 2518、セクション12.9を参照してください
The response body for a successful DAV:principal-match REPORT request MUST contain a DAV:response element for each member of the collection that matches the current user. When the DAV:principal-property element is used, a match occurs if the current user is matched by the principal identified by the URI found in the DAV:href element of the property identified by the DAV:principal-property element. When the DAV:self element is used in a DAV:principal-match report issued against a group, it matches the group if a member identifies the same principal as the current user.
成功したDAV：プリンシパルマッチレポートリクエストの応答本体には、現在のユーザーと一致するコレクションの各メンバーのDAV：応答要素が含まれている必要があります。DAV：プリンシパルプロパティ要素を使用すると、現在のユーザーがDAV：DAV：プリンシパルプロパティ要素によって識別されたプロパティのHREF要素で見つかったURIによって識別されたプリンシパルによって一致する場合に一致します。DAV：Self ElementがDAV：グループに対して発行されたプリンシパルマッチレポートで使用される場合、メンバーが現在のユーザーと同じプリンシパルを識別した場合、グループと一致します。
If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements.
DAV：PROPがリクエスト本体で指定されている場合、DAV：PROP要素で指定されたプロパティは、DAV：応答要素で報告する必要があります。
The following example identifies the members of the collection identified by the URL http://www.example.com/doc that are owned by the current user. The current user ("gclemm") is authenticated using Digest authentication.
次の例では、現在のユーザーが所有するURL http://www.example.com/docによって識別されたコレクションのメンバーを識別します。現在のユーザー（ "GCLEMM"）は、Digest認証を使用して認証されます。
>> Request <<
REPORT /doc/ HTTP/1.1
Host: www.example.com
Authorization: Digest username="gclemm",
realm="users@example.com", nonce="...",
uri="/papers/", response="...", opaque="..."
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Depth: 0
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-match xmlns:D="DAV:">
<D:principal-property>
<D:owner/>
</D:principal-property>
</D:principal-match>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/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/doc/foo.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.example.com/doc/img/bar.gif</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
The DAV:principal-property-search REPORT performs a search for all principals whose properties contain character data that matches the search criteria specified in the request. One expected use of this report is to discover the URL of a principal associated with a given person or group by searching for them by name. This is done by searching over DAV:displayname, which is defined on all principals.
DAV：Principal-Property-Searchレポートは、リクエストで指定された検索基準に一致する文字データが含まれているすべてのプリンシパルの検索を実行します。このレポートの予想される使用の1つは、名前でそれらを検索することにより、特定の人またはグループに関連するプリンシパルのURLを発見することです。これは、すべてのプリンシパルで定義されているDav：DisplayNameを検索することによって行われます。
The actual search method (exact matching vs. substring matching vs, prefix-matching, case-sensitivity) deliberately is left to the server implementation to allow implementation on a wide set of possible user management systems. In cases where the implementation of DAV:principal-property-search is not constrained by the semantics of an underlying user management repository, preferred default semantics are caseless substring matches.
実際の検索方法（正確なマッチング対サブストリングマッチング、プレフィックスマッチング、ケース感受性）は、意図的にサーバーの実装に任され、可能なユーザー管理システムの幅広いセットで実装を可能にします。DAV：プリンシパルプロパティ検索の実装が基礎となるユーザー管理リポジトリのセマンティクスによって制約されていない場合、優先デフォルトのセマンティクスはCaseless Substringマッチです。
For implementation efficiency, servers do not typically support searching on all properties. A search requesting properties that are not searchable for a particular principal will not match that principal.
実装効率のために、サーバーは通常、すべてのプロパティでの検索をサポートしません。特定のプリンシパルを検索できないプロパティを要求する検索は、そのプリンシパルと一致しません。
Support for the DAV:principal-property-search report is REQUIRED.
DAVのサポート：プリンシパルプロパティ - 検索レポートが必要です。
Implementation Note: The value of a WebDAV property is a sequence of well-formed XML, and hence can include any character in the Unicode/ISO-10646 standard, that is, most known characters in human languages. Due to the idiosyncrasies of case mapping across human languages, implementation of case-insensitive matching is non-trivial. Implementors of servers that do perform substring matching are strongly encouraged to consult "The Unicode Standard" [UNICODE4], especially Section 5.18, Subsection "Caseless Matching", for guidance when implementing their case-insensitive matching algorithms.
実装注：WebDAVプロパティの値は、よく形成されたXMLのシーケンスであるため、Unicode/ISO-10646標準、つまり人間言語で最も知られている文字に任意のキャラクターを含めることができます。人間の言語全体でケースマッピングの特異性があるため、ケース非感受性マッチングの実装は自明ではありません。サブストリングマッチングを実行するサーバーの実装者は、「Unicode Standard」[Unicode4]、特にセクション5.18、サブセクション「Caseless Matching」を参照することを強くお勧めします。
Implementation Note: Some implementations of this protocol will use an LDAP repository for storage of principal metadata. The schema describing each attribute (akin to a WebDAV property) in an LDAP repository specifies whether it supports case-sensitive or caseless searching. One of the benefits of leaving the search method to the discretion of the server implementation is the default LDAP attribute search behavior can be used when implementing the DAV:principal-property-search report.
実装注：このプロトコルの一部の実装では、主要メタデータの保存にLDAPリポジトリを使用します。LDAPリポジトリ内の各属性（WebDavプロパティに似ている）を記述するスキーマは、ケースに敏感な検索またはCaseless検索をサポートするかどうかを指定します。サーバーの実装の裁量に検索方法を任せる利点の1つは、DAVの実装時に使用できるデフォルトのLDAP属性の検索動作です。
Marshalling:
マーシャリング：
The request body MUST be a DAV:principal-property-search XML element containing a search specification and an optional list of properties. For every principal that matches the search specification, the response will contain the value of the requested properties on that principal.
リクエスト本体は、検索仕様とオプションのプロパティリストを含むプリンシパルプロパティ - 検索XML要素である必要があります。検索仕様に一致するすべてのプリンシパルについて、応答には、そのプリンシパルの要求されたプロパティの値が含まれます。
<!ELEMENT principal-property-search
((property-search+), prop?, apply-to-principal-collection-set?) >
By default, the report searches all members (at any depth) of the collection identified by the Request-URI. If DAV:apply-to-principal-collection-set is specified in the request body, the request is applied instead to each collection identified by the DAV:principal-collection-set property of the resource identified by the Request-URI.
デフォルトでは、レポートはリクエスト-URIによって識別されたコレクションのすべてのメンバー（任意の深さ）を検索します。DAV：リクエスト本体で適用対策対象セットが指定されている場合、リクエストは代わりにDAV：リクエスト-URIによって識別されたリソースのプリンシパルコレクションセットプロパティによって識別された各コレクションに適用されます。
The DAV:property-search element contains a prop element enumerating the properties to be searched and a match element, containing the search string.
DAV：Property-Search要素には、検索するプロパティを列挙するProp要素と、検索文字列を含む一致要素が含まれています。
<!ELEMENT property-search (prop, match) >
prop: see RFC 2518, Section 12.11
<!ELEMENT match #PCDATA > Multiple property-search elements or multiple elements within a DAV:prop element will be interpreted with a logical AND.
<！要素マッチ#PCDATA> DAV内の複数のプロパティ検索要素または複数の要素：PROP要素は、論理的に解釈されます。
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".
このレポートは、深度ヘッダーの値「0」の場合にのみ定義されます。その他の値は、400（悪い要求）エラー応答になります。[RFC3253]、セクション3.6は、深度ヘッダーが存在しない場合、デフォルトは「0」の値になることに注意してください。
The response body for a successful request MUST be a DAV:multistatus XML element. In the case where there are no response elements, the returned multistatus XML element is empty.
リクエストを成功させるための応答本体は、DAV：MultiStatus XML要素でなければなりません。応答要素がない場合、返されたMultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
Multistatus：RFC 2518、セクション12.9を参照してください
The response body for a successful DAV:principal-property-search REPORT request MUST contain a DAV:response element for each principal whose property values satisfy the search specification given in DAV:principal-property-search.
成功したDAVの応答本体：プリンシパルプロパティサージレポートリクエストには、DAV：DAV：プリンシパルプロパティサージで与えられた検索仕様を満たす各プリンシパルの応答要素を含める必要があります。
If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements.
DAV：PROPがリクエスト本体で指定されている場合、DAV：PROP要素で指定されたプロパティは、DAV：応答要素で報告する必要があります。
Preconditions:
前提条件：
None
なし
Postconditions:
ポストコンディション：
(DAV:number-of-matches-within-limits): The number of matching principals must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.
（DAV：ライミットのマッチ数）：マッチングプリンシパルの数は、サーバー固有の事前定義された制限内に該当する必要があります。たとえば、検索仕様が非常に多数の応答を返すと、この条件がトリガーされる場合があります。
There are several cases to consider when matching strings. The easiest case is when a property value is "simple" and has only character information item content (see [REC-XML-INFOSET]). For example, the search string "julian" would match the DAV:displayname property with value "Julian Reschke". Note that the on-the-wire marshaling of DAV:displayname in this case is:
文字列を一致させるときに考慮すべきいくつかのケースがあります。最も簡単なケースは、プロパティ値が「単純」で、文字情報アイテムのコンテンツのみがある場合です（[rec-xml-infoset]を参照）。たとえば、検索文字列「Julian」は、DAV：DisplayNameプロパティをValue「Julian Reschke」と一致させます。DAVのオンザワイヤマーシャリング：この場合のDisplayNameは次のとおりです。
<D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname> The name of the property is encoded into the XML element information item, and the character information item content of the property is "Julian Reschke".
<D：DisplayName XMLNS：D = "DAV："> Julian Reschke </d：displayName>プロパティの名前はXML要素情報項目にエンコードされ、プロパティの文字情報項目コンテンツは「Julian Reschke」です。
A more complicated case occurs when properties have mixed content (that is, compound values consisting of multiple child element items, other types of information items, and character information item content). Consider the property "aprop" in the namespace "http:// www.example.com/props/", marshaled as:
より複雑なケースは、プロパティが混合コンテンツ（つまり、複数の子要素項目、他の種類の情報項目、およびキャラクター情報項目のコンテンツで構成される複合値）を持っている場合に発生します。名前空間「http：// www.example.com/props/」のプロパティ「aprop」を考えてみましょう。
<W:aprop xmlns:W="http://www.example.com/props/">
{cdata 0}<W:elem1>{cdata 1}</W:elem1>
<W:elem2>{cdata 2}</W:elem2>{cdata 3}
</W:aprop>
In this case, matching is performed on each individual contiguous sequence of character information items. In the example above, a search string would be compared to the four following strings:
この場合、個々の隣接する文字情報項目のシーケンスごとに一致が実行されます。上記の例では、検索文字列は次の4つの文字列と比較されます。
{cdata 0}
{cdata 1}
{cdata 2}
{cdata 3}
That is, four individual matches would be performed, one each for {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
つまり、4つの個別の一致が実行されます。1つは{cdata 0}、{cdata 1}、{cdata 2}、および{cdata 3}の1つです。
In this example, the client requests the principal URLs of all users whose DAV:displayname property contains the substring "doE" and whose "title" property in the namespace "http://BigCorp.com/ns/" (that is, their professional title) contains "Sales". In addition, the client requests five properties to be returned with the matching principals:
この例では、クライアントは、Dav：DisplayNameプロパティにサブストリング「DOE」と名前空間の「タイトル」プロパティが含まれているすべてのユーザーの主要なURLを要求しますhttp://bigcorp.com/ns/ "プロのタイトル）には「販売」が含まれています。さらに、クライアントは、一致するプリンシパルで5つのプロパティを返すように要求します。
In the DAV: namespace: displayname
DAV：namespace：displayName
In the http://www.example.com/ns/ namespace: department, phone, office, salary The response shows that two principal resources meet the search specification, "John Doe" and "Zygdoebert Smith". The property "salary" in namespace "http://www.example.com/ns/" is not returned, since the principal making the request does not have sufficient access permissions to read this property.
http://www.example.com/ns/ namespace：部門、電話、オフィス、給与では、2つの主要なリソースが検索仕様「John Doe」と「Zygdoebert Smith」を満たしていることが示されています。名前空間のプロパティ「給与」 "http://www.example.com/ns/"は返されません。リクエストを作成する元本には、このプロパティを読み取るのに十分なアクセス許可がないためです。
>> Request <<
REPORT /users/ HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset=utf-8
Content-Length: xxxx
Depth: 0
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-property-search xmlns:D="DAV:">
<D:property-search>
<D:prop>
<D:displayname/>
</D:prop>
<D:match>doE</D:match>
</D:property-search>
<D:property-search>
<D:prop xmlns:B="http://www.example.com/ns/">
<B:title/>
</D:prop>
<D:match>Sales</D:match>
</D:property-search>
<D:prop xmlns:B="http://www.example.com/ns/">
<D:displayname/>
<B:department/>
<B:phone/>
<B:office/>
<B:salary/>
</D:prop>
</D:principal-property-search>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset=utf-8
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:B="http://BigCorp.com/ns/">
<D:response>
<D:href>http://www.example.com/users/jdoe</D:href>
<D:propstat>
<D:prop>
<D:displayname>John Doe</D:displayname>
<B:department>Widget Sales</B:department>
<B:phone>234-4567</B:phone>
<B:office>209</B:office>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<B:salary/>
</D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/users/zsmith</D:href>
<D:propstat>
<D:prop>
<D:displayname>Zygdoebert Smith</D:displayname>
<B:department>Gadget Sales</B:department>
<B:phone>234-7654</B:phone>
<B:office>114</B:office>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<B:salary/>
</D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:propstat>
</D:response>
</D:multistatus>
The DAV:principal-search-property-set REPORT identifies those properties that may be searched using the DAV:principal-property-search REPORT (defined in Section 9.4).
DAV：Principal-Search-Property-Setレポートは、DAV：Principal-Property-Searchレポート（セクション9.4で定義）を使用して検索できるプロパティを特定します。
Servers MUST support the DAV:principal-search-property-set REPORT on all collections identified in the value of a DAV:principal-collection-set property.
サーバーは、DAV：DAV：プリンシパルコレクションセットプロパティの価値で識別されたすべてのコレクションに関するDAV：プリンシパルサーチプロパティセットレポートをサポートする必要があります。
An access control protocol user agent could use the results of the DAV:principal-search-property-set REPORT to present a query interface to the user for retrieving principals.
アクセス制御プロトコルユーザーエージェントは、DAV：Principal-Search-Property-Setレポートの結果を使用して、プリンシパルを取得するためにユーザーにクエリインターフェイスを提示できます。
Support for this report is REQUIRED.
このレポートのサポートが必要です。
Implementation Note: Some clients will have only limited screen real estate for the display of lists of searchable properties. In this case, a user might appreciate having the most frequently searched properties be displayed on-screen, rather than having to scroll through a long list of searchable properties. One mechanism for signaling the most frequently searched properties is to return them towards the start of a list of properties. A client can then preferentially display the list of properties in order, increasing the likelihood that the most frequently searched properties will appear on-screen, and will not require scrolling for their selection.
実装注：一部のクライアントは、検索可能なプロパティのリストを表示するためのスクリーン不動産のみを限定しています。この場合、ユーザーは、検索可能なプロパティの長いリストをスクロールする必要があるのではなく、最も頻繁に検索されたプロパティを画面上に表示することを高く評価する場合があります。最も頻繁に検索されるプロパティを信号するメカニズムの1つは、プロパティのリストの開始に向けてそれらを返すことです。クライアントは、プロパティのリストを順番に優先的に表示し、最も頻繁に検索されるプロパティが画面上に表示される可能性を高め、選択にスクロールする必要はありません。
Marshalling:
マーシャリング：
The request body MUST be an empty DAV:principal-search-property-set XML element.
リクエスト本体は空のDAVでなければなりません：プリンシパルサクロパティセットXML要素。
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".
このレポートは、深度ヘッダーの値「0」の場合にのみ定義されます。その他の値は、400（悪い要求）エラー応答になります。[RFC3253]、セクション3.6は、深度ヘッダーが存在しない場合、デフォルトは「0」の値になることに注意してください。
The response body MUST be a DAV:principal-search-property-set XML element, containing a DAV:principal-search-property XML element for each property that may be searched with the DAV:principal-property-search REPORT. A server MAY limit its response to just a subset of the searchable properties, such as those likely to be useful to an interactive access control client.
応答本体は、dav：dav：dav：principal-property-searchレポートで検索される可能性のある各プロパティのプリンシパルサーチプロパティxml要素を含む、dav：dav：principal-search-property xml要素を含むdav：dav：dav：search-search-property xml要素である必要があります。サーバーは、インタラクティブなアクセス制御クライアントに役立つ可能性が高いものなど、検索可能なプロパティのサブセットのみに対する応答を制限する場合があります。
<!ELEMENT principal-search-property-set
(principal-search-property*) >
Each DAV:principal-search-property XML element contains exactly one searchable property, and a description of the property.
各DAV：プリンシパルサーチプロパティXML要素には、正確に1つの検索可能なプロパティと、プロパティの説明が含まれています。
<!ELEMENT principal-search-property (prop, description) >
The DAV:prop element contains one principal property on which the server is able to perform a DAV:principal-property-search REPORT.
DAV：Prop要素には、サーバーがDAV：プリンシパルプロパティ検索レポートを実行できる1つの主要なプロパティが含まれています。
prop: see RFC 2518, Section 12.11 The description element is a human-readable description of what information this property represents. Servers MUST indicate the human language of the description using the xml:lang attribute and SHOULD consider the HTTP Accept-Language request header when selecting one of multiple available languages.
プロップ：RFC 2518、セクション12.11を参照してください。説明要素は、このプロパティが表す情報の人間が読みやすい説明です。サーバーは、XML：Lang属性を使用して説明の人間言語を示す必要があり、複数の利用可能な言語のいずれかを選択するときにHTTP Accept-Language Requestヘッダーを考慮する必要があります。
<!ELEMENT description #PCDATA >
In this example, the client determines the set of searchable principal properties by requesting the DAV:principal-search-property-set REPORT on the root of the server's principal URL collection set, identified by http://www.example.com/users/.
この例では、クライアントは、http://www.example.com/usersによって識別されるサーバーの主要なURLコレクションセットのルートに関するDAV：プリンシパルサクプロパティセットレポートを要求することにより、検索可能なプリンシパルプロパティのセットを決定します。/。
>> Request <<
REPORT /users/ HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
Accept-Language: en, de
Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=
Depth: 0
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-search-property-set xmlns:D="DAV:"/>
>> Response <<
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:principal-search-property-set xmlns:D="DAV:">
<D:principal-search-property>
<D:prop>
<D:displayname/>
</D:prop>
<D:description xml:lang="en">Full name</D:description>
</D:principal-search-property>
<D:principal-search-property>
<D:prop xmlns:B="http://BigCorp.com/ns/">
<B:title/>
</D:prop>
<D:description xml:lang="en">Job title</D:description>
</D:principal-search-property>
</D:principal-search-property-set>
Implementations of this specification MUST support the XML element ignore rule, as specified in Section 23.3.2 of [RFC2518], and the XML Namespace recommendation [REC-XML-NAMES].
この仕様の実装は、[RFC2518]のセクション23.3.2で指定されているように、XML要素を無視するルールをサポートする必要があります。
Note that use of the DAV namespace is reserved for XML elements and property names defined in a standards-track or Experimental IETF RFC.
DAVネームスペースの使用は、標準トラックまたは実験的なIETF RFCで定義されたXML要素とプロパティ名に予約されていることに注意してください。
In this specification, the only human-readable content can be found in the description XML element, found within the DAV:supported-privilege-set property. This element contains a human-readable description of the capabilities controlled by a privilege. As a result, the description element must be capable of representing descriptions in multiple character sets. Since the description element is found within a WebDAV property, it is represented on the wire as XML [REC-XML], and hence can leverage XML's language tagging and character set encoding capabilities. Specifically, XML processors at minimum must be able to read XML elements encoded using the UTF-8 [RFC3629] encoding of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in [RFC3023], as well as the XML "encoding" attribute, which together provide charset identification information for MIME and XML processors. Furthermore, this specification requires server implementations to tag description fields with the xml:lang attribute (see Section 2.12 of [REC-XML]), which specifies the human language of the description. Additionally, server implementations should take into account the value of the Accept-Language HTTP header to determine which description string to return.
この仕様では、DAV：Support-Privilege-Setプロパティ内にある説明XML要素に唯一の人間読み取り可能なコンテンツが見つかります。この要素には、特権によって制御される機能の人間が読みやすい説明が含まれています。その結果、説明要素は、複数の文字セットで説明を表すことができなければなりません。説明要素はWebDavプロパティ内に見られるため、ワイヤー上でXML [Rec-XML]として表されるため、XMLの言語タグ付けと文字セットエンコーディング機能を活用できます。具体的には、XMLプロセッサは、ISO 10646多言語平面のEncodingをエンコードするUTF-8 [RFC3629]を使用してエンコードされたXML要素を読み取ることができなければなりません。この仕様のXMLの例は、[RFC3023]で定義されているコンテンツタイプのヘッダーのcharsetパラメーターの使用と、MIMEおよびXMLプロセッサの憲章識別情報を一緒に提供するXML「エンコード」属性の使用を示しています。さらに、この仕様では、説明の人間言語を指定するXML：LANG属性（[REC-XML]のセクション2.12を参照）で説明フィールドをタグ付けするためのサーバー実装が必要です。さらに、サーバーの実装では、承認言語HTTPヘッダーの値を考慮して、返すべき文字列を決定する必要があります。
For XML elements other than the description element, it is expected that implementations will treat the property names, privilege names, and values as tokens, and convert these tokens into human-readable text in the user's language and character set when displayed to a person. Only a generic WebDAV property display utility would display these values in their raw form to a human user.
説明要素以外のXML要素の場合、実装はプロパティ名、特権名、および値をトークンとして扱い、これらのトークンを人に表示するとユーザーの言語とキャラクターセットで人間の読み取り可能なテキストに変換することが期待されます。一般的なWebDavプロパティディスプレイユーティリティのみが、これらの値を生の形式で人間のユーザーに表示します。
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., 200 (OK)). 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ステータスコードの慣習に従って、コードの短い英語の説明（例：200（OK））。作成されていないユーザーエージェントがこのメッセージをユーザーに表示する可能性は存在しますが、国際化されたアプリケーションはこのメッセージを無視し、ユーザーの言語とキャラクターセットに適切なメッセージを表示します。
Further internationalization considerations for this protocol are described in the WebDAV Distributed Authoring protocol specification [RFC2518].
このプロトコルのさらなる国際化に関する考慮事項は、WebDAV分散オーサリングプロトコル仕様[RFC2518]で説明されています。
Applications and users of this access control protocol should be aware of several security considerations, detailed below. In addition to the discussion in this document, the security considerations detailed in the HTTP/1.1 specification [RFC2616], the WebDAV Distributed Authoring Protocol specification [RFC2518], and the XML Media Types specification [RFC3023] should be considered in a security analysis of this protocol.
このアクセス制御プロトコルのアプリケーションとユーザーは、以下に詳述するいくつかのセキュリティ上の考慮事項を認識する必要があります。このドキュメントの議論に加えて、HTTP/1.1仕様[RFC2616]に詳述されているセキュリティ考慮事項、WebDAV分散オーサリングプロトコル仕様[RFC2518]、およびXMLメディアタイプ仕様[RFC3023]は、セキュリティ分析で検討する必要があります。このプロトコル。
In the absence of a mechanism for remotely manipulating access control lists, if a single user's authentication credentials are compromised, only those resources for which the user has access permission can be read, modified, moved, or deleted. With the introduction of this access control protocol, if a single compromised user has the ability to change ACLs for a broad range of other users (e.g., a super-user), the number of resources that could be altered by a single compromised user increases. This risk can be mitigated by limiting the number of people who have write-acl privileges across a broad range of resources.
アクセス制御リストをリモートで操作するメカニズムがない場合、単一のユーザーの認証資格情報が妥協された場合、ユーザーがアクセス許可を持っているリソースのみを読み取り、変更、移動、または削除できます。このアクセス制御プロトコルの導入により、単一の侵害されたユーザーが他の幅広いユーザー（スーパーユーザーなど）に対してACLを変更する機能を持っている場合、単一の侵害されたユーザーが変更できるリソースの数が増加します。。このリスクは、幅広いリソースでWrite-ACL特権を持っている人の数を制限することで緩和できます。
The ability to read the access privileges (stored in the DAV:acl property), or the privileges permitted the currently authenticated user (stored in the DAV:current-user-privilege-set property) on a resource may seem innocuous, since reading an ACL cannot possibly affect the resource's state. However, if all resources have world-readable ACLs, it is possible to perform an exhaustive search for those resources that have inadvertently left themselves in a vulnerable state, such as being world-writable. In particular, the property retrieval method PROPFIND, executed with Depth infinity on an entire hierarchy, is a very efficient way to retrieve the DAV:acl or DAV:current-user-privilege-set properties. Once found, this vulnerability can be exploited by a denial of service attack in which the open resource is repeatedly overwritten. Alternately, writable resources can be modified in undesirable ways.
アクセス特権（DAV：ACLプロパティに保存されている）を読む機能、またはリソースの現在認証されているユーザー（DAV：Current-User-Privilege-Setプロパティに保存）を許可する特権は無害に思えるかもしれません。ACLはリソースの状態に影響を与える可能性があります。ただし、すべてのリソースに世界的に読みやすいACLSがある場合、世界で人や脆弱な状態に誤って自分自身を残したリソースを徹底的に検索することができます。特に、階層全体で深さの無限で実行されるプロパティ検索方法Propfindは、DAV：ACLまたはDAV：Current-User-Privilege-Setプロパティを取得するための非常に効率的な方法です。発見されると、この脆弱性は、オープンリソースが繰り返し上書きされるサービス拒否攻撃によって活用される可能性があります。あるいは、手続き可能なリソースは、望ましくない方法で変更できます。
To reduce this risk, read-acl privileges should not be granted to unauthenticated principals, and restrictions on read-acl and read-current-user-privilege-set privileges for authenticated principals should be carefully analyzed when deploying this protocol. Access to the current-user-privilege-set property will involve a tradeoff of usability versus security. When the current-user-privilege-set is visible, user interfaces are expected to provide enhanced information concerning permitted and restricted operations, yet this information may also indicate a vulnerability that could be exploited. Deployment of this protocol will need to evaluate this tradeoff in light of the requirements of the deployment environment.
このリスクを軽減するには、認証されたプリンシパルの読み取り科学者および読み取り電流型ユーザープリビレゲセットの特権に関する読み取りACL特権を認められた校長に許可するべきではありません。現在のユーザー-Privilege-Setプロパティへのアクセスには、ユーザビリティとセキュリティのトレードオフが含まれます。現在のユーザー-Privilege-Setが表示されると、ユーザーインターフェイスは許可された制限された操作に関する強化された情報を提供することが期待されますが、この情報は悪用される可能性のある脆弱性を示している可能性があります。このプロトコルの展開では、展開環境の要件に照らしてこのトレードオフを評価する必要があります。
In an effort to reduce protocol complexity, this protocol specification intentionally does not address the issue of how to manage or discover the initial ACL that is placed upon a resource when it is created. The only way to discover the initial ACL is to create a new resource, then retrieve the value of the DAV:acl property. This assumes the principal creating the resource also has been granted the DAV:read-acl privilege.
プロトコルの複雑さを減らすために、このプロトコル仕様は、作成時にリソースに配置された初期ACLを管理または発見する方法の問題に意図的に対処しません。最初のACLを発見する唯一の方法は、新しいリソースを作成し、DAV：ACLプロパティの値を取得することです。これは、リソースを作成するプリンシパルがDAV：Read-ACL特権も付与されていることを前提としています。
As a result, it is possible that a principal could create a resource, and then discover that its ACL grants privileges that are undesirable. Furthermore, this protocol makes it possible (though unlikely) that the creating principal could be unable to modify the ACL, or even delete the resource. Even when the ACL can be modified, there will be a short period of time when the resource exists with the initial ACL before its new ACL can be set.
その結果、プリンシパルがリソースを作成し、そのACLが望ましくない特権を付与することを発見できる可能性があります。さらに、このプロトコルにより、作成プリンシパルがACLを変更したり、リソースを削除したりすることができないことが可能になります（ありますが）。ACLを変更できる場合でも、新しいACLを設定する前に、最初のACLにリソースが存在する短い期間があります。
Several factors mitigate this risk. Human principals are often aware of the default access permissions in their editing environments and take this into account when writing information. Furthermore, default privilege policies are usually very conservative, limiting the privileges granted by the initial ACL.
いくつかの要因がこのリスクを軽減します。人間の校長は、多くの場合、編集環境のデフォルトアクセス許可を認識しており、情報を書くときにこれを考慮します。さらに、デフォルトの特権ポリシーは通常非常に保守的であり、最初のACLによって付与された特権を制限します。
Authentication mechanisms defined for use with HTTP and WebDAV also apply to this WebDAV Access Control Protocol, in particular the Basic and Digest authentication mechanisms defined in [RFC2617]. Implementation of the ACL spec requires that Basic authentication, if used, MUST only be supported over secure transport such as TLS.
HTTPおよびWebDAVで使用するために定義された認証メカニズムは、このWebDAVアクセス制御プロトコル、特に[RFC2617]で定義されている基本および消化認証メカニズムにも適用されます。ACL仕様の実装では、基本認証は、使用する場合は、TLSなどの安全な輸送でのみサポートする必要があります。
This document uses the namespace defined by [RFC2518] for XML elements. That is, this specification uses the "DAV:" URI namespace, previously registered in the URI schemes registry. All other IANA considerations mentioned in [RFC2518] are also applicable to this specification.
このドキュメントでは、XML要素に対して[RFC2518]で定義された名前空間を使用します。つまり、この仕様では、以前にURIスキームレジストリに登録されていた「DAV：」URI NameSpaceを使用しています。[RFC2518]で言及されている他のすべてのIANAの考慮事項は、この仕様にも適用できます。
This protocol is the collaborative product of the WebDAV ACL design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors are grateful for the detailed review and comments provided by Jim Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, and Keith Wannamaker. We thank Keith Wannamaker for the initial text of the principal property search sections. Prior work on WebDAV access control protocols has been performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. We would like to acknowledge the foundation laid for us by the authors of the DeltaV, WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV working group.
このプロトコルは、WebDav ACLデザインチームの共同製品です。BernardChester、Geoff Clemm、Anne Hopkins、Barry Lind、Sean Lyndersay、Eric Sedlar、Greg Stein、およびJim Whiteheadです。著者は、ジム・アムスデン、ディラン・バレル、ジーノ・バッソ、マーシー・チンタラパティ、リサ・デュッセー、ステファン・アイシング、ティム・エリソン、ヤロン・ゴーランド、デニス・ハミルトン、ローリー・ハーパー、エコハード・ヘルマン、ロン・ジェイコブス、クリス・ナイト、クリス・ナイト、クリス・ナイト、デニス・ハミルトン、ヤロン・ゴランド、、レミー・マウチェラット、ラリー・マスインター、ジョー・オートン、ピーター・レイモンド、キース・ワンナメーカー。キースワナメーカーは、主要なプロパティ検索セクションの最初のテキストについて感謝します。WebDAVアクセス制御プロトコルに関する以前の作業は、Yaron Goland、Paul Leach、Lisa Dusseault、Howard Palmer、Jon Radoffによって実行されました。このプロトコルが階層化されているDeltav、WebDav、およびHTTPプロトコルの著者と、WebDavワーキンググループからの貴重なフィードバックによって、私たちのために築かれた財団を認めたいと思います。
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 ((Third ed)", W3C REC REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
[Rec-XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C. and E. Maler、「拡張マークアップ言語（XML）1.0（（3番目のED）」、W3C Rec Rec-XML-20040204、2月2004、<http://www.w3.org/tr/2004/REC-XML-20040204>。
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[Rec-XML-Infoset] Cowan、J。および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. and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[Rec-XML-Names] Bray、T.、Hollander、D。、A。Layman、「XMLの名前空間」、W3C Rec-XML-Names-19990114、1999年1月、<http://www.w3.org/TR/1999/REC-XML-NAMES-1990114>。
[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月。
[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月。
[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。and 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。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[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", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、Ellison、T.、Kaler、C。and J. Whitehead、「extensionsへの拡張機能」、RFC 3253、2002年3月。
[RFC3530] Shepler, S., Ed., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Ed。、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M.、D。Noveck、 "Network File System（NFS）バージョン4プロトコル"、RFC 3530、2003年4月。
[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月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255] Howes、T。およびM. Smith、「LDAP URL形式」、RFC 2255、1997年12月。
[UNICODE4] The Unicode Consortium, "The Unicode Standard - Version 4.0", Addison-Wesley , August 2003, <http://www.unicode.org/versions/Unicode4.0.0/>. ISBN 0321185781.
[Unicode4] Unicode Consortium、「Unicode Standard -Version 4.0」、Addison -Wesley、2003年8月、<http://www.unicode.org/versions/unicode4.0.0/>。ISBN 0321185781。
All XML elements defined in this Document Type Definition (DTD) belong to the DAV namespace. This DTD should be viewed as an addendum to the DTD provided in [RFC2518], section 23.1.
このドキュメントタイプ定義（DTD）で定義されているすべてのXML要素は、DAVネームスペースに属します。このDTDは、[RFC2518]、セクション23.1で提供されているDTDの補遺と見なす必要があります。
<!-- Privileges -- (Section 3)>
<!ELEMENT read EMPTY>
<!ELEMENT write EMPTY>
<!ELEMENT write-properties EMPTY>
<!ELEMENT write-content EMPTY>
<!ELEMENT unlock EMPTY>
<!ELEMENT read-acl EMPTY>
<!ELEMENT read-current-user-privilege-set EMPTY>
<!ELEMENT write-acl EMPTY>
<!ELEMENT bind EMPTY>
<!ELEMENT unbind EMPTY>
<!ELEMENT all EMPTY>
<!-- Principal Properties (Section 4) -->
<!ELEMENT principal EMPTY>
<!ELEMENT alternate-URI-set (href*)>
<!ELEMENT principal-URL (href)>
<!ELEMENT group-member-set (href*)>
<!ELEMENT group-membership (href*)>
<!-- Access Control Properties (Section 5) -->
<!-- DAV:owner Property (Section 5.1) -->
<!ELEMENT owner (href?)>
<!-- DAV:group Property (Section 5.2) -->
<!ELEMENT group (href?)>
<!-- DAV:supported-privilege-set Property (Section 5.3) -->
<!ELEMENT supported-privilege-set (supported-privilege*)>
<!ELEMENT supported-privilege
(privilege, abstract?, description, supported-privilege*)>
<!ELEMENT privilege ANY>
<!ELEMENT abstract EMPTY>
<!ELEMENT description #PCDATA>
<!-- DAV:current-user-privilege-set Property (Section 5.4) -->
<!ELEMENT current-user-privilege-set (privilege*)>
<!-- DAV:acl Property (Section 5.5) -->
<!ELEMENT acl (ace)* >
<!ELEMENT ace ((principal | invert), (grant|deny), protected?,
inherited?)>
<!ELEMENT principal (href) | all | authenticated | unauthenticated | property | self)>
<！要素プリンシパル（HREF）|すべて|認証|認識されていない|プロパティ|自己）>
<!ELEMENT all EMPTY>
<!ELEMENT authenticated EMPTY>
<!ELEMENT unauthenticated EMPTY>
<!ELEMENT property ANY>
<!ELEMENT self EMPTY>
<!ELEMENT invert principal>
<!ELEMENT grant (privilege+)>
<!ELEMENT deny (privilege+)>
<!ELEMENT privilege ANY>
<!ELEMENT protected EMPTY>
<!ELEMENT inherited (href)>
<!-- DAV:acl-restrictions Property (Section 5.6) -->
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
<！要素ACL-RESTRICTIONS（Grant-Only？、No Invert？、deny-be-be-grant？、必要なprincipal？）>
<!ELEMENT grant-only EMPTY>
<!ELEMENT no-invert EMPTY>
<!ELEMENT deny-before-grant EMPTY>
<!ELEMENT required-principal
(all? | authenticated? | unauthenticated? | self? | href*
|property*)>
<!-- DAV:inherited-acl-set Property (Section 5.7) -->
<!ELEMENT inherited-acl-set (href*)>
<!-- DAV:principal-collection-set Property (Section 5.8) -->
<!ELEMENT principal-collection-set (href*)>
<!-- Access Control and Existing Methods (Section 7) -->
<!ELEMENT need-privileges (resource)* >
<!ELEMENT resource ( href, privilege )
<!-- ACL method preconditions (Section 8.1.1) -->
<!ELEMENT no-ace-conflict EMPTY>
<!ELEMENT no-protected-ace-conflict EMPTY>
<!ELEMENT no-inherited-ace-conflict EMPTY>
<!ELEMENT limited-number-of-aces EMPTY>
<!ELEMENT grant-only EMPTY>
<!ELEMENT no-invert EMPTY>
<!ELEMENT deny-before-grant EMPTY>
<!ELEMENT no-abstract EMPTY>
<!ELEMENT not-supported-privilege EMPTY>
<!ELEMENT missing-required-principal EMPTY>
<!ELEMENT recognized-principal EMPTY>
<!ELEMENT allowed-principal EMPTY>
<!-- REPORTs (Section 9) -->
<!ELEMENT acl-principal-prop-set ANY> ANY value: a sequence of one or more elements, with at most one DAV:prop element.
<！要素ACL-PRINCIPAL-PROP-SET ANY> ANY値：1つ以上の要素のシーケンス、最大で1つのDAV：PROP要素。
<!ELEMENT principal-match ((principal-property | self), prop?)>
<!ELEMENT principal-property ANY>
ANY value: an element whose value identifies a property. The
expectation is the value of the named property typically contains
an href element that contains the URI of a principal
<!ELEMENT self EMPTY>
<!ELEMENT principal-property-search ((property-search+), prop?) >
<!ELEMENT property-search (prop, match) >
<!ELEMENT match #PCDATA >
<!ELEMENT principal-search-property-set (
principal-search-property*) >
<!ELEMENT principal-search-property (prop, description) >
<!ELEMENT description #PCDATA >
Appendix B. WebDAV Method Privilege Table (Normative)
付録B. webdavメソッド特権テーブル（規範）
The following table of WebDAV methods (as defined in RFC 2518, 2616, and 3253) clarifies which privileges are required for access for each method. Note that the privileges listed, if denied, MUST cause access to be denied. However, given that a specific implementation MAY define an additional custom privilege to control access to existing methods, having all of the indicated privileges does not mean that access will be granted. Note that lack of the indicated privileges does not imply that access will be denied, since a particular implementation may use a sub-privilege aggregated under the indicated privilege to control access. Privileges required refer to the current resource being processed unless otherwise specified.
次のWebDAVメソッドの表（RFC 2518、2616、および3253で定義されている）は、各メソッドのアクセスに必要な特権を明確にしています。リストされている特権は、拒否された場合、アクセスを拒否されなければならないことに注意してください。ただし、特定の実装が既存のメソッドへのアクセスを制御するための追加のカスタム特権を定義する可能性があることを考えると、指定されたすべての特権を持つことは、アクセスが許可されることを意味しません。特定の実装では、アクセスを制御するために示された特権の下で集約されたサブプリビレジを使用する可能性があるため、指定された特権の欠如はアクセスが拒否されることを意味しないことに注意してください。特権が必要な特権は、特に指定されていない限り、処理中の現在のリソースを参照してください。
+---------------------------------+---------------------------------+
| METHOD | PRIVILEGES |
+---------------------------------+---------------------------------+
| GET | <D:read> |
| HEAD | <D:read> |
| OPTIONS | <D:read> |
| PUT (target exists) | <D:write-content> on target |
| | resource |
| PUT (no target exists) | <D:bind> on parent collection |
| | of target |
| PROPPATCH | <D:write-properties> |
| ACL | <D:write-acl> |
| PROPFIND | <D:read> (plus <D:read-acl> and |
| | <D:read-current-user-privilege- |
| | set> as needed) |
| COPY (target exists) | <D:read>, <D:write-content> and |
| | <D:write-properties> on target |
| | resource |
| COPY (no target exists) | <D:read>, <D:bind> on target |
| | collection |
| MOVE (no target exists) | <D:unbind> on source collection |
| | and <D:bind> on target |
| | collection |
| MOVE (target exists) | As above, plus <D:unbind> on |
| | the target collection |
| DELETE | <D:unbind> on parent collection |
| LOCK (target exists) | <D:write-content> |
| LOCK (no target exists) | <D:bind> on parent collection |
| MKCOL | <D:bind> on parent collection |
| UNLOCK | <D:unlock> |
| CHECKOUT | <D:write-properties> |
| CHECKIN | <D:write-properties> |
| REPORT | <D:read> (on all referenced |
| | resources) |
| VERSION-CONTROL | <D:write-properties> |
| MERGE | <D:write-content> |
| MKWORKSPACE | <D:write-content> on parent |
| | collection |
| BASELINE-CONTROL | <D:write-properties> and |
| | <D:write-content> |
| MKACTIVITY | <D:write-content> on parent |
| | collection |
+---------------------------------+---------------------------------+
Index
索引
A ACL method 40
ACLメソッド40
C Condition Names DAV:allowed-principal (pre) 42 DAV:deny-before-grant (pre) 41 DAV:grant-only (pre) 41 DAV:limited-number-of-aces (pre) 41 DAV:missing-required-principal (pre) 42 DAV:no-abstract (pre) 41 DAV:no-ace-conflict (pre) 41 DAV:no-inherited-ace-conflict (pre) 41 DAV:no-invert (pre) 41 DAV:no-protected-ace-conflict (pre) 41 DAV:not-supported-privilege (pre) 42 DAV:number-of-matches-within-limits (post) 48, 53 DAV:recognized-principal (pre) 42
-Principal（Pre）42 Dav：Abstract no-Abstract（pre）41 dav：no-ace-conflict（pre）41 dav：no-inherited-ace-conflict（pre）41 dav：no-invert（pre）41 dav：保護されていないACE紛争（PRE）41 DAV：サポートされていないプリビレジ（PRE）42 DAV：マッチ数（POST）48、53 DAV：認識されているプリンシパル（PRE）42
D DAV header compliance class 'access-control' 38 DAV:acl property 23 DAV:acl-principal-prop-set report 48 DAV:acl-restrictions property 27 DAV:all privilege 13 DAV:allowed-principal precondition 42 DAV:alternate-URI-set property 14 DAV:bind privilege 12 DAV:current-user-privilege-set property 21 DAV:deny-before-grant precondition 41 DAV:grant-only precondition 41 DAV:group property 18 DAV:group-member-set property 14 DAV:group-membership property 14 DAV:inherited-acl-set property 29 DAV:limited-number-of-aces precondition 41 DAV:missing-required-principal precondition 42 DAV:no-abstract precondition 41 DAV:no-ace-conflict precondition 41 DAV:no-inherited-ace-conflict precondition 41 DAV:no-invert precondition 41 DAV:no-protected-ace-conflict precondition 41 DAV:not-supported-privilege precondition 42 DAV:number-of-matches-within-limits postcondition 48, 53 DAV:owner property 15 DAV:principal resource type 13 DAV:principal-collection-set property 30 DAV:principal-match report 50 DAV:principal-property-search 51 DAV:principal-search-property-set 56 DAV:principal-URL property 14 DAV:read privilege 10 DAV:read-acl privilege 11 DAV:read-current-user-privilege-set privilege 12 DAV:recognized-principal precondition 42 DAV:supported-privilege-set property 18 DAV:unbind privilege 12 DAV:unlock privilege 11 DAV:write privilege 10 DAV:write-acl privilege 12 DAV:write-content privilege 10 DAV:write-properties privilege 10
D DAVヘッダーコンプライアンスクラス 'Access-Control' 38 DAV：ACLプロパティ23 DAV：ACL-PRINCIPAL-PROP-SET REPORT 48 DAV：ACL-RESTRICTIONS PROPERTY 27 DAV：ALL特権13 DAV：許可されたプリンシパルの前提条件42 DAV：代替-URI-SETプロパティ14 DAV：Bind Privilege 12 Dav：Current-User-Privilege-Set Property 21 Dav：拒否前の前提条件41 Dav：Grant Only Precondition 41 Dav：Group Property 18 Dav：Group-Memble-Set Property14 DAV：グループメンバーシッププロパティ14 DAV：継承されたACL-SETプロパティ29 DAV：Limited-Number-Number-Number-Number-Number-Number-Number-Number-Number-Number-Number-Number Precondition 41 Dav：Missing-Required-Principal Precondition 42 DAV：Abstract Precondition 41 Dav：No-ace--競合の前提条件41 DAV：無毛網の紛争前処理41 DAV：非偏dyな前処理41 DAV：無保護 - ACE紛争前処理41 DAV：サポートされていないプリビレゲの前提条件42 DAV：-limits postcondition 48、53 dav：所有者プロパティ15 Dav：プリンシパルリソースタイプ13 DAV：プリンシパルコレクションセットプロパティ30 DAV：プリンシパルマッチレポート50 DAV：プリンシパルプロパティ - 検索51 DAV：プリンシパル - サクロパティセット56 DAV：プリンシパルURLプロパティ14 DAV：Read Privilege 10 Dav：Read-ACL特権11 Dav：Read-Current-User-Privilege-Set特権12 Dav：認識されたPrincipal Precondition 42 Dav：サポートされるPrivilege-Set Property 18 Dav：Unbind特権12 Dav：ロック解除特権11 Dav：Write Privilege 10 Dav：Write-Acl Privilege 12 Dav：Write-Content Privilege 10 Dav：Write-Properties Privilege 10
M Methods ACL 40
MメソッドACL 40
P Privileges DAV:all 13 DAV:bind 12 DAV:read 10 DAV:read-acl 11 DAV:read-current-user-privilege-set 12 DAV:unbind 12 DAV:unlock 11 DAV:write 10 DAV:write-acl 12 DAV:write-content 11 DAV:write-properties 10 Properties DAV:acl 23 DAV:acl-restrictions 27 DAV:alternate-URI-set 14 DAV:current-user-privilege-set 21 DAV:group 18 DAV:group-member-set 14 DAV:group-membership 14 DAV:inherited-acl-set 29 DAV:owner 15 DAV:principal-collection-set 30 DAV:principal-URL 14 DAV:supported-privilege-set 18
P特権dav：すべて13 Dav：バインド12 dav：read 10 dav：read-acl 11 dav：read-current-user-privilege-set 12 dav：un-bind 12 dav：nollock 11 dav：write 10 dav：write-acl 12DAV：書き込みコンテンント11 DAV：書き込みプロパティ10プロパティDAV：ACL 23 DAV：ACL-RESTRICTIONS 27 DAV：Alternate-URI-Set 14 DAV：Current-User-Privilege-Set 21 Dav：Group 18 Dav：Group-Member-set 14 dav：グループメンバーシップ14 Dav：継承acl-set 29 dav：所有者15 dav：プリンシパルコレクションセット30 dav：プリンシパル-url 14 dav：supported-privilege-set 18
R Reports DAV:acl-principal-prop-set 47 DAV:principal-match 49 DAV:principal-property-search 51 DAV:principal-search-property-set 56 Resource Types DAV:principal 13
RレポートDAV：ACL-PRINCIPAL-PROP-SET 47 DAV：プリンシパルマッチ49 DAV：プリンシパルプロパティ - 検索51 DAV：プリンシパル - サクロッパ-Set 56リソースタイプDAV：プリンシパル13
Authors' Addresses
著者のアドレス
Geoffrey Clemm IBM 20 Maguire Road Lexington, MA 02421
Geoffrey Clemm IBM 20 Maguire Road Lexington、MA 02421
EMail: geoffrey.clemm@us.ibm.com
Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany
Julian F. Reschke Greenbytes Gmbh Salzmannstrasse 152 Muenster、NW 48159ドイツ
EMail: julian.reschke@greenbytes.de
Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065
エリックセドラーオラクルコーポレーション500オラクルパークウェイレッドウッドショアーズ、カリフォルニア94065
EMail: eric.sedlar@oracle.com
Jim Whitehead U.C. Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064
ジムホワイトヘッドU.C.サンタクルーズ、コンピューターサイエンス部1156ハイストリートサンタクルス、カリフォルニア95064
EMail: ejw@cse.ucsc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
Copyright（c）The Internet Society（2004）。この文書は、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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
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エディター機能の資金は現在、インターネット協会によって提供されています。