On Jul 8, 2008, at 5:45 AM, Erik Rissanen wrote:
> Open issues:
>
> - Could we live without the URI-variants since there is an URI to
> string conversion function in 3.0?
>
Since URIs are unique beasts I suggest the functions stay separate.
>
> - Would we like to overload the substring functions such that a
> negative index indicated the beginning/end of the string? This would
> expand the functionality of the proposed functions. But could it
> lead to more hard to detect errors in policies?
>
I should have read the whole email first, I just typed up this
suggestion :-P I think there is a lot of value in allowing the second
argument of substring/matching function to be negative. My experience
is that a lot more logic is is typically expended where the payload is
(end of string) vs. the domain/host side. Being able to grab chars
from the back allows one to forgo length functions, parse counts, etc.
and I think can actually improve the accuracy of culling out the chars
of interest.
> Another issue which has to be taken into account is that it looks to
> me that in general converting to upper case and testing for
> equality, vs, converting to lower case and testing for equality
> could yield different results. We would have to define either mode.
I assume you referring specifically to only string functions here?
Portions of URIs are case sensitive so I would think that the
application of global case functions would be highly undesirable for
matching purposes regardless of charset :)
b