Juergen, that is a defect in RFC 4007, which left the character set undefined. We can't get that toothpaste back in the tube, but by using the ABNF construct ZoneID = 1*( unreserved / pct-encoded ) we can get round these cases; we can't fix them I'm afraid.
Regards Brian On 2012-05-04 15:10, Juergen Schoenwaelder wrote: > On Fri, May 04, 2012 at 09:54:36AM -0400, Simon Perreault wrote: >> On 2012-05-04 09:44, Juergen Schoenwaelder wrote: >>> On Fri, May 04, 2012 at 08:29:11AM -0500, Rajiv Asati (rajiva) wrote: >>>> +1 for option 3 with hyphen. >>>> >>>> I like to be able to read the URI without having to put my glasses on. >>> Interface names can contain other fancy characters and hence this one >>> will simply not work in the general case. >> The character just after the address is "special". We know it is >> special because it is just after the address. It can never be >> confused with the interface name itself. We could even choose >> something ridiculous, e.g. "x", as the special character and there >> would be no possibility of conflict. > > My understanding is that URI formats place restrictions on the set of > allowed unquoted characters. Some vendors (e.g. Juniper) use interface > names that even contain slashes, e.g. fe-0/0/0. While replacing the % > separating the zone identifier (typically an interface name) solves > one problem, it does not solve the problems with fancy characters in > the zone identifier. > > /js > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
