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] 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]