RE: ACL Draft

Opaque Principals - I will add language making it clear that principals
are opaque to the protocol and potentially opaque to the client.

Append Right - Hum... I would like to restrict the rights listed in the
draft to those that are considered absolutely essential. The problem is,
how do we define what "essential" means? My intention is to make the
rights listed in the spec required. Without a minimal subset of required
rights, interoperability becomes a joke. So, is append an essential
required right or is it something that would make a good parallel spec?

Side Effects - Currently, setting the ACL property sets the ACL. As I
have previously discussed, this will be changed to an ACL method.

effect vs affect - Sigh, you and Jim have been talking haven't you? =) I
am unfortunately known for this screw up. I will fix it.

2.1.1, 2.1.2, 5, bibliography reference - Added to the to-do list, will
be fixed in the next version of the draft.

3 - The other choice is no inheritance at all. The ACL and the owner
property are completely independent of each other. So a resource can
have an owner but no ACL. In that case all rights are denied to
everyone. However, the definition of the owner property is that the
owner ALWAYS has the right to set the ACL, regardless of the current ACL
settings. I will clarify this issue in the spec.

7.3 - Locking and ACLs have totally independent discovery mechanisms.
They also have independent errors. So there should be no confusion. I
will however put in some language on this topic. I will also clarify
that the behavior I am talking about is what methods are affected by a
write lock and nothing more.

	As always, thanks for the comments,

			Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Monday, October 20, 1997 7:19 PM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	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 Tuesday, 21 October 1997 16:49:34 UTC