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.