Subject: BIND and access control lists

From: Joe Hildebrand <[email-masked]>
Date: Thu, 3 Feb 2005 00:07:52 -0700

Trying to predict what the IESG might latch on to during their last 
call.

I understand that DAV:acl is a property, which applies to the resource, 
not the URL.  The suggestion has been made that MOVE has the same 
issue, but 3744 gives explicit requirements for MOVE and COPY, which 
differ slightly.  I don't know the history of 3744, but I assume that 
there needed to be text for section 7.3 and 7.4 since it wasn't obvious 
what would happen to acl's in the face of those operations.

I could imagine an IESG member who knew about the entire suite of 
protocols asking for the draft that added a new operation specifying 
how that operation fits into that suite.  I would expect that a line 
saying "BIND is the same as MOVE with respect to acl's", "BIND is the 
same as COPY with respect to acl's", or a paragraph on the same lines 
as 7.3 or 7.4 from 3744 would be enough to answer that question.

-- 
Joe Hildebrand

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 3 Feb 2005 08:18:15 -0500

The statement that would be consistent with 3744 would be
"BIND is the same as MOVE with respect to the DAV:acl property". 
(I prefer to state it that way, rather than copying the
paragraphs from 3744, since that allows us to modify
DAV:acl behavior in 3744bis without having to revise the
binding specification).

If nobody objects to that behavior, then I am happy to add
that sentence to the BIND specification.

If anyone objects to that behavior, then that is an issue
against 3744, and then I believe the BIND specification
should remain silent on the topic, and the issue should be raised
against 3744 for resolution.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Feb 2005 18:25:02 +0100

> "BIND is the same as MOVE with respect to the DAV:acl property".  

...same for REBIND...

> DAV:acl behavior in 3744bis without having to revise the

+1

> that sentence to the BIND specification.

So where should that statement go (or these statements when we include 
UNBIND)? Should we insert a new top-level paragraph stating the behaviour?

> against 3744 for resolution.

+1

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Feb 2005 11:20:07 -0800

> UNBIND)? Should we insert a new top-level paragraph stating the 
Wherever you think best!  I think location and organization largely go 
under authors' discretion.

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Feb 2005 11:36:35 -0800

This is fine with me for BIND, and I think the same is also true of 
REBIND and UNBIND.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Feb 2005 23:57:37 +0100

> This is fine with me for BIND, and I think the same is also true of 

How is UNBIND relevant here?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Feb 2005 16:08:41 -0800

Let's say the user creates resource 'myresume.doc' and puts it into a 
collection 'http://example.org/~lisa/public/'.  Further, let's say that 
the public nature of this collection involves inherited permissions 
which make the new document publicly readable.

In step 2, the user does a BIND to also bind  'myresume.doc' into 
'http://example.org/~lisa/career/'.  This new location is a private 
folder, but let's assume that 'myresume.doc' remains publicly readable 
because of its membership in the public folder.  (This is where the 
BIND language would come in but this behavior seems consistent with 
that.)

In step 3, when the user does UNBIND and removes the binding into the 
public collection, does the document remain public?  That's the 
question for which I'm looking for additional specification 
requirements.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2005 21:23:53 +0100

> against 3744 for resolution.

OK,

issue tracked at: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.9_ns_op_and_acl>

Potential resolution: new paragraph:

9.  Relationship to WebDAV Access Control Protocol

    BIND and REBIND behave the same as MOVE with respect to the DAV:acl
    property (see [RFC3744], section 7.3).

Feedback appreciated,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2005 21:27:28 +0100

Lisa Dusseault wrote:
> because of its membership in the public folder.  (This is where the BIND 
> language would come in but this behavior seems consistent with that.)
> 
> public collection, does the document remain public?  That's the question 
> for which I'm looking for additional specification requirements.

I guess all we can say is that we don't know, just like for MOVE, BIND 
and REBIND.

But if this is the case for UNBIND, it also applies to DELETE. So should 
we state that?

Best regards, Julian