<tim>
1. provide separate functions for matching URNs and URLs.</>
<anne>
Fine.</>
isn't the only difference the use of protocol reference "http://"? i can
go either way on this but can someone help me understand where this will
help?
<tim>
2. simply use our existing regex-match function to match URNs.</>
<anne>
Fine.</>
agreed.
<tim>
3. provide an ipV4Address match function. We will not provide a matching
function for ipV6 addresses.</>
<anne>
I am trying to support java.net.SocketPermission, where host can
be a hostname, an IPv4address, or an IPv6address, and is followed
by an optional portrange.</>
does this preclude us from having v4 and v6 datatypes? my fear is that
the complexity of v6 naming is a bit much for those still in the v4
world; it also seems like it would be practical to assume that a polcicy
writer developing ip/subnet based policies for which address type they
are protecting. personally i would prefer they be separate datatypes.
<anne>
Where do people use ranges now?</>
what is the subnet mask for 10.0.0.0.2 through 10.0.0.17? it is quite
common to have an address range that does not conform to a simple subnet
mask.
<tim>
5. simply use our existing regex-match function to match DNS names.</>
<anne>
Fine.</>
agreed.
<tim>
6. split URLs into three parts: a scheme part for which string-match will be
used; an authority part for which we will use either ipV4Address-match or
dnsName-match and a path part for which we will use the existing regex-match
function. IP addresses will be distinguishable from DNS names because they
begin with a number. Port number will be treated as part of the path and,
if it is missing, the default port number for the scheme will be
inserted.</>
<anne>
Fine.</>
i think the guys protecting http://525.com may have an issue with this
;o) perhaps to resolve all host names to ip addresses for url matching?
either that or use regex-match for the whole thing (yes, i am a broken
record!)
b
