[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. thinking about this a bit more, what happens for those HRs that are case sensitive throughout? try this on a unix machine: $ browser file:///etc/hosts $ browser file:///eTc/hosts i don't think all URLs are case insensitive, it depends upon the protocol. so, is this handled by a text description in a profile somewhere? does this then mean that the policy writer must 'learn' that 'file:///Sun/East' is ok (for windows resources), but it must be 'file:///sun/east' on unix? again, i fear that the sum of exceptions (and ad hoc repairs) will exceed the base learning curve of regex and that this should be hidden by whatever UI the implementation chooses to provide (but not the policy exchange format because of the possibility of ambiguity.) i am not trying to push regex specifically, but it seems to be the closest thing to a standard we can refer at the moment for handling this. therefore i believe it provides the highest probability of unambiguous (deterministic) results from a given input. b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]