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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: RE: [xacml] REST Profile wd04


What happens when App A uses one versioning scheme when posting revisions to a repository, and App B uses a different versioning scheme when posting revisions to the same repository?   One app's post could violate the other app's semantics.

-Danny

Danny Thorpe 
Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com 


-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of remon.sinnema@emc.com
Sent: Wednesday, May 23, 2012 1:48 AM
To: cforster@us.ibm.com
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] REST Profile wd04

Craig,


From: Craig R Forster [mailto:cforster@us.ibm.com] 
Sent: Tuesday, May 22, 2012 9:32 PM
To: Danny Thorpe
Cc: Sinnema, Remon; xacml@lists.oasis-open.org
Subject: Re: [xacml] REST Profile wd04

> Shouldn't the server control the version?

I don't see how a server could know whether an update indicates a minor or major change. So unless you have a very simplistic versioning scheme, where you just increment a single digit, the server can't implement it. The client, on the other hand, is in a much better position, since it most likely has knowledge of what events led to the creation of a new version of the policy. So it could, for example, implement semantic versioning [1].

So there are basically two approaches that we can take:
(1) let the client specify the version
(2) let the client indicate to the server what kind of change is made

Approach #2 is what you see in source code control systems like SVN, where there are different commands for incrementing the minor and major version (commit vs. branch).

I like #1 better, because
(1) it's simpler, which keeps the costs for implementation low
(2) it allows the client to chose any versioning scheme it wants, instead of having the server dictate one
(3) it allows the server to validate the given policy as-is against the policy schema

#2 is especially important for the Authorization-as-a-Service use case, where different tenants may want to use different versioning schemes, while using the same server (farm).


Thanks,
Ray


[1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf



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