idnits 2.17.1
draft-ietf-webdav-acl-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== There are 4 instances of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 15 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 2331 has weird spacing: '...contain a DAV...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 26, 2002) is 7945 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'WEBDAV' is mentioned on line 460, but not defined
== Missing Reference: 'RFC2589' is mentioned on line 610, but not defined
== Unused Reference: 'RFC2368' is defined on line 2852, but no explicit
reference was found in the text
== Unused Reference: 'RFC2026' is defined on line 2863, but no explicit
reference was found in the text
== Unused Reference: 'RFC2251' is defined on line 2869, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML'
-- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML-NAMES'
-- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML-INFOSET'
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
-- Obsolete informational reference (is this intentional?): RFC 2255
(Obsoleted by RFC 4510, RFC 4516)
-- Obsolete informational reference (is this intentional?): RFC 2251
(Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513)
Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT Geoffrey Clemm, Rational Software
2 draft-ietf-webdav-acl-09 Anne Hopkins, Microsoft Corporation
3 Eric Sedlar, Oracle Corporation
4 Jim Whitehead, U.C. Santa Cruz
6 Expires January 26, 2003 July 26, 2002
8 WebDAV Access Control Protocol
10 Status of this Memo
12 This document is an Internet-Draft and is subject to all provisions
13 of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six months
18 and may be updated, replaced, or obsoleted by other documents at any
19 time. It is inappropriate to use Internet- Drafts as reference
20 material or to cite them other than as "work in progress."
21 The list of current Internet-Drafts can be accessed at
22 http://www.ietf.org/ietf/1id-abstracts.txt
23 The list of Internet-Draft Shadow Directories can be accessed at
24 http://www.ietf.org/shadow.html.
26 Abstract
28 This document specifies a set of methods, headers, message bodies,
29 properties, and reports that define Access Control extensions to the
30 WebDAV Distributed Authoring Protocol. This protocol permits a client
31 to read and modify access control lists that instruct a server
32 whether to allow or deny operations upon a resource (such as
33 HyperText Transfer Protocol (HTTP) method invocations) by a given
34 principal. A lightweight representation of principals as Web
35 resources supports integration of a wide range of user management
36 repositories. Search operations allow discovery and manipulation of
37 principals using human names.
39 This document is a product of the Web Distributed Authoring and
40 Versioning (WebDAV) working group of the Internet Engineering Task
41 Force. Comments on this draft are welcomed, and should be addressed
42 to the acl@webdav.org mailing list. Other related documents can be
43 found at http://www.webdav.org/acl/, and
44 http://www.ics.uci.edu/pub/ietf/webdav/.
46 Table of Contents
48 1 INTRODUCTION....................................................4
49 1.1 Terms.........................................................7
50 1.2 Notational Conventions........................................8
52 2 PRINCIPALS......................................................8
54 3 PRIVILEGES......................................................9
55 3.1 DAV:read Privilege...........................................10
56 3.2 DAV:write Privilege..........................................10
57 3.3 DAV:write-properties.........................................10
58 3.4 DAV:write-content............................................11
59 3.5 DAV:unlock...................................................11
60 3.6 DAV:read-acl Privilege.......................................12
61 3.7 DAV:read-current-user-privilege-set Privilege................12
62 3.8 DAV:write-acl Privilege......................................12
63 3.9 DAV:all Privilege............................................12
64 3.10 Aggregation of Predefined Privileges........................12
66 4 PRINCIPAL PROPERTIES...........................................13
67 4.1 DAV:alternate-URI-set........................................14
68 4.2 DAV:principal-URL............................................14
69 4.3 DAV:group-member-set.........................................14
70 4.4 DAV:group-membership.........................................14
72 5 ACCESS CONTROL PROPERTIES......................................15
73 5.1 DAV:owner....................................................15
74 5.1.1 Example: Retrieving DAV:owner............................15
75 5.1.2 Example: An Attempt to Set DAV:owner.....................16
76 5.2 DAV:supported-privilege-set..................................17
77 5.2.1 Example: Retrieving a List of Privileges Supported on a
78 Resource.......................................................18
79 5.3 DAV:current-user-privilege-set...............................20
80 5.3.1 Example: Retrieving the User's Current Set of Assigned
81 Privileges.....................................................21
82 5.4 DAV:acl......................................................22
83 5.4.1 ACE Principal............................................22
84 5.4.2 ACE Grant and Deny.......................................24
85 5.4.3 ACE Protection...........................................24
86 5.4.4 ACE Inheritance..........................................24
87 5.4.5 Example: Retrieving a Resource's Access Control List.....25
88 5.5 DAV:acl-semantics............................................26
89 5.5.1 Example: Retrieving DAV:acl-semantics....................27
90 5.6 DAV:inherited-acl-set........................................28
91 5.7 DAV:principal-collection-set.................................28
92 5.7.1 Example: Retrieving DAV:principal-collection-set.........29
93 5.8 Example: PROPFIND to retrieve access control properties......30
94 6 ACL SEMANTICS..................................................34
95 6.1 ACE Combination..............................................34
96 6.1.1 DAV:first-match ACE Combination..........................34
97 6.1.2 DAV:all-grant-before-any-deny ACE Combination............34
98 6.1.3 DAV:specific-deny-overrides-grant ACE Combination........35
99 6.2 ACE Ordering.................................................35
100 6.2.1 DAV:deny-before-grant ACE Ordering.......................35
101 6.3 Allowed ACE..................................................35
102 6.3.1 DAV:principal-only-one-ace ACE Constraint................35
103 6.3.2 DAV:grant-only ACE Constraint............................35
104 6.3.3 DAV:no-invert ACE Constraint.............................36
105 6.4 Required Principals..........................................36
107 7 ACCESS CONTROL AND EXISTING METHODS............................36
108 7.1 OPTIONS......................................................36
109 7.1.1 Example - OPTIONS........................................36
110 7.2 MOVE.........................................................37
111 7.3 COPY.........................................................37
112 7.4 DELETE.......................................................37
113 7.5 LOCK.........................................................37
115 8 ACCESS CONTROL METHODS.........................................37
116 8.1 ACL..........................................................37
117 8.1.1 ACL Preconditions........................................38
118 8.1.2 Example: the ACL method..................................40
119 8.1.3 Example: ACL method failure due to protected ACE
120 conflict ................................................41
121 8.1.4 Example: ACL method failure due to an inherited ACE
122 conflict ................................................42
123 8.1.5 Example: ACL method failure due to an attempt to set
124 grant and deny in a single ACE ..........................43
126 9 ACCESS CONTROL REPORTS.........................................44
127 9.1 REPORT Method................................................44
128 9.2 DAV:acl-principal-prop-set Report............................44
129 9.2.1 Example: DAV:acl-principal-prop-set Report...............45
130 9.3 DAV:principal-match REPORT...................................46
131 9.3.1 Example: DAV:principal-match REPORT......................48
132 9.4 DAV:principal-property-search REPORT.........................48
133 9.4.1 Matching.................................................51
134 9.4.2 Example: successful DAV:principal-property-search REPORT 51
135 9.4.3 Example: Unsuccessful DAV:principal-property-search
136 REPORT ..................................................53
137 9.5 DAV:principal-search-property-set REPORT.....................54
138 9.5.1 Example: DAV:principal-search-property-set REPORT........56
140 10 XML PROCESSING...............................................57
142 11 INTERNATIONALIZATION CONSIDERATIONS..........................57
143 12 SECURITY CONSIDERATIONS......................................58
144 12.1 Increased Risk of Compromised Users.........................58
145 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
146 Privileges.......................................................58
147 12.3 No Foreknowledge of Initial ACL.............................59
149 13 AUTHENTICATION...............................................59
151 14 IANA CONSIDERATIONS..........................................60
153 15 INTELLECTUAL PROPERTY........................................60
155 16 ACKNOWLEDGEMENTS.............................................60
157 17 REFERENCES...................................................61
158 17.1 Normative References........................................61
159 17.2 Informational References....................................61
161 18 AUTHORS' ADDRESSES...........................................62
163 19 APPENDICES...................................................63
164 19.1 WebDAV XML Document Type Definition Addendum................63
166 1 INTRODUCTION
168 The goal of the WebDAV access control extensions is to provide an
169 interoperable mechanism for handling discretionary access control
170 for content and metadata managed by WebDAV servers. WebDAV access
171 control can be implemented on content repositories with security as
172 simple as that of a UNIX file system, as well as more sophisticated
173 models. The underlying principle of access control is that who you
174 are determines what operations you can perform on a resource. The
175 "who you are" is defined by a "principal" identifier; users, client
176 software, servers, and groups of the previous have principal
177 identifiers. The "operations you can perform" are determined by a
178 single "access control list" (ACL) associated with a resource. An
179 ACL contains a set of "access control entries" (ACEs), where each
180 ACE specifies a principal and a set of privileges that are either
181 granted or denied to that principal. When a principal submits an
182 operation (such as an HTTP or WebDAV method) to a resource for
183 execution, the server evaluates the ACEs in the ACL to determine if
184 the principal has permission for that operation.
186 Since every ACE contains the identifier of a principal, client
187 software operated by a human must provide a mechanism for selecting
188 this principal. This specification uses http(s) scheme URLs to
189 identify principals, which are represented as WebDAV-capable
190 resources. There is no guarantee that the URLs identifying
191 principals will be meaningful to a human. For example,
192 http://www.dav.org/u/256432 and
193 http://www.dav.org/people/Greg.Stein are both valid URLs that could
194 be used to identify the same principal. To remedy this, every
195 principal resource has the DAV:displayname property containing a
196 human-readable name for the principal.
198 Since a principal can be identified by multiple URLs, it raises the
199 problem of determining exactly which principal is being referenced
200 in a given ACE. It is impossible for a client to determine that an
201 ACE granting the read privilege to
202 http://www.dav.org/people/Greg.Stein also affects the principal at
203 http://www.dav.org/u/256432. That is, a client has no mechanism for
204 determining that two URLs identify the same principal resource. As
205 a result, this specification requires clients to use just one of
206 the many possible URLs for a principal when creating ACEs. A client
207 can discover which URL to use by retrieving the DAV:principal-URL
208 property (Section 4.2) from a principal resource. No matter which
209 of the principal's URLs is used with PROPFIND, the property always
210 returns the same URL.
212 With a system having hundreds to thousands of principals, the
213 problem arises of how to allow a human operator of client software
214 to select just one of these principals. One approach is to use
215 broad collection hierarchies to spread the principals over a large
216 number of collections, yielding few principals per collection. An
217 example of this is a two level hierarchy with the first level
218 containing 36 collections (a-z, 0-9), and the second level being
219 another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such
220 that a principal with last name "Stein" would appear at /s/t/Stein.
221 In effect, this pre-computes a common query, search on last name,
222 and encodes it into a hierarchy. The drawback with this scheme is
223 that it handles only a small set of predefined queries, and
224 drilling down through the collection hierarchy adds unnecessary
225 steps (navigate down/up) when the user already knows the
226 principal's name. While organizing principal URLs into a hierarchy
227 is a valid namespace organization, users should not be forced to
228 navigate this hierarchy to select a principal.
230 This specification provides the capability to perform substring
231 searches over a small set of properties on the resources
232 representing principals. This permits searches based on last name,
233 first name, user name, job title, etc. Two separate searches are
234 supported, both via the REPORT method, one to search principal
235 resources (DAV:principal-property-search, Section 9.4), the other
236 to determine which properties may be searched at all
237 (DAV:principal-search-property-set, Section 9.5).
239 Once a principal has been identified in an ACE, a server evaluating
240 that ACE must know the identity of the principal making a protocol
241 request, and must validate that that principal is who they claim to
242 be, a process known as authentication. This specification
243 intentionally omits discussion of authentication, as the HTTP
244 protocol already has a number of authentication mechanisms
245 [RFC2617]. Some authentication mechanism (such as HTTP Digest
246 Authentication, which all WebDAV compliant implementations are
247 required to support) must be available to validate the identity of
248 a principal.
250 The following issues are out of scope for this document:
252 * Access control that applies only to a particular property on a
253 resource (excepting the access control properties DAV:acl and
254 DAV:current-user-privilege-set), rather than the entire
255 resource,
257 * Role-based security (where a role can be seen as a dynamically
258 defined group of principals),
260 * Specification of the ways an ACL on a resource is initialized,
262 * Specification of an ACL that applies globally to all
263 resources, rather than to a particular resource.
265 * Creation and maintenance of resources representing people or
266 computational agents (principals), and groups of these.
268 This specification is organized as follows. Section 1.1 defines key
269 concepts used throughout the specification, and is followed by a
270 more in-depth discussion of principals (Section 2), and privileges
271 (Section 3). Properties defined on principals are specified in
272 Section 4, and access control properties for content resources are
273 specified in Section 5. The semantics of access control lists are
274 described in Section 6, including sections on ACE combination
275 (Section 6.1), ACE ordering (Section 6.2), and principals required
276 to be present in an ACE (Section 6.3.2). Client discovery of access
277 control capability using OPTIONS is described in Section 7.1.
278 Interactions between access control functionality and existing HTTP
279 and WebDAV methods are described in the remainder of Section 7. The
280 access control setting method, ACL, is specified in Section 8. Four
281 reports that provide limited server-side searching capabilities are
282 described in Section 9. Sections on XML processing (Section 10),
283 Internationalization considerations (Section 11), security
284 considerations (Section 12), and authentication (Section 13) round
285 out the specification. An appendix (Section 19.1) provides an XML
286 Document Type Definition (DTD) for the XML elements defined in the
287 specification.
289 1.1 Terms
291 This draft uses the terms defined in HTTP [RFC2616] and WebDAV
292 [RFC2518]. In addition, the following terms are defined:
294 principal
295 A "principal" is a distinct human or computational actor that
296 initiates access to network resources. In this protocol, a
297 principal is an HTTP resource that represents such an actor.
299 group
300 A "group" is a principal that represents a set of other principals.
302 privilege
303 A "privilege" controls access to a particular set of HTTP
304 operations on a resource.
306 aggregate privilege
307 An "aggregate privilege" is a privilege that contains a set of
308 other privileges.
310 abstract privilege
311 The modifier "abstract", when applied to a privilege on a resource,
312 means the privilege cannot be set in an access control element
313 (ACE) on that resource .
315 access control list (ACL)
316 An "ACL" is a list of access control elements that define access
317 control to a particular resource.
319 access control element (ACE)
320 An "ACE" either grants or denies a particular set of (non-abstract)
321 privileges for a particular principal.
323 inherited ACE
324 An "inherited ACE" is an ACE that is dynamically shared from the
325 ACL of another resource. When a shared ACE changes on the primary
326 resource, it is also changed on inheriting resources.
328 protected property
329 A "protected property" is one whose value cannot be updated except
330 by a method explicitly defined as updating that specific property.
331 In particular, a protected property cannot be updated with a
332 PROPPATCH request.
334 1.2 Notational Conventions
336 The augmented BNF used by this document to describe protocol
337 elements is described in Section 2.1 of [RFC2616]. Because this
338 augmented BNF uses the basic production rules provided in Section
339 2.2 of [RFC2616], those rules apply to this document as well.
341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
343 this document are to be interpreted as described in [RFC2119].
345 Definitions of XML elements in this document use XML element type
346 declarations (as found in XML Document Type Declarations),
347 described in Section 3.2 of [REC-XML]. When an XML element type in
348 the "DAV:" namespace is referenced in this document outside of the
349 context of an XML fragment, the string "DAV:" will be prefixed to
350 the element name.
352 2 PRINCIPALS
354 A principal is a network resource that represents a distinct human
355 or computational actor that initiates access to network resources.
356 Users and groups are represented as principals in many
357 implementations; other types of principals are also possible. A URI
358 of any scheme MAY be used to identify a principal resource.
359 However, servers implementing this specification MUST expose
360 principal resources at an http(s) URL, which is a privileged scheme
361 that points to resources that have additional properties, as
362 described in Section 4. So, a principal resource can have multiple
363 URIs, one of which has to be an http(s) scheme URL. Although an
364 implementation SHOULD support PROPFIND and MAY support PROPPATCH to
365 access and modify information about a principal, it is not required
366 to do so.
368 A principal resource may be a group, where a group is a principal
369 that represents a set of other principals, called the members of
370 the group. If a person or computational agent matches a principal
371 resource that is a member of a group, they also match the group.
372 Membership in a group is recursive, so if a principal is a member
373 of group GRPA, and GRPA is a member of group GRPB, then the
374 principal is also a member of GRPB.
376 3 PRIVILEGES
378 Ability to perform a given method on a resource SHOULD be
379 controlled by one or more privileges. Authors of protocol
380 extensions that define new HTTP methods SHOULD specify which
381 privileges (by defining new privileges, or mapping to ones below)
382 are required to perform the method. A principal with no privileges
383 to a resource SHOULD be denied any HTTP access to that resource,
384 unless the principal matches an ACE constructed using the DAV:all,
385 DAV:authenticated, or DAV:unauthenticated pseudo-principals (see
386 Section 5.4.1).
388 Privileges may be containers of other privileges, in which case
389 they are termed "aggregate privileges". If a principal is granted
390 or denied an aggregate privilege, it is semantically equivalent to
391 granting or denying each of the aggregated privileges individually.
392 For example, an implementation may define add-member and remove-
393 member privileges that control the ability to add and remove a
394 member of a group. Since these privileges control the ability to
395 update the state of a group, these privileges would be aggregated
396 by the DAV:write privilege on a group, and granting the DAV:write
397 privilege on a group would also grant the add-member and remove-
398 member privileges.
400 Privileges may be declared to be "abstract" for a given resource,
401 in which case they cannot be set in an ACE on that resource.
402 Aggregate and non-aggregate privileges are both capable of being
403 abstract. Abstract privileges are useful for modeling privileges
404 that otherwise would not be exposed via the protocol. Abstract
405 privileges also provide server implementations with flexibility in
406 implementing the privileges defined in this specification. For
407 example, if a server is incapable of separating the read resource
408 capability from the read ACL capability, it can still model the
409 DAV:read and DAV:read-acl privileges defined in this specification
410 by declaring them abstract, and containing them within a non-
411 abstract aggregate privilege (say, read-all) that holds DAV:read,
412 and DAV:read-acl. In this way, it is possible to set the aggregate
413 privilege, read-all, thus coupling the setting of DAV:read and
414 DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-
415 acl individually. Since aggregate privileges can be abstract, it is
416 also possible to use abstract privileges to group or organize non-
417 abstract privileges. Privilege containment loops are not allowed;
418 therefore, a privilege MUST NOT contain itself. For example,
419 DAV:read cannot contain DAV:read.
421 The set of privileges that apply to a particular resource may vary
422 with the DAV:resourcetype of the resource, as well as between
423 different server implementations. To promote interoperability,
424 however, this specification defines a set of well-known privileges
425 (e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
426 current-user-privilege-set, and DAV:all), which can at least be
427 used to classify the other privileges defined on a particular
428 resource. The access permissions on null resources (defined in
429 [RFC2518], Section 3) are solely those they inherit (if any), and
430 they are not discoverable (i.e., the access control properties
431 specified in Section 5 are not defined on null resources). On the
432 transition from null to stateful resource, the initial access
433 control list is set by the server's default ACL value policy (if
434 any).
436 Server implementations MAY define new privileges beyond those
437 defined in this specification. Privileges defined by individual
438 implementations MUST NOT use the DAV: namespace, and instead should
439 use a namespace that they control, such as an http scheme URL.
441 3.1 DAV:read Privilege
443 The read privilege controls methods that return information about
444 the state of the resource, including the resource's properties.
445 Affected methods include GET and PROPFIND. Any implementation-
446 defined privilege that also controls access to GET and PROPFIND
447 must be aggregated under DAV:read�if an ACL grants access to
448 DAV:read, the client may expect that no other privilege needs to be
449 granted to have access to GET and PROPFIND. Additionally, the read
450 privilege MAY control the OPTIONS method.
452
454 3.2 DAV:write Privilege
456 The write privilege controls methods that lock a resource or modify
457 the content, dead properties, or (in the case of a collection)
458 membership of the resource, such as PUT and PROPPATCH. Note that
459 state modification is also controlled via locking (see section 5.3
460 of [WEBDAV]), so effective write access requires that both write
461 privileges and write locking requirements are satisfied. Any
462 implementation-defined privilege that also controls access to
463 methods modifying content, dead properties or collection membership
464 must be aggregated under DAV:write, e.g. if an ACL grants access to
465 DAV:write, the client may expect that no other privilege needs to
466 be granted to have access to PUT and PROPPATCH.
468
470 3.3 DAV:write-properties
472 The DAV:write-properties privilege controls methods that modify the
473 dead properties of the resource, such as PROPPATCH. Whether this
474 privilege may be used to control access to any live properties is
475 determined by the implementation. Any implementation-defined
476 privilege that also controls access to methods modifying dead
477 properties must be aggregated under DAV:write-properties�e.g. if an
478 ACL grants access to DAV:write-properties, the client can safely
479 expect that no other privilege needs to be granted to have access
480 to PROPPATCH.
482
484 3.4 DAV:write-content
486 The DAV:write-content privilege controls methods that modify the
487 content or (in the case of a collection) membership of the
488 resource, such as PUT and DELETE. Any implementation-defined
489 privilege that also controls access to content or alteration of
490 collection membership must be aggregated under DAV:write-content�
491 e.g. if an ACL grants access to DAV:write-content, the client can
492 safely expect that no other privilege needs to be granted to have
493 access to PUT or DELETE.
495
497 3.5 DAV:unlock
499 The DAV:unlock privilege controls the use of the UNLOCK method by a
500 principal other than the lock owner (the principal that created a
501 lock can always perform an UNLOCK). While the set of users who may
502 lock a resource is most commonly the same set of users who may
503 modify a resource, servers may allow various kinds of
504 administrators to unlock resources locked by others. Any privilege
505 controlling access by non-lock owners to UNLOCK MUST be aggregated
506 under DAV:unlock.
508 A lock owner can always remove a lock by issuing an UNLOCK with the
509 correct lock token and authentication credentials. That is, even if
510 a principal does not have DAV:unlock privilege, they can still
511 remove locks they own. Principals other than the lock owner can
512 remove a lock only if they have DAV:unlock privilege and they issue
513 an UNLOCK with the correct lock token. Lock timeout is not affected
514 by the DAV:unlock privilege.
516
517 3.6 DAV:read-acl Privilege
519 The DAV:read-acl privilege controls the use of PROPFIND to retrieve
520 the DAV:acl property of the resource.
522
524 3.7 DAV:read-current-user-privilege-set Privilege
526 The DAV:read-current-user-privilege-set privilege controls the use
527 of PROPFIND to retrieve the DAV:current-user-privilege-set property
528 of the resource.
530 Clients are intended to use this property to visually indicate in
531 their UI items that are dependent on the permissions of a resource,
532 for example, by graying out resources that are not writeable.
534 This privilege is separate from DAV:read-acl because there is a
535 need to allow most users access to the privileges permitted the
536 current user (due to its use in creating the UI), while the full
537 ACL contains information that may not be appropriate for the
538 current authenticated user. As a result, the set of users who can
539 view the full ACL is expected to be much smaller than those who can
540 read the current user privilege set, and hence distinct privileges
541 are needed for each.
543
545 3.8 DAV:write-acl Privilege
547 The DAV:write-acl privilege controls use of the ACL method to
548 modify the DAV:acl property of the resource.
550
552 3.9 DAV:all Privilege
554 DAV:all is an aggregate privilege that contains the entire set of
555 privileges that can be applied to the resource.
557
559 3.10 Aggregation of Predefined Privileges
561 Server implementations are free to aggregate the predefined
562 privileges (defined above in Sections 3.1-3.9) subject to the
563 following limitations:
565 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,
566 DAV:write-properties, DAV:write-content, or DAV:read-current-user-
567 privilege-set.
569 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl,
570 or DAV:read-current-user-privilege-set.
572 DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
573 DAV:read, DAV:read-acl, or DAV:write-acl.
575 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
576 current-user-privilege-set.
578 DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-
579 properties, or DAV:write-content.
581 DAV:write MUST contain DAV:write-properties and DAV:write-content.
583 4 PRINCIPAL PROPERTIES
585 Principals are manifested to clients as a WebDAV resource,
586 identified by a URL. A principal MUST have a non-empty
587 DAV:displayname property (defined in Section 13.2 of [RFC2518]),
588 and a DAV:resourcetype property (defined in Section 13.9 of
589 [RFC2518]). Additionally, a principal MUST report the
590 DAV:principal XML element in the value of the DAV:resourcetype
591 property. The element type declaration for DAV:principal is:
593
595 This protocol defines the following additional properties for a
596 principal. Since it can be expensive for a server to retrieve
597 access control information, the name and value of these properties
598 SHOULD NOT be returned by a PROPFIND allprop request (as defined in
599 Section 12.14.1 of [RFC2518]).
601 4.1 DAV:alternate-URI-set
603 This protected property, if non-empty, contains the URIs of network
604 resources with additional descriptive information about the
605 principal. This property identifies additional network resources
606 (i.e., it contains one or more URIs) that may be consulted by a
607 client to gain additional knowledge concerning a principal. One
608 expected use for this property is the storage of an LDAP [RFC2255]
609 scheme URL. A user-agent encountering an LDAP URL could use LDAP
610 [RFC2589] to retrieve additional machine-readable directory
611 information about the principal, and display that information in
612 its user interface. Support for this property is REQUIRED, and the
613 value is empty if no alternate URI exists for the principal.
615
617 4.2 DAV:principal-URL
619 A principal may have many URLs, but there must be one primary URL
620 that clients can use to uniquely identify a principal�the
621 principal-URL. This protected property contains the URL that MUST
622 be used to identify this principal in an ACL request. Support for
623 this property is REQUIRED.
625
627 4.3 DAV:group-member-set
629 This property of a group principal identifies the principals that
630 are direct members of this group. Since a group may be a member of
631 another group, a group may also have indirect members (i.e. the
632 members of its direct members). A URL in the DAV:group-member-set
633 for a principal MUST be the DAV:principal-URL of that principal.
635
637 4.4 DAV:group-membership
639 This protected property identifies the groups in which the
640 principal is directly a member. Note that a server may allow a
641 group to be a member of another group, in which case the DAV:group-
642 membership of those other groups would need to be queried in order
643 to determine the groups in which the principal is indirectly a
644 member. Support for this property is REQUIRED.
646
647 5 ACCESS CONTROL PROPERTIES
649 This specification defines a number of new properties for WebDAV
650 resources. Access control properties may be retrieved just like
651 other WebDAV properties, using the PROPFIND method. Since it is
652 expensive, for many servers, to retrieve access control
653 information, a PROPFIND allprop request (as defined in Section
654 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the
655 properties defined in this section.
657 HTTP resources that support the WebDAV Access Control Protocol MUST
658 contain the following properties. Null resources (described in
659 Section 3 of [RFC2518]) MUST NOT contain the following properties:
661 5.1 DAV:owner
663 This protected property identifies a particular principal as being
664 the "owner" of the resource. Since the owner of a resource often
665 has special access control capabilities (e.g., the owner frequently
666 has permanent DAV:write-acl privilege), clients might display the
667 resource owner in their user interface.
669
671 5.1.1 Example: Retrieving DAV:owner
673 This example shows a client request for the value of the DAV:owner
674 property from a collection resource with URL
675 http://www.webdav.org/papers/. The principal making the request is
676 authenticated using Digest authentication. The value of DAV:owner
677 is the URL http://www.webdav.org/acl/users/gstein, wrapped in the
678 DAV:href XML element.
680 >> Request <<
682 PROPFIND /papers/ HTTP/1.1
683 Host: www.webdav.org
684 Content-type: text/xml; charset="utf-8"
685 Content-Length: xxx
686 Depth: 0
687 Authorization: Digest username="jim",
688 realm="jim@webdav.org", nonce="...",
689 uri="/papers/", response="...", opaque="..."
691
692
693
694
695
696
697 >> Response <<
699 HTTP/1.1 207 Multi-Status
700 Content-Type: text/xml; charset="utf-8"
701 Content-Length: xxx
703
704
705
706 http://www.webdav.org/papers/
707
708
709
710 http://www.webdav.org/acl/users/gstein
711
712
713 HTTP/1.1 200 OK
714
715
716
718 5.1.2 Example: An Attempt to Set DAV:owner
720 The following example shows a client request to modify the value of
721 the DAV:owner property on the resource with URL
722 . Since DAV:owner is a protected
723 property, the server responds with a 207 (Multi-Status) response
724 that contains a 403 (Forbidden) status code for the act of setting
725 DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status
726 code information, and Section 11 of [RFC2518] describes the Multi-
727 Status response.
729 >> Request <<
731 PROPPATCH /papers/ HTTP/1.1
732 Host: www.webdav.org
733 Content-type: text/xml; charset="utf-8"
734 Content-Length: xxx
735 Depth: 0
736 Authorization: Digest username="jim",
737 realm="jim@webdav.org", nonce="...",
738 uri="/papers/", response="...", opaque="..."
740
741
742
743
744
745 http://www.webdav.org/acl/users/jim
746
747
748
749
751 >> Response <<
753 HTTP/1.1 207 Multi-Status
754 Content-Type: text/xml; charset="utf-8"
755 Content-Length: xxx
757
758
759
760 http://www.webdav.org/papers/
761
762
763 HTTP/1.1 403 Forbidden
764
765 Failure to set protected property (DAV:owner)
766
767
768
769
771 5.2 DAV:supported-privilege-set
773 This is a protected property that identifies the privileges defined
774 for the resource.
776
778 Each privilege appears as an XML element, where aggregate
779 privileges list as sub-elements all of the privileges that they
780 aggregate.
782
784
786 An abstract privilege MUST NOT be used in an ACE for that resource.
787 Servers MUST fail an attempt to set an abstract privilege.
789
790 A description is a human-readable description of what this
791 privilege controls access to. Servers MUST indicate the human
792 language of the description using the xml:lang attribute and SHOULD
793 consider the HTTP Accept-Language request header when selecting one
794 of multiple available languages.
796
798 It is envisioned that a WebDAV ACL-aware administrative client
799 would list the supported privileges in a dialog box, and allow the
800 user to choose non-abstract privileges to apply in an ACE. The
801 privileges tree is useful programmatically to map well-known
802 privileges (defined by WebDAV or other standards groups) into
803 privileges that are supported by any particular server
804 implementation. The privilege tree also serves to hide complexity
805 in implementations allowing large number of privileges to be
806 defined by displaying aggregates to the user.
808 5.2.1 Example: Retrieving a List of Privileges Supported on a
809 Resource
811 This example shows a client request for the DAV:supported-
812 privilege-set property on the resource
813 http://www.webdav.org/papers/. The value of the DAV:supported-
814 privilege-set property is a tree of supported privileges (using
815 "[XML Namespace , localname]" to identify each privilege):
817 [DAV:, all] (aggregate, abstract)
818 |
819 +-- [DAV:, read] (aggregate)
820 |
821 +-- [DAV:, read-acl] (abstract)
822 +-- [DAV:, read-current-user-privilege-set] (abstract)
823 |
824 +-- [DAV:, write] (aggregate)
825 |
826 +-- [DAV:, write-acl] (abstract)
827 +-- [DAV:, write-properties]
828 +-- [DAV:, write-content]
829 |
830 +-- [DAV:, unlock]
832 This privilege tree is not normative (except that it reflects the
833 normative aggregation rules given in Section 3.10), and many
834 possible privilege trees are possible.
836 >> Request <<
838 PROPFIND /papers/ HTTP/1.1
839 Host: www.webdav.org
840 Content-type: text/xml; charset="utf-8"
841 Content-Length: xxx
842 Depth: 0
843 Authorization: Digest username="gclemm",
844 realm="gclemm@webdav.org", nonce="...",
845 uri="/papers/", response="...", opaque="..."
847
848
849
850
851
852
854 >> Response <<
856 HTTP/1.1 207 Multi-Status
857 Content-Type: text/xml; charset="utf-8"
858 Content-Length: xxx
860
861
862
863 http://www.webdav.org/papers/
864
865
866
867
868
869
870 Any
871 operation
872
873
874 Read any
875 object
876
877
878
879 Read
880 ACL
881
882
883
884
885
886
887 Read current user
888 privilege set property
889
890
891
892
893 Write any
894 object
895
896
897 Write
898 ACL
899
900
901
902
903 Write
904 properties
905
906
907
908 Write resource
909 content
910
911
912
913
914 Unlock
915 resource
916
917
918
919
920 HTTP/1.1 200 OK
921
922
923
925 5.3 DAV:current-user-privilege-set
927 DAV:current-user-privilege-set is a protected property containing
928 the exact set of privileges (as computed by the server) granted to
929 the currently authenticated HTTP user. Aggregate privileges and
930 their contained privileges are listed. A user-agent can use the
931 value of this property to adjust its user interface to make actions
932 inaccessible (e.g., by graying out a menu item or button) for which
933 the current principal does not have permission. This is
934 particularly useful for an access control user interface, which can
935 be constructed without knowing the ACE combining semantics of the
936 server. This property is also useful for determining what
937 operations the current principal can perform, without having to
938 actually execute an operation.
940
941
943 If the current user is granted a specific privilege, that privilege
944 must belong to the set of privileges that may be set on this
945 resource. Therefore, each element in the DAV:current-user-
946 privilege-set property MUST identify a non-abstract privilege from
947 the DAV:supported-privilege-set property.
949 5.3.1 Example: Retrieving the User's Current Set of Assigned
950 Privileges
952 Continuing the example from Section 5.2.1, this example shows a
953 client requesting the DAV:current-user-privilege-set property from
954 the resource with URL http://www.webdav.org/papers/. The username
955 of the principal making the request is "khare", and Digest
956 authentication is used in the request. The principal with username
957 "khare" has been granted the DAV:read privilege. Since the DAV:read
958 privilege contains the DAV:read-acl and DAV:read-current-user-
959 privilege-set privileges (see Section 5.2.1), the principal with
960 username "khare" can read the ACL property, and the DAV:current-
961 user-privilege-set property. However, the DAV:all, DAV:read-acl,
962 DAV:write-acl and DAV:read-current-user-privilege-set privileges
963 are not listed in the value of DAV:current-user-privilege-set,
964 since (for this example) they are abstract privileges. DAV:write is
965 not listed since the principal with username "khare" is not listed
966 in an ACE granting that principal write permission.
968 >> Request <<
970 PROPFIND /papers/ HTTP/1.1
971 Host: www.webdav.org
972 Content-type: text/xml; charset="utf-8"
973 Content-Length: xxx
974 Depth: 0
975 Authorization: Digest username="khare",
976 realm="khare@webdav.org", nonce="...",
977 uri="/papers/", response="...", opaque="..."
978
979
980
981
982
983
985 >> Response <<
987 HTTP/1.1 207 Multi-Status
988 Content-Type: text/xml; charset="utf-8"
989 Content-Length: xxx
991
992
993
994 http://www.webdav.org/papers/
995
996
997
998
999
1000
1001 HTTP/1.1 200 OK
1002
1003
1004
1006 5.4 DAV:acl
1008 This is a protected property that specifies the list of access
1009 control entries (ACEs), which define what principals are to get
1010 what privileges for this resource.
1012
1014 Each DAV:ace element specifies the set of privileges to be either
1015 granted or denied to a single principal. If the DAV:acl property
1016 is empty, no principal is granted any privilege.
1018
1021 5.4.1 ACE Principal
1023 The DAV:principal element identifies the principal to which this
1024 ACE applies.
1026
1030 The current user matches DAV:href only if that user is
1031 authenticated as being (or being a member of) the principal
1032 identified by the URL contained by that DAV:href.
1034 The current user always matches DAV:all.
1036
1038 The current user matches DAV:authenticated only if authenticated.
1040
1042 The current user matches DAV:unauthenticated only if not
1043 authenticated.
1045
1047 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated.
1048 For a given request, the user matches either DAV:authenticated, or
1049 DAV:unauthenticated, but not both (that is, DAV:authenticated and
1050 DAV:unauthenticated are disjoint sets).
1052 The current user matches a DAV:property principal in a DAV:acl
1053 property of a resource only if the value of the identified property
1054 of that resource contains at most one DAV:href XML element, the URI
1055 value of DAV:href identifies a principal, and the current user is
1056 authenticated as being (or being a member of) that principal. For
1057 example, if the DAV:property element contained , the
1058 current user would match the DAV:property principal only if the
1059 current user is authenticated as matching the principal identified
1060 by the DAV:owner property of the resource.
1062
1064 Alternately, some servers may support ACEs applying to those users
1065 NOT matching the current principal, e.g. all users not in a
1066 particular group. This can be done by wrapping the DAV:principal
1067 element with DAV:invert.
1069
1070 The current user matches DAV:self in a DAV:acl property of the
1071 resource only if that resource is a principal and that principal
1072 matches the current user or, if the principal is a group, a member
1073 of that group matches the current user.
1075
1077 5.4.2 ACE Grant and Deny
1079 Each DAV:grant or DAV:deny element specifies the set of privileges
1080 to be either granted or denied to the specified principal. A
1081 DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
1082 only contain non-abstract elements specified in the DAV:supported-
1083 privilege-set of that resource.
1085
1086
1087
1089 5.4.3 ACE Protection
1091 A server indicates an ACE is protected by including the
1092 DAV:protected element in the ACE. If the ACL of a resource contains
1093 an ACE with a DAV:protected element, an attempt to remove that ACE
1094 from the ACL MUST fail.
1096
1098 5.4.4 ACE Inheritance
1100 The presence of a DAV:inherited element indicates that this ACE is
1101 inherited from another resource that is identified by the URL
1102 contained in a DAV:href element. An inherited ACE cannot be
1103 modified directly, but instead the ACL on the resource from which
1104 it is inherited must be modified.
1106 Note that ACE inheritance is not the same as ACL initialization.
1107 ACL initialization defines the ACL that a newly created resource
1108 will use (if not specified). ACE inheritance refers to an ACE that
1109 is logically shared - where an update to the resource containing an
1110 ACE will affect the ACE of each resource that inherits that ACE.
1111 The method by which ACLs are initialized or by which ACEs are
1112 inherited is not defined by this document.
1114
1115 5.4.5 Example: Retrieving a Resource's Access Control List
1117 Continuing the example from Sections 5.2.1 and 5.3.1, this example
1118 shows a client requesting the DAV:acl property from the resource
1119 with URL http://www.webdav.org/papers/. There are two ACEs defined
1120 in this ACL:
1122 ACE #1: The group identified by URL
1123 http://www.webdav.org/acl/groups/maintainers (the group of site
1124 maintainers) is granted DAV:write privilege. Since (for this
1125 example) DAV:write contains the DAV:write-acl privilege (see
1126 Section 5.2.1), this means the "maintainers" group can also modify
1127 the access control list.
1129 ACE #2: All principals (DAV:all) are granted the DAV:read
1130 privilege. Since (for this example) DAV:read contains DAV:read-acl
1131 and DAV:read-current-user-privilege-set, this means all users
1132 (including all members of the "maintainers" group) can read the
1133 DAV:acl property and the DAV:current-user-privilege-set property.
1135 >> Request <<
1137 PROPFIND /papers/ HTTP/1.1
1138 Host: www.webdav.org
1139 Content-type: text/xml; charset="utf-8"
1140 Content-Length: xxx
1141 Depth: 0
1142 Authorization: Digest username="masinter",
1143 realm="webdav.org", nonce="...",
1144 uri="/papers/", response="...", opaque="..."
1146
1147
1148
1149
1150
1151
1153 >> Response <<
1155 HTTP/1.1 207 Multi-Status
1156 Content-Type: text/xml; charset="utf-8"
1157 Content-Length: xxx
1159
1160
1161
1162 http://www.webdav.org/papers/
1163
1164
1165
1166
1167
1168 http://www.webdav.org/acl/groups/maintainers
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184 HTTP/1.1 200 OK
1185
1186
1187
1189 5.5 DAV:acl-semantics
1191 This is a protected property that defines the ACL semantics of the
1192 ACEs specified in the DAV:acl property of this resource. These
1193 semantics define how multiple ACEs that match the current user are
1194 combined, what are the constraints on how ACEs can be ordered, and
1195 which principals must have an ACE. A client user interface could
1196 use the value of this property to provide feedback to a human
1197 operator concerning the impact of proposed changes to an ACL.
1198 Alternately, a client can use this property to help it determine,
1199 before submitting an ACL method invocation, what ACL changes it
1200 needs to make to accomplish a specific goal (or whether that goal
1201 is even achievable on this server).
1203 Since it is not practical to require all implementations to use the
1204 same ACL semantics, the DAV:acl-semantics property is used to
1205 identify the ACL semantics for a particular resource. The DAV:acl-
1206 semantics element is defined in Section 6.
1208 5.5.1 Example: Retrieving DAV:acl-semantics
1210 In this example, the client requests the value of the DAV:acl-
1211 semantics property. Digest authentication provides credentials for
1212 the principal operating the client. In this example, the ACE
1213 combination semantics are DAV:first-match, described in Section
1214 6.1.1, the ACE ordering semantics are not specified (some value
1215 other than DAV:deny-before-grant, described in Section 6.2.1), the
1216 DAV:allowed-ace element states that only one ACE is permitted for
1217 each principal, and an ACE describing the privileges granted the
1218 DAV:all principal must exist in every ACL.
1220 >> Request <<
1222 PROPFIND /papers/ HTTP/1.1
1223 Host: www.webdav.org
1224 Content-type: text/xml; charset="utf-8"
1225 Content-Length: xxx
1226 Depth: 0
1227 Authorization: Digest username="srcarter",
1228 realm="srcarter@webdav.org", nonce="...",
1229 uri="/papers/", response="...", opaque="..."
1231
1232
1233
1234
1235
1236
1238 >> Response <<
1240 HTTP/1.1 207 Multi-Status
1241 Content-Type: text/xml; charset="utf-8"
1242 Content-Length: xxx
1244
1245
1246
1247 http://www.webdav.org/papers/
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263 HTTP/1.1 200 OK
1264
1265
1266
1268 5.6 DAV:inherited-acl-set
1270 This protected property contains a set of URLs that identify other
1271 resources that also control the access to this resource. To have a
1272 privilege on a resource, not only must the ACL on that resource
1273 (specified in the DAV:acl property of that resource) grant the
1274 privilege, but so must the ACL of each resource identified in the
1275 DAV:inherited-acl-set property of that resource. Effectively, the
1276 privileges granted by the current ACL are ANDed with the privileges
1277 granted by each inherited ACL.
1279
1281 Note that the ACL semantics of a resource are specified in the
1282 DAV:acl-semantics property of that resource, and therefore each
1283 inherited ACL can have different ACL semantics.
1285 5.7 DAV:principal-collection-set
1287 This protected property of a resource contains a set of URLs that
1288 identify the root collections that contain the principals that are
1289 available on the server that implements this resource. A WebDAV
1290 Access Control Protocol user agent could use the contents of
1291 DAV:principal-collection-set to retrieve the DAV:displayname
1292 property (specified in Section 13.2 of [RFC2518]) of all principals
1293 on that server, thereby yielding human-readable names for each
1294 principal that could be displayed in a user interface.
1296
1297 Since different servers can control different parts of the URL
1298 namespace, different resources on the same host MAY have different
1299 DAV:principal-collection-set values. The collections specified in
1300 the DAV:principal-collection-set MAY be located on different hosts
1301 from the resource. The URLs in DAV:principal-collection-set SHOULD
1302 be http or https scheme URLs. For security and scalability reasons,
1303 a server MAY report only a subset of the entire set of known
1304 principal collections, and therefore clients should not assume they
1305 have retrieved an exhaustive listing. Additionally, a server MAY
1306 elect to report none of the principal collections it knows about,
1307 in which case the property value would be empty.
1309 The value of DAV:principal-collection-set gives the scope of the
1310 DAV:principal-property-search REPORT (defined in Section 9.4).
1311 Clients use the DAV:principal-property-search REPORT to populate
1312 their user interface with a list of principals. Therefore, servers
1313 that limit a client's ability to obtain principal information will
1314 interfere with the client's ability to manipulate access control
1315 lists, due to the difficulty of getting the URL of a principal for
1316 use in an ACE.
1318 5.7.1 Example: Retrieving DAV:principal-collection-set
1320 In this example, the client requests the value of the
1321 DAV:principal-collection-set property on the collection resource
1322 identified by URL http://www.webdav.org/papers/. The property
1323 contains the two URLs, http://www.webdav.org/acl/users/ and
1324 http://www.webdav.org/acl/groups/, both wrapped in DAV:href XML
1325 elements. Digest authentication provides credentials for the
1326 principal operating the client.
1328 The client might reasonably follow this request with two separate
1329 PROPFIND requests to retrieve the DAV:displayname property of the
1330 members of the two collections (/acl/users and /acl/groups). This
1331 information could be used when displaying a user interface for
1332 creating access control entries.
1334 >> Request <<
1336 PROPFIND /papers/ HTTP/1.1
1337 Host: www.webdav.org
1338 Content-type: text/xml; charset="utf-8"
1339 Content-Length: xxx
1340 Depth: 0
1341 Authorization: Digest username="yarong",
1342 realm="yarong@webdav.org", nonce="...",
1343 uri="/papers/", response="...", opaque="..."
1345
1346
1347
1348
1349
1350
1351 >> Response <<
1353 HTTP/1.1 207 Multi-Status
1354 Content-Type: text/xml; charset="utf-8"
1355 Content-Length: xxx
1357
1358
1359
1360 http://www.webdav.org/papers/
1361
1362
1363
1364 http://www.webdav.org/acl/users/
1365 http://www.webdav.org/acl/groups/
1366
1367
1368 HTTP/1.1 200 OK
1369
1370
1371
1373 5.8 Example: PROPFIND to retrieve access control properties
1375 The following example shows how access control information can be
1376 retrieved by using the PROPFIND method to fetch the values of the
1377 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
1378 set, and DAV:acl properties.
1380 >> Request <<
1382 PROPFIND /top/container/ HTTP/1.1
1383 Host: www.foo.org
1384 Content-type: text/xml; charset="utf-8"
1385 Content-Length: xxx
1386 Depth: 0
1387 Authorization: Digest username="ejw",
1388 realm="users@foo.org", nonce="...",
1389 uri="/top/container/", response="...", opaque="..."
1391
1392
1393
1394
1395
1396
1397
1398
1399
1401 >> Response <<
1403 HTTP/1.1 207 Multi-Status
1404 Content-Type: text/xml; charset="utf-8"
1405 Content-Length: xxx
1407
1408
1411 http://www.foo.org/top/container/
1412
1413
1414
1415 http://www.foo.org/users/gclemm
1416
1417
1418
1419
1420 Any operation
1421
1422
1423 Read any
1424 object
1425
1426
1427
1428
1429 Write any
1430 object
1431
1432
1433 Create an
1434 object
1435
1436
1437
1438 Update an
1439 object
1440
1441
1442
1443 Delete an
1444 object
1445
1446
1447
1448
1449 Read the ACL
1450
1451
1452
1453 Write the
1454 ACL
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465 http://www.foo.org/users/esedlar
1466
1467
1468
1469
1470
1471
1472
1473
1474 http://www.foo.org/groups/marketing
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491 http://www.foo.org/top
1492
1493
1494 HTTP/1.1 200 OK
1495
1497 The value of the DAV:owner property is a single DAV:href XML
1498 element containing the URL of the principal that owns this
1499 resource.
1501 The value of the DAV:supported-privilege-set property is a tree of
1502 supported privileges (using "[XML Namespace , localname]" to
1503 identify each privilege):
1505 [DAV:, all] (aggregate, abstract)
1506 |
1507 +-- [DAV:, read]
1508 +-- [DAV:, write] (aggregate, abstract)
1509 |
1510 +-- [http://www.webdav.org/acl, create]
1511 +-- [http://www.webdav.org/acl, update]
1512 +-- [http://www.webdav.org/acl, delete]
1513 +-- [DAV:, read-acl]
1514 +-- [DAV:, write-acl]
1516 The DAV:current-user-privilege-set property contains two
1517 privileges, DAV:read, and DAV:read-acl. This indicates that the
1518 current authenticated user only has the ability to read the
1519 resource, and read the DAV:acl property on the resource.
1521 The DAV:acl property contains a set of four ACEs:
1523 ACE #1: The principal identified by the URL
1524 http://www.foo.org/users/esedlar is granted the DAV:read,
1525 DAV:write, and DAV:read-acl privileges.
1527 ACE #2: The principals identified by the URL
1528 http://www.foo.org/groups/marketing are denied the DAV:read
1529 privilege. In this example, the principal URL identifies a group.
1531 ACE #3: In this ACE, the principal is a property principal,
1532 specifically the DAV:owner property. When evaluating this ACE, the
1533 value of the DAV:owner property is retrieved, and is examined to
1534 see if it contains a DAV:href XML element. If so, the URL within
1535 the DAV:href element is read, and identifies a principal. In this
1536 ACE, the owner is granted DAV:read-acl, and DAV:write-acl
1537 privileges.
1539 ACE #4: This ACE grants the DAV:all principal (all users) the
1540 DAV:read privilege. This ACE is inherited from the resource
1541 http://www.foo.org/top, the parent collection of this resource.
1543 6 ACL SEMANTICS
1545 The ACL semantics define how multiple ACEs that match the current
1546 user are combined, what are the constraints on how ACEs can be
1547 ordered, and which principals must have an ACE.
1549
1552 6.1 ACE Combination
1554 The DAV:ace-combination element defines how privileges from
1555 multiple ACEs that match the current user will be combined to
1556 determine the access privileges for that user. Multiple ACEs may
1557 match the same user because the same principal can appear in
1558 multiple ACEs, because multiple principals can identify the same
1559 user, and because one principal can be a member of another
1560 principal.
1562
1566 6.1.1 DAV:first-match ACE Combination
1568 The ACEs are evaluated in the order in which they appear in the
1569 ACL. If the first ACE that matches the current user does not grant
1570 all the privileges needed for the request, the request MUST fail.
1572
1574 6.1.2 DAV:all-grant-before-any-deny ACE Combination
1576 The ACEs are evaluated in the order in which they appear in the
1577 ACL. If an evaluated ACE denies a privilege needed for the
1578 request, the request MUST fail. If all ACEs have been evaluated
1579 without the user being granted all privileges needed for the
1580 request, the request MUST fail.
1582
1583 6.1.3 DAV:specific-deny-overrides-grant ACE Combination
1585 All ACEs in the ACL are evaluated. An "individual ACE" is one
1586 whose principal matches the current user. A "group ACE" is one
1587 whose principal is a group that has a member that matches the
1588 current user. A privilege is granted if it is granted by an
1589 individual ACE and not denied by an individual ACE, or if it is
1590 granted by a group ACE and not denied by an individual or group
1591 ACE. A request MUST fail if any of its needed privileges are not
1592 granted.
1594
1596 6.2 ACE Ordering
1598 The DAV:ace-ordering element defines a constraint on how the ACEs
1599 can be ordered in the ACL.
1601
1603 6.2.1 DAV:deny-before-grant ACE Ordering
1605 This element indicates that all deny ACEs must precede all grant
1606 ACEs.
1608
1610 6.3 Allowed ACE
1612 The DAV:allowed-ace XML element specifies constraints on what kinds
1613 of ACEs are allowed in an ACL.
1615
1618 6.3.1 DAV:principal-only-one-ace ACE Constraint
1620 This element indicates that a principal can appear in only one ACE
1621 per resource.
1623
1625 6.3.2 DAV:grant-only ACE Constraint
1627 This element indicates that ACEs with deny clauses are not allowed.
1629
1630 6.3.3 DAV:no-invert ACE Constraint
1632 This element indicates that ACEs with the element are not
1633 allowed.
1635
1637 6.4 Required Principals
1639 The required principal elements identify which principals must have
1640 an ACE defined in the ACL.
1642
1646 For example, the following element requires that the ACL contain a
1647 DAV:owner property ACE:
1649
1650
1651
1653 7 ACCESS CONTROL AND EXISTING METHODS
1655 This section defines the impact of access control functionality on
1656 existing methods.
1658 7.1 OPTIONS
1660 If the server supports access control, it MUST return "access-
1661 control" as a field in the DAV response header from an OPTIONS
1662 request on any resource implemented by that server. A value of
1663 "access-control" in the DAV header MUST indicate that the server
1664 supports all MUST level requirements and REQUIRED features
1665 specified in this document.
1667 7.1.1 Example - OPTIONS
1669 >> Request <<
1671 OPTIONS /foo.html HTTP/1.1
1672 Host: www.webdav.org
1673 Content-Length: 0
1675 >> Response <<
1677 HTTP/1.1 200 OK
1678 DAV: 1, 2, access-control
1679 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
1680 In this example, the OPTIONS response indicates that the server
1681 supports access control and that /foo.html can have its access
1682 control list modified by the ACL method.
1684 7.2 MOVE
1686 When a resource is moved from one location to another due to a MOVE
1687 request, the non-inherited and non-protected ACEs in the DAV:acl
1688 property of the resource MUST NOT be modified, or the MOVE request
1689 fails. Handling of inherited and protected ACEs is intentionally
1690 undefined to give server implementations flexibility in how they
1691 implement ACE inheritance and protection.
1693 7.3 COPY
1695 The DAV:acl property on the resource at the destination of a COPY
1696 MUST be the same as if the resource was created by an individual
1697 resource creation request (e.g. MKCOL, PUT). Clients wishing to
1698 preserve the DAV:acl property across a copy need to read the
1699 DAV:acl property prior to the COPY, then perform an ACL operation
1700 on the new resource at the destination to restore, insofar as this
1701 is possible, the original access control list.
1703 7.4 DELETE
1705 The precise combination of privileges and resources necessary to
1706 permit the DELETE method is intentionally left to the discretion of
1707 each server implementation. It is envisioned that on some servers,
1708 DELETE will require write permission on the collection containing
1709 the resource to be deleted. On other servers, it might also
1710 require write permission on the resource being deleted.
1712 7.5 LOCK
1714 A lock on a resource ensures that only the lock owner can modify
1715 ACEs that are not inherited and not protected (these are the only
1716 ACEs that a client can modify with an ACL request). A lock does not
1717 protect inherited or protected ACEs, since a client cannot modify
1718 them with an ACL request on that resource.
1720 8 ACCESS CONTROL METHODS
1722 8.1 ACL
1724 The ACL method modifies the access control list (which can be read
1725 via the DAV:acl property) of a resource. Specifically, the ACL
1726 method only permits modification to ACEs that are not inherited,
1727 and are not protected. An ACL method invocation modifies all non-
1728 inherited and non-protected ACEs in a resource's access control
1729 list to exactly match the ACEs contained within in the DAV:acl XML
1730 element (specified in Section 5.4) of the request body. An ACL
1731 request body MUST contain only one DAV:acl XML element. Unless the
1732 non-inherited and non-protected ACEs of the DAV:acl property of the
1733 resource can be updated to be exactly the value specified in the
1734 ACL request, the ACL request MUST fail.
1736 It is possible that the ACEs visible to the current user in the
1737 DAV:acl property may only be a portion of the complete set of ACEs
1738 on that resource. If this is the case, an ACL request only modifies
1739 the set of ACEs visible to the current user, and does not affect
1740 any non-visible ACE.
1742 In order to avoid overwriting DAV:acl changes by another client, a
1743 client SHOULD acquire a WebDAV lock on the resource before
1744 retrieving the DAV:acl property of a resource that it intends on
1745 updating.
1747 Implementation Note: Two common operations are to add or remove
1748 an ACE from an existing access control list. To accomplish this,
1749 a client uses the PROPFIND method to retrieve the value of the
1750 DAV:acl property, then parses the returned access control list
1751 to remove all inherited and protected ACEs (these ACEs are
1752 tagged with the DAV:inherited and DAV:protected XML elements).
1753 In the remaining set of non-inherited, non-protected ACEs, the
1754 client can add or remove one or more ACEs before submitting the
1755 final ACE set in the request body of the ACL method.
1757 8.1.1 ACL Preconditions
1759 An implementation MAY enforce one or more of the following
1760 constraints on an ACL request. If the constraint is violated, a
1761 403 (Forbidden) or 409 (Conflict) response MUST be returned and the
1762 indicated XML element MUST be returned as a child of a top level
1763 DAV:error element in an XML response body.
1765 (DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST
1766 NOT conflict with each other. What is considered a conflict
1767 depends on the ACL semantics of that resource.
1769 (DAV:no-protected-ace-conflict): The ACEs submitted in the ACL
1770 request MUST NOT conflict with the protected ACEs on the resource.
1771 For example, if the resource has a protected ACE granting DAV:write
1772 to a given principal, then it would not be consistent if the ACL
1773 request submitted an ACE denying DAV:write to the same principal.
1775 (DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL
1776 request MUST NOT conflict with the inherited ACEs on the resource.
1777 For example, if the resource inherits an ACE from its parent
1778 collection granting DAV:write to a given principal, then it would
1779 not be consistent if the ACL request submitted an ACE denying
1780 DAV:write to the same principal. Note that reporting of this error
1781 will be implementation-dependent. Implementations have the choice
1782 to either report this error, or to allow the ACE to be set, and
1783 then let normal ACE evaluation rules determine whether the new ACE
1784 has any impact on the privileges available to a specific principal.
1786 (DAV:limited-number-of-aces): The number of ACEs submitted in the
1787 ACL request MUST NOT exceed the number of ACEs allowed on that
1788 resource. However, ACL-compliant servers MUST support at least one
1789 ACE granting privileges to a single principal, and one ACE granting
1790 privileges to a group.
1792 (DAV:deny-before-grant): All non-inherited deny ACEs MUST precede
1793 all non-inherited grant ACEs.
1795 (DAV:principal-only-one-ace): The ACL request MUST NOT result in
1796 more than one ACE for a given principal. This precondition applies
1797 only when the ACL semantics of the resource includes the
1798 DAV:principal-only-one-ace constraint (defined in Section 6.3.1).
1800 (DAV:grant-only): The ACEs submitted in the ACL request MUST NOT
1801 include a deny ACE. This precondition applies only when the ACL
1802 semantics of the resource includes the DAV:grant-only constraint
1803 (defined in Section 6.3.2).
1805 (DAV:no-invert): The ACL request MUST NOT include a DAV:invert
1806 element. This precondition applies only when the ACL semantics of
1807 the resource includes the DAV:no-invert constraint (defined in
1808 Section 6.3.4).
1810 (DAV:no-abstract): The ACL request MUST NOT attempt to grant or
1811 deny an abstract privilege (see Section 5.2).
1813 (DAV:not-supported-privilege): The ACEs submitted in the ACL
1814 request MUST be supported by the resource.
1816 (DAV:missing-required-principal): The result of the ACL request
1817 MUST have at least one ACE for each principal identified in a
1818 DAV:required-principal XML element in the ACL semantics of that
1819 resource (see Section 6.3.2).
1821 (DAV:recognized-principal): Every principal URL in the ACL request
1822 MUST identify a principal resource.
1824 (DAV:allowed-principal): The principals specified in the ACEs
1825 submitted in the ACL request MUST be allowed as principals for the
1826 resource. For example, a server where only authenticated principals
1827 can access resources would not allow the DAV:all or
1828 DAV:unauthenticated principals to be used in an ACE, since these
1829 would allow unauthenticated access to resources.
1831 8.1.2 Example: the ACL method
1833 In the following example, user "fielding", authenticated by
1834 information in the Authorization header, grants the principal
1835 identified by the URL http://www.foo.org/users/esedlar (i.e., the
1836 user "esedlar") read and write privileges, grants the owner of the
1837 resource read-acl and write-acl privileges, and grants everyone
1838 read privileges.
1840 >> Request <<
1842 ACL /top/container/ HTTP/1.1
1843 Host: www.foo.org
1844 Content-Type: text/xml; charset="utf-8"
1845 Content-Length: xxxx
1846 Authorization: Digest username="fielding",
1847 realm="users@foo.org", nonce="...",
1848 uri="/top/container/", response="...", opaque="..."
1850
1851
1852
1853
1854 http://www.foo.org/users/esedlar
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1877 >> Response <<
1879 HTTP/1.1 200 OK
1881 8.1.3 Example: ACL method failure due to protected ACE conflict
1883 In the following request, user "fielding", authenticated by
1884 information in the Authorization header, attempts to deny the
1885 principal identified by the URL http://www.foo.org/users/esedlar
1886 (i.e., the user "esedlar") write privileges. Prior to the request,
1887 the DAV:acl property on the resource contained a protected ACE (see
1888 Section 5.4.3) granting DAV:owner the DAV:read and DAV:write
1889 privileges. The principal identified by URL
1890 http://www.foo.org/users/esedlar is the owner of the resource. The
1891 ACL method invocation fails because the submitted ACE conflicts
1892 with the protected ACE, thus violating the semantics of ACE
1893 protection.
1895 >> Request <<
1897 ACL /top/container/ HTTP/1.1
1898 Host: www.foo.org
1899 Content-Type: text/xml; charset="utf-8"
1900 Content-Length: xxxx
1901 Authorization: Digest username="fielding",
1902 realm="users@foo.org", nonce="...",
1903 uri="/top/container/", response="...", opaque="..."
1905
1906
1907
1908
1909 http://www.foo.org/users/esedlar
1910
1911
1912
1913
1914
1915
1917 >> Response <<
1919 HTTP/1.1 403 Forbidden
1920 Content-Type: text/xml; charset="utf-8"
1921 Content-Length: xxx
1923
1924
1925
1926
1928 8.1.4 Example: ACL method failure due to an inherited ACE conflict
1930 In the following request, user "ejw", authenticated by information
1931 in the Authorization header, tries to change the access control
1932 list on the resource http://www.foo.org/top/index.html. This
1933 resource has two inherited ACEs.
1935 Inherited ACE #1 grants the principal identified by URL
1936 http://www.foo.org/users/ejw (i.e., the user "ejw")
1937 http://www.foo.org/privs/write-all and DAV:read-acl privileges. On
1938 this server, http://www.foo.org/privs/write-all is an aggregate
1939 privilege containing DAV:write, and DAV:write-acl.
1941 Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
1943 The request attempts to set a (non-inherited) ACE, denying the
1944 principal identified by the URL http://www.foo.org/users/ejw (i.e.,
1945 the user "ejw") DAV:write permission. This conflicts with inherited
1946 ACE #1. Note that the decision to report an inherited ACE conflict
1947 is specific to this server implementation. Another server
1948 implementation could have allowed the new ACE to be set, and then
1949 used normal ACE evaluation rules to determine whether the new ACE
1950 has any impact on the privileges available to a principal.
1952 >> Request <<
1954 ACL /top/index.html HTTP/1.1
1955 Host: www.foo.org
1956 Content-Type: text/xml; charset="utf-8"
1957 Content-Length: xxxx
1958 Authorization: Digest username="ejw",
1959 realm="users@foo.org", nonce="...",
1960 uri="/top/index.html", response="...", opaque="..."
1962
1963
1964
1965
1966 http://www.foo.org/users/ejw
1967
1968
1969
1970
1972 >> Response <<
1974 HTTP/1.1 403 Forbidden
1975 Content-Type: text/xml; charset="utf-8"
1976 Content-Length: xxx
1978
1979
1980
1981
1983 8.1.5 Example: ACL method failure due to an attempt to set grant and
1984 deny in a single ACE.
1986 In this example, user "ygoland", authenticated by information in
1987 the Authorization header, tries to change the access control list
1988 on the resource http://www.foo.org/diamond/engagement-ring.gif. The
1989 ACL request includes a single, syntactically and semantically
1990 incorrect ACE, which attempts to grant the group identified by the
1991 URL http://www.foo.org/users/friends DAV:read privilege and deny
1992 the principal identified by URL http://www.foo.org/users/ygoland-so
1993 (i.e., the user "ygoland-so") DAV:read privilege. However, it is
1994 illegal to have multiple principal elements, as well as both a
1995 grant and deny element in the same ACE, so the request fails due to
1996 poor syntax.
1998 >> Request <<
2000 ACL /diamond/engagement-ring.gif HTTP/1.1
2001 Host: www.foo.org
2002 Content-Type: text/xml; charset="utf-8"
2003 Content-Length: xxxx
2004 Authorization: Digest username="ygoland",
2005 realm="users@foo.org", nonce="...",
2006 uri="/diamond/engagement-ring.gif", response="...", opaque="..."
2008
2009
2010
2011
2012 http://www.foo.org/users/friends
2013
2014
2015
2016 http://www.foo.org/users/ygoland-so
2017
2018
2019
2020
2022 >> Response <<
2024 HTTP/1.1 400 Bad Request
2025 Content-Length: 0
2027 Note that if the request had been divided into two ACEs, one to
2028 grant, and one to deny, the request would have been syntactically
2029 well formed.
2031 9 ACCESS CONTROL REPORTS
2033 9.1 REPORT Method
2035 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
2036 extensible mechanism for obtaining information about a resource.
2037 Unlike the PROPFIND method, which returns the value of one or more
2038 named properties, the REPORT method can involve more complex
2039 processing. REPORT is valuable in cases where the server has access
2040 to all of the information needed to perform the complex request
2041 (such as a query), and where it would require multiple requests for
2042 the client to retrieve the information needed to perform the same
2043 request.
2045 A server that supports the WebDAV Access Control Protocol MUST
2046 support the DAV:expand-property report (defined in Section 3.8 of
2047 [RFC3253]).
2049 9.2 DAV:acl-principal-prop-set Report
2051 The DAV:acl-principal-prop-set report returns, for all principals
2052 in the DAV:acl property (of the Request-URI) that are identified by
2053 http(s) URLs or by a DAV:property principal, the value of the
2054 properties specified in the REPORT request body. In the case where
2055 a principal URL appears multiple times, the DAV:acl-principal-prop-
2056 set report MUST return the properties for that principal only once.
2057 Support for this report is REQUIRED.
2059 One expected use of this report is to retrieve the human readable
2060 name (found in the DAV:displayname property) of each principal
2061 found in an ACL. This is useful for constructing user interfaces
2062 that show each ACE in a human readable form.
2064 Marshalling
2065 The request body MUST be a DAV:acl-principal-prop-set XML element.
2067
2068 ANY value: a sequence of one or more elements, with at most one
2069 DAV:prop element.
2070 prop: see RFC 2518, Section 12.11
2072 This report is only defined when the Depth header has value "0";
2073 other values result in a 400 (Bad Request) error response. Note
2074 that [RFC3253], Section 3.6, states that if the Depth header is not
2075 present, it defaults to a value of "0".
2077 The response body for a successful request MUST be a
2078 DAV:multistatus XML element (i.e., the response uses the same
2079 format as the response for PROPFIND).
2081 multistatus: see RFC 2518, Section 12.9
2083 The response body for a successful DAV:acl-principal-prop-set
2084 REPORT request MUST contain a DAV:response element for each
2085 principal identified by an http(s) URL listed in a DAV:principal
2086 XML element of an ACE within the DAV:acl property of the resource
2087 identified by the Request-URI.
2089 9.2.1 Example: DAV:acl-principal-prop-set Report
2091 Resource http://www.webdav.org/index.html has an ACL with three
2092 ACEs:
2094 ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
2095 current-user-privilege-set access.
2097 ACE #2: The principal identified by
2098 http://www.webdav.org/people/gstein (the user "gstein") is granted
2099 DAV:write, DAV:write-acl, DAV:read-acl privileges.
2101 ACE #3: The group identified by
2102 http://www.webdav.org/groups/authors (the "authors" group) is
2103 granted DAV:write and DAV:read-acl privileges.
2105 The following example shows a DAV:acl-principal-prop-set report
2106 requesting the DAV:displayname property. It returns the value of
2107 DAV:displayname for resources http://www.webdav.org/people/gstein
2108 and http://www.webdav.org/groups/authors , but not for DAV:all,
2109 since this is not an http(s) URL.
2111 >> Request <<
2113 REPORT /index.html HTTP/1.1
2114 Host: www.webdav.org
2115 Content-Type: text/xml; charset="utf-8"
2116 Content-Length: xxxx
2117 Depth: 0
2119
2120
2121
2122
2123
2124
2126 >> Response <<
2128 HTTP/1.1 207 Multi-Status
2129 Content-Type: text/xml; charset="utf-8"
2130 Content-Length: xxxx
2132
2133
2134
2135 http://www.webdav.org/people/gstein
2136
2137
2138 Greg Stein
2139
2140 HTTP/1.1 200 OK
2141
2142
2143
2144 http://www.webdav.org/groups/authors
2145
2146
2147 Site authors
2148
2149 HTTP/1.1 200 OK
2150
2151
2152
2154 9.3 DAV:principal-match REPORT
2156 The DAV:principal-match REPORT is used to identify all members (at
2157 any depth) of the collection identified by the Request-URI that
2158 match the current user. In particular, if the collection contains
2159 principals, the report can be used to identify all members of the
2160 collection that match the current user. Alternatively, if the
2161 collection contains resources that have a property that identifies
2162 a principal (e.g. DAV:owner), the report can be used to identify
2163 all members of the collection whose property identifies a principal
2164 that matches the current user. For example, this report can return
2165 all of the resources in a collection hierarchy that are owned by
2166 the current user. Support for this report is REQUIRED.
2168 Marshalling:
2169 The request body MUST be a DAV:principal-match XML element.
2171
2172
2173 ANY value: an element whose value identifies a property. The
2174 expectation is the value of the named property typically contains
2175 an href element that contains the URI of a principal
2176
2177 prop: see RFC 2518, Section 12.11
2179 This report is only defined when the Depth header has value "0";
2180 other values result in a 400 (Bad Request) error response. Note
2181 that [RFC3253], Section 3.6, states that if the Depth header is not
2182 present, it defaults to a value of "0".
2184 The response body for a successful request MUST be a
2185 DAV:multistatus XML element.
2187 multistatus: see RFC 2518, Section 12.9
2189 The response body for a successful DAV:principal-match REPORT
2190 request MUST contain a DAV:response element for each member of the
2191 collection that matches the current user. When the DAV:principal-
2192 property element is used, a match occurs if the current user is
2193 matched by the principal identified by the URI found in the
2194 DAV:href element of the property identified by the DAV:principal-
2195 property element. When the DAV:self element is used in a
2196 DAV:principal-match report issued against a group, it matches a
2197 member of the group if that child (a principal resource) identifies
2198 the same principal as the current user.
2200 If DAV:prop is specified in the request body, the properties
2201 specified in the DAV:prop element MUST be reported in the
2202 DAV:response elements.
2204 9.3.1 Example: DAV:principal-match REPORT
2206 The following example identifies the members of the collection
2207 identified by the URL http://www.webdav.org/doc that are owned by
2208 the current user. The current user ("gclemm") is authenticated
2209 using Digest authentication.
2211 >> Request <<
2213 REPORT /doc/ HTTP/1.1
2214 Host: www.webdav.org
2215 Authorization: Digest username="gclemm",
2216 realm="gclemm@webdav.org", nonce="...",
2217 uri="/papers/", response="...", opaque="..."
2218 Content-Type: text/xml; charset="utf-8"
2219 Content-Length: xxxx
2220 Depth: 0
2222
2223
2224
2225
2226
2227
2229 >> Response <<
2231 HTTP/1.1 207 Multi-Status
2232 Content-Type: text/xml; charset="utf-8"
2233 Content-Length: xxxx
2235
2236
2237
2238 http://www.webdav.org/doc/foo.html
2239 HTTP/1.1 200 OK
2240
2241
2242 http://www.webdav.org/doc/img/bar.gif
2243 HTTP/1.1 200 OK
2244
2245
2247 9.4 DAV:principal-property-search REPORT
2249 The DAV:principal-property-search REPORT performs a search for all
2250 principals whose properties contain character data that matches the
2251 search criteria specified in the request. One expected use of this
2252 report is to discover the URL of a principal associated with a
2253 given person or group by searching for them by name. This is done
2254 by searching over DAV:displayname, which is defined on all
2255 principals.
2257 The actual search method (exact matching vs. substring matching vs,
2258 prefix-matching, case-sensitivity) deliberately is left to the
2259 server implementation to allow implementation on a wide set of
2260 possible user management systems. In cases where the implementation
2261 of DAV:principal-property-search is not constrained by the
2262 semantics of an underlying user management repository, preferred
2263 default semantics are caseless substring matches.
2265 For implementation efficiency, servers do not typically support
2266 searching on all properties. A client can discover the set of
2267 searchable properties by using the DAV:principal-search-property-
2268 set REPORT, defined in Section 9.5.
2270 Support for the DAV:principal-property-search report is REQUIRED.
2272 Implementation Note: The value of a WebDAV property is a
2273 sequence of well-formed XML, and hence can include any character
2274 in the Unicode/ISO-10646 standard, that is, most known
2275 characters in human languages. Due to the idiosyncrasies of case
2276 mapping across human languages, implementation of case-
2277 insensitive matching is non-trivial. Implementors of servers
2278 that do perform substring matching are strongly encouraged to
2279 consult [CaseMap], especially Section 2.3 ("Caseless Matching"),
2280 for guidance when implementing their case-insensitive matching
2281 algorithms.
2283 Implementation Note: Some implementations of this protocol will
2284 use an LDAP repository for storage of principal metadata. The
2285 schema describing each attribute (akin to a WebDAV property) in
2286 an LDAP repository specifies whether it supports case-sensitive
2287 or caseless searching. One of the benefits of leaving the search
2288 method to the discretion of the server implementation is the
2289 default LDAP attribute search behavior can be used when
2290 implementing the DAV:principal-property-search report.
2292 Marshalling:
2293 The request body MUST be a DAV:principal-property-search XML
2294 element containing a search specification and an optional list of
2295 properties. For every principal that matches the search
2296 specification, the response will contain the value of the requested
2297 properties on that principal.
2299
2301 By default, the report searches all members (at any depth) of the
2302 collection identified by the Request-URI. If DAV:apply-to-
2303 principal-collection-set is specified in the request body, the
2304 request is applied instead to each collection identified by the
2305 DAV:prinicipal-collection-set property of the resource identified
2306 by the Request-URI.
2308 The DAV:property-search element contains a prop element enumerating
2309 the properties to be searched and a match element, containing the
2310 search string.
2312
2313 prop: see RFC 2518, Section 12.11
2315
2317 Multiple property-search elements or multiple elements within a
2318 DAV:prop element will be interpreted with a logical AND.
2320 This report is only defined when the Depth header has value "0";
2321 other values result in a 400 (Bad Request) error response. Note
2322 that [RFC3253], Section 3.6, states that if the Depth header is not
2323 present, it defaults to a value of "0".
2325 The response body for a successful request MUST be a
2326 DAV:multistatus XML element.
2328 multistatus: see RFC 2518, Section 12.9
2330 The response body for a successful DAV:principal-property-search
2331 REPORT request MUST contain a DAV:response element for each
2332 principal whose property values satisfy the search specification
2333 given in DAV:principal-property-search.
2335 The response body for an unsuccessful DAV:principal-property-search
2336 REPORT request MUST contain, after the XML element indicating the
2337 failed precondition or postcondition, a DAV:prop element containing
2338 the property that caused the pre/postcondition to fail.
2340 If DAV:prop is specified in the request body, the properties
2341 specified in the DAV:prop element MUST be reported in the
2342 DAV:response elements.
2344 Preconditions:
2345 (DAV:property-must-be-searchable): All properties specified in the
2346 DAV:principal-property-search REPORT must be searchable.
2348 9.4.1 Matching
2350 There are several cases to consider when matching strings. The
2351 easiest case is when a property value is "simple" and has only
2352 character information item content (see [REC-XML-INFOSET]). For
2353 example, the search string "julian" would match the DAV:displayname
2354 property with value "Julian Reschke". Note that the on-the-wire
2355 marshalling of DAV:displayname in this case is:
2357 Julian Reschke
2359 The name of the property is encoded into the XML element
2360 information item, and the character information item content of the
2361 property is "Julian Reschke".
2363 A more complicated case occurs when properties have mixed content
2364 (that is, compound values consisting of multiple child element
2365 items, other types of information items, and character information
2366 item content). Consider the property "aprop" in the namespace
2367 "http://www.webdav.org/props/", marshalled as:
2369
2370 {cdata 0}{cdata 1}
2371 {cdata 2}{cdata 3}
2372
2374 In this case, matching is performed on each individual contiguous
2375 sequence of character information items. In the example above, a
2376 search string would be compared to the four following strings:
2378 {cdata 0}
2379 {cdata 1}
2380 {cdata 2}
2381 {cdata 3}
2383 That is, four individual matches would be performed, one each for
2384 {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
2386 9.4.2 Example: successful DAV:principal-property-search REPORT
2388 In this example, the client requests the principal URLs of all
2389 users whose DAV:displayname property contains the substring "doE"
2390 and whose "title" property in the namespace
2391 "http://BigCorp.com/ns/" (that is, their professional title)
2392 contains "Sales". In addition, the client requests five properties
2393 to be returned with the matching principals:
2395 In the DAV: namespace: displayname
2396 In the http://www.BigCorp.com/ns/ namespace: department, phone,
2397 office, salary
2399 The response shows that two principal resources meet the search
2400 specification, "John Doe" and "Zygdoebert Smith". The property
2401 "salary" in namespace "http://www.BigCorp.com/ns/" is not returned,
2402 since the principal making the request does not have sufficient
2403 access permissions to read this property.
2405 >> Request <<
2407 REPORT /users/ HTTP/1.1
2408 Host: www.BigCorp.com
2409 Content-Type: text/xml; charset=utf-8
2410 Content-Length: xxxx
2411 Depth: 0
2413
2414
2415
2416
2417
2418
2419 doE
2420
2421
2422
2423
2424
2425 Sales
2426
2427
2428
2429
2430
2431
2432
2433
2434
2436 >> Response <<
2438 HTTP/1.1 207 Multi-Status
2439 Content-Type: text/xml; charset=utf-8
2440 Content-Length: xxxx
2441
2442
2443
2444 http://www.BigCorp.com/users/jdoe
2445
2446
2447 John Doe
2448 Widget Sales
2449 234-4567
2450 209
2451
2452 HTTP/1.1 200 OK
2453
2454
2455
2456
2457
2458 HTTP/1.1 403 Forbidden
2459
2460
2461
2462 http://www.BigCorp.com/users/zsmith
2463
2464
2465 Zygdoebert Smith
2466 Gadget Sales
2467 234-7654
2468 114
2469
2470 HTTP/1.1 200 OK
2471
2472
2473
2474
2475
2476 HTTP/1.1 403 Forbidden
2477
2478
2479
2481 9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT
2483 In this example, the client requests a search on the non-searchable
2484 property "phone" in the namespace "http://www.BigCorp.com/ns/".
2485 The response is a 403 (Forbidden), with a response body containing
2486 a DAV:property-must-be-searchable XML element as the value of a
2487 DAV:error XML element.
2489 >> Request <<
2491 REPORT /users/ HTTP/1.1
2492 Host: www.BigCorp.com
2493 Content-Type: text/xml; charset=utf-8
2494 Content-Length: xxxx
2495 Depth: 0
2497
2498
2499
2500
2501
2502
2503 232
2504
2505
2507 >> Response <<
2509 HTTP/1.1 403 Forbidden
2510 Content-Type: text/xml; charset=utf-8
2511 Content-Length: xxxx
2513
2514
2515
2516
2517
2518
2519
2520
2522 9.5 DAV:principal-search-property-set REPORT
2524 The DAV:principal-search-property-set REPORT identifies those
2525 properties that may be searched using the DAV:principal-property-
2526 search REPORT (defined in Section 9.4).
2528 Servers MUST support the DAV:principal-search-property-set REPORT
2529 on all collections identified in the value of a DAV:principal-
2530 collection-set property.
2532 An access control protocol user agent could use the results of the
2533 DAV:principal-search-property-set REPORT to present a query
2534 interface to the user for retrieving principals.
2536 Support for this report is REQUIRED.
2538 Implementation Note: Some clients will have only limited screen
2539 real estate for the display of lists of searchable properties.
2540 In this case, a user might appreciate having the most frequently
2541 searched properties be displayed on-screen, rather than having
2542 to scroll through a long list of searchable properties. One
2543 mechanism for signaling the most frequently searched properties
2544 is to return them towards the start of a list of properties. A
2545 client can then preferentially display the list of properties in
2546 order, increasing the likelihood that the most frequently
2547 searched properties will appear on-screen, and will not require
2548 scrolling for their selection.
2550 Marshalling:
2551 The request body MUST be an empty DAV:principal-search-property-set
2552 XML element.
2554 This report is only defined when the Depth header has value "0";
2555 other values result in a 400 (Bad Request) error response. Note
2556 that [RFC3253], Section 3.6, states that if the Depth header is not
2557 present, it defaults to a value of "0".
2559 The response body MUST be a DAV:principal-search-property-set XML
2560 element, containing a DAV:principal-search-property XML element for
2561 each property that may be searched with the DAV:principal-property-
2562 search REPORT. A server MAY limit its response to just a subset of
2563 the searchable properties, such as those likely to be useful to an
2564 interactive access control client.
2566
2569 Each DAV:principal-search-property XML element contains exactly one
2570 searchable property, and a description of the property.
2572
2574 The DAV:prop element contains one principal property on which the
2575 server is able to perform a DAV:principal-property-search REPORT.
2577 prop: see RFC 2518, Section 12.11
2578 The description element is a human-readable description of what
2579 information this property represents. Servers MUST indicate the
2580 human language of the description using the xml:lang attribute and
2581 SHOULD consider the HTTP Accept-Language request header when
2582 selecting one of multiple available languages.
2584
2586 9.5.1 Example: DAV:principal-search-property-set REPORT
2588 In this example, the client determines the set of searchable
2589 principal properties by requesting the DAV:principal-search-
2590 property-set REPORT on the root of the server's principal URL
2591 collection set, identified by http://www.BigCorp.com/users/.
2593 >> Request <<
2595 REPORT /users/ HTTP/1.1
2596 Host: www.BigCorp.com
2597 Content-Type: text/xml; charset="utf-8"
2598 Content-Length: xxx
2599 Accept-Language: en, de
2600 Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=
2601 Depth: 0
2603
2604
2606 >> Response <<
2608 HTTP/1.1 200 OK
2609 Content-Type: text/xml; charset="utf-8"
2610 Content-Length: xxx
2612
2613
2614
2615
2616
2617
2618 Full name
2619
2620
2621
2622
2623
2624 Job title
2625
2626
2628 10 XML PROCESSING
2630 Implementations of this specification MUST support the XML element
2631 ignore rule, as specified in Section 23.3.2 of [RFC2518], and the
2632 XML Namespacerecommendation [REC-XML-NAMES].
2634 Note that use of the DAV namespace is reserved for XML elements and
2635 property names defined in a standards-track or Experimental IETF
2636 RFC.
2638 11 INTERNATIONALIZATION CONSIDERATIONS
2640 In this specification, the only human-readable content can be found
2641 in the description XML element, found within the DAV:supported-
2642 privilege-set property. This element contains a human-readable
2643 description of the capabilities controlled by a privilege. As a
2644 result, the description element must be capable of representing
2645 descriptions in multiple character sets. Since the description
2646 element is found within a WebDAV property, it is represented on-
2647 the-wire as XML [REC-XML], and hence can leverage XML's language
2648 tagging and character set encoding capabilities. Specifically, XML
2649 processors must, at minimum, be able to read XML elements encoded
2650 using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual
2651 plane. XML examples in this specification demonstrate use of the
2652 charset parameter of the Content-Type header, as defined in
2653 [RFC3023], as well as the XML "encoding" attribute, which together
2654 provide charset identification information for MIME and XML
2655 processors. Futhermore, this specification requires server
2656 implementations to tag description fields with the xml:lang
2657 attribute (see Section 2.12 of [REC-XML]), which specifies the
2658 human language of the description. Additionally, server
2659 implementations should take into account the value of the Accept-
2660 Language HTTP header to determine which description string to
2661 return.
2663 For XML elements other than the description element, it is expected
2664 that implementations will treat the property names, privilege
2665 names, and values as tokens, and convert these tokens into human-
2666 readable text in the user's language and character set when
2667 displayed to a person. Only a generic WebDAV property display
2668 utility would display these values in their raw form to a human
2669 user.
2671 For error reporting, we follow the convention of HTTP/1.1 status
2672 codes, including with each status code a short, English description
2673 of the code (e.g., 200 (OK)). While the possibility exists that a
2674 poorly crafted user agent would display this message to a user,
2675 internationalized applications will ignore this message, and
2676 display an appropriate message in the user's language and character
2677 set.
2679 Further internationalization considerations for this protocol are
2680 described in the WebDAV Distributed Authoring protocol
2681 specification [RFC2518].
2683 12 SECURITY CONSIDERATIONS
2685 Applications and users of this access control protocol should be
2686 aware of several security considerations, detailed below. In
2687 addition to the discussion in this document, the security
2688 considerations detailed in the HTTP/1.1 specification [RFC2616],
2689 the WebDAV Distributed Authoring Protocol specification [RFC2518],
2690 and the XML Media Types specification [RFC3023] should be
2691 considered in a security analysis of this protocol.
2693 12.1 Increased Risk of Compromised Users
2695 In the absence of a mechanism for remotely manipulating access
2696 control lists, if a single user's authentication credentials are
2697 compromised, only those resources for which the user has access
2698 permission can be read, modified, moved, or deleted. With the
2699 introduction of this access control protocol, if a single
2700 compromised user has the ability to change ACLs for a broad range
2701 of other users (e.g., a super-user), the number of resources that
2702 could be altered by a single compromised user increases. This risk
2703 can be mitigated by limiting the number of people who have write-
2704 acl privileges across a broad range of resources.
2706 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
2707 Privileges
2709 The ability to read the access privileges (stored in the DAV:acl
2710 property), or the privileges permitted the currently authenticated
2711 user (stored in the DAV:current-user-privilege-set property) on a
2712 resource may seem innocuous, since reading an ACL cannot possibly
2713 affect the resource's state. However, if all resources have world-
2714 readable ACLs, it is possible to perform an exhaustive search for
2715 those resources that have inadvertently left themselves in a
2716 vulnerable state, such as being world-writeable. In particular, the
2717 property retrieval method PROPFIND, executed with Depth infinity on
2718 an entire hierarchy, is a very efficient way to retrieve the
2719 DAV:acl or DAV:current-user-privilege-set properties. Once found,
2720 this vulnerability can be exploited by a denial of service attack
2721 in which the open resource is repeatedly overwritten. Alternately,
2722 writeable resources can be modified in undesirable ways.
2724 To reduce this risk, read-acl privileges should not be granted to
2725 unauthenticated principals, and restrictions on read-acl and read-
2726 current-user-privilege-set privileges for authenticated principals
2727 should be carefully analyzed when deploying this protocol. Access
2728 to the current-user-privilege-set property will involve a tradeoff
2729 of usability versus security. When the current-user-privilege-set
2730 is visible, user interfaces are expected to provide enhanced
2731 information concerning permitted and restricted operations, yet
2732 this information may also indicate a vulnerability that could be
2733 exploited. Deployment of this protocol will need to evaluate this
2734 tradeoff in light of the requirements of the deployment
2735 environment.
2737 12.3 No Foreknowledge of Initial ACL
2739 In an effort to reduce protocol complexity, this protocol
2740 specification intentionally does not address the issue of how to
2741 manage or discover the initial ACL that is placed upon a resource
2742 when it is created. The only way to discover the initial ACL is to
2743 create a new resource, then retrieve the value of the DAV:acl
2744 property. This assumes the principal creating the resource also has
2745 been granted the DAV:read-acl privilege.
2747 As a result, it is possible that a principal could create a
2748 resource, and then discover that its ACL grants privileges that are
2749 undesirable. Furthermore, this protocol makes it possible (though
2750 unlikely) that the creating principal could be unable to modify the
2751 ACL, or even delete the resource. Even when the ACL can be
2752 modified, there will be a short period of time when the resource
2753 exists with the initial ACL before its new ACL can be set.
2755 Several factors mitigate this risk. Human principals are often
2756 aware of the default access permissions in their editing
2757 environments and take this into account when writing information.
2758 Furthermore, default privilege policies are usually very
2759 conservative, limiting the privileges granted by the initial ACL.
2761 13 AUTHENTICATION
2763 Authentication mechanisms defined for use with HTTP and WebDAV also
2764 apply to this WebDAV Access Control Protocol, in particular the
2765 Basic and Digest authentication mechanisms defined in [RFC2617].
2767 14 IANA CONSIDERATIONS
2769 This document uses the namespace defined by [RFC2518] for XML
2770 elements. All other IANA considerations mentioned in [RFC2518] also
2771 applicable to this specification.
2773 15 INTELLECTUAL PROPERTY
2775 The following notice is copied from RFC 2026, section 10.4, and
2776 describes the position of the IETF concerning intellectual property
2777 claims made against this document.
2779 The IETF takes no position regarding the validity or scope of any
2780 intellectual property or other rights that might be claimed to
2781 pertain to the implementation or use other technology described in
2782 this document or the extent to which any license under such rights
2783 might or might not be available; neither does it represent that it
2784 has made any effort to identify any such rights. Information on
2785 the IETF's procedures with respect to rights in standards-track and
2786 standards-related documentation can be found in BCP-11. Copies of
2787 claims of rights made available for publication and any assurances
2788 of licenses to be made available, or the result of an attempt made
2789 to obtain a general license or permission for the use of such
2790 proprietary rights by implementers or users of this specification
2791 can be obtained from the IETF Secretariat.
2793 The IETF invites any interested party to bring to its attention any
2794 copyrights, patents or patent applications, or other proprietary
2795 rights that may cover technology that may be required to practice
2796 this standard. Please address the information to the IETF
2797 Executive Director.
2799 16 ACKNOWLEDGEMENTS
2801 This protocol is the collaborative product of the WebDAV ACL design
2802 team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean
2803 Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors
2804 are grateful for the detailed review and comments provided by Jim
2805 Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa
2806 Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis
2807 Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris
2808 Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond,
2809 Julian Reschke, and Keith Wannamaker. We thank Keith Wannamaker for
2810 the initial text of the principal property search sections. Prior
2811 work on WebDAV access control protocols has been performed by Yaron
2812 Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff.
2813 We would like to acknowledge the foundation laid for us by the
2814 authors of the DeltaV, WebDAV and HTTP protocols upon which this
2815 protocol is layered, and the invaluable feedback from the WebDAV
2816 working group.
2818 17 REFERENCES
2820 17.1 Normative References
2822 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
2823 Requirement Levels." RFC 2119, BCP 14, March, 1997.
2825 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible
2826 Markup Language (XML)." World Wide Web Consortium Recommendation
2827 REC-xml.http://www.w3.org/TR/REC-xml
2829 [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in
2830 XML" World Wide Web Consortium Recommendation REC-xml-names.
2831 http://www.w3.org/TR/REC-xml-names/
2833 [RFC3253] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead,
2834 "Versioning Extensions to WebDAV." RFC 3253, March 2002.
2836 [REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World
2837 Wide Web Consortium Recommendation REC-xml-infoset.
2838 http://www.w3.org/TR/xml-infoset/
2840 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
2841 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
2842 Protocol -- HTTP/1.1." RFC 2616, June, 1999.
2844 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.
2845 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
2846 Digest Access Authentication." RFC 2617, June, 1999.
2848 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
2849 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC
2850 2518, February, 1999.
2852 [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
2853 scheme." RFC 2368, July, 1998.
2855 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC
2856 3023, January, 2001.
2858 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and
2859 ISO 10646." RFC 2279, January, 1998.
2861 17.2 Informational References
2863 [RFC2026] S.Bradner, "The Internet Standards Process - Revision 3."
2864 RFC 2026, BCP 9. Harvard, October, 1996.
2866 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
2867 Netscape, December, 1997.
2869 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
2870 Access Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode,
2871 December, 1997.
2873 [CaseMap] M. Davis, "Case Mappings", Unicode Standard Annex #21,
2874 March 26, 2001. http://www.unicode.org/unicode/reports/tr21
2876 18 AUTHORS' ADDRESSES
2878 Geoffrey Clemm
2879 Rational Software
2880 20 Maguire Road
2881 Lexington, MA 02421
2882 Email: geoffrey.clemm@rational.com
2884 Anne Hopkins
2885 Microsoft Corporation
2886 One Microsoft Way
2887 Redmond, WA 98052
2888 Email: annehop@microsoft.com
2890 Eric Sedlar
2891 Oracle Corporation
2892 500 Oracle Parkway
2893 Redwood Shores, CA 94065
2894 Email: esedlar@us.oracle.com
2896 Jim Whitehead
2897 U.C. Santa Cruz
2898 Dept. of Computer Science
2899 Baskin Engineering
2900 1156 High Street
2901 Santa Cruz, CA 95064
2902 Email: ejw@cse.ucsc.edu
2903 19 APPENDICES
2905 19.1 WebDAV XML Document Type Definition Addendum
2907 All XML elements defined in this Document Type Definition (DTD)
2908 belong to the DAV namespace. This DTD should be viewed as an
2909 addendum to the DTD provided in [RFC2518], section 23.1.
2911
2913
2914
2915
2916
2917
2918
2919
2920
2921
2923
2925
2927
2928
2929
2930
2932
2934
2936
2937
2939
2941
2942
2945
2946
2947
2948
2949
2951
2953
2955
2956
2958
2960
2964
2965
2966
2967
2968
2969
2971
2972
2973
2975
2977
2979
2981
2983
2985
2987
2989
2991
2994
2995
2996
2998
2999
3001
3003
3004
3005
3006
3008
3012
3014
3015
3016
3017
3018
3019
3020
3021
3022
3024
3026
3027 ANY value: a sequence of one or more elements, with at most one
3028 DAV:prop element.
3030
3031
3032 ANY value: an element whose value identifies a property. The
3033 expectation is the value of the named property typically contains
3034 an href element that contains the URI of a principal
3035
3037
3038
3039
3041
3043