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
