Re: ACL Draft

Nice draft.  I expecially like the bit about dynamic vs static inheritance.
 I think this spec would certainly be sufficient for what I need to do.  I
look forward to seeing the next version.

A few comments

I realize (from your earlier email) that you  want this spec to treat
principal names as opaque.  Seems right, but you should add a sentence or
two that says that explicitly, otherwise people will think they are missing
something.  I certainly found myself wishing for the ability to name hosts,
for example.

It might be nice to have an "append" right as well.  This would allow
ADDREF or PUT but not DELETE or DELREF.

in the Introduction, you seem worried about side effects.  It's a little
unclear to me what you're worried about.  You write "by setting the ACL
property to a certain value the ACL on the resource gets set to the same
value".  This implies (to me) that the "ACL property" is somehow a separate
thing from the "ACL on the resource".   How are they different?  Is this
just a language thing, or is there a concept I am missing?  e.g. does
setting the WebDAV ACL property also sets the ACL on an underlying file
system?  

There's a systematic typo.  The verb "effect" is spelled "affect", except
when used as "cause to occur", e.g. "effect the changes".   So e.g.
"changes to the ACL source do not affect the new resource".  "effect" is
usually a noun, thus "there is no effect on the ACL".  The word "affect"
means "emotion" (more or less).  This happens in several places.

2.1.1 has a garbled sentence "is granted the right the resource".

2.1.2 would be clearer if it said "compound" before the first occurence of
"principal"

3 ACL inheritance says "when a new resource is created it may inherit its
ACL from its containing resource".  if it doesn't inherit, then where does
the ACL come from?  Is there a server wide default?  Surely it has to
inherit something, otherwise even the owner would not have the right to
make changes to the ACL.

5. Owner Property.  This property is Live, right?  Then it should say so.

7.1 All Right.  The description says this overrides all over rights.  But
does a more specific right over ride this, and if not is this a violation
of the rule that more specific should override more general?

7.3 So I can't tell the difference in any way between a resource being
write locked (LOCK) and being ACL locked for writing?  Is there an
interaction with lock discovery?  Should i be able to find out why I can't
write?

In fact, in general it's nice if I have the ability, when access is denied,
to find out why not.  For example, I might have show that I am authorized
by establishing additional authentication (e.g. showing my student ID)  but
maybe this is outside the scope.

In all your examples, you should be careful to always use the fully
qualified names of tags and not rely on XML namespace scoping.  I know you
know this, this is just a reminder.

In the bibliography you might want to cite the latest DAV spec not 01.  And
you should of course cite it as work in progress.

best regards.
Jim


------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301

Received on Monday, 20 October 1997 22:21:54 UTC