Spec's been updated and posted.  Sean made changes to support ACL as a
property and fixed rights discovery.  I added support for inheritance.
other misc questions below:

1. Inheritance Flags are optional.  Systems that don't support
inheritance don't need to support this property.  But, for systems that
do support inheritance, should we make the <dav:inheritanceflags>
mandatory, even if it contains no flags (which is a legal state), or
should we state that it only needs to be returned if there are flags
present?  Also, since the meaning of "no <dav:inheritanceflags>" is the
same as "<dav:inheritanceflags> present but empty", should we allow
both, or is it easier on implementors to specify a single legal
semantic?

3. NT ACLs support per-property ACEs, where the ACE contains a
property-type identifier, in addition to the normal stuff.
property-type ACEs contain rights that only affect access to a certain
property or property-set on the resource.  It seems this could be highly
useful for webdav.  Should we incorporate it into the core spec?

4. My inheritance section doesn't mention anything about default ACLs.
Not sure our spec needs to cover this.  We assume that it's
system-dependent how an initial ACL gets created when a resource is
created.  Do we need to say anything more?

5. Regarding whether the client should strip out inherited ACEs prior to
updating the ACL, after more thought and internal discussion, it seemed
that this could be an obstacle to certain system-specific optimizations.
For example, consider a system that prefers the client to perform
propagation of ACL inheritance (ie, when the user writes an update to an
acl, an intelligent client calculates the inheritance and updates the
ACLs of all children in the subtree.  a system might prefer this to
server-side churn.)  It's also kind of friendly to let a client read an
ACL, tweak a little something, then write the ACL.  Furthermore, for
systems that allow  In any case, it seems like we'd be safe in saying
that the client shouldn't ordinarily add or change ACEs with the
<dav:inherited> flag, but should include any read inherited ACEs in the
ACL that gets written.  It is a server-implementation detail whether the
inherited ACEs get stripped out or checked for validity or whatever upon
an ACL proppatch.

6. I defined <dav:aclsemantics> as an element containing exactly one tag
to indicate which acl semantic model applies to this ACL.  This is a
little redundant; should it be replaced with just a list of elements, of
which exactly one must be present?

7. There are a bunch of per-ACL flags, etc. (like aclsemantics,
protectfrominheritance).  should these be subelements of the ACL itself?
How about owner and rights.  is it "neater" to contain all of this
access control information inside the acl property?