view Side-By-Side changes

   draft-ietf-webdav-acl-06 
draft-ietf-webdav-acl-07          Anne Hopkins, Microsoft Corporation 
                                  Eric Sedlar, Oracle Corporation 
                                  Jim Whitehead, U.C. Santa Cruz 
                                   
Expires December 21, May 9, 2001        June 21,               November 9, 2001 

                     WebDAV Access Control Protocol 

Status of this Memo 

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC2026. 

Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and its working groups. Note that other groups 
may also distribute working documents as Internet-
   Drafts. Internet-Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet- Drafts as reference material 
or to cite them other than as "work in progress." 

The list of current Internet-Drafts can be accessed at 
http://www.ietf.org/ietf/1id-abstracts.txt 

The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html. 


Abstract 

This document specifies a set of methods, headers, and message bodies 
that define Access Control extensions to the WebDAV Distributed 
Authoring Protocol. This protocol permits a client to 
   remotely read and modify 
access control lists that instruct a server whether to grant allow or deny 
operations upon a resource (such as HTTP method invocations) by a given 
principal. 

This document is a product of the Web Distributed Authoring and 
Versioning (WebDAV) working group of the Internet Engineering Task 
Force. Comments on this draft are welcomed, and should be addressed to 
the acl@webdav.org mailing list. Other related documents can be found at
http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/.












Clemm, Hopkins, Sedlar, Whitehead                             [Page 1] 

INTERNET-DRAFT                WebDAV ACL               June 21,            November 9, 2001 

Table of Contents 

1 INTRODUCTION...................................................4 INTRODUCTION.......................................................5 
1.1  Terms.......................................................5 Terms............................................................7 
1.2 Notational Conventions......................................6 Conventions...........................................8 

2 PRINCIPALS.....................................................6 PRINCIPALS.........................................................8 

3 PRIVILEGES.....................................................7 PRIVILEGES.........................................................9 
3.1 DAV:read Privilege..........................................8 Privilege..............................................11 
3.2 DAV:write Privilege.........................................8 Privilege.............................................11 
3.3 DAV:read-acl Privilege......................................9 Privilege..........................................11 
3.4 DAV:read-current-user-privilege-set Privilege...............9 Privilege...................11 
3.5 DAV:write-acl Privilege.....................................9 Privilege.........................................12 
3.6 DAV:all Privilege...........................................9 Privilege...............................................12 
3.7 Aggregation of Predefined Privileges........................9 Privileges............................12 

4 PRINCIPAL PROPERTIES..........................................10 PROPERTIES..............................................12 
4.1  DAV:alternate-URL..........................................10 DAV:alternate-URI-set...........................................13 

5 ACCESS CONTROL PROPERTIES.....................................10 PROPERTIES.........................................13 
5.1  DAV:owner..................................................11 DAV:owner.......................................................13 
 5.1.1 Example: Retrieving DAV:owner............................11 DAV:owner................................14 
 5.1.2 Example: An Attempt to Set DAV:owner.....................12 DAV:owner.........................15 
5.2  DAV:supported-privilege-set................................13 DAV:supported-privilege-set.....................................16 
 5.2.1 Example: Retrieving a List of Privileges Supported on a 
          Resource.................................................14 
       Resource.....................................................16 
5.3  DAV:current-user-privilege-set.............................15 DAV:current-user-privilege-set..................................18 
 5.3.1 Example: Retrieving the User's Current Set of Assigned 
          Privileges...............................................16 
 Privileges.........................................................19 
5.4  DAV:acl....................................................17 DAV:acl.........................................................20 
 5.4.1 ACE Principal............................................17 Principal................................................20 
 5.4.2 ACE Grant and Deny.......................................18 Deny...........................................21 
 5.4.3 ACE Protection...........................................18 Protection...............................................21 
 5.4.4 ACE Inheritance..........................................18 Inheritance..............................................22 
 5.4.5 Example: Retrieving a Resource's Access Control List.....19 List......22 
5.5  DAV:acl-semantics..........................................20 DAV:acl-semantics...............................................23 
 5.5.1 Example: Retrieving DAV:acl-semantics....................21 DAV:acl-semantics........................24 
5.6  DAV:principal-collection-set...............................22 DAV:principal-collection-set....................................25 
 5.6.1 Example: Retrieving DAV:principal-collection-set.........22 DAV:principal-collection-set.............26 
5.7 Example: PROPFIND to retrieve access control properties....23 properties.........27 

6 ACL SEMANTICS.................................................27 SEMANTICS.....................................................30 
6.1 ACE Combination............................................27 Combination.................................................31 
 6.1.1 DAV:first-match ACE Combination..........................27 Combination..............................31 
 6.1.2 DAV:all-grant-before-any-deny ACE Combination............27 Combination................31 
 6.1.3 DAV:specific-deny-overrides-grant ACE Combination........27 Combination............31 
6.2 ACE Ordering...............................................28 Ordering....................................................31 
 6.2.1 DAV:deny-before-grant ACE Ordering.......................28 Ordering...........................32 
6.3 Allowed ACE................................................28 ACE.....................................................32 
 6.3.1 DAV:principal-only-one-ace ACE Constraint................28 
    6.3.2 DAV:grant-only ACE Constraint............................28 
   6.4  Required Principals........................................28 Constraint....................32 

Clemm, Hopkins, Sedlar, Whitehead                           [Page 2] 

INTERNET-DRAFT                WebDAV ACL              June 21,            November 9, 2001 

 6.3.2 DAV:grant-only ACE Constraint................................32 
6.4 Required Principals.............................................32 

7 ACCESS CONTROL AND EXISTING METHODS...........................29 METHODS...............................32 
7.1  OPTIONS....................................................29 OPTIONS.........................................................33 
 7.1.1 Example - OPTIONS........................................29 OPTIONS............................................33 
7.2  MOVE.......................................................29 MOVE............................................................33 
7.3  COPY.......................................................29 COPY............................................................33 
7.4 DELETE..........................................................33 
7.5 LOCK............................................................34 

8 ACCESS CONTROL METHODS........................................29 METHODS............................................34 
8.1  ACL........................................................29 ACL.............................................................34 
 8.1.1 ACL Preconditions........................................30 Preconditions............................................34 
 8.1.2 Example: the ACL method..................................31 method......................................36 
 8.1.3 Example: ACL method failure due to protected ACE 
          conflict ................................................32 conflict....37 
 8.1.4 Example: ACL method failure due to an inherited ACE conflict ................................................33 38 
 8.1.5 Example: ACL method failure due to an attempt to set grant 
       and deny in a single ACE ..........................34 ACE.....................................39 

9 ACCESS CONTROL REPORTS........................................35 REPORTS............................................40 
9.1 REPORT Method..............................................35 Method...................................................40 
9.2 DAV:acl-principal-props Report.............................36 Report..................................40 
 9.2.1 Example: DAV:acl-principal-props Report..................36 Report......................40 
9.3 DAV:principal-match REPORT.................................37 REPORT......................................42 
 9.3.1 Example: DAV:principal-match REPORT......................38 REPORT..........................43 
9.4 DAV:principal-property-search REPORT............................44 
 9.4.1 Matching.....................................................45 
 9.4.2 Example: successful DAV:principal-property-search REPORT.....46 
 9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT...48 
9.5 DAV:principal-search-property-set REPORT........................49 
 9.5.1 Example: DAV:principal-search-property-set REPORT............50 

10  XML PROCESSING..............................................39 PROCESSING..................................................51 

11  INTERNATIONALIZATION CONSIDERATIONS.........................39 CONSIDERATIONS.............................51 

12  SECURITY CONSIDERATIONS.....................................40 CONSIDERATIONS.........................................52 
12.1  Increased Risk of Compromised Users........................40 Users...........................52 
12.2  Risks of the DAV:read-acl and DAV:current-user-privilege-set 
        Privileges.................................................40 
      Privileges....................................................52 
12.3  No Foreknowledge of Initial ACL............................41 ACL...............................53 

13  AUTHENTICATION..............................................41  AUTHENTICATION..................................................53 

14  IANA CONSIDERATIONS.........................................42 CONSIDERATIONS.............................................53 

15  INTELLECTUAL PROPERTY.......................................42 PROPERTY...........................................54 

16  ACKNOWLEDGEMENTS............................................42  ACKNOWLEDGEMENTS................................................54 

Clemm, Hopkins, Sedlar, Whitehead                           [Page 3] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

17  REFERENCES..................................................43  REFERENCES......................................................55 
17.1  Normative References.......................................43 References..........................................55 
17.2  Informational References...................................43 References......................................56 

18  AUTHORS' ADDRESSES..........................................43 ADDRESSES..............................................56 

19  APPENDICIES.................................................44  APPENDICIES.....................................................57 
19.1  XML Document Type Definition...............................44 Definition..................................57 

20  NOTE TO RFC EDITOR..........................................46 EDITOR..............................................59 
  








































Clemm, Hopkins, Sedlar, Whitehead                           [Page 3] 4] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


1  INTRODUCTION 

   The goal of the WebDAV access control extensions is to provide an 
   interoperable mechanism for handling discretionary access control for
   content in and metadata managed by WebDAV servers.  WebDAV access 
   control can be implemented on content repositories with security as 
   simple as that of a UNIX file system, as well as more sophisticated 
   models.  The underlying principle of access control is that who you 
   are determines how what operations you can access perform on a resource. The 
   "who you are" is defined by a "principal" identifier; users, client 
   software, servers, and groups of the previous have principal 
   identifiers. The "how" "operations you can perform" is determined by a 
   single "access control list" (ACL) associated with a resource.  An 
   ACL contains a set of "access control entries" (ACEs), where each ACE
   specifies a principal and a set of privileges that are either granted
   or denied to that principal. When a principal submits an operation 
   (such as an HTTP or WebDAV method) to a resource for execution, the 
   server evaluates the ACEs in the ACL to determine if the principal 
   has permission for that operation. 

        This specification intentionally omits discussion of 
        authentication, as 

   Since every ACE contains the HTTP protocol already has a number identifier of 
        authentication mechanisms [RFC2617].  Some authentication a principal, client 
   software operated by a human must provide a mechanism (such as HTTP Digest Authentication, for selecting 
   this principal. This specification uses http(s) scheme URLs to 
   identify principals, which all WebDAV 
        compliant implementations are required to support) must represented as WebDAV-capable 
   resources. There is no guarantee that the URLs identifying principals
   will be 
        available meaningful to validate the identity of a principal.  

        The following issues human. For example, 
   http://www.dav.org/u/256432 and http://www.dav.org/people/Greg.Stein 
   are out of scope for this document: 

          * Access control both valid URLs that applies only could be used to a particular property 
            on a identify the same 
   principal. To remedy this, every principal resource (excepting has the access control properties 
            DAV:acl and DAV:current-user-privilege-set), rather than 
   DAV:displayname property containing a human-readable name for the entire resource, 

          * Role-based security (where 
   principal. 

   Since a role principal can be seen as a 
            dynamically defined collection of principals), 

          * Specification of identified by multiple URLs, it raises the ways an ACL on 
   problem of determining exactly which principal's operations are being
   described in a resource given ACE. It is 
            initialized, 

          * Specification of an ACL that applies globally impossible for a client to all 
            resources , rather than determine 
   that an ACE granting the read privilege to 
   http://www.dav.org/people/Greg.Stein also affects the principal at 
   http://www.dav.org/u/256432. That is, a particular resource. 

          * Creation and maintenance of resources representing people 
            or computational agents (principals), and groups of these. 

        This client has no mechanism for 
   determining that two URLs identify the same principal resource.  As a
   result, this specification requires clients to use just one of the 
   many possible URLs for a principal when creating ACEs. A client can 
   discover this URL by retrieving the DAV:principal-URL property 
   (Section 4.2) from a principal resource. No matter which of the 
   principal's URLs is organized as follows. Section 1.1 defines 
        key concepts used throughout with PROPFIND, the specification, and is followed 
        by more in-depth discussion property always returns 
   the same URL. 

   Once a system has hundreds to thousands of principals (Section 2), and 
        privileges (Section 3). Properties defined on principals are 
        specified in Section 4, and access control properties for 
        content resources are specified in Section 5. The semantics principals, the problem 
   arises of 
        access control lists are described in Section 6, including 
        sections on ACE combination (Section 6.1), ACE ordering how to allow a human operator of client software to select 
   just one of these principals. One approach is to use broad collection

Clemm, Hopkins, Sedlar, Whitehead                           [Page 4] 5] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        (Section 6.2), and principals required 

   hierarchies to be present in an ACE 
        (Section 6.4). Client discovery spread the principals over a large number of access control capability 
        using OPTIONS 
   collections, yielding few principals per collection. An example of 
   this is described in Section 7.1, a two level hierarchy with the first level containing 36 
   collections (a-z, 0-9), and the access 
        control setting method, ACL, second level being another 36, 
   creating collections /a/a/, /a/b/, à, /a/z/, such that a principal 
   with last name "Stein" would appear at /s/t/Stein. In effect, this 
   pre-computes a common query, search on last name, and encodes it into
   a hierarchy. The drawback with this scheme is specified in Section 8. 
        Internationalization considerations (Section 11) that it handles only a 
   small set of predefined queries, and security 
        considerations (Section 12) round out drilling down through the specification. An 
        appendix (Section 19.1) provides an XML Document Type 
        Definition (DTD) for 
   collection hierarchy adds unnecessary steps (navigate down/up) when 
   the XML elements defined in user already knows the 
        specification. 

   1.1 Terms principal's name. While organizing 
   principal URLs into a hierarchy is a valid namespace organization, 
   users should not be forced to navigate this hierarchy to select a 
   principal. 

   This draft uses specification provides the terms defined in HTTP [RFC2616] and WebDAV 
        [RFC2518].  In addition, capability to perform substring 
   searches on a small set of properties on the following terms resources representing 
   principals. This permits searches based on last name, first name, 
   user name, job title, etc. Two separate searches are defined: supported, via 
   the REPORT method, one to search principal 

        A "principal" is a distinct human or computational actor that 
        initiates access resources, the other to network resources.  In this protocol, 
   determine which properties may be searched at all.  

   Once a principal is has been identified in an HTTP resource ACE, a server evaluating 
   that represents such an actor. ACE must know the identity of the principal collection 

        A "principal collection" is making a group of principals, and is 
        represented in this protocol by a WebDAV collection containing 
        HTTP resources that represent principals, 
   request, and must validate that that principal 
        collections. 

      privilege 

        A "privilege" controls access is who they claim to 
   be, a particular set process known as authentication. This specification 
   intentionally omits discussion of authentication, as the HTTP 
        operations on a resource. 

      aggregate privilege 

        An "aggregate privilege" is a privilege that contains 
   protocol already has a set number of 
        other privileges. 

      abstract privilege 

        The modifier "abstract", when applied authentication mechanisms [RFC2617].
   Some authentication mechanism (such as HTTP Digest Authentication, 
   which all WebDAV compliant implementations are required to a privilege, means the 
        privilege cannot support) 
   must be set in an access control element (ace).  

      access control list (ACL) 

        An "ACL" is available to validate the identity of a list principal.  

   The following issues are out of access scope for this document: 

        * Access control elements that define 
        access control applies only to a particular resource. property on a
          resource (excepting the access control element (ace) 

        An "ace" either grants or denies properties DAV:acl and 
          DAV:current-user-privilege-set), rather than the entire 
          resource, 

        * Role-based security (where a particular set role can be seen as a dynamically
          defined collection of (non-
        abstract) privileges for principals), 

        * Specification of the ways an ACL on a resource is initialized,

        * Specification of an ACL that applies globally to all 
          resources, rather than to a particular principal. resource. 

        * Creation and maintenance of resources representing people or 
          computational agents (principals), and groups of these. 

   This specification is organized as follows. Section 1.1 defines key 
   concepts used throughout the specification, and is followed by a more

Clemm, Hopkins, Sedlar, Whitehead                           [Page 5] 6] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 

      inherited ace 

        An "inherited ace" is an ace that is dynamically shared from 
        the ACL 

   in-depth discussion of another resource. When a shared ACE changes on the 
        primary resource, it is also changed on inheriting resources. 

      protected property 

        A "protected property" is one whose value cannot be updated 
        except by a method explicitly principals (Section 2), and privileges 
   (Section 3). Properties defined as updating that specific 
        property.  In particular, a protected property cannot be 
        updated with a PROPPATCH request.  

   1.2 Notational Conventions 

        The augmented BNF used by this document to describe protocol 
        elements is described on principals are specified in 
   Section 2.1 of [RFC2616]. Because this 
        augmented BNF uses the basic production rules provided 4, and access control properties for content resources are 
   specified in Section 2.2 of [RFC2616], those rules apply to this document as 
        well. 5. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
        "OPTIONAL" in this document semantics of access control lists are 
   described in Section 6, including sections on ACE combination 
   (Section 6.1), ACE ordering (Section 6.2), and principals required to
   be interpreted as present in an ACE (Section 6.4). Client discovery of access 
   control capability using OPTIONS is described in [RFC2119]. 

        Definitions Section 7.1. 
   Interactions between access control functionality and existing HTTP 
   and WebDAV methods are described in the remainder of XML elements Section 7. The 
   access control setting method, ACL, is specified in this document use XML element 
        type declarations (as found Section 8. Four 
   reports that provide limited server-side searching capabilities are 
   described in Section 9. A note on XML processing (Section 10), 
   Internationalization considerations (Section 11), security 
   considerations (Section 12), and a note on authentication (Section 
   13) round out the specification. An appendix (Section 19.1) provides 
   an XML Document Type Declarations), 
        described Definition (DTD) for the XML elements defined in Section 3.2 of [REC-XML]. 

   2  PRINCIPALS 

        A
   the specification. 

1.1 Terms 

   This draft uses the terms defined in HTTP [RFC2616] and WebDAV 
   [RFC2518].  In addition, the following terms are defined: 

   principal 

     A "principal" is a network resource that represents a distinct human or computational actor that 
     initiates access to network resources. On many implementations, users and groups are 
        represented as principals; other types of principals are also 
        possible. A URI of any scheme MAY be used to identify a 
        principal resource. However, servers implementing  In this 
        specification MUST expose protocol, a 
     principal resources at an http(s) 
        URL, which is a privileged scheme that points to resources an HTTP resource that 
        have additional properties, as described in Section 4. So, a represents such an actor. 

   principal resource can have multiple URI identifiers, one of 
        which has to be an http(s) scheme URL. Although an 
        implementation SHOULD support PROPFIND and MAY support 
        PROPPATCH to access and modify information about a principal, 
        it is not required to do so. collection 

     A principal resource may or may not be a collection.  If a 
        person or computational agent matches "principal collection" is a principal resource that group of principals, and is contained 
     represented in this protocol by a WebDAV collection principal, they also match the 
        collection principal. This definition is recursive, containing HTTP
     resources that represent principals, and hence 
        if a person or computational agent matches a collection principal that is the child collections. 

   privilege 

     A "privilege" controls access to a particular set of another collection principal, 
        they also match the parent collection principal. Membership in HTTP 
     operations on a collection principal resource. 

   aggregate privilege 

     An "aggregate privilege" is also recursive, so a principal in privilege that contains a 
        collection principal GRPA contained by collection principal set of 
     other privileges. 

   abstract privilege 

     The modifier "abstract", when applied to a privilege, means the 
     privilege cannot be set in an access control element (ACE).  

   access control list (ACL) 

Clemm, Hopkins, Sedlar, Whitehead                           [Page 6] 7] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        GRPB 

     An "ACL" is a member list of both GRPA and GRPB. Implementations not 
        supporting recursive membership in principal collections can 
        return an error if the client attempts to bind collection 
        principals into other collection principals. 

        Servers access control elements that support aggregation of principals (e.g. groups of 
        users define access 
     control to a particular resource. 

   access control element (ACE) 

     An "ACE" either grants or other groups) MUST manifest them as collection 
        principals. At minimum, principals and collection principals 
        MUST support the OPTIONS and PROPFIND methods.  

           Implementer's Note: Collection principals are first and 
           foremost WebDAV collections. Therefore they contain 
           resources as members. Since there denies a particular set of (non-abstract)
     privileges for a particular principal. 

   inherited ACE 

     An "inherited ACE" is no requirement an ACE that all 
           members is dynamically shared from the 
     ACL of another resource. When a collection principal need be principals, shared ACE changes on the primary 
     resource, it is 
           possible for also changed on inheriting resources. 

   protected property 

    A "protected property" is one whose value cannot be updated except 
    by a collection principal to have non-principals method explicitly defined as members. When enumerating the principals-only membership 
           of updating that specific property.  
    In particular, a collection principal, it is necessary protected property cannot be updated with a 
    PROPPATCH request.  

1.2 Notational Conventions 

   The augmented BNF used by this document to retrieve describe protocol elements
   is described in Section 2.1 of [RFC2616]. Because this augmented BNF 
   uses the 
           DAV:resourcetype property basic production rules provided in Section 2.2 of [RFC2616],
   those rules apply to this document as well. 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and check it for the DAV:principal "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 

   Definitions of XML elements in this document use XML element (described type 
   declarations (as found in XML Document Type Declarations), described 
   in Section 4). If the DAV:principal 3.2 of [REC-XML]. When an XML element is not present, type in the resource "DAV:" 
   namespace is not a principal 
           and may be ignored for the purposes referenced in this document outside of determining the 
           principals-only membership context of an
   XML fragment, the collection principal. 

           For example, string "DAV:" will be prefixed to the collection element type.


2  PRINCIPALS 

   A principal /FOO/ has two members, 
           Bar and Baz. Bar is a principal but Baz is not. Therefore 
           when determining which network resource that represents a distinct human or
   computational actor that initiates access to network resources. Users
   and groups are represented as principals belong in many implementations; 
   other types of principals are also possible. A URI of any scheme MAY 
   be used to the collection 
           principal /FOO/, identify a client would enumerate the membership 
           using PROPFIND while asking for the DAV:resourcetype 
           property, and see that only Bar has the DAV:principal XML 
           element. Therefore, only Bar is the only principal that resource. However, servers 
   implementing this specification MUST expose principal resources at an
   http(s) URL, which is a 
           member of the collection principal /FOO/. 

   3  PRIVILEGES 

        Ability privileged scheme that points to perform a given method on resources 
   that have additional properties, as described in Section 4. So, a 
   principal resource SHOULD be 
        controlled by can have multiple URIs, one or more privileges.  Authors of protocol 
        extensions that define new HTTP methods SHOULD specify which 
        privileges (by defining new privileges, or mapping has to ones 
        below) are be an 
   http(s) scheme URL. Although an implementation SHOULD support 

Clemm, Hopkins, Sedlar, Whitehead                           [Page 8] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   PROPFIND and MAY support PROPPATCH to access and modify information 
   about a principal, it is not required to perform the method. do so.   

   A principal with no 
        privileges to a resource SHOULD be denied any HTTP access to 
        that resource. 

        Privileges may or may not be containers of other privileges, in which case 
        they are termed aggregate privileges. a collection.  If a principal is 
        granted person or denied an aggregate privilege, it 
   computational agent matches a principal resource that is semantically 
        equivalent to granting or denying each of contained by
   a collection principal, they also match the aggregated 
        privileges individually.  For example, an implementation may 
        define add-member collection principal. 
   This definition is recursive, and remove-member privileges hence if a person or computational 
   agent matches a collection principal that control is the 
        ability to add and remove an internal member child of another 
   collection principal, they also match the parent collection 
   principal. Membership in a collection.  
        Since these privileges control collection principal is also recursive, so
   a principal in a collection principal GRPA contained by collection 
   principal GRPB is a member of both GRPA and GRPB. Implementations not
   supporting recursive membership in principal collections can return 
   an error if the ability client attempts to update bind collection principals into 
   other collection principals. 

   Servers that support aggregation of principals (e.g. groups of users 
   or other groups) MUST manifest them as collection principals. At 
   minimum, principals and collection principals MUST support the state 
   OPTIONS and PROPFIND methods.  

     Implementer's Note: Collection principals are first and foremost 
     WebDAV collections. Therefore they contain resources as members. 
     Since there is no requirement that all members of a collection, these privileges would collection 
     principal need be aggregated by the 
        DAV:write privilege on principals, it is possible for a collection, and granting collection 
     principal to have non-principals as members. When enumerating the DAV:write 
        privilege on 
     principals-only membership of a collection would also grant principal, it is 
     necessary to retrieve the add-member DAV:resourcetype property and 
        remove-member privileges. 


   Clemm, Hopkins, Sedlar, Whitehead                      [Page 7] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        Privileges may have check it 
     for the quality of being abstract, in which 
        case they cannot be set DAV:principal XML element (described in an ACE. Aggregate and non-aggregate 
        privileges are both capable of being abstract. Abstract 
        privileges are useful for modeling privileges that otherwise 
        would not be exposed via Section 4). If the protocol. Abstract privileges also 
        provide server implementations with flexibility in implementing 
     DAV:principal XML element is not present, the privileges defined in this specification.  For example, if 
        a server resource is incapable not a 
     principal and may be ignored for the purposes of separating determining the read resource 
        capability from 
     principals-only membership of the read ACL capability, it can still model collection principal. 

     For example, the 
        DAV:read and DAV:read-acl privileges defined in this 
        specification by declaring them abstract, collection principal /FOO/ has two members, Bar 
     and containing them 
        within Baz. Bar is a non-abstract aggregate privilege (say, read-all) that 
        holds DAV:read, and DAV:read-acl. In this way, it principal but Baz is possible not. Therefore when 
     determining which principals belong to set the aggregate privilege, read-all, thus coupling collection principal 
     /FOO/, a client would enumerate the 
        setting of DAV:read membership using PROPFIND 
     while asking for the DAV:resourcetype property, and DAV:read-acl, but it see that only 
     Bar has the DAV:principal XML element. Therefore, only Bar is not possible to 
        set DAV:read, or DAV:read-acl individually. Since aggregate 
        privileges can be abstract, it the 
     only principal that is also possible to use abstract 
        privileges to group or organize non-abstract privileges. 
        Privilege containment loops are not allowed, hence a privilege 
        MUST NOT contain itself. For example, DAV:read cannot contain 
        DAV:read. 

        The set member of privileges that apply the collection principal /FOO/. 


3  PRIVILEGES 

   Ability to perform a particular resource may 
        vary with the DAV:resourcetype of the resource, as well as 
        between different server implementations.  To promote 
        interoperability, however, this specification defines given method on a set resource SHOULD be controlled 
   by one or more privileges.  Authors of 
        well-known privileges (e.g. DAV:read,DAV:write, DAV:read-acl, 
        DAV:write-acl, DAV:read-current-user-privilege-set, and 
        DAV:all), protocol extensions that 
   define new HTTP methods SHOULD specify which can at least be used privileges (by defining 
   new privileges, or mapping to classify ones below) are required to perform the other
   method.  A principal with no privileges defined on to a particular resource. The resource SHOULD be 
   denied any HTTP access 
        permissions on null and lock-null resources (defined to that resource, unless the principal matches


Clemm, Hopkins, Sedlar, Whitehead                           [Page 9] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   an ACE constructed using the DAV:all, DAV:authenticated, or 
   DAV:unauthenticated pseudo-principals (see Section 5.4.1). 

   Privileges may be containers of other privileges, in 
        [RFC2518], Sections 3 and 7.4) are solely those they inherit 
        (if any), and which case they 
   are not discoverable (i.e., termed aggregate privileges.  If a principal is granted or denied
   an aggregate privilege, it is semantically equivalent to granting or 
   denying each of the access 
        control properties specified in Section 5 are not defined on 
        null aggregated privileges individually.  For example,
   an implementation may define add-member and lock-null resources). On remove-member privileges 
   that control the transition from null or 
        lock-null ability to add and remove an internal member of a stateful resource, the initial access 
   collection.  Since these privileges control 
        list is set by the server's default ACL value policy (if any). 

   3.1 DAV:read Privilege 

        The read privilege controls methods that return information 
        about ability to update the
   state of a collection, these privileges would be aggregated by the resource, including the resource's 
        properties. Affected methods include GET and PROPFIND.  
        Additionally, the read privilege MAY control the OPTIONS 
        method. 

        <!ELEMENT read EMPTY> 

   3.2 
   DAV:write Privilege 

        The write privilege controls methods that modify the content, 
        dead properties, or (in the case of on a collection) membership of 
        the resource, such as PUT and PROPPATCH.  Note that state 
        modification is also controlled via locking (see section 5.3 of 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 8] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        [WEBDAV]), so effective write access requires that both write 
        privileges collection, and write locking requirements are satisfied. 

        <!ELEMENT write EMPTY> 

   3.3 DAV:read-acl Privilege 

        The DAV:read-acl privilege controls the use of PROPFIND to 
        retrieve the DAV:acl property of granting the resource. 

        <!ELEMENT read-acl EMPTY> 

   3.4 DAV:read-current-user-privilege-set Privilege 

        The DAV:read-current-user-privilege-set DAV:write 
   privilege controls on a collection would also grant the 
        use of PROPFIND to retrieve add-member and remove-
   member privileges. 

   Privileges may have the DAV:current-user-privilege-set 
        property quality of the resource.  

        Clients are intended to use this property to visually indicate being abstract, in their UI items that which case they
   cannot be set in an ACE. Aggregate and non-aggregate privileges are dependent on the permissions 
   both capable of a 
        resource, being abstract. Abstract privileges are useful for example, by graying out resources 
   modeling privileges that are otherwise would not 
        writeable. 

        This privilege is separate from DAV:read-acl because there is a 
        need to allow most users access to be exposed via the 
   protocol. Abstract privileges permitted also provide server implementations 
   with flexibility in implementing the 
        current user (due to its use privileges defined in creating this 
   specification.  For example, if a server is incapable of separating 
   the UI), while read resource capability from the 
        full read ACL contains information that may not be appropriate for 
        the current authenticated user. As a result, the set of users 
        who can view the full ACL is expected to be much smaller than 
        those who capability, it can read 
   still model the current user privilege set, DAV:read and hence 
        distinct DAV:read-acl privileges are needed for each. 

        <!ELEMENT read-current-user-privilege-set EMPTY> 

   3.5 DAV:write-acl Privilege 

        The DAV:write-acl defined in this 
   specification by declaring them abstract, and containing them within 
   a non-abstract aggregate privilege controls use of the ACL method (say, read-all) that holds 
   DAV:read, and DAV:read-acl. In this way, it is possible to 
        modify set the DAV:acl property of 
   aggregate privilege, read-all, thus coupling the resource. 

        <!ELEMENT write-acl EMPTY> 

   3.6 DAV:all Privilege 

        DAV:all setting of DAV:read 
   and DAV:read-acl, but it is an not possible to set DAV:read, or 
   DAV:read-acl individually. Since aggregate privileges can be 
   abstract, it is also possible to use abstract privileges to group or 
   organize non-abstract privileges. Privilege containment loops are not
   allowed, hence a privilege that contains the entire MUST NOT contain itself. For example, 
   DAV:read cannot contain DAV:read. 

   The set of privileges that apply to a particular resource may vary 
   with the resource. 

        <!ELEMENT all EMPTY> 

   3.7 Aggregation DAV:resourcetype of Predefined Privileges 

        Server implementations are free the resource, as well as between 
   different server implementations.  To promote interoperability, 
   however, this specification defines a set of well-known privileges 
   (e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
   current-user-privilege-set, and DAV:all), which can at least be used 
   to aggregate classify the predefined other privileges defined on a particular resource. 
   The access permissions on null resources (defined above in Sections 3.1-3.6) subject to [RFC2518], 
   Section 3) are solely those they inherit (if any), and they are not 
   discoverable (i.e., the 
        following limitations: access control properties specified in 
   Section 5 are not defined on null resources). On the transition from 
   null to stateful resource, the initial access control list is set by 
   the server's default ACL value policy (if any). 

   Server implementations MAY define new privileges beyond those defined
   in this specification. Privileges defined by individual 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 9] 10] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-
        acl, or DAV:read-current-user-privilege-set. 

        DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-
        acl, or DAV:read-current-user-privilege-set. 

        DAV:read-current-user-privilege-set MUST NOT contain DAV:write, 
        DAV:read, DAV:read-acl, or DAV:write-acl. 

        DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
        current-user-privilege-set. 

        DAV:read 

   implementations MUST NOT contain DAV:write, or DAV:write-acl. 

   4  PRINCIPAL PROPERTIES 

        Principals are manifested to clients use the DAV: namespace, and instead should 
   use a namespace that they control, such as an HTTP resource, 
        identified by a http scheme URL.  A principal MUST have a DAV:displayname 
        property (defined in Section 13.2 

3.1 DAV:read Privilege 

   The read privilege controls methods that return information about the
   state of [RFC2518]), the resource, including the resource's properties. Affected 
   methods include GET and a 
        DAV:resourcetype property (defined in Section 13.9 of 
        [RFC2518]). PROPFIND.  Additionally, a principal MUST report the 
        DAV:principal empty XML element in the value of read privilege 
   MAY control the 
        DAV:resourcetype property in addition to all other reported 
        elements. For example, a collection principal would report 
        DAV:collection and DAV:principal elements. The element type 
        declaration for DAV:principal is: OPTIONS method. 

     <!ELEMENT principal read EMPTY> 
         
        This protocol defines 

3.2 DAV:write Privilege 

   The write privilege controls methods that modify the following additional property for a 
        principal. Since it is expensive, for many servers, to retrieve 
        access control information, content, dead 
   properties, or (in the name and value case of this property 
        SHOULD NOT be returned by a PROPFIND allprop request (as 
        defined in Section 12.14.1 collection) membership of [RFC2518]).  

   4.1 DAV:alternate-URL 

        This protected property, if non-empty, contains the URIs 
   resource, such as PUT and PROPPATCH.  Note that state modification is
   also controlled via locking (see section 5.3 of 
        network resources with additional descriptive information about 
        the principal. This property identifies one or more additional 
        network resources (i.e., it contains one or more URIs) [WEBDAV]), so 
   effective write access requires that may 
        be consulted by a client to gain additional knowledge 
        concerning a principal. Two potential uses for this property both write privileges and write 
   locking requirements are satisfied. 

     <!ELEMENT write EMPTY> 

3.3 DAV:read-acl Privilege 

   The DAV:read-acl privilege controls the use of PROPFIND to store an ldap [RFC2255] or mailto [RFC2368] scheme URL. 
        Support for this property is REQUIRED, and retrieve 
   the value is empty 
        if no alternate URL exists for DAV:acl property of the principal. . resource. 

     <!ELEMENT alternate-URL (href*)> 

   5  ACCESS CONTROL PROPERTIES 

        This specification defines a number of new properties for 
        WebDAV resources.  Access control properties may be retrieved 
        just like other WebDAV properties, using read-acl EMPTY> 

3.4 DAV:read-current-user-privilege-set Privilege 

   The DAV:read-current-user-privilege-set privilege controls the use of
   PROPFIND method.   
        Since it is expensive, for many servers, to retrieve access 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 10] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        control information, a PROPFIND allprop request (as defined in 
        Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and 
        values DAV:current-user-privilege-set property of 
   the properties defined in resource.  

   Clients are intended to use this section. 

        HTTP resources property to visually indicate in 
   their UI items that support are dependent on the WebDAV Access Control Protocol 
        MUST contain the following properties. Null, and lock-null 
        resources (described in Section 7.4 permissions of [RFC2518]) MUST NOT 
        contain the following properties: 

   5.1 DAV:owner 

        This protected property identifies a particular principal as 
        being the "owner" of the resource. Since the owner of resource, 
   for example, by graying out resources that are not writeable. 

   This privilege is separate from DAV:read-acl because there is a 
        resource often has special need 
   to allow most users access control capabilities (e.g., to the owner frequently has permanent DAV:write-acl privilege), 
        clients might display privileges permitted the resource owner in their current 
   user 
        interface. 

        <!ELEMENT owner (href)> 
         

   5.1.1 Example: Retrieving DAV:owner 

        This example shows a client request for (due to its use in creating the value of UI), while the 
        DAV:owner property from a collection resource with URL 
        http://www.webdav.org/papers/. The principal making full ACL contains
   information that may not be appropriate for the request 
        is current authenticated using Digest authentication. The value
   user. As a result, the set of 
        DAV:owner is users who can view the URL http://www.webdav.org/_acl/users/gstein, 
        wrapped in full ACL is 
   expected to be much smaller than those who can read the DAV:href XML element. 

        >> Request << 
         
        PROPFIND /papers/ HTTP/1.1 
        Host: www.webdav.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="jim",  
           realm="jim@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propfind xmlns:D="DAV:"> 
          <D:owner/> 
        </D:propfind> 
         
        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus xmlns:D="DAV:"> current user 
   privilege set, and hence distinct privileges are needed for each. 

     <!ELEMENT read-current-user-privilege-set EMPTY> 



Clemm, Hopkins, Sedlar, Whitehead                          [Page 11] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


           <D:response>  
              <D:href>http://www.webdav.org/papers/</D:href> 
              <D:propstat> 
                 <D:status>HTTP/1.1 200 OK</D:status> 
                 <D:prop> 
                    <D:owner> 
                     <D:href>
                       http://www.webdav.org/_acl/users/gstein
                     </D:href>        
                    </D:owner> 
                 </D:prop> 
              </D:propstat> 
           </D:response> 
        </D:multistatus> 

   5.1.2 Example: An Attempt to Set DAV:owner 

3.5 DAV:write-acl Privilege 

   The following example shows a client request DAV:write-acl privilege controls use of the ACL method to modify 
   the 
        value of the DAV:owner DAV:acl property on of the resource with URL 
        http://www.webdav.org/papers/. Since DAV:owner resource. 

     <!ELEMENT write-acl EMPTY> 

3.6 DAV:all Privilege 

   DAV:all is a protected 
        property, the server responds with a 207 (Multi-Status) 
        response an aggregate privilege that contains a 403 (Forbidden) status code for the 
        act of setting DAV:owner. [RFC2518], Section 8.2.1 describes 
        PROPPATCH status code information, and Section 11 describes the 
        Multi-Status response. 

        >> Request << 
         
        PROPPATCH /papers/ HTTP/1.1 
        Host: www.webdav.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="jim",  
           realm="jim@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propertyupdate xmlns:D="DAV:"> 
           <D:set> 
              <D:prop> 
                 <D:owner> 
                   <D:href>
                     http://www.webdav.org/_acl/users/jim
                   </D:href> 
                 </D:owner> 
              </D:prop> 
           </D:set> 
        </D:propertyupdate> 
         

        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 12] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus xmlns:D="DAV:">  
           <D:response>  
              <D:href>http://www.webdav.org/papers/</D:href> 
              <D:propstat> 
                 <D:status>HTTP/1.1 403 Forbidden</D:status> 
                 <D:prop><D:owner/></D:prop> 
              </D:propstat> 
              <D:responsedescription>Failure to entire set protected property 
        (DAV:owner) 
              </D:responsedescription> 
           </D:response> 
        </D:multistatus> 
         

   5.2 DAV:supported-privilege-set 

        This is a protected property that identifies the of 
   privileges 
        defined for that can be applied to the resource. 

     <!ELEMENT supported-privilege-set (supported-privilege*)> 
         
        Each privilege appears as an XML element, where aggregate 
        privileges list as sub-elements all EMPTY> 

3.7 Aggregation of Predefined Privileges 

   Server implementations are free to aggregate the predefined 
   privileges that they 
        aggregate. 

        <!ELEMENT supported-privilege 
         (privilege, abstract?, description, supported-privilege*)> 
        <!ELEMENT privilege ANY> 
         
        An abstract privilege of a resource (defined above in Sections 3.1-3.6) subject to the 
   following limitations: 

   DAV:read-acl MUST NOT be used in an ACE 
        for that resource. Servers contain DAV:read, DAV:write, DAV:write-acl, or 
   DAV:read-current-user-privilege-set. 

   DAV:write-acl MUST fail an attempt to set an 
        abstract privilege. 

        <!ELEMENT abstract EMPTY> NOT contain DAV:write, DAV:read, DAV:read-acl, or 
   DAV:read-current-user-privilege-set. 

   DAV:read-current-user-privilege-set MUST NOT contain DAV:write, 
   DAV:read, DAV:read-acl, or DAV:write-acl. 

   DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
   current-user-privilege-set. 

   DAV:read MUST NOT contain DAV:write, or DAV:write-acl. 


4  PRINCIPAL PROPERTIES 

   Principals are manifested to clients as a WebDAV resource, identified
   by a URL.  A description is principal MUST have a human-readable description DAV:displayname property (defined 
   in Section 13.2 of what this 
        privilege controls access to.  

        <!ELEMENT description #PCDATA> 
         
        It is envisioned that [RFC2518]), and a WebDAV ACL-aware administrative client 
        would list the supported privileges DAV:resourcetype property 
   (defined in Section 13.9 of [RFC2518]).  Additionally, a dialog box, and allow principal 
   MUST report the user to choose non-abstract privileges to apply DAV:principal empty XML element in an ACE.  
        The privileges tree is useful programmatically the value of the 
   DAV:resourcetype property in addition to map well-
        known privileges (defined by WebDAV or all other standards groups) 
        into privileges that are supported by any particular server 
        implementation. reported elements.
   For example, a collection principal would report DAV:collection and 
   DAV:principal elements. The privilege tree also serves to hide 
        complexity in implementations allowing large number of 
        privileges to be defined by displaying aggregates element type declaration for 
   DAV:principal is: 

     <!ELEMENT principal EMPTY> 
      
   This protocol defines the following additional property for a 
   principal. Since it is expensive, for many servers, to retrieve 
   access control information, the user. name and value of this property 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 13] 12] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


   5.2.1 Example: Retrieving 

   SHOULD NOT be returned by a List PROPFIND allprop request (as defined in 
   Section 12.14.1 of Privileges Supported on a 
         Resource [RFC2518]).  

4.1 DAV:alternate-URI-set 

   This example shows a client request for the DAV:supported- protected property, if non-empty, contains the URIs of network 
   resources with additional descriptive information about the 
   principal. This property identifies additional network resources 
   (i.e., it contains one or more URIs) that may be consulted by a 
   client to gain additional knowledge concerning a principal. One 
   expected use for this property is the storage of an ldap [RFC2255] 
   scheme URL. A user-agent encountering an ldap URL could use LDAP 
   [RFC2589] to retrieve additional machine-readable directory 
   information about the principal, and display that information in its 
   user interface. Support for this property is REQUIRED, and the value 
   is empty if no alternate URI exists for the principal. 

     <!ELEMENT alternate-URI-set (href*)> 

4.2 DAV:principal-URL 

    This protected property contains the URL that MUST be used to 
   identify this principal in an ACL request.  

     <!ELEMENT principal-URL (href)> 


5  ACCESS CONTROL PROPERTIES 

   This specification defines a number of new properties for WebDAV 
   resources.  Access control properties may be retrieved just like 
   other WebDAV properties, using the PROPFIND method.   Since it is 
   expensive, for many servers, to retrieve access control information, 
   a PROPFIND allprop request (as defined in Section 12.14.1 of 
   [RFC2518]) SHOULD NOT return the names and values of the properties 
   defined in this section. 

   HTTP resources that support the WebDAV Access Control Protocol MUST 
   contain the following properties. Null resources (described in 
   Section 3 of [RFC2518]) MUST NOT contain the following properties: 

5.1 DAV:owner 

   This protected property identifies a particular principal as being 
   the "owner" of the resource. Since the owner of a resource often has 
   special access control capabilities (e.g., the owner frequently has 
   permanent DAV:write-acl privilege), clients might display the 
   resource owner in their user interface. 

     <!ELEMENT owner (href)> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 13] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

5.1.1 Example: Retrieving DAV:owner 

   This example shows a client request for the value of the DAV:owner 
   property from a collection resource with URL 
   http://www.webdav.org/papers/. The principal making the request is 
   authenticated using Digest authentication. The value of DAV:owner is 
   the URL http://www.webdav.org/_acl/users/gstein, wrapped in the 
   DAV:href XML element. 

     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="jim",  
        realm="jim@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
       <D:prop> 
         <D:owner/> 
       </D:prop> 
     </D:propfind> 
      
     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
        <D:response>  
           <D:href>http://www.webdav.org/papers/</D:href> 
           <D:propstat> 
              <D:prop> 
                 <D:owner> 
     <D:href>http://www.webdav.org/_acl/users/gstein</D:href>        
                 </D:owner> 
              </D:prop> 
              <D:status>HTTP/1.1 200 OK</D:status>       
           </D:propstat> 
        </D:response> 
     </D:multistatus> 



Clemm, Hopkins, Sedlar, Whitehead                          [Page 14] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

5.1.2 Example: An Attempt to Set DAV:owner 

   The following example shows a client request to modify the value of 
   the DAV:owner property on the resource with URL 
   http://www.webdav.org/papers/. Since DAV:owner is a protected 
   property, the server responds with a 207 (Multi-Status) response that
   contains a 403 (Forbidden) status code for the act of setting 
   DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status code
   information, and Section 11 of [RFC2518] describes the Multi-Status 
   response. 

     >> Request << 
      
     PROPPATCH /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="jim",  
        realm="jim@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propertyupdate xmlns:D="DAV:"> 
        <D:set> 
           <D:prop> 
              <D:owner> 
                 <D:href>http://www.webdav.org/_acl/users/jim</D:href> 
              </D:owner> 
           </D:prop> 
        </D:set> 
     </D:propertyupdate> 
    

     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
        <D:response>  
           <D:href>http://www.webdav.org/papers/</D:href> 
           <D:propstat> 
              <D:prop><D:owner/></D:prop> 
              <D:status>HTTP/1.1 403 Forbidden</D:status> 
              <D:responsedescription>Failure to set protected property 
     (DAV:owner) 
              </D:responsedescription> 
           </D:propstat> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 15] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

        </D:response> 
     </D:multistatus> 
    

5.2 DAV:supported-privilege-set 

     This is a protected property that identifies the privileges defined
     for the resource.   
     <!ELEMENT supported-privilege-set (supported-privilege*)> 
      
     Each privilege appears as an XML element, where aggregate 
     privileges list as sub-elements all of the privileges that they 
     aggregate. 
     <!ELEMENT supported-privilege (privilege, abstract?, description, 
     supported-privilege*)> 
     <!ELEMENT privilege ANY> 
      
   An abstract privilege MUST NOT be used in an ACE for that resource. 
   Servers MUST fail an attempt to set an abstract privilege. 

     <!ELEMENT abstract EMPTY> 
      
   A description is a human-readable description of what this privilege 
   controls access to. Servers MUST indicate the human language of the 
   description using the xml:lang attribute and SHOULD consider the HTTP
   Accept-Language request header when selecting one of multiple 
   available languages. 

     <!ELEMENT description #PCDATA> 
      
   It is envisioned that a WebDAV ACL-aware administrative client would 
   list the supported privileges in a dialog box, and allow the user to 
   choose non-abstract privileges to apply in an ACE.  The privileges 
   tree is useful programmatically to map well-known privileges (defined
   by WebDAV or other standards groups) into privileges that are 
   supported by any particular server implementation.  The privilege 
   tree also serves to hide complexity in implementations allowing large
   number of privileges to be defined by displaying aggregates to the 
   user. 

5.2.1 Example: Retrieving a List of Privileges Supported on a Resource 

   This example shows a client request for the DAV:supported-privilege-
   set property on the resource http://www.webdav.org/papers/. The value
   of the DAV:supported-privilege-set property is a tree of supported 
   privileges: 

       DAV:all (aggregate, abstract) 
           | 
           +-- DAV:read (aggregate) 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 16] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 
                  | 
                  +-- DAV:read-acl (abstract) 
                  +-- DAV:read-current-user-privilege-set (abstract) 
           +-- DAV:write (aggregate) 
                  | 
                  +-- DAV:write-acl (abstract) 
    

   This privilege tree is not normative, and many possible privilege 
   trees are possible. 

    
     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="gclemm",  
        realm="gclemm@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
       <D:prop> 
         <D:supported-privilege-set/> 
       </D:prop> 
     </D:propfind> 
      
     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
       <D:response>  
         <D:href>http://www.webdav.org/papers/</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:supported-privilege-set> 
               <D:supported-privilege> 
                 <D:privilege> <D:all/> </D:privilege> 
                 <D:abstract/> 
                 <D:description xml:lang="en">Any 
     operation</D:description> 
                 <D:supported-privilege> 
                   <D:privilege> <D:read/> </D:privilege> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 17] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

                   <D:description xml:lang="en">Read any 
     object</D:description> 
                   <D:supported-privilege> 
                     <D:privilege> <D:read-acl/> </D:privilege> 
                     <D:abstract/> 
                     <D:description xml:lang="en">Read 
     ACL</D:description> 
                   </D:supported-privilege> 
                 </D:supported-privilege> 
                   <D:supported-privilege> 
                     <D:privilege>  
                       <D:read-current-user-privilege-set/> 
                     </D:privilege> 
                     <D:abstract/> 
                     <D:description xml:lang="en">Read current user 
     privilege set property</D:description> 
                   </D:supported-privilege> 
                 <D:supported-privilege> 
                   <D:privilege> <D:write/> </D:privilege> 
                   <D:description xml:lang="en">Write any 
     object</D:description> 
                   <D:supported-privilege> 
                     <D:privilege> <D:write-acl/> </D:privilege> 
                     <D:description xml:lang="en">Write 
     ACL</D:description> 
                     <D:abstract/> 
                   </D:supported-privilege> 
                 </D:supported-privilege> 
               </D:supported-privilege> 
             </D:supported-privilege-set> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       </D:response> 
     </D:multistatus> 

5.3 DAV:current-user-privilege-set 

   DAV:current-user-privilege-set is a protected property containing the
   exact set of privileges (as computed by the server) granted to the 
   currently authenticated HTTP user. Aggregate privileges and their 
   contained privileges are listed. A user-agent can use the value of 
   this property to adjust its user interface to make actions 
   inaccessible (e.g., by graying out a menu item or button) for which 
   the current principal does not have permission. This is particularly 
   useful for an access control user interface, which can be constructed
   without knowing the ACE combining semantics of the server. This 
   property is also useful for determining what operations the current 
   principal can perform, without having to actually execute an 
   operation. 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 18] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <!ELEMENT current-user-privilege-set (privilege*)> 
     <!ELEMENT privilege ANY> 
      
   If the current user is granted a specific privilege, that privilege 
   must belong to the set of privileges that may be set on this 
   resource. Therefore, each element in the DAV:current-user-privilege-
   set property MUST identify a non-abstract privilege from the 
   DAV:supported-privilege-set property. 

5.3.1 Example: Retrieving the UserÆs Current Set of Assigned Privileges 

   Continuing the example from Section 5.2.1, this example shows a 
   client requesting the DAV:current-user-privilege-set property from 
   the resource with URL http://www.webdav.org/papers/. The username of 
   the principal making the request is ôkhare", and Digest 
   authentication is used in the request. The principal with username 
   ôkhare" has been granted the DAV:read privilege. Since the DAV:read 
   privilege contains the DAV:read-acl and DAV:read-current-user-
   privilege-set privileges (see Section 5.2.1), the principal with 
   username ôkhare" can read the ACL property, and the DAV:current-user-
   privilege-set property. However, the DAV:all, DAV:read-acl, 
   DAV:write-acl and DAV:read-current-user-privilege-set privileges are 
   not listed in the value of DAV:current-user-privilege-set, since (for
   this example) they are abstract privileges. DAV:write is not listed 
   since the principal with username ôkhare" is not listed in an ACE 
   granting that principal write permission. 

     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="khare",  
        realm="khare@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
       <D:prop> 
         <D:current-user-privilege-set/> 
       </D:prop> 
     </D:propfind> 
    

     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 19] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
       <D:response>  
         <D:href>http://www.webdav.org/papers/</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:current-user-privilege-set> 
               <D:privilege> <D:read/> </D:privilege> 
             </D:current-user-privilege-set> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       </D:response> 
     </D:multistatus> 

5.4 DAV:acl 

   This is a protected property on that specifies the list of access 
   control entries (ACEs), which define what principals are to get what 
   privileges for this resource. 

     <!ELEMENT acl (ace*)> 
      
   Each DAV:ace element specifies the set of privileges to be either 
   granted or denied to a single principal.  If the DAV:acl property is 
   empty, no principal is granted any privilege. 

     <!ELEMENT ace (principal, (grant|deny), protected?, inherited?)> 

5.4.1 ACE Principal 

   The DAV:principal element identifies the principal to which this ACE 
   applies. 

     <!ELEMENT principal ((href) 
      | all | authenticated | unauthenticated 
      | property | self)> 
      
   The current user matches DAV:href only if that user is authenticated 
   as being (or being a member of) the principal identified by the URL 
   contained by that DAV:href.  

   The current user always matches DAV:all.  

     <!ELEMENT all EMPTY> 
      
   The current user matches DAV:authenticated only if authenticated. 

     <!ELEMENT authenticated EMPTY> 
      
Clemm, Hopkins, Sedlar, Whitehead                          [Page 20] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   The current user matches DAV:unauthenticated only if not 
   authenticated. 

     <!ELEMENT unauthenticated EMPTY> 
      
   DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. 
   For a given request, the user matches either DAV:authenticated, or 
   DAV:unauthenticated, but not both (that is, DAV:authenticated and 
   DAV:unauthenticated are disjoint sets). 

   The current user matches a DAV:property principal in a DAV:acl 
   property of a resource 
        http://www.webdav.org/papers/. The only if the value of the DAV:supported-
        privilege-set identified property 
   of that resource contains at most one DAV:href XML element, the URI 
   value of DAV:href identifies a principal, and the current user is 
   authenticated as being (or being a tree member of) that principal.  For 
   example, if the DAV:property element contained <DAV:owner/>, the 
   current user would match the DAV:property principal only if the 
   current user is authenticated as matching the principal identified by
   the DAV:owner property of supported privileges: 

          DAV:all (aggregate, abstract) 
              | 
            +-- DAV:read (aggregate) 
                     | 
                     +-- DAV:read-acl (abstract) 
                     +-- DAV:read-current-user-privilege-set (abstract) 
            +-- DAV:write (aggregate) 
                 | 
                     +-- DAV:write-acl (abstract) 
         

        This privilege tree the resource. 

     <!ELEMENT property ANY> 
      
   The current user matches DAV:self in a DAV:acl property of the 
   resource only if that resource is not normative, a principal object and many possible 
        privilege trees are possible. 

         

        >> Request << 
         
        PROPFIND /papers/ HTTP/1.1 
        Host: www.webdav.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="gclemm",  
           realm="gclemm@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propfind xmlns:D="DAV:"> 
          <D:supported-privilege-set/> 
        </D:propfind> 
         
        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus xmlns:D="DAV:">  
          <D:response>  
            <D:href>http://www.webdav.org/papers/</D:href> 
            <D:propstat> 
              <D:status>HTTP/1.1 200 OK</D:status> 
              <D:prop> 
                <D:supported-privilege-set> 


   Clemm, Hopkins, Sedlar, Whitehead                      [Page 14] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


                  <D:supported-privilege> 
                    <D:privilege> <D:all/> </D:privilege> 
                    <D:abstract/> 
                    <D:description>Any operation</D:description> 
                    <D:supported-privilege> 
                      <D:privilege> <D:read/> </D:privilege> 
                      <D:description>Read any object</D:description> 
                      <D:supported-privilege> 
                        <D:privilege> <D:read-acl/> </D:privilege> 
                        <D:abstract/> 
                        <D:description>Read ACL</D:description> 
                      </D:supported-privilege> 
                    </D:supported-privilege> 
                      <D:supported-privilege> 
                        <D:privilege>  
                          <D:read-current-user-privilege-set/> 
                        </D:privilege> 
                        <D:abstract/> 
                        <D:description>Read the current 
   user privilege set 
        property</D:description> 
                      </D:supported-privilege> 
                    <D:supported-privilege> 
                      <D:privilege> <D:write/> </D:privilege> 
                      <D:description>Write any object</D:description> 
                      <D:supported-privilege> 
                        <D:privilege> <D:write-acl/> </D:privilege> 
                        <D:description>Write ACL</D:description> 
                        <D:abstract/> 
                      </D:supported-privilege> 
                    </D:supported-privilege> 
                  </D:supported-privilege> 
                </D:supported-privilege-set> 
              </D:prop> 
            </D:propstat> 
          </D:response> 
        </D:multistatus> 

   5.3 DAV:current-user-privilege-set 

        DAV:current-user-privilege-set is authenticated as being that principal or a protected property 
        containing member of that 
   principal collection. 

     <!ELEMENT self EMPTY> 

5.4.2 ACE Grant and Deny 

   Each DAV:grant or DAV:deny element specifies the exact set of privileges (as computed by the 
        server) to
   be either granted or denied to the currently authenticated HTTP user. 
        Aggregate privileges and their contained privileges are listed. specified principal.  A user-agent can use DAV:grant 
   or DAV:deny element of the value DAV:acl of this property to adjust its 
        user interface to make actions inaccessible (e.g., by graying 
        out a menu item or button) for which resource MUST only contain 
   non-abstract elements specified in the current principal does 
        not have permission. This is particularly useful for DAV:supported-privilege-set of
   that resource. 

     <!ELEMENT grant (privilege+)> 
     <!ELEMENT deny (privilege+)> 
     <!ELEMENT privilege ANY> 

5.4.3 ACE Protection 

   A server indicates an access 
        control user interface, which can be constructed without 
        knowing the ACE combining semantics of the server. This 
        property is also useful for determining what operations protected by including the 
        current principal can perform, without having to actually 
        execute DAV:protected
   element in the ACE. If the ACL of a resource contains an operation. ACE with a 
   DAV:protected element, an attempt to remove that ACE from the ACL 
   MUST fail.. 

     <!ELEMENT current-user-privilege-set (privilege*)> protected EMPTY> 



Clemm, Hopkins, Sedlar, Whitehead                          [Page 15] 21] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        <!ELEMENT privilege ANY> 
         
        If 

5.4.4 ACE Inheritance 

   The presence of a DAV:inherited element indicates that this ACE is 
   inherited from another resource that is identified by the URL 
   contained in a DAV:href element.  An inherited ACE cannot be modified
   directly, but instead the ACL on the resource from which it is 
   inherited must be modified. 

   Note that ACE inheritance is not the same as ACL initialization.  ACL
   initialization defines the current user is granted ACL that a specific privilege, newly created resource will use
   (if not specified).  ACE inheritance refers to an ACE that 
        privilege must belong is 
   logically shared - where an update to the set resource containing an ACE 
   will affect the ACE of privileges each resource that may be set 
        on inherits that ACE.  The 
   method by which ACLs are initialized or by which ACEs are inherited 
   is not defined by this resource. Therefore, each element in the DAV:current-
        user-privilege-set property MUST identify a non-abstract 
        privilege from the DAV:supported-privilege-set property. 

   5.3.1 document. 

     <!ELEMENT inherited (href)> 

5.4.5 Example: Retrieving the User's Current Set of Assigned 
         Privileges a ResourceÆs Access Control List 

   Continuing the example from Section 5.2.1, Sections 5.2.1 and 5.3.1, this example 
   shows a client requesting the DAV:current-user-privilege-set DAV:acl property from the resource with
   URL http://www.webdav.org/papers/. There are two ACEs defined in this
   ACL: 

   ACE #1: The 
        username principal collection identified by URL 
   http://www.webdav.org/_acl/groups/maintainers/ (the group of site 
   maintainers) is granted DAV:write privilege. Since (for this example)
   DAV:write contains the principal making DAV:write-acl privilege (see Section 5.2.1), 
   this means the request is ôkhareö, and 
        Digest authentication is used in ômaintainers" group can also modify the request. The principal 
        with username ôkhareö has been access control
   list. 

   ACE #2: All principals (DAV:all) are granted the DAV:read privilege. 
   Since the (for this example) DAV:read privilege contains the DAV:read-acl and 
        DAV:read-current-user-privilege-set privileges (see Section 
        5.2.1), DAV:read-
   current-user-privilege-set, this means all users (including all 
   members of the principal with username ôkhareö ômaintainers" group) can read the ACL 
        property, DAV:acl property and
   the DAV:current-user-privilege-set property. 
        However, the DAV:all, DAV:read-acl, DAV:write-acl and DAV:read-
        current-user-privilege-set privileges are not listed in the 
        value of DAV:current-user-privilege-set, since (for this 
        example) they are abstract privileges. DAV:write is not listed 
        since the principal with username ôkhareö is not listed in an 
        ACE granting that principal write permission. 

      
     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="khare",  
           realm="khare@webdav.org", username="masinter",  
        realm="masinter@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 22] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <D:propfind xmlns:D="DAV:"> 
          <D:current-user-privilege-set/> 
       <D:prop> 
         <D:acl/> 
       </D:prop> 
     </D:propfind> 
    

     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
       <D:response>  

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 16] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001  
         <D:href>http://www.webdav.org/papers/</D:href> 
         <D:propstat> 
              <D:status>HTTP/1.1 200 OK</D:status> 
            
           <D:prop> 
                <D:current-user-privilege-set> 
             <D:acl> 
               <D:ace> 
                 <D:principal> 
                   <D:href> 
                     http://www.webdav.org/_acl/groups/maintainers/ 
                   </D:href> 
                 </D:principal>  
                 <D:grant> 
                   <D:privilege> <D:write/> </D:privilege> 
                 </D:grant> 
               </D:ace> 
               <D:ace> 
                 <D:principal> 
                   <D:all/> 
                 </D:principal> 
                 <D:grant> 
                   <D:privilege> <D:read/> </D:privilege> 
                </D:current-user-privilege-set>  
                 </D:grant> 
               </D:ace> 
             </D:acl> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       </D:response> 
     </D:multistatus> 
         

   5.4 DAV:acl 
      

5.5 DAV:acl-semantics 

   This is a protected property that specifies defines the list of access 
        control entries (ACEs), which ACL semantics.  These 
   semantics define what principals are to get 
        what privileges for this resource. 

        <!ELEMENT acl (ace*)> 
         
        Each DAV:ace element specifies the set of privileges to be 
        either granted or denied to a single principal.  If the DAV:acl 
        property is empty, no principal is granted any privilege. 

        <!ELEMENT ace (principal, (grant|deny), protected?, 
        inherited?)> 
         
         

   5.4.1 ACE Principal 

        The DAV:principal element identifies the principal to which 
        this ACE applies. 

        <!ELEMENT principal ((href) 
         | all | authenticated | unauthenticated 
         | property | self)> 
         
        The current user matches DAV:href only if how multiple ACEs that user is 
        authenticated as being (or being a member of) the principal 
        identified by match the URL contained by that DAV:href.  
         
        The current user always matches DAV:all.  

        <!ELEMENT all EMPTY> 
         
        The current user matches DAV:authenticated only if 
        authenticated. 

        <!ELEMENT authenticated EMPTY> 
         
        The current user matches DAV:unauthenticated only if not 
        authenticated. are 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 17] 23] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        <!ELEMENT unauthenticated EMPTY> 
         
        DAV:all is the union of DAV:authenticated, and 
        DAV:unauthenticated. For a given request, 

   combined, what are the user matches 
        either DAV:authenticated, or DAV:unauthenticated, but not both 
        (that is, DAV:authenticated constraints on how ACEs can be ordered, and DAV:unauthenticated are 
        disjoint sets). 

        The current 
   which principals must have an ACE. A client user matches a DAV:property principal in a DAV:acl 
        property of a resource only if interface could use 
   the value of the identified this property of that resource contains at most one DAV:href XML 
        element, to provide feedback to a human operator 
   concerning the URI value impact of DAV:href identifies proposed changes to an ACL. Alternately, a principal, and 
        the current user is authenticated as being (or being 
   client can use this property to help it determine, before submitting 
   an ACL method invocation, what ACL changes it needs to make to 
   accomplish a member 
        of) specific goal (or whether that principal.  For example, if the DAV:property element 
        contained <DAV:owner/>, the current user would match the 
        DAV:property principal only if the current user goal is 
        authenticated as matching even achievable 
   on this server). 

   Since it is not practical to require all implementations to use the principal identified by 
   same ACL semantics, the 
        DAV:owner DAV:acl-semantics property of is used to 
   identify the ACL semantics for a particular resource. 

        <!ELEMENT property ANY>  The current user matches DAV:self DAV:acl-
   semantics element is defined in a DAV:acl property of Section 6. 

5.5.1 Example: Retrieving DAV:acl-semantics 

   In this example, the 
        resource only if that resource is a principal object and client requests the 
        current user is authenticated as being that principal or a 
        member value of that the DAV:acl-
   semantics property. Digest authentication provides credentials for 
   the principal collection. 

        <!ELEMENT self EMPTY> 

   5.4.2 ACE Grant and Deny 

        Each DAV:grant or DAV:deny element specifies operating the set of 
        privileges to be either granted or denied to client. In this example, the specified 
        principal.  A DAV:grant or DAV:deny element of ACE 
   combination semantics are DAV:first-match, described in Section 
   6.1.1, the DAV:acl of a 
        resource MUST only contain non-abstract elements ACE ordering semantics are not specified (some value other
   than DAV:deny-before-grant, described in Section 6.2.1), the DAV:supported-privilege-set of that resource. 

        <!ELEMENT grant (privilege+)> 
        <!ELEMENT deny (privilege+)> 
        <!ELEMENT privilege ANY> 

   5.4.3 ACE Protection 

        If an ACE contains a DAV:protected element, an ACL request 
        without that ACE MUST fail. 

        <!ELEMENT protected EMPTY> 

   5.4.4 ACE Inheritance 

        The presence of a DAV:inherited 
   DAV:allowed-ace element indicates states that this only one ACE is inherited from another resource that is identified by the 
        URL contained in a DAV:href element.  An inherited permitted for 
   each principal, and an ACE cannot 
        be modified directly, but instead describing the ACL on privileges granted the resource from 
        which it is inherited 
   DAV:all principal must be modified. exist in every ACL. 

    

     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="srcarter",  
        realm="srcarter@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
       <D:prop> 
         <D:acl-semantics/> 
       </D:prop> 
     </D:propfind> 
    

     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 18] 24] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        Note that ACE inheritance is not the same as ACL 
        initialization.  ACL initialization defines the ACL that a 
        newly created resource will use (if not specified).  ACE 
        inheritance refers to an ACE that is logically shared - where 
        an update to the resource containing an ACE will affect the ACE 
        of each resource that inherits that ACE.  The method by which 
        ACLs are initialized 

     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
       <D:response>  
         <D:href>http://www.webdav.org/papers/</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:acl-semantics> 
               <D:ace-combination> 
                 <D:first-match/> 
               </D:ace-combination> 
               <D:ace-ordering/> 
            <D:allowed-ace> 
                 <D:principal-only-one-ace/> 
               </D:allowed-ace> 
               <D:required-principal> 
                 <D:all/> 
               </D:required-principal> 
             </D:acl-semantics> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       <D:response> 
     </D:multistatus> 
    

5.6 DAV:principal-collection-set 

   This protected property contains zero, one, or by which ACEs are inherited more URLs that 
   identify a collection principal. It is not 
        defined by expected that implementations 
   of this document. 

        <!ELEMENT inherited (href)> 

   5.4.5 Example: Retrieving protocol will typically use a Resource's Access Control List 

        Continuing relatively small number of 
   locations in the example from Sections 5.2.1 URL namespace for principals, and 5.3.1, collection 
   principals. In cases where this 
        example shows a client requesting assumption holds, the DAV:acl DAV:principal-
   collection-set property from will contain a small set of URLs identifying 
   the 
        resource with URL http://www.webdav.org/papers/. There are two 
        ACEs defined in this ACL: 

        ACE #1: The principal top of a collection identified by URL 
        http://www.webdav.org/_acl/groups/maintainers/ (the group hierarchy containing multiple principals and 
   collection principals. An access control protocol user agent could 
   use the contents of 
        site maintainers) is granted DAV:write privilege. Since (for 
        this example) DAV:write contains DAV:principal-collection-set to retrieve the DAV:write-acl privilege 
        (see 
   DAV:displayname property (specified in Section 5.2.1), this means the ômaintainersö group can 
        also modify the access control list. 

        ACE #2: All 13.2 of [RFC2518]) of 
   all principals (DAV:all) are granted the DAV:read 
        privilege. on that server, thereby yielding human-readable names 
   for each principal that could be displayed in a user interface. 

     <!ELEMENT principal-collection-set (href*)> 
   Since (for this example) DAV:read contains DAV:read-
        acl and DAV:read-current-user-privilege-set, this means all 
        users (including all members different servers can control different parts of the ômaintainersö group) can 
        read URL 
   namespace, different resources on the DAV:acl property same host MAY have different 
   DAV:principal-collection-set values. The collections specified in the
   DAV:principal-collection-set MAY be located on different hosts from 
   the resource. The URLs in DAV:principal-collection-set SHOULD be http
   or https scheme URLs. For security and scalability reasons, a server 
   MAY report only a subset of the DAV:current-user-privilege- entire set property. 

         
        >> Request << 
         
        PROPFIND /papers/ HTTP/1.1 
        Host: www.webdav.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="masinter",  
           realm="masinter@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propfind xmlns:D="DAV:"> 
          <D:acl/> 
        </D:propfind> 
         

        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" of known collection 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 19] 25] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus xmlns:D="DAV:">  
          <D:response>  
            <D:href>http://www.webdav.org/papers/</D:href> 
            <D:propstat> 
              <D:status>HTTP/1.1 200 OK</D:status> 
              <D:prop> 
                <D:acl> 
                  <D:ace> 
                    <D:principal> 
                      <D:href>
                        http://www.webdav.org/_acl/groups/maintainers/
                      </D:href> 
                    </D:principal>  
                    <D:grant> 
                      <D:privilege> <D:write/> </D:privilege> 
                    </D:grant> 
                  </D:ace> 
                  <D:ace> 
                    <D:principal> 
                      <D:href> <D:all/> </D:href> 
                    </D:principal> 
                    <D:grant> 
                      <D:privilege> <D:read/> </D:privilege>  
                    </D:grant> 
                  </D:ace> 
                </D:acl> 
              </D:prop> 
            </D:propstat> 
          </D:response> 
        </D:multistatus> 
         

   5.5 DAV:acl-semantics 

        This is a protected property that defines the ACL semantics.  
        These semantics define how multiple ACEs that match the current 
        user are combined, what are the constraints on how ACEs can be 
        ordered, 

   principals, and which principals must therefore clients should not assume they have 
   retrieved an ACE. A client user 
        interface could use exhaustive listing. Additionally, a server MAY elect to 
   report none of the collection principals it knows about, in which 
   case the property value would be empty.  

   The value of this property to provide 
        feedback to a human operator concerning DAV:principal-collection-set gives the impact of proposed 
        changes to an ACL. Alternately, a client can use this property 
        to help it determine, before submitting an ACL method 
        invocation, what ACL changes it needs to make to accomplish a 
        specific goal (or whether that goal is even achievable on this 
        server). 

        Since it is not practical to require all implementations to scope of the 
   DAV:principal-property-search REPORT (defined in Section 9.4). 
   Clients use the same ACL semantics, DAV:principal-property-search REPORT to populate 
   their user interface with a list of principals. Therefore, servers 
   that limit a client's ability to obtain principal information will 
   interfere with the DAV:acl-semantics property is used client's ability to manipulate access control 
   lists, due to identify the ACL semantics for difficulty of getting the URL of a particular resource.  The 
        DAV:acl-semantics element is defined principal for 
   use in Section 6. 



   Clemm, Hopkins, Sedlar, Whitehead                      [Page 20] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


   5.5.1 an ACE. 

5.6.1 Example: Retrieving DAV:acl-semantics DAV:principal-collection-set 

   In this example, the client requests the value of the DAV:acl-
        semantics property. DAV:principal-
   collection-set property on the collection resource identified by URL 
   http://www.webdav.org/papers/. The property contains the two URLs, 
   http://www.webdav.org/_acl/users/ and 
   http://www.webdav.org/_acl/groups/, both wrapped in <DAV:href> XML 
   elements. Digest authentication provides credentials for the 
   principal operating the client. In 

   The client might reasonably follow this example, request with two separate 
   PROPFIND requests to retrieve the 
        ACE combination semantics are DAV:first-match, described in 
        Section 6.1.1, DAV:displayname property of the ACE ordering semantics are not specified 
        (some value other than DAV:deny-before-grant, described in 
        Section 6.2.1), 
   members of the two collections (/_acl/users/ and /_acl_groups/). This
   information could be used when displaying a user interface for 
   creating access control entries. 

      
     >> Request << 
      
     PROPFIND /papers/ HTTP/1.1 
     Host: www.webdav.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="yarong",  
        realm="yarong@webdav.org", nonce="...", 
        uri="/papers/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
       <D:prop> 
         <D:principal-collection-set/> 
       </D:prop> 
     </D:propfind> 
    

     >> Response << 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 26] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:">  
       <D:response>  
         <D:href>http://www.webdav.org/papers/</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:principal-collection-set> 
               <D:href> 
                 http://www.webdav.org/_acl/users/ 
               </D:href> 
               <D:href> 
                 http://www.webdav.org/_acl/groups/ 
               </D:href> 
             </D:principal-collection-set> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       </D:response> 
     </D:multistatus> 

5.7 Example: PROPFIND to retrieve access control properties 

   The following example shows how access control information can be 
   retrieved by using the DAV:allowed-ace element states that only 
        one ACE is permitted for each principal, and an ACE describing PROPFIND method to fetch the privileges granted values of the DAV:all principal must exist in 
        every ACL. 
   DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
   set, and DAV:acl properties.  

     >> Request << 
      
     PROPFIND /papers/ /top/container/ HTTP/1.1 
     Host: www.webdav.org www.foo.org 
     Content-type: text/xml; charset="utf-8"  
     Content-Length: xxx 
     Depth: 0 
     Authorization: Digest username="srcarter",  
           realm="srcarter@webdav.org", username="ejw",  
        realm="users@foo.org", nonce="...", 
           uri="/papers/", 
        uri="/top/container/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:propfind xmlns:D="DAV:"> 
          <D:acl-semantics/> 
       <D:prop> 
         <D:owner/> 
         <D:supported-privilege-set/> 
         <D:current-user-privilege-set/> 
         <D:acl/> 
       </D:prop> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 27] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     </D:propfind> 
      
     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:"> 
        xmlns:D="DAV:" 
        xmlns:A="http://www.webdav.org/acl/"> <D:response>  
            <D:href>http://www.webdav.org/papers/</D:href>  
       <D:href>http://www.foo.org/top/container/</D:href> 
       <D:propstat> 
       <D:prop> 
         <D:owner> 
           <D:href>http://www.foo.org/users/gclemm</D:href> </D:owner> 
         <D:supported-privilege-set> 
           <D:supported-privilege> 
             <D:privilege> <D:all/> </D:privilege> 
             <D:abstract/> 
             <D:description xml:lang="en">Any operation</D:description> 
             <D:supported-privilege> 
               <D:privilege> <D:read/> </D:privilege> 
               <D:description xml:lang="en">Read any 
     object</D:description> 
             </D:supported-privilege> 
             <D:supported-privilege> 
               <D:privilege> <D:write/> </D:privilege> 
               <D:abstract/> 
               <D:description xml:lang="en">Write any 
     object</D:description> 
               <D:supported-privilege> 
                 <D:privilege> <A:create/> </D:privilege> 
                 <D:description xml:lang="en">Create an 
     object</D:description> 
               </D:supported-privilege> 
               <D:supported-privilege> 
                 <D:privilege> <A:update/> </D:privilege> 
                 <D:description xml:lang="en">Update an 
     object</D:description> 
               </D:supported-privilege> 
               <D:supported-privilege> 
                 <D:privilege> <A:delete/> </D:privilege> 
                 <D:description xml:lang="en">Delete an 
     object</D:description> 
               </D:supported-privilege> 
             </D:supported-privilege> 
             <D:supported-privilege> 
               <D:privilege> <D:read-acl/> </D:privilege> 
               <D:description xml:lang="en">Read the ACL</D:description>

Clemm, Hopkins, Sedlar, Whitehead                          [Page 28] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

             </D:supported-privilege> 
             <D:supported-privilege> 
               <D:privilege> <D:write-acl/> </D:privilege> 
               <D:description xml:lang="en">Write the 
     ACL</D:description> 
             </D:supported-privilege> 
           </D:supported-privilege> 
         </D:supported-privilege-set> 
         <D:current-user-privilege-set> 
           <D:privilege> <D:read/> </D:privilege> 
           <D:privilege> <D:read-acl/> </D:privilege> 
         </D:current-user-privilege-set> 
         <D:acl> 
           <D:ace> 
             <D:principal> 
               <D:href>http://www.foo.org/users/esedlar</D:href> 
               </D:principal>  
             <D:grant> 
               <D:privilege> <D:read/> </D:privilege> 
               <D:privilege> <D:write/> </D:privilege> 
               <D:privilege> <D:read-acl/> </D:privilege> </D:grant> 
           </D:ace> 
           <D:ace> 
             <D:principal> 
               <D:href>http://www.foo.org/groups/marketing/</D:href> 
             </D:principal> 
             <D:deny> 
               <D:privilege> <D:read/> </D:privilege> </D:deny> 
           </D:ace> 
           <D:ace> 
             <D:principal> 
               <D:property> <D:owner/> </D:property> </D:principal> 
             <D:grant> 
               <D:privilege> <D:read-acl/> </D:privilege> 
               <D:privilege> <D:write-acl/> </D:privilege> </D:grant> 
           </D:ace> 
           <D:ace> 
             <D:principal> <D:all/> </D:principal> 
             <D:grant> 
               <D:privilege> <D:read/> </D:privilege></D:grant> 
             <D:inherited> 
               <D:href>http://www.foo.org/top/</D:href> </D:inherited> 
           </D:ace> </D:acl> 
         </D:prop> 
         <D:status>HTTP/1.1 200 OK</D:status> 
              <D:prop> 
                <D:acl-semantics> 
                  <D:ace-combination> 
                    <D:first-match/> 
                  </D:ace-combination> 
                  <D:ace-ordering/> 
                  <D:allowed-ace> 
                    <D:principal-only-one-ace/> 
                  </D:allowed-ace> 
                  <D:required-principal> 
       </D:propstat> </D:response> </D:multistatus> 
    

   The value of the DAV:owner property is a single DAV:href XML element 
   containing the URL of the principal that owns this resource.  

Clemm, Hopkins, Sedlar, Whitehead                          [Page 21] 29] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


                    <D:all/> 
                  </D:required-principal> 
                </D:acl-semantics> 
              </D:prop> 
            </D:propstat> 
          <D:response> 
        </D:multistatus> 
         

   5.6 DAV:principal-collection-set 

        This protected 

   The value of the DAV:supported-privilege-set property contains zero, one, or more URLs that 
        identify a collection principal. It is expected that 
        implementations a tree of this protocol will typically use 
   supported privileges: 

       DAV:all (aggregate, abstract) 
           | 
         +-- DAV:read 
         +-- DAV:write (aggregate, abstract) 
              | 
              +-- http://www.webdav.org/acl/create 
              +-- http://www.webdav.org/acl/update 
              +-- http://www.webdav.org/acl/delete 
           +-- DAV:read-acl 
           +-- DAV:write-acl 
    

   The DAV:current-user-privilege-set property contains two privileges, 
   DAV:read, and DAV:read-acl. This indicates that the current 
   authenticated user only has the ability to read the resource, and 
   read the DAV:acl property on the resource. 

   The DAV:acl property contains a 
        relatively small number set of locations in four ACEs: 

   ACE #1: The principal identified by the URL namespace for 
        principal, 
   http://www.foo.org/users/esedlar is granted the DAV:read, DAV:write, 
   and DAV:read-acl privileges. 

   ACE #2: The principals identified by the URL 
   http://www.foo.org/groups/marketing/ are denied the DAV:read 
   privilege.  In this example, the principal URL identifies a group, 
   which is represented by a collection principals. principal. 

   ACE #3: In cases where this 
        assumption holds, ACE, the DAV:principal-collection-set property 
        will contain principal is a small set of URLs identifying property principal, 
   specifically the top DAV:owner property. When evaluating this ACE, the 
   value of the DAV:owner property is retrieved, and is examined to see 
   if it contains a 
        collection hierarchy containing multiple principals DAV:href XML element. If so, the URL within the 
   DAV:href element is read, and 
        collection principals. An access control protocol user agent 
        could use identifies a principal. In this ACE, 
   the owner is granted DAV:read-acl, and DAV:write-acl privileges. 

   ACE #4: This ACE grants the DAV:all principal (all users) the 
   DAV:read privilege. This ACE is inherited from the contents of DAV:principal-collection-set to query resource 
   http://www.foo.org/top/, the DAV:displayname property (specified in Section 13.2 of 
        [RFC2518]) parent collection of all principals on that server, thereby yielding 
        human-readable names for each principal this resource. 


6  ACL SEMANTICS 

   The ACL semantics define how multiple ACEs that could be displayed 
        in a match the current 
   user interface. 

        <!ELEMENT principal-collection-set (href*)> 

        Since different servers can control different parts of are combined, what are the URL 
        namespace, different resources constraints on the same host MAY how ACEs can be 
   ordered, and which principals must have 
        different DAV:principal-collection-set values. an ACE. 

     <!ELEMENT acl-semantics (ace-combination?, ace-ordering?, allowed-
     ace?, required-principal?)> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 30] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

6.1 ACE Combination 

   The collections 
        specified in DAV:ace-combination element defines how privileges from multiple 
   ACEs that match the DAV:principal-collection-set MAY current user will be located on 
        different hosts from combined to determine the resource. The URLs 
   access privileges for that user.  Multiple ACEs may match the same 
   user because the same principal can appear in DAV:principal-
        collection-set SHOULD be http or https scheme URLs. For 
        security and scalability reasons, a server MAY report only a 
        subset of multiple ACEs, because 
   multiple principals can identify the entire set of known collection principals, same user, and 
        therefore clients should not assume they have retrieved an 
        exhaustive listing. Additionally, because one 
   principal can be a server MAY elect to report 
        none member of another principal.   

     <!ELEMENT ace-combination 
      (first-match | all-grant-before-any-deny | specific-deny-
     overrides-grant)> 

6.1.1 DAV:first-match ACE Combination 

   The ACEs are evaluated in the collection principals it knows about, order in which case 
        the property value would be empty. 

   5.6.1 Example: Retrieving DAV:principal-collection-set 

        In this example, they appear in the client requests ACL. 
   If the value of first ACE that matches the 
        DAV:principal-collection-set property on current user does not grant all the collection 
        resource identified by URL http://www.webdav.org/papers/.
   privileges needed for the request, the request MUST fail. 

     <!ELEMENT first-match EMPTY> 

6.1.2 DAV:all-grant-before-any-deny ACE Combination 

   The 
        property contains ACEs are evaluated in the two URLs, 
        http://www.webdav.org/_acl/users/ and 
        http://www.webdav.org/_acl/groups/, both wrapped order in <DAV:href> 
        XML elements. Digest authentication provides credentials which they appear in the ACL. 
   If an evaluated ACE denies a privilege needed for the principal operating request, the client. 

        The client might reasonably follow this 
   request with two 
        separate PROPFIND requests to retrieve the DAV:displayname 


   Clemm, Hopkins, Sedlar, Whitehead                      [Page 22] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        property of the members of MUST fail.  If all ACEs have been evaluated without the two collections (/_acl/users/ 
        and /_acl_groups/). This information could be used when 
        displaying a user interface 
   being granted all privileges needed for creating access control 
        entries. 

         
        >> Request << 
         
        PROPFIND /papers/ HTTP/1.1 
        Host: www.webdav.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="yarong",  
           realm="yarong@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propfind xmlns:D="DAV:"> 
          <D:principal-collection-set/> 
        </D:propfind> 

        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus xmlns:D="DAV:">  
          <D:response>  
            <D:href>http://www.webdav.org/papers/</D:href> 
            <D:propstat> 
              <D:status>HTTP/1.1 200 OK</D:status> 
              <D:prop> 
                <D:principal-collection-set> 
                  <D:href> 
                    http://www.webdav.org/_acl/users/ 
                  </D:href> 
                  <D:href> 
                    http://www.webdav.org/_acl/groups/ 
                  </D:href> 
                </D:principal-collection-set> 
              </D:prop> 
            </D:propstat>
          </D:response>
        </D:multistatus>
         
   5.7 Example: PROPFIND to retrieve access control properties the request, the request MUST
   fail.  

     <!ELEMENT all-grant-before-any-deny EMPTY> 

6.1.3 DAV:specific-deny-overrides-grant ACE Combination 

   All ACEs in the ACL are evaluated.  An "individual ACE" is one whose 
   principal identifies the current user.  A "group ACE" is one whose 
   principal is a collection that contains a principal that identifies 
   the current user.  A privilege is granted if it is granted by an 
   individual ACE and not denied by an individual ACE, or if it is 
   granted by a group ACE and not denied by an individual or group ACE. 
   A request MUST fail if any of its needed privileges are not granted. 

     <!ELEMENT specific-deny-overrides-grant EMPTY> 

6.2 ACE Ordering 

   The following example shows DAV:ace-ordering element defines a constraint on how access control information the ACEs can
   be retrieved by using the PROPFIND method to fetch the values 
        of ordered in the DAV:owner, DAV:supported-privilege-set, DAV:current-
        user-privilege-set, and DAV:acl properties.  

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 23] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        >> Request << 
         
        PROPFIND /top/container/ HTTP/1.1 
        Host: www.foo.org 
        Content-type: text/xml; charset="utf-8"  
        Content-Length: xxx 
        Depth: 0 
        Authorization: Digest username="ejw",  
           realm="users@foo.org", nonce="...", 
           uri="/top/container/", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:propfind xmlns:D="DAV:"> 
          <D:owner/> 
          <D:supported-privilege-set/> 
          <D:current-user-privilege-set/> 
          <D:acl/> 
        </D:propfind> 
         
        >> Response << 
         
        HTTP/1.1 207 Multi-Status 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus 
           xmlns:D="DAV:" 
           xmlns:A="http://www.webdav.org/acl/"> <D:response>  
          <D:href>http://www.foo.org/top/container/</D:href> 
          <D:propstat> 
          <D:status>HTTP/1.1 200 OK</D:status> 
          <D:prop> 
            <D:owner> 
              <D:href>http://www.foo.org/users/gclemm</D:href> 
            </D:owner> 
            <D:supported-privilege-set> 
              <D:supported-privilege> 
                <D:privilege> <D:all/> </D:privilege> 
                <D:abstract/> 
                <D:description>Any operation</D:description> 
                <D:supported-privilege> 
                  <D:privilege> <D:read/> </D:privilege> 
                  <D:description>Read any object</D:description> 
                </D:supported-privilege> 
                <D:supported-privilege> 
                  <D:privilege> <D:write/> </D:privilege> 
                  <D:abstract/> 
                  <D:description>Write any object</D:description> 
                  <D:supported-privilege> 
                    <D:privilege> <A:create/> </D:privilege> 
                    <D:description>Create an object</D:description> 
                  </D:supported-privilege> 
                  <D:supported-privilege> ACL.   

     <!ELEMENT ace-ordering (deny-before-grant)? > 



Clemm, Hopkins, Sedlar, Whitehead                          [Page 24] 31] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


                    <D:privilege> <A:update/> </D:privilege> 
                    <D:description>Update 

6.2.1 DAV:deny-before-grant ACE Ordering 

   This element indicates that all deny ACEs must precede all grant 
   ACEs. 

     <!ELEMENT deny-before-grant EMPTY> 

6.3 Allowed ACE 

   The DAV:allowed-ace XML element specifies constraints on what kinds 
   of ACEs are allowed in an object</D:description> 
                  </D:supported-privilege> 
                  <D:supported-privilege> 
                    <D:privilege> <A:delete/> </D:privilege> 
                    <D:description>Delete ACL. 

     <!ELEMENT allowed-ace (principal-only-one-ace | grant-only)*> 

6.3.1 DAV:principal-only-one-ace ACE Constraint 

   This element indicates that a principal can appear in only one ACE 
   per resource. 

     <!ELEMENT principal-only-one-ace EMPTY> 

6.3.2 DAV:grant-only ACE Constraint 

   This element indicates that ACEs with deny clauses are not allowed. 

     <!ELEMENT grant-only EMPTY> 

6.4 Required Principals 

   The required principal elements identify which principals must have 
   an object</D:description> 
                  </D:supported-privilege> 
                </D:supported-privilege> 
                <D:supported-privilege> 
                  <D:privilege> <D:read-acl/> </D:privilege> 
                  <D:description>Read ACE defined in the ACL</D:description> 
                </D:supported-privilege> 
                <D:supported-privilege> 
                  <D:privilege> <D:write-acl/> </D:privilege> 
                  <D:description>Write ACL.   

     <!ELEMENT required-principal 
       (all? | authenticated? | unauthenticated? | self? | href* | 
     property*)> 
      
   For example, the ACL</D:description> 
                </D:supported-privilege> 
              </D:supported-privilege> 
            </D:supported-privilege-set> 
            <D:current-user-privilege-set> 
              <D:privilege> <D:read/> </D:privilege> 
              <D:privilege> <D:read-acl/> </D:privilege> 
            </D:current-user-privilege-set> 
            <D:acl> 
              <D:ace> 
                <D:principal> 
                  <D:href>http://www.foo.org/users/esedlar</D:href> 
                  </D:principal>  
                <D:grant> 
                  <D:privilege> <D:read/> </D:privilege> 
                  <D:privilege> <D:write/> </D:privilege> 
                  <D:privilege> <D:read-acl/> </D:privilege> </D:grant> 
              </D:ace> 
              <D:ace> 
                <D:principal> 
                  <D:href>http://www.foo.org/groups/marketing/</D:href> 
                </D:principal> 
                <D:deny> 
                  <D:privilege> <D:read/> </D:privilege> </D:deny> 
              </D:ace> 
              <D:ace> 
                <D:principal> following element requires that the ACL contain a 
   DAV:owner property ACE: 

     <D:required-principal xmlns:D="DAV:"> 
       <D:property> <D:owner/> </D:property> </D:principal> 
                <D:grant> 
                  <D:privilege> <D:read-acl/> </D:privilege> 
                  <D:privilege> <D:write-acl/> </D:privilege> 
                </D:grant> 
              </D:ace> 
              <D:ace> 
                <D:principal> <D:all/> </D:principal> 
                <D:grant> 
                  <D:privilege> <D:read/> </D:privilege></D:grant> 
                <D:inherited> 
                  <D:href>http://www.foo.org/top/</D:href> 
        </D:inherited> 
     </D:required-principal> 


7  ACCESS CONTROL AND EXISTING METHODS 

   This section defines the impact of access control functionality on 
   existing methods. 




Clemm, Hopkins, Sedlar, Whitehead                          [Page 25] 32] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


              </D:ace> </D:acl> 
            </D:prop> 
          </D:propstat> </D:response> </D:multistatus> 
         

        The value of 

7.1 OPTIONS 

   If the DAV:owner property is server supports access control, it MUST return "access-
   control" as a single DAV:href XML 
        element containing the URL of field in the principal DAV response header from an OPTIONS 
   request on any resource implemented by that owns server. 

7.1.1 Example - OPTIONS 

     >> Request << 
      
       OPTIONS /foo.html HTTP/1.1  
       Host: www.webdav.org 
       Content-Length: 0 
         
     >> Response << 
      
       HTTP/1.1 200 OK 
       DAV: 1, 2, access-control 
       Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL 
      
   In this 
        resource.  

        The value of example, the DAV:supported-privilege-set property is a tree 
        of supported privileges: 

          DAV:all (aggregate, abstract) 
              | 
            +-- DAV:read 
            +-- DAV:write (aggregate, abstract) 
                 | 
                 +-- http://www.webdav.org/acl/create 
                 +-- http://www.webdav.org/acl/update 
                 +-- http://www.webdav.org/acl/delete 
              +-- DAV:read-acl 
              +-- DAV:write-acl 
         

        The DAV:current-user-privilege-set property contains two 
        privileges, DAV:read, and DAV:read-acl. This OPTIONS response indicates that the 
        current authenticated user only has server 
   supports access control and that /foo.html can have its access 
   control list modified by the ability ACL method. 

7.2 MOVE 

   When a resource is moved from one location to read another due to a MOVE 
   request, the 
        resource, non-inherited and read the DAV:acl property on non-protected ACEs in the resource. 

        The DAV:acl 
   property contains a set of four ACEs: 

        ACE #1: The principal identified by the URL 
        http://www.foo.org/users/esedlar is granted resource MUST NOT be modified, or the DAV:read, 
        DAV:write, MOVE request 
   fails. Handling of inherited and DAV:read-acl privileges. protected ACEs is intentionally 
   undefined to give server implementations flexibility in how they 
   implement ACE #2: inheritance and protection. 

7.3 COPY 

   The principals identified by the URL 
        http://www.foo.org/groups/marketing/ are denied the DAV:read 
        privilege.  In this example, DAV:acl property on the principal URL identifies a 
        group, which is represented by a collection principal. 

        ACE #3: In this ACE, resource at the principal is destination of a property principal, 
        specifically COPY 
   MUST be the DAV:owner property. When evaluating this ACE, same as if the value of resource was created by an individual 
   resource creation request (e.g. MKCOL, PUT). Clients wishing to 
   preserve the DAV:owner DAV:acl property is retrieved, and is 
        examined to see if it contains across a DAV:href XML element. If so, copy need to read the URL within DAV:acl 
   property prior to the DAV:href element is read, and identifies a 
        principal. In this ACE, COPY, then perform an ACL operation on the owner new 
   resource at the destination to restore, insofar as this is granted DAV:read-acl, possible, 
   the original access control list. 

7.4 DELETE 

   The precise combination of privileges and 
        DAV:write-acl privileges. 

        ACE #4: This ACE grants resources necessary to 
   permit the DAV:all principal (all users) DELETE method is intentionally left to the 
        DAV:read privilege. This ACE discretion of 
   each server implementation. It is inherited from envisioned that on some servers, 
   DELETE will require write permission on the collection containing the
   resource 
        http://www.foo.org/top/, to be deleted.  On other servers, it might also require 
   write permission on the parent collection of this 
        resource. resource being deleted. 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 26] 33] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


   6  ACL SEMANTICS 

        The ACL semantics define how multiple ACEs 

7.5 LOCK 

   A lock on a resource ensures that match the 
        current user are combined, what are only the constraints on how ACEs lock owner can be ordered, and which principals must have an ACE. 

        <!ELEMENT acl-semantics acl-sem*> 
          
        <!ELEMENT acl-sem (ace-combination, ace-ordering, allowed-ace, 
        required-principal*)> 

   6.1 ACE Combination 

        The DAV:ace-combination element defines how privileges from 
        multiple modify ACEs
   that match the current user will be combined to 
        determine are not inherited and not protected  (these are the access privileges for that user.  Multiple only ACEs 
        may match the same user because the same principal 
   that a client can appear 
        in multiple modify with an ACL request). A lock does not 
   protect inherited or protected ACEs, because multiple principals can identify the 
        same user, and because one principal can be since a member of another 
        principal.   

        <!ELEMENT ace-combination 
         (first-match | all-grant-before-any-deny | specific-deny-
        overrides-grant)> 

   6.1.1 DAV:first-match ACE Combination client cannot modify 
   them with an ACL request on that resource. 


8  ACCESS CONTROL METHODS 

8.1 ACL 

   The ACEs are evaluated in ACL method modifies the order in which they appear in access control list (which can be read 
   via the 
        ACL.  If DAV:acl property) of a resource.  Specifically, the first ACE ACL 
   method only permits modification to ACEs that matches the current user does are not 
        grant inherited, and 
   are not protected. An ACL method invocation modifies all non-
   inherited and non-protected ACEs in a resourceÆs access control list 
   to exactly match the privileges needed for ACEs contained within in the request, DAV:acl XML element
   (specified in Section 5.4) of the request body. An ACL request body 
   MUST fail. 

        <!ELEMENT first-match EMPTY> 

   6.1.2 DAV:all-grant-before-any-deny ACE Combination 

        The contain only one DAV:acl XML element. Unless the non-inherited 
   and non-protected ACEs are evaluated in of the order in which they appear in DAV:acl property of the 
        ACL.  If an evaluated ACE denies a privilege needed for resource can be
   updated to be exactly the value specified in the ACL request, the ACL
   request MUST fail.  If all  

   It is possible that the ACEs have been 
        evaluated without visible to the current user being granted all privileges needed 
        for in the request, 
   DAV:acl property may only be a portion of the request MUST fail.  

        <!ELEMENT all-grant-before-any-deny EMPTY> 

   6.1.3 DAV:specific-deny-overrides-grant ACE Combination 

        All complete set of ACEs in on
   that resource. If this is the case, an ACL are evaluated.  An "individual ACE" is one 
        whose principal identifies request only modifies the current user.  A "group ACE" is 
        one whose principal is a collection that contains a principal 
        that identifies 
   set of ACEs visible to the current user.  A privilege is granted if it 
        is granted by an individual ACE user, and does not denied by an individual 
        ACE, or if it is granted affect any non-
   visible ACE. 

   In order to avoid overwriting DAV:acl changes by another client, a group ACE and not denied by an 
        individual or group ACE.  A request MUST fail if any of its 
        needed privileges are not granted. 


   Clemm, Hopkins, Sedlar, Whitehead                      [Page 27] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        <!ELEMENT specific-deny-overrides-grant EMPTY> 

   6.2 ACE Ordering 

        The DAV:ace-ordering element defines 
   client SHOULD acquire a constraint WebDAV lock on how the 
        ACEs can be ordered in resource before retrieving
   the ACL.   

        <!ELEMENT ace-ordering (deny-before-grant)? > 

   6.2.1 DAV:deny-before-grant ACE Ordering 

        This element indicates DAV:acl property of a resource that all deny ACEs must precede all 
        grant ACEs. 

        <!ELEMENT deny-before-grant EMPTY> 

   6.3 Allowed ACE 

        The DAV:allowed-ace XML element specifies constraints it intends on what 
        kinds of ACEs updating. 

     Implementation Note: Two common operations are allowed in to add or remove an ACL. 

        <!ELEMENT allowed-ace (principal-only-one-ace | grant-only)*> 

   6.3.1 DAV:principal-only-one-ace 
     ACE Constraint 

        This element indicates that from an existing access control list. To accomplish this, a principal 
     client uses the PROPFIND method to retrieve the value of the 
     DAV:acl property, then parses the returned access control list to 
     remove all inherited and protected ACEs (these ACEs are tagged 
     with the DAV:inherited and DAV:protected XML elements). In the 
     remaining set of non-inherited, non-protected ACEs, the client can appear in only 
     add or remove one 
        ACE per resource. 

        <!ELEMENT principal-only-one-ace EMPTY> 

   6.3.2 DAV:grant-only ACE Constraint 

        This element indicates that or more ACEs with deny clauses are not 
        allowed. 

        <!ELEMENT grant-only EMPTY> 

   6.4 Required Principals 

        The required principal elements identify which principals must 
        have an before submitting the final ACE defined set 
     in the ACL.   

        <!ELEMENT required-principal 
          (href | all | authenticated | unauthenticated | property | 
        self)> 
         
        For example, request body of the following element requires that ACL method. 

8.1.1 ACL Preconditions 

   An implementation MAY enforce one or more of the following 
   constraints on an ACL 
        contain request.  If the constraint is violated, a DAV:owner property ACE: 

        <D:required-principal xmlns:D="DAV:"> 
          <D:property> <D:owner/> </D:property> 
        </D:required-principal> 403 
   (Forbidden) response MUST be returned and the indicated XML element 
   MUST be returned as the top level element in an XML response body. 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 28] 34] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


   7  ACCESS CONTROL AND EXISTING METHODS 

        This section defines the impact of access control functionality 
        on existing methods. 

   7.1 OPTIONS 

        If the server supports access control, it MUST return "access-
        control" as a field 

   <DAV:ace-conflict/>: A conflict exists between two or more ACEs 
   submitted in the DAV response header from ACL request.  

   <DAV:protected-ace-conflict/>: A conflict exists between an OPTIONS ACE in 
   the ACL request and a protected ACE on any the resource. For example, if 
   the resource implemented by that server. 

   7.1.1 Example - OPTIONS 

        >> Request << 
         
          OPTIONS /foo.html HTTP/1.1  
          Host: www.webdav.org 
          Content-Length: 0 
            
        >> Response << 
         
          HTTP/1.1 200 OK 
          DAV: 1, 2, access-control 
          Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, has a protected ACE granting DAV:write to a given 
   principal, then it would be a protected ACE conflict if the ACL 
         
        In this example, 
   request submitted an ACE denying DAV:write to the OPTIONS response indicates that same principal. 

   <DAV:inherited-ace-conflict/>: A conflict exists between an ACE in 
   the server 
        supports access control ACL request and that /foo.html can have its access 
        control list modified by an inherited ACE on the resource. For example, if
   the ACL method. 

   7.2 MOVE 

        When a resource is moved inherits an ACE from one location to another due its parent collection granting 
   DAV:write to a 
        MOVE request, given principal, then it would be an inherited ACE 
   conflict if the non-inherited ACEs in ACL request submitted an ACE denying DAV:write to the DAV:acl property
   same principal. Note that reporting of 
        the resource MUST NOT this error will be modified, 
   implementation-dependent. Implementations have the choice to either 
   report this error, or to allow the MOVE request fails. 

   7.3 COPY 

        The DAV:acl property ACE to be set, and then let normal
   ACE evaluation rules determine whether the new ACE has any impact on 
   the resource at privileges available to a specific principal. 

   <DAV:too-many-aces/>: An implementation MAY limit the destination number of ACEs 
   in an ACL.  However, ACL-compliant servers MUST support at least one 
   ACE granting privileges to a 
        COPY single principal, and one ACE granting 
   privileges to a collection principal. 

   <DAV:deny-before-grant/>: All non-inherited deny ACEs MUST be precede 
   all non-inherited grant ACEs. 

   <DAV:principal-only-one-ace/>: For implementations that have the same as if 
   DAV:principal-only-one-ace constraint (defined in Section 6.3.1), 
   this XML element indicates that fulfilling the resource was created by an 
        individual resource creation request (e.g. MKCOL, PUT). 

   8  ACCESS CONTROL METHODS 

   8.1 ACL 

        The ACL method modifies request would 
   result in multiple ACEs for one or more principals. 

   <DAV:grant-only/>: For implementations that have the access control list (which can be 
        read via DAV:grant-only 
   constraint (defined in Section 6.3.2), this XML element indicates the DAV:acl property)
   request contained one or more deny ACEs. 

   <DAV:no-abstract/>: The ACL request attempts to set an abstract 
   privilege in an ACE (see Section 5.2). 

   <DAV:supported-privilege/>: One or more of a resource.  Specifically, the privileges in the ACL method only permits modification to ACEs that are 
   request is not 
        inherited, and are supported by the resource. 

   <DAV:required-principal/>: One or more required principals (see 
   Section 6.4) would not protected. An ACL method invocation 
        modifies all non-inherited and non-protected ACEs be present in a 
        resource's the access control list to exactly match the ACEs 
        contained within in after 
   processing the DAV:acl ACL request. The DAV:required-principal XML element (specified 
   MUST contain a list of the missing principal(s), following the syntax
   specified in Section 5.4) 6.4. 

   <DAV:recognized-principal/>: One or more of the request body. An principal URLs in the
   ACL request body MUST 
        contain only one DAV:acl XML element. Unless the non-inherited does not identify a principal resource. 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 29] 35] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


        and non-protected ACEs of the DAV:acl property 

   <DAV:allowed-principal/>: One or more of the resource 
        can be updated to be exactly the value specified principal URLs in the 
   ACL 
        request, the ACL request MUST fail.  

        It is possible that the ACEs visible to the current user not allowed in the 
        DAV:acl property may only be a portion of the complete set of 
        ACEs on that resource. If this is the case, an ACL request only 
        modifies the set of ACEs visible to the current user, and does 
        not affect any non-visible ACE. 

        In order to avoid overwriting DAV:acl changes by another 
        client, a client SHOULD acquire a WebDAV lock on the resource 
        before retrieving the DAV:acl property of For example, a resource that it 
        intends on updating. 

         

          Implementation Note: Two common operations are to add or 
          remove an ACE from an existing server where 
   only authenticated principals can access control list. To 
          accomplish this, a client uses resources would not allow 
   the PROPFIND method DAV:all or DAV:unauthenticated principals to 
          retrieve the value of the DAV:acl property, then parses the 
          returned be used in an ACE, 
   since these would allow unauthenticated access control list to remove all inherited and 
          protected ACEs (these ACEs are tagged with resources. 

8.1.2 Example: the DAV:inherited 
          and DAV:protected XML elements). ACL method 

   In the remaining set of non-
          inherited, non-protected ACEs, following example, user "fielding", authenticated by 
   information in the client can add or remove 
          one or more ACEs before submitting Authorization header, grants the final ACE set in principal 
   identified by the 
          request body URL http://www.foo.org/users/esedlar  (i.e., the 
   user "esedlar") read and write privileges, grants the owner of the 
   resource read-acl and write-acl privileges, and grants everyone read 
   privileges.  

     >> Request << 
      
     ACL method. 

   8.1.1 /top/container/ HTTP/1.1 
     Host: www.foo.org 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
     Authorization: Digest username="fielding",  
        realm="users@foo.org", nonce="...", 
        uri="/top/container/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:acl xmlns:D="DAV:"> 
       <D:ace> 
         <D:principal> 
           <D:href>http://www.foo.org/users/esedlar</D:href> 
         </D:principal> 
         <D:grant> 
           <D:privilege> <D:read/> </D:privilege> 
           <D:privilege> <D:write/> </D:privilege>  
         </D:grant> 
       </D:ace> 
       <D:ace> 
         <D:principal> 
           <D:property> <D:owner/> </D:property>  
         </D:principal> 
         <D:grant> 
           <D:privilege> <D:read-acl/> </D:privilege> 
           <D:privilege> <D:write-acl/> </D:privilege>  
         </D:grant> 
       </D:ace> 
       <D:ace> 
         <D:principal> <D:all/> </D:principal> 
         <D:grant> 
           <D:privilege> <D:read/> </D:privilege> 
         </D:grant> 
       </D:ace>  

Clemm, Hopkins, Sedlar, Whitehead                          [Page 36] 

INTERNET-DRAFT                WebDAV ACL Preconditions 

        An implementation MAY enforce one or more of            November 9, 2001 

     </D:acl> 
      
     >> Response << 
      
     HTTP/1.1 200 OK 

8.1.3 Example: ACL method failure due to protected ACE conflict 

   In the following 
        constraints on an ACL request.  If request, user "fielding", authenticated by 
   information in the constraint is violated, 
        a 403 (Forbidden) response MUST be returned and Authorization header, attempts to deny the indicated 
        XML element MUST be returned as 
   principal identified by the top level element in an XML 
        response body. 

        <DAV:ace-conflict/>: A conflict exists between two or more ACEs 
        submitted in URL http://www.foo.org/users/esedlar  
   (i.e., the user "esedlar") write privileges. Prior to the ACL request.  

        <DAV:protected-ace-conflict/>: A conflict exists between an ACE 
        in request, 
   the ACL request and a protected ACE DAV:acl property on the resource. For 
        example, if the resource has contained a protected ACE (see 
   Section 5.4.3) granting DAV:owner the DAV:read and DAV:write 
        to a given principal, then it would be a protected ACE conflict 
        if 
   privileges. The principal identified by URL 
   http://www.foo.org/users/esedlar is the owner of the resource. The 
   ACL request method invocation fails because the submitted an ACE denying DAV:write to conflicts with 
   the 
        same principal. 

        <DAV:inherited-ace-conflict/>: A conflict exists between an ACE 
        in protected ACE, thus violating the semantics of ACE protection. 

     >> Request << 
      
     ACL request and /top/container/ HTTP/1.1 
     Host: www.foo.org 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
     Authorization: Digest username="fielding",  
        realm="users@foo.org", nonce="...", 
        uri="/top/container/", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:acl xmlns:D="DAV:"> 
       <D:ace> 
         <D:principal> 
           <D:href>http://www.foo.org/users/esedlar</D:href> 
         </D:principal> 
         <D:deny>  
           <D:privilege> <D:write/> </D:privilege>  
         </D:deny> 
       </D:ace> 
     </D:acl> 
      
     >> Response << 
      
     HTTP/1.1 403 Forbidden 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:protected-ace-conflict xmlns:D="DAV:"/> 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 37] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

8.1.4 Example: ACL method failure due to an inherited ACE on conflict 

   In the resource. For 
        example, if following request, user "ejw", authenticated by information in
   the Authorization header, tries to change the access control list on 
   the resource inherits http://www.foo.org/top/index.html. This resource has two
   inherited ACEs.  

   Inherited ACE #1 grants the principal identified by URL 
   http://www.foo.org/users/ejw (i.e., the user "ejw") 
   http://www.foo.org/privs/write-all and DAV:read-acl privileges. On 
   this server, http://www.foo.org/privs/write-all is an aggregate 
   privilege containing DAV:write, and DAV:write-acl.  

   Inherited ACE from its parent 
        collection granting #2 grants principal DAV:all the DAV:read privilege. 

   The request attempts to set a (non-inherited) ACE, denying the 
   principal identified by the URL http://www.foo.org/users/ejw (i.e., 
   the user ôejw") DAV:write to a given principal, then it 
        would be an permission. This conflicts with inherited 
   ACE conflict if the ACL request submitted 
        an ACE denying DAV:write to the same principal. #1. Note that 
        reporting of this error will be implementation-dependent. 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 30] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        Implementations have the choice decision to either report this error, or an inherited ACE conflict is
   specific to allow this server implementation. Another server implementation
   could have allowed the new ACE to be set, and then let used normal ACE 
   evaluation rules to determine whether the new ACE has any impact on 
   the privileges available to a specific principal. 

        <DAV:too-many-aces/>: An implementation MAY limit the number of 
        ACEs in an ACL.  However, ACL-compliant servers MUST support at 
        least one ACE granting privileges to a single principal, and 
        one ACE granting privileges to a collection principal. 

        <DAV:deny-before-grant/>: All non-inherited deny ACEs MUST 
        precede all non-inherited grant ACEs. 

        <DAV:principal-only-one-ace/>: For implementations that have 
        the DAV:principal-only-one-ace constraint (defined in Section 
        6.3.1), this XML element indicates that fulfilling the ACL 
        request would result in multiple ACEs for one or more 
        principals. 

        <DAV:grant-only/>: For implementations that have the DAV:grant-
        only constraint (defined in Section 6.3.2), this XML element 
        indicates the request contained one or more deny ACEs. 

        <DAV:required-principal>: One or more required principals (see 
        Section 6.4) would not be present in the access control list 
        after processing the 

     >> Request << 
      
     ACL request. The DAV:required-principal 
        XML element MUST contain a list of the missing principal(s), 
        following the syntax specified in Section 6.4. 


   8.1.2 /top/index.html HTTP/1.1 
     Host: www.foo.org 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
     Authorization: Digest username="ejw",  
        realm="users@foo.org", nonce="...", 
        uri="/top/index.html", response="...", opaque="..." 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:acl xmlns:D="DAV:" xmlns:F="http://www.foo.org/privs/"> 
       <D:ace> 
         <D:principal> 
           <D:href>http://www.foo.org/users/ejw</D:href> 
         </D:principal> 
         <D:grant><D:write/></D:grant> 
       </D:ace> 
     </D:acl> 
      
     >> Response << 
      
     HTTP/1.1 403 Forbidden 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 38] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <D:inherited-ace-conflict xmlns:D="DAV:"/> 

8.1.5 Example: the ACL method failure due to an attempt to set grant and 
      deny in a single ACE. 

   In the following this example, user "fielding", "ygoland", authenticated by information in the 
   Authorization header, grants tries to change the access control list on the 
   resource http://www.foo.org/diamond/engagement-ring.gif. The ACL 
   request includes a single, syntactically and semantically incorrect 
   ACE, which attempts to grant the collection principal identified by 
   the URL http://www.foo.org/users/esedlar http://www.foo.org/users/friends/ DAV:read privilege and deny
   the principal identified by URL http://www.foo.org/users/ygoland-so 
   (i.e., the user "esedlar") read "ygoland-so") DAV:read privilege. However, it is 
   illegal to have multiple principal elements, as well as both a grant 
   and write privileges, grants deny element in the owner 
        of same ACE, so the resource read-acl and write-acl privileges, and grants 
        everyone read privileges. request fails due to poor 
   syntax. 

     >> Request << 
      
     ACL /top/container/ /diamond/engagement-ring.gif HTTP/1.1 
     Host: www.foo.org 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
     Authorization: Digest username="fielding", username="ygoland",  
        realm="users@foo.org", nonce="...", 
           uri="/top/container/", 
        uri="/diamond/engagement-ring.gif", response="...", opaque="..."
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:acl xmlns:D="DAV:"> 
       <D:ace> 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 31] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


            <D:principal> 
              <D:href>http://www.foo.org/users/esedlar</D:href> 
            </D:principal> 
            <D:grant> 
              <D:privilege> <D:read/> </D:privilege> 
              <D:privilege> <D:write/> </D:privilege>  
            </D:grant> 
          </D:ace> 
          <D:ace> 
         <D:principal> 
              <D:property> <D:owner/> </D:property> 
           <D:href>http://www.foo.org/users/friends/</D:href> 
         </D:principal> 
            <D:grant> 
              <D:privilege> <D:read-acl/> </D:privilege> 
              <D:privilege> <D:write-acl/> </D:privilege>  
            </D:grant> 
          </D:ace> 
          <D:ace> 
         <D:grant><D:read/></D:grant> 
         <D:principal> <D:all/> 
           <D:href>http://www.foo.org/users/ygoland-so</D:href> 
         </D:principal> 
            <D:grant> 
              <D:privilege> <D:read/> </D:privilege> 
            </D:grant> 
         <D:deny><D:read/></D:deny> 
       </D:ace> 
     </D:acl> 
      
     >> Response << 
      
     HTTP/1.1 200 OK 

   8.1.3 Example: 400 Bad Request 
     Content-Length: 0 
      
   Note that if the request had been divided into two ACEs, one to 
   grant, and one to deny, the request would have been syntactically 
   well formed. 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 39] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

9  ACCESS CONTROL REPORTS 

9.1 REPORT Method 

   The REPORT method (defined in Section 3.6 of [RFCxxxx]) provides an 
   extensible mechanism for obtaining information about a resource.  
   Unlike the PROPFIND method, which returns the value of one or more 
   named properties, the REPORT method failure due can involve more complex 
   processing. REPORT is valuable in cases where the server has access 
   to protected ACE conflict 

        In all of the following request, user "fielding", authenticated by information in needed to perform the Authorization header, attempts complex request (such
   as a query), and where it would require multiple requests for the 
   client to deny retrieve the 
        principal information needed to perform the same 
   request. 

9.2 DAV:acl-principal-props Report 

   The DAV:acl-principle-props report returns, for all principals in the
   DAV:acl property that are identified by http(s) URLs, the value of 
   the properties specified in the REPORT request body. In the case 
   where a principal URL 
        http://www.foo.org/users/esedlar appears multiple times, the DAV:acl-principal-
   props report MUST return the properties for that principal only once.

   Marshalling 

   The request body MUST be a DAV:acl-principal-props XML element. 

     <!ELEMENT acl-principal-props ANY> 
     ANY value: a sequence of one or more elements, with at most one 
     DAV:prop element. 
     prop: see RFC 2518, Section 12.11 
    

   The response body for a successful request MUST be a DAV:multistatus 
   XML element (i.e., the user "esedlar") 
        write privileges. Prior to response uses the request, same format as the response 
   for PROPFIND). 

     multistatus: see RFC 2518, Section 12.9 
      
   The response body for a successful DAV:acl-principal-props REPORT 
   request MUST contain a DAV:response element for each principal 
   identified by an http(s) URL listed in a DAV:principal XML element of
   an ACE within the DAV:acl property on of the resource contained a protected ACE (see Section 5.4.3) 
        granting DAV:owner identified by the 
   Request-URI. 

9.2.1 Example: DAV:acl-principal-props Report 

   Resource http://www.webdav.org/index.html has an ACL with three ACEs:

   ACE #1: All principals (DAV:all) have DAV:read and DAV:write DAV:read-current-
   user-privilege-set access. 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 40] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   ACE #2: The principal identified by 
   http://www.webdav.org/people/gstein (the user ôgstein") is granted 
   DAV:write,  DAV:write-acl, DAV:read-acl privileges. 

   ACE #3: The collection principal identified by URL http://www.foo.org/users/esedlar 
   http://www.webdav.org/groups/authors/ (the ôauthors" group) is 
        the owner of the resource. 
   granted DAV:write and DAV:read-acl privileges. 

   The ACL method invocation fails 
        because the submitted ACE conflicts with following example shows a DAV:acl-principal-props report 
   requesting the protected ACE, 
        thus violating DAV:displayname property. It returns the semantics value of ACE protection. 
   DAV:displayname for resources http://www.webdav.org/people/gstein and
   http://www.webdav.org/groups/authors/ , but not for DAV:all, since 
   this is not an http(s) URL.  

      
   >> Request << 
         
        ACL /top/container/ 

      
     REPORT /index.html HTTP/1.1 
     Host: www.foo.org www.webdav.org 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
        Authorization: Digest username="fielding",  
           realm="users@foo.org", nonce="...", 
           uri="/top/container/", response="...", opaque="..."  
      
     <?xml version="1.0" encoding="utf-8" ?> 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 32] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        <D:acl 
     <D:acl-principal-props xmlns:D="DAV:"> 
          <D:ace> 
            <D:principal> 
              <D:href>http://www.foo.org/users/esedlar</D:href> 
            </D:principal> 
            <D:deny>  
              <D:privilege> <D:write/> </D:privilege>  
            </D:deny> 
          </D:ace> 
        </D:acl> 
       <D:prop> 
         <D:displayname/> 
       </D:prop> 
     </D:acl-principal-props> 
      
   >> Response << 

     HTTP/1.1 403 Forbidden 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxx xxxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
        <DAV:protected-ace-conflict/> 

   8.1.4 Example: 
     <D:multistatus xmlns:D="DAV:"> 
       <D:response> 
         <D:href>http://www.webdav.org/people/gstein</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:displayname>Greg Stein</D:displayname> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
       </D:response> 
       <D:response> 
         <D:href>http://www.webdav.org/groups/authors/</D:href> 
         <D:propstat> 
           <D:prop> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 41] 

INTERNET-DRAFT                WebDAV ACL method failure due            November 9, 2001 

             <D:displayname>Site authors</D:displayname> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status>  
         </D:propstat> 
       </D:response> 
     </D:multistatus> 

9.3 DAV:principal-match REPORT 

   The DAV:principal-match REPORT is used to an inherited ACE conflict identify all members of a 
   collection that match the current user. In particular, if the 
   collection contains principals, the report can be used to identify 
   all members of the collection that match the current user. 
   Alternatively, if the collection contains resources that have a 
   property that identifies a principal (e.g. DAV:owner), then the 
   report can be used to identify all members of the collection whose 
   property identifies a principal that matches the current user. For 
   example, this report can return all of the following request, user "ejw", authenticated by 
        information resources in a collection 
   hierarchy that are owned by the Authorization header, tries to change current user. 

   The Depth header (defined in Section 9.2 of [RFC2518]), with value 
   "infinity", can be used with this report. In this case, the 
        access control list report 
   operates on the resource 
        http://www.foo.org/top/index.html. This resource has two 
        inherited ACEs.  

        Inherited ACE #1 grants the principal identified by URL 
        http://www.foo.org/users/ejw (i.e., collection in the user "ejw") 
        http://www.foo.org/privs/write-all and DAV:read-acl privileges. 
        On this server, http://www.foo.org/privs/write-all Request-URI, as well as all child 
   collections, grandchild collections, etc. 

   Marshalling: 

   The request body MUST be a DAV:principal-match XML element. 

     <!ELEMENT principal-match ((principal-property | self), prop?)> 
     <!ELEMENT principal-property ANY> 
     ANY value: an element whose value identifies a property. The 
     expectation is the value of the named property typically contains 
     an 
        aggregate privilege containing DAV:write, and DAV:write-acl.  

        Inherited ACE #2 grants principal DAV:all href element that contains the DAV:read 
        privilege. URI of a principal 
     <!ELEMENT self EMPTY> 
     prop: see RFC 2518, Section 12.11 
    

   The response body for a successful request MUST be a DAV:multistatus 
   XML element. 

     multistatus: see RFC 2518, Section 12.9 
    

   The response body for a successful DAV:principal-match REPORT request attempts to set
   MUST contain a (non-inherited) ACE, denying DAV:response element for each member of the 
        principal identified by collection
   that matches the URL http://www.foo.org/users/ejw 
        (i.e., current user. When the user ôejwö) DAV:write permission. This conflicts 
        with inherited ACE #1. Note that DAV:principal-property 
   element is used, a match occurs if the decision to report an 
        inherited ACE conflict current user is specific to this server 
        implementation. Another server implementation could have 
        allowed the new ACE to be set, and then used normal ACE 
        evaluation rules to determine whether same as 
   the principal identified by the URI found in the DAV:href element of 
   the new ACE has any 
        impact on property identified by the privileges available to DAV:principal-property element. When 
   the DAV:self element is used in a principal. 

        >> Request << 
         
        ACL /top/index.html HTTP/1.1 
        Host: www.foo.org 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxxx 
        Authorization: Digest username="ejw", DAV:principal-match report issued 
   against a collection principal, it matches a child of the collection 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 33] 42] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


           realm="users@foo.org", nonce="...", 
           uri="/top/index.html", response="...", opaque="..." 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <D:acl xmlns:D="DAV:" xmlns:F="http://www.foo.org/privs/"> 
          <D:ace> 
            <D:principal> 
              <D:href>http://www.foo.org/users/ejw</D:href> 
            </D:principal> 
            <D:grant><D:write/></D:grant> 
          </D:ace> 
        </D:acl> 
         
        >> Response << 
         
        HTTP/1.1 403 Forbidden 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxx 
         
        <?xml version="1.0" encoding="utf-8" ?> 
        <DAV:inherited-ace-conflict/> 

   8.1.5 Example: ACL method failure due to an attempt to set grant and 
         deny in a single ACE. 

        In this example, user "ygoland", authenticated by information 

   principal if that child (a principal resource) identifies the same 
   principal as the current user. 

   If DAV:prop is specified in the Authorization header, tries to change request body, the access control 
        list on properties 
   specified in the resource http://www.foo.org/diamond/engagement-
        ring.gif. DAV:prop element MUST be reported in the 
   DAV:response elements. 

9.3.1 Example: DAV:principal-match REPORT 

   The ACL request includes a single, syntactically and 
        semantically incorrect ACE, which attempts to grant following example identifies the members of the collection principal 
   identified by the URL 
        http://www.foo.org/users/friends/ DAV:read privilege and deny 
        the principal identified http://www.webdav.org/doc/ that are owned by URL 
        http://www.foo.org/users/ygoland-so (i.e., 
   the current user. The current user "ygoland-
        so") DAV:read privilege. However, it (ôgclemm") is illegal to have 
        multiple principal elements, as well as both a grant and deny 
        element in the same ACE, so the request fails due to poor 
        syntax. authenticated using 
   Digest authentication. 

   >> Request << 
         
        ACL /diamond/engagement-ring.gif 

     REPORT /doc/ HTTP/1.1 
     Host: www.foo.org 
        Content-Type: text/xml; charset="utf-8" 
        Content-Length: xxxx www.webdav.org 
     Authorization: Digest username="ygoland",  
           realm="users@foo.org", username="gclemm",  
        realm="gclemm@webdav.org", nonce="...", 
           uri="/diamond/engagement-ring.gif", 
        uri="/papers/", response="...", opaque="..." 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx  
     Depth: infinity 
      
     <?xml version="1.0" encoding="utf-8" ?> 
        <D:acl 
     <D:principal-match xmlns:D="DAV:"> 
          <D:ace> 
            <D:principal> 
       <D:principal-property> 
         <D:owner/> 
       </D:principal-property> 
     </D:principal-match> 
      
     >> Response << 
      
     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:"> 
       <D:response> 
         <D:href>http://www.webdav.org/doc/foo.html</D:href> 
         <D:status>HTTP/1.1 200 OK</D:status> 
       </D:response> 
       <D:response> 
         <D:href>http://www.webdav.org/doc/img/bar.gif</D:href> 
         <D:status>HTTP/1.1 200 OK</D:status> 
       </D:response> 
     </D:multistatus> 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 34] 43] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 


              <D:href>http://www.foo.org/users/friends/</D:href> 
            </D:principal> 
            <D:grant><D:read/></D:grant> 
            <D:principal> 
              <D:href>http://www.foo.org/users/ygoland-so</D:href> 
            </D:principal> 
            <D:deny><D:read/></D:deny> 
          </D:ace> 
        </D:acl> 
         
        >> Response << 
         
        HTTP/1.1 400 Bad Request 
        Content-Length: 0 
         
        Note that if 

9.4 DAV:principal-property-search REPORT 

   The DAV:principal-property-search REPORT performs a substring search 
   on the request had been divided into two ACEs, one to 
        grant, character data value of specified properties. The server MUST 
   perform caseless matching of substrings. Only properties defined on 
   principal or collection principal resources are searched. For 
   implementation efficiency, servers do not typically support substring
   searching on all properties. A client can discover the set of 
   searchable properties by using the principal-search-property-set 
   REPORT, defined in Section 9.5.  

      Implementation Note: The value of a WebDAV property is a sequence 
      of well-formed XML, and one hence can include any character in the 
      Unicode/ISO-10646 standard, that is, most known characters in 
      human languages. Due to deny, the request would have been 
        syntactically well formed. 

   9  ACCESS CONTROL REPORTS 

   9.1 REPORT Method 

        A REPORT request idiosyncrasies of case mapping across 
      human languages, implementation of caseless matching is an extensible mechanism non-
      trivial. Implementors are strongly encouraged to consult 
      [CaseMap], especially Section 2.3 ("Caseless Matching"), for obtaining 
        information about a resource.  Unlike a 
      guidance when implementing their caseless matching algorithms. 

   Marshalling: 

   The DAV:principal-collection-set property of the resource property, 
        which has a single value, identified 
   by the value Request-URI specifies the scope of the DAV:principal-property-
   search REPORT, as follows: 

   - All principal and collection principal resources identified in 
   DAV:principal-collection-set are searched 
   - All principal and collection principal resources that are 
   descendents of a report can depend on 
        additional information specified collection principal resource identified in 
   DAV:principal collection-set are searched. 

   Servers MUST support the DAV:principal-property-search REPORT request body and on all 
   principal collections identified in the REPORT request headers. 

      Marshalling: 

        The body value of a REPORT request specifies which report is being 
        requested, as well as any additional information that will be 
        used to customize the report. DAV:principal-
   collection-set property. 

   The request MAY include a Depth header.   

        The response body for a successful request MUST contain the 
        requested report. 

        If a Depth request header is included, the response MUST be a 
        207 Multi-Status. 

      Postconditions: 

        The REPORT method MUST NOT change the content or dead 
        properties of any resource. 

        If DAV:principal-property-search XML element 
   containing a Depth request header is included, search specification and an optional list of properties.
   For every principal that matches the request MUST be 
        applied separately to search specification, the collection itself and to all members 
   response will contain the value of the collection properties on that satisfy the Depth value. principal. 

     <!ELEMENT principal-property-search ((property-search+), prop?) > 
      
   The DAV:prop DAV:property-search element of contains a DAV:response for prop element enumerating 
   the properties to be searched and a given resource MUST contain caseless-substring element, 
   containing the 
        requested report for that resource. search string. 

     <!ELEMENT property-search (prop, caseless-substring) > 
     prop: see RFC 2518, Section 12.11 
       
     <!ELEMENT caseless-substring #PCDATA > 
      
Clemm, Hopkins, Sedlar, Whitehead                          [Page 35] 44] 

INTERNET-DRAFT                WebDAV ACL           June 21, 2001 


   9.2 DAV:acl-principal-props Report 

        The DAV:acl-principle-props report returns, for all principals 
        in the DAV:acl property that are identified by http(s) URLs, 
        the value of the properties specified in the REPORT request 
        body. In the case where a principal URL appears multiple times, 
        the DAV:acl-principal-props report MUST return the properties 
        for that principal only once. 

      Marshalling 

        The request body MUST be a DAV:acl-principal-props XML element. 

        <!ELEMENT acl-principal-props ANY> 
        ANY value: a sequence of one or more elements, with at most one ACL            November 9, 2001 

   Multiple property-search elements or multiple elements within a 
   DAV:prop element will be interpreted with a logical AND.  An empty 
   DAV:caseless-substring element will match all properties specified in
   its parent DAV:property-search element. 
        prop: see RFC 2518, Section 12.11 

   The response body for a successful request MUST be a DAV:multistatus 
   XML element (i.e., the response uses the same 
        format as the response for PROPFIND). element. 

     multistatus: see RFC 2518, Section 12.9 
      
   The response body for a successful DAV:acl-principal-props DAV:principal-property-search 
   REPORT request MUST contain  a DAV:response element for each 
   principal identified by an http(s) URL listed whose property values satisfy the search specification 
   given in a 
        DAV:principal XML DAV:principal-property-search. 

   If DAV:prop is specified in the request body, the properties 
   specified in the DAV:prop element of an ACE within MUST be reported in the DAV:acl property 
   DAV:response elements. 

   Errors: 

   If a request specifies a search of  a property that is not 
   searchable, a 403 (Forbidden) response MUST be returned and the resource identified by 
   response body MUST be a DAV:non-searchable-property element, 
   containing the Request-URI. 

    9.2.1 Example: DAV:acl-principal-props Report 

        Resource http;//www.webdav.org/index.html unsearchable properties. 

     <!ELEMENT non-searchable-property (prop) > 
 

9.4.1 Matching 

   There are several cases to consider when matching strings. The 
   easiest case is when a property value is "simple" and has an ACL only 
   character information item content (see [REC-XMLINFOSET]). For 
   example, the search string "julian" would match the DAV:displayname 
   property with three 
        ACEs: 

        ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
        current-user-privilege-set access. 

        ACE #2: value "Julian Reschke". Note that the on-the-wire 
   marshalling of DAV:displayname in this case is: 

     <D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname> 
    

   The principal identified by 
        http://www.webdav.org/people/gstein (the user ôgsteinö) name of the property is 
        granted DAV:write,  DAV:write-acl, DAV:read-acl privileges. 

        ACE #3: encoded into the XML element information 
   item, and the character information item content of the property is 
   "Julian Reschke". 

   The collection principal identified by 
        http://www.webdav.org/groups/authors/ (the ôauthorsö group) more complicated case occurred when properties have mixed content
   (that is, compound values consisting of multiple child element items,
   other types of information items, and character information item 
   content). Consider the property http://www.webdav.org/props/aprop, 
   marshalled as: 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 45] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <W:aprop xmlns:W="http://www.webdav.org/props/"> 
     {cdata 0}<W:elem1>{cdata 1}</W:elem1> 
       <W:elem2>{cdata 2}</W:elem2>{cdata 3} 
     </W:aprop> 
    

   In this case, substring matching is 
        granted DAV:write and DAV:read-acl privileges. 

        The following performed on each individual 
   contiguous sequence of character information items. In the example shows 
   above, a DAV:acl-principal-props report 
        requesting search string would be compared to the DAV:displayname property. It returns four following 
   strings: 

     {cdata 0} 
     {cdata 1} 
     {cdata 2} 
     {cdata 3} 
    
   That is, four individual caseless substring matches would be 
   performed, one each for {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 
   3}. 

9.4.2 Example: successful DAV:principal-property-search REPORT 

   In this example, the value client requests the principal URLs of all users 
   whose DAV:displayname for property contains the substring "doE" and whose
   http://BigCorp.com/ns/title property (that is, their professional 
   title) contains "sales".  In addition, the client requests five 
   properties to be returned with the matching principals: 

   In the DAV: namespace: displayname 
   In the http://www.BigCorp.com/ns/ namespace: department, phone, 
   office, salary 

   The response shows that two principal resources 
        http://www.webdav.org/people/gstein meet the search 
   specification, "John Doe" and 
        http://www.webdav.org/groups/authors/ , but "Zygdoebert Smith". The property 
   "salary" in namespace "http://www.BigCorp.com/ns/" is not for DAV:all, returned, 
   since this is the principal making the request does not an http(s) URL. have sufficient 
   access permissions to read this property. 


   >> Request << 

     REPORT /users/ HTTP/1.1 
     Host: www.BigCorp.com 
     Content-Type: text/xml; charset=utf-8 
     Content-Length: xxxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:principal-property-search xmlns:D="DAV:"> 
       <D:property-search> 
         <D:prop> 


Clemm, Hopkins, Sedlar, Whitehead                          [Page 36] 46] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

           <D:displayname/> 
         </D:prop> 
         <D:caseless-substring>doE</D:caseless-substring> 
       </D:property-search> 
       <D:property-search> 
         <D:prop xmlns:B="http://www.BigCorp.com/ns/"> 
           <B:title/> 
         </D:prop> 
         <D:caseless-substring>sales</D:caseless-substring> 
       </D:property-search> 
       <D:prop xmlns:B="http://www.BigCorp.com/ns/"> 
         <D:displayname/> 
         <B:department/> 
         <B:phone/> 
         <B:office/> 
         <B:salary/> 
       </D:prop> 
     </D:principal-property-search> 
    

   >> Response << 

    

     HTTP/1.1 207 Multi-Status 
     Content-Type: text/xml; charset=utf-8 
     Content-Length: xxxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
     <D:multistatus xmlns:D="DAV:" xmlns:B="http://BigCorp.com/ns/"> 
       <D:response> 
         <D:href>http://www.BigCorp.com/users/jdoe</D:href> 
         <D:propstat> 
           <D:prop> 
             <D:displayname>John Doe</D:displayname> 
             <B:department>Widget Sales</B:department> 
             <B:phone>234-4567</B:phone> 
             <B:office>209</B:office> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
         <D:propstat> 
           <D:prop> 
             <B:salary/> 
           </D:prop> 
           <D:status>HTTP/1.1 403 Forbidden</D:status> 
         </D:propstat> 
       </D:response> 
       <D:response> 
         <D:href>http://www.BigCorp.com/users/zsmith</D:href> 
         <D:propstat> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 47] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 

           <D:prop> 
             <D:displayname>Zygdoebert Smith</D:displayname> 
             <B:department>Gadget Sales</B:department> 
             <B:phone>234-7654</B:phone> 
             <B:office>114</B:office> 
           </D:prop> 
           <D:status>HTTP/1.1 200 OK</D:status> 
         </D:propstat> 
         <D:propstat> 
           <D:prop> 
             <B:salary/> 
           </D:prop> 
           <D:status>HTTP/1.1 403 Forbidden</D:status> 
         </D:propstat> 
       </D:response> 
     </D:multistatus> 
      

9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT 

   In this example, the client requests a search on the non-searchable 
   property "phone" in the namespace "http://www.BigCorp.com/ns/".  The 
   response is a 403 (Forbidden), with a response body containing the 
   XML element DAV:non-searchable-property listing the non-searchable 
   property. 

   >> Request << 

     REPORT /index.html /users/ HTTP/1.1 
     Host: www.webdav.org www.BigCorp.com 
     Content-Type: text/xml; charset="utf-8" charset=utf-8 
     Content-Length: xxxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
        <D:acl-principal-props 
     <D:principal-property-search xmlns:D="DAV:"> 
          <D:prop> 
            <D:displayname/> 
       <D:property-search> 
         <D:prop xmlns:B="http://www.BigCorp.com/ns/"> 
           <B:phone/> 
         </D:prop> 
        </D:acl-principal-props> 
         <D:caseless-substring>232</D:caseless-substring> 
       </D:property-search> 
     </D:principal-property-search> 
    

   >> Response << 

      
     HTTP/1.1 207 Multi-Status 403 FORBIDDEN 
     Content-Type: text/xml; charset="utf-8" charset=utf-8 
     Content-Length: xxxx 
      

Clemm, Hopkins, Sedlar, Whitehead                          [Page 48] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus 
     <D:non-searchable-property xmlns:D="DAV:"> 
          <D:response> 
            <D:href>http://www.webdav.org/people/gstein</D:href> 
            <D:propstat> 
              <D:prop> 
                <D:displayname>Greg Stein</D:displayname> 
              </D:prop> 
              <D:status>HTTP/1.1 200 OK</D:status> 
            </D:propstat> 
          </D:response> 
          <D:response> 
            <D:href>http://www.webdav.org/groups/authors/</D:href> 
            <D:propstat> 
              <D:prop> 
                <D:displayname>Site authors</D:displayname> 
       <D:prop xmlns:B="http://www.BigCorp.com/ns/"> 
         <B:phone/> 
       </D:prop> 
              <D:status>HTTP/1.1 200 OK</D:status>  
            </D:propstat> 
          </D:response> 
        </D:multistatus> 

   9.3 DAV:principal-match 
     </D:non-searchable-property> 
      

9.5 DAV:principal-search-property-set REPORT 

   The DAV:principal-match DAV:principal-search-property-set REPORT is used to identify all members 
        of a collection identifies those 
   properties that match the current user. In particular, if 
        the collection contains principals, the report can may be used to 
        identify all members searched using the DAV:principal-property-
   search REPORT (defined in Section 9.4). The DAV:principal-collection-
   set property of the collection that match resource identified by the current 
        user. Alternatively, if Request-URI specifies 
   the scope of the DAV:principal-search-property-set REPORT, as 
   follows: 

   - All principal and collection contains principal resources that 
        have a property that identifies a identified in 
   DAV:principal-collection-set are in scope 
   - All principal (e.g. DAV:owner), 
        then the report can be used to identify all members of the and collection whose property identifies a principal resources that matches 
        the current user. For example, this report can return all are 
   descendents of 


   Clemm, Hopkins, Sedlar, Whitehead                      [Page 37] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


        the resources in a collection hierarchy that principal resource identified in 
   DAV:principal collection-set are owned by the 
        current user. 

      Marshalling: 

        The request body also in scope.  

   Principals and collection principals within this scope are examined 
   for searchable properties.  

   Servers MUST be a DAV:principal-match XML element. 

        <!ELEMENT principal-match ((principal-property | self), prop?)> 
        <!ELEMENT principal-property ANY> 
        ANY value: an element whose value identifies a property. The 
        expectation is the value of support the named property typically 
        contains an href element that contains DAV:principal-search-property-set REPORT on 
   all principal collections identified in the URI value of a principal 
        <!ELEMENT self EMPTY> 
        prop: see RFC 2518, Section 12.11 
         

        The response body for DAV:principal-
   collection-set property. 

   An access control protocol user agent could use the results of the 
   DAV:principal-search-property-set REPORT to present a successful query interface
   to the user for retrieving principals. 

   Marshalling: 

   The request body MUST be a 
        DAV:multistatus an empty DAV:principal-search-property-set 
   XML element. 

        multistatus: see RFC 2518, Section 12.9 

   The response body for a successful DAV:principal-match REPORT 
        request MUST contain be a DAV:response DAV:principal-search-property-set XML 
   element, containing a DAV:principal-search-property XML element for 
   each member of 
        the collection property that matches the current user. When may be searched with the 
        DAV:principal-property element is used, DAV:principal-property-
   search REPORT. A server MAY limit its response to just a match occurs if the 
        current user is subset of 
   the same searchable properties, such as the principal identified by the URI 
        found in the DAV:href those likely to be useful to an 
   interactive access control client. 

     <!ELEMENT principal-search-property-set (principal-search-
     property*) > 
    

   Each DAV:principal-search-property XML element contains exactly one 
   searchable property, and a description of the property. 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 49] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

     <!ELEMENT principal-search-property (prop, description) > 
      
   The DAV:prop element contains one principal property identified by the 
        DAV:principal-property element. When on which the DAV:self 
   server is able to perform DAV:principal-property-search REPORTs.   

     prop: see RFC 2518, Section 12.11 
      
   The description element is 
        used in a DAV:principal-match report issued against a 
        collection principal, it matches a child human-readable description of what 
   information this property represents. Servers MUST indicate the collection 
        principal if that child (a principal resource) identifies human
   language of the 
        same principal as description using the current user. 

        If DAV:prop is specified in xml:lang attribute and SHOULD 
   consider the HTTP Accept-Language request body, header when selecting one 
   of multiple available languages. 

     <!ELEMENT description #PCDATA > 

9.5.1 Example: DAV:principal-search-property-set REPORT 

   In this example, the properties 
        specified in client determines the DAV:prop element MUST be reported in set of searchable 
   principal properties by requesting the 
        DAV:response elements. 

   9.3.1 Example: DAV:principal-match DAV:principal-search-property-
   set REPORT 

        The following example identifies on the members root of the collection 
        identified by the serverÆs principal URL http://www.webdav.org/doc/ that are owned collection set, 
   identified by the current user. The current user (ôgclemmö) is 
        authenticated using Digest authentication. http://www.BigCorp.com/users/.  

   >> Request << 

     REPORT /doc/ /users/ HTTP/1.1 
     Host: www.webdav.org 
        Authorization: Digest username="gclemm",  
           realm="gclemm@webdav.org", nonce="...", 
           uri="/papers/", response="...", opaque="..." www.BigCorp.com 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx  
         

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 38] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 xxx 
     Accept-Language: en, de 
     Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ= 
      
     <?xml version="1.0" encoding="utf-8" ?> 
        <D:principal-match xmlns:D="DAV:"> 
          <D:principal-property> 
            <D:owner/> 
          </D:principal-property> 
        </D:principal-match> 
     <D:principal-search-property-set xmlns:D="DAV:"/> 
    

   >> Response << 

     HTTP/1.1 207 Multi-Status 200 OK 
     Content-Type: text/xml; charset="utf-8" 
     Content-Length: xxxx xxx 
      
     <?xml version="1.0" encoding="utf-8" ?> 
        <D:multistatus 
     <D:principal-search-property-set xmlns:D="DAV:"> 
          <D:response> 
            <D:href>http://www.webdav.org/doc/foo.html</D:href> 
            <D:status>HTTP/1.1 200 OK</D:status> 
          </D:response> 
          <D:response> 
            <D:href>http://www.webdav.org/doc/img/bar.gif</D:href> 
            <D:status>HTTP/1.1 200 OK</D:status> 
          </D:response> 
        </D:multistatus> 
       <D:principal-search-property> 
         <D:prop> 
           <D:displayname/> 
         </D:prop> 
         <D:description xml:lang="en">Full name</D:description> 
       </D:principal-search-property> 
       <D:principal-search-property> 
         <D:prop xmlns:B="http://BigCorp.com/ns/"> 
           <B:title/> 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 50] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

         </D:prop> 
         <D:description xml:lang="en">Job title</D:description> 
       </D:principal-search-property> 
     </D:principal-search-property-set> 


10 XML PROCESSING 

   Implementations of this specification MUST support the XML element 
   ignore rule, as specified in Section 23.3.2 of [RFC2518], and the WebDAV XML
   Namespace interpretation 
        convention, described in Section 23.4 Recommendation [REC-XML-NAMES]. 

   Note that use of [RFC2518]. the DAV namespace is reserved for XML elements and 
   property names defined in a standards-track or Experimental IETF RFC.


11 INTERNATIONALIZATION CONSIDERATIONS 

   In this specification, the only human-readable content can be found 
   in the description XML element, found within the 
        DAV:supported-privilege-set DAV:supported-
   privilege-set property.  This element contains a human-readable 
   description of the capabilities controlled by a privilege.  As a 
   result, the description element must be capable of representing 
   descriptions in multiple character sets.  Since the description 
   element is found within a WebDAV property, it is represented on-the-wire on-the-
   wire as XML [REC-XML], and hence can leverage XML's language tagging 
   and character set encoding capabilities. Specifically, XML processors
   must, at minimum, be able to read XML elements encoded using the UTF-8 UTF-
   8 [UTF-8] encoding of the ISO 10646 multilingual plane. XML examples 
   in this specification demonstrate use of the charset parameter of the
   Content-Type header, as defined in [RFC3023], as well as the XML 
   "encoding" attribute, which together provide charset identification 
   information for MIME and XML processors. Furthermore, this 
   specification requires server implementations to tag description 
   fields with the xml:lang attribute (see Section 2.12 of [REC-XML]), 
   which specifies the human language of the description. Additionally, 
   server implementations should take into account the value of the 
   Accept-Language HTTP header to determine which description string to 
   return. 

   For XML elements other than the description element, it is expected 
   that implementations will treat the property names, privilege names, 
   and values as tokens, and convert these tokens 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 39] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 into human-readable 
   text in the user's language and character set when displayed to a 
   person.  Only a generic WebDAV property display utility would display
   these values in their raw form to a human user. 

   For error reporting, we follow the convention of HTTP/1.1 status 
   codes, including with each status code a short, English description 
   of the code (e.g., 200 (OK)).  While the possibility exists that a 
   poorly crafted user agent would display this message to a user, 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 51] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   internationalized applications will ignore this message, and display 
   an appropriate message in the user's language and character set. 

   Further internationalization considerations for this protocol are 
   described in the WebDAV Distributed Authoring protocol specification 
   [RFC2518]. 


12 SECURITY CONSIDERATIONS  

   Applications and users of this access control protocol should be 
   aware of several security considerations, detailed below. In addition
   to the discussion in this document, the security considerations 
   detailed in the HTTP/1.1 specification [RFC2616], the WebDAV 
   Distributed Authoring Protocol specification [RFC2518], and the XML 
   Media Types specification [RFC3023] should be considered in a 
   security analysis of this protocol.  

12.1 Increased Risk of Compromised Users 

   In the absence of a mechanism for remotely manipulating access 
   control lists, if a single user's authentication credentials are 
   compromised, only those resources for which the user has access 
   permission can be read, modified, moved, or deleted. With the 
   introduction of this access control protocol, if a single compromised
   user has the ability to change ACLs for a broad range of other users 
   (e.g., a super-user), the number of resources that could be altered 
   by a single compromised user increases. This risk can be mitigated by
   limiting the number of people who have write-acl privileges across a 
   broad range of resources. 

12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set 
     Privileges 

   The ability to read the access privileges (stored in the DAV:acl 
   property), or the privileges permitted the currently authenticated 
   user (stored in the DAV:current-user-privilege-
        set DAV:current-user-privilege-set property) on a 
   resource may seem innocuous, since reading an ACL cannot possibly 
   affect the resource's state. However, if all resources have world-readable world-
   readable ACLs, it is possible to perform an exhaustive search for 
   those resources that have inadvertently left themselves in a 
   vulnerable state, such as being world-writeable. In particular, the 
   property retrieval 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 40] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 method PROPFIND, executed with Depth infinity on 
   an entire hierarchy, is a very efficient way to retrieve the DAV:acl 
   or DAV:current-user-privilege-set properties. Once found, this 
   vulnerability can be exploited by a denial of service attack in which
   the open resource is repeatedly overwritten. Alternately, writeable 
   resources can be modified in undesirable ways. 

   To reduce this risk, read-acl privileges should not be granted to 
   unauthenticated principals, and restrictions on read-acl and 
        cuprivset read-

Clemm, Hopkins, Sedlar, Whitehead                          [Page 52] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

   current-user-privilege-set privileges for authenticated principals 
   should be carefully analyzed when deploying this protocol. Access to 
   the current-user-privilege-set property will involve a tradeoff of 
   usability versus security. When the current-user-privilege-set is 
   visible, user interfaces are expected to provide enhanced information
   concerning permitted and restricted operations, yet this information 
   may also indicate a vulnerability that could be exploited. Deployment
   of this protocol will need to evaluate this tradeoff in light of the 
   requirements of the deployment environment. 

12.3 No Foreknowledge of Initial ACL 

   In an effort to reduce protocol complexity, this protocol 
   specification intentionally does not address the issue of how to 
   manage or discover the initial ACL that is placed upon a resource 
   when it is created. The only way to discover the initial ACL is to 
   create a new resource, then retrieve the value of the DAV:acl 
   property. This assumes the principal creating the resource also has 
   been granted the DAV:read-acl privilege. 

   As a result, it is possible that a principal could create a resource,
   and then discover that its ACL grants privileges that are 
   undesirable. Furthermore, this protocol makes it possible (though 
   unlikely) that the creating principal could be unable to modify the 
   ACL, or even delete the resource. Even when the ACL can be modified, 
   there will be a short period of time when the resource exists with 
   the initial ACL before its new ACL can be set. 

   Several factors mitigate this risk. Human principals are often aware 
   of the default access permissions in their editing environments and 
   take this into account when writing information. Furthermore, default
   privilege policies are usually very conservative, limiting the 
   privileges granted by the initial ACL.  


13 AUTHENTICATION 

   Authentication mechanisms defined in for use with HTTP and  WebDAV also 
   apply to this WebDAV Access Control Protocol, in particular the Basic
   and Digest authentication mechanisms defined in [RFC2617]. 



   Clemm, Hopkins, Sedlar, Whitehead                      [Page 41] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 


14 IANA CONSIDERATIONS 

   This document uses the namespace defined by [RFC2518] for XML 
   elements.  All other IANA considerations mentioned in [RFC2518] also 
   applicable to WebDAV ACL. 




Clemm, Hopkins, Sedlar, Whitehead                          [Page 53] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

15 INTELLECTUAL PROPERTY 

   The following notice is copied from RFC 2026, section 10.4, and 
   describes the position of the IETF concerning intellectual property 
   claims made against this document. 

   The IETF takes no position regarding the validity or scope of any 
   intellectual property or other rights that might be claimed to 
   pertain to the implementation or use other technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; neither does it represent that it 
   has made any effort to identify any such rights.  Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11.  Copies of 
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to 
   obtain a general license or permission for the use of such 
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to practice 
   this standard.  Please address the information to the IETF Executive 
   Director. 


16 ACKNOWLEDGEMENTS 

   This protocol is the collaborative product of the WebDAV ACL design 
   team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean 
   Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors 
   are grateful for the detailed review and comments provided by Jim 
   Amsden, Gino Basso, Murthy Chintalapati, Dennis Hamilton, Laurie 
   Harper, Ron Jacobs, Chris Knight, Remy Maucherat, Larry Masinter, 
   Yaron Goland, Lisa Dusseault, and Joe Orton. Orton, Stefan Eissing, Julian 
   Reschke, Keith Wannamaker, Tim Ellison, and Dylan Barrell. We thank 
   Keith Wannamaker for the initial text of the principal property 
   search sections. Prior work on WebDAV access control protocols has 
   been performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard 
   Palmer, and Jon Radoff. We would like to acknowledge the foundation 
   laid for us by the authors of the DeltaV, WebDAV and HTTP protocols 
   upon which this protocol is layered, and the invaluable feedback from
   the WebDAV working group. 







Clemm, Hopkins, Sedlar, Whitehead                          [Page 42] 54] 

INTERNET-DRAFT                WebDAV ACL           June 21,            November 9, 2001 

17 REFERENCES 

17.1 Normative References 

   [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 
   Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997. 

   [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible 
        Markup Language (XML)." Paoli, C.M. Sperberg-McQueen, "Extensible 
   Markup Language (XML)." World Wide Web Consortium Recommendation REC-
   xml.http://www.w3.org/TR/REC-xml 

   [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, ôName Spaces in 
   XML" World Wide Web Consortium Recommendation REC-xml-names. 
   http://www.w3.org/TR/REC-xml-names/ 

   [RFCxxxx] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead, 
   "Versioning Extensions to WebDAV." RFC xxxx. Rational, IBM, 
   Microsoft, U.C. Santa Cruz, 2001. 

   [REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World 
   Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
        19980210. REC-xml-infoset. 
   http://www.w3.org/TR/xml-infoset/ 

   [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 
   Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol 
   -- HTTP/1.1." RFC 2616. U.C. Irvine, Compaq, Xerox, Microsoft, 
   MIT/LCS, June, 1999. 

   [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. 
   Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and 
   Digest Access Authentication." RFC 2617. Northwestern University, 
   Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market, June,
   1999. 

   [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D. Jensen,
   "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC 2518. 
   Microsoft, U.C. Irvine, Netscape, Novell, February, 1999. 

   [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL 
   scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape, July, 
   1998. 

        [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255. 
        Netscape, December, 1997. 

   [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC 
   3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures, 
   January, 2001. 

   [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and 
   ISO 10646." RFC 2279. Alis Technologies. January, 1998. 





Clemm, Hopkins, Sedlar, Whitehead                          [Page 55] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

17.2 Informational References 

   [RFC2026] S.Bradner, "The Internet Standards Process û Revision 3." 
   RFC 2026, BCP 9. Harvard, October, 1996. 

   [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255. 
   Netscape, December, 1997. 

   [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 
   Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode, December, 
   1997. 

   [CaseMap] M. Davis, "Case Mappings", Unicode Technical Report #21, 
   <http://www.unicode.org/unicode/reports/tr21> 


18 AUTHORS' ADDRESSES 

     Geoffrey Clemm 
     Rational Software 
     20 Maguire Road 
     Lexington, MA 02421 
     Email: geoffrey.clemm@rational.com 
         

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 43] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 
      
     Anne Hopkins 
     Microsoft Corporation 
     One Microsoft Way 
     Redmond, WA 98052 
     Email: annehop@microsoft.com 
      
     Eric Sedlar 
     Oracle Corporation 
     500 Oracle Parkway 
     Redwood Shores, CA 94065 
     Email: esedlar@us.oracle.com 
      
     Jim Whitehead 
     U.C. Santa Cruz 
     Dept. of Computer Science 
     Baskin Engineering 
     1156 High Street 
     Santa Cruz, CA 95064 
     Email: ejw@cse.ucsc.edu 
      







Clemm, Hopkins, Sedlar, Whitehead                          [Page 56] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 


19 APPENDICIES 

19.1 WebDAV XML Document Type Definition Addendum 

   All XML elements defined in this Document Type Definition (DTD) 
   belong to the DAV namespace. This DTD should be viewed as an addendum
   to the DTD provided in [RFC2518], section 23.1. 

     <!-- Privileges --> 
      
     <!ELEMENT read EMPTY> 
     <!ELEMENT write EMPTY> 
     <!ELEMENT read-acl EMPTY> 
     <!ELEMENT read-current-user-privilege-set EMPTY> 
     <!ELEMENT write-acl EMPTY> 
     <!ELEMENT all EMPTY> 
      
      
     <!-- Principal Properties (Section 4) --> 
      
     <!ELEMENT is-principal (#PCDATA)> principalEMPTY> 
      
     <!ELEMENT alternate-URL alternate-URI-set (href*)> 
     <!ELEMENT principal-URL (href)> 
      
     <!-- Access Control Properties (Section 5) --> 
      
     <!-- DAV:owner Property (Section 5.1) --> 
      
     <!ELEMENT owner (href prop?)> 
     <!ELEMENT prop (see [RFC2518], section 12.11)> 
      
      
     <!-- DAV:supported-privilege-set Property (Section 5.2) -->  
      
     <!ELEMENT supported-privilege-set (supported-privilege*)> 
     <!ELEMENT supported-privilege 
      (privilege, abstract?, description, supported-privilege*)> 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 44] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 
      
     <!ELEMENT privilege ANY> 
     <!ELEMENT abstract EMPTY> 
     <!ELEMENT description #PCDATA>  
     <!ELEMENT privilege ANY> 
      
      
     <!-- DAV:current-user-privilege-set Property (Section 5.3) --> 
      
     <!ELEMENT current-user-privilege-set (privilege*)> 
      
Clemm, Hopkins, Sedlar, Whitehead                          [Page 57] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 
      
     <!-- DAV:acl Property (Section 5.4) --> 
      
     <!ELEMENT acl (ace*)> 
      
     <!ELEMENT ace (principal, (grant|deny), protected?, inherited?)> 
     <!ELEMENT principal ((href, prop?) 
      | all | authenticated | unauthenticated 
      | property | self)> 
      
     <!ELEMENT prop (see [RFC2518], section 12.11)> 
     <!ELEMENT all EMPTY> 
     <!ELEMENT authenticated EMPTY> 
     <!ELEMENT unauthenticated EMPTY> 
     <!ELEMENT property ANY> 
     <!ELEMENT self EMPTY> 
      
     <!ELEMENT grant (privilege+)> 
     <!ELEMENT deny (privilege+)> 
     <!ELEMENT privilege ANY> 
      
     <!ELEMENT protected EMPTY> 
      
     <!ELEMENT inherited (href)> 
      
      
     <!-- DAV:principal-collection-set Property (Section 5.6) --> 
      
     <!ELEMENT principal-collection-set (href*)> 
      
      
     <!-- DAV:acl-semantics Property (Section 6) --> 
      
     <!ELEMENT acl-semantics acl-sem*> 
        <!ELEMENT acl-sem (ace-combination, ace-ordering, allowed-ace, 
        required-principal*)> (ace-combination?, ace-ordering?, allowed-
     ace?, required-principal?)> 
       
     <!ELEMENT ace-combination 
      (first-match | all-grant-before-any-deny | specific-deny-
     overrides-grant)> 
     <!ELEMENT first-match EMPTY> 
     <!ELEMENT all-grant-before-any-deny EMPTY> 

   Clemm, Hopkins, Sedlar, Whitehead                      [Page 45] 

   INTERNET-DRAFT               WebDAV ACL           June 21, 2001 
     <!ELEMENT specific-deny-overrides-grant EMPTY> 
      
     <!ELEMENT ace-ordering (deny-before-grant)? > 
     <!ELEMENT deny-before-grant EMPTY> 
      
     <!ELEMENT allowed-ace (principal-only-one-ace | grant-only)*> 
     <!ELEMENT principal-only-one-ace EMPTY> 
     <!ELEMENT grant-only EMPTY> 
      
     <!ELEMENT required-principal 
          (href | all 

Clemm, Hopkins, Sedlar, Whitehead                          [Page 58] 

INTERNET-DRAFT                WebDAV ACL            November 9, 2001 

       (all? | authenticated authenticated? | unauthenticated unauthenticated? | property self? | 
        self)> href* 
     |property*)> 
      
      
     <!-- ACL method preconditions (Section 8.1.1) --> 
      
     <!ELEMENT ace-conflict EMPTY> 
     <!ELEMENT protected-ace-conflict EMPTY> 
     <!ELEMENT inherited-ace-conflict EMPTY> 
     <!ELEMENT too-many-aces EMPTY> 
      
      
     <!-- REPORT Method REPORTs (Section 9) --> 
      
     <!ELEMENT acl-principal-props ANY> 
     ANY value: a sequence of one or more elements, with at most one 
     DAV:prop element. 
      
     <!ELEMENT principal-match ((principal-property | self), prop?)> 
     <!ELEMENT principal-property ANY> 
     ANY value: an element whose value identifies a property. The 
     expectation is the value of the named property typically contains 
     an href element that contains the URI of a principal 
      
     <!ELEMENT self EMPTY> 
      
     <!ELEMENT principal-property-search ((property-search+), prop?) > 
     <!ELEMENT property-search (prop, caseless-substring) > 
     <!ELEMENT caseless-substring #PCDATA > 
     <!ELEMENT non-searchable-property (prop) > 
      
     <!ELEMENT principal-search-property-set (principal-search-
     property*) > 
     <!ELEMENT principal-search-property (prop, description) > 


20 NOTE TO RFC EDITOR 

        *** This section (Section 20) MUST be removed before 
        publication as an RFC *** 

        Section 9.1 defines 

   As of the REPORT method. The REPORT method is 
        also defined in draft-ietf-deltav-versioning-15, in Section 
        3.6, using identical text. This was done to avoid making writing of this 
        specification dependent on draft-ietf-deltav-versioning.  

        If draft-ietf-deltav-versioning is specification, the DeltaV protocol, 
   described in draft-ietf-deltav-versioning-20, has been approved by 
   the IESG, but not yet published as an RFC before RFC. Within this specification,
   the DeltaV protocol is referenced as [RFCxxxx]. These references need
   to be replaced with the actual RFC number. As well, the citation in 
   Section 9.1 MUST 17.1 also needs to be removed. updated with the correct RFC number, 
   and the month of issue. 

 




Clemm, Hopkins, Sedlar, Whitehead                          [Page 46] 59] 
----