W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Bindings and permissions

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 30 Nov 2004 13:08:55 -0800
Message-Id: <0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org>
To: WebDAV (WebDAV WG) <w3c-dist-auth@w3.org>

I think I've discussed this before but it's come up again in a use case 
I'm working on.  In Chandler we want a user to be able to share the 
same item (for example, a calendar event) in multiple collections.  For 
example, I might want to show the "OSAF holiday party" in both my work 
calendar share and my home calendar share, so that other users who view 
either my work or my home calendar will see the event regardless (and 
users who share both won't see the event twice).

The natural way to do this if the server supports bindings would be to 
create the event in one collection, let's say the client will create it 
in my work share where permissions are inherited so that all OSAF 
people can view the event.  Then BIND the event to the other 
collection, where the inherited permissions normally would 
automatically make it so that my family and friends can view the event.

Do we leave it unspecified what happens in this case?  Do I end up with 
a resource that is bound into my home calendar but only work people can 
see it unless my client fixes up the ACLs?  Or do I end up with a 
resource that is bound into both and has the sum permissions of both?

If the client has to fix up the ACLs, now what happens when I add a 
person to the permissions of my home calendar share, and then apply 
that new permission to all the resources in my home calendar share?  
Does my client have to go through each one and ACL each one or can the 
server calculate the appropriate permissions for resources that are 
bound into both collections?

I can imagine a server implementing it either way depending on what 
they think the common use cases are; what can the client predict or 
require here?

Received on Tuesday, 30 November 2004 21:09:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC