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
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names.
この文書は、オーサリングプロトコルWebDAVの分散にアクセスコントロールの拡張機能を定義する方法、ヘッダ、メッセージ本文、プロパティ、およびレポートのセットを指定します。このプロトコルは、所与のプリンシパルによって（例えば、ハイパーテキスト転送プロトコル（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ファイルシステムのそのような単純なセキュリティだけでなく、より洗練されたモデルとコンテンツ・リポジトリに実装することができます。アクセス制御の基本原理は、誰あなたがいることは、あなたがリソース上で実行できる操作を決定することです。 「あなたがしている者」「校長」識別子によって定義されます。以前のユーザー、クライアントソフトウェア、サーバ、およびグループは、主要な識別子を持っています。 「あなたが実行できる操作は、」リソースに関連付けられているシングル「アクセスコントロールリスト」（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です。プリンシパルの人間可読な名前を含むのDisplayNameプロパティ：これを解決するには、すべての主要なリソースは、DAVを持っています。
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
プリンシパルが複数のURLによって識別することができるので、主が与えられたACEで参照されている正確に決定する問題を提起します。クライアントは、ACEがhttp://www.example.com/people/ Greg.Steinに読み取り権限を付与することを決定することは不可能であることもhttp://www.example.com/u/ 256432で主要な影響を与えます。つまり、クライアントはその2を決定するための機構がありません
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を作成する際の主要なためだけの多くの可能なURLのいずれかを使用するようにクライアントを必要とします。主要なリソースから元本-URLプロパティ（4.2節）：クライアントはDAVを取得することによって、使用する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.
システムがプリンシパルの数百〜数千を持つ、問題は、クライアントソフトウェアの人間のオペレータは、これらの原理の一つだけを選択できるようにする方法を生じます。一つのアプローチは、コレクションごとにいくつかのプリンシパルを得、コレクションの数が多い上プリンシパルを広めるために、幅広いコレクションの階層を使用することです。この例は、36点のコレクション（AZ、0-9）を含む第一のレベルを有する2つのレベルの階層であり、そして第二のレベルの作成、別の36であるコレクション/ A / A /、/ A / B / ,. / / Z /、姓を持つ校長は「スタインは、」/ S / T /スタインで出現するようになっています。実際には、これが最後の名前に共通のクエリ、検索を事前に計算し、階層にそれをエンコードします。この方式の欠点は、それが事前に定義されたクエリの唯一の小さなセットを扱うことで、ユーザーはすでにプリンシパルの名前を知っているとき、コレクション階層をドリルダウンは（アップ/ダウン移動）、不要なステップを追加します。階層に元本のURLを整理すると、有効な名前空間の組織ですが、ユーザーがプリンシパルを選択するには、この階層を移動することを強制すべきではありません。
This specification provides the capability to perform substring searches over a small set of properties on the resources representing principals. This permits searches based on last name, first name, user name, job title, etc. Two separate searches are supported, both via the REPORT method, one to search principal resources (DAV:principal-property-search, Section 9.4), the other to determine which properties may be searched at all (DAV:principal-search-property-set, Section 9.5).
この仕様は、プリンシパルを表すリソースのプロパティの小さなセットの上に文字列検索を実行する機能を提供します。これは、両方のREPORTメソッドを介して、1は、主要なリソース（DAV：元本-プロパティ検索、セクション9.4）を検索するために、2件の別々の検索がサポートされているなどの姓、名、ユーザ名、役職、に基づいて検索を可能にし、全て（：主-検索プロパティセット、セクション9.5 DAV）で検索することができる特性を決定するために、他の。
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を評価するサーバは、プロトコル要求をするプリンシパルのIDを知っている必要があり、そのプリンシパルが、彼らは、認証と呼ばれるプロセスであると主張する人であることを検証する必要があります。 HTTPプロトコルが既に認証メカニズム[RFC2617]の数を有する、本明細書では意図的に、認証の説明を省略しています。 （そのような全てのWebDAV準拠の実装をサポートするために必要なHTTPダイジェスト認証など）いくつかの認証機構は、プリンシパルのアイデンティティを検証するために利用可能でなければなりません。
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,
リソース（：ACLおよびDAV：アクセス制御プロパティDAVを除く現在のユーザ特権セット）にのみ特定のプロパティに適用Oアクセス制御、むしろ全体のリソースよりも、
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,
リソース上のACLが初期化された方法のO仕様、
o Specification of an ACL that applies globally to all resources, rather than to a particular resource.
すべてのリソースにはなく、特定のリソースにグローバルに適用ACLのO仕様。
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で指定され、コンテンツリソースのアクセス制御プロパティはACLはオプションを使用してアクセス制御機能の第6章クライアントの発見に記載されて評価される方法は、セクション7.2に記載されているセクション5で指定されています。アクセス制御機能との間の相互作用と既存のHTTPおよびWebDAV方法は、第7の残り方法、ACLのアクセス制御設定に記載されているが、セクションに指定された制限されたサーバ側検索機能を提供する8つのレポートは、セクション9に記載されています。 XML処理のセクション（セクション10）、国際上の考慮事項（セクション11）、セキュリティ上の考慮事項（セクション12）、および認証（セクション13）が仕様を締めくくります。付録（付録A）仕様で定義されたXML要素のXML文書型定義（DTD）を提供します。
This document uses the terms defined in HTTP [RFC2616] and WebDAV [RFC2518]. In addition, the following terms are defined:
この文書では、HTTP [RFC2616]とWebDAV [RFC2518]で定義された用語を使用します。また、以下の用語が定義されています。
principal
主要な
A "principal" is a distinct human or computational actor that initiates access to network resources. In this protocol, a principal is an HTTP resource that represents such an actor.
「校長は、」ネットワークリソースへのアクセスを開始する明確な人間または計算の俳優です。このプロトコルでは、主は、このような俳優を表すHTTPリソースです。
group
グループ
A "group" is a principal that represents a set of other principals.
「グループ」は、他のプリンシパルの集合を表す主です。
privilege
特権
A "privilege" controls access to a particular set of HTTP operations on a resource.
「特権」のコントロールは、リソースにHTTP操作の特定のセットにアクセスできます。
aggregate privilege
集約権限
An "aggregate privilege" is a privilege that contains a set of other privileges.
「集約権限は、」その他の権限のセットが含ま特権です。
abstract privilege
抽象特権
The modifier "abstract", when applied to a privilege on a resource, means the privilege cannot be set in an access control element (ACE) on that resource.
修飾語「抽象」、リソース上の特権に適用される、特典がそのリソースにアクセス制御要素（ACE）に設定することができないことを意味します。
access control list (ACL)
アクセス制御リスト（ACL）
An "ACL" is a list of access control elements that define access control to a particular resource.
「ACL」は、特定のリソースへのアクセス制御を定義するアクセス制御要素のリストです。
access control element (ACE)
アクセス制御要素（ACE）
An "ACE" either grants or denies a particular set of (non-abstract) privileges for a particular principal.
「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 augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], those rules apply to this document as well.
プロトコル要素を記述するために、この文書で使用される拡張BNFは[RFC2616]のセクション2.1に記載されています。この増補BNFは[RFC2616]のセクション2.2で提供される基本的なプロダクションルールを使用しているため、これらのルールは、同様に、この文書に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "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.
[REC-XML]のセクション3.2で説明した本文書の使用XML要素型宣言内の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は、主リソースを識別するために使用され得ます。しかし、この仕様を実装したサーバがそうセクション4で説明したように、追加のプロパティを持っているリソースを指し示す特権スキームであるHTTP（S）URL、で主要なリソースを公開する必要があり、主要なリソースは、のいずれかを複数のURIを持つことができますこれは、HTTP（S）方式のURLである必要があります。実装がPROPFINDをサポートする必要があり、元本についての情報にアクセスし、変更するPROPPATCHをサポートするかもしれないが、そうする必要はありません。
A principal resource may be a group, where a group is a principal that represents a set of other principals, called the members of the group. If a person or computational agent matches a principal resource that is a member of a group, they also match the group. Membership in a group is recursive, so if a principal is a member of group GRPA, and GRPA is a member of group GRPB, then the principal is also a member of GRPB.
主要リソースは、グループは、グループのメンバーと呼ばれる他のプリンシパルの集合を表す主要な基であってもよいです。人または計算代理人がグループのメンバーである主要なリソースと一致した場合、彼らはまた、グループに一致します。グループのメンバーシップは再帰的であるので、主にグループGRPAのメンバーであり、そしてGRPAグループGRPBのメンバーである場合、主はまたGRPBのメンバーです。
Ability to perform a given method on a resource MUST be controlled by one or more privileges. Authors of protocol extensions that define new HTTP methods SHOULD specify which privileges (by defining new privileges, or mapping to ones below) are required to perform the method. A principal with no privileges to a resource MUST be denied any HTTP access to that resource, unless the principal matches an ACE constructed using the DAV:all, DAV:authenticated, or DAV:unauthenticated pseudo-principals (see Section 5.5.1). Servers MUST report a 403 "Forbidden" error if access is denied, except in the case where the privilege restricts the ability to know the resource exists, in which case 404 "Not Found" may be returned.
リソースで指定された方法を実行する能力は、一の以上の権限によって制御されなければなりません。新しいHTTPメソッドを定義するプロトコルの拡張の著者は、方法を実行するために必要とされる（新しい権限、以下のものへのマッピングを定義することによって）権限を特定すべきです。全て、DAV：認証、またはDAV：認証されていない疑似プリンシパル（セクション5.5.1を参照）プリンシパルがDAVを使用して構築ACEと一致しない限り、リソースの無権限を持つプリンシパルは、そのリソースへのHTTPアクセスを拒否されなければなりません。アクセスが拒否された場合、サーバーが権限は404が返されることがあり、「見つかりません」、その場合には、リソースが存在することがわかっている能力を、制限する場合を除き、403「禁止」エラーを報告しなければなりません。
Privileges may be containers of other privileges, in which case they are termed "aggregate privileges". If a principal is granted or denied an aggregate privilege, it is semantically equivalent to granting or denying each of the aggregated privileges individually. For example, an implementation may define add-member and remove-member privileges that control the ability to add and remove a member of a group. Since these privileges control the ability to update the state of a group, these privileges would be aggregated by the DAV:write privilege on a group, and granting the DAV:write privilege on a group would also grant the add-member and remove-member privileges.
権限は、彼らが「集約権限」と呼ばれ、その場合には他の権限、の容器であってもよいです。プリンシパルが付与または集約権限を拒否された場合、それが付与または個別に集約された権限のそれぞれを否定する意味的に等価です。例えば、実装は、メンバーを追加し、グループのメンバを追加および削除する能力を制御特権メンバーの削除定義することができます。これらの権限は、グループの状態を更新する機能を制御するので、これらの権限は、DAVによって集約される：グループに権限を書き込み、DAVを付与：グループへの書き込み権限もアドイン部材を付与し、除去部材をだろう特権。
Privileges may be declared to be "abstract" for a given resource, in which case they cannot be set in an ACE on that resource. Aggregate and non-aggregate privileges are both capable of being abstract. Abstract privileges are useful for modeling privileges that otherwise would not be exposed via the protocol. Abstract privileges also provide server implementations with flexibility in implementing the privileges defined in this specification. For example, if a server is incapable of separating the read resource capability from the read ACL capability, it can still model the DAV:read and DAV:read-acl privileges defined in this specification by declaring them abstract, and containing them within a non-abstract aggregate privilege (say, read-all) that holds DAV:read, and DAV:read-acl. In this way, it is possible to set the aggregate privilege, read-all, thus coupling the setting of DAV:read and DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-acl individually. Since aggregate privileges can be abstract, it is also possible to use abstract privileges to group or organize non-abstract privileges. Privilege containment loops are not allowed; therefore, a privilege MUST NOT contain itself. For example, DAV:read cannot contain DAV:read.
権限は、彼らがそのリソース上のACEに設定することができない、その場合には特定のリソースのための「抽象的」であると宣言することができます。集約および非集約権限は、抽象的であることの両方が可能です。抽象権限はそうでない場合は、プロトコルを介して公開されることはないモデリング特権のために便利です。抽象権限もこの仕様で定義された権限の実装に柔軟にサーバの実装を提供します。たとえば、サーバーが読んACL機能から読み込んだリソース機能を分離することができない場合、それはまだDAVをモデル化することができます：読み取りおよびDAV：読み取りのACLこの仕様で定義された権限を彼らは抽象宣言、および非内でそれらを含むことにより、読んで、そしてDAV：：読み取りACL DAVを保持している-abstract集約権限（たとえば、読み取りすべて）。このようにして、集計権限を設定することが可能であり、読み取り全てを、このようにDAVの設定を結合：読み取りおよびDAV：読み取りACLを、DAVを設定することはできません：読み取り、またはDAV：読み取りACLを個々に。集約権限は抽象することができますので、グループに抽象的権限を使用するか、または非抽象権限を整理することも可能です。特権封じ込めループは許可されていません。そのため、権限自体を含めることはできません。たとえば、DAV：読み取り：読み取りがDAVを含めることはできません。
The set of privileges that apply to a particular resource may vary with the DAV:resourcetype of the resource, as well as between different server implementations. To promote interoperability, however, this specification defines a set of well-known privileges (e.g., DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-current-user-privilege-set, and DAV:all), which can at least be used to classify the other privileges defined on a particular resource. The access permissions on null resources (defined in [RFC2518], Section 3) are solely those they inherit (if any), and they are not discoverable (i.e., the access control properties specified in
リソースのresourcetypeの、ならびに間で異なるサーバーの実装を：DAVによって変化し得る特定のリソースに適用される権限のセット。 、DAVをお読みください：書き込み、DAV：読み取りACLを、DAV：書き込み-ACLを、DAV：読み取り、現在のユーザー特権セットの相互運用性を促進するために、しかし、この仕様は、よく知られている権限（例えば、DAVのセットを定義します、およびDAV：すべて）は、少なくとも特定のリソースに定義された他の権限を分類するために使用することができます。 （[RFC2518]、セクション3で定義される）ヌルリソースに対するアクセス権限は、単にそれらが（もしあれば）を継承し、それらが指定された発見（すなわち、アクセス制御プロパティではないものです
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).
第5節）は、ヌルリソースに定義されていません。ステートフルリソースへのヌルからの移行では、最初のアクセス制御リスト（もしあれば）、サーバのデフォルトの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.
サーバ実装は、この仕様で定義されたものを超え、新たな権限を定義することができます。彼らは、このようなHTTPスキームのURLとして、コントロールの名前空間を使用する必要があります代わりに、名前空間、および：個々の実装によって定義された権限は、DAVを使用してはなりません。
The read privilege controls methods that return information about the state of the resource, including the resource's properties. Affected methods include GET and PROPFIND. Any implementation-defined privilege that also controls access to GET and PROPFIND must be aggregated under DAV:read - if an ACL grants access to DAV:read, the client may expect that no other privilege needs to be granted to have access to GET and PROPFIND. Additionally, the read privilege MUST control the OPTIONS method.
読み取り権限は、リソースのプロパティを含むリソースの状態に関する情報を返す方法を制御します。影響を受ける方法はGETとPROPFINDが含まれます。読み - ACLの助成金は、DAVにアクセスする場合：：もGETするとPROPFINDはDAVの下に集約されなければならないアクセスを制御し、任意の実装定義特権クライアントは、他の特典がGETとPROPFINDへのアクセスを持つように付与する必要がないことを期待することがあり、読んで。また、読み取り権限がOPTIONSメソッドを制御する必要があります。
<!ELEMENT read EMPTY>
<！ELEMENTは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.
書き込み権限は、PUTやPROPPATCHなどのリソースをロックしたり、コンテンツを変更する方法、死んプロパティ、または（コレクションの場合）、リソースのメンバーシップを制御します。その状態の変更も、非常に効果的書き込みアクセス（[RFC2518]のセクション5.3を参照）のロックを介して制御されるメモの両方が権限を書き込み、要件が満たされているロック書き込むことを要求します。また、コンテンツを変更する方法へのアクセスを制御する任意の実装で定義された権限は、死者のプロパティまたはコレクションのメンバーシップは、DAVの下に集約する必要があります。ACLの助成金は、DAVにアクセスする場合、例えば、書き込み：書き込み、クライアントは、他の権限があることが必要ないことを期待することがありPUTへのアクセスとPROPPATCHを持つことが許可されました。
<!ELEMENT write EMPTY>
<！ELEMENT 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：書き込みプロパティの権限は、PROPPATCHなどのリソースの死者プロパティを変更する方法を制御します。この権限は、任意のライブプロパティへのアクセスを制御するために使用することができるかどうかは、実装によって決定されます。また、死者のプロパティを変更するメソッドへのアクセスを制御し、任意の実装定義特権がDAVの下に集約されている必要があります書き込みのプロパティを - DAVへのACLのアクセスを許可があれば、例えば：-プロパティを記述し、クライアントが安全に他の特権をする必要がないことを期待することができますPROPPATCHへのアクセス権を持つことが許可されました。
<!ELEMENT write-properties EMPTY>
<！ELEMENT書き込みプロパティ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：書き込み内容の特権は、PUTなどの既存のリソースの内容を修正する方法を制御します。また、コンテンツへのアクセスを制御する任意の実装で定義された権限は、DAVの下に集約されている必要があります書き込み内容を - たとえば、ACLの助成金は、DAVにアクセスする場合：書き込み内容は、クライアントが安全に、他の権限を持つように付与する必要がないことを期待することができますPUTするためのアクセス。そのPUTに注意してください - マッピングされていないURIに適用されたときに - 新しいリソースを作成し、したがって、DAVによって制御されます。親コレクションにバインド特権。
<!ELEMENT write-content EMPTY>
<！ELEMENT書き込み内容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メソッドの使用を制御します。リソースをロックして、ユーザーのセットは、最も一般的リソースを修正することができ、ユーザーの同じセットですが、サーバーは、管理者の様々な種類が他のユーザーによってロックされたリソースのロックを解除することを可能にします。ロックを解除するために非ロック所有者によるアクセスを制御する任意の権限は、DAVの下に集約されなければならない：ロックを解除します。
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を持っていない場合でも、次のとおりです。特権のロックを解除し、彼らはまだ、彼らが所有するロックを削除することができます。ロック所有者以外のプリンシパルは、彼らがDAVを持っている場合にのみ、ロックを解除することができます：権限のロックを解除し、それらが正しいロック・トークンとUNLOCKを発行します。ロックのタイムアウトはDAVに影響されない：特典のロックを解除します。
<!ELEMENT unlock EMPTY>
<！ELEMENT EMPTYロックを解除>
The DAV:read-acl privilege controls the use of PROPFIND to retrieve the DAV:acl property of the resource.
DAV：リソースのACLプロパティ：読み取りACL権限がDAVを取得するPROPFINDの使用を制御します。
<!ELEMENT read-acl EMPTY>
<！ELEMENT読み取り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：リソースの現在のユーザー特権設定プロパティを：読み取り、現在のユーザー特権セット特権は、DAVを取得するPROPFINDの使用を制御します。
Clients are intended to use this property to visually indicate in their UI items that are dependent on the permissions of a resource, for example, by graying out resources that are not writable.
クライアントは、例えば、書き込み可能でないリソースをグレーアウトすることによって、視覚的にリソースの権限に依存している彼らのUI項目に示すために、このプロパティを使用することを意図しています。
This privilege is separate from DAV:read-acl because there is a need to allow most users access to the privileges permitted the current user (due to its use in creating the UI), while the full ACL contains information that may not be appropriate for the current authenticated user. As a result, the set of users who can view the full ACL is expected to be much smaller than those who can read the current user privilege set, and hence distinct privileges are needed for each.
この権限は、DAVから分離されている：完全なACLはに対して適切ではないかもしれない情報が含まれていながら、（によるUIの作成におけるその使用）現在のユーザーを許可するほとんどのユーザーは、権限へのアクセスを許可する必要があるため、ACLを読みます現在の認証されたユーザー。その結果、完全なACLを表示することができ、ユーザーのセットが設定され、現在のユーザーの権限を読み取ることができ、ひいては明確な権限がそれぞれに必要とされる人よりもはるかに小さいことが予想されます。
<!ELEMENT read-current-user-privilege-set EMPTY>
<！ELEMENTは、読み取り電流ユーザー権限設定EMPTYを>
The DAV:write-acl privilege controls use of the ACL method to modify the DAV:acl property of the resource.
DAV：リソースのACLプロパティ：書き込みACL権限がDAVを変更するためのACLの方法の使用を制御します。
<!ELEMENT write-acl EMPTY>
<！ELEMENT書き込み-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特権は、メソッドが（PUTやMKCOL経由など）指定されたコレクションに新しいメンバーのURLを追加することができます。それはコレクションではありませんリソースのために無視されます。
<!ELEMENT bind EMPTY>
<！ELEMENTバインド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：アンバインド特権（DELETEまたはMOVEを介してなど）指定されたコレクションからメンバーURLを削除する方法を可能にします。それはコレクションではありませんリソースのために無視されます。
<!ELEMENT unbind EMPTY>
<！ELEMENT EMPTYバインド解除>
DAV:all is an aggregate privilege that contains the entire set of privileges that can be applied to the resource.
DAV：すべてのリソースに適用することが可能な権限のセット全体が含まれている集計特権です。
<!ELEMENT all EMPTY>
<！ELEMENTすべて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：読み取りACLはDAVを含めることはできません：、DAVを読む：書き込み、DAV：書き込み-ACLを、DAV：書き込みプロパティを、DAV：-内容を書き込み、またはDAV：読み取り、現在のユーザー特権セット。
DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or DAV:read-current-user-privilege-set.
DAV：書き込み-ACLは、DAVを含めることはできません：、DAVを書く：、DAVを読む：読み取りACL、またはDAVを：読み取り、現在のユーザー特権セット。
DAV:read-current-user-privilege-set MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or DAV:write-acl.
DAV：読み取り、現在のユーザー特権セットは、DAVを含めることはできません：、DAVを書く：読んで、DAV：-ACLを読み、またはDAV：-ACLを記述します。
DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-current-user-privilege-set.
DAV：書き込みがDAVを含めることはできません：、DAVを読む：読み取りACL、またはDAVを：読み取り、現在のユーザー特権セット。
DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-properties, or DAV:write-content.
DAV：読み取りがDAVを含めることはできません：、DAVを書く：書き込みACLを、DAV：-プロパティを書き込み、またはDAV：書き込み内容。
DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and DAV:write-content.
DAV：バインド、DAV：：アンバインド、DAV：およびDAV-プロパティを書く：書き込み内容の書き込みがDAVを含まなければなりません。
Principals are manifested to clients as a WebDAV resource, identified by a URL. A principal MUST have a non-empty DAV:displayname property (defined in Section 13.2 of [RFC2518]), and a DAV:resourcetype property (defined in Section 13.9 of [RFC2518]). Additionally, a principal MUST report the DAV:principal XML element in the value of the DAV:resourcetype property. The element type declaration for DAV:principal is:
プリンシパルは、URLで識別のWebDAVリソースとしてクライアントに明示されています。 （[RFC2518]のセクション13.2で定義される）のDisplayNameプロパティ、およびDAV：（[RFC2518]のセクション13.9で定義された）resourcetypeのプロパティ主は、非空DAVを持たなければなりません。 DAVの価値の主要なXML要素：resourcetypeのプロパティまた、校長は、DAVを報告しなければなりません。 DAVの要素型宣言：プリンシパルがあります。
<!ELEMENT principal EMPTY>
<！ELEMENT校長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]).
このプロトコルは、主のために、以下の追加のプロパティを定義します。サーバは、アクセス制御情報を取得することは高価なことができますので、これらのプロパティの名前と値は、PROPFINDのallprop要求（[RFC2518]のセクション12.14.1で定義されている）によって返されるべきではありません。
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を含んでいる）を識別する。このプロパティの一つの予想される使用は、LDAP [RFC2255]のスキームのURLのストレージです。 LDAPのURLに遭遇したユーザーエージェントは、本人に関する追加の機械読み取り可能なディレクトリ情報を取得するために、LDAP [RFC2251]を使用して、そのユーザーインターフェイスで、その情報を表示することができます。このプロパティのサポートが必要であり、いかなる代替URIが主のために存在しない場合、この値は空です。
<!ELEMENT alternate-URI-set (href*)>
<！ELEMENTの代替URIセット（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があるかもしれませんが、クライアントが一意にプリンシパルを識別するために使用できる1「主要なURL」がなければなりません。この保護されたプロパティは、ACLのリクエストでこのプリンシパルを識別するために使用しなければならないURLが含まれています。このプロパティのサポートが必要です。
<!ELEMENT principal-URL (href)>
<！ELEMENTプリンシパル-URL（HREF）>
This property of a group principal identifies the principals that are direct members of this group. Since a group may be a member of another group, a group may also have indirect members (i.e., the members of its direct members). A URL in the DAV:group-member-set for a principal MUST be the DAV:principal-URL of that principal.
グループプリンシパルのこの特性は、このグループの直接的なメンバーであるプリンシパルを識別する。グループが他のグループのメンバーである可能性があるため、グループはまた、間接的なメンバーを有していてもよい（すなわち、その直接のメンバーのメンバー）。 DAVでURL：そのプリンシパルの主-URL：プリンシパルのグループ・メンバーセットは、DAVでなければなりません。
<!ELEMENT group-member-set (href*)>
<！ELEMENTグループメンバーセット（HREF *）>
This protected property identifies the groups in which the principal is directly a member. Note that a server may allow a group to be a member of another group, in which case the DAV:group-membership of those other groups would need to be queried in order to determine the groups in which the principal is indirectly a member. Support for this property is REQUIRED.
この保護されたプロパティは、プリンシパルが直接メンバーであるグループを識別する。これらの他のグループのグループメンバーシッププリンシパルが間接的メンバーであるグループを決定するために照会される必要があるであろう：サーバがグループはDAVが、その場合、他のグループのメンバーであることを可能にすることができることに留意されたいです。このプロパティのサポートが必要です。
<!ELEMENT group-membership (href*)>
<！ELEMENTグループ・メンバーシップ（HREFの*）>
This specification defines a number of new properties for WebDAV resources. Access control properties may be retrieved just like other WebDAV properties, using the PROPFIND method. Since it is expensive, for many servers, to retrieve access control information, a PROPFIND allprop request (as defined in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the properties defined in this section.
この仕様は、WebDAVリソースのための新しいプロパティの数を定義します。アクセス制御特性はPROPFINDメソッドを使用して、ちょうど他のWebDAV特性のよう取り出すことができます。それは、アクセス制御情報を取得するために、多くのサーバのために、高価であるため、PROPFINDのallprop要求は（[RFC2518]のセクション12.14.1で定義されている）、このセクションで定義されたプロパティの名前と値を返すべきではありません。
Access control properties (especially DAV:acl and DAV:inherited-acl-set) are defined on the resource identified by the Request-URI of a PROPFIND request. A direct consequence is that if the resource is accessible via multiple URI, the value of access control properties is the same across these URI.
アクセス制御特性（特にDAV：ACLおよびDAV：継承-ACL-セット）PROPFIND要求のRequest-URIによって識別されるリソース上で定義されています。直接の結果は、リソースが複数のURIを介してアクセスされた場合、アクセス制御プロパティの値は、これらのURI全体で同じであるということです。
HTTP resources that support the WebDAV Access Control Protocol MUST contain the following properties. Null resources (described in Section 3 of [RFC2518]) MUST NOT contain the following properties.
WebDAVのアクセス制御プロトコルは、次のプロパティが含まれていなければならないサポートするHTTPリソース。 （[RFC2518]のセクション3を参照）ヌルリソースは、次のプロパティを含んではなりません。
This property identifies a particular principal as being the "owner" of the resource. Since the owner of a resource often has special access control capabilities (e.g., the owner frequently has permanent DAV:write-acl privilege), clients might display the resource owner in their user interface.
このプロパティは、リソースの「所有者」であると特定のプリンシパルを識別する。リソースの所有者は、多くの場合、特殊なアクセス制御機能を持っているので（例えば、所有者が頻繁に永久的なDAVがあります書き込みACL権限）、クライアントは自分のユーザーインタフェースでリソースの所有者が表示される場合があります。
Servers MAY implement DAV:owner as protected property and MAY return an empty DAV:owner element as property value in case no owner information is available.
保護されたプロパティとして所有者と空のDAV返すことがあります：サーバーはDAVを実装するかもしれなし、所有者情報が利用できない場合には、プロパティ値として所有者要素を。
<!ELEMENT owner (href?)>
<！ELEMENTの所有者（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/論文/でコレクションリソースから所有者のプロパティ：この例では、DAVの値のためのクライアント要求を示しています。要求を行っているプリンシパルは、ダイジェスト認証を使用して認証されます。 DAVの値：// www.example.com/acl/users/gstein、DAVに包まれた：hrefのXML要素の所有者は、URLはhttpです。
>> 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="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "ジム"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:owner/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：オーナー/> </ D：プロップ> </ D ：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/紙/ </ D：HREF> <D：propstat> <D：プロペラ> <D：所有者> <D：HREF> http://www.example.com/acl/users/gstein </ D：HREF> < / D：所有者> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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
次の例では、DAVの値を変更するには、クライアントの要求を示しています。<：// www.example.com/papers HTTP> URLでリソースの所有者の財産。 DAVので：所有者：所有者は、この特定のサーバー上の保護されたプロパティであり、それはDAVを設定する行為のための403（禁止）ステータスコードが含まれている207（マルチステータス）応答で応答します。 [RFC2518]のセクション8.2.1 PROPPATCHステータスコード情報を記述し、[RFC2518]のセクション11は、説明します
Multi-Status response and Sections 1.6 and 3.12 of [RFC3253] describe additional error marshaling for PROPPATCH attempts on protected properties.
多状態応答とセクション[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="..."
PROPPATCH /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "ジム"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：propertyupdateのxmlns：D = "DAV："> <D：セット> <D：プロペラ> <D：所有者> <D：HREF> http://www.example.com/acl/users/jim </ D：HREF> </ D：所有者> </ D：プロップ> </ D：セット> </ D：propertyupdate>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/紙/ </ D：HREF> <D：propstat> <D：プロペラ> <D：オーナー/> </ D：プロペラ> <D：ステータス> HTTP / 1.1 403禁止</ D：状態> <D：responsedescription > <D：エラー> <D：CAN-変更しない保護-性/> </ D：エラー>保護されたプロパティを設定する失敗（DAV：所有者）</ D：responsedescription> </ D：propstat> </ D：応答> </ 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返すことがあります：サーバーはDAVを実装するかもしれ一切グループ情報が利用できない場合には、プロパティ値として族元素を。
<!ELEMENT group (href?)>
<！ELEMENTグループ（HREF？）>
This is a protected property that identifies the privileges defined for the resource.
これは、リソースに対して定義された権限を識別し、保護プロパティです。
<!ELEMENT supported-privilege-set (supported-privilege*)>
<！ELEMENTサポート-特権セット（サポート-特権*）>
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>
<！ELEMENTサポート-特権（特権、抽象?,説明、サポート特権*）> <！ELEMENT権限ANY>
An abstract privilege MUST NOT be used in an ACE for that resource. Servers MUST fail an attempt to set an abstract privilege.
抽象的権限は、そのリソースのACEで使用してはいけません。サーバーは抽象権限を設定しようとする試みが失敗しなければなりません。
<!ELEMENT abstract EMPTY>
<！ELEMENT抽象EMPTY>
A description is a human-readable description of what this privilege controls access to. Servers MUST indicate the human language of the description using the xml:lang attribute and SHOULD consider the HTTP Accept-Language request header when selecting one of multiple available languages.
説明は、この権限はへのアクセスを制御するかの人間が読める記述です。サーバーは、人間のXMLを使用して説明の言語を示している必要があります：lang属性を、複数の利用可能な言語のいずれかを選択する際にHTTP Accept-Language要求ヘッダを考慮すべきです。
<!ELEMENT description #PCDATA>
<！ELEMENT記述#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クライアント要求を示しています。 DAVの値：サポートされている特権セットプロパティがサポートされている特権（各特権を識別するために「[ローカル名、XML名前空間を」使用）の木です。
[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="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "gclemm"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:supported-privilege-set/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：サポートされている特権セット/> </ D：小道具> </ D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status
HTTP / 1.1 207マルチステータス
Content-Type: text/xml; charset="utf-8" Content-Length: xxx
コンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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">
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/論文/ </ D：のhref> <D：propstat> <D：小道具> <D：サポートされている特権セット> <D：サポートされている特権> <D：特権> <D：すべて/> </ D：特権> <D：抽象/> <D：説明XML：langは= "EN">任意の操作</ D：記述> <D：サポートされている特権> <D：特権> <D：読み取り/> </ D：特権> <D：説明XML：記述> <D：サポートされている特権> <D：特権> <D：読み取りACL /> </ D：langは= "EN"> </ D任意のオブジェクトを読む権限> <D ：抽象/> <D：説明XML：LANG = "EN">読むACL </ D：記述> </ D：サポートされている特権> <D：サポートされている特権> <D：特権> <D：読み取り現在-user-特権セット/> </ D：特権> <D：抽象/> <D：説明XML：LANG = "EN">現在のユーザ権限設定プロパティを読む</ D：記述> </ D：supported-特権> </ D：サポートされている特権> <D：サポートされている特権> <D：特権> <D：書き込み/> </ D：特権> <D：説明XML：langは= "EN">任意のオブジェクトを書きます< / D：記述> <D：サポートされている特権> <D：privil EGE> <D：ライトACL /> </ D：特権> <D：説明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>
ACLを書く</ D：記述> <D：抽象/> </ D：サポートされている特権> <D：サポートされている特権> <D：特権> <D：書き込みプロパティ/> </ D：特権> <D ：説明XML：LANG = "EN">特性</ Dを書く記述> </ D：サポートされている特権> <D：サポートされている特権> <D：特権> <D：ライトコンテンツ/> </ D：特権> <D：説明XML：LANG = "EN">書き込みリソースコンテンツ</ D：記述> </ D：サポートされている特権> </ D：サポートされている特権> <D：サポートされている特権> <D：特権> <D：アンロック/> </ D：特権> <D：説明XML：LANG = "EN">リソースのロックを解除</ D：記述> </ D：サポートされている特権> </ D：サポートされている特権> < / D：サポートされている特権セット> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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：現在のユーザー特権セットは、現在認証HTTPユーザに付与された権限の正確なセットを（サーバによって計算される）を含む保護された特性です。集約権限とその含まれる特権が記載されています。ユーザエージェントは、現在のプリンシパルがアクセス許可を持たないため（例えば、メニュー項目またはボタンをグレーアウトすることによって）アクションをアクセス不能にするために、そのユーザーインターフェイスを調整するために、このプロパティの値を使用することができます。このプロパティは、実際に動作を実行することなく、現在のプリンシパルが実行できる操作を決定するために有用です。
<!ELEMENT current-user-privilege-set (privilege*)> <!ELEMENT privilege ANY>
<！ELEMENT現在のユーザー特権セット（特権*）> <！ELEMENT権限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.
現在のユーザーが特定の権限が付与されている場合は、その特権は、このリソースに設定することができる権限セットに属している必要があります。したがって、DAVの各要素：現在のユーザー特権設定プロパティは、DAVから非抽象特権を識別しなければならない：サポートされている特権セットプロパティ。
5.4.1. Example: Retrieving the User's Current Set of Assigned Privileges
5.4.1. 例：割り当てられた特権のユーザの現在の設定を取得
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.
URLのhttp://www.example.com/papers/とリソースから現在のユーザー特権設定プロパティ：5.3.1からの例を続けると、この例では、DAVを要求しているクライアントを示しています。要求を行っているプリンシパルのユーザー名は「khare」であり、ダイジェスト認証が要求に使用されています。読み込み権限：ユーザー名「khare」と校長は、DAVを付与されています。読みACLおよびDAV：：読み取り権限DAV含まれていますDAVがあるので読みを電流ユーザー特権セット特権、ACLプロパティを読み取ることができ、ユーザ名「khare」と校長、およびDAV（5.3.1項を参照してください） ：現在のユーザー特権設定プロパティ。しかし、DAV：すべて、DAV：読み取りACL、DAV：書き込み-ACLおよびDAV：読み取り、現在のユーザー特権セット特権がDAVの値に記載されていない：現在のユーザー特権セット、以来（この例では）彼らは抽象的権限です。 DAV：ユーザ名「khare」と校長がその主な書き込み権限を付与するACEに記載されていないため、書き込みがリストされていません。
>> Request <<
>>リクエスト<<
PROPFIND /papers/ HTTP/1.1 Host: www.example.com Content-type: text/xml; charset="utf-8" Content-Length: xxx Depth: 0 Authorization: Digest username="khare", realm="users@example.com", nonce="...", uri="/papers/", response="...", opaque="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "khare"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:current-user-privilege-set/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：現在のユーザー特権セット/> </ D ：プロップ> </ D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/紙/ </ D：HREF> <D：propstat> <D：プロペラ> <D：現在のユーザー特権セット> <D：特権> <D：読み取り/> </ D：特権> </ D：現在のユーザー特権セット> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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）のリストを指定し、保護プロパティです。
<!ELEMENT acl (ace*) >
<！ELEMENTのACL（エース*）>
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：エース要素は、単一のプリンシパルに付与または拒否するためのいずれかの権限のセットを指定します。 DAV場合：ACLプロパティが空で、何のプリンシパルは任意の権限を付与されません。
<!ELEMENT ace ((principal | invert), (grant|deny), protected?, inherited?)>
<！ELEMENTエース（（元本|反転）、（助成金|？拒否）、保護された?,継承）>
The DAV:principal element identifies the principal to which this ACE applies.
DAV：主要要素は、このACEが適用されるプリンシパルを識別する。
<!ELEMENT principal (href | all | authenticated | unauthenticated | property | self)>
<！ELEMENTプリンシパル（HREF |すべて|認証さ|認証されていない|プロパティ|自己）>
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に含まれるURLによって識別される主要：HREF。
The current user always matches DAV:all.
現在のユーザーは常にDAVにマッチする：すべて。
<!ELEMENT all EMPTY>
<！ELEMENTすべてEMPTY>
The current user matches DAV:authenticated only if authenticated.
認証された場合にのみ認証された：現在のユーザーがDAV一致します。
<!ELEMENT authenticated EMPTY>
<！ELEMENTは、EMPTY、認証しました>
The current user matches DAV:unauthenticated only if not authenticated.
認証されていない認証されていない場合にのみ：現在のユーザーがDAV一致します。
<!ELEMENT unauthenticated EMPTY>
<！ELEMENT認証されていないEMPTY>
DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. For a given request, the user matches either DAV:authenticated, or DAV:unauthenticated, but not both (that is, DAV:authenticated and DAV:unauthenticated are disjoint sets).
DAV：認証済み、およびDAV：認証されていないすべてのDAVの労働組合です。認証、またはDAV：認証されていない、両方ではなく（すなわちDAVである：認証およびDAV：認証されていないが互いに素な集合である）特定の要求のために、ユーザは、DAVのいずれかと一致します。
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.
、HREFプリンシパルを識別します、DAVのURI値がHREF XML要素：そのリソースの識別されたプロパティの値は、多くても1つのDAVに含まれている場合にのみ、リソースのACLプロパティ：DAVにおけるプロパティ主要：現在のユーザがDAVと一致しますそして、現在のユーザがある（またはのメンバーである）は、その主体として認証されます。例えば、DAV場合：プロパティ要素が含まれる<DAV：所有者/>リソースの所有者プロパティ：現在のユーザーがDAVにより同定主にマッチとして認証された場合にのみプロパティプリンシパル、現在のユーザーがDAVに一致するであろう。
<!ELEMENT property ANY>
<！ELEMENTプロパティ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で自己：現在のユーザーがDAVに一致するプリンシパルがグループである場合、そのリソースが主である場合にのみ、リソースのACLプロパティを、その主は、現在のユーザに一致するか、そのグループのメンバーは、現在のユーザが一致します。
<!ELEMENT self EMPTY>
<！ELEMENT自己EMPTY>
Some servers may support ACEs applying to those users NOT matching the current principal, e.g., all users not in a particular group. This can be done by wrapping the DAV:principal element with DAV:invert.
一部のサーバーは、現在のプリンシパルを一致しないものをユーザーに適用するACEをサポートすることができ、例えば、特定のグループ内のすべてのユーザーではありません。これは、DAVをラップすることによって行うことができます。DAVとの主な要素：反転。
<!ELEMENT invert principal>
<！ELEMENT反転プリンシパル>
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：助成金やDAV：要素を否定するには、特権のセットが指定されたプリンシパルに付与または拒否するかのいずれかを指定します。 DAV：助成金やDAV：リソースのACLがDAVに指定された非抽象要素のみを含まなければならない：そのリソースのサポート特権セットDAVの要素を否定します。
<!ELEMENT grant (privilege+)> <!ELEMENT deny (privilege+)> <!ELEMENT privilege ANY>
<！ELEMENTの助成金（特典+）> <！ELEMENT拒否（特典+）> <！ELEMENT権限ANY>
A server indicates an ACE is protected by including the DAV:protected element in the ACE. If the ACL of a resource contains an ACE with a DAV:protected element, an attempt to remove that ACE from the ACL MUST fail.
ACEで保護された要素：サーバは、ACEは、DAVを含めることによって保護されていることを示します。リソースのACLは、DAVとACEが含まれている場合：保護された要素を、ACLからそのACEを削除しようとする試みは失敗しなければなりません。
<!ELEMENT protected EMPTY>
<！ELEMENT 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の存在：HREF要素：継承された要素は、このACEは、DAVに含まれている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)>
<！ELEMENTが継承された（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:
URLのhttp://www.example.com/papers/のリソースからACLプロパティ：セクション5.3.1および5.4.1からの例を続けると、この例では、DAVを要求しているクライアントを示しています。このACLで定義された2つのACEがあります。
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.
ACE＃1：URL http://www.example.com/acl/グループ/メンテナ（サイトのメンテナのグループ）によって識別されるグループは、DAVを付与されている：権限を記述します。 （この例では）のでDAV：特権（5.3.1項を参照してください） - ACLの書き込み、これはまた、アクセス制御リストを変更することができ、「メンテナ」基を意味する：書き込みは、DAVが含まれています。
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：すべての）：読み取り権限DAVが付与されます。リードDAVが含まれています：（この例の）DAVのでDAV-ACLを読み取る：読み取り電流ユーザー特権セット、これは（「保守」グループのすべてのメンバーを含む）すべてのユーザーがDAVを読み取ることができることを意味：ACLプロパティそしてDAV：現在のユーザー特権設定プロパティ。
>> 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="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "masinter"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<D:propfind xmlns:D="DAV:"> <D:prop> <D:acl/> </D:prop> </D:propfind>
<D：PROPFIND用のxmlns：D = "DAV："> <D：プロペラ> <D：ACL /> </ D：プロップ> </ D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/papers/ </ D：HREF> <D：propstat> <D：小道具> <D：ACL> <D：ACE> <D：主> <D：HREF> http://www.example.com/acl/groups/maintainers </ D：HREF> </ D：主> <D ：助成金> <D：特権> <D：書き込み/> </ D：特権>
</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>
</ D：付与> </ D：ACE> <D：ACE> <D：主> <D：すべての/> </ D：主> <D：グラント> <D：特権> <D：読み取り/> </ D：特権> </ D：付与> </ D：ACE> </ D：ACL> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D： propstat> </ D：レスポンス> </ 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
<助成金専用>拒否ACEはサポートされていません。
<no-invert> Inverted ACEs are not supported
<無反転>倒立ACEはサポートされていません。
<deny-before-grant> All deny ACEs must occur before any grant ACEs
<拒否・ビフォア・グラント>すべてのACEがどの助成金のACEの前に発生しなければなら拒否します
<required-principal> Indicates which principals are required to be present
<所要主>は、プリンシパルが存在することが要求されることを示し
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
<！ELEMENTのACL-制限（助成金専用?,無反転?,拒否・ビフォア・助成金?,必要-校長？）>
This element indicates that ACEs with deny clauses are not allowed.
この要素は拒否条項付きのACEが許可されていないことを示しています。
<!ELEMENT grant-only EMPTY>
<！ELEMENTの助成金専用EMPTY>
This element indicates that ACEs with the <invert> element are not allowed.
この要素は、<反転>要素とのACEが許可されていないことを示しています。
<!ELEMENT no-invert EMPTY>
<！ELEMENT無反転EMPTY>
This element indicates that all deny ACEs must precede all grant ACEs.
この要素は、すべてのACEは、すべての補助金のACEに先行しなければなら拒否することを示しています。
<!ELEMENT deny-before-grant EMPTY>
<！ELEMENTが拒否する前に、助成金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*)>
<！ELEMENT必要-元本（すべて|？認証された|？認証されていない？|自己|？のhref * |プロパティ*）>
For example, the following element requires that the ACL contain a
たとえば、以下の要素は、ACLが含まれている必要があります
DAV:owner property ACE:
DAV：ownerプロパティのACE：
<D:required-principal xmlns:D="DAV:"> <D:property><D:owner/></D:property> </D:required-principal>
<D：所要主のxmlns：D = "DAV："> <D：プロパティ> <D：オーナー/> </ D：プロパティ> </ D：所要プリンシパル>
In this example, the client requests the value of the DAV:acl-restrictions property. Digest authentication provides credentials for the principal operating the client.
ACL-制約プロパティ：この例では、クライアントは、DAVの値を要求します。ダイジェスト認証は、クライアントを操作する主体の資格を提供します。
>> 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="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "srcarter"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:acl-restrictions/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：ACL-制限/> </ D：小道具> < / D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/紙/ </ D：HREF> <D：propstat> <D：プロペラ> <D：ACL-制限> <D：グラント専用/> <D：所要主> <D：すべての/> </ D：ステータス> HTTP / 1.1 200 OK </ D：所要主> </ D：ACL-制限> </ D：プロペラ> <Dステータス> </ D：propstat> </ D：レスポンス> </ 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のセットが含まれています。リソース上の権限を持っているために、そのリソース（DAVで指定：そのリソースのACLプロパティを）上のACLがなければならないだけでなく、権限を付与しますが、その各リソースのACLは、DAVで識別しなければならない：継承された-ACL-セットそのリソースのプロパティ。事実上、現在のACLによって付与された権限は、各継承ACLによって付与された権限とAND演算されています。
<!ELEMENT inherited-acl-set (href*)>
<！ELEMENT継承-ACL-セット（HREFの*）>
This protected property of a resource contains a set of URLs that identify the root collections that contain the principals that are available on the server that implements this resource. A WebDAV Access Control Protocol user agent could use the contents of DAV:principal-collection-set to retrieve the DAV:displayname property (specified in Section 13.2 of [RFC2518]) of all principals on that server, thereby yielding human-readable names for each principal that could be displayed in a user interface.
リソースのこの保護されたプロパティは、このリソースを実装して、サーバー上で利用可能なプリンシパルが含まれているルートのコレクションを識別するURLのセットが含まれています。 WebDAVのアクセス制御プロトコルのユーザエージェントは、DAVの内容を使用することができます：DAVを取得する主なコレクションセット：そのサーバー上のすべてのプリンシパルの表示名プロパティが（[RFC2518]のセクション13.2で指定された）、それによってのための人間が読める名前をもたらしますユーザインタフェースに表示することができる各プリンシパル。
<!ELEMENT principal-collection-set (href*)>
<！ELEMENT元本-コレクションセット（HREF *）>
Since different servers can control different parts of the URL namespace, different resources on the same host MAY have different DAV:principal-collection-set values. The collections specified in the DAV:principal-collection-set MAY be located on different hosts from the resource. The URLs in DAV:principal-collection-set SHOULD be http or https scheme URLs. For security and scalability reasons, a server MAY report only a subset of the entire set of known principal collections, and therefore clients should not assume they have retrieved an exhaustive listing. Additionally, a server MAY elect to report none of the principal collections it knows about, in which case the property value would be empty.
主なコレクション - 設定値：異なるサーバーがURL名前空間の異なる部分を制御することができるので、同じホスト上の異なるリソースが異なるDAVを持っているかもしれません。 DAVで指定されたコレクション：元本-コレクションセットは、リソースとは別のホスト上に配置することができます。 DAV内のURL：主なコレクションセットは、HTTPまたはHTTPSスキームのURLであるべきです。セキュリティとスケーラビリティの理由から、サーバが知られている主要なコレクションの全セットのサブセットだけを報告することがあり、そのためクライアントは、彼らが徹底的リストを取得したと仮定してはいけません。また、サーバは、プロパティの値が空になり、その場合には、それは知っている主なコレクション、のどれを報告しないことを選ぶことができます。
The value of DAV:principal-collection-set gives the scope of the DAV:principal-property-search REPORT (defined in Section 9.4). Clients use the DAV:principal-property-search REPORT to populate their user interface with a list of principals. Therefore, servers that limit a client's ability to obtain principal information will interfere with the client's ability to manipulate access control lists, due to the difficulty of getting the URL of a principal for use in an ACE.
DAVの値：主-プロパティ調査報告書（セクション9.4で定義される）：主要コレクションセットは、DAVの範囲を与えます。プリンシパルのリストに自分のユーザー・インタフェースを移入する主な財産 - 検索レポート：クライアントはDAVを使用しています。このため、ACEで使用するためのプリンシパルのURLを得ることの難しさに、アクセス制御リストを操作するクライアントの機能を妨害する主な情報を得るために、クライアントの能力を制限するサーバ。
In this example, the client requests the value of the DAV:principal-collection-set property on the collection resource identified by URL http://www.example.com/papers/. The property contains the two URLs, http://www.example.com/acl/users/ and http:// www.example.com/acl/groups/, both wrapped in DAV:href XML elements. Digest authentication provides credentials for the principal operating the client.
URLのhttp://www.example.com/papers/で識別される収集資源の元本-コレクションセットプロパティ：この例では、クライアントは、DAVの値を要求します。 // www.example.com/acl/groups/、DAVに包まれた両方：hrefのXML要素プロパティは、2つのURL、http://www.example.com/acl/users/とHTTPが含まれています。ダイジェスト認証は、クライアントを操作する主体の資格を提供します。
The client might reasonably follow this request with two separate PROPFIND requests to retrieve the DAV:displayname property of the members of the two collections (/acl/users and /acl/groups). This information could be used when displaying a user interface for creating access control entries.
2つのコレクション（/ ACL /ユーザおよび/ ACL /グループ）のメンバーの表示名プロパティ：クライアントには、合理的にDAVを取得するには、2つの別々のPROPFIND要求とこの要求に従うことがあります。アクセス制御エントリを作成するためのユーザインタフェースを表示するときに、この情報を使用することができます。
>> Request <<
>>リクエスト<<
PROPFIND /papers/ HTTP/1.1 Host: www.example.com Content-type: text/xml; charset="utf-8" Content-Length: xxx Depth: 0 Authorization: Digest username="yarong", realm="users@example.com", nonce="...", uri="/papers/", response="...", opaque="..."
PROPFIND /論文/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "yarong"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、レスポンス= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:principal-collection-set/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：主捕集設定/> </ D：小道具> </ D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/紙/ </ D：HREF> <D：propstat> <D：プロペラ> <D：主捕集セット> <D：HREF> http://www.example.com/acl/users/ </ D： HREF> <D：HREF> http://www.example.com/acl/groups/ </ D：HREF> </ D：主捕集セット> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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.
所有者は、DAV：サポートされている特権セット、DAV：現在のユーザー特権セット、およびDAV：ACLプロパティ次の例では、アクセス制御情報は、DAVの値をフェッチするPROPFINDメソッドを使用して取得することができる方法を示しています。
>> 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="..."
PROPFIND /トップ/コンテナ/ HTTP / 1.1ホスト：www.example.comコンテンツタイプ：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX深さ：0認証：ダイジェストユーザ名= "EJW"、領域= "users@example.com"、ナンス=」... "URI =" /トップ/コンテナ/ "レスポンス=" ... "不透明=" ...」
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：小道具> <：オーナー/ D> <D：サポートされている特権セット/ > <D：現在のユーザー特権セット/> <D：ACL /> </ D：プロップ> </ D：PROPFIND>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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/>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：A = "http://www.example.com/acl/"> <D ：レスポンス> <D：HREF> http://www.example.com/top/container/ </ D：HREF> <D：propstat> <D：プロペラ> <D：所有者> <D：HREF>のhttp： //www.example.com/users/gclemm </ D：HREF> </ D：所有者> <D：サポートされている特権セット> <D：サポートされている特権> <D：特権> <D：すべて/> </ D：特権> <D：抽象/>
<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>
<D：現在のユーザー特権セット> <D：特権> <D：読み取り/> </ D：特権> <D：特権> <D：読み取りACL /> </ D：特権> </ D ：現在のユーザー特権セット> <D：ACL> <D：ACE> <D：主> <D：HREF> http://www.example.com/users/esedlar </ D：HREF> </ D：主> <D：グラント> <D：特権> <D：読み取り/> </ D：特権> <D：特権> <D：書き込み/> </ D：特権> <D：特権> <D ：読み取りACL /> </ D：特権> </ D：付与> </ D：ACE> <D：ACE> <D：主> <D：HREF> http://www.example.com/groups / mrktng </ D：HREF> </ D：主> <D：拒否> <D：特権> <D：読み取り/> </ D：特権> </ D：拒否> </ D：ACE> <D ：エース> <D：主> <D：プロパティ> <D：オーナー/> </ D：プロパティ> </ D：主> <D：グラント> <D：特権> <D：読み取りACL /> < / D：特権> <D：特権> <D：ライトACL /> </ D：特権> </ D：付与> </ D：ACE> <D：ACE> <D：主> <D：すべて/> </ D：元金> <D：助成金> <D：特権> <D：読み取り/> </ D：特権> </ D：助成金> <D：継承された> <D：のhref>のhttp：// www.example.com/top </ D：HREF> </ D：継承> </ D：ACE> </ D：ACL> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D ：ステータス> </ D：propstat> </ D：レスポンス> </ 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.
DAVの値：hrefのXML要素、このリソースを所有するプリンシパルのURLを含む：所有者プロパティは、単一のDAVです。
The value of the DAV:supported-privilege-set property is a tree of supported privileges (using "[XML Namespace , localname]" to identify each privilege):
DAVの値：サポートされている特権セットプロパティがサポートされている特権（各特権を識別するために「[ローカル名、XML名前空間を」使用）の木です。
[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：読み取り、およびDAV：現在のユーザー特権設定プロパティは、2つの権限、DAVが含まれている読み取りACLを。リソースのACLプロパティ：これは、現在の認証されたユーザーのみがリソースを読み、DAVを読み取る機能を有していることを示しています。 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/のユーザー/ esedlarで識別されるプリンシパルは、DAVを付与された：DAV、読み：書き込み、およびDAV：読み取りACL権限を。
ACE #2: The principals identified by the URL http://www.example.com/ groups/mrktng are denied the DAV:read privilege. In this example, the principal URL identifies a group.
ACE＃2：読み取り特権：URL http://www.example.com/グループ/ mrktngで識別されるプリンシパルは、DAVを拒否されます。この例では、主URLは、グループを識別する。
ACE #3: In this ACE, the principal is a property principal, specifically the DAV:owner property. When evaluating this ACE, the value of the DAV:owner property is retrieved, and is examined to see if it contains a DAV:href XML element. If so, the URL within the DAV:href element is read, and identifies a principal. In this ACE, the owner is granted DAV:read-acl, and DAV:write-acl privileges.
ACE＃3：所有者プロパティ：このACEは、主は、プロパティ主、具体DAVです。このACEを評価する際には、DAVの値：所有者プロパティが取得され、それがDAV含まれているかどうかを確認するために検査さ：hrefのXML要素を。その場合は、DAV内のURL：hrefの要素を読み込み、およびプリンシパルを識別しています。読み取りACL、およびDAV：書き込みACL権限このACEでは、所有者は、DAVが付与されます。
ACE #4: This ACE grants the DAV:all principal (all users) the DAV:read privilege. This ACE is inherited from the resource http:// www.example.com/top, the parent collection of this resource.
ACE＃4：すべてのプリンシパル（すべてのユーザー）DAV：：読み取り権限このACEは、DAVを付与します。 // www.example.com/top、このリソースの親コレクション：このACEは、リソースをhttpから継承されます。
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は）[RFC3530]のWindows NT上とのNFSv4でのACLと同様の方法で評価されています。 ACLは、アクセスがWebDAVの要求のために許可されるかどうかを決定するために評価されます。 ACEは特定の順序で維持され、現在の要求によって必要な権限のすべてが付与されるまで、ACLの評価が終了し、アクセスが許可された時点で、評価されます。 ACLの評価時に、（現在のユーザーをマッチング）<拒否> ACEがまだ付与されていない特権のために発生した、場合、ACLの評価が終了し、アクセスが拒否されました。すべての必要な権限を持っているに失敗すると、拒否されるアクセスで結果を付与されました。
Note that the semantics of many other existing ACL systems may be represented via this mechanism, by mixing deny and grant ACEs. For example, consider the standard "rwx" privilege scheme used by UNIX. In this scheme, if the current user is the owner of the file, access is granted if the corresponding privilege bit is set and denied if not set, regardless of the permissions set on the file's group and for the world. An ACL for UNIX permissions of "r--rw-r--" might be constructed like:
他の多くの既存のACLシステムのセマンティクスが拒否およびACEを付与混合することにより、この機構を介して表現されてもよいことに留意されたいです。たとえば、UNIXで使用される標準的な「rwxの」特権スキームを検討してください。現在のユーザーがファイルの所有者である場合は、対応する権限ビットは関係なく、ファイルのグループで、世界のために設定されたアクセス権の設定と設定されていない場合は拒否された場合は、この方式では、アクセスが許可されます。 「R - RW-r--の」のUNIXパーミッションのためのACLは、次のように構築されることがあります。
<D:acl> <D:ace> <D:principal> <D:property><D:owner/></D:property> </D:principal> <D:grant> <D:privilege><D:read/></D:privilege> </D:grant> </D:ace> <D:ace> <D:principal> <D:property><D:owner/></D:property> </D:principal> <D:deny> <D:privilege><D:all/></D:privilege> </D:deny> </D:ace> <D:ace> <D:principal> <D:property><D:group/></D:property> </D:principal> <D:grant> <D:privilege><D:read/></D:privilege> <D:privilege><D:write/></D:privilege> </D:grant> </D:ace>
<D：ACL> <D：ACE> <D：主> <D：プロパティ> <D：オーナー/> </ D：プロパティ> </ D：主> <D：グラント> <D：特権> <D ：特権> </ D：付与> </ D：ACE> <D：ACE> <D：主> <D：プロパティ> <D：オーナー/> </ D：プロパティ> </> </ D読み取り/ D：主> <D：拒否> <D：特権> <D：すべての/> </ D：特権> </ D：拒否> </ D：ACE> <D：ACE> <D：プリンシパル> < D：プロパティ> <D：グループ/> </ D：プロパティ> </ D：主> <D：グラント> <D：特権> <D：読み取り/> </ D：特権> <D：特権> < D：書き込み/> </ D：特権> </ D：助成金> </ D：エース>
<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>
<D：ACE> <D：主> <D：プロパティ> <D：グループ/> </ D：プロパティ> </ D：主> <D：拒否> <D：特権> <D：すべての/> < / D：特権> </ D：ACE> <D：ACE> <D：主> <D：すべて> </ D：主> <D：グラント> <D：> </ D拒否する権限> <D ：特権> </ D：付与> </ D：エース> </ D：ACL> /> </ D読みます
and the <acl-restrictions> would be defined as:
そして、<ACL-制限は>のように定義されます。
<D:no-invert/> <D:required-principal> <D:all/> <D:property><D:owner/></D:property> <D:property><D:group/><D:group/> </D:required-principal>
<D：無反転/> <D：所要主> <D：すべての/> <D：プロパティ> <D：オーナー/> </ D：プロパティ> <D：プロパティ> <D：グループ/> < D：グループ/> </ D：所要プリンシパル>
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.
（上記のACLでのものより主要その他を指定するACEを追加）、または<D：<許可-元本D>クライアントが、<ACL-制限を>従う含めたにも関わらず、UNIXサーバーからのエラーを得ることができることに注意してください：ACE-競合>これらの特定の実装セマンティクスは宣言単純な（しかし、一般的な）制限を捕捉するには余りにも複雑であるように、（上記の例でのACEの順序を変更しようとすることによります）。
This section defines the impact of access control functionality on existing methods.
このセクションでは、既存の方法でアクセス制御機能の影響を定義します。
The WebDAV ACL mechanism requires the usage of HTTP method "preconditions" as described in section 1.6 of RFC3253 for ALL HTTP methods. All HTTP methods have an additional precondition called DAV:need-privileges. If an HTTP method fails due to insufficient privileges, the response body to the "403 Forbidden" error MUST contain the <DAV:error> element, which in turn contains the
すべてのHTTPメソッドのRFC3253のセクション1.6で説明したようにWebDAVのACLメカニズムはHTTPメソッド「前提条件」の使用を必要とします。必要-特権：すべてのHTTPメソッドは、DAVと呼ばれる追加の前提条件があります。今度は含まれています：<エラーDAV>要素、HTTPメソッドが不十分な特権に失敗した場合、「403禁止」エラーへの応答本体は含まれていなければなりません
<DAV:need-privileges> element, which contains one or more <DAV:resource> elements indicating which resource had insufficient privileges, and what the lacking privileges were:
1つ以上含まれています。<DAV必要-特権>要素、<DAV：リソースを>リソースが不十分な権限を持っていたかを示す要素、および欠けている権限は何でしたか：
<!ELEMENT need-privileges (resource)* > <!ELEMENT resource ( href , privilege ) >
<！ELEMENTの必要性 - 権限（リソース）*> <！ELEMENTリソース（HREF、特権）>
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ホスト：www.example.com先：http://www.example.com/c/d
>> Response <<
>>回答<<
HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 403禁止のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<D：エラーのxmlns：D = "DAV："> <D：必要-権限> <D：リソース> <D：HREF> / A </ D：のhref> <D：特権> <D：アンバインド/> < / D：特権> </ D：リソース> <D：リソース> <D：HREF> / C </ D：HREF> <D：特権> <D：結合/> </ D：特権> </ D：リソース> </ D：必要-権限> </ D：エラー>
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レスポンスヘッダ内のフィールドとして、「アクセス制御」を返さなければなりません。 DAVヘッダ内の「アクセス制御」の値は、サーバがすべてのMUSTレベルの要件と、この文書で指定された必要な機能をサポートしていることを示す必要があります。
>> Request <<
>>リクエスト<<
OPTIONS /foo.html HTTP/1.1 Host: www.example.com Content-Length: 0
OPTIONS /foo.html HTTP / 1.1ホスト：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、アクセス制御許可：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.
リソースが移動要求による、ある場所から別の場所へ移動したときに、非継承および非保護DAVのACE：リソースのACLプロパティは、変更してはいけません、または移動要求は失敗します。継承され、保護されたACEの取り扱いについては、意図的に、彼らはACEの継承と保護を実装する方法では、サーバの実装に柔軟性を与えるために定義されていません。
The DAV:acl property on the resource at the destination of a COPY MUST be the same as if the resource was created by an individual resource creation request (e.g., MKCOL, PUT). Clients wishing to preserve the DAV:acl property across a copy need to read the DAV:acl property prior to the COPY, then perform an ACL operation on the new resource at the destination to restore, insofar as this is possible, the original access control list.
DAV：コピー先のリソースのACLプロパティは、リソースが個々のリソースの作成要求によって作成された場合（例えば、MKCOLは、PUT）と同じでなければなりません。 DAVを維持したいクライアント：ACLプロパティをコピー全体では、DAV読みする必要があります：COPY前のACLプロパティを、そして、これが可能である限り、元のアクセス制御を回復するために先に新しいリソースのACLの操作を実行リスト。
A lock on a resource ensures that only the lock owner can modify ACEs that are not inherited and not protected (these are the only ACEs that a client can modify with an ACL request). A lock does not protect inherited or protected ACEs, since a client cannot modify them with an ACL request on that resource.
リソースのロックはロック所有者が継承されていないと（これらは、クライアントがACL要求に変更することができるということのみのACEです）保護されていないACEを変更できるようになります。クライアントがそのリソースのACL要求でそれらを変更することはできませんので、ロックは、継承されたまたは保護されたACEを保護しません。
The ACL method modifies the access control list (which can be read via the DAV:acl property) of a resource. Specifically, the ACL method only permits modification to ACEs that are not inherited, and are not protected. An ACL method invocation modifies all non-inherited and non-protected ACEs in a resource's access control list to exactly match the ACEs contained within in the DAV:acl XML element (specified in Section 5.5) of the request body. An ACL request body MUST contain only one DAV:acl XML element. Unless the non-inherited and non-protected ACEs of the DAV:acl property of the resource can be updated to be exactly the value specified in the ACL request, the ACL request MUST fail.
リソースの：ACL方法は、（ACLプロパティDAVを介して読み取ることができる）アクセス制御リストを変更します。具体的には、ACLの方法は、継承されず、保護されていないのACEへの変更を可能にします。 ACLのメソッド呼び出しは、リソースのアクセス制御リスト内のすべての非継承および非保護ACEは、正確にDAV中に含まれるのACEに一致するように変更しますリクエストボディの（5.5節で指定）のACL XML要素を。 ACL XML要素：ACLのリクエストボディは、一つだけDAVを含まなければなりません。 DAVの非継承および非保護のACEのない限り、リソースのACLプロパティはACL要求で指定された正確値に更新することができ、ACL要求が失敗しなければなりません。
It is possible that the ACEs visible to the current user in the DAV:acl property may only be a portion of the complete set of ACEs on that resource. If this is the case, an ACL request only modifies the set of ACEs visible to the current user, and does not affect any non-visible ACE.
ACLプロパティのみ、そのリソース上のACEの完全なセットの一部であってもよい。DAVで現在のユーザに見えるACEがいる可能性があります。この場合、ACLのリクエストは、現在のユーザに見えるACEのセットを変更し、そして任意の非可視ACEに影響を及ぼしません。
In order to avoid overwriting DAV:acl changes by another client, a client SHOULD acquire a WebDAV lock on the resource before retrieving the DAV:acl property of a resource that it intends on updating.
DAV上書きを避けるために：それは更新に意図したリソースのACLプロパティ：別のクライアントでのACLの変更を、クライアントがDAVを取得する前に、リソース上のWebDAVロックを取得すべきです。
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を追加または削除します。これを実現するために、クライアントは、DAVの値取得するために、PROPFINDメソッドを使用します。ACLプロパティを、すべての継承と保護されたACEを削除するために返されたアクセス制御リストを解析する（これらのACEは、DAVでタグ付けされています継承され、DAV：保護されたXML要素）。非継承、非保護ACEの残りのセットでは、クライアントは、ACLメソッドのリクエストボディの最後のACEのセットを送信する前に、一つ以上のACEを追加または削除することができます。
An implementation MUST enforce the following constraints on an ACL request. If the constraint is violated, a 403 (Forbidden) or 409 (Conflict) response MUST be returned and the indicated XML element MUST be returned as a child of a top level DAV:error element in an XML response body.
実装は、ACLのリクエストに応じて、以下の制約を強制しなければなりません。制約に違反する場合は、403（禁止）または409（競合）応答が返されなければならないと指示されたXML要素は、トップレベルのDAVの子として返さなければならない：XMLレスポンスボディのエラー要素。
Though these status elements are generally expressed as empty XML elements (and are defined as EMPTY in the DTD), implementations MAY return additional descriptive XML elements as children of the status element. Clients MUST be able to accept children of these status elements. Clients that do not understand the additional XML elements should ignore them.
これらの状態要素は、一般に、空のXML要素（およびDTDでEMPTYとして定義される）として表現されているが、実装は、状態要素の子として追加の説明XML要素を返すことができます。クライアントは、これらのステータス要素の子どもたちを受け入れることができなければなりません。追加のXML要素を理解していないクライアントは、それらを無視すべきです。
(DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST NOT conflict with each other. This is a catchall error code indicating that an implementation-specific ACL restriction has been violated.
（DAV：無エース紛争）：ACL要求で提出ACEは互いに競合しないようにしてください。これは、実装固有のACLの制限に違反したことを示すキャッチオールエラーコードです。
(DAV:no-protected-ace-conflict): The ACEs submitted in the ACL request MUST NOT conflict with the protected ACEs on the resource. For example, if the resource has a protected ACE granting DAV:write to a given principal, then it would not be consistent if the ACL request submitted an ACE denying DAV:write to the same principal.
（DAV：無保護-ACE-紛争）：ACL要求に提出したACEは、リソース上の保護されたACEと競合してはなりません。リソースは、DAVを付与保護ACEを有する場合、例えば：同じ主に書き込む：ACL要求がDAVを拒否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：無継承-ACE-紛争）：ACL要求に提出したACEは、リソースに継承されたACEと競合してはなりません。リソースは、DAVを付与する親コレクションからACEを継承する場合、たとえば、次のように同じ校長に書き込む：与えられたプリンシパルに書き込みACL要求がDAVを拒否ACEを提出した場合、それは一貫していないでしょう。このエラーの報告は実装依存となります注意してください。実装はこのエラーを報告したり、ACEを設定することができ、その後、通常のACEの評価規則は、新しいACEは、特定のプリンシパルに使用可能な特権に影響があるかどうかを決定させる必要があります。
(DAV:limited-number-of-aces): The number of ACEs submitted in the ACL request MUST NOT exceed the number of ACEs allowed on that resource. However, ACL-compliant servers MUST support at least one ACE granting privileges to a single principal, and one ACE granting privileges to a group.
（DAV：限られた数の-エース）：ACLのリクエストで送信ACEの数は、そのリソース上で許可ACEの数を超えてはなりません。しかし、ACL準拠のサーバーは、単一のプリンシパルに権限を付与する少なくとも一つのACE、およびグループに権限を付与する1つのACEをサポートしなければなりません。
(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all non-inherited grant ACEs.
（DAV：拒否・ビフォア・グラント）：すべての非継承ACEは、すべての非継承の許可ACEを先行しなければなりません拒否する。
(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：助成金のみ）：ACL要求に提出ACEは拒否ACEを含んではいけません。 （5.6.1項で定義される）助成金のみの制約：この前提条件は、リソースのACLの制限がDAVを含める場合にのみ適用されます。
(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：非反転）：反転要素：ACLのリクエストは、DAVを含めることはできません。 （5.6.2項で定義される）無反転制約：この前提条件は、リソースのACLセマンティクスがDAVを含んでいる場合にのみ適用されます。
(DAV:no-abstract): The ACL request MUST NOT attempt to grant or deny an abstract privilege (see Section 5.3).
（DAV：無抽象）：ACL要求は抽象的権限を（5.3節を参照）を許可または拒否することを試みてはいけません。
(DAV:not-supported-privilege): The ACEs submitted in the ACL request MUST be supported by the resource.
（DAV： - サポートされていない特権）：ACL要求に提出ACEは、リソースによってサポートしなければなりません。
(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：-必要な欠落-校長）：そのリソースのACLの意味で必要な、主要なXML要素（5.5節を参照）：ACL要求の結果は、DAVで識別された各校長のために少なくとも一つのACEを持たなければなりません。
(DAV:recognized-principal): Every principal URL in the ACL request MUST identify a principal resource.
（DAV：認識-校長）：ACL要求のすべての主要なURLは、主要リソースを特定しなければなりません。
(DAV:allowed-principal): The principals specified in the ACEs submitted in the ACL request MUST be allowed as principals for the resource. For example, a server where only authenticated principals can access resources would not allow the DAV:all or DAV:unauthenticated principals to be used in an ACE, since these would allow unauthenticated access to resources.
（DAV：せ-主）：ACLのリクエストで送信するACEに指定されたプリンシパルは、リソースのプリンシパルとして許容されなければなりません。たとえば、唯一の認証されたプリンシパルがリソースにアクセスできるサーバはDAVを許可しません：すべてまたはDAV：認証されていないプリンシパルは、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ヘッダ内の情報によって認証されたユーザ「守備」は、URLによって識別される主要http://www.example.com/users/esedlar（すなわち、ユーザ「esedlar」）を付与読み取りおよび書き込み特権は、リソースの読み取り-ACLおよび書き込み-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="..."
ACL /トップ/コンテナ/ HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "守備"、領域= "users@example.com"、ナンス= "... " URI ="/トップ/コンテナ/"、応答= "... "不透明=" ..."
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のACLのxmlns：D = "DAV："> <D：ACE> <D：主> <D：HREF>のhttp：// WWW .example.comの/ユーザー/ esedlar </ D：HREF> </ D：主> <D：グラント> <D：特権> <D：読み取り/> </ D：特権> <D：特権> <D：書き込み/> </ D：特権> </ D：助成金> </ D：エース>
<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>
<D：ACE> <D：主> <D：プロパティ> <D：オーナー/> </ D：プロパティ> </ D：主> <D：グラント> <D：特権> <D：読み取りACL / > </ D：特権> <D：特権> <D：ライトACL /> </ D：特権> </ D：付与> </ D：ACE> <D：ACE> <D：主> <D ：すべての/> </ D：主> <D：グラント> <D：特権> <D：読み取り/> </ D：特権> </ D：付与> </ 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ヘッダ内の情報によって認証次の要求、ユーザ「守備」において、URL http://www.example.com/users/esedlar（すなわち、ユーザ「esedlar」）によって識別される主体を拒否しようと書きます特権。要求前に、DAV：DAV所有者：リソースのACLプロパティは、保護されたACE（5.5.3項を参照）DAVを許可を含ま読み、DAV：権限を記述します。 URL http://www.example.com/ユーザー/ 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="..."
ACL /トップ/コンテナ/ HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "守備"、領域= "users@example.com"、ナンス= "... " URI ="/トップ/コンテナ/"、応答= "... "不透明=" ..."
<?xml version="1.0" encoding="utf-8" ?> <D:acl xmlns:D="DAV:"> <D:ace> <D:principal>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のACLのxmlns：D = "DAV："> <D：ACE> <D：プリンシパル>
<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>
<D：HREF> http://www.example.com/users/esedlar </ D：HREF> </ D：主> <D：拒否> <D：特権> <D：書き込み/> </ D：特権> </ D：拒否> </ D：エース> </ D：ACL>
>> Response <<
>>回答<<
HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 403禁止のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:no-protected-ace-conflict/> </D:error>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：エラーのxmlns：D = "DAV："> <D：無保護-ACE-衝突/> </ D：エラー>
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上のアクセス制御リストを変更しようとします。このリソースは、2つの継承されたACEを持っています。
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.
// www.example.com/users/ejw（すなわち、ユーザが "EJW"）のhttp：// www.example.com/privs/write-allとDAV URLはhttpで識別ACE＃1助成金元本を継承：読み取りACL権限。このサーバーでは、http://www.example.com/privs/write-allはDAVを含む集計特権です：書き込み、およびDAV：書き込みACL。
Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
継承ACE＃2助成金元本DAV：すべてのDAV：読み取り権限。
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.
書き込み許可を：要求がDAV URL http://www.example.com/users/ejw（すなわち、ユーザ「EJW」）によって識別される主体を拒否する、（非継承）ACEを設定することを試みます。これは、継承された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="..."
ACL /top/index.html HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "EJW"、領域= "users@example.com"、ナンス= "... " URI ="/トップ/ index.htmlを"、レスポンス= "... "不透明=" ..."
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のACLのxmlns：D = "DAV：" のxmlns：F = "http://www.example.com/privs/"> <D ：エース> <D：主> <D：HREF> http://www.example.com/users/ejw </ D：HREF> </ D：主> <D：グラント> <D：書き込み/> < / D：付与> </ D：ACE> </ D：ACL>
>> Response <<
>>回答<<
HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 403禁止のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:no-inherited-ace-conflict/> </D:error>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：エラーのxmlns：D = "DAV："> <D：なし継承-ACE-衝突/> </ D：エラー>
8.1.5. Example: ACL method failure due to an attempt to set grant and deny in a single ACE
8.1.5. 例：単一のACEに許可を設定し、拒否しようとする試みに起因ACL方法障害
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上のアクセス制御リストを変更しようとします。 URLはhttpによって識別されるプリンシパルを読ん特権と拒否：// DAVをwww.example.com/users/friends：ACL要求の構文と意味的に、URLはhttpによって識別されるグループを付与しようとし、誤ったACEを、単一含み/ /www.example.com/users/ygoland-so（すなわち、ユーザが "ygoland-SO"）DAV：読み取り権限。しかし、複数の主要な要素、並びに許可の両方を持っており、要求が不十分な構文に失敗したので、同じ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="..."
ACL /diamond/engagement-ring.gif HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "ygoland"、領域= "users@example.com"、ナンス=」... "URI =" /ダイヤモンド/婚約-ring.gif "レスポンス=" ... "不透明=" ...」
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のACLのxmlns：D = "DAV："> <D：ACE> <D：主> <D：HREF>のhttp：// WWW .example.comと/ユーザー/友人</ D：HREF> </ D：元金> <D：助成金> <D：読み取り/> </ D：助成金> <D：元本> <D：のhref>のhttp：/ /www.example.com/users/ygoland-so </ D：HREF> </ D：主> <D：拒否> <D：読み取り/> </ D：拒否> </ D：ACE> </ D ：ACL>
>> Response <<
>>回答<<
HTTP/1.1 400 Bad Request Content-Length: 0
HTTP / 1.1 400不正なリクエストの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.
（[RFC3253]のセクション3.6で定義された）報告方法は、リソースに関する情報を取得するための拡張可能なメカニズムを提供します。一つ以上の名前付きプロパティの値を返す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をサポートしなければならない：（[RFC3253]の3.8節で定義される）を展開-プロパティをレポート。
The DAV:acl-principal-prop-set report returns, for all principals in the DAV:acl property (of the Request-URI) that are identified by http(s) URLs or by a DAV:property principal, the value of the properties specified in the REPORT request body. In the case where a principal URL appears multiple times, the DAV:acl-principal-prop-set report MUST return the properties for that principal only once. Support for this report is REQUIRED.
DAV：DAV内のすべてのプリンシパルのために、レポート戻るACL-主 - プロプ設定：プロパティプリンシパルの値：ACLプロパティHTTP（S）URLで、またはDAVにより同定される（要求URIの） REPORT要求本体に指定されたプロパティ。主要なURLが複数回表示される場合は、DAV：ACL-元本プロップセットレポートは一度だけその元本のプロパティを返さなければなりません。このレポートのためのサポートが必要です。
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.
ACLで見つかった各校長の：この報告書の一つ予想される使用は、（のDisplayNameプロパティDAVで見つかった）人間が読める形式の名前を取得することです。これは、人間が読める形式で各ACEを示すユーザインタフェースを構築するために有用です。
Marshalling
マーシャリング
The request body MUST be a DAV:acl-principal-prop-set XML element.
ACL-主 - プロプセットXML要素：リクエストボディは、DAVでなければなりません。
<!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
<！ELEMENT ANY ACL-元本 - プロプ設定>任意の値：1つの以上の要素の順序、最大1つのDAVと：要素小道具。小道具：RFC 2518、セクション12.11を参照してください
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".
奥行きヘッダが値「0」を有する場合、このレポートにのみ定義されています。他の値は400（不正な要求）エラー応答をもたらします。 、[RFC3253]そのセクション3.6なお、奥行きヘッダが「0」の値に現在、デフォルトでない場合、と述べています。
The response body for a successful request MUST be a DAV:multistatus XML element (i.e., the response uses the same format as the response for PROPFIND). In the case where there are no response elements, the returned multistatus XML element is empty.
multistatus XML要素（すなわち、応答がPROPFINDに対するレスポンスと同じフォーマットを使用）：成功した要求に対する応答の本体は、DAVでなければなりません。応答要素が存在しない場合、返さmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：RFC 2518を参照してください、セクション12.9
The response body for a successful DAV:acl-principal-prop-set REPORT request MUST contain a DAV:response element for each principal identified by an http(s) URL listed in a DAV:principal XML element of an ACE within the DAV:acl property of the resource identified by the Request-URI.
成功DAVのレスポンスボディ：DAV内のACEの主要XML要素：DAVに記載されているHTTP（S）URLによって識別される各プリンシパルの応答エレメント：ACL-プリンシパル - プロプセットレポート要求は、DAVを含まなければなりません。 Request-URIによって識別されるリソースのACLプロパティ。
Postconditions:
事後条件：
(DAV:number-of-matches-within-limits): The number of matching principals must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.
（DAV：数のマッチ-内-限界）：一致するプリンシパルの数は、サーバ固有の、事前に定義された限界内に入らなければなりません。検索仕様は応答の非常に多くのリターンを引き起こす場合たとえば、この条件がトリガされる可能性があります。
Resource http://www.example.com/index.html has an ACL with three ACEs:
リソースhttp://www.example.com/index.htmlは3つのACEを持つACLがあります。
ACE #1: All principals (DAV:all) have DAV:read and DAV:read-current-user-privilege-set access.
ACE＃1：すべてのプリンシパル（DAV：すべては）DAVを持っている：読み取りおよびDAV：読み取り、現在のユーザー特権-設定されたアクセス。
ACE #2: The principal identified by http://www.example.com/people/ gstein (the user "gstein") is granted DAV:write, DAV:write-acl, DAV:read-acl privileges.
ACE＃2：http://www.example.com/people/ gstein（ユーザー "gstein"）で識別されるプリンシパルは、DAVを付与されています、書き込み-ACL DAV：：読み取りACL権限をDAV、書きます。
ACE #3: The group identified by http://www.example.com/groups/authors (the "authors" group) is granted DAV:write and DAV:read-acl privileges.
ACE＃3：http://www.example.com/groups/authors（ "作者" グループ）によって識別されるグループは、DAVを付与されている：書き込み、DAV：権限-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を示す：DAVを要求ACL-主 - プロプセット報告のDisplayNameプロパティ。これは、DAVの値を返します：リソースのためのDisplayName http://www.example.com/people/gsteinとhttp://www.example.com/groups/authorsはなく、DAVについて：すべて、これではありませんので、 HTTP（S）URL。
>> Request <<
>>リクエスト<<
REPORT /index.html HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Depth: 0
REPORT /index.htmlがHTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：xxxxの深さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：ACL-プリンシパル - プロプセットのxmlns：D = "DAV"> <D：プロペラ> <D：表示名/> </ A ：プロップ> </ D：ACL-プリンシパル - プロプセット>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/人/ gstein </ D：のhref> <D：propstat> <D：小道具> <D：のDisplayName>グレッグ・スタイン</ D：表示名> </ D：小道具> <D：状態> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> http://www.example.com/groups/authors </ D：HREF> <D：propstat> <D：小道具> <D：のDisplayName>サイト作成者</ D：表示名> </ D：小道具> <D：状態> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：応答> </ 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：主マッチレポートが主体であり、それは現在のユーザに一致するのRequest-URIによって識別されるコレクションの（任意の深さで）すべてのメンバーを識別するために使用されます。コレクションは、プリンシパルが含まれている場合は特に、報告書は、現在のユーザーに一致するコレクションのすべてのメンバーを識別するために使用することができます。コレクションが主（例えば、DAV：所有者）を識別するプロパティを有するリソースが含まれている場合は別の方法として、レポートは、プロパティ、現在のユーザに一致するプリンシパルを識別し、コレクションのすべてのメンバーを同定するために使用することができます。たとえば、このレポートは、現行のユーザーが所有するコレクション階層内のすべてのリソースを返すことができます。このレポートのためのサポートが必要です。
Marshalling:
マーシャリング：
The request body MUST be a DAV:principal-match XML element. <!ELEMENT principal-match ((principal-property | self), prop?)> <!ELEMENT principal-property ANY>
主要マッチXML要素：リクエストボディは、DAVでなければなりません。 <！ELEMENTプリンシパルマッチ（（元本-プロパティ|？自己）、小道具）> <！ELEMENTプリンシパル・プロパティ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
ANY値：値プロパティを識別します要素。期待という名前のプロパティの値は、一般的に元本のURIが含まれているのhref要素が含まれています。<！ELEMENTの自己EMPTY>小道具：RFC 2518を参照してください、セクション12.11
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0". The response body for a successful request MUST be a DAV:multistatus XML element. In the case where there are no response elements, the returned multistatus XML element is empty.
奥行きヘッダが値「0」を有する場合、このレポートにのみ定義されています。他の値は400（不正な要求）エラー応答をもたらします。 、[RFC3253]そのセクション3.6なお、奥行きヘッダが「0」の値に現在、デフォルトでない場合、と述べています。 multistatus XML要素：成功したリクエストのレスポンスボディは、DAVでなければなりません。応答要素が存在しない場合、返さmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：RFC 2518を参照してください、セクション12.9
The response body for a successful DAV:principal-match REPORT request MUST contain a DAV:response element for each member of the collection that matches the current user. When the DAV:principal-property element is used, a match occurs if the current user is matched by the principal identified by the URI found in the DAV:href element of the property identified by the DAV:principal-property element. When the DAV:self element is used in a DAV:principal-match report issued against a group, it matches the group if a member identifies the same principal as the current user.
主一致REPORT要求がDAVを含まなければなりません：現在のユーザに一致するコレクションの各メンバーのための応答エレメント成功DAVのレスポンスボディ。 DAV場合：主-property要素が使用されている現在のユーザがURIによって識別される主にマッチした場合、一致が発生DAVで見つかった：DAVにより識別されたプロパティのhref要素：主-性要素。自己要素DAVで使用される：DAVの場合グループに対して発行された主マッチレポートメンバーが現在のユーザーと同じプリンシパルを識別した場合、それはグループと一致します。
If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements.
支柱リクエストボディに指定され、DAVで指定された特性は：DAVの場合、応答エレメント：エレメントPROP DAVに報告しなければなりません。
The following example identifies the members of the collection identified by the URL http://www.example.com/doc that are owned by the current user. The current user ("gclemm") is authenticated using Digest authentication.
次の例では、現在のユーザーによって所有されているURLのhttp://www.example.com/docで識別されるコレクションのメンバーを識別します。現在のユーザー（「gclemm」）は、ダイジェスト認証を使用して認証されます。
>> 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
REPORT / DOC / HTTP / 1.1ホスト：www.example.com認証：ダイジェストユーザ名= "gclemm"、領域= "users@example.com"、ナンス= "... " URI ="/論文/"、応答= "... "不透明=" ..." のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：xxxxの深さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：主マッチのxmlns：D = "DAV："> <D：主-性> <D：オーナー/> </ D：プリンシパル-property> </ D：主マッチ>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/ DOC / foo.htmlという</ D：HREF> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：レスポンス> <D：レスポンス> <D：HREF>のhttp：//www.example .COM / DOC / IMG / bar.gif </ D：HREF> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：レスポンス> </ 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：元本-プロパティ検索REPORTは、プロパティの要求で指定した検索条件に一致する文字データを含むすべてのプリンシパルのための検索を実行します。この報告書の一つ予想される使用は、名前でそれらを検索することによって、与えられた個人またはグループに関連付けられた元本のURLを発見することです。 DisplayNameに、すべてのプリンシパルに定義されています。これは、DAVの上に探索することによって行われます。
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のインプリメンテーションの場合に：主-プロパティ検索が下にあるユーザ管理リポジトリのセマンティクスによって制約されない、好ましいデフォルトセマンティクスはケースレスサブストリングの一致があります。
For implementation efficiency, servers do not typically support searching on all properties. A search requesting properties that are not searchable for a particular principal will not match that principal.
実装効率のために、サーバーは通常、すべてのプロパティでの検索をサポートしていません。そのプリンシパルが一致しないであろう特定のプリンシパルのために検索できないプロパティを要求して検索。
Support for the DAV:principal-property-search report is REQUIRED.
DAVのサポート：主要-プロパティ・サーチレポートが必要です。
Implementation Note: The value of a WebDAV property is a sequence of well-formed XML, and hence can include any character in the Unicode/ISO-10646 standard, that is, most known characters in human languages. Due to the idiosyncrasies of case mapping across human languages, implementation of case-insensitive matching is non-trivial. Implementors of servers that do perform substring matching are strongly encouraged to consult "The Unicode Standard" [UNICODE4], especially Section 5.18, Subsection "Caseless Matching", for guidance when implementing their case-insensitive matching algorithms.
実装上の注意：WebDAVのプロパティの値が整形式のXMLのシーケンスであるため、ユニコード/ ISO-10646標準の任意の文字を含めることができ、それは、人間の言語の中で最も知られている文字です。人為的言語間ケースマッピングの特異性を、大文字と小文字を区別しないマッチングの実装では、非自明です。サブストリングマッチングを実行しないサーバーの実装者が強く、「Unicode標準」[UNICODE4]、特にセクション5.18に相談することが奨励され、指導のためのサブセクション「ケース無しマッチング」、彼らの大文字と小文字を区別しないマッチングアルゴリズムを実装します。
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を実装する際に使用することができLDAPが行動を属性検索のデフォルトです。
Marshalling:
マーシャリング：
The request body MUST be a DAV:principal-property-search XML element containing a search specification and an optional list of properties. For every principal that matches the search specification, the response will contain the value of the requested properties on that principal.
検索仕様およびプロパティのオプションのリストを含む主要資産検索XML要素：リクエストボディは、DAVでなければなりません。検索仕様に一致するすべての主要について、応答はその元本に要求されたプロパティの値が含まれます。
<!ELEMENT principal-property-search ((property-search+), prop?, apply-to-principal-collection-set?) >
<！ELEMENT元本-プロパティ検索（（プロパティ検索+）、適用対主要-コレクションセット?,小道具？）>
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場合：Request-URIによって識別されるリソースの主捕集設定プロパティ：適用ツー主捕集セットがリクエストボディに指定され、要求はDAVにより識別された各コレクションに代えて適用されます。
The DAV:property-search element contains a prop element enumerating the properties to be searched and a match element, containing the search string.
DAV：プロパティ検索要素は、検索文字列を含む、検索するプロパティと一致する要素を列挙支柱要素が含まれています。
<!ELEMENT property-search (prop, match) > prop: see RFC 2518, Section 12.11
<！ELEMENTプロパティ検索（小道具、試合）>小道具：RFC 2518を参照してください、セクション12.11
<!ELEMENT match #PCDATA >
<！ELEMENTマッチ#PCDATA>
Multiple property-search elements or multiple elements within a DAV:prop element will be interpreted with a logical AND.
DAV内の複数のプロパティ検索要素または複数の要素：要素PROP論理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".
奥行きヘッダが値「0」を有する場合、このレポートにのみ定義されています。他の値は400（不正な要求）エラー応答をもたらします。 、[RFC3253]そのセクション3.6なお、奥行きヘッダが「0」の値に現在、デフォルトでない場合、と述べています。
The response body for a successful request MUST be a DAV:multistatus XML element. In the case where there are no response elements, the returned multistatus XML element is empty.
multistatus XML要素：成功したリクエストのレスポンスボディは、DAVでなければなりません。応答要素が存在しない場合、返さmultistatus XML要素は空です。
multistatus: see RFC 2518, Section 12.9
multistatus：RFC 2518を参照してください、セクション12.9
The response body for a successful DAV:principal-property-search REPORT request MUST contain a DAV:response element for each principal whose property values satisfy the search specification given in DAV:principal-property-search.
成功DAVのレスポンスボディ：プリンシパル・プロパティ検索：プロパティ値DAVで与えられた検索仕様を満足する各プリンシパルの応答エレメント：主-性サーチレポート要求は、DAVを含まなければなりません。
If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements.
支柱リクエストボディに指定され、DAVで指定された特性は：DAVの場合、応答エレメント：エレメントPROP DAVに報告しなければなりません。
Preconditions:
前提条件：
None
無し
Postconditions:
事後条件：
(DAV:number-of-matches-within-limits): The number of matching principals must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.
（DAV：数のマッチ-内-限界）：一致するプリンシパルの数は、サーバ固有の、事前に定義された限界内に入らなければなりません。検索仕様は応答の非常に多くのリターンを引き起こす場合たとえば、この条件がトリガされる可能性があります。
There are several cases to consider when matching strings. The easiest case is when a property value is "simple" and has only character information item content (see [REC-XML-INFOSET]). For example, the search string "julian" would match the DAV:displayname property with value "Julian Reschke". Note that the on-the-wire marshaling of DAV:displayname in this case is:
文字列を照合する際に考慮すべきいくつかの例があります。プロパティの値が「シンプル」であり、唯一の文字情報項目の内容を（[REC-XML-INFOSET]参照）がある場合、最も簡単な場合です。値「ジュリアンReschke」とのDisplayNameプロパティ：たとえば、検索文字列「ジュリアンは、」DAVと一致します。 DAVのオン・ザ・ワイヤマーシャリングことに注意：この場合の表示名です。
<D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname>
<D：のdisplayNameのxmlns：D = "DAV：">ジュリアン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".
プロパティの名前は、XML要素情報項目にエンコードされ、プロパティの文字情報項目の内容は「ジュリアン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:
より複雑な場合には、特性が混在したコンテンツを持っている場合に発生する（つまり、複数の子要素のアイテム、情報アイテムの他のタイプ、および文字情報の項目内容からなる化合物の値）。名前空間にプロパティ「aprop」を考えてみましょう「のhttp：// www.example.com/props/」、としてマーシャリング：
<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>
<W：aprop用のxmlns：W = "http://www.example.com/props/"> CDATA {0} <W：elem1> CDATA {1} </ W：elem1> <W：のElem2> {2 CDATA } </ 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}
{CDATA 0} {1} {CDATA CDATA 2} {3} CDATA
That is, four individual matches would be performed, one each for {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
すなわち、4つの個々の一致が一つずつ{CDATA 0}、{CDATA 1}、{CDATA 2}、及び{CDATA 3}のために、実行される、です。
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、すべてのユーザーの主要なURLを要求しますのDisplayNameプロパティは、サブストリング「DOE」とその「タイトル」名前空間のプロパティ「http://BigCorp.com/ns/」（つまりが含まれ、そのプロのタイトル）は、「売上高」が含まれています。また、クライアントは、マッチング・プリンシパルで返される5つのプロパティを要求します。
In the DAV: namespace: displayname
名前空間：DisplayNameにDAVで
In the http://www.example.com/ns/ namespace: department, phone, office, salary
部署、電話、オフィス、給与：http://www.example.com/ns/名前空間に
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.
応答は、二つの主要なリソースは、検索仕様、「ジョン・ドウ」と「Zygdoebertスミス」を満たしていることを示しています。要求を行う主体が、このプロパティを読み取るための十分なアクセス権を持っていないので、名前空間のプロパティ「給与」「http://www.example.com/ns/」は、返されません。
>> Request <<
>>リクエスト<<
REPORT /users/ HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset=utf-8 Content-Length: xxxx Depth: 0
REPORT /ユーザー/ HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、文字セット= UTF-8のContent-Length：XXXXの深さ：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：主-プロパティ検索のxmlns：D = "DAV："> <D：プロパティ検索> <D：プロペラ> <D：のDisplayName /> </ D：プロペラ> <D：マッチ> DOE </ D：マッチ> </ D：プロパティ検索> <D：プロパティ検索> <D：B = "HTTP：// WWWのxmlnsプロップ。 example.com/ns / "> <B：タイトル/> </ D：小道具> <D：試合>販売</ D：試合> </ D：プロパティ検索> <D：のxmlns小道具：B =" HTTP ：//www.example.com/ns/ "> <D：DisplayNameに/> <B：デパート/> <B：携帯電話/> <B：オフィス/> <B：給与/> </ D：小道具> < / D：主-プロパティ検索>
>> Response <<
>>回答<<
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset=utf-8 Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、文字セット= 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：B = "http://BigCorp.com/ns/"> <D：応答> <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>
<D：小道具> <D：のDisplayName>ジョン・ドウ</ D：表示名> <B：部門>ウィジェットセールス</ B：部門> <B：携帯電話> 234-4567 </ B：携帯電話> <B：オフィス> 209 </ B：オフィス> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：プロペラ> <B：給与/ > </ D：小道具> <D：禁断の状態> HTTP / 1.1 403 </ D：状態> </ D：propstat> </ D：レスポンス> <D：応答> <D：のhref>のhttp：// WWW .example.comと/ユーザー/ zsmith </ D：のhref> <D：propstat> <D：小道具> <D：のDisplayName> Zygdoebertスミス</ D：表示名> <B：部門>ガジェットセールス</ B：部門> <B：携帯電話> 234-7654 </ B：携帯電話> <B：オフィス> 114 </ B：オフィス> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：プロペラ> <B：給与/> </ D：プロペラ> <D：ステータス> HTTP / 1.1 403禁止</ D：状態> </ D：propstat> </ D：応答> </ 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：プリンシパル・プロパティ・サーチレポート（セクション9.4で定義される）：主要-検索プロパティセットレポートは、それらDAVを使用して検索することができる特性を識別する。
Servers MUST support the DAV:principal-search-property-set REPORT on all collections identified in the value of a DAV:principal-collection-set property.
サーバはDAVをサポートしなければならない：DAVの値で識別されるすべてのコレクションの元本・検索・プロパティ・セットREPORT：元本-コレクション・プロパティセット。
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.
プリンシパルを取得するためにユーザにクエリインタフェースを提示する主要-検索プロパティセットREPORT：アクセス制御プロトコルユーザエージェントは、DAVの結果を使用することができます。
Support for this report is REQUIRED.
このレポートのためのサポートが必要です。
Implementation Note: Some clients will have only limited screen real estate for the display of lists of searchable properties. In this case, a user might appreciate having the most frequently searched properties be displayed on-screen, rather than having to scroll through a long list of searchable properties. One mechanism for signaling the most frequently searched properties is to return them towards the start of a list of properties. A client can then preferentially display the list of properties in order, increasing the likelihood that the most frequently searched properties will appear on-screen, and will not require scrolling for their selection.
実装上の注意：一部のクライアントは、検索可能なプロパティのリストを表示するためにのみ限られた画面の不動産を持っています。この場合、ユーザーは最も頻繁に検索プロパティではなく、検索可能な特性の長いリストをスクロールするより、画面に表示された感謝があります。最も頻繁に検索プロパティをシグナリングのための1つのメカニズムは、プロパティのリストの開始に向けて、それらを返すことです。次に、クライアントは、優先的に最も頻繁に検索プロパティは、画面上に表示される可能性を高め、ために、プロパティのリストを表示することができ、そしてその選択にスクロールする必要はありません。
Marshalling:
マーシャリング：
The request body MUST be an empty DAV:principal-search-property-set XML element.
主要な検索 - プロパティセットのXML要素：リクエストボディは空DAVでなければなりません。
This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".
奥行きヘッダが値「0」を有する場合、このレポートにのみ定義されています。他の値は400（不正な要求）エラー応答をもたらします。 、[RFC3253]そのセクション3.6なお、奥行きヘッダが「0」の値に現在、デフォルトでない場合、と述べています。
The response body MUST be a DAV:principal-search-property-set XML element, containing a DAV:principal-search-property XML element for each property that may be searched with the DAV:principal-property-search REPORT. A server MAY limit its response to just a subset of the searchable properties, such as those likely to be useful to an interactive access control client.
要性探索REPORT：DAVで検索することができる各プロパティの要検索プロパティXML要素：DAVを含む、主要なサーチ・プロパティ・セットXML要素：応答体はDAVでなければなりません。サーバーは、このような対話型のアクセス制御クライアントにとって有用である可能性が高いものと検索可能なプロパティのサブセットのみへの対応を制限することがあります。
<!ELEMENT principal-search-property-set (principal-search-property*) >
<！ELEMENTプリンシパル・サーチ・プロパティ・セット（元本-検索プロパティ*）>
Each DAV:principal-search-property XML element contains exactly one searchable property, and a description of the property.
各DAV：元本-検索プロパティXML要素は、1つの検索可能なプロパティ、およびプロパティの説明が含まれています。
<!ELEMENT principal-search-property (prop, description) >
<！ELEMENTプリンシパル・サーチ・プロパティ（小道具、説明）>
The DAV:prop element contains one principal property on which the server is able to perform a DAV:principal-property-search REPORT.
DAV：支柱要素は、サーバがDAVを行うことが可能である上1つの主要なプロパティが含まれています。主な財産 - 検索REPORT。
prop: see RFC 2518, Section 12.11
小道具：RFC 2518、セクション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.
description要素は、このプロパティが何を表すかの情報を、人間が読める記述です。サーバーは、人間のXMLを使用して説明の言語を示している必要があります：lang属性を、複数の利用可能な言語のいずれかを選択する際にHTTP Accept-Language要求ヘッダを考慮すべきです。
<!ELEMENT description #PCDATA >
<！ELEMENT記述#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/.
この例では、クライアントは、DAVを要求することにより、検索可能な主なプロパティのセットを決定します。http://www.example.com/usersで識別されるサーバーの主要なURLのコレクションセットのルート上の主要な検索 - プロパティセットレポートを、 /。
>> 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
REPORT /ユーザー/ HTTP / 1.1ホスト：www.example.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX-言語を受け入れる：アン、デ許可：BASIC d2FubmFtYWs6cGFzc3dvcmQ =深さ：0
<?xml version="1.0" encoding="utf-8" ?> <D:principal-search-property-set xmlns:D="DAV:"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：主-検索プロパティセットのxmlns：D = "DAV：" />
>> Response <<
>>回答<<
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 200 OKのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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/>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：主-検索プロパティ・セットのxmlns：D = "DAV："> <D：主-検索プロパティ> <D：小道具> <D：表示名/> </ D：プロペラ> <D：説明XML：LANG = "EN">氏名</ D：記述> </ D：主-検索プロパティ> <D：主-検索プロパティ> <D：プロペラのxmlns：B = "http://BigCorp.com/ns/"> <B：タイトル/>
</D:prop> <D:description xml:lang="en">Job title</D:description> </D:principal-search-property> </D:principal-search-property-set>
</ D：プロペラ> <D：説明XML：LANG = "EN">役職</ D：記述> </ D：主-検索プロパティ> </ D：主-検索プロパティセット>
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名前空間勧告[REC-XML-NAMES]で指定されたXML要素は、ルールを無視サポートしなければなりません。
Note that use of the DAV namespace is reserved for XML elements and property names defined in a standards-track or Experimental IETF RFC.
DAVの名前空間の使用は標準トラックや実験IETF RFCで定義されたXML要素とプロパティ名用に予約されて注意してください。
In this specification, the only human-readable content can be found in the description XML element, found within the DAV:supported-privilege-set property. This element contains a human-readable description of the capabilities controlled by a privilege. As a result, the description element must be capable of representing descriptions in multiple character sets. Since the description element is found within a WebDAV property, it is represented on the wire as XML [REC-XML], and hence can leverage XML's language tagging and character set encoding capabilities. Specifically, XML processors at minimum must be able to read XML elements encoded using the UTF-8 [RFC3629] encoding of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in [RFC3023], as well as the XML "encoding" attribute, which together provide charset identification information for MIME and XML processors. Furthermore, this specification requires server implementations to tag description fields with the xml:lang attribute (see Section 2.12 of [REC-XML]), which specifies the human language of the description. Additionally, server implementations should take into account the value of the Accept-Language HTTP header to determine which description string to return.
サポートされる特権セットプロパティ：この仕様では、唯一の人間が読めるコンテンツがDAV内で見つかった、説明のXML要素で見つけることができます。この要素は、特権によって制御能力の人間が読める記述が含まれています。結果として、description要素は、複数の文字セットの記述を表現することができなければなりません。 description要素は、WebDAVのプロパティ内に見出されるので、[REC-XML] XMLとしてワイヤ上に表示されるため、XMLの言語タグと文字セット符号化機能を活用することができます。具体的には、最低でもXMLプロセッサは、ISO 10646多平面のUTF-8 [RFC3629]エンコードを使用してエンコードされたXML要素を読み取ることができなければなりません。本明細書におけるXMLの例は、[RFC3023]で定義されるように、Content-Typeヘッダのcharsetパラメータの使用を実証、ならびに一緒にMIMEおよびXMLプロセッサの文字セット識別情報を提供するXML「コードする」属性。 lang属性（[REC-XML]のセクション2.12を参照）、説明の人間の言語を指定します。また、この仕様は、XMLで記述フィールドをタグ付けするサーバの実装を必要とします。また、サーバの実装は、戻り先の説明文字列を決定するために考慮に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.
エラー報告のために、我々は、各ステータスコードコードの短い、英語の記述（例えば、200（OK））を含むHTTP / 1.1ステータスコードの慣例に従います。可能性が不十分に細工されたユーザエージェントがユーザーにこのメッセージを表示することを存在するが、国際化されたアプリケーションは、このメッセージを無視し、ユーザーの言語と文字セットで適切なメッセージを表示します。
Further internationalization considerations for this protocol are described in the WebDAV Distributed Authoring protocol specification [RFC2518].
このプロトコルの更なる国際化の考慮事項は、WebDAVの分散オーサリングプロトコル仕様[RFC2518]に記載されています。
Applications and users of this access control protocol should be aware of several security considerations, detailed below. In addition to the discussion in this document, the security considerations detailed in the HTTP/1.1 specification [RFC2616], the WebDAV Distributed Authoring Protocol specification [RFC2518], and the XML Media Types specification [RFC3023] should be considered in a security analysis of this protocol.
このアクセス制御プロトコルのアプリケーションとユーザーは、以下の詳細ないくつかのセキュリティ上の考慮事項、注意する必要があります。この文書の議論に加えて、セキュリティの考慮事項は、HTTP / 1.1仕様書[RFC2616]に詳述され、WebDAVの分散オーサリングプロトコル仕様[RFC2518]、およびXMLのメディアタイプ仕様[RFC3023]はのセキュリティ分析で考慮されるべきですこのプロトコル。
In the absence of a mechanism for remotely manipulating access control lists, if a single user's authentication credentials are compromised, only those resources for which the user has access permission can be read, modified, moved, or deleted. With the introduction of this access control protocol, if a single compromised user has the ability to change ACLs for a broad range of other users (e.g., a super-user), the number of resources that could be altered by a single compromised user increases. This risk can be mitigated by limiting the number of people who have write-acl privileges across a broad range of resources.
リモートでアクセス制御リストを操作するためのメカニズムが存在しない場合には、単一のユーザーの認証資格情報が危険にさらされている場合、ユーザーがアクセス権限を持っているリソースのみを読み取ることができ、変更、移動、または削除。このアクセス制御プロトコルの導入により、単一損なわユーザが他のユーザの広い範囲（例えば、スーパーユーザ）のACLを変更する能力を有する場合、単一損なわユーザが増加することによって変更することができるリソースの数。このリスクは、リソースの幅広い書き込みACL権限を持っている人の数を制限することによって緩和することができます。
12.2. Risks of the DAV:read-acl and DAV:current-user-privilege-set Privileges
12.2. DAVのリスク：読み取りACLおよびDAVを：現在のユーザー特権セット特権
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に格納されている）は、現在認証されたユーザを許可しましたACLは、おそらく、リソースの状態に影響を与えることができません。すべてのリソースが世界で読み取り可能なACLを持っている場合は、不注意な誰でも書き込めるものとして、脆弱な状態で自分自身を残してきたこれらのリソースのための徹底的な検索を行うことが可能です。 ACLまたはDAV：現在のユーザー特権セットの特性、特に、階層全体に奥行き無限で実行性検索方法のPROPFINDは、DAVを取得するための非常に効率的な方法です。見つけたら、この脆弱性は、オープンリソースが繰り返し上書きされているサービス拒否攻撃で悪用される可能性があります。代わりに、書き込み可能なリソースは、望ましくない方法で変更することができます。
To reduce this risk, read-acl privileges should not be granted to unauthenticated principals, and restrictions on read-acl and read-current-user-privilege-set privileges for authenticated principals should be carefully analyzed when deploying this protocol. Access to the current-user-privilege-set property will involve a tradeoff of usability versus security. When the current-user-privilege-set is visible, user interfaces are expected to provide enhanced information concerning permitted and restricted operations, yet this information may also indicate a vulnerability that could be exploited. Deployment of this protocol will need to evaluate this tradeoff in light of the requirements of the deployment environment.
このリスクを軽減するために、権限認証されていないプリンシパルに付与され、かつ読み-ACLに制限すべきではない、ACLの読み込みと読み出し電流ユーザー特権セットこのプロトコルを展開する際に、慎重に分析する必要があり、認証済みのプリンシパルの権限。現在のユーザー特権設定プロパティへのアクセスは、セキュリティ対使いやすさのトレードオフを伴います。現在のユーザー特権セットが表示されている場合、ユーザインターフェースは許可と制限された操作に関する強化された情報を提供することが期待され、まだこの情報は、悪用される可能性があり、この脆弱性を示すことができます。このプロトコルの展開は、デプロイメント環境の要件に照らして、このトレードオフを評価する必要があります。
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プロパティ：初期ACLを発見する唯一の方法は、DAVの値を取得し、その後、新しいリソースを作成することです。読み取りACL権限：これは、リソースを作成するプリンシパルはまた、DAVが付与されている前提としています。
As a result, it is possible that a principal could create a resource, and then discover that its ACL grants privileges that are undesirable. Furthermore, this protocol makes it possible (though unlikely) that the creating principal could be unable to modify the ACL, or even delete the resource. Even when the ACL can be modified, there will be a short period of time when the resource exists with the initial ACL before its new ACL can be set.
その結果、主要なリソースを作成し、そのACLは望ましくない権限を付与することを発見する可能性があります。さらに、このプロトコルは、作成主体がACLを変更することができない、あるいはリソースを削除できること（そうが）ことが可能となります。 ACLを変更することができた場合でも、その新しいACLを設定することができます前に、リソースが最初のACLに存在する時間の短い期間があるでしょう。
Several factors mitigate this risk. Human principals are often aware of the default access permissions in their editing environments and take this into account when writing information. Furthermore, default privilege policies are usually very conservative, limiting the privileges granted by the initial ACL.
いくつかの要因が、このリスクを軽減します。人間の校長は、多くの場合、彼らの編集環境でのデフォルトのアクセス権限を認識しているとの情報を書き込む際に、このことを考慮します。さらに、デフォルトの特権ポリシーは、最初のACLによって付与された権限を制限し、通常は非常に保守的です。
Authentication mechanisms defined for use with HTTP and WebDAV also apply to this WebDAV Access Control Protocol, in particular the Basic and Digest authentication mechanisms defined in [RFC2617]. Implementation of the ACL spec requires that Basic authentication, if used, MUST only be supported over secure transport such as TLS.
HTTPおよびWebDAVで使用するために定義された認証メカニズムはまた、特にこのWebDAVのアクセス制御プロトコル、[RFC2617]で定義された基本とダイジェスト認証メカニズムに適用されます。 ACL仕様の実装は、基本認証を使用する場合、唯一のTLSのような安全なトランスポート上でサポートされている必要があります。
This document uses the namespace defined by [RFC2518] for XML elements. That is, this specification uses the "DAV:" URI namespace, previously registered in the URI schemes registry. All other IANA considerations mentioned in [RFC2518] are also applicable to this specification.
この文書は、XML要素のために[RFC2518]で定義された名前空間を使用しています。 URI名前空間、以前URIスキームレジストリに登録：つまり、この仕様は、「DAV」を使用しています。 [RFC2518]に記載されたその他のIANA問題もこの仕様に適用されます。
This protocol is the collaborative product of the WebDAV ACL design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors are grateful for the detailed review and comments provided by Jim Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, and Keith Wannamaker. We thank Keith Wannamaker for the initial text of the principal property search sections. Prior work on WebDAV access control protocols has been performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. We would like to acknowledge the foundation laid for us by the authors of the DeltaV, WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV working group.
このプロトコルは、WebDAV ACLのデザインチームのコラボレーティブな製品です：バーナードチェスター、ジェフClemm、アン・ホプキンス、バリー・リンド、ショーンLyndersay、エリックSedlar、グレッグ・スタイン、そしてジム・ホワイトヘッド。著者はジムAmsden、ディランBarrell、ジーノ・バッソ、マーシーChintalapati、リサDusseault、ステファンEissing、ティム・エリソン、ヤロンGoland、デニス・ハミルトン、ローリー・ハーパー、Eckehardヘルマン、ロン・ジェイコブス、クリス・ナイトが提供する詳細なレビューとコメントに感謝してい、レミーMaucherat、ラリーMasinter、ジョー・オートン、ピーター・レイモンド、そしてキース・ワナメーカー。私たちは、主要なプロパティの検索セクションの最初のテキストのためのキース・ワナメーカーに感謝します。 WebDAVアクセス制御プロトコルの前の仕事は、ヤロンGoland、ポールリーチ、リサDusseault、ハワード・パーマー、そしてジョン・ラドフによって行われています。私たちは、このプロトコルが積層された時にデルタV、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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.およびE. MALER、 "拡張マークアップ言語（XML）1.0（（第3版）"、W3C REC REC-XML-20040204、2月2004年、<http://www.w3.org/TR/2004/REC-xml-20040204>。
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[REC-XML-INFOSET]コーワン、J.とR.トビン、 "XML情報セット（第二版）"、W3C REC REC-XML-インフォセット-20040204、2004年2月、<http://www.w3.org/ TR / 2004 / REC-XML-インフォセット-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]ブレイ、T.、オランダ、D.とA.素人、 "XMLで名前空間"、W3C REC REC-XML-名-19990114、1999年1月、<http://www.w3.org / TR / 1999 / REC-XML-名-19990114>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証"、 RFC 2617、1999年6月。
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、St.Laurent、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、エリソン、T.、Kaler、C.およびJ.ホワイトヘッド、 "WebDAVのにバージョンの拡張"、RFC 3253、2002年3月。
[RFC3530] Shepler, S., Ed., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.編、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.とD. Noveck、「ネットワークファイルシステム（NFS）プロトコルバージョン4 」、RFC 3530、2003年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629 November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629 2003年11月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[UNICODE4] The Unicode Consortium, "The Unicode Standard - Version 4.0", Addison-Wesley , August 2003, <http://www.unicode.org/versions/Unicode4.0.0/>. ISBN 0321185781.
[UNICODE4]はUnicodeコンソーシアム、 "Unicode標準 - バージョン4.0"、アディソン・ウェズリー、2003年8月、<http://www.unicode.org/versions/Unicode4.0.0/>。 ISBN 0321185781。
Appendix A. WebDAV XML Document Type Definition Addendum
付録A.のWebDAV XML文書型定義の補遺
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)>
<！ - 特権 - （第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>
<！ELEMENTの書き込みプロパティEMPTY> <！ELEMENTの書き込み内容EMPTY> <！ELEMENTがEMPTY書く> <！ELEMENTはEMPTY読む> <！ELEMENT読み取りACL EMPTY> <！ELEMENT読み取り、現在のユーザー<！ELEMENT EMPTYロックを解除>を-privilege-設定> <！ELEMENT書き込み-ACL EMPTY> <！ELEMENTバインドEMPTY EMPTY> <！ELEMENTがEMPTY> <！ELEMENTのバインドを解除し、すべてのEMPTY>
<!-- Principal Properties (Section 4) -->
<！ - 主なプロパティ（第4節） - >
<!ELEMENT principal EMPTY>
<！ELEMENT校長EMPTY>
<!ELEMENT alternate-URI-set (href*)> <!ELEMENT principal-URL (href)> <!ELEMENT group-member-set (href*)> <!ELEMENT group-membership (href*)>
<！ELEMENTの代替URIセット（HREF *）> <！ELEMENT元本-URL（HREF）> <！ELEMENTグループ・メンバー・セット（HREF *）> <！ELEMENTグループ・メンバーシップ（HREF *）>
<!-- Access Control Properties (Section 5) -->
<！ - アクセスコントロールのプロパティ]（第5節） - >
<!-- DAV:owner Property (Section 5.1) -->
<！ - DAV：所有者プロパティ（セクション5.1） - >
<!ELEMENT owner (href?)>
<！ELEMENTの所有者（HREF？）>
<!-- DAV:group Property (Section 5.2) -->
<！ - DAV：グループプロパティ（5.2節） - >
<!ELEMENT group (href?)>
<！ELEMENTグループ（HREF？）>
<!-- DAV:supported-privilege-set Property (Section 5.3) -->
<！ - DAV：サポートされている特権セットプロパティ（5.3節） - >
<!ELEMENT supported-privilege-set (supported-privilege*)> <!ELEMENT supported-privilege (privilege, abstract?, description, supported-privilege*)>
<！ELEMENTサポート-特権セット（サポート-特権*）> <！ELEMENTサポート-特権（特権、抽象?,説明、サポート特権*）>
<!ELEMENT privilege ANY> <!ELEMENT abstract EMPTY> <!ELEMENT description #PCDATA>
<！ELEMENT権限ANY> <！ELEMENT抽象EMPTY> <！ELEMENT記述#PCDATA>
<!-- DAV:current-user-privilege-set Property (Section 5.4) -->
<！ - DAV：現在のユーザー特権-setプロパティ（5.4節） - >
<!ELEMENT current-user-privilege-set (privilege*)>
<！ELEMENT現在のユーザー特権セット（特権*）>
<!-- DAV:acl Property (Section 5.5) -->
<！ - 鳩：aklaプロパティ（5.5節） - >
<!ELEMENT acl (ace)* > <!ELEMENT ace ((principal | invert), (grant|deny), protected?, inherited?)>
<！ELEMENTのACL（エース）*> <！ELEMENTエース（（元本|反転）、（助成金|拒否）、保護された？、継承されました？）>
<!ELEMENT principal (href) | all | authenticated | unauthenticated | property | self)>
<！ELEMENTプリンシパル（HREF）|すべて|認証されました|認証されていません|プロパティ|自己）>
<!ELEMENT all EMPTY> <!ELEMENT authenticated EMPTY> <!ELEMENT unauthenticated EMPTY> <!ELEMENT property ANY> <!ELEMENT self EMPTY>
<！ELEMENTすべてEMPTY> <！ELEMENT認証されていないEMPTY> <！ELEMENTプロパティANY> <！ELEMENTの自己EMPTY> <！ELEMENTがEMPTY認証済み>
<!ELEMENT invert principal>
<！ELEMENT反転プリンシパル>
<!ELEMENT grant (privilege+)> <!ELEMENT deny (privilege+)> <!ELEMENT privilege ANY>
<！ELEMENTの助成金（特典+）> <！ELEMENT拒否（特典+）> <！ELEMENT権限ANY>
<!ELEMENT protected EMPTY>
<！ELEMENT EMPTY保護>
<!ELEMENT inherited (href)>
<！ELEMENTが継承された（HREF）>
<!-- DAV:acl-restrictions Property (Section 5.6) -->
<！ - DAV：ACL-制約プロパティ（5.6節） - >
<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?, required-principal?)>
<！ELEMENTのACL-制限（助成金専用?,無反転?,拒否・ビフォア・助成金?,必要-校長？）>
<!ELEMENT grant-only EMPTY> <!ELEMENT no-invert EMPTY> <!ELEMENT deny-before-grant EMPTY>
<！ELEMENT助成金専用EMPTY> <！ELEMENT無反転EMPTY> <！ELEMENTは拒否の前に、助成金EMPTY>
<!ELEMENT required-principal (all? | authenticated? | unauthenticated? | self? | href* |property*)>
<！ELEMENT必要-元本（すべて|？認証された|？認証されていない？|自己|？のhref * |プロパティ*）>
<!-- DAV:inherited-acl-set Property (Section 5.7) -->
<！ - DAV：継承された-ACL-setプロパティ（5.7節） - >
<!ELEMENT inherited-acl-set (href*)>
<！ELEMENT継承-ACL-セット（HREFの*）>
<!-- DAV:principal-collection-set Property (Section 5.8) -->
<！ - DAV：主なコレクションセットのプロパティ（セクション5.8） - >
<!ELEMENT principal-collection-set (href*)>
<！ELEMENT元本-コレクションセット（HREF *）>
<!-- Access Control and Existing Methods (Section 7) -->
<！ - アクセス制御と既存の方法（第7節） - >
<!ELEMENT need-privileges (resource)* > <!ELEMENT resource ( href, privilege )
<！ELEMENTの必要性 - 権限（リソース）*> <！ELEMENTリソース（HREF、特権）
<!-- ACL method preconditions (Section 8.1.1) -->
<！ - ACL法前提条件（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>
<！ELEMENT無エース紛争EMPTY> <！ELEMENT無保護-ACE-紛争EMPTY> <！ELEMENT無継承-ACE-紛争EMPTY> <！ELEMENT数制限の-エースEMPTY> <！ELEMENTの助成金-only EMPTY> <！ELEMENT無反転EMPTY> <！ELEMENT拒否・ビフォア・助成金をEMPTY> <！ELEMENT無抽象EMPTY> <！ELEMENT-サポートされていない特権EMPTY> <！ELEMENTは、必要な欠落-校長EMPTY> <！ELEMENTが認められ、主なEMPTY> <！ELEMENT許さ-校長EMPTY>
<!-- REPORTs (Section 9) -->
<！ - レポート（第9節） - >
<!ELEMENT acl-principal-prop-set ANY> ANY value: a sequence of one or more elements, with at most one DAV:prop element.
<！ELEMENT ANY ACL-元本 - プロプ設定>任意の値：1つの以上の要素の順序、最大1つのDAVと：要素小道具。
<!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プリンシパルマッチ（（元本-プロパティ|セルフ）、小道具？）>任意の値：値がプロパティを識別要素<ELEMENTプリンシパル・プロパティANY！>。期待は、名前付きプロパティの値は、一般的に元本のURIが含まれているのhref要素が含まれています。<！ELEMENT自己EMPTY>
<!ELEMENT principal-property-search ((property-search+), prop?) > <!ELEMENT property-search (prop, match) > <!ELEMENT match #PCDATA >
<！ELEMENT元本-プロパティ検索（（プロパティ検索+）、小道具？）> <！ELEMENTプロパティ検索（小道具、試合）> <！ELEMENTマッチ#PCDATA>
<!ELEMENT principal-search-property-set ( principal-search-property*) > <!ELEMENT principal-search-property (prop, description) > <!ELEMENT description #PCDATA >
<！ELEMENTプリンシパル・サーチ・プロパティ・セット（元本-検索プロパティ*）> <！ELEMENTプリンシパル・サーチ・プロパティ（小道具、説明）> <！ELEMENT記述#PCDATA>
Appendix B. WebDAV Method Privilege Table (Normative)
付録B. WebDAVのメソッド特権表（規定）
The following table of WebDAV methods (as defined in RFC 2518, 2616, and 3253) clarifies which privileges are required for access for each method. Note that the privileges listed, if denied, MUST cause access to be denied. However, given that a specific implementation MAY define an additional custom privilege to control access to existing methods, having all of the indicated privileges does not mean that access will be granted. Note that lack of the indicated privileges does not imply that access will be denied, since a particular implementation may use a sub-privilege aggregated under the indicated privilege to control access. Privileges required refer to the current resource being processed unless otherwise specified.
WebDAVメソッドの次の表（RFC 2518、2616、および3253で定義されるように）権限が各メソッドのアクセスのために必要とされる明確にしています。拒否された場合は、リストされた権限は、アクセスが拒否されることになりなければならないことに注意してください。しかし、特定の実装が許可されることのアクセスを意味するものではありません示された特権のすべてを持つ、既存のメソッドへのアクセスを制御するために、追加のカスタム権限を定義するかもしれないことに与えられました。特定の実装では、アクセスを制御するために示された権限の下に集約サブ特権を使用するかもしれないので、そのアクセスが拒否されます意味するものではありません示された権限の欠如に注意してください。必要な権限は、特に指定しない限り、処理されている現在のリソースを参照してください。
+---------------------------------+---------------------------------+
| METHOD | PRIVILEGES |
+---------------------------------+---------------------------------+
| GET | <D:read> |
| HEAD | <D:read> |
| OPTIONS | <D:read> |
| PUT (target exists) | <D:write-content> on target |
| | resource |
| PUT (no target exists) | <D:bind> on parent collection |
| | of target |
| PROPPATCH | <D:write-properties> |
| ACL | <D:write-acl> |
| PROPFIND | <D:read> (plus <D:read-acl> and |
| | <D:read-current-user-privilege- |
| | set> as needed) |
| COPY (target exists) | <D:read>, <D:write-content> and |
| | <D:write-properties> on target |
| | resource |
| COPY (no target exists) | <D:read>, <D:bind> on target |
| | collection |
| MOVE (no target exists) | <D:unbind> on source collection |
| | and <D:bind> on target |
| | collection |
| MOVE (target exists) | As above, plus <D:unbind> on |
| | the target collection |
| DELETE | <D:unbind> on parent collection |
| LOCK (target exists) | <D:write-content> |
| LOCK (no target exists) | <D:bind> on parent collection |
| MKCOL | <D:bind> on parent collection |
| UNLOCK | <D:unlock> |
| CHECKOUT | <D:write-properties> |
| CHECKIN | <D:write-properties> |
| REPORT | <D:read> (on all referenced |
| | resources) |
| VERSION-CONTROL | <D:write-properties> |
| MERGE | <D:write-content> |
| MKWORKSPACE | <D:write-content> on parent |
| | collection |
| BASELINE-CONTROL | <D:write-properties> and |
| | <D:write-content> |
| MKACTIVITY | <D:write-content> on parent |
| | collection |
+---------------------------------+---------------------------------+
Index
指数
A ACL method 40
ACLメソッド40
C Condition Names DAV:allowed-principal (pre) 42 DAV:deny-before-grant (pre) 41 DAV:grant-only (pre) 41 DAV:limited-number-of-aces (pre) 41 DAV:missing-required-principal (pre) 42 DAV:no-abstract (pre) 41 DAV:no-ace-conflict (pre) 41 DAV:no-inherited-ace-conflict (pre) 41 DAV:no-invert (pre) 41 DAV:no-protected-ace-conflict (pre) 41 DAV:not-supported-privilege (pre) 42 DAV:number-of-matches-within-limits (post) 48, 53 DAV:recognized-principal (pre) 42
C条件名DAV：せ、プリンシパル（予備）42 DAV：拒否・ビフォア・グラント（予備）41 DAV：グラントのみ（前）41 DAV：限られた数の-エース（予備）41 DAV：-必要欠落-principal（予備）42 DAV：非抽象（予備）41 DAV：無ACE-コンフリクト（PRE）41 DAV：なし継承-ACE-コンフリクト（PRE）41 DAV：非反転（予備）41 DAV：無保護-ACE-コンフリクト（PRE）41 DAV： - サポートされていない特権（予備）42 DAV：数のマッチ-内-限界（ポスト）48、53 DAV：認識-プリンシパル（予備）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
D DAVヘッダコンプライアンスクラス 'アクセス制御' 38 DAV：ACLプロパティ23 DAV：ACL-プリンシパル - プロプ設定レポート48 DAV：ACL-制約プロパティ27 DAV：すべての特権13 DAV：せ、主前提42 DAV：alternate- URI-プロパティセット14 DAV：バインド特権12 DAV：現在のユーザー特権設定プロパティ21 DAV：拒否・ビフォア・グラント前提条件を41 DAV：グラントのみ前提条件41 DAV：グループプロパティ18 DAV：グループメンバ設定プロパティ14 DAV：グループメンバーシッププロパティ14 DAV：継承-ACL設定プロパティ29 DAV：限られた数の-ACEは41 DAVを予め調整： - 必要欠落主要前提条件42 DAV：無抽象前提41 DAV：無ACE-紛争の前提条件41 DAV：無継承-ACE-紛争の前提条件41 DAV：無反転前提条件41 DAV：無保護-ACE-紛争の前提条件41 DAV： - サポートされていない特権の前提条件42 DAV：数のマッチ-内-limits事後条件48、53 DAV：ownerプロパティ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
DAV：主リソースタイプ13 DAV：主捕集プロパティセット30 DAV：主マッチレポート50 DAV：プリンシパルプロパティ検索51 DAV：主-検索プロパティセット56 DAV：主-URLのプロパティ14 DAV：読み取り特権10 DAV：読み取りACL権限11 DAV：読み取り電流ユーザー特権セット特権12 DAV：認識-主要前提条件42 DAV：サポートされている特権セットプロパティ18 DAV：アンバインド特権12 DAV：特権11 DAVのロックを解除します。特権10 DAVを書く：特典12 DAV-ACLを書く：書き込み内容の特権10 DAV：書き込みプロパティの権限10
M Methods ACL 40
MメソッドACL 40
P Privileges DAV:all 13 DAV:bind 12 DAV:read 10 DAV:read-acl 11 DAV:read-current-user-privilege-set 12 DAV:unbind 12 DAV:unlock 11 DAV:write 10 DAV:write-acl 12 DAV:write-content 11 DAV:write-properties 10 Properties DAV:acl 23 DAV:acl-restrictions 27 DAV:alternate-URI-set 14 DAV:current-user-privilege-set 21 DAV:group 18 DAV:group-member-set 14 DAV:group-membership 14 DAV:inherited-acl-set 29 DAV:owner 15 DAV:principal-collection-set 30 DAV:principal-URL 14 DAV:supported-privilege-set 18
P権限DAV：全13 DAV：バインド12 DAV：10 DAVを読み取る：読み取りACLを11 DAV：読み取り電流ユーザー特権セット12 DAV：アンバインド12 DAV：11 DAVのロックを解除：10 DAVの書き込み：書き込みACL 12 DAV：書き込みコンテンツ11 DAVを：書き込みプロパティ10プロパティDAV：ACL 23 DAV：ACL-制限27 DAV：代替URIセット14 DAV：現在のユーザー特権セット21 DAV：グループ18 DAV：グループメンバーグループメンバーシップ14 DAV：継承-ACLセット29 DAV：所有者は15 DAV：主捕集セット30 DAV：主-URL 14 DAV：サポートされている特権セット18 14 DAVを-set
R Reports DAV:acl-principal-prop-set 47 DAV:principal-match 49 DAV:principal-property-search 51 DAV:principal-search-property-set 56 Resource Types DAV:principal 13
Rは、DAVレポート：ACL-プリンシパル - プロプセット47 DAV：主一致49 DAV：プリンシパルプロパティ検索51 DAV：主-検索プロパティセット56のリソースタイプDAV：プリンシパル13
Authors' Addresses
著者のアドレス
Geoffrey Clemm IBM 20 Maguire Road Lexington, MA 02421
ジェフリー・Clemm IBM 20マグワイアの道レキシントン、MA 02421
EMail: geoffrey.clemm@us.ibm.com
メールアドレス：geoffrey.clemm@us.ibm.com
Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany
ジュリアン・F. Reschke greenbytes社Salzmannstrasse 152ミュンスター、NW 48159ドイツ
EMail: julian.reschke@greenbytes.de
メールアドレス：julian.reschke@greenbytes.de
Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065
エリックSedlar米国Oracle Corporation 500 Oracleのパークウェイレッドウッドショア、CA 94065
EMail: eric.sedlar@oracle.com
メールアドレス：eric.sedlar@oracle.com
Jim Whitehead U.C. Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064
ジム・ホワイトヘッドU.C.サンタクルス、コンピュータサイエンス学科1156ハイストリートサンタクルス、CA 95064
EMail: ejw@cse.ucsc.edu
メールアドレス：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.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。