[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] URI-match function proposal
Anne Anderson wrote: > I think the primary problems in using reg-exp are that URL's > contain case-sensitive segments and case-insensitive segments. > HTTP or http or Http or ... will work. sun.com or Sun.COM or > SUN.com, etc. will work. "http://eastmail2bur.East.Sun.COM/" or > "http://129.148.13.40" will work. if you don't want to create regex so support that case (i would be interested in the use case for not knowing what the case insensitive portion of the resource would be at policy writing time ;o) we could extend the regexp-match function to contain two components [resourceContainer][resourceNodes] (for example) for hierarchies. > There is also the issue that there are optimized functions > available on some systems for this type of matching. People > don't want to be forced to use reg-exp. where? using what spec that we can reference? the problem is that we are forcing them to learn XACML expressions ('*' vs. '**' vs. '***' vs. whatever else we conjure up to solve discrete problems in an unbounded realm). > If it is easy to write a reg-exp for the URL-matching functions, > then it should be easy for you to implement the URL-matching > functions using that reg-exp pattern, if you choose. ...right after learning it...right after we attempt to generate a syntax that implements all cases. if some implementation wants to simplify the UI so that policy writers don't have to write regex that is great, but we shouldn't be generating that mapping in my opinion. b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]