OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on ACL PRoposal

HI all,


I couldn't find a JIRA entry for the ACL proposal so far (perhaps we should create one). So I use this list to create some comments on the current proposal that I suggest to discuss in the next ACL call. Base is the latest (0.7) spec in the Documents directory:


Issue 1 (Page 7):


We should rethink the notation of the levels. I understand the intention but using Level 1 for fine grained permissions and Level 2 for the coarse grained permissions caused confusions when discussing the implementation design with our dev teams.

Proposal: We should think about reverting the numbers or avoiding numbers at all.


Issue 2 (page 14):

"If no ACL is assigned to an object, all permissions are granted by default (unless overwritten by specific policies)"

Comment: To me in this case the repository should behave in its natural way and decide about the default set of permissions. I am not sure that his can be implemented by all repositories (what happens to inherited permissions that can't be overridden?).

Proposal: The default set of permissions granted in case that no ACL is provided is repository specific.


Issue 3:

I would like to discuss if the following use case is worth to be reflected in the specification:

A repository might be able to support both the basic permission set and the extended permission set to satisfy all kind of clients. In this case the call to GetRepositoryInfo() just returning a set of capabilities is not sufficient. In this case a client should be able to express his demand "Behave like a basic permissions repository" or "Behave like a generic permissions" repository. To my understanding this is currently not possible.


Issue 4 (page 17):

When applying ACEs should we make any statement whether it is allowed or forbidden for a client to mix permissions from the basic permission set with the permissions from the generic permission set in a set of ACEs for a call to ApplyACEs?  Personally I would favor an approach that a client either uses the basic permissions or the generic permissions in a single call but not both.


Maybe some of them become obsolete if we make clearer if the levels are mutually exclusive or if a higher level always includes the capabilities of a lower level.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]