idnits 2.17.1
draft-ietf-webdav-acl-06.txt:
-(814): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(823): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1902): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
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 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
== There are 11 instances of lines with non-ascii characters in the
document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 44
longer pages, the longest (page 6) being 62 lines
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:
----------------------------------------------------------------------------
-- 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 (June 21, 2001) is 8344 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 426, but not defined
== Unused Reference: 'RFC2026' is defined on line 2271, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML'
** 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 2255 (Obsoleted by RFC 4510, RFC 4516)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 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-06 Anne Hopkins, Microsoft Corporation
3 Eric Sedlar, Oracle Corporation
4 Jim Whitehead, U.C. Santa Cruz
6 Expires December 21, 2001 June 21, 2001
8 WebDAV Access Control Protocol
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other documents
22 at any time. It is inappropriate to use Internet- Drafts as
23 reference material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 Abstract
33 This document specifies a set of methods, headers, and message
34 bodies that define Access Control extensions to the WebDAV
35 Distributed Authoring Protocol. This protocol permits a client to
36 remotely read and modify access control lists that instruct a server
37 whether to grant or deny operations upon a resource (such as HTTP
38 method invocations) by a given principal.
40 This document is a product of the Web Distributed Authoring and
41 Versioning (WebDAV) working group of the Internet Engineering Task
42 Force. Comments on this draft are welcomed, and should be addressed
43 to the acl@webdav.org mailing list. Other related documents can be
44 found at http://www.webdav.org/acl/, and
45 http://www.ics.uci.edu/pub/ietf/webdav/.
47 Table of Contents
49 1 INTRODUCTION...................................................4
50 1.1 Terms.......................................................5
51 1.2 Notational Conventions......................................6
53 2 PRINCIPALS.....................................................6
55 3 PRIVILEGES.....................................................7
56 3.1 DAV:read Privilege..........................................8
57 3.2 DAV:write Privilege.........................................8
58 3.3 DAV:read-acl Privilege......................................9
59 3.4 DAV:read-current-user-privilege-set Privilege...............9
60 3.5 DAV:write-acl Privilege.....................................9
61 3.6 DAV:all Privilege...........................................9
62 3.7 Aggregation of Predefined Privileges........................9
64 4 PRINCIPAL PROPERTIES..........................................10
65 4.1 DAV:alternate-URL..........................................10
67 5 ACCESS CONTROL PROPERTIES.....................................10
68 5.1 DAV:owner..................................................11
69 5.1.1 Example: Retrieving DAV:owner............................11
70 5.1.2 Example: An Attempt to Set DAV:owner.....................12
71 5.2 DAV:supported-privilege-set................................13
72 5.2.1 Example: Retrieving a List of Privileges Supported on a
73 Resource.................................................14
74 5.3 DAV:current-user-privilege-set.............................15
75 5.3.1 Example: Retrieving the User's Current Set of Assigned
76 Privileges...............................................16
77 5.4 DAV:acl....................................................17
78 5.4.1 ACE Principal............................................17
79 5.4.2 ACE Grant and Deny.......................................18
80 5.4.3 ACE Protection...........................................18
81 5.4.4 ACE Inheritance..........................................18
82 5.4.5 Example: Retrieving a Resource's Access Control List.....19
83 5.5 DAV:acl-semantics..........................................20
84 5.5.1 Example: Retrieving DAV:acl-semantics....................21
85 5.6 DAV:principal-collection-set...............................22
86 5.6.1 Example: Retrieving DAV:principal-collection-set.........22
87 5.7 Example: PROPFIND to retrieve access control properties....23
89 6 ACL SEMANTICS.................................................27
90 6.1 ACE Combination............................................27
91 6.1.1 DAV:first-match ACE Combination..........................27
92 6.1.2 DAV:all-grant-before-any-deny ACE Combination............27
93 6.1.3 DAV:specific-deny-overrides-grant ACE Combination........27
94 6.2 ACE Ordering...............................................28
95 6.2.1 DAV:deny-before-grant ACE Ordering.......................28
96 6.3 Allowed ACE................................................28
97 6.3.1 DAV:principal-only-one-ace ACE Constraint................28
98 6.3.2 DAV:grant-only ACE Constraint............................28
99 6.4 Required Principals........................................28
100 7 ACCESS CONTROL AND EXISTING METHODS...........................29
101 7.1 OPTIONS....................................................29
102 7.1.1 Example - OPTIONS........................................29
103 7.2 MOVE.......................................................29
104 7.3 COPY.......................................................29
106 8 ACCESS CONTROL METHODS........................................29
107 8.1 ACL........................................................29
108 8.1.1 ACL Preconditions........................................30
109 8.1.2 Example: the ACL method..................................31
110 8.1.3 Example: ACL method failure due to protected ACE
111 conflict ................................................32
112 8.1.4 Example: ACL method failure due to an inherited ACE
113 conflict ................................................33
114 8.1.5 Example: ACL method failure due to an attempt to set
115 grant and deny in a single ACE ..........................34
117 9 ACCESS CONTROL REPORTS........................................35
118 9.1 REPORT Method..............................................35
119 9.2 DAV:acl-principal-props Report.............................36
120 9.2.1 Example: DAV:acl-principal-props Report..................36
121 9.3 DAV:principal-match REPORT.................................37
122 9.3.1 Example: DAV:principal-match REPORT......................38
124 10 XML PROCESSING..............................................39
126 11 INTERNATIONALIZATION CONSIDERATIONS.........................39
128 12 SECURITY CONSIDERATIONS.....................................40
129 12.1 Increased Risk of Compromised Users........................40
130 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
131 Privileges.................................................40
132 12.3 No Foreknowledge of Initial ACL............................41
134 13 AUTHENTICATION..............................................41
136 14 IANA CONSIDERATIONS.........................................42
138 15 INTELLECTUAL PROPERTY.......................................42
140 16 ACKNOWLEDGEMENTS............................................42
142 17 REFERENCES..................................................43
143 17.1 Normative References.......................................43
144 17.2 Informational References...................................43
146 18 AUTHORS' ADDRESSES..........................................43
148 19 APPENDICIES.................................................44
149 19.1 XML Document Type Definition...............................44
151 20 NOTE TO RFC EDITOR..........................................46
152 1 INTRODUCTION
154 The goal of the WebDAV access control extensions is to provide
155 an interoperable mechanism for handling discretionary access
156 control for content in WebDAV servers. WebDAV access control
157 can be implemented on content repositories with security as
158 simple as that of a UNIX file system, as well as more
159 sophisticated models. The underlying principle of access
160 control is that who you are determines how you can access a
161 resource. The "who you are" is defined by a "principal"
162 identifier; users, client software, servers, and groups of the
163 previous have principal identifiers. The "how" is determined by
164 a single "access control list" (ACL) associated with a
165 resource. An ACL contains a set of "access control entries"
166 (ACEs), where each ACE specifies a principal and a set of
167 privileges that are either granted or denied to that principal.
168 When a principal submits an operation (such as an HTTP or
169 WebDAV method) to a resource for execution, the server
170 evaluates the ACEs in the ACL to determine if the principal has
171 permission for that operation.
173 This specification intentionally omits discussion of
174 authentication, as the HTTP protocol already has a number of
175 authentication mechanisms [RFC2617]. Some authentication
176 mechanism (such as HTTP Digest Authentication, which all WebDAV
177 compliant implementations are required to support) must be
178 available to validate the identity of a principal.
180 The following issues are out of scope for this document:
182 * Access control that applies only to a particular property
183 on a resource (excepting the access control properties
184 DAV:acl and DAV:current-user-privilege-set), rather than
185 the entire resource,
187 * Role-based security (where a role can be seen as a
188 dynamically defined collection of principals),
190 * Specification of the ways an ACL on a resource is
191 initialized,
193 * Specification of an ACL that applies globally to all
194 resources , rather than to a particular resource.
196 * Creation and maintenance of resources representing people
197 or computational agents (principals), and groups of these.
199 This specification is organized as follows. Section 1.1 defines
200 key concepts used throughout the specification, and is followed
201 by more in-depth discussion of principals (Section 2), and
202 privileges (Section 3). Properties defined on principals are
203 specified in Section 4, and access control properties for
204 content resources are specified in Section 5. The semantics of
205 access control lists are described in Section 6, including
206 sections on ACE combination (Section 6.1), ACE ordering
207 (Section 6.2), and principals required to be present in an ACE
208 (Section 6.4). Client discovery of access control capability
209 using OPTIONS is described in Section 7.1, and the access
210 control setting method, ACL, is specified in Section 8.
211 Internationalization considerations (Section 11) and security
212 considerations (Section 12) round out the specification. An
213 appendix (Section 19.1) provides an XML Document Type
214 Definition (DTD) for the XML elements defined in the
215 specification.
217 1.1 Terms
219 This draft uses the terms defined in HTTP [RFC2616] and WebDAV
220 [RFC2518]. In addition, the following terms are defined:
222 principal
224 A "principal" is a distinct human or computational actor that
225 initiates access to network resources. In this protocol, a
226 principal is an HTTP resource that represents such an actor.
228 principal collection
230 A "principal collection" is a group of principals, and is
231 represented in this protocol by a WebDAV collection containing
232 HTTP resources that represent principals, and principal
233 collections.
235 privilege
237 A "privilege" controls access to a particular set of HTTP
238 operations on a resource.
240 aggregate privilege
242 An "aggregate privilege" is a privilege that contains a set of
243 other privileges.
245 abstract privilege
247 The modifier "abstract", when applied to a privilege, means the
248 privilege cannot be set in an access control element (ace).
250 access control list (ACL)
252 An "ACL" is a list of access control elements that define
253 access control to a particular resource.
255 access control element (ace)
257 An "ace" either grants or denies a particular set of (non-
258 abstract) privileges for a particular principal.
260 inherited ace
262 An "inherited ace" is an ace that is dynamically shared from
263 the ACL of another resource. When a shared ACE changes on the
264 primary resource, it is also changed on inheriting resources.
266 protected property
268 A "protected property" is one whose value cannot be updated
269 except by a method explicitly defined as updating that specific
270 property. In particular, a protected property cannot be
271 updated with a PROPPATCH request.
273 1.2 Notational Conventions
275 The augmented BNF used by this document to describe protocol
276 elements is described in Section 2.1 of [RFC2616]. Because this
277 augmented BNF uses the basic production rules provided in
278 Section 2.2 of [RFC2616], those rules apply to this document as
279 well.
281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
282 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
283 "OPTIONAL" in this document are to be interpreted as described
284 in [RFC2119].
286 Definitions of XML elements in this document use XML element
287 type declarations (as found in XML Document Type Declarations),
288 described in Section 3.2 of [REC-XML].
290 2 PRINCIPALS
292 A principal is a network resource that represents a distinct
293 human or computational actor that initiates access to network
294 resources. On many implementations, users and groups are
295 represented as principals; other types of principals are also
296 possible. A URI of any scheme MAY be used to identify a
297 principal resource. However, servers implementing this
298 specification MUST expose principal resources at an http(s)
299 URL, which is a privileged scheme that points to resources that
300 have additional properties, as described in Section 4. So, a
301 principal resource can have multiple URI identifiers, one of
302 which has to be an http(s) scheme URL. Although an
303 implementation SHOULD support PROPFIND and MAY support
304 PROPPATCH to access and modify information about a principal,
305 it is not required to do so.
307 A principal resource may or may not be a collection. If a
308 person or computational agent matches a principal resource that
309 is contained by a collection principal, they also match the
310 collection principal. This definition is recursive, and hence
311 if a person or computational agent matches a collection
312 principal that is the child of another collection principal,
313 they also match the parent collection principal. Membership in
314 a collection principal is also recursive, so a principal in a
315 collection principal GRPA contained by collection principal
316 GRPB is a member of both GRPA and GRPB. Implementations not
317 supporting recursive membership in principal collections can
318 return an error if the client attempts to bind collection
319 principals into other collection principals.
321 Servers that support aggregation of principals (e.g. groups of
322 users or other groups) MUST manifest them as collection
323 principals. At minimum, principals and collection principals
324 MUST support the OPTIONS and PROPFIND methods.
326 Implementer's Note: Collection principals are first and
327 foremost WebDAV collections. Therefore they contain
328 resources as members. Since there is no requirement that all
329 members of a collection principal need be principals, it is
330 possible for a collection principal to have non-principals
331 as members. When enumerating the principals-only membership
332 of a collection principal, it is necessary to retrieve the
333 DAV:resourcetype property and check it for the DAV:principal
334 XML element (described in Section 4). If the DAV:principal
335 XML element is not present, the resource is not a principal
336 and may be ignored for the purposes of determining the
337 principals-only membership of the collection principal.
339 For example, the collection principal /FOO/ has two members,
340 Bar and Baz. Bar is a principal but Baz is not. Therefore
341 when determining which principals belong to the collection
342 principal /FOO/, a client would enumerate the membership
343 using PROPFIND while asking for the DAV:resourcetype
344 property, and see that only Bar has the DAV:principal XML
345 element. Therefore, only Bar is the only principal that is a
346 member of the collection principal /FOO/.
348 3 PRIVILEGES
350 Ability to perform a given method on a resource SHOULD be
351 controlled by one or more privileges. Authors of protocol
352 extensions that define new HTTP methods SHOULD specify which
353 privileges (by defining new privileges, or mapping to ones
354 below) are required to perform the method. A principal with no
355 privileges to a resource SHOULD be denied any HTTP access to
356 that resource.
358 Privileges may be containers of other privileges, in which case
359 they are termed aggregate privileges. If a principal is
360 granted or denied an aggregate privilege, it is semantically
361 equivalent to granting or denying each of the aggregated
362 privileges individually. For example, an implementation may
363 define add-member and remove-member privileges that control the
364 ability to add and remove an internal member of a collection.
365 Since these privileges control the ability to update the state
366 of a collection, these privileges would be aggregated by the
367 DAV:write privilege on a collection, and granting the DAV:write
368 privilege on a collection would also grant the add-member and
369 remove-member privileges.
371 Privileges may have the quality of being abstract, in which
372 case they cannot be set in an ACE. Aggregate and non-aggregate
373 privileges are both capable of being abstract. Abstract
374 privileges are useful for modeling privileges that otherwise
375 would not be exposed via the protocol. Abstract privileges also
376 provide server implementations with flexibility in implementing
377 the privileges defined in this specification. For example, if
378 a server is incapable of separating the read resource
379 capability from the read ACL capability, it can still model the
380 DAV:read and DAV:read-acl privileges defined in this
381 specification by declaring them abstract, and containing them
382 within a non-abstract aggregate privilege (say, read-all) that
383 holds DAV:read, and DAV:read-acl. In this way, it is possible
384 to set the aggregate privilege, read-all, thus coupling the
385 setting of DAV:read and DAV:read-acl, but it is not possible to
386 set DAV:read, or DAV:read-acl individually. Since aggregate
387 privileges can be abstract, it is also possible to use abstract
388 privileges to group or organize non-abstract privileges.
389 Privilege containment loops are not allowed, hence a privilege
390 MUST NOT contain itself. For example, DAV:read cannot contain
391 DAV:read.
393 The set of privileges that apply to a particular resource may
394 vary with the DAV:resourcetype of the resource, as well as
395 between different server implementations. To promote
396 interoperability, however, this specification defines a set of
397 well-known privileges (e.g. DAV:read,DAV:write, DAV:read-acl,
398 DAV:write-acl, DAV:read-current-user-privilege-set, and
399 DAV:all), which can at least be used to classify the other
400 privileges defined on a particular resource. The access
401 permissions on null and lock-null resources (defined in
402 [RFC2518], Sections 3 and 7.4) are solely those they inherit
403 (if any), and they are not discoverable (i.e., the access
404 control properties specified in Section 5 are not defined on
405 null and lock-null resources). On the transition from null or
406 lock-null to a stateful resource, the initial access control
407 list is set by the server's default ACL value policy (if any).
409 3.1 DAV:read Privilege
411 The read privilege controls methods that return information
412 about the state of the resource, including the resource's
413 properties. Affected methods include GET and PROPFIND.
414 Additionally, the read privilege MAY control the OPTIONS
415 method.
417
419 3.2 DAV:write Privilege
421 The write privilege controls methods that modify the content,
422 dead properties, or (in the case of a collection) membership of
423 the resource, such as PUT and PROPPATCH. Note that state
424 modification is also controlled via locking (see section 5.3 of
426 [WEBDAV]), so effective write access requires that both write
427 privileges and write locking requirements are satisfied.
429
431 3.3 DAV:read-acl Privilege
433 The DAV:read-acl privilege controls the use of PROPFIND to
434 retrieve the DAV:acl property of the resource.
436
438 3.4 DAV:read-current-user-privilege-set Privilege
440 The DAV:read-current-user-privilege-set privilege controls the
441 use of PROPFIND to retrieve the DAV:current-user-privilege-set
442 property of the resource.
444 Clients are intended to use this property to visually indicate
445 in their UI items that are dependent on the permissions of a
446 resource, for example, by graying out resources that are not
447 writeable.
449 This privilege is separate from DAV:read-acl because there is a
450 need to allow most users access to the privileges permitted the
451 current user (due to its use in creating the UI), while the
452 full ACL contains information that may not be appropriate for
453 the current authenticated user. As a result, the set of users
454 who can view the full ACL is expected to be much smaller than
455 those who can read the current user privilege set, and hence
456 distinct privileges are needed for each.
458
460 3.5 DAV:write-acl Privilege
462 The DAV:write-acl privilege controls use of the ACL method to
463 modify the DAV:acl property of the resource.
465
467 3.6 DAV:all Privilege
469 DAV:all is an aggregate privilege that contains the entire set
470 of privileges that apply to the resource.
472
474 3.7 Aggregation of Predefined Privileges
476 Server implementations are free to aggregate the predefined
477 privileges (defined above in Sections 3.1-3.6) subject to the
478 following limitations:
480 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-
481 acl, or DAV:read-current-user-privilege-set.
483 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-
484 acl, or DAV:read-current-user-privilege-set.
486 DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
487 DAV:read, DAV:read-acl, or DAV:write-acl.
489 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
490 current-user-privilege-set.
492 DAV:read MUST NOT contain DAV:write, or DAV:write-acl.
494 4 PRINCIPAL PROPERTIES
496 Principals are manifested to clients as an HTTP resource,
497 identified by a URL. A principal MUST have a DAV:displayname
498 property (defined in Section 13.2 of [RFC2518]), and a
499 DAV:resourcetype property (defined in Section 13.9 of
500 [RFC2518]). Additionally, a principal MUST report the
501 DAV:principal empty XML element in the value of the
502 DAV:resourcetype property in addition to all other reported
503 elements. For example, a collection principal would report
504 DAV:collection and DAV:principal elements. The element type
505 declaration for DAV:principal is:
507
509 This protocol defines the following additional property for a
510 principal. Since it is expensive, for many servers, to retrieve
511 access control information, the name and value of this property
512 SHOULD NOT be returned by a PROPFIND allprop request (as
513 defined in Section 12.14.1 of [RFC2518]).
515 4.1 DAV:alternate-URL
517 This protected property, if non-empty, contains the URIs of
518 network resources with additional descriptive information about
519 the principal. This property identifies one or more additional
520 network resources (i.e., it contains one or more URIs) that may
521 be consulted by a client to gain additional knowledge
522 concerning a principal. Two potential uses for this property
523 are to store an ldap [RFC2255] or mailto [RFC2368] scheme URL.
524 Support for this property is REQUIRED, and the value is empty
525 if no alternate URL exists for the principal. .
527
529 5 ACCESS CONTROL PROPERTIES
531 This specification defines a number of new properties for
532 WebDAV resources. Access control properties may be retrieved
533 just like other WebDAV properties, using the PROPFIND method.
534 Since it is expensive, for many servers, to retrieve access
535 control information, a PROPFIND allprop request (as defined in
536 Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and
537 values of the properties defined in this section.
539 HTTP resources that support the WebDAV Access Control Protocol
540 MUST contain the following properties. Null, and lock-null
541 resources (described in Section 7.4 of [RFC2518]) MUST NOT
542 contain the following properties:
544 5.1 DAV:owner
546 This protected property identifies a particular principal as
547 being the "owner" of the resource. Since the owner of a
548 resource often has special access control capabilities (e.g.,
549 the owner frequently has permanent DAV:write-acl privilege),
550 clients might display the resource owner in their user
551 interface.
553
555 5.1.1 Example: Retrieving DAV:owner
557 This example shows a client request for the value of the
558 DAV:owner property from a collection resource with URL
559 http://www.webdav.org/papers/. The principal making the request
560 is authenticated using Digest authentication. The value of
561 DAV:owner is the URL http://www.webdav.org/_acl/users/gstein,
562 wrapped in the DAV:href XML element.
564 >> Request <<
566 PROPFIND /papers/ HTTP/1.1
567 Host: www.webdav.org
568 Content-type: text/xml; charset="utf-8"
569 Content-Length: xxx
570 Depth: 0
571 Authorization: Digest username="jim",
572 realm="jim@webdav.org", nonce="...",
573 uri="/papers/", response="...", opaque="..."
575
576
577
578
580 >> Response <<
582 HTTP/1.1 207 Multi-Status
583 Content-Type: text/xml; charset="utf-8"
584 Content-Length: xxx
586
587
588
589 http://www.webdav.org/papers/
590
591 HTTP/1.1 200 OK
592
593
594
595 http://www.webdav.org/_acl/users/gstein
596
597
598
599
600
601
603 5.1.2 Example: An Attempt to Set DAV:owner
605 The following example shows a client request to modify the
606 value of the DAV:owner property on the resource with URL
607 http://www.webdav.org/papers/. Since DAV:owner is a protected
608 property, the server responds with a 207 (Multi-Status)
609 response that contains a 403 (Forbidden) status code for the
610 act of setting DAV:owner. [RFC2518], Section 8.2.1 describes
611 PROPPATCH status code information, and Section 11 describes the
612 Multi-Status response.
614 >> Request <<
616 PROPPATCH /papers/ HTTP/1.1
617 Host: www.webdav.org
618 Content-type: text/xml; charset="utf-8"
619 Content-Length: xxx
620 Depth: 0
621 Authorization: Digest username="jim",
622 realm="jim@webdav.org", nonce="...",
623 uri="/papers/", response="...", opaque="..."
625
626
627
628
629
630
631 http://www.webdav.org/_acl/users/jim
632
633
634
635
636
638 >> Response <<
640 HTTP/1.1 207 Multi-Status
641 Content-Type: text/xml; charset="utf-8"
642 Content-Length: xxx
643
644
645
646 http://www.webdav.org/papers/
647
648 HTTP/1.1 403 Forbidden
649
650
651 Failure to set protected property
652 (DAV:owner)
653
654
655
657 5.2 DAV:supported-privilege-set
659 This is a protected property that identifies the privileges
660 defined for the resource.
662
664 Each privilege appears as an XML element, where aggregate
665 privileges list as sub-elements all of the privileges that they
666 aggregate.
668
670
672 An abstract privilege of a resource MUST NOT be used in an ACE
673 for that resource. Servers MUST fail an attempt to set an
674 abstract privilege.
676
678 A description is a human-readable description of what this
679 privilege controls access to.
681
683 It is envisioned that a WebDAV ACL-aware administrative client
684 would list the supported privileges in a dialog box, and allow
685 the user to choose non-abstract privileges to apply in an ACE.
686 The privileges tree is useful programmatically to map well-
687 known privileges (defined by WebDAV or other standards groups)
688 into privileges that are supported by any particular server
689 implementation. The privilege tree also serves to hide
690 complexity in implementations allowing large number of
691 privileges to be defined by displaying aggregates to the user.
693 5.2.1 Example: Retrieving a List of Privileges Supported on a
694 Resource
696 This example shows a client request for the DAV:supported-
697 privilege-set property on the resource
698 http://www.webdav.org/papers/. The value of the DAV:supported-
699 privilege-set property is a tree of supported privileges:
701 DAV:all (aggregate, abstract)
702 |
703 +-- DAV:read (aggregate)
704 |
705 +-- DAV:read-acl (abstract)
706 +-- DAV:read-current-user-privilege-set (abstract)
707 +-- DAV:write (aggregate)
708 |
709 +-- DAV:write-acl (abstract)
711 This privilege tree is not normative, and many possible
712 privilege trees are possible.
714 >> Request <<
716 PROPFIND /papers/ HTTP/1.1
717 Host: www.webdav.org
718 Content-type: text/xml; charset="utf-8"
719 Content-Length: xxx
720 Depth: 0
721 Authorization: Digest username="gclemm",
722 realm="gclemm@webdav.org", nonce="...",
723 uri="/papers/", response="...", opaque="..."
725
726
727
728
730 >> Response <<
732 HTTP/1.1 207 Multi-Status
733 Content-Type: text/xml; charset="utf-8"
734 Content-Length: xxx
736
737
738
739 http://www.webdav.org/papers/
740
741 HTTP/1.1 200 OK
742
743
744
745
746
747 Any operation
748
749
750 Read any object
751
752
753
754 Read ACL
755
756
757
758
759
760
761
762 Read current user privilege set
763 property
764
765
766
767 Write any object
768
769
770 Write ACL
771
772
773
774
775
776
777
778
779
781 5.3 DAV:current-user-privilege-set
783 DAV:current-user-privilege-set is a protected property
784 containing the exact set of privileges (as computed by the
785 server) granted to the currently authenticated HTTP user.
786 Aggregate privileges and their contained privileges are listed.
787 A user-agent can use the value of this property to adjust its
788 user interface to make actions inaccessible (e.g., by graying
789 out a menu item or button) for which the current principal does
790 not have permission. This is particularly useful for an access
791 control user interface, which can be constructed without
792 knowing the ACE combining semantics of the server. This
793 property is also useful for determining what operations the
794 current principal can perform, without having to actually
795 execute an operation.
797
798
800 If the current user is granted a specific privilege, that
801 privilege must belong to the set of privileges that may be set
802 on this resource. Therefore, each element in the DAV:current-
803 user-privilege-set property MUST identify a non-abstract
804 privilege from the DAV:supported-privilege-set property.
806 5.3.1 Example: Retrieving the User's Current Set of Assigned
807 Privileges
809 Continuing the example from Section 5.2.1, this example shows a
810 client requesting the DAV:current-user-privilege-set property
811 from the resource with URL http://www.webdav.org/papers/. The
812 username of the principal making the request is �khare�, and
813 Digest authentication is used in the request. The principal
814 with username �khare� has been granted the DAV:read privilege.
815 Since the DAV:read privilege contains the DAV:read-acl and
816 DAV:read-current-user-privilege-set privileges (see Section
817 5.2.1), the principal with username �khare� can read the ACL
818 property, and the DAV:current-user-privilege-set property.
819 However, the DAV:all, DAV:read-acl, DAV:write-acl and DAV:read-
820 current-user-privilege-set privileges are not listed in the
821 value of DAV:current-user-privilege-set, since (for this
822 example) they are abstract privileges. DAV:write is not listed
823 since the principal with username �khare� is not listed in an
824 ACE granting that principal write permission.
826 >> Request <<
828 PROPFIND /papers/ HTTP/1.1
829 Host: www.webdav.org
830 Content-type: text/xml; charset="utf-8"
831 Content-Length: xxx
832 Depth: 0
833 Authorization: Digest username="khare",
834 realm="khare@webdav.org", nonce="...",
835 uri="/papers/", response="...", opaque="..."
837
838
839
840
842 >> Response <<
844 HTTP/1.1 207 Multi-Status
845 Content-Type: text/xml; charset="utf-8"
846 Content-Length: xxx
848
849
850
851 http://www.webdav.org/papers/
852
853 HTTP/1.1 200 OK
854
855
856
857
858
859
860
861
863 5.4 DAV:acl
865 This is a protected property that specifies the list of access
866 control entries (ACEs), which define what principals are to get
867 what privileges for this resource.
869
871 Each DAV:ace element specifies the set of privileges to be
872 either granted or denied to a single principal. If the DAV:acl
873 property is empty, no principal is granted any privilege.
875
878 5.4.1 ACE Principal
880 The DAV:principal element identifies the principal to which
881 this ACE applies.
883
887 The current user matches DAV:href only if that user is
888 authenticated as being (or being a member of) the principal
889 identified by the URL contained by that DAV:href.
891 The current user always matches DAV:all.
893
895 The current user matches DAV:authenticated only if
896 authenticated.
898
900 The current user matches DAV:unauthenticated only if not
901 authenticated.
903
905 DAV:all is the union of DAV:authenticated, and
906 DAV:unauthenticated. For a given request, the user matches
907 either DAV:authenticated, or DAV:unauthenticated, but not both
908 (that is, DAV:authenticated and DAV:unauthenticated are
909 disjoint sets).
911 The current user matches a DAV:property principal in a DAV:acl
912 property of a resource only if the value of the identified
913 property of that resource contains at most one DAV:href XML
914 element, the URI value of DAV:href identifies a principal, and
915 the current user is authenticated as being (or being a member
916 of) that principal. For example, if the DAV:property element
917 contained , the current user would match the
918 DAV:property principal only if the current user is
919 authenticated as matching the principal identified by the
920 DAV:owner property of the resource.
922
924 The current user matches DAV:self in a DAV:acl property of the
925 resource only if that resource is a principal object and the
926 current user is authenticated as being that principal or a
927 member of that principal collection.
929
931 5.4.2 ACE Grant and Deny
933 Each DAV:grant or DAV:deny element specifies the set of
934 privileges to be either granted or denied to the specified
935 principal. A DAV:grant or DAV:deny element of the DAV:acl of a
936 resource MUST only contain non-abstract elements specified in
937 the DAV:supported-privilege-set of that resource.
939
940
941
943 5.4.3 ACE Protection
945 If an ACE contains a DAV:protected element, an ACL request
946 without that ACE MUST fail.
948
950 5.4.4 ACE Inheritance
952 The presence of a DAV:inherited element indicates that this ACE
953 is inherited from another resource that is identified by the
954 URL contained in a DAV:href element. An inherited ACE cannot
955 be modified directly, but instead the ACL on the resource from
956 which it is inherited must be modified.
958 Note that ACE inheritance is not the same as ACL
959 initialization. ACL initialization defines the ACL that a
960 newly created resource will use (if not specified). ACE
961 inheritance refers to an ACE that is logically shared - where
962 an update to the resource containing an ACE will affect the ACE
963 of each resource that inherits that ACE. The method by which
964 ACLs are initialized or by which ACEs are inherited is not
965 defined by this document.
967
969 5.4.5 Example: Retrieving a Resource's Access Control List
971 Continuing the example from Sections 5.2.1 and 5.3.1, this
972 example shows a client requesting the DAV:acl property from the
973 resource with URL http://www.webdav.org/papers/. There are two
974 ACEs defined in this ACL:
976 ACE #1: The principal collection identified by URL
977 http://www.webdav.org/_acl/groups/maintainers/ (the group of
978 site maintainers) is granted DAV:write privilege. Since (for
979 this example) DAV:write contains the DAV:write-acl privilege
980 (see Section 5.2.1), this means the �maintainers� group can
981 also modify the access control list.
983 ACE #2: All principals (DAV:all) are granted the DAV:read
984 privilege. Since (for this example) DAV:read contains DAV:read-
985 acl and DAV:read-current-user-privilege-set, this means all
986 users (including all members of the �maintainers� group) can
987 read the DAV:acl property and the DAV:current-user-privilege-
988 set property.
990 >> Request <<
992 PROPFIND /papers/ HTTP/1.1
993 Host: www.webdav.org
994 Content-type: text/xml; charset="utf-8"
995 Content-Length: xxx
996 Depth: 0
997 Authorization: Digest username="masinter",
998 realm="masinter@webdav.org", nonce="...",
999 uri="/papers/", response="...", opaque="..."
1001
1002
1003
1004
1006 >> Response <<
1008 HTTP/1.1 207 Multi-Status
1009 Content-Type: text/xml; charset="utf-8"
1010 Content-Length: xxx
1012
1013
1014
1015 http://www.webdav.org/papers/
1016
1017 HTTP/1.1 200 OK
1018
1019
1020
1021
1022
1023 http://www.webdav.org/_acl/groups/maintainers/
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1044 5.5 DAV:acl-semantics
1046 This is a protected property that defines the ACL semantics.
1047 These semantics define how multiple ACEs that match the current
1048 user are combined, what are the constraints on how ACEs can be
1049 ordered, and which principals must have an ACE. A client user
1050 interface could use the value of this property to provide
1051 feedback to a human operator concerning the impact of proposed
1052 changes to an ACL. Alternately, a client can use this property
1053 to help it determine, before submitting an ACL method
1054 invocation, what ACL changes it needs to make to accomplish a
1055 specific goal (or whether that goal is even achievable on this
1056 server).
1058 Since it is not practical to require all implementations to use
1059 the same ACL semantics, the DAV:acl-semantics property is used
1060 to identify the ACL semantics for a particular resource. The
1061 DAV:acl-semantics element is defined in Section 6.
1063 5.5.1 Example: Retrieving DAV:acl-semantics
1065 In this example, the client requests the value of the DAV:acl-
1066 semantics property. Digest authentication provides credentials
1067 for the principal operating the client. In this example, the
1068 ACE combination semantics are DAV:first-match, described in
1069 Section 6.1.1, the ACE ordering semantics are not specified
1070 (some value other than DAV:deny-before-grant, described in
1071 Section 6.2.1), the DAV:allowed-ace element states that only
1072 one ACE is permitted for each principal, and an ACE describing
1073 the privileges granted the DAV:all principal must exist in
1074 every ACL.
1076 >> Request <<
1078 PROPFIND /papers/ HTTP/1.1
1079 Host: www.webdav.org
1080 Content-type: text/xml; charset="utf-8"
1081 Content-Length: xxx
1082 Depth: 0
1083 Authorization: Digest username="srcarter",
1084 realm="srcarter@webdav.org", nonce="...",
1085 uri="/papers/", response="...", opaque="..."
1087
1088
1089
1090
1092 >> Response <<
1094 HTTP/1.1 207 Multi-Status
1095 Content-Type: text/xml; charset="utf-8"
1096 Content-Length: xxx
1098
1099
1100
1101 http://www.webdav.org/papers/
1102
1103 HTTP/1.1 200 OK
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1122 5.6 DAV:principal-collection-set
1124 This protected property contains zero, one, or more URLs that
1125 identify a collection principal. It is expected that
1126 implementations of this protocol will typically use a
1127 relatively small number of locations in the URL namespace for
1128 principal, and collection principals. In cases where this
1129 assumption holds, the DAV:principal-collection-set property
1130 will contain a small set of URLs identifying the top of a
1131 collection hierarchy containing multiple principals and
1132 collection principals. An access control protocol user agent
1133 could use the contents of DAV:principal-collection-set to query
1134 the DAV:displayname property (specified in Section 13.2 of
1135 [RFC2518]) of all principals on that server, thereby yielding
1136 human-readable names for each principal that could be displayed
1137 in a user interface.
1139
1141 Since different servers can control different parts of the URL
1142 namespace, different resources on the same host MAY have
1143 different DAV:principal-collection-set values. The collections
1144 specified in the DAV:principal-collection-set MAY be located on
1145 different hosts from the resource. The URLs in DAV:principal-
1146 collection-set SHOULD be http or https scheme URLs. For
1147 security and scalability reasons, a server MAY report only a
1148 subset of the entire set of known collection principals, and
1149 therefore clients should not assume they have retrieved an
1150 exhaustive listing. Additionally, a server MAY elect to report
1151 none of the collection principals it knows about, in which case
1152 the property value would be empty.
1154 5.6.1 Example: Retrieving DAV:principal-collection-set
1156 In this example, the client requests the value of the
1157 DAV:principal-collection-set property on the collection
1158 resource identified by URL http://www.webdav.org/papers/. The
1159 property contains the two URLs,
1160 http://www.webdav.org/_acl/users/ and
1161 http://www.webdav.org/_acl/groups/, both wrapped in
1162 XML elements. Digest authentication provides credentials for
1163 the principal operating the client.
1165 The client might reasonably follow this request with two
1166 separate PROPFIND requests to retrieve the DAV:displayname
1167 property of the members of the two collections (/_acl/users/
1168 and /_acl_groups/). This information could be used when
1169 displaying a user interface for creating access control
1170 entries.
1172 >> Request <<
1174 PROPFIND /papers/ HTTP/1.1
1175 Host: www.webdav.org
1176 Content-type: text/xml; charset="utf-8"
1177 Content-Length: xxx
1178 Depth: 0
1179 Authorization: Digest username="yarong",
1180 realm="yarong@webdav.org", nonce="...",
1181 uri="/papers/", response="...", opaque="..."
1183
1184
1185
1186
1188 >> Response <<
1190 HTTP/1.1 207 Multi-Status
1191 Content-Type: text/xml; charset="utf-8"
1192 Content-Length: xxx
1194
1195
1196
1197 http://www.webdav.org/papers/
1198
1199 HTTP/1.1 200 OK
1200
1201
1202
1203 http://www.webdav.org/_acl/users/
1204
1205
1206 http://www.webdav.org/_acl/groups/
1207
1208
1209
1210
1211
1212
1214 5.7 Example: PROPFIND to retrieve access control properties
1216 The following example shows how access control information can
1217 be retrieved by using the PROPFIND method to fetch the values
1218 of the DAV:owner, DAV:supported-privilege-set, DAV:current-
1219 user-privilege-set, and DAV:acl properties.
1221 >> Request <<
1223 PROPFIND /top/container/ HTTP/1.1
1224 Host: www.foo.org
1225 Content-type: text/xml; charset="utf-8"
1226 Content-Length: xxx
1227 Depth: 0
1228 Authorization: Digest username="ejw",
1229 realm="users@foo.org", nonce="...",
1230 uri="/top/container/", response="...", opaque="..."
1232
1233
1234
1235
1236
1237
1238
1240 >> Response <<
1242 HTTP/1.1 207 Multi-Status
1243 Content-Type: text/xml; charset="utf-8"
1244 Content-Length: xxx
1246
1247
1250 http://www.foo.org/top/container/
1251
1252 HTTP/1.1 200 OK
1253
1254
1255 http://www.foo.org/users/gclemm
1256
1257
1258
1259
1260
1261 Any operation
1262
1263
1264 Read any object
1265
1266
1267
1268
1269 Write any object
1270
1271
1272 Create an object
1273
1274
1275
1276 Update an object
1277
1278
1279
1280 Delete an object
1281
1282
1283
1284
1285 Read the ACL
1286
1287
1288
1289 Write the ACL
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300 http://www.foo.org/users/esedlar
1301
1302
1303
1304
1305
1306
1307
1308
1309 http://www.foo.org/groups/marketing/
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327 http://www.foo.org/top/
1328
1329
1330
1331
1333 The value of the DAV:owner property is a single DAV:href XML
1334 element containing the URL of the principal that owns this
1335 resource.
1337 The value of the DAV:supported-privilege-set property is a tree
1338 of supported privileges:
1340 DAV:all (aggregate, abstract)
1341 |
1342 +-- DAV:read
1343 +-- DAV:write (aggregate, abstract)
1344 |
1345 +-- http://www.webdav.org/acl/create
1346 +-- http://www.webdav.org/acl/update
1347 +-- http://www.webdav.org/acl/delete
1348 +-- DAV:read-acl
1349 +-- DAV:write-acl
1351 The DAV:current-user-privilege-set property contains two
1352 privileges, DAV:read, and DAV:read-acl. This indicates that the
1353 current authenticated user only has the ability to read the
1354 resource, and read the DAV:acl property on the resource.
1356 The DAV:acl property contains a set of four ACEs:
1358 ACE #1: The principal identified by the URL
1359 http://www.foo.org/users/esedlar is granted the DAV:read,
1360 DAV:write, and DAV:read-acl privileges.
1362 ACE #2: The principals identified by the URL
1363 http://www.foo.org/groups/marketing/ are denied the DAV:read
1364 privilege. In this example, the principal URL identifies a
1365 group, which is represented by a collection principal.
1367 ACE #3: In this ACE, the principal is a property principal,
1368 specifically the DAV:owner property. When evaluating this ACE,
1369 the value of the DAV:owner property is retrieved, and is
1370 examined to see if it contains a DAV:href XML element. If so,
1371 the URL within the DAV:href element is read, and identifies a
1372 principal. In this ACE, the owner is granted DAV:read-acl, and
1373 DAV:write-acl privileges.
1375 ACE #4: This ACE grants the DAV:all principal (all users) the
1376 DAV:read privilege. This ACE is inherited from the resource
1377 http://www.foo.org/top/, the parent collection of this
1378 resource.
1380 6 ACL SEMANTICS
1382 The ACL semantics define how multiple ACEs that match the
1383 current user are combined, what are the constraints on how ACEs
1384 can be ordered, and which principals must have an ACE.
1386
1388
1391 6.1 ACE Combination
1393 The DAV:ace-combination element defines how privileges from
1394 multiple ACEs that match the current user will be combined to
1395 determine the access privileges for that user. Multiple ACEs
1396 may match the same user because the same principal can appear
1397 in multiple ACEs, because multiple principals can identify the
1398 same user, and because one principal can be a member of another
1399 principal.
1401
1405 6.1.1 DAV:first-match ACE Combination
1407 The ACEs are evaluated in the order in which they appear in the
1408 ACL. If the first ACE that matches the current user does not
1409 grant all the privileges needed for the request, the request
1410 MUST fail.
1412
1414 6.1.2 DAV:all-grant-before-any-deny ACE Combination
1416 The ACEs are evaluated in the order in which they appear in the
1417 ACL. If an evaluated ACE denies a privilege needed for the
1418 request, the request MUST fail. If all ACEs have been
1419 evaluated without the user being granted all privileges needed
1420 for the request, the request MUST fail.
1422
1424 6.1.3 DAV:specific-deny-overrides-grant ACE Combination
1426 All ACEs in the ACL are evaluated. An "individual ACE" is one
1427 whose principal identifies the current user. A "group ACE" is
1428 one whose principal is a collection that contains a principal
1429 that identifies the current user. A privilege is granted if it
1430 is granted by an individual ACE and not denied by an individual
1431 ACE, or if it is granted by a group ACE and not denied by an
1432 individual or group ACE. A request MUST fail if any of its
1433 needed privileges are not granted.
1435
1437 6.2 ACE Ordering
1439 The DAV:ace-ordering element defines a constraint on how the
1440 ACEs can be ordered in the ACL.
1442
1444 6.2.1 DAV:deny-before-grant ACE Ordering
1446 This element indicates that all deny ACEs must precede all
1447 grant ACEs.
1449
1451 6.3 Allowed ACE
1453 The DAV:allowed-ace XML element specifies constraints on what
1454 kinds of ACEs are allowed in an ACL.
1456
1458 6.3.1 DAV:principal-only-one-ace ACE Constraint
1460 This element indicates that a principal can appear in only one
1461 ACE per resource.
1463
1465 6.3.2 DAV:grant-only ACE Constraint
1467 This element indicates that ACEs with deny clauses are not
1468 allowed.
1470
1472 6.4 Required Principals
1474 The required principal elements identify which principals must
1475 have an ACE defined in the ACL.
1477
1481 For example, the following element requires that the ACL
1482 contain a DAV:owner property ACE:
1484
1485
1486
1487 7 ACCESS CONTROL AND EXISTING METHODS
1489 This section defines the impact of access control functionality
1490 on existing methods.
1492 7.1 OPTIONS
1494 If the server supports access control, it MUST return "access-
1495 control" as a field in the DAV response header from an OPTIONS
1496 request on any resource implemented by that server.
1498 7.1.1 Example - OPTIONS
1500 >> Request <<
1502 OPTIONS /foo.html HTTP/1.1
1503 Host: www.webdav.org
1504 Content-Length: 0
1506 >> Response <<
1508 HTTP/1.1 200 OK
1509 DAV: 1, 2, access-control
1510 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
1512 In this example, the OPTIONS response indicates that the server
1513 supports access control and that /foo.html can have its access
1514 control list modified by the ACL method.
1516 7.2 MOVE
1518 When a resource is moved from one location to another due to a
1519 MOVE request, the non-inherited ACEs in the DAV:acl property of
1520 the resource MUST NOT be modified, or the MOVE request fails.
1522 7.3 COPY
1524 The DAV:acl property on the resource at the destination of a
1525 COPY MUST be the same as if the resource was created by an
1526 individual resource creation request (e.g. MKCOL, PUT).
1528 8 ACCESS CONTROL METHODS
1530 8.1 ACL
1532 The ACL method modifies the access control list (which can be
1533 read via the DAV:acl property) of a resource. Specifically,
1534 the ACL method only permits modification to ACEs that are not
1535 inherited, and are not protected. An ACL method invocation
1536 modifies all non-inherited and non-protected ACEs in a
1537 resource's access control list to exactly match the ACEs
1538 contained within in the DAV:acl XML element (specified in
1539 Section 5.4) of the request body. An ACL request body MUST
1540 contain only one DAV:acl XML element. Unless the non-inherited
1541 and non-protected ACEs of the DAV:acl property of the resource
1542 can be updated to be exactly the value specified in the ACL
1543 request, the ACL request MUST fail.
1545 It is possible that the ACEs visible to the current user in the
1546 DAV:acl property may only be a portion of the complete set of
1547 ACEs on that resource. If this is the case, an ACL request only
1548 modifies the set of ACEs visible to the current user, and does
1549 not affect any non-visible ACE.
1551 In order to avoid overwriting DAV:acl changes by another
1552 client, a client SHOULD acquire a WebDAV lock on the resource
1553 before retrieving the DAV:acl property of a resource that it
1554 intends on updating.
1556 Implementation Note: Two common operations are to add or
1557 remove an ACE from an existing access control list. To
1558 accomplish this, a client uses the PROPFIND method to
1559 retrieve the value of the DAV:acl property, then parses the
1560 returned access control list to remove all inherited and
1561 protected ACEs (these ACEs are tagged with the DAV:inherited
1562 and DAV:protected XML elements). In the remaining set of non-
1563 inherited, non-protected ACEs, the client can add or remove
1564 one or more ACEs before submitting the final ACE set in the
1565 request body of the ACL method.
1567 8.1.1 ACL Preconditions
1569 An implementation MAY enforce one or more of the following
1570 constraints on an ACL request. If the constraint is violated,
1571 a 403 (Forbidden) response MUST be returned and the indicated
1572 XML element MUST be returned as the top level element in an XML
1573 response body.
1575 : A conflict exists between two or more ACEs
1576 submitted in the ACL request.
1578 : A conflict exists between an ACE
1579 in the ACL request and a protected ACE on the resource. For
1580 example, if the resource has a protected ACE granting DAV:write
1581 to a given principal, then it would be a protected ACE conflict
1582 if the ACL request submitted an ACE denying DAV:write to the
1583 same principal.
1585 : A conflict exists between an ACE
1586 in the ACL request and an inherited ACE on the resource. For
1587 example, if the resource inherits an ACE from its parent
1588 collection granting DAV:write to a given principal, then it
1589 would be an inherited ACE conflict if the ACL request submitted
1590 an ACE denying DAV:write to the same principal. Note that
1591 reporting of this error will be implementation-dependent.
1593 Implementations have the choice to either report this error, or
1594 to allow the ACE to be set, and then let normal ACE evaluation
1595 rules determine whether the new ACE has any impact on the
1596 privileges available to a specific principal.
1598 : An implementation MAY limit the number of
1599 ACEs in an ACL. However, ACL-compliant servers MUST support at
1600 least one ACE granting privileges to a single principal, and
1601 one ACE granting privileges to a collection principal.
1603 : All non-inherited deny ACEs MUST
1604 precede all non-inherited grant ACEs.
1606 : For implementations that have
1607 the DAV:principal-only-one-ace constraint (defined in Section
1608 6.3.1), this XML element indicates that fulfilling the ACL
1609 request would result in multiple ACEs for one or more
1610 principals.
1612 : For implementations that have the DAV:grant-
1613 only constraint (defined in Section 6.3.2), this XML element
1614 indicates the request contained one or more deny ACEs.
1616 : One or more required principals (see
1617 Section 6.4) would not be present in the access control list
1618 after processing the ACL request. The DAV:required-principal
1619 XML element MUST contain a list of the missing principal(s),
1620 following the syntax specified in Section 6.4.
1622 8.1.2 Example: the ACL method
1624 In the following example, user "fielding", authenticated by
1625 information in the Authorization header, grants the principal
1626 identified by the URL http://www.foo.org/users/esedlar (i.e.,
1627 the user "esedlar") read and write privileges, grants the owner
1628 of the resource read-acl and write-acl privileges, and grants
1629 everyone read privileges.
1631 >> Request <<
1633 ACL /top/container/ HTTP/1.1
1634 Host: www.foo.org
1635 Content-Type: text/xml; charset="utf-8"
1636 Content-Length: xxxx
1637 Authorization: Digest username="fielding",
1638 realm="users@foo.org", nonce="...",
1639 uri="/top/container/", response="...", opaque="..."
1641
1642
1643
1644
1645 http://www.foo.org/users/esedlar
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1668 >> Response <<
1670 HTTP/1.1 200 OK
1672 8.1.3 Example: ACL method failure due to protected ACE conflict
1674 In the following request, user "fielding", authenticated by
1675 information in the Authorization header, attempts to deny the
1676 principal identified by the URL
1677 http://www.foo.org/users/esedlar (i.e., the user "esedlar")
1678 write privileges. Prior to the request, the DAV:acl property on
1679 the resource contained a protected ACE (see Section 5.4.3)
1680 granting DAV:owner the DAV:read and DAV:write privileges. The
1681 principal identified by URL http://www.foo.org/users/esedlar is
1682 the owner of the resource. The ACL method invocation fails
1683 because the submitted ACE conflicts with the protected ACE,
1684 thus violating the semantics of ACE protection.
1686 >> Request <<
1688 ACL /top/container/ HTTP/1.1
1689 Host: www.foo.org
1690 Content-Type: text/xml; charset="utf-8"
1691 Content-Length: xxxx
1692 Authorization: Digest username="fielding",
1693 realm="users@foo.org", nonce="...",
1694 uri="/top/container/", response="...", opaque="..."
1696
1697
1698
1699
1700 http://www.foo.org/users/esedlar
1701
1702
1703
1704
1705
1706
1708 >> Response <<
1710 HTTP/1.1 403 Forbidden
1711 Content-Type: text/xml; charset="utf-8"
1712 Content-Length: xxx
1714
1715
1717 8.1.4 Example: ACL method failure due to an inherited ACE conflict
1719 In the following request, user "ejw", authenticated by
1720 information in the Authorization header, tries to change the
1721 access control list on the resource
1722 http://www.foo.org/top/index.html. This resource has two
1723 inherited ACEs.
1725 Inherited ACE #1 grants the principal identified by URL
1726 http://www.foo.org/users/ejw (i.e., the user "ejw")
1727 http://www.foo.org/privs/write-all and DAV:read-acl privileges.
1728 On this server, http://www.foo.org/privs/write-all is an
1729 aggregate privilege containing DAV:write, and DAV:write-acl.
1731 Inherited ACE #2 grants principal DAV:all the DAV:read
1732 privilege.
1734 The request attempts to set a (non-inherited) ACE, denying the
1735 principal identified by the URL http://www.foo.org/users/ejw
1736 (i.e., the user �ejw�) DAV:write permission. This conflicts
1737 with inherited ACE #1. Note that the decision to report an
1738 inherited ACE conflict is specific to this server
1739 implementation. Another server implementation could have
1740 allowed the new ACE to be set, and then used normal ACE
1741 evaluation rules to determine whether the new ACE has any
1742 impact on the privileges available to a principal.
1744 >> Request <<
1746 ACL /top/index.html HTTP/1.1
1747 Host: www.foo.org
1748 Content-Type: text/xml; charset="utf-8"
1749 Content-Length: xxxx
1750 Authorization: Digest username="ejw",
1751 realm="users@foo.org", nonce="...",
1752 uri="/top/index.html", response="...", opaque="..."
1754
1755
1756
1757
1758 http://www.foo.org/users/ejw
1759
1760
1761
1762
1764 >> Response <<
1766 HTTP/1.1 403 Forbidden
1767 Content-Type: text/xml; charset="utf-8"
1768 Content-Length: xxx
1770
1771
1773 8.1.5 Example: ACL method failure due to an attempt to set grant and
1774 deny in a single ACE.
1776 In this example, user "ygoland", authenticated by information
1777 in the Authorization header, tries to change the access control
1778 list on the resource http://www.foo.org/diamond/engagement-
1779 ring.gif. The ACL request includes a single, syntactically and
1780 semantically incorrect ACE, which attempts to grant the
1781 collection principal identified by the URL
1782 http://www.foo.org/users/friends/ DAV:read privilege and deny
1783 the principal identified by URL
1784 http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-
1785 so") DAV:read privilege. However, it is illegal to have
1786 multiple principal elements, as well as both a grant and deny
1787 element in the same ACE, so the request fails due to poor
1788 syntax.
1790 >> Request <<
1792 ACL /diamond/engagement-ring.gif HTTP/1.1
1793 Host: www.foo.org
1794 Content-Type: text/xml; charset="utf-8"
1795 Content-Length: xxxx
1796 Authorization: Digest username="ygoland",
1797 realm="users@foo.org", nonce="...",
1798 uri="/diamond/engagement-ring.gif", response="...",
1799 opaque="..."
1801
1802
1803
1804
1805 http://www.foo.org/users/friends/
1806
1807
1808
1809 http://www.foo.org/users/ygoland-so
1810
1811
1812
1813
1815 >> Response <<
1817 HTTP/1.1 400 Bad Request
1818 Content-Length: 0
1820 Note that if the request had been divided into two ACEs, one to
1821 grant, and one to deny, the request would have been
1822 syntactically well formed.
1824 9 ACCESS CONTROL REPORTS
1826 9.1 REPORT Method
1828 A REPORT request is an extensible mechanism for obtaining
1829 information about a resource. Unlike a resource property,
1830 which has a single value, the value of a report can depend on
1831 additional information specified in the REPORT request body and
1832 in the REPORT request headers.
1834 Marshalling:
1836 The body of a REPORT request specifies which report is being
1837 requested, as well as any additional information that will be
1838 used to customize the report.
1840 The request MAY include a Depth header.
1842 The response body for a successful request MUST contain the
1843 requested report.
1845 If a Depth request header is included, the response MUST be a
1846 207 Multi-Status.
1848 Postconditions:
1850 The REPORT method MUST NOT change the content or dead
1851 properties of any resource.
1853 If a Depth request header is included, the request MUST be
1854 applied separately to the collection itself and to all members
1855 of the collection that satisfy the Depth value. The DAV:prop
1856 element of a DAV:response for a given resource MUST contain the
1857 requested report for that resource.
1859 9.2 DAV:acl-principal-props Report
1861 The DAV:acl-principle-props report returns, for all principals
1862 in the DAV:acl property that are identified by http(s) URLs,
1863 the value of the properties specified in the REPORT request
1864 body. In the case where a principal URL appears multiple times,
1865 the DAV:acl-principal-props report MUST return the properties
1866 for that principal only once.
1868 Marshalling
1870 The request body MUST be a DAV:acl-principal-props XML element.
1872
1873 ANY value: a sequence of one or more elements, with at most one
1874 DAV:prop element.
1875 prop: see RFC 2518, Section 12.11
1877 The response body for a successful request MUST be a
1878 DAV:multistatus XML element (i.e., the response uses the same
1879 format as the response for PROPFIND).
1881 multistatus: see RFC 2518, Section 12.9
1883 The response body for a successful DAV:acl-principal-props
1884 REPORT request MUST contain a DAV:response element for each
1885 principal identified by an http(s) URL listed in a
1886 DAV:principal XML element of an ACE within the DAV:acl property
1887 of the resource identified by the Request-URI.
1889 9.2.1 Example: DAV:acl-principal-props Report
1891 Resource http;//www.webdav.org/index.html has an ACL with three
1892 ACEs:
1894 ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
1895 current-user-privilege-set access.
1897 ACE #2: The principal identified by
1898 http://www.webdav.org/people/gstein (the user �gstein�) is
1899 granted DAV:write, DAV:write-acl, DAV:read-acl privileges.
1901 ACE #3: The collection principal identified by
1902 http://www.webdav.org/groups/authors/ (the �authors� group) is
1903 granted DAV:write and DAV:read-acl privileges.
1905 The following example shows a DAV:acl-principal-props report
1906 requesting the DAV:displayname property. It returns the value
1907 of DAV:displayname for resources
1908 http://www.webdav.org/people/gstein and
1909 http://www.webdav.org/groups/authors/ , but not for DAV:all,
1910 since this is not an http(s) URL.
1912 >> Request <<
1914 REPORT /index.html HTTP/1.1
1915 Host: www.webdav.org
1916 Content-Type: text/xml; charset="utf-8"
1917 Content-Length: xxxx
1919
1920
1921
1922
1923
1924
1926 >> Response <<
1928 HTTP/1.1 207 Multi-Status
1929 Content-Type: text/xml; charset="utf-8"
1930 Content-Length: xxxx
1932
1933
1934
1935 http://www.webdav.org/people/gstein
1936
1937
1938 Greg Stein
1939
1940 HTTP/1.1 200 OK
1941
1942
1943
1944 http://www.webdav.org/groups/authors/
1945
1946
1947 Site authors
1948
1949 HTTP/1.1 200 OK
1950
1951
1952
1954 9.3 DAV:principal-match REPORT
1956 The DAV:principal-match REPORT is used to identify all members
1957 of a collection that match the current user. In particular, if
1958 the collection contains principals, the report can be used to
1959 identify all members of the collection that match the current
1960 user. Alternatively, if the collection contains resources that
1961 have a property that identifies a principal (e.g. DAV:owner),
1962 then the report can be used to identify all members of the
1963 collection whose property identifies a principal that matches
1964 the current user. For example, this report can return all of
1965 the resources in a collection hierarchy that are owned by the
1966 current user.
1968 Marshalling:
1970 The request body MUST be a DAV:principal-match XML element.
1972
1973
1974 ANY value: an element whose value identifies a property. The
1975 expectation is the value of the named property typically
1976 contains an href element that contains the URI of a principal
1977
1978 prop: see RFC 2518, Section 12.11
1980 The response body for a successful request MUST be a
1981 DAV:multistatus XML element.
1983 multistatus: see RFC 2518, Section 12.9
1985 The response body for a successful DAV:principal-match REPORT
1986 request MUST contain a DAV:response element for each member of
1987 the collection that matches the current user. When the
1988 DAV:principal-property element is used, a match occurs if the
1989 current user is the same as the principal identified by the URI
1990 found in the DAV:href element of the property identified by the
1991 DAV:principal-property element. When the DAV:self element is
1992 used in a DAV:principal-match report issued against a
1993 collection principal, it matches a child of the collection
1994 principal if that child (a principal resource) identifies the
1995 same principal as the current user.
1997 If DAV:prop is specified in the request body, the properties
1998 specified in the DAV:prop element MUST be reported in the
1999 DAV:response elements.
2001 9.3.1 Example: DAV:principal-match REPORT
2003 The following example identifies the members of the collection
2004 identified by the URL http://www.webdav.org/doc/ that are owned
2005 by the current user. The current user (�gclemm�) is
2006 authenticated using Digest authentication.
2008 >> Request <<
2010 REPORT /doc/ HTTP/1.1
2011 Host: www.webdav.org
2012 Authorization: Digest username="gclemm",
2013 realm="gclemm@webdav.org", nonce="...",
2014 uri="/papers/", response="...", opaque="..."
2015 Content-Type: text/xml; charset="utf-8"
2016 Content-Length: xxxx
2017
2018
2019
2020
2021
2022
2024 >> Response <<
2026 HTTP/1.1 207 Multi-Status
2027 Content-Type: text/xml; charset="utf-8"
2028 Content-Length: xxxx
2030
2031
2032
2033 http://www.webdav.org/doc/foo.html
2034 HTTP/1.1 200 OK
2035
2036
2037 http://www.webdav.org/doc/img/bar.gif
2038 HTTP/1.1 200 OK
2039
2040
2042 10 XML PROCESSING
2044 Implementations of this specification MUST support the XML
2045 element ignore rule, as specified in Section 23.3.2 of
2046 [RFC2518], and the WebDAV XML Namespace interpretation
2047 convention, described in Section 23.4 of [RFC2518].
2049 11 INTERNATIONALIZATION CONSIDERATIONS
2051 In this specification, the only human-readable content can be
2052 found in the description XML element, found within the
2053 DAV:supported-privilege-set property. This element contains a
2054 human-readable description of the capabilities controlled by a
2055 privilege. As a result, the description element must be
2056 capable of representing descriptions in multiple character
2057 sets. Since the description element is found within a WebDAV
2058 property, it is represented on-the-wire as XML [REC-XML], and
2059 hence can leverage XML's language tagging and character set
2060 encoding capabilities. Specifically, XML processors must, at
2061 minimum, be able to read XML elements encoded using the UTF-8
2062 [UTF-8] encoding of the ISO 10646 multilingual plane. XML
2063 examples in this specification demonstrate use of the charset
2064 parameter of the Content-Type header, as defined in [RFC3023],
2065 as well as the XML "encoding" attribute, which together provide
2066 charset identification information for MIME and XML processors.
2068 For XML elements other than the description element, it is
2069 expected that implementations will treat the property names,
2070 privilege names, and values as tokens, and convert these tokens
2071 into human-readable text in the user's language and character
2072 set when displayed to a person. Only a generic WebDAV property
2073 display utility would display these values in their raw form to
2074 a human user.
2076 For error reporting, we follow the convention of HTTP/1.1
2077 status codes, including with each status code a short, English
2078 description of the code (e.g., 200 (OK)). While the
2079 possibility exists that a poorly crafted user agent would
2080 display this message to a user, internationalized applications
2081 will ignore this message, and display an appropriate message in
2082 the user's language and character set.
2084 Further internationalization considerations for this protocol
2085 are described in the WebDAV Distributed Authoring protocol
2086 specification [RFC2518].
2088 12 SECURITY CONSIDERATIONS
2090 Applications and users of this access control protocol should
2091 be aware of several security considerations, detailed below. In
2092 addition to the discussion in this document, the security
2093 considerations detailed in the HTTP/1.1 specification
2094 [RFC2616], the WebDAV Distributed Authoring Protocol
2095 specification [RFC2518], and the XML Media Types specification
2096 [RFC3023] should be considered in a security analysis of this
2097 protocol.
2099 12.1 Increased Risk of Compromised Users
2101 In the absence of a mechanism for remotely manipulating access
2102 control lists, if a single user's authentication credentials
2103 are compromised, only those resources for which the user has
2104 access permission can be read, modified, moved, or deleted.
2105 With the introduction of this access control protocol, if a
2106 single compromised user has the ability to change ACLs for a
2107 broad range of other users (e.g., a super-user), the number of
2108 resources that could be altered by a single compromised user
2109 increases. This risk can be mitigated by limiting the number of
2110 people who have write-acl privileges across a broad range of
2111 resources.
2113 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
2114 Privileges
2116 The ability to read the access privileges (stored in the
2117 DAV:acl property), or the privileges permitted the currently
2118 authenticated user (stored in the DAV:current-user-privilege-
2119 set property) on a resource may seem innocuous, since reading
2120 an ACL cannot possibly affect the resource's state. However, if
2121 all resources have world-readable ACLs, it is possible to
2122 perform an exhaustive search for those resources that have
2123 inadvertently left themselves in a vulnerable state, such as
2124 being world-writeable. In particular, the property retrieval
2125 method PROPFIND, executed with Depth infinity on an entire
2126 hierarchy, is a very efficient way to retrieve the DAV:acl or
2127 DAV:current-user-privilege-set properties. Once found, this
2128 vulnerability can be exploited by a denial of service attack in
2129 which the open resource is repeatedly overwritten. Alternately,
2130 writeable resources can be modified in undesirable ways.
2132 To reduce this risk, read-acl privileges should not be granted
2133 to unauthenticated principals, and restrictions on read-acl and
2134 cuprivset privileges for authenticated principals should be
2135 carefully analyzed when deploying this protocol. Access to the
2136 current-user-privilege-set property will involve a tradeoff of
2137 usability versus security. When the current-user-privilege-set
2138 is visible, user interfaces are expected to provide enhanced
2139 information concerning permitted and restricted operations, yet
2140 this information may also indicate a vulnerability that could
2141 be exploited. Deployment of this protocol will need to evaluate
2142 this tradeoff in light of the requirements of the deployment
2143 environment.
2145 12.3 No Foreknowledge of Initial ACL
2147 In an effort to reduce protocol complexity, this protocol
2148 specification intentionally does not address the issue of how
2149 to manage or discover the initial ACL that is placed upon a
2150 resource when it is created. The only way to discover the
2151 initial ACL is to create a new resource, then retrieve the
2152 value of the DAV:acl property. This assumes the principal
2153 creating the resource also has been granted the DAV:read-acl
2154 privilege.
2156 As a result, it is possible that a principal could create a
2157 resource, and then discover that its ACL grants privileges that
2158 are undesirable. Furthermore, this protocol makes it possible
2159 (though unlikely) that the creating principal could be unable
2160 to modify the ACL, or even delete the resource. Even when the
2161 ACL can be modified, there will be a short period of time when
2162 the resource exists with the initial ACL before its new ACL can
2163 be set.
2165 Several factors mitigate this risk. Human principals are often
2166 aware of the default access permissions in their editing
2167 environments and take this into account when writing
2168 information. Furthermore, default privilege policies are
2169 usually very conservative, limiting the privileges granted by
2170 the initial ACL.
2172 13 AUTHENTICATION
2174 Authentication mechanisms defined in WebDAV also apply to this
2175 WebDAV Access Control Protocol, in particular the Basic and
2176 Digest authentication mechanisms defined in [RFC2617].
2178 14 IANA CONSIDERATIONS
2180 This document uses the namespace defined by [RFC2518] for XML
2181 elements. All other IANA considerations mentioned in [RFC2518]
2182 also applicable to WebDAV ACL.
2184 15 INTELLECTUAL PROPERTY
2186 The following notice is copied from RFC 2026, section 10.4, and
2187 describes the position of the IETF concerning intellectual
2188 property claims made against this document.
2190 The IETF takes no position regarding the validity or scope of
2191 any intellectual property or other rights that might be claimed
2192 to pertain to the implementation or use other technology
2193 described in this document or the extent to which any license
2194 under such rights might or might not be available; neither does
2195 it represent that it has made any effort to identify any such
2196 rights. Information on the IETF's procedures with respect to
2197 rights in standards-track and standards-related documentation
2198 can be found in BCP-11. Copies of claims of rights made
2199 available for publication and any assurances of licenses to be
2200 made available, or the result of an attempt made to obtain a
2201 general license or permission for the use of such proprietary
2202 rights by implementers or users of this specification can be
2203 obtained from the IETF Secretariat.
2205 The IETF invites any interested party to bring to its attention
2206 any copyrights, patents or patent applications, or other
2207 proprietary rights that may cover technology that may be
2208 required to practice this standard. Please address the
2209 information to the IETF Executive Director.
2211 16 ACKNOWLEDGEMENTS
2213 This protocol is the collaborative product of the WebDAV ACL
2214 design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry
2215 Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim
2216 Whitehead. The authors are grateful for the detailed review and
2217 comments provided by Jim Amsden, Gino Basso, Murthy
2218 Chintalapati, Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris
2219 Knight, Remy Maucherat, Larry Masinter, Yaron Goland, Lisa
2220 Dusseault, and Joe Orton. Prior work on WebDAV access control
2221 protocols has been performed by Yaron Goland, Paul Leach, Lisa
2222 Dusseault, Howard Palmer, and Jon Radoff. We would like to
2223 acknowledge the foundation laid for us by the authors of the
2224 WebDAV and HTTP protocols upon which this protocol is layered,
2225 and the invaluable feedback from the WebDAV working group.
2227 17 REFERENCES
2229 17.1 Normative References
2231 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
2232 Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997.
2234 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible
2235 Markup Language (XML)." World Wide Web Consortium
2236 Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
2237 19980210.
2239 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
2240 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
2241 Protocol -- HTTP/1.1." RFC 2616. U.C. Irvine, Compaq, Xerox,
2242 Microsoft, MIT/LCS, June, 1999.
2244 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S.
2245 Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP
2246 Authentication: Basic and Digest Access Authentication." RFC
2247 2617. Northwestern University, Verisign, AbiSource, Agranat,
2248 Microsoft, Netscape, Open Market, June, 1999.
2250 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
2251 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV."
2252 RFC 2518. Microsoft, U.C. Irvine, Netscape, Novell, February,
2253 1999.
2255 [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
2256 scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape,
2257 July, 1998.
2259 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
2260 Netscape, December, 1997.
2262 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types."
2263 RFC 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon
2264 Ventures, January, 2001.
2266 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
2267 and ISO 10646." RFC 2279. Alis Technologies. January, 1998.
2269 17.2 Informational References
2271 [RFC2026] S.Bradner, "The Internet Standards Process � Revision
2272 3." RFC 2026, BCP 9. Harvard, October, 1996.
2274 18 AUTHORS' ADDRESSES
2276 Geoffrey Clemm
2277 Rational Software
2278 20 Maguire Road
2279 Lexington, MA 02421
2280 Email: geoffrey.clemm@rational.com
2281 Anne Hopkins
2282 Microsoft Corporation
2283 One Microsoft Way
2284 Redmond, WA 98052
2285 Email: annehop@microsoft.com
2287 Eric Sedlar
2288 Oracle Corporation
2289 500 Oracle Parkway
2290 Redwood Shores, CA 94065
2291 Email: esedlar@us.oracle.com
2293 Jim Whitehead
2294 U.C. Santa Cruz
2295 Dept. of Computer Science
2296 Baskin Engineering
2297 1156 High Street
2298 Santa Cruz, CA 95064
2299 Email: ejw@cse.ucsc.edu
2301 19 APPENDICIES
2303 19.1 XML Document Type Definition
2305
2307
2308
2309
2310
2311
2312
2314
2316
2318
2320
2322
2324
2325
2327
2329
2330
2332
2333
2334
2335
2337
2339
2341
2343
2345
2347
2351
2352
2353
2354
2355
2356
2358
2359
2360
2362
2364
2366
2368
2370
2372
2373
2376
2379
2380
2381
2383
2384
2386
2387
2388
2390
2394
2396
2397
2398
2399
2401
2403
2404 ANY value: a sequence of one or more elements, with at most one
2405 DAV:prop element.
2406
2407
2408 ANY value: an element whose value identifies a property. The
2409 expectation is the value of the named property typically
2410 contains an href element that contains the URI of a principal
2411
2413 20 NOTE TO RFC EDITOR
2415 *** This section (Section 20) MUST be removed before
2416 publication as an RFC ***
2418 Section 9.1 defines the REPORT method. The REPORT method is
2419 also defined in draft-ietf-deltav-versioning-15, in Section
2420 3.6, using identical text. This was done to avoid making this
2421 specification dependent on draft-ietf-deltav-versioning.
2423 If draft-ietf-deltav-versioning is published as an RFC before
2424 this specification, Section 9.1 MUST be removed.