[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Follow up on TC call
..couple more things.. > Who said you have to create "extension" functions that take function > as an argument? You don't have to do that to be conformant or > compliant with the specification. That's the quickest way to make XACML into yet another useless standard. Fact one - many implementation will extend funcitons used. Fact two - if they are not exactly the same model as standard functions interoperability will be severely complicated. I guess people never learn - there are thousand of dead languages out there, with all the cool and "solid" features. Those are used that are practical, and for which libraries are available. > Since it is outside of the specification, you can make it do anything > you want. Your customer will have to have your manual, not XACML, in her > hand to know what that function does, no matter what. I guess that was the argument for not standartizing C++ ABI.. Really helped in having a lot of interoperable libraries. >> This approach has an added flexibility that the operations can be >> specified in context as attribute values. >Just the thing that is doable, but is frightening because now you cannot >do assurance analysis on your policy when it looks up a function name as >an attribute value. That is because you may not know what the semantics >of the function named in the attribute, or even if it is supported by > your XACML processor. Wrong. If you define it as a data type with appropriate restrictions: for example "type:functions-that-take-two-integers-and-return-a-boolean" than this assurance is done by your type checking system - otherwise you need to "magically" know that the operation specified is apropriate. This approach is safer - and more flexible. > So what? If you are going to add extensions, publish your manual and its > specs, and use away. That's what I want - and i want other implementations to be able to do the same as I am convinced that this will happen.. But we just decided to give everybody a gun to be able to shoot future interoperability in the foot. Once extensions may be not the SAME as standard functions - they eventually will be non compatible. Daniel;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC