INTERNET-DRAFT                   Eric Sedlar, Oracle Corporation
    draft-ietf-webdav-acl-01.txt                   Geoffrey Clemm, Rational Software
          draft-ietf-webdav-acl-02         Anne Hopkins, Microsoft Corporation
                                           Eric Sedlar, Oracle Corporation

          Expires November 1, 2000         May 1, January 14, 2001         July 14, 2000

                           Access Control Extensions to WebDAV

          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 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 resource-types
          that define the WebDAV Access Control extensions to the HTTP/1.1
          protocol.

    Sedlar, Clemm                                       [Page 1]

          Table of Contents

          1 INTRODUCTION............................................3
          1.1 Notational Conventions................................3

          2 PRINCIPALS..............................................3

          3 RIGHTS..................................................4
          3.1 RIGHTS-DISCOVERY method...............................5 DAV:access-rights property............................5
          3.2 Rights defined by WebDAV..............................6
           3.2.1 read Right........................................6
           3.2.2 write Right.......................................6 Right.......................................7
           3.2.3 readacl Right.....................................6 Right.....................................7
           3.2.4 writeacl Right....................................6 Right....................................7
           3.2.5 all Right.........................................6 Right.........................................7

          4 ACCESS CONTROL PROPERTIES...............................7
          4.1 Example 1 - Retrieving Access Control information.....8 Information................11
           4.1.1 Example: Retrieving Access Control information...11
          4.2 Setting Access Control Information...................12
           4.2.1 Example: Setting Access Control information......13

          5 USING ACLS..............................................9 ACLS.............................................14
          5.1 System Controlled Rights.............................14
          5.2 Special Principal Identifiers........................15
          5.3 ACL Semantics Options................................15
           5.3.1 FirstSpecific....................................16
           5.3.2 ExplicitDenyPrecedence...........................16

          6 ACL METHOD.............................................10 INHERITANCE........................................18
          6.1 Example 1 - Setting ACLs.............................10

    7 Inheritable ACEs.....................................18
          6.2 Propagate ACE but do not use for Access Check on this resource....19
          6.3 Propagate to immediate children only.................19
          6.4 Protect ACL INHERITANCE / DEFAULT ACLS.........................11

    8 from inheritance.........................19

          7 XML SCHEMA FOR DEFINED ELEMENTS........................12

    9 ELEMENTS........................20

          8 INTERNATIONALIZATION CONSIDERATIONS....................13

    10 CONSIDERATIONS....................21

          9 SECURITY CONSIDERATIONS..............................13 CONSIDERATIONS................................21

          10  SCALABILITY..........................................21

          11  SCALABILITY..........................................13  AUTHENTICATION.......................................21

          12  AUTHENTICATION.......................................13

    13  IANA CONSIDERATIONS..................................13

    14 CONSIDERATIONS..................................21

          13  INTELLECTUAL PROPERTY................................13 PROPERTY................................21

          14  ACKNOWLEDGEMENTS.....................................22

          15  ACKNOWLEDGEMENTS.....................................14  INDEX................................................22
          16  INDEX................................................14  REFERENCES...........................................22

          17  REFERENCES...........................................14

    18  AUTHORS' ADDRESSES...................................15

    19 ADDRESSES...................................23

          18  STILL TO DO :........................................15

    Sedlar, Clemm                                       [Page 2] :........................................23

          19  OPEN ISSUES:.........................................25

          1  INTRODUCTION

               The underlying principle of access control is that who you are
               determines how you can access 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" is determined by an "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 rights that are either granted or denied to that
               principal.

          1.1 Notational Conventions

               The augmented BNF used by this document to describe protocol
               elements is described in Section 2.1 of [RFC2068]. Because this
               augmented BNF uses the basic production rules provided in Section
               2.2 of [RFC2068], those rules apply to this document as well.
               The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
               NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
               "OPTIONAL" in this document are to be interpreted as described in
               [RFC2119].

          2  PRINCIPALS

               A principal identifies an entity that can be given access rights
               to HTTP resources.  On many implementations, a user or a group
               will be examples of principals, but other types of principals are
               possible.  For the most part, any classification or other
               information about the entity identified by a principal is opaque
               with respect to this specification, and is dependent on the
               implementation.
               Principals are manifested to clients as a HTTP resource,
               identified by a URL.  The set of properties exposed by that
               resource are implementation dependent, although certain
               properties are required by this specification.  Those properties
               include:

           @ <dav:principalname>:
               . DAV:principalname:    A "live" 'live' property containing the name
                 used to authenticate this principal (typically typed into a
                 login prompt/dialog).  [OPTIONAL]

           @ <dav:displayname>:
               . DAV:displayname: A property containing a human-readable
                 description of this principal.  This property may be "live"
                 and not settable via PROPPATCH. [REQUIRED]

           @ <dav:principal-type>:

               . DAV:principal-type:   A "live" 'live' property containing a
                 classification word for this principal.  The values <dav:user/> DAV:user
                 and <dav:group/> DAV:group are choices for value of this property
                 recommended by this spec. The presence of

    Sedlar, Clemm                                       [Page 3] this property can be
                 used to distinguish it as a principal from other resources on
                 a WebDAV server.  (Note that <dav:resourcetype> DAV:resourcetype may not be used,
                 as all collections must use the value "collection" for <resourcetype>,
                 DAV:resourcetype, which wouldn't distinguish normal
                 collections from principal collections.) [REQUIRED]

               Server implementations may include any other descriptive
               information for a principal via properties.
               A principal resource may or may not be a collection.  A
               collection principal may only contain other principals (not other
               types of resources).  Servers that support aggregation of
               principals (e.g. groups of users or other groups) MUST manifest
               them as collection principals.  The WebDAV methods for examining
               maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used to
               maintain collection principals.  Membership in a collection
               principal is recusive, recursive, so a principal in a collection principal
               A contained by collection principal B is a member of both
               collection principals.  Implementations not supporting recursive
               membership in principal collections can return an error if the
               client attempts to bind collection principals into other
               collection principals.  Using WebDAV methods to alter the content
               of a principal (e.g. using PROPPATCH or PUT) is outside the scope
               of this specification, and is not required, recommended, or
               forbidden by this spec.

          3  RIGHTS

               A right controls access to a particular set of HTTP operations on
               a resource.  The set of rights that apply to a particular
               resource may vary with the <dav:resourcetype> DAV:resourcetype of the resource, as
               well as between different server implementations.  To promote
               interoperability, however, WebDAV defines a set of well-known
               rights (e.g. <dav:read> DAV:read and <dav:write>), DAV:write), which can at least be used
               to set some context to the other rights defined on a particular
               resource.
               Rights may be aggregates of other rights.  For example, one
               implementation may split out a right controlling the ability to
         BIND
               add children into to a collection from the right allowing a resource
               to be removed from a collection.  Since these rights control the
               ability to write to a collection, these rights would be
               aggregated by the <dav:write> DAV:write right.  The relationships between
               atomic rights and aggregate rights can be discovered via the RIGHTS-DISCOVERY HTTP method
               DAV:access-rights property on a particular resource.  Servers may
               specify some rights as abstract, which means that it
         may MUST not
               appear in an ACL, but is described in the RIGHTS-
         DISCOVERY method DAV:access-rights
               property to aid in setting context.  Server implementations must
               return the same response to the RIGHTS-
         DISCOVERY method DAV:access-rights property on all
               of the resources with the same
         <dav:resourcetype> DAV:resourcetype value.

    Sedlar, Clemm                                       [Page 4]

          3.1 RIGHTS-DISCOVERY method

         Rights discovery DAV:access-rights property

               The DAV:access-rights property is a method with no arguments, live property that returns contains
               the rights aggregation tree. The DAV:access-rights property MUST
               be available on every resource available via a WebDAV Access
               Control-compliant server. Each right appears as an XML element,
               where aggregate rights list all of their children as sub-
               elements. Each right element can contain the following
               attributes:

           @
               . abstract (Boolean):  "true" 'true' if this right cannot MUST NOT be used in
                 an ACL/ACE. Defaults to "false"

           @ description 'false.' Note: an abstract right need
                 not be an aggregate right.

               . Description (string): a human readable human-readable description of what
                 this right controls access to.  Required. [REQUIRED]. The server MAY
                 localize this description, based on the Accept-Language header
                 of the request.

               For example, the following response might be generated to a
         RIGHTS-DISCOVERY
               request on a WebDAV server implemented by a
         relational database (where the resource in this case corresponds
         to a table): server.
               Request
         RIGHTS-DISCOVERY /schemas/scott/emp
               PROPFIND /file HTTP/1.1
               Host: www.foo.bar
               Content-type: text/xml; charset="utf-8"
         Content-Length:
               Accept-Language: en-us
               Depth: 0
               Content-Length: xxx

               <?xml version="1.0" encoding="utf-8"?>
               <D:propfind xmlns:D="DAV:">
                   <D:prop>
                         <D:access-rights/>
                    </D:prop>
               </D:propfind>

               Response
               HTTP/1.1 200 Success 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxxxx xxx

               <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?> version="1.0"?>
               <D:multistatus xmlns:D="DAV:"
               xlmns:A="http://www.foo.bar/schema/">
                 <D:response>
           <D:all abstract=true description="All access">
                   <D:href>http://www.foo.bar/file</D:href>
                   <D:propstat>
                     <D:status>HTTP/1.1 200 OK</D:status>
                     <D:prop>
                       <D:access-rights>
                         <D:all>
                          <D:write abstract=true abstract="true" description="Write any database row">
               <ORA:insert abstract=false description="Insert a row"/>
               <ORA:update abstract=false
               object">
                            <A:create abstract="false" description="Create an
               object"/>
                            <A:update abstract="false" description="Update a row"/>
               <ORA:delete abstract=false an
               object"/>
                            <A:delete abstract="false" description="Delete a row"/>
             </D:write> an
               object"/>
                          <D:write/>
                          <D:read abstract=false description="SELECT data from a row"/> abstract="false" description="Read any
               object"/>
                          <D:readacl abstract=false abstract="false" description="Read the
               ACL"/>
             <D:acadmin abstract=false description="Update
                          <D:writeacl abstract="false" description="Write the ACL and
         owner"/>
               ACL"/>
                        </D:all>
                       </D:access-rights>
                     </D:prop>
                   </D:propstat>
                 </D:response>
               </D:multistatus>

               It is envisioned that a WebDAV ACL-aware administrative client
               would list the available rights in a dialog box, and allow the
               user to choose non-abstract rights to apply in an ACE.  The
               rights tree is useful programmatically to map well-known rights
               (defined by WebDAV or other standards groups) into rights that
               are supported by any particular server implementation.

    Sedlar, Clemm                                       [Page 5]

          3.2 Rights defined by WebDAV

               The rights defined by WebDAV access control MUST be present in
               the response to the RIGHTS-DISCOVERY method, DAV:access-rights property, although they may be abstract
               (and not usable within an ACE on a particular implementation).
               Ability to perform a given method on a resource MUST be
               controlled by some right.  Authors of Internet drafts that define
               new methods must specify which right (by defining a new right, or
               mapping to one below) is required to perform the method.  A
               principal with no rights to a resource should be denied any HTTP
               access to that resource.

          3.2.1read Right

               Name:            <dav:read>            DAV:read
               Purpose:         The read right provides and restricts access to
               information regarding the state of the resource, including the
               resource's properties. Affected methods include GET and PROPFIND.
               The read right does not affect the OPTIONS method since it
               reflects capabilities rather than state.

          3.2.2write Right

               Name:            <dav:write>            DAV:write
               Purpose:         The <write> write right affects the same methods as the
               Write Lock. Please refer to [WEBDAV] section 5.3 for the list of
               affected methods. Note however, that a write lock is a different
               mechanism than a write access change, although they affect the
               same methods, they have independent methods to set them and
               independent error codes.

          3.2.3readacl Right

               Name:            <dav:readacl>            DAV:readacl
               Purpose:         The <readacl> readacl right provides and restricts access
               to the <dav:acl> DAV:acl property of this resource, rather than the <dav:read>
               DAV:read right.  If a user has the <readacl> readacl right and not the <read> read
               right, the <dav:acl> property ONLY is DAV:acl and DAV:access-rights properties MUST be
               accessible via PROPFIND, and the GET method is not authorized.
               If a user has the <read> read right and not the <readacl> readacl right, the <dav:acl>
         property
               DAV:acl and DAV:access-rights properties will not be included in
               any PROPFIND requests on the associated resource.

          3.2.4writeacl Right

               Name:            <dav:writeacl>            DAV:writeacl
               Purpose:         The <writeacl> (Access Control ADMINistration) writeacl right provides and restricts access
               to ACL method, which is the
         only means of altering the <dav:acl> (and indirectly,
         <dav:rights>) property of a resource. DAV:acl and DAV:owner properties.

          3.2.5all Right

               Name:            <dav:all>

    Sedlar, Clemm                                       [Page 6]            DAV:all
               Purpose:         The <dav:all> DAV:all right controls all other rights on
               this resource.  If the <dav:all> DAV:all right appears in an ACE, it is an
               error to have any other right in that ACE.  This right is merely
               shorthand for all of the rights enumerated in the RIGHTS-
         DISCOVERY method, access-rights
               property, and should not control access to rights not exposed via
               that route.

          4  ACCESS CONTROL PROPERTIES

               This specification defines a number of new properties for WebDAV
               resources.  Access control properties may be set and retrieved
               just like other WebDAV properties, using the PROPFIND method. and
               PROPPATCH method (subject to permissions and 'liveness.'  An HTTP
               resource on a WebDAV ACL-compliant Access Control-compliant server MUST contain
               the following properties:

           @ <dav:owner>:
               . DAV:owner:  A property containing the principal information
                 identifying a particular user as the owner of the resource.

                 This property is readable by anyone with read access to the
                 resource.  There is no provision for a client
                             updating this property in this spec, however
                             it is recommended that any authenticated user
                             with appropriate administrative privileges be
                             allowed to issue a PROPPATCH to update its
                             value. Normally, an attempt to PROPPATCH this
                             property will result in a 401 (Not
                             Authorized) error.  [REQUIRED]

           @ <dav:owner-name>:   A "live" property containing a human-
                             readable description of the <dav:owner>
                             [OPTIONAL]

           @ <dav:rights>:

               . DAV:rights: A "live" 'live' readonly property containing the list of
                 rights of the currently authenticated HTTP user.  Read  The read
                 right controls read access to this property is
                             controlled by the <read> right.  This
                             property can NEVER be set directly. property. [REQUIRED]

           @ <dav:acl>:

               . DAV:acl:    A "live" 'live' property containing one or more
                             <dav:ace> DAV:ace
                 tags, which specify which principals are to get access to what
                 rights, for the resource with this ACL property.  [REQUIRED]

               . DAV:aclsemantics: A readonly property indicating the ACL
                 semantics model supported by the system.  [REQUIRED]

               . DAV:protectaclfrominheritance:  A "live" property indicating
                 that the ACL does not inherit any ACEs.  If this property is
                 present, the ACL should contain no ACEs with the DAV:inherited
                 element present.  If this property is not present and the
                 system supports ACL inheritance, then the ACL will contain
                 inheritable ACEs from its parent resource.  If a resource
                 without this property present is updated with this property,
                 it is a client choice whether to remove the inherited ACEs or
                 retain them but remove the DAV:inherited element from the
                 ACEs.   [OPTIONAL]

               The <dav:acl> DAV:owner element (property) contains 0 one or more of the following XML
               elements:

           @ <dav:ace>:     An access control entry, which specifies
               . DAV:href:   This contains the
                             set of rights to be granted URI to a single
                             principal.

         The <dav:ace> element contains the following XML elements:

    Sedlar, Clemm                                       [Page 7] 
           @ <dav:grant>:   Contains principal resource
                 that is the set 'owner' of XML elements
                             corresponding  the resource.  Normally, an attempt to
                 PROPPATCH this property will result in a 401 (Not Authorized)
                 error.  The principal indicated by the rights being owner property is
                 implicitly granted via
                             this ACE.  Must contain at least one right

           @ <dav:deny>:    Contains readacl and writeacl rights.  This enables
                 the set of XML elements
                             corresponding owner to restore an appropriate ACL in the rights being denied via
                             this ACE.  Must contain at least one right,
                             if present.

           @ <dav:principal-id>: A URL of case that it
                 becomes maliciously or accidently corrupted such that no
                 principal is granted the writeacl right by any ACE.
                 [REQUIRED]

               . DAV:principalname, DAV:displayname, DAV:principal-type: These
                 are the same as the properties that can exist on the principal resource
                 URI. In this ACE
                             applies to, context they are considered 'live.' [OPTIONAL]

               The DAV:acl element (property) contains 0 or one more of the tags <dav:owner>
               following XML elements:
               . DAV:ace:    A "live" property representing an access control
                 entry, which specifies the set of rights to be either granted
                 or
                             <dav:all-principals>.  Always present. denied to a single principal.

               The
                             value DAV:ace element contains the following XML elements:
               . DAV:grant:  Contains the set of XML elements corresponding to
                 the rights being granted via this element must ACE.  MUST contain at least
                 one right.  MUST NOT be unique within
                             an ACL.

           @ <dav:principal>: present if the DAV:deny element is
                 present.

               . DAV:deny:   Contains properties the set of XML elements corresponding to
                 the rights being denied via this ACE.  MUST contain at least
                 one right, if present.  MUST NOT be present if the DAV:grant
                 element is present.

               . DAV:principal:   Contains information about the principal
                 resource (made available here this ACE applies to. [REQUIRED].

               . DAV:acepropertytypes: A "live" property containing one or more
                 elements, each of which is an XML tag identifying either a
                 property on this resource or a property on a child resource
                 that may inherit this ACE.  Presence of DAV:acepropertytypes
                 distinguishes this ACE as a "Property ACE."  The rights
                 associated with a "Property ACE" control access to avoid only the
                             need for
                 property(ies) contained in DAV:acepropertytypes, and do not
                 control access to the resource as a separate PROPFIND request).
                             Optional.

         A PROPFIND whole.  The set of access
                 rights supported on Property ACEs may be all or a resource subset of
                 the DAV:access-rights present on this resource.  This spec
                 does not provide a WebDAV ACL server might produce mechanism to specify a different set of
                 access-rights for a property, than for the
         following XML output:

    4.1 Example 1 - Retrieving Access Control information

         Request
         PROPFIND /top/container HTTP/1.1
         Host: www.foo.bar
         Content-type: text/xml; charset="utf-8"
         Content-Length: 0
         Depth: 0

         <?xml version="1.0">
         <D:propfind xmlns:D="DAV:">
           <D:allprop/>
         </D:propfind>

         Response
         HTTP/1.1 200 Success
         Content-Type: text/xml
         Content-Length: xxxxx

         <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.ietf.org/standards/webdav/ AS =
         D"?>
         <D:response>
           <D:propstat>
             <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
             <D:displayname>Example collection</D:displayname>
             <D:resourcetype><D:collection/></D:resourcetype>
             <D:supportedlock> XXXXX</D:supportedlock>

         <D:owner>http://www.rational.com/principals/users/gclemm</d:owner
         >
             <D:owner-name>Geoffrey Clemm</d:owner-name>

    Sedlar, Clemm                                       [Page 8] 
             <D:rights>
               <D:read/><D:readacl/>
             </D:rights>
             <D:acl>
                <D:ace>
                  <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                  <D:principal-id>
                  <D:href>http://www.foo.com/users/esedlar</D:href>
                </D:principal-id>
                  <D:principal>
                    <D:principal-type>User</D:principal-type>
                    <D:principalname>esedlar</D:principalname>
                    <D:displayname>Eric Sedlar</D:displayname>
                  </D:principal>
                </D:ace>
                <D:ace>
                  <D:grant><D:read/><D:readacl/></D:grant>
                <D:deny><D:writeacl/></D:deny>
                  <D:principal-id>
                    <D:href>http://www.foo.com/groups/marketing</d:href>
                </D:principal-id>
                  <D:principal>
                    <D:principal-type>Group</D:principal-type>
                    <D:displayname>Foo.Com marketing
    department</D:displayname>
                    <D:principalname>mktdept</D:principalname>
                  </D:principal>
                </D:ace>
                <D:ace>
                <D:grant><D:read/></D:grant>
                  <D:principal-id><d:all/></D:principal-id>
                </D:ace>
             </D:acl>
           <D:propstat>
         <D:response>

    5  USING ACLS

         By default, a principal has no access rights to an object
         protected by an ACL. A particular ACE may either grant or deny resource.  An
                 implementation that supports a different set of rights to access-rights
                 for a single principal.  It is illegal property than for the resource, must return an ACL to
         have two ACEs applying error
                 "Unsupported Right" on an attempt to the same principal.  However, since write a
         server may match the currently authenticated HTTP user Property ACE with
         multiple principals, it
                 rights not supported by the server.  [OPTIONAL]

               . DAV:inherittochildtype:    A "live" property containing one or
                 more elements, each of which is possible for multiple ACEs to apply to an XML tag identifying the current user.  In
                 type of child object that will inherit this case, if a particular right ACE.  This
                 property is denied
         to only present if DAV:inheritanceflags contains at
                 least one of the following: DAV:inheritonly,
                 DAV:containerinherit, or DAV:objectinherit.  A child of the
                 current user by any ACE, resource will only inherit this supercedes any ACE that
         might grant that right.  This is the case regardless if a ("more
         specific") ACE granting access applied to a principal identifying the user directly, while type of the ACE denying access applied to a
         collection principal
                 child object is present in DAV:inherittochildtype.

               . DAV:inheritanceflags: A "live" property containing that user.  The particular order
         of flags
                 indicating the ACEs within inheritance features of this ACE.  For an ACL ACE
                 that is irrelevant.  The <principal-id> tag
         can also contain neither inherited, nor inheritable, this element may
                 be either not present, or present but empty.  [OPTIONAL]

               . DAV:inheritancesource: A readonly property containing the following special tags: <owner>, <all>,
         <unauthenticated>.  These tags have URL
                 of the following meaning:

    Sedlar, Clemm                                       [Page 9] 
           @ owner:  The principal identified by resource from which this ACE was inherited (contained
                 within an DAV:href element).  In other words, the owner property ACL on
              this resource is granted or denied the rights specified in
                 resource referred to by this ACE.

           @ all:  The URI contains the inheritable
                 explicit ACE which, when propagated to the current user always matches this ACE, whether or
              not s/he is authenticated.

           @ unauthenticated:  The resource,
                 resulted in the current user matches this ACE if not
              authenticated

         Server implementations ACE. This element may limit contain the number
                 special value of ACEs in an ACL.
         However, ACL-compliant servers are required DAV:system-ace to support at least
         one indicate that the ACE granting rights to a single principal, is
                 read-only and one ACE
         granting represents rights to a collection principal.  The granted implicitly by the
                 system.  This element may contain the special value of
                 DAV:unknown if the server should
         return an error "Too many ACEs" in this case.

    6  ACL METHOD

         The ACL Method provides a mechanism to set ACL information. Its
         request body is used unable to define alterations generate a valid URI to
                 the ACL of the resource identified by the request-URI. Its response body from which this element was inherited. This
                 element MUST be present if DAV:inheritanceflags contains the current ACL
                 DAV:inherited flag for that resource. inherited ACEs and MUST NOT be present
                 for explicit ACEs.

               The ACL method
         replaces DAV:principal element contains the <acl> and <owner> properties on following elements:
               . DAV:href:   This is a URI representing the specified resource with to which
                 the properties in ACE applies, or one of the request.  All readable ACEs
         previously stored special principal identifier
                 tags (e.g.,  DAV:owner) described in the ACL on the indicated resource "Special Principal
                 Identifiers" section of this spec. [REQUIRED]

               . DAV:principalname, DAV:displayname, DAV:principal-type: These
                 are
         removed, so an ACL method the same as the properties that can exist on a resource with an unreadable <acl>
         property will be ignored.  (If the server implements rights
         outside of those defined in principal
                 URI. In this specification, context they might allow
         only some ACEs to be visible¨in this case, only part are considered 'live.' [OPTIONAL]

               The DAV:inheritanceflags element contains 0 or more of the ACL
         will be replaced).

         Change requests through
               following XML elements:
               . DAV:inherited:   This flag indicates the ACE is inherited from
                 the ACL method on a different resource, identified in
                 DAV:inheritancesource.  This flag MUST be atomic. If any
         part of the change request fails then all changes MUST fail.  The
         presence of present for an empty ACL causes all ACEs in the ACL, including
         ACEs
                 inherited ACE and MUST NOT be present for associated properties, to an explicit ACE.
                 This flag must not be deleted.  An empty request
         body will cause no change to the ACL or associated values.  If present if the <principal>
                 DAV:protectaclfrominheritance element (specifying properties of the is present on this
                 resource
         identified by unless the ACE's <principal-id>) is specified, it (and its
         children) is ignored.

    6.1 Example 1 - Setting ACLs

         An ACL request body is an acl-info XML element.  The <dav:acl-
         info> DAV:inheritancesource element contains properties that can be set by the ACL
         method (currently just <acl>).

         Request
         ACL /top/container HTTP/1.1
         Host: www.foo.com
         Content-Type: text/xml
         Content-Length: xxxx
         <?namespace href = "http://www.ietf.org/standards/webdav/ AS =
         D"?>
         <D:acl-info>

    Sedlar, Clemm                                      [Page 10] 
           <D:acl>
                <D:ace>
                  <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                  <D:principal-id>
                    <D:href>http://www.foo.com/users/esedlar</D:href>
                </D:principal-id>
                </D:ace>
                <D:ace>
                  <D:grant><D:read/> </D:grant>
                  <D:principal-id>
                  <D:href>http://www.foo.com/groups/marketing</D:href>
                </D:principal-id>
                </D:ace>
           </D:acl>
         </D:acl-info>

         Response
         HTTP/1.1 200 Success
         Content-Length: 0
                 special value DAV:system-ace, indicating that this ACE wasn't
                 really inherited, but reflects implicit system-granted rights.
                 [REQUIRED]

               . DAV:inheritonly: This request changes flag indicates the group ACE to disallow read should be ignored
                 during access to the
         ACL check.  The ACE is present for the marketing group. purposes of
                 inheritance only and does not affect the security of the
                 current resource.  [OPTIONAL]

               . DAV:containerinherit: This flag indicates that container
                 objects inherit this ACE as an effective ACE.  The other information had to
                 DAV:inheritonly flag, if also present on this ACE, will be
         recopied
                 removed from the ACL retrieved in inherited effective ACE on the previous example.

    7  ACL INHERITANCE / DEFAULT ACLS

         To be added

    Sedlar, Clemm                                      [Page 11] 
    8  XML SCHEMA FOR DEFINED ELEMENTS

           <?xml version='1.0'?>
           <!-- XML Schema for WebDAV ACLs -->
           <!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN" container.  If
                 the DAV:nopropagateinheritance flag is present on the current
                 ACE, the DAV: containerinherit flag is removed from the
                 inherited ACE on the container.  [REQUIRED]

               . DAV:objectinherit:    This flag indicates that non-container
                 resources inherit this ACE as an effective ACE.  The
                 DAV:inheritonly flag, if also present on this ACE, will be
                 removed from the inherited effective ACE on the non-container
                 resource.  If the DAV:nopropagateinheritance> flag is not
                 present, then container resources will also inherit this ACE
                 with the addition of the DAV:inheritonly> flag.  [REQUIRED]

               . DAV:nopropagateinheritance: This flag indicates the ACE should
                 be inherited one level only.  If an object inherits this ACE,
                 the DAV:containerinherit and DAV:objectinherit flags are
                 removed from the resultant inherited ACE, preventing further
                 propagation of this ACE.  [OPTIONAL]
               The DAV:aclsemantics element MUST contain exactly one of the
               following XML elements:
               . DAV:firstspecific:    This element is present if the ACL
                 conforms to the FirstSpecific semantics described in this
                 spec.

               . DAV:explicitdenyprecedence: This element is present if the ACL
                 conforms to the ExplicitDenyPrecedence semantics described in
                 this spec.

          4.1 Retrieving Access Control Information

               Retrieving Access Control information is done via PROPFIND on the
               resource in question. All ACL properties are also returned as
               part of the response to PROPFIND allprop request.

          4.1.1Example: Retrieving Access Control information

               The following example shows how access control information could
               be retrieved using PROPFIND method.
               Request
               PROPFIND /top/container/ HTTP/1.1
               Host: www.foo.bar
               Content-type: text/xml; charset="utf-8"
               Content-Length: 0
               Depth: 0

               <?xml version='1.0'>
               <D:propfind xmlns:D='DAV:'>
                 <D:allprop/>
               </D:propfind>

               Response
               HTTP/1.1 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxx

               <?xml version="1.0" encoding="utf-8" ?>
               <D:multistatus xmlns:D="DAV">
               <D:response>
                 <D:propstat>
                   <D:status>HTTP/1.1 200 OK</D:status>
                   <D:prop>
                     <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
                     <D:displayname>Example collection</D:displayname>
                     <D:resourcetype><D:collection/></D:resourcetype>
                     <D:supportedlock> XXXXX</D:supportedlock>
                     <D:owner>
                       <D:href>http://www.foo.bar/users/gclemm
                     <D:displayname>Geoffrey Clemm</D:displayname>
                     </D:owner>
                     <D:rights>
                       <D:read/><D:readacl/>
                     </D:rights>
                     <D:acl>
                        <D:ace>
                          <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                          <D:principal>
                            <D:href>http://www.foo.bar/users/esedlar</D:href>
                            <D:principal-type><DAV:user/></D:principal-type>
                            <D:principalname>esedlar</D:principalname>
                            <D:displayname>Eric Sedlar</D:displayname>
                          </D:principal>
                        </D:ace>
                        <D:ace>
                          <D:grant><D:read/><D:readacl/></D:grant>
                          <D:principal>
                            <D:href>http://www.foo.bar/groups/marketing</d:href>
                            <D:principal-type><DAV:group/></D:principal-type>
                            <D:displayname>Foo.Bar marketing
               department</D:displayname>
                            <D:principalname>mktdept</D:principalname>
                          </D:principal>
                        </D:ace>
                        <D:ace>
                       <D:deny><D:writeacl/></D:deny>
                           <D:principal>

               <D:href>http://www.foo.bar/groups/marketing</d:href>
                             <D:principal-type><DAV:group/></D:principal-type>
                             <D:displayname>Foo.Bar marketing
               department</D:displayname>
                             <D:principalname>mktdept</D:principalname>
                           </D:principal>
                        <D:ace/>
                        <D:ace>
                        <D:grant><D:read/></D:grant>
                          <D:principal><d:all/></D:principal>
                        </D:ace>
                     </D:acl>
                   </D:prop>
                 <D:propstat>
               <D:response>
               <D:multistatus>

          4.2 Setting Access Control Information

               An ACL is set by executing a PROPPATCH against the resource that
               contains the DAV:acl property.  An ACL must be written in its
               entirety. All ACEs (readable by the current user)  previously
               stored in the ACL on the indicated resource are removed. (If the
               server implements rights outside of those defined in this
               specification, they might allow only some ACEs to be visible=97
               behaviour on a PROPPATCH is undefined with respect to this
               specification).
               Setting an empty ACL property causes all ACEs in the ACL,
               including ACEs for associated properties, to be deleted.
               Since permission to set an ACL is typically controlled by a
               different right from permission to set other properties, it is
               recommended that ACL-setting PROPPATCHes be executed
               independently from PROPPATCHes of other properties. PROPATCH as
               defined in [WEBDAV] is an atomic operation, so failure to set the
               ACL will result in a failure to set all other properties.
               [WEBDAV] also defines that operations must be performed from top
               to bottom, so multiple instances of the DAV:acl element in a
               single PROPPATCH result in only the last being set.
               Changing ownership of a resource requires setting the DAV:href
               element of the DAV:owner property.

          4.2.1Example: Setting Access Control information

               The following example follows from the previous example and
               changes the group ACE to disallow read access to the ACL for the
               marketing group. The other information had to be copied from the
               ACL retrieved in the previous example.
               Request
               PROPPATCH /top/container HTTP/1.1
               Host: www.foo.bar
               Content-Type: text/xml
               Content-Length: xxxx

               <?xml version="1.0"?>
               <D:propertyupdate xmlns:D="DAV:">
                  <D:set>
                     <D:prop>
                     <D:acl>
                          <D:ace>
                            <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                            <D:principal>
                              <D:href>http://www.foo.bar/users/esedlar</D:href>
                          </D:principal>
                          </D:ace>
                          <D:ace>
                            <D:grant><D:read/></D:grant>
                            <D:principal>
                            <D:href>http://www.foo.bar/groups/marketing</D:href>
                          </D:principal>
                          </D:ace>
                     </D:acl>
                   </D:prop>
                 </D:set>
               </D:propertyupdate>

               Response
               HTTP/1.1 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxx

               <?xml version="1.0"?>
               <D:multistatus xmlns:a="DAV:">
                 <D:response>
                   <D:href>http://www.foo.bar/top/container/</D:href>
                   <D:propstat>
                     <D:status>HTTP/1.1 200 OK</D:status>
                     <D:prop>
                       <D:acl/>
                     </D:prop>
                   </D:propstat>
                 </D:response>
               </D:multistatus>

          5  USING ACLS

               An ACL contains zero or more ACEs that express the rights granted
               or denied to the principal specified in the ACE.  An ACL with
               zero ACEs implies that no principal is granted any rights.  A
               particular ACE may either grant or deny a set of rights to a
               single principal.  However, since a server may match the
               currently authenticated HTTP user with multiple principals (for
               instance, in the case where one principal refers to the user and
               another principal refers to a group to which the user belongs),
               it is possible for multiple ACEs to "match" the current user.  A
               user has no access rights to an object protected by an ACL unless
               that user matches one or more of the principals specified in the
               ACEs.
               Server implementations may limit the number of ACEs in an ACL.
               However, ACL-compliant servers are required to support at least
               one ACE granting rights to a single principal, and one ACE
               granting rights to a collection principal.  If a client tries to
               write an ACL containing more ACEs than the server supports, the
               server should return an error "Too many ACEs."

          5.1 System Controlled Rights

               Some implementations may grant certain rights implicitly.  For
               example, some systems grant the resource owner DAV:readacl and
               DAV:writeacl implicitly to prevent an ACL from becoming
               irrevocably locked by an update that grants no one the
               DAV:writeacl right.  Any rights granted implicitly by the system
               should be reflected as standard ACEs in the ACL returned to the
               client.  Since these implicit permissions are read-only, they
               should be reflected as "system controlled" ACEs where
               DAV:inheritanceflags contains DAV:inherited and the
               DAV:inheritancesource element contains DAV:system-ace.

          5.2 Special Principal Identifiers

               The DAV:principal element in an ACE may contain, instead of a
               specific security principal identifier, one of the following
               special tags:
               . DAV:owner:  The principal identified by the owner property on
                 this resource is granted or denied the rights specified in
                 this ACE.

               . DAV:all:  The current user always matches this ACE, whether or
                 not s/he is authenticated.

               . DAV:authenticated:  The current user matches this ACE if
                 authenticated.

               . DAV:unauthenticated:  The current user matches this ACE if not
                 authenticated

               . DAV:selfprincipal: The current user matches this ACE if the
                 resource (for example, a user information object or security
                 principal account) associated with this ACL is a
                 representation of the current user.

          5.3 ACL Semantics Options

               In order to accommodate the different semantics of multiple
               existing server implementations, we define a number of ACL
               Semantics options.  The tag associated with each option is used
               to indicate what semantics to apply to the ACL.  A client may use
               this tag to display information that helps an ACL author
               understand the implications of his updates.  The client must also
               use this tag to determine the legal semantics for ordering ACEs
               prior to updating the ACL property.
               The following ACL Semantics options have been defined to
               indicate:
               . restrictions, if any, on the ordering of ACEs within a stored
                 ACL,

               . how to determine during access check which ACE(s) apply to a
                 user that matches multiple principals,

               . how to combine the rights granted or denied by multiple
                 matching ACEs during access check.

               Additional ACL models may be accommodated by defining and
               registering additional ACL Semantics tags.  [How is this done?
               TBD].
               Requested Rights: Some access check algorithms are based on not
               just the user identity and the ACEs, but also on the "requested
               rights," which is the set of rights required by the operation for
               which the access check is being performed.

               Effective Rights: The "effective rights" of a user is the set of
               all rights that would be granted to a user by a given ACL.  This
               set, which is exposed via the DAV:rights property, is independent
               of any operation "requested rights" and may be generated by a
               different algorithm than the access check algorithm that
               determines whether a user has specific requested rights.  Each
               right in the Effective Rights set applies to the user whether the
               right is requested individually, or in combination with other
               rights, in the requested rights for an operation.

          5.3.1FirstSpecific

               The FirstSpecific semantic model has the following
               characteristics:
               Order of ACEs: ACEs are ordered from "most specific" to "least
               specific."  Typically, the "most specific" ACEs identify
               principals that refer to a single user.  ACEs with "intermediate"
               specificity have principals that refer to a collection or group
               of users or other entities.  The "least specific" ACEs contain
               principals, like "World" or "Everyone," that indicate an
               unbounded set of users.  If multiple ACEs with the same level of
               specificity are present, their order relative to each other is
               not defined here.  Implementations of the FirstSpecific model are
               unlikely to have multiple ACEs in the intermediate and least
               specific categories (where multiple ACE matches are possible),
               making it unimportant to define a rule for relative ordering of
               ACEs within these two specificity levels.
               ACE Matching Algorithm:  ACEs are evaluated in the order in which
               they appear in the ACL, from first to last.  When a match is
               found, the algorithm is complete.  This first matching ACE alone
               is used to determine the effective rights of the user.  If it is
               a Grant ACE, then the user is granted all rights in the ACE.  If
               it is a Deny ACE, then the user is denied all rights in the ACE.
               Requested rights may be compared with the effective rights to
               determine if access should be granted.
               ACE Combining Algorithm: The FirstSpecific model never matches
               more than one ACE to a user, thus there's no need to combine the
               rights of multiple ACEs.
               Example Implementation: UNIX rights (rwx for user:group:world) is
               an example of the FirstSpecific model.

          5.3.2ExplicitDenyPrecedence

               The ExplicitDenyPrecedence model has the following
               characteristics:
               Order of ACEs: All Explicit ACEs must precede all Inherited ACEs.
               Within the group of Explicit ACEs, all Deny ACEs must precede all
               Grant ACEs.  Inherited ACEs are placed in the order in which they
               are inherited.  ACEs inherited from the resource's parent come
               first, then ACEs from the grandparent, and so on.

               ACE Matching and Combining Algorithm: The ACE matching and
               combining algorithms are not distinct in this model and must be
               described together.  A set of "Granted rights" and a set of
               "Denied rights", both initialized with zero rights, are
               maintained in the algorithms to check for Requested Rights and to
               calculate Effective Rights.  In both cases, ACEs are evaluated in
               the order in which they appear in the ACL, from first to last.
               Checking for Requested Rights: For each ACE evaluated, if the ACE
               matches the current user, then:
               . if it is a Grant ACE, any rights in the ACE that are not
                 already in the "Granted rights" or "Denied rights" sets are
                 added to the "Granted rights" set

               . if it is a Deny ACE, any rights in the ACE that are not
                 already in the "Granted rights" or "Denied rights" sets are
                 added to the "Denied rights" set

               If the "Granted rights" set now contains all rights in the set of
               "requested rights," then no more ACEs are evaluated and the
               algorithm completes with "Requested Access Granted."
               If the "Denied rights" set now contains any right that is in the
               set of "requested rights," then no more ACEs are evaluated and
               the algorithm completes with "Requested Access Denied."
               If neither of these cases is true, then the next ACE is
               evaluated.  If there are no more ACEs present in the ACL, then
               the algorithm completes with "Requested Access Denied" since the
               accumulated Granted rights did not contain all of the requested
               rights.
               Calculating the effective rights of a user: As in the check for
               requested rights, for each ACE evaluated, if the ACE matches the
               current user, then:
               . if it is a Grant ACE, any rights in the ACE that are not
                 already in the "Granted rights" or "Denied rights" sets are
                 added to the "Granted rights" set

               . if it is a Deny ACE, any rights in the ACE that are not
                 already in the "Granted rights" or "Denied rights" sets are
                 added to the "Denied rights" set

               If the union of the "Granted rights" and "Denied rights" now
               contains all possible rights, then no more ACEs are evaluated and
               the algorithm returns the Granted rights as the set of Effective
               Rights.
               Otherwise, the next ACE is evaluated.  If there are no more ACEs
               present in the ACL, then all rights present in the "Granted
               rights" set are returned as Effective Rights.
               Example Implementation: Microsoft Windows NT canonical ACLs are
               an example of this model.

          6  ACL INHERITANCE

               To support a more scalable administration model for configuration
               of access control information, the spec defines an ACL
               inheritance model that enables an ACL, or elements of an ACL, to
               be inherited and reused by other resources.  An ACL-compliant
               implementation is not required to support inheritance.
               Typically, an ACL defined on a container resource may be
               inherited by children of that container, grandchildren if they
               exist, and so on down the tree.  Although this hierarchical tree
               model of inheritance is popular, this spec does not require an
               implementation's ACL inheritance model to follow a tree structure
               where child resource inherits from parent resource.  Nonetheless,
               for convenience, this description of inheritance assumes that a
               child resource would inherit access control information from its
               parent.

          6.1 Inheritable ACEs

               Access control information is inherited at the granularity of an
               ACE.  An inherited ace is identified by the presence of the
               DAV:inherited element in the DAV:inheritanceflags property.  An
               "Explicit" ACE is an ACE defined directly on a resource, rather
               than inherited from a different resource.  An ACE without the
               DAV:inherited element is by definition an Explicit ACE.  Only
               Explicit ACEs may updated by the client.
               To indicate that an ACE should be inherited by child resources,
               the DAV:inheritanceflags should contain:
               . DAV:objectinherit to indicate that non-container children
                 should inherit the ACE,

               . DAV:containerinherit to indicate that container children
                 should inherit the ACE, or

               . both to indicate that all child resources should inherit the
                 ACE.

          6.2 Updating an inherited ACE

               When a child resource ACL inherits an ACE, the DAV:inherited
               flag is present on the ACE to indicate that this ACE is read-
               only (it may only be edited on the resource where the ACE was
               explicitly defined).  To assist users who want to make changes
               to the rights that appear in an inherited ACE, the resource from
               which the ACE was inherited (and therefore, on which the
               explicit ACE is defined and editable) is identified in the
               DAV:inheritancesource property.  If the inheritance source
               cannot be determined or if the system is unable to generate a
               valid URI to the resource from which the ACE was inherited,
               DAV:inheritancesource contains the special tag DAV:unknown.

          6.3 Propagate ACE but do not use for Access Check on this resource

               In some cases, an ACE (whether explicit or inherited) may be
               present on a container ACL purely for the sake of propagating
               the ACE to child objects and NOT to be used for access control
               on the container itself.  In this case, the  optional
               DAV:inheritonly flag is present on the ACE to indicate it should
               not be used for access check on this container.

          6.4 Propagate to immediate children only

               To indicate that an ACE should be inherited by children, but not
               by grandchildren or any further down the tree, the optional
               DAV:nopropagateinheritance flag is present on the ACE.  This
               flag indicates that when this ACE is inherited by child objects,
               the DAV:objectinherit and/or DAV:containerinherit elements must
               be removed from the inherited ACE.

          6.5 Protect ACL from inheritance

               To prevent an ACL from inheriting any ACEs, the optional
               DAV:protectaclfrominheritance property is set on the resource.
               If this property is present on a resource, the DAV:inherited
               element must not be present on any ACEs in that resource's ACL.
               Other inheritance flags may be present on the ACEs of this
               resource, since this ACL may be the source of inheritable ACEs
               for the subtree under this resource.

          7  XML SCHEMA FOR DEFINED ELEMENTS

                 <?xml version='1.0'?>
                 <!-- XML Schema for WebDAV ACLs -->
                 <!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN"
                 "WebDAVACL.dtd" >
                 <schema xmlns="http://www.w3.org/1999/XMLSchema"

                 targetNamespace="http://www.ietf.org/standards/webdav"
                         xmlns:dav="http://www.ietf.org/standards/webdav"
                         blockDefault="#all" elementFormDefault="qualified">

                 <element name="right" abstract="true">
                   <complexType content="empty">
                 </element>

                 <!--For those folks not familiar with XML Schema, minOccurs
                      defaults to 0, and maxOccurs defaults to 1 -->

                 <element name="dav:read" name="DAV:read" base="right" equivClass="right"/>
                 <element name="dav:write" name="DAV:write" base="right" equivClass="right"/>
                 <element name="dav:readacl" name="DAV:readacl" base="right" equivClass="right"/>
                 <element name="dav:writeacl" name="DAV:writeacl" base="right"
                 equivClass="right"/>
                 <element name="dav:all" name="DAV:all" base="right" equivClass="right"/>

                 <complexType name="dav:rights-list"> name="DAV:rights-list">
                   <choice minOccurs="1" maxOccurs="unbounded">
                   <element ref="dav:right"> ref="DAV:right">
                   <element name="dav:unauthenticated" name="DAV:unauthenticated" content="empty"/>
                   <element name="dav:all" name="DAV:all" content="empty"/>
                   <element name="dav:owner" name="DAV:owner" content="empty"/>
                 </complexType>

                 <complexType name="dav:ace"> name="DAV:ace">
                   <element name="dav:grant" type="dav:rights-list" name="DAV:grant" type="DAV:rights-list"
                            minOccurs="0" maxOccurs="1">
                   <element name="dav:deny" type="dav:rights-list" name="DAV:deny" type="DAV:rights-list"
                            minOccurs="0" maxOccurs="1">
                   <element name="dav:principal-id" name="DAV:principal-id" minOccurs="1"/>
                     <complexType>
                       <choice minOccurs="1">
                         <element name="dav:owner" name="DAV:owner" content="empty"/>
                         <element name="dav:all" name="DAV:all" content="empty"/>
                         <element name="dav:unauthenticated" name="DAV:unauthenticated" content="empty"/>
                         <element name="dav:href" name="DAV:href" type="uri"/>
                       </choice>
                     </complexType>
                   </element>
                   <element name="dav:principal" name="DAV:principal" minOccurs="0" maxOccurs="1">
                     <complexType>
                       <element name="dav:principal-name" name="DAV:principal-name" type="string"
                 minOccurs="1"/>

    Sedlar, Clemm                                      [Page 12]
                       <element name="dav:principal-type" name="DAV:principal-type" type="string"
                 minOccurs="1"/>
                     </complexType>
                   </element>
                 </complexType>

                 <element name="dav:acl"> name="DAV:acl">
                   <complexType>
                     <element name="dav:ace" type="dav:ace" name="DAV:ace" type="DAV:ace"
                            minOccurs="0" maxOccurs="unbounded"/>
                   </complexType>
                 </element>

                 <element name="dav:rights"> name="DAV:rights">
                   <complexType>
                     <choice minOccurs="1" maxOccurs="unbounded">
                       <element ref="dav:right"/> ref="DAV:right"/>
                     </choice>
                   </complexType>
                 </element>
                 </schema>

    9

          8  INTERNATIONALIZATION CONSIDERATIONS

               To be supplied.

    10

          9  SECURITY CONSIDERATIONS

               To be supplied.

    11 SCALABILITY

         To supplied.

          10 SCALABILITY

               To be supplied.

          11 AUTHENTICATION

               Authentication mechanisms defined in WebDAV will also apply to
               WebDAV ACL.

          12 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.

          13 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 supplied.

    12 AUTHENTICATION

         Authentication mechanisms defined found
               in WebDAV will also apply BCP-11.  Copies of claims of rights made available for
               publication and any assurances of licenses to
         WebDAV ACL.

    13 IANA CONSIDERATIONS 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.

          14 ACKNOWLEDGEMENTS

               This document uses protocol is the namespace defined collaborative product of the WebDAV ACL
               design team: xxx, yyy, zzz.  We would like to acknowledge the
               foundation laid for us by [RFC2518] the authors of the WebDAV and HTTP
               protocols upon which this protocol is layered, and the invaluable
               feedback from the WebDAV working group.

          15 INDEX

               To be supplied.

          16 REFERENCES

               [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
               1996, <http://www.ietf.org/rfc/rfc2026.txt>.
               [RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
               T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
               2068, U.C. Irvine, DEC, MIT/LCS, 1997,
               <http://www.ietf.org/rfc/rfc2068.txt >.
               [RFC2119] S.Bradner, "Key words for XML
         elements.  All other IANA considerations mentioned use in [RFC2518]
         also applicable RFCs to WebDAV ACL.

    14 INTELLECTUAL PROPERTY

         The following notice is copied Indicate
               Requirement Levels", Harvard, 1997,
               <http://www.ietf.org/rfc/rfc2119.txt >.
                [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
               "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
               U.C.Irvine, Netscape, Novell, 1999
               <http://www.ietf.org/rfc/rfc2518.txt>.

          17 AUTHORS' ADDRESSES

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

               Anne Hopkins
               Microsoft Corporation
               One Microsoft Way
               Redmond, WA
               Email: annehop@microsoft.com

               Eric Sedlar
               Oracle Corporation
               500 Oracle Parkway
               Redwood Shores, CA  94065
               Email: esedlar@us.oracle.com

          18 STILL TO DO :

               . Describe the interactions with resource locking.  I'm not
                 clear what the resolution was as far as locking the ACL
                 separately from RFC 2026, section 10.4, and
         describes locking the position of resource.

               . Add a section defining new error codes/messages?  Or should we
                 make a pass through the IETF concerning intellectual
         property claims made against this document.

    Sedlar, Clemm                                      [Page 13] 
         The IETF takes no position regarding doc and ensure all possible error
                 conditions are mapped to existing errors?

               . Articulate that the validity or scope of any
         intellectual required DAV:principal property or other rights that might should be claimed to
         pertain
                 able to the implementation or use other technology described
         in be used for equality checks.  Equality checks were
                 mentioned as one reason why this document or property should be mandatory,
                 even if the extent URI is fake.

               . Update "Setting Access Control Information" and to which any license under such
         rights might or might not address
                 whether read-only (ie, inherited) ACEs should be available; neither does it represent
         that it has made any effort stripped out
                 by the client prior to identify any such rights.
         Information PROPPATCH.  Fix, if necessary, comments
                 on editing inherited ACEs in ACL Inheritance section.

               . Renaming DAV:rights to DAV:effectiverights? and update sample

               . Revisit description of Property ACEs to reflect group
                 agreement.  Add sample code.  Anne will need to update
                 Semantics descriptions to address property ACEs.

               . Update the self, ownergroup stuff according to eventual
                 agreements.

               . Make document consistent:

                      o Ensure all property descriptions indicate whether the IETF's procedures with respect
                         property is:

                           . "live" or "dead"
                           . read-only or writable
                           . REQUIRED or OPTIONAL
                      o Ensure sample XML exists for all new properties, tags,
                         etc.
                      o Complete empty sections, like Scalability
          19 OPEN ISSUES:

               Issue          Description                   Status
               1. Aggregate   a right, if granted, that     Now addressed in
                rights        grants access to a set of     spec.
                              subsidiary rights
               2. Rights      How do we find out what       Now addressed in
         standards-track and standards-related documentation can be found
         in BCP-11.  Copies of claims of
                discovery     rights made available for
         publication and any assurances of licenses are applicable to a    spec.
                              given resource?  Can this be made available,
         or
                              done by resource type, to
                              avoid the result of an attempt made need to obtain ask each
                              resource this question?
               3. Defined     Should we define a general license or
         permission for the use of such proprietary rights by implementers
         or users 'group'    Collection
                list of       principal type which          principals will
                "principal-   specifically requires that    have semantic
                types"        principal membership be       meaning (recursive
                              recursive?  This might make   membership applies)
                              administrative client
                              implementation easier.
                              Should this specification can be obtained from a
                              recommendation rather than a
                              requirement?
               4. Reserved    Is the IETF
         Secretariat.

         The IETF invites any interested party to bring to its attention
         any copyrights, patents or patent applications, list of 'reserved'     Discussed in 4/28
                principals    principals complete (         conference call.
                              'owner', 'all', or other
         proprietary            Still Open.
                              'unauthenticated', 'all-
                              authenticated', etc.)
               5. Standard    Is the list of standard       Discussed on
                rights that may cover technology that may be required        rights complete?              conference call and
                                                            updated once in
                                                            draft.
               6. XML         Do we need to practice this standard.  Please address scope the information to       Use DAV namespace,
                namespace     namespace of our XML          like other working
                for ACL       elements via <?namespace      groups.  Closed.
                              href =
                              "http://www.ietf.org/standar
                              ds/acl/ AS = "A"?>, or can
                              we use the
         IETF Executive Director.

    15 ACKNOWLEDGEMENTS

         This protocol regular DAV
                              namespace (shared by both
                              versioning and RFC 2518)?
               7. Rights      What is the collaborative product of method for        Not a method.
                discovery     figuring out the WebDAV ACL
         design team: xxx, yyy, zzz.  We would like list of      DAV:Access-Rights
                              rights?                       property available.
                                                            Closed.
               8. Multiple    Are we sure we don't want to acknowledge  Requires an
                principals/A  allow multiple                explicit vote
                CE [CKNIGHT]  principals/ACE?
               9. Grant &     Are we sure we don't want to  Added to spec.
                Deny          allow grant & deny in the
         foundation laid     Decision reversed
                [CKNIGHT]     same ACE?  Note that this     per 6/23 call and
                              simplifies the ACE rule to    added to spec 01.3.
                              disallow two ACEs for us by the authors     Closed.
                              same principal.
               10.  Semantic  Do we need to specify stuff   Yes.  Added to
                meaning of the WebDAV and HTTP
         protocols upon which this protocol    like whether or not           spec.
                principal     collection principal
                colls.        membership is layered, recursive?
                [GCLEMM]
               11.  principa  The semantic meaning of       Added to spec=97
                l-name vs.    principal-name should be      principal-name
                display-name  defined, or display-name      holds
                [GCLEMM]      should be used                "authentication"
                                                            string and
                                                            displayname holds
                                                            readable string
               12.  ChangeOw  Can servers disallow          PROPPATCH support
                ner [GCLEMM/  changing the invaluable
         feedback from owner?           for owner is
                CKNIGHT]                                    optional in the WebDAV working group.

    16 INDEX
                                                            spec.
               13.  Local     What text is needed           Open
                principal     regarding principal URLs
                URLs          without hostname:port
               14.  ACL as    To what extent should ACLs    ACLs are
                properties    be supplied.

    17 REFERENCES

         [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
         1996, <http://www.ietf.org/rfc/rfc2026.txt>.

         [RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
         T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
         2068, U.C. Irvine, DEC, MIT/LCS, 1997,
         <http://www.ietf.org/rfc/rfc2068.txt >.

         [RFC2119] S.Bradner, "Key words treated as properties?     properties. Closed.
               15.  Semantic  Would it be more appropriate  Open
                s Model       to identify these semantic
                names         models by their
                [ANNEHOP]     implementation names, ie,
                              UNIX, NT Canonical?  Could
                              be easier for use in RFCs developers and
                              users.  Neither of these
                              models is likely to Indicate
         Requirement Levels", Harvard, 1997,
         <http://www.ietf.org/rfc/rfc2119.txt >.

          [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
         "HTTP Extensions be re-
                              used by another
                              implementation.
               16.  Addition  Do we need to include         Open
                al Semantics  additional ACL semantics
                models        models?  What other systems
                [ANNEHOP]     (.htaccess?) do we need to
                              support?
               17.  Detectin  How are WebDAV Access         Open
                g a WebDAV    Control compliant servers
                Access        detected?  Define acl
                Control       extension for Distributed Authoring - WEBDAV", Microsoft,
         U.C.Irvine, Netscape, Novell, 1999
         <http://www.ietf.org/rfc/rfc2518.txt>.

    Sedlar, Clemm                                      [Page 14] 
    18 AUTHORS' ADDRESSES

         Eric Sedlar
         Oracle Corporation
         500 Oracle Parkway
         Redwood Shores, CA  94065
         Email: esedlar@us.oracle.com

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

    19 STILL TO DO :

           @ Describe the interactions with resource locking.  I'm not
              clear what the resolution was as far DAV:
                server        header?
                [SEANLYND]
               18.  DAV:user  If we're going to be          Open
                /group or     treating users as locking resources,
                DAV:resource  then we should go all the
                /collection   way.
                [SEANLYND]
               19.  Per-      ability to specify rights on  Open
                property      a per-property basis could
                ACEs          be very useful for webdav.
                [ANNEHOP]     consider adding an optional
                              propertytype-id to the ace?
               20.  Register  Need to describe process for  Open
                ing           registering a new ACL
              separately from locking
                Semantics     semantics model option.
                Models
                [ANNEHOP]
               21.  Strip     Should the resource. client strip all   Agreed to strip
                Inherited     Inherited (read-only) ACEs    inherited ACEs in
                ACEs?         prior to setting an ACL?  Do  6/23 call.  Anne
                [ANNEHOP]     we need a flag that           re-opening issue.
                              indicates whether the server
                              accepts a client update of
                              inherited ACEs (to support
                              client-side propagation of
                              inheritance)?  And/or a flag
                              to indicate that the client
                              WANTs to set inherited ACEs?