[要約] RFC 3744は、WebDAVプロトコルを拡張し、リソース（ファイルやフォルダ）に対する詳細な「アクセス制御 (Access Control)」をサーバー側で直接管理するためのプロトコルを定義しています。アクセス制御リスト（ACL）の取得と更新、ユーザーやグループの権限設定、および現在のアクセス許可を確認するためのHTTPメソッドとプロパティを規定しています。ウェブ上の共有作業環境において、標準化された手順できめ細かなセキュリティポリシーを適用し、安全な共同編集を実現することを目的としています。
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.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定し、改善に向けた議論や提案を求めます。このプロトコルの標準化上の状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。この文書の配布に制限はありません。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
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アクセス制御拡張の目的は、WebDAVサーバーが管理するコンテンツおよびメタデータに対する任意アクセス制御を扱う、相互運用可能な仕組みを提供することです。WebDAVアクセス制御は、UNIXファイルシステム程度の単純なセキュリティを備えたコンテンツリポジトリにも、より高度なモデルにも実装できます。アクセス制御の基本原則は、主体が誰であるかによって、リソース上で実行できる操作が決まることです。「主体が誰であるか」はプリンシパル識別子で表し、ユーザー、クライアントソフトウェア、サーバー、およびそれらを構成するグループがプリンシパル識別子を持ちます。「実行できる操作」は、リソースに関連付けられた1つのアクセス制御リスト（ACL）によって決まります。ACLにはアクセス制御エントリ（ACE）が複数含まれ、各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にはプリンシパルの識別子が含まれるため、人が操作するクライアントソフトウェアには、そのプリンシパルを選択する仕組みが必要です。この仕様では、WebDAV対応リソースとして表されるプリンシパルを識別するために、http(s)スキームのURLを使用します。プリンシパルを識別する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 に読み取り特権を付与するACEが、http://www.example.com/u/256432 のプリンシパルにも影響するかどうかをクライアントが判断することはできません。つまり、2つのURLが同じプリンシパルリソースを指すかをクライアントが判断する仕組みはありません。そのため、この仕様では、ACEを作成するときにクライアントが各プリンシパルに対して多数の候補URLのうち1つだけを使うよう求めています。プリンシパルリソースからDAV:principal-URLプロパティ（セクション4.2）を取得すれば、使用するURLを確認できます。PROPFINDでどのURLを指定しても、このプロパティは常に同じ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）のコレクションを置き、次の階層にも36個置く2階層構造では、/a/a/、/a/b/、..., /a/z/のようなコレクションができます。この場合、姓が「Stein」のプリンシパルは/s/t/Steinに配置されます。これは、姓による検索という一般的なクエリをあらかじめ階層に符号化する方法です。この方式では、事前定義された少数のクエリしか扱えず、利用者がすでにプリンシパル名を知っている場合にも、コレクション階層を下りたり上ったりする余分な手順が生じます。プリンシパル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).
この仕様では、プリンシパルを表すリソース上の限られたプロパティについて、部分文字列検索を行えます。これにより、姓、名、ユーザー名、役職などに基づく検索が可能です。REPORTメソッドによる検索を2種類サポートします。1つはプリンシパルリソースを検索するもの（DAV:principal-property-search、セクション9.4）、もう1つは検索対象にできるプロパティを調べるもの（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内のプリンシパルが特定された後、ACEを評価するサーバーは、プロトコル要求を行ったプリンシパルの識別情報を把握し、そのプリンシパルが主張どおりの主体であることを確認する必要があります。この確認は認証と呼ばれます。HTTPプロトコルにはすでに複数の認証方式があるため[RFC2617]、この仕様では認証について意図的に扱いません。プリンシパルの識別情報を確認するには、何らかの認証方式を利用できる必要があります。たとえばHTTP Digest Authenticationがあり、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で説明します。OPTIONSを使ってクライアントがアクセス制御機能を確認する方法はセクション7.2で説明します。アクセス制御機能と既存のHTTPおよびWebDAVメソッドとの連携は、セクション7の残りの部分で扱います。アクセス制御を設定するACLメソッドはセクション8で規定します。サーバー側の限定的な検索機能を提供する4種類のレポートはセクション9で説明します。セクション10のXML処理、セクション11の国際化に関する考慮事項、セクション12のセキュリティに関する考慮事項、およびセクション13の認証で仕様を締めくくります。付録Aには、この仕様で定義するXML要素のXML文書型定義（DTD）を示します。
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.
「ACE」は、特定のプリンシパルに対する特定の（抽象でない）特権群を付与または拒否します。
inherited ACE
継承された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.
「継承されたACE」とは、別のリソースのACLから動的に共有されるACEです。元のリソースで共有ACEが変更されると、それを継承するリソース上でも変更されます。
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.
「保護されたプロパティ」とは、そのプロパティ自体を更新すると明示的に定義されたメソッド以外では値を更新できないプロパティです。特に、保護されたプロパティはPROPPATCH要求では更新できません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書で使うキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」および「OPTIONAL」は、[RFC2119]に記載された意味で解釈します。
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要素を定義する際は、[REC-XML]のセクション3.2で説明されるXML要素型宣言（XML文書型宣言に現れるもの）を使用します。XMLフラグメントの外で「DAV:」名前空間の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スキームをプリンシパルリソースの識別に使用できます (MAY)。ただし、この仕様を実装するサーバーは、セクション4に記載される追加プロパティを持つリソースを指す特権スキームであるhttp(s) URL上に、プリンシパルリソースを公開しなければなりません (MUST)。したがって、プリンシパルリソースは複数のURIを持つことができ、そのうち少なくとも1つはhttp(s)スキームのURLである必要があります。実装は、プリンシパル情報へのアクセスにPROPFINDをサポートすべきです (SHOULD)。また、その情報へのアクセスと変更にPROPPATCHをサポートしてもかまいません (MAY)。ただし、これらのメソッドのサポートは必須ではありません。
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つ以上の特権によって制御しなければなりません (MUST)。新しいHTTPメソッドを定義するプロトコル拡張の作成者は、そのメソッドの実行に必要な特権を指定すべきです (SHOULD)。そのために新しい特権を定義するか、以下に示す既存の特権へ対応付けます。リソースに対する特権を持たないプリンシパルには、そのリソースへのHTTPアクセスを一切拒否しなければなりません (MUST)。ただし、DAV:all、DAV:authenticated、またはDAV:unauthenticated疑似プリンシパルを使って構成したACEに該当する場合を除きます（セクション5.5.1を参照）。アクセスを拒否した場合、サーバーは403「Forbidden」エラーを返さなければなりません (MUST)。ただし、その特権がリソースの存在を知る能力も制限する場合は例外であり、その場合は404「Not Found」を返してもかまいません。
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-member特権とremove-member特権を定義できます。これらはグループの状態を更新する能力を制御するため、グループのDAV:write特権に集約されます。グループにDAV:writeを付与すると、add-memberとremove-memberも付与されます。
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.
特定のリソースに対する特権を「抽象」と宣言すると、そのリソース上のACEには設定できません。集約特権と非集約特権のどちらも抽象にできます。抽象特権は、通常ならプロトコルを通じて公開しない特権をモデル化するときに役立ちます。また、この仕様で定義した特権の実装に柔軟性を与えます。たとえば、サーバーがリソースの読み取り能力とACLの読み取り能力を分離できない場合でも、DAV:readとDAV:read-aclを抽象として宣言し、両方を保持するread-allなどの非抽象集約特権に含めれば、この仕様の2つの特権をモデル化できます。この方法ではread-allを設定してDAV:readとDAV:read-aclを連動させることはできますが、個々に設定することはできません。集約特権自体も抽象にできるため、抽象特権を使って非抽象特権をグループ化・整理することもできます。特権の包含関係にループを作ることは許されません。したがって、特権は自分自身を包含してはなりません (MUST NOT)。たとえば、DAV:readがDAV:readを包含することはできません。
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:read、DAV:write、DAV:read-acl、DAV:write-acl、DAV:read-current-user-privilege-set、DAV:allなど）を定義します。これらは少なくとも、個々のリソースに定義された他の特権を分類するために使用できます。ヌルリソース（[RFC2518]のセクション3で定義）のアクセス許可は、継承したものがあればそれだけであり、発見可能ではありません。つまり、セクション5で規定するアクセス制御プロパティはヌルリソース上に定義されません。ヌルリソースから状態を持つリソースへ移行するとき、初期ACLはサーバーの既定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.
サーバー実装は、この仕様で定義するもの以外の特権を定義してもかまいません (MAY)。個々の実装が定義する特権ではDAV:名前空間を使用してはなりません (MUST NOT)。代わりに、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.
read特権は、リソースのプロパティを含む状態情報を返すメソッドを制御します。対象メソッドにはGETとPROPFINDがあります。GETとPROPFINDへのアクセスも制御する実装固有の特権は、DAV:readの下に集約しなければなりません。ACLがDAV:readへのアクセスを許可する場合、クライアントはGETおよびPROPFINDへのアクセスに他の特権の付与が不要だと期待できます。さらに、read特権はOPTIONSメソッドを制御しなければなりません (MUST)。
<!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特権は、リソースをロックするメソッドや、PUTやPROPPATCHなど、リソースのコンテンツ、デッドプロパティ、または（コレクションの場合）メンバーシップを変更するメソッドを制御します。状態の変更はロックによっても制御されるため（[RFC2518]のセクション5.3を参照）、実効的な書き込みアクセスには、書き込み特権と書き込みロックの要件の両方を満たす必要があります。コンテンツ、デッドプロパティ、またはコレクションのメンバーシップを変更するメソッドへのアクセスも制御する実装固有の特権は、DAV:writeの下に集約する必要があります。たとえば、ACLがDAV:writeへのアクセスを許可する場合、クライアントは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.
DAV:write-properties特権は、PROPPATCHなど、リソースのデッドプロパティを変更するメソッドを制御します。この特権をライブプロパティへのアクセス制御にも使えるかどうかは、実装によって決まります。デッドプロパティを変更するメソッドへのアクセスも制御する実装固有の特権は、DAV:write-propertiesの下に集約する必要があります。たとえば、ACLがDAV:write-propertiesへのアクセスを許可する場合、クライアントはPROPPATCHへのアクセスに他の特権の付与は不要だと安全に期待できます。
<!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.
DAV:write-content特権は、PUTなど、既存リソースのコンテンツを変更するメソッドを制御します。コンテンツへのアクセスも制御する実装固有の特権は、DAV:write-contentの下に集約する必要があります。たとえば、ACLがDAV:write-contentへのアクセスを許可する場合、クライアントはPUTへのアクセスに他の特権の付与は不要だと安全に期待できます。PUTをマッピングされていないURIに適用すると新しいリソースが作成されるため、その場合は親コレクション上のDAV:bind特権によって制御されます。
<!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.
DAV:unlock特権は、ロック所有者以外のプリンシパルがUNLOCKメソッドを使用する場合のアクセスを制御します（ロックを作成したプリンシパルは常にUNLOCKを実行できます）。リソースをロックできる利用者と変更できる利用者は通常同じですが、サーバーは各種管理者に、他者がロックしたリソースのロック解除を許可することがあります。ロック所有者以外の利用者によるUNLOCKへのアクセスを制御する特権は、DAV:unlockの下に集約しなければなりません (MUST)。
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.
ロック所有者は、正しいロックトークンと認証資格情報を付けてUNLOCKを要求すれば、常にロックを解除できます。つまり、プリンシパルがDAV:unlock特権を持たなくても、自分が所有するロックは解除できます。ロック所有者以外のプリンシパルがロックを解除できるのは、DAV:unlock特権を持ち、正しいロックトークンを付けてUNLOCKを要求する場合に限ります。ロックのタイムアウトはDAV:unlock特権の影響を受けません。
<!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-user-privilege-set特権は、PROPFINDを使ってリソースのDAV:current-user-privilege-setプロパティを取得する操作を制御します。
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.
この特権をDAV:read-aclから分けているのは、UIの作成に使うため、現在のユーザーに許可されている特権には大半のユーザーがアクセスできるようにする必要がある一方、完全な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.
DAV:bind特権を使うと、指定したコレクションに新しいメンバー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を削除するメソッドを実行できます（DELETEやMOVEなど）。コレクション以外のリソースでは、この特権は無視されます。
<!ELEMENT unbind EMPTY>
DAV:all is an aggregate privilege that contains the entire set of privileges that can be applied to the resource.
DAV:allは、そのリソースに適用できるすべての特権を含む集約特権です。
<!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:
サーバー実装は、次の制約に従う限り、上記セクション3.1～3.10で定義した特権を自由に集約できます。
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、DAV:write-acl、DAV:write-properties、DAV:write-content、またはDAV:read-current-user-privilege-setを包含してはなりません (MUST NOT)。
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を包含してはなりません (MUST NOT)。
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を包含してはなりません (MUST NOT)。
DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-current-user-privilege-set.
DAV:writeは、DAV:read、DAV:read-acl、またはDAV:read-current-user-privilege-setを包含してはなりません (MUST NOT)。
DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-properties, or DAV:write-content.
DAV:readは、DAV:write、DAV:write-acl、DAV:write-properties、またはDAV:write-contentを包含してはなりません (MUST NOT)。
DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and DAV:write-content.
DAV:writeは、DAV:bind、DAV:unbind、DAV:write-properties、およびDAV:write-contentを包含しなければなりません (MUST)。
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:
<!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]).
<!ELEMENT principal EMPTY> このプロトコルでは、プリンシパル向けに次の追加プロパティを定義します。サーバーがアクセス制御情報を取得すると高コストになる場合があるため、PROPFIND allprop要求（[RFC2518]のセクション12.14.1で定義）に対して、これらのプロパティ名と値を返すべきではありません (SHOULD NOT)。
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]を使ってプリンシパルに関する追加の機械可読なディレクトリ情報を取得し、ユーザーインターフェイスに表示できます。このプロパティはサポートしなければなりません (REQUIRED)。プリンシパルに代替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が格納されます (MUST)。このプロパティはサポートしなければなりません (REQUIRED)。
<!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:group-member-set内にあるURLは、そのプリンシパルのDAV:principal-URLでなければなりません (MUST)。
<!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:group-membershipを照会する必要があります。このプロパティはサポートしなければなりません (REQUIRED)。
<!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で定義）は、このセクションで定義するプロパティの名前と値を返すべきではありません (SHOULD NOT)。
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:inherited-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リソースには、次のプロパティを含めなければなりません (MUST)。ヌルリソース（[RFC2518]のセクション3で説明）には、次のプロパティを含めてはなりません (MUST NOT)。
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:ownerを保護されたプロパティとして実装してもかまいません (MAY)。所有者情報がない場合、プロパティ値として空のDAV:owner要素を返してもかまいません (MAY)。
<!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:ownerプロパティの値を要求するクライアント要求を示します。要求元のプリンシパルはDigest認証を使って認証されています。DAV:ownerの値は、DAV:href XML要素に格納されたURL http://www.example.com/acl/users/gstein です。
>> 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:ownerプロパティの値を変更するクライアント要求を示します。このサーバーではDAV:ownerが保護されたプロパティであるため、DAV:ownerの設定に対する403（Forbidden）ステータスコードを含む207（Multi-Status）応答を返します。[RFC2518]のセクション8.2.1ではPROPPATCHのステータスコード情報を、同セクション11ではMulti-Status応答を説明しています。また、[RFC3253]のセクション1.6および3.12では、保護されたプロパティに対するPROPPATCH要求で追加されるエラー情報を説明しています。
>> 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を保護されたプロパティとして実装してもかまいません (MAY)。グループ情報がない場合、プロパティ値として空のDAV:group要素を返してもかまいません (MAY)。
<!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で使用してはなりません (MUST NOT)。サーバーは、抽象特権を設定する要求を失敗させなければなりません (MUST)。
<!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属性を使って説明文の言語を示さなければなりません (MUST)。複数の言語で説明を提供する場合、選択時にHTTPのAccept-Language要求ヘッダーを考慮すべきです (SHOULD)。
<!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:supported-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 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: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ユーザーに付与された特権の正確な集合を格納する保護されたプロパティです。この集合はサーバーが計算し、集約特権とそれに含まれる特権の両方を列挙します。ユーザーエージェントはこのプロパティの値を使い、現在のプリンシパルに許可されていない操作をUI上で無効化できます（たとえば、メニュー項目やボタンをグレー表示します）。このプロパティを使えば、実際に操作を実行しなくても、現在のプリンシパルが実行できる操作を確認できます。
<!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.
<!ELEMENT current-user-privilege-set (privilege*)> <!ELEMENT privilege ANY> 現在のユーザーに特定の特権が付与されている場合、その特権はこのリソースに設定可能な特権の集合に含まれている必要があります。したがって、DAV:current-user-privilege-setプロパティの各要素は、DAV:supported-privilege-setプロパティに含まれる抽象でない特権を示さなければなりません (MUST)。
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特権が付与されています。DAV:readにはDAV:read-aclとDAV:read-current-user-privilege-setが含まれるため（セクション5.3.1を参照）、このプリンシパルはACLプロパティとDAV:current-user-privilege-setプロパティを読み取れます。ただし、この例ではDAV:all、DAV:read-acl、DAV:write-acl、およびDAV:read-current-user-privilege-setは抽象特権であるため、DAV:current-user-privilege-setの値には列挙されません。ユーザー名「khare」のプリンシパルは、書き込みを許可するACEに記載されていないため、DAV:writeも列挙されません。
>> 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.
この保護されたプロパティはアクセス制御エントリ（ACE）の一覧を指定します。各ACEは、このリソースについてどのプリンシパルにどの特権を与えるかを定義します。
<!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:principal要素は、このACEの適用対象となるプリンシパルを示します。
<!ELEMENT principal (href | all | authenticated | unauthenticated | property | self)>
<!ELEMENT principal (href | all | authenticated | unauthenticated | property | self)>
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に該当するのは、そのユーザーがDAV:hrefに含まれるURLで識別されるプリンシパル本人、またはそのプリンシパルのメンバーとして認証されている場合に限ります。
The current user always matches DAV:all.
現在のユーザーは常にDAV:allに該当します。
<!ELEMENT all EMPTY>
The current user matches DAV:authenticated only if authenticated.
現在のユーザーがDAV:authenticatedに該当するのは、認証済みの場合に限ります。
<!ELEMENT authenticated EMPTY>
The current user matches DAV:unauthenticated only if not authenticated.
現在のユーザーがDAV:unauthenticatedに該当するのは、未認証の場合に限ります。
<!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:allはDAV:authenticatedとDAV:unauthenticatedの和集合です。各要求について、ユーザーはDAV:authenticatedかDAV:unauthenticatedのどちらか一方に該当し、両方には該当しません（つまり、この2つは互いに素な集合です）。
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.
現在のユーザーがリソースのDAV:aclプロパティ内にあるDAV:propertyプリンシパルに該当するには、識別対象プロパティの値に含まれるDAV:href XML要素が最大1つであり、そのDAV:hrefのURI値がプリンシパルを示し、現在のユーザーがそのプリンシパル本人またはそのメンバーとして認証されている必要があります。たとえば、DAV:property要素に<DAV:owner/>が含まれる場合、リソースのDAV:ownerプロパティで識別されるプリンシパル本人として現在のユーザーが認証されている場合に限り、DAV:propertyプリンシパルに該当します。
<!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:aclプロパティ内にあるDAV:selfに該当するのは、そのリソースがプリンシパルであり、そのプリンシパルが現在のユーザーに該当する場合に限ります。プリンシパルがグループである場合は、そのグループのメンバーのいずれかが現在のユーザーに該当すれば、DAV:selfに該当します。
<!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:principal要素をDAV:invertで囲むことで実現できます。
<!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要素は、指定したプリンシパルに付与または拒否する特権の集合を示します。リソースのDAV:acl内にあるDAV:grant要素またはDAV:deny要素には、そのリソースのDAV:supported-privilege-setに定義された抽象でない要素だけを含めなければなりません (MUST)。
<!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内にDAV:protected要素を含めることで、そのACEが保護されていることを示します。リソースのACLにDAV:protected要素を含むACEがある場合、そのACEをACLから削除する要求は失敗しなければなりません (MUST)。
<!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:inherited要素があることは、このACEが別のリソースから継承されたことを示します。そのリソースはDAV:href要素内のURLで識別されます。継承されたACEを直接変更することはできません。代わりに、継承元リソース上の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を指します。ACEを含むリソースを更新すると、その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/groups/maintainersで識別されるグループ（サイト保守担当者のグループ）にDAV:write特権を付与します。この例ではDAV:writeにDAV:write-aclが含まれるため（セクション5.3.1を参照）、maintainersグループはアクセス制御リストも変更できます。
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.
ACE #2：すべてのプリンシパル（DAV:all）にDAV:read特権を付与します。この例ではDAV:readにDAV:read-aclとDAV:read-current-user-privilege-setが含まれるため、すべてのユーザー（maintainersグループの全メンバーを含む）がDAV:aclプロパティと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> 拒否ACEはサポートされません。
<no-invert> Inverted ACEs are not supported
<no-invert> 反転ACEはサポートされません。
<deny-before-grant> All deny ACEs must occur before any grant ACEs
<deny-before-grant> すべての拒否ACEは、許可ACEのいずれよりも前に置く必要があります。
<required-principal> Indicates which principals are required to be present
<required-principal> 必ず含めなければならないプリンシパルを示します。
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
This element indicates that ACEs with deny clauses are not allowed.
この要素は、拒否節を含むACEが許可されないことを示します。
<!ELEMENT grant-only EMPTY>
This element indicates that ACEs with the <invert> element are not allowed.
この要素は、<invert>要素を含むACEが許可されないことを示します。
<!ELEMENT no-invert EMPTY>
This element indicates that all deny ACEs must precede all grant ACEs.
この要素は、すべての拒否ACEをすべての許可ACEより前に置く必要があることを示します。
<!ELEMENT deny-before-grant EMPTY>
The required principal elements identify which principals must have an ACE defined in the ACL.
必須プリンシパル要素は、ACLにACEを定義しておく必要があるプリンシパルを示します。
<!ELEMENT required-principal
(all? | authenticated? | unauthenticated? | self? | href* |
property*)>
For example, the following element requires that the ACL contain a DAV:owner property ACE:
たとえば、次の要素は、ACLにDAV:ownerプロパティを対象とするACEを含めるよう要求します：
<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認証を使います。
>> 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（DAV:aclプロパティで指定）に加え、DAV:inherited-acl-set内で示された各リソースのACLも、その特権を付与している必要があります。つまり、現在のACLと各継承ACLがそれぞれ付与する特権の論理積が有効になります。
<!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:principal-collection-setの内容を使って、そのサーバー上の全プリンシパルについてDAV:displaynameプロパティ（[RFC2518]のセクション13.2で規定）を取得できます。これにより、各プリンシパルの人間可読名をUIに表示できます。
<!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:principal-collection-setの値が異なる場合があります (MAY)。DAV:principal-collection-setに指定するコレクションは、リソースとは別のホスト上にあってもかまいません (MAY)。DAV:principal-collection-set内のURLは、httpまたはhttpsスキームのURLであるべきです (SHOULD)。セキュリティと拡張性の理由から、サーバーは既知のプリンシパルコレクション全体ではなく、その一部だけを報告してもかまいません (MAY)。したがって、クライアントは取得した一覧が網羅的だと想定すべきではありません。さらに、サーバーは把握しているプリンシパルコレクションを1つも報告しないことを選んでもかまいません (MAY)。その場合、このプロパティの値は空になります。
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:principal-collection-setの値は、DAV:principal-property-search REPORT（セクション9.4で定義）の検索範囲を示します。クライアントはDAV:principal-property-search REPORTを使ってプリンシパル一覧を取得し、ユーザーインターフェイスに表示します。そのため、プリンシパル情報の取得を制限するサーバーは、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:principal-collection-setプロパティの値を要求します。このプロパティには、http://www.example.com/acl/users/とhttp://www.example.com/acl/groups/という2つのURLが含まれ、どちらもDAV:href XML要素に格納されています。クライアントを操作するプリンシパルの資格情報にはDigest認証を使います。
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つのPROPFIND要求を送り、2つのコレクション（/acl/usersおよび/acl/groups）のメンバーについてDAV:displaynameプロパティを取得できます。この情報は、アクセス制御エントリを作成するためのユーザーインターフェイスに表示できます。
>> 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:owner、DAV:supported-privilege-set、DAV:current-user-privilege-set、およびDAV:aclプロパティの値を取得し、アクセス制御情報を読み出す方法を示します。
>> 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: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> このリソースを所有するプリンシパルのURLは、DAV:ownerプロパティの値に含まれる単一の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:supported-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があります。
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/users/esedlarで識別されるプリンシパルに、DAV:read、DAV:write、および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/groups/mrktngで識別されるプリンシパルからDAV:read特権を拒否します。この例では、プリンシパル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.
ACE #3：このACEのプリンシパルは、プロパティプリンシパル、具体的にはDAV:ownerプロパティです。このACEを評価するとき、DAV:ownerプロパティの値を取得し、DAV:href XML要素が含まれているか確認します。含まれている場合は、その要素内のURLを読み取り、プリンシパルを識別します。このACEでは、所有者に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：このACEはDAV:allプリンシパル（全ユーザー）にDAV:read特権を付与します。このACEは、当該リソースの親コレクションである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]のACLと同様の方法で評価します。WebDAV要求へのアクセスを許可するかどうかを決めるためにACLを評価します。ACEは特定の順序で保持され、現在の要求に必要なすべてのアクセス許可が与えられるまで評価されます。すべての許可が得られると評価を終了し、アクセスを許可します。ACLの評価中、現在のユーザーに該当する<deny> ACEが、まだ付与されていない特権に対して見つかった場合、評価を終了してアクセスを拒否します。必要な特権がすべて付与されなければ、アクセスは拒否されます。
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と拒否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:allowed-principal>（上記ACLにないプリンシパルを指定するACEを追加する場合）や<D:ace-conflict>（上記例のACE順序を変更しようとする場合）など、<acl-restrictions>を守っていてもUNIXサーバーからエラーが返ることがあります。これらの実装固有の意味は複雑であり、単純ながら汎用的な宣言型の制約では表現できないためです。
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 <DAV:need-privileges> element, which contains one or more <DAV:resource> elements indicating which resource had insufficient privileges, and what the lacking privileges were:
WebDAV ACL機構では、すべてのHTTPメソッドについて、RFC 3253のセクション1.6で説明するHTTPメソッドの「事前条件」を使用します。すべてのHTTPメソッドにはDAV:need-privilegesという追加の事前条件があります。特権不足が原因でHTTPメソッドが失敗した場合、「403 Forbidden」エラーの応答本文には<DAV:error>要素を含めなければなりません (MUST)。この要素には<DAV:need-privileges>要素が含まれ、その要素には、特権が不足していたリソースと不足していた特権を示す<DAV:resource>要素が1つ以上含まれます。
<!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
MOVE /a/b/ HTTP/1.1 Host: www.example.com Destination: 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.
サーバーがアクセス制御をサポートする場合、そのサーバーが実装する任意のリソースに対するOPTIONS要求へのDAV応答ヘッダーに、access-controlをフィールドとして含めなければなりません (MUST)。DAVヘッダーの値access-controlは、この文書で指定するすべてのMUSTレベルの要件 (MUST) とREQUIRED機能 (MUST) をサーバーがサポートすることを示さなければなりません (MUST)。
>> Request <<
OPTIONS /foo.html HTTP/1.1 Host: www.example.com Content-Length: 0
OPTIONS /foo.html HTTP/1.1 Host: www.example.com Content-Length: 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, access-control Allow: OPTIONS, 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.
この例のOPTIONS応答は、サーバーがアクセス制御をサポートしていることと、/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.
MOVE要求でリソースを別の場所へ移動するとき、そのリソースのDAV:aclプロパティ内にある継承されておらず保護もされていないACEを変更してはなりません (MUST NOT)。変更するとMOVE要求は失敗します。継承された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.
COPY先のリソースのDAV:aclプロパティは、個別のリソース作成要求（MKCOLやPUTなど）で作成された場合と同じでなければなりません (MUST)。コピー後もDAV:aclプロパティを保持したいクライアントは、COPY前に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.
リソースをロックすると、ロック所有者だけが、継承されておらず保護もされていないACEを変更できます（クライアントがACL要求で変更できるのはこのACEだけです）。クライアントは当該リソースへのACL要求で継承されたACEや保護されたACEを変更できないため、ロックはそれらの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プロパティで読み取り可能）を変更します。具体的には、継承されておらず保護もされていないACEだけを変更できます。ACLメソッドを実行すると、リソースのアクセス制御リストにある継承されていないACEおよび保護されていないACEをすべて、要求本文のDAV:acl XML要素（セクション5.5で規定）に含まれるACEと完全に一致するよう変更します。ACL要求本文にはDAV:acl XML要素を1つだけ含めなければなりません (MUST)。ACL要求で指定された値に一致するようDAV:aclプロパティ内の継承されていないACEおよび保護されていないACEを更新できない場合、ACL要求は失敗しなければなりません (MUST)。
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プロパティで閲覧できるACEは、そのリソースに存在する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の変更を上書きしないよう、クライアントは更新予定のリソースからDAV:aclプロパティを取得する前に、そのリソースにWebDAVロックを取得すべきです (SHOULD)。
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.
実装上の注意：既存のアクセス制御リストにACEを追加または削除する操作はよく行われます。そのために、クライアントはPROPFINDメソッドでDAV:aclプロパティの値を取得し、返されたアクセス制御リストを解析して、継承されたACEと保護されたACEをすべて取り除きます（これらのACEにはDAV:inheritedおよびDAV:protected XML要素が付いています）。残った継承されておらず保護もされていないACEの集合に、クライアントは1つ以上のACEを追加または削除し、最終的なACEの集合をACLメソッドの要求本文で送信します。
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要求に対して次の制約を適用しなければなりません (MUST)。制約に違反した場合、403（Forbidden）または409（Conflict）応答を返さなければなりません (MUST)。また、XML応答本文内で、指定されたXML要素をトップレベルのDAV:error要素の子要素として返さなければなりません (MUST)。
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でもEMPTYと定義されていますが、実装は説明用の追加XML要素をステータス要素の子として返してもかまいません (MAY)。クライアントはステータス要素の子要素を受け入れられなければなりません (MUST)。追加の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要求で送信するACE同士が競合してはなりません (MUST NOT)。これは、実装固有の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:no-protected-ace-conflict)：ACL要求で送信するACEは、リソース上の保護されたACEと競合してはなりません (MUST NOT)。たとえば、リソース上の保護されたACEが特定のプリンシパルにDAV:writeを付与している場合、ACL要求で同じプリンシパルにDAV:writeを拒否するACEを送信すると整合しません。
(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-inherited-ace-conflict)：ACL要求で送信するACEは、リソース上の継承されたACEと競合してはなりません (MUST NOT)。たとえば、親コレクションからDAV:writeを特定のプリンシパルに付与するACEを継承しているリソースに対し、同じプリンシパルへのDAV:writeを拒否するACEをACL要求で送ると整合しません。このエラーを報告するかどうかは実装に依存します。実装は、このエラーを報告するか、ACEの設定を許可したうえで通常のACE評価規則を適用し、新しいACEが特定のプリンシパルに利用可能な特権に影響するか判断しなければなりません (MUST)。
(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:limited-number-of-aces)：ACL要求で送信するACEの数は、そのリソースで許可されるACEの数を超えてはなりません (MUST NOT)。ただし、ACL準拠サーバーは、単一プリンシパルに特権を付与するACEを少なくとも1つ、グループに特権を付与するACEを少なくとも1つサポートしなければなりません (MUST)。
(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all non-inherited grant ACEs.
(DAV:deny-before-grant)：継承されていないすべての拒否ACEは、継承されていないすべての許可ACEより前に置かなければなりません (MUST)。
(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要求で送信するACEに拒否ACEを含めてはなりません (MUST NOT)。この事前条件は、リソースのACL制約にDAV:grant-only制約（セクション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:invert要素を含めてはなりません (MUST NOT)。この事前条件は、リソースのACL意味論にDAV:no-invert制約（セクション5.6.2で定義）が含まれる場合に限って適用されます。
(DAV:no-abstract): The ACL request MUST NOT attempt to grant or deny an abstract privilege (see Section 5.3).
(DAV:no-abstract)：ACL要求で抽象特権を付与または拒否しようとしてはなりません (MUST NOT)（セクション5.3を参照）。
(DAV:not-supported-privilege): The ACEs submitted in the ACL request MUST be supported by the resource.
(DAV:not-supported-privilege)：ACL要求で送信するACEは、そのリソースがサポートする特権を使用しなければなりません (MUST)。
(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:missing-required-principal)：ACL要求の結果には、そのリソースのACL意味論にあるDAV:required-principal XML要素が示す各プリンシパルについて、少なくとも1つのACEがなければなりません (MUST)（セクション5.5を参照）。
(DAV:recognized-principal): Every principal URL in the ACL request MUST identify a principal resource.
(DAV:recognized-principal)：ACL要求に含まれるすべてのプリンシパルURLは、プリンシパルリソースを示さなければなりません (MUST)。
(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:allowed-principal)：ACL要求で送信するACEに指定されたプリンシパルは、そのリソースのプリンシパルとして許可されていなければなりません (MUST)。たとえば、認証済みプリンシパルだけがリソースにアクセスできるサーバーでは、DAV:allやDAV:unauthenticatedを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.
次の例では、Authorizationヘッダーの情報で認証されたユーザー「fielding」が、URL http://www.example.com/users/esedlarで識別されるプリンシパル（ユーザー「esedlar」）にreadおよびwrite特権を付与します。また、リソースの所有者にread-aclおよびwrite-acl特権を付与し、全員にread特権を付与します。
>> 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.
次の要求では、Authorizationヘッダーの情報で認証されたユーザー「fielding」が、URL http://www.example.com/users/esedlarで識別されるプリンシパル（ユーザー「esedlar」）へのwrite特権を拒否しようとします。要求前のDAV:aclプロパティには、DAV:ownerにDAV:readおよびDAV:write特権を付与する保護されたACEが含まれていました（セクション5.5.3を参照）。URL http://www.example.com/users/esedlarで識別されるプリンシパルはリソースの所有者です。送信されたACEが保護されたACEと競合し、ACE保護の意味に反するため、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: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.
次の要求では、Authorizationヘッダーの情報で認証されたユーザー「ejw」が、リソースhttp://www.example.com/top/index.htmlのアクセス制御リストを変更しようとします。このリソースには継承されたACEが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.
継承ACE #1は、URL http://www.example.com/users/ejwで識別されるプリンシパル（ユーザー「ejw」）に、http://www.example.com/privs/write-allおよび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.
継承ACE #2はDAV:allプリンシパルにDAV:read特権を付与します。
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.
要求では、継承されていないACEを設定し、URL http://www.example.com/users/ejwで識別されるプリンシパル（ユーザー「ejw」）のDAV:write権限を拒否しようとしています。これは継承ACE #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.
この例では、Authorizationヘッダーの情報で認証されたユーザー「ygoland」が、リソースhttp://www.example.com/diamond/engagement-ring.gifのアクセス制御リストを変更しようとします。ACL要求には構文上も意味上も誤ったACEが1つ含まれています。このACEは、URL http://www.example.com/users/friendsで識別されるグループにDAV:read特権を付与し、URL http://www.example.com/users/ygoland-soで識別されるプリンシパル（ユーザー「ygoland-so」）にはDAV:read特権を拒否しようとします。ただし、1つのACEに複数のプリンシパル要素を含めることも、許可要素と拒否要素の両方を含めることもできません。そのため、構文エラーとして要求は失敗します。
>> 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 Bad Request Content-Length: 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つのACE（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.
REPORTメソッド（[RFC3253]のセクション3.6で定義）は、リソースに関する情報を取得するための拡張可能な仕組みです。名前を指定した1つ以上のプロパティ値を返すPROPFINDメソッドと異なり、REPORTメソッドではより複雑な処理を行えます。サーバーが複雑な要求（クエリなど）に必要な情報をすべて持っている場合や、クライアントが同じ要求に必要な情報を取得するのに複数の要求を要する場合に、REPORTメソッドが有用です。
A server that supports the WebDAV Access Control Protocol MUST support the DAV:expand-property report (defined in Section 3.8 of [RFC3253]).
WebDAVアクセス制御プロトコルをサポートするサーバーは、DAV:expand-propertyレポート（[RFC3253]のセクション3.8で定義）をサポートしなければなりません (MUST)。
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レポートは、Request-URIのDAV:aclプロパティに含まれる全プリンシパルのうち、http(s) URLまたはDAV:propertyプリンシパルで識別されるものについて、REPORT要求本文で指定されたプロパティの値を返します。プリンシパルURLが複数回現れる場合、そのプリンシパルのプロパティは1回だけ返さなければなりません (MUST)。このレポートはサポートしなければなりません (REQUIRED)。
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要素でなければなりません (MUST)。
<!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".
このレポートはDepthヘッダーの値が「0」の場合に限って定義されます。それ以外の値では400（Bad Request）エラー応答になります。[RFC3253]のセクション3.6によると、Depthヘッダーがない場合の既定値は「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要素でなければなりません (MUST)（PROPFINDの応答と同じ形式です）。応答要素がない場合、返されるmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：[RFC2518]のセクション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 REPORT要求が成功した場合、その応答本文には、Request-URIで識別されるリソースのDAV:aclプロパティ内のACEにあるDAV:principal XML要素で列挙されたhttp(s) URLが示す各プリンシパルについて、DAV:response要素を含めなければなりません (MUST)。
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:number-of-matches-within-limits)：一致するプリンシパルの数は、サーバー固有の事前定義された上限内でなければなりません。たとえば、検索仕様が極めて多数の応答を返す場合、この条件が発生することがあります。
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：URL 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：URL http://www.example.com/groups/authorsで識別されるグループ（「authors」グループ）に、DAV:writeおよび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:displaynameプロパティを要求するDAV:acl-principal-prop-setレポートを示します。http://www.example.com/people/gsteinおよびhttp://www.example.com/groups/authorsのリソースについてDAV:displaynameの値を返しますが、http(s) URLではないDAV:allについては返しません。
>> 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:principal-match REPORTは、Request-URIで識別されるコレクション内の全階層にわたって、プリンシパルであり現在のユーザーに該当するすべてのメンバーを特定します。コレクションにプリンシパルが含まれる場合、このレポートで現在のユーザーに該当するメンバーをすべて特定できます。あるいは、コレクション内のリソースがプリンシパルを示すプロパティ（DAV:ownerなど）を持つ場合、このレポートで、そのプロパティが現在のユーザーに該当するプリンシパルを示すメンバーをすべて特定できます。たとえば、コレクション階層内で現在のユーザーが所有するリソースをすべて返せます。このレポートはサポートしなければなりません (REQUIRED)。
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.
このレポートはDepthヘッダーの値が「0」の場合に限って定義され、それ以外では400（Bad Request）エラー応答になります。[RFC3253]のセクション3.6によると、Depthヘッダーがない場合の既定値は「0」です。要求が成功した場合、応答本文はDAV:multistatus XML要素でなければなりません (MUST)。応答要素がない場合、返されるmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：[RFC2518]のセクション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:principal-match REPORT要求が成功した場合、応答本文には、現在のユーザーに該当するコレクション内の各メンバーについてDAV:response要素を含めなければなりません (MUST)。DAV:principal-property要素を使う場合、その要素が示すプロパティ内のDAV:href要素のURIで識別されるプリンシパルに現在のユーザーが該当すれば、一致とみなします。グループに対するDAV:principal-matchレポートでDAV:self要素を使う場合、メンバーの1人が現在のユーザーと同じプリンシパルを示せば、そのグループに一致します。
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:response要素内に報告しなければなりません (MUST)。
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 REPORTは、要求で指定された検索条件に一致する文字データをプロパティに含むすべてのプリンシパルを検索します。このレポートの想定用途の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:principal-property-searchの実装が基盤となるユーザー管理リポジトリの意味論に制約されない場合、既定の検索方法には大文字小文字を区別しない部分文字列一致を推奨します。
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:principal-property-searchレポートはサポートしなければなりません (REQUIRED)。
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標準にある任意の文字、すなわち人間の言語で使われる既知の文字の大半を含められます。言語によって大文字小文字の変換規則に固有の違いがあるため、大文字小文字を区別しない照合の実装は簡単ではありません。部分文字列照合を行うサーバーの実装者には、大文字小文字を区別しない照合アルゴリズムの実装指針として「The 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プロパティに相当）のスキーマには、大文字小文字を区別する検索と区別しない検索のどちらをサポートするかが示されています。検索方法をサーバー実装の判断に委ねる利点の1つは、DAV:principal-property-searchレポートを実装する際に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.
要求本文は、検索仕様と任意のプロパティ一覧を含むDAV:principal-property-search XML要素でなければなりません (MUST)。検索仕様に一致するプリンシパルごとに、そのプリンシパル上で要求されたプロパティの値を応答に含めます。
<!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.
既定では、このレポートはRequest-URIが示すコレクションの全メンバーを、階層の深さにかかわらず検索します。要求本文にDAV:apply-to-principal-collection-setが指定されている場合は、Request-URIで識別されるリソースのDAV:principal-collection-setプロパティが示す各コレクションを検索対象とします。
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要素と、検索文字列を含むmatch要素があります。
<!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.
<!ELEMENT match #PCDATA > DAV:prop要素内に複数のproperty-search要素または複数の要素がある場合、それらは論理積（AND）として解釈されます。
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".
このレポートはDepthヘッダーの値が「0」の場合に限って定義され、それ以外では400（Bad Request）エラー応答になります。[RFC3253]のセクション3.6によると、Depthヘッダーがない場合の既定値は「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要素でなければなりません (MUST)。応答要素がない場合、返されるmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：[RFC2518]のセクション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:principal-property-search REPORT要求が成功した場合、DAV:principal-property-searchで指定された検索条件をプロパティ値が満たす各プリンシパルについて、応答本文にDAV:response要素を含めなければなりません (MUST)。
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:response要素内に報告しなければなりません (MUST)。
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:number-of-matches-within-limits)：一致するプリンシパルの数は、サーバー固有の事前定義された上限内でなければなりません。たとえば、検索仕様が極めて多数の応答を返す場合、この条件が発生することがあります。
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」は値が「Julian Reschke」であるDAV:displaynameプロパティに一致します。この場合、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}.
つまり、{cdata 0}、{cdata 1}、{cdata 2}、{cdata 3}について1つずつ、合計4回照合します。
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」を含み、名前空間http://BigCorp.com/ns/の「title」プロパティ（職業上の肩書き）に「Sales」を含むすべてのユーザーのプリンシパルURLをクライアントが要求します。さらに、一致したプリンシパルについて5つのプロパティも返すよう要求します。
In the DAV: namespace: displayname
DAV:名前空間：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/：department、phone、office、salary。応答では検索条件に合致するプリンシパルリソースが2つ、「John Doe」と「Zygdoebert Smith」と示されます。要求を行ったプリンシパルにはsalaryプロパティを読む十分なアクセス許可がないため、名前空間http://www.example.com/ns/のsalaryプロパティは返されません。
>> 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 REPORTは、DAV:principal-property-search REPORT（セクション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:principal-collection-setプロパティの値に列挙されたすべてのコレクションで、DAV:principal-search-property-set REPORTをサポートしなければなりません (MUST)。
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 REPORTの結果を使い、プリンシパルを検索するためのクエリ画面を利用者に提示できます。
Support for this report is REQUIRED.
このレポートはサポートしなければなりません (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:principal-search-property-set XML要素でなければなりません (MUST)。
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".
このレポートはDepthヘッダーの値が「0」の場合に限って定義され、それ以外では400（Bad Request）エラー応答になります。[RFC3253]のセクション3.6によると、Depthヘッダーがない場合の既定値は「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:principal-search-property-set XML要素でなければなりません (MUST)。その中に、DAV:principal-property-search REPORTで検索できる各プロパティについてDAV:principal-search-property XML要素を含めます。サーバーは、対話型アクセス制御クライアントに役立ちそうなものなど、検索可能なプロパティの一部だけに応答を限定してもかまいません (MAY)。
<!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:principal-search-property 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:principal-property-search REPORTで検索できるプリンシパルプロパティが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.
prop：[RFC2518]のセクション12.11を参照。description要素は、そのプロパティが表す情報を人間可読な形で説明します。サーバーはxml:lang属性を使って説明文の言語を示さなければなりません (MUST)。複数の言語がある場合、選択にあたってHTTPのAccept-Language要求ヘッダーを考慮すべきです (SHOULD)。
<!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:principal-search-property-set REPORTを要求し、検索可能なプリンシパルプロパティの集合を確認します。
>> 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要素の無視規則と、XML Namespaces勧告[REC-XML-NAMES]をサポートしなければなりません (MUST)。
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:supported-privilege-setプロパティ内のdescription XML要素だけです。この要素には、特権が制御する機能を人間可読な形で説明します。そのため、description要素では複数の文字セットで説明を表現できる必要があります。description要素はWebDAVプロパティ内にあるため、通信上はXML [REC-XML]として表され、XMLの言語タグ付け機能と文字セット符号化機能を利用できます。具体的には、XMLプロセッサは少なくとも、ISO 10646多言語面をUTF-8 [RFC3629]で符号化したXML要素を読み取れる必要があります。この仕様のXML例では、[RFC3023]で定義されるContent-Typeヘッダーのcharsetパラメーターと、XMLのencoding属性を使用しています。両者によりMIMEおよびXMLプロセッサに文字セットを示します。さらに、この仕様はサーバー実装に対し、説明フィールドへxml:lang属性（[REC-XML]のセクション2.12を参照）を付け、説明文の言語を示すよう求めています。サーバー実装では、返す説明文を選ぶ際にAccept-Language 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.
description要素以外の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.
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.
アクセス制御リストを遠隔操作する仕組みがなければ、1人のユーザーの認証情報が漏えいしても、そのユーザーにアクセス許可があるリソースしか読み取り、変更、移動、削除できません。このアクセス制御プロトコルを導入し、侵害されたユーザー1人が幅広い他のユーザーのACLを変更できる（たとえばスーパーユーザーである）場合、そのユーザー1人が改変できるリソースの数は増えます。このリスクは、広範囲のリソースで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の読み取り自体はリソース状態に影響しないため、無害に思えるかもしれません。しかし、すべてのリソースのACLが誰にでも読み取れる場合、誰でも書き込み可能になっているなど、脆弱な状態を意図せず残したリソースを網羅的に検索できてしまいます。特に、階層全体に対してDepth infinityで実行する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.
このリスクを減らすため、未認証プリンシパルにはread-acl特権を付与すべきではありません。また、このプロトコルを導入する際には、認証済みプリンシパルに対するread-aclおよびread-current-user-privilege-set特権の制限を慎重に検討してください。current-user-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]で定義されたBasic認証とDigest認証が該当します。ACL仕様の実装でBasic認証を使う場合は、TLSなどの安全なトランスポート上でのみサポートしなければなりません (MUST)。
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設計チームで共同作成しました。Bernard Chester、Geoff Clemm、Anne Hopkins、Barry Lind、Sean Lyndersay、Eric Sedlar、Greg Stein、Jim Whiteheadに感謝します。詳細なレビューとコメントを寄せた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、Keith Wannamakerにも感謝します。プリンシパルプロパティ検索節の初稿を提供したKeith Wannamakerにも感謝します。このプロトコル以前の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, "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-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. 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-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. and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 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, 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, June 1999.
[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 Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[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, "Versioning Extensions to WebDAV", RFC 3253, March 2002.
[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. and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629 November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629 November 2003.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[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] The Unicode Consortium, "The Unicode Standard - Version 4.0", Addison-Wesley , August 2003, <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)>
<!ELEMENT principal (href) | all | authenticated | unauthenticated | property | self)>
<!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?)>
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-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.
<!ELEMENT acl-principal-prop-set ANY> ANY value: a sequence of one or more elements, with at most one DAV:prop 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>
<!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 >
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.
次の表は、RFC 2518、RFC 2616、およびRFC 3253で定義されるWebDAVメソッドごとに、アクセスに必要な特権を示します。ここに挙げた特権が拒否された場合、アクセスを拒否しなければなりません (MUST)。ただし、特定の実装が既存メソッドへのアクセスを制御する追加の独自特権を定義してもかまいません (MAY)。そのため、ここに示した特権をすべて持っていてもアクセスが許可されるとは限りません。また、実装によっては、表示された特権に集約される下位特権を使ってアクセスを制御する場合があるため、ここに示した特権を持たないことだけでアクセス拒否が決まるわけではありません。特に明記しない限り、必要な特権は現在処理中のリソースに関するものです。
+---------------------------------+---------------------------------+
| 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
A ACL method 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
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
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 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
M Methods ACL 40
M Methods 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 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
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 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
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 Germany
EMail: julian.reschke@greenbytes.de
Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065
Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065
EMail: eric.sedlar@oracle.com
Jim Whitehead U.C. Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064
Jim Whitehead U.C. Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 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.
本文書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表する、または後援を受ける組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示または黙示を問わず一切の保証を否認します。これには、本文書の情報を使用しても権利を侵害しないという保証、商品性の黙示保証、および特定目的への適合性の黙示保証が含まれますが、これらに限りません。
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開示、その権利に基づき利用可能となるライセンスの保証、または本仕様の実装者・利用者が当該所有権の使用について一般ライセンスや許可を得ようとした結果は、IETFオンラインIPRリポジトリ（http://www.ietf.org/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 Editor機能の運営資金は、現在Internet Societyが提供しています。