>>> 1) Leave the problem unsolved. >>> >>> This would mean that per-interface diagnostics would still have to be >>> performed using ping or ping6 >>> >>> ping fe80::a%en1 >>> >>> Advantage: works today. >>> >>> Disadvantage: less convenient than using a browswer. >>> >>> 2) Escaping the escape character as allowed by RFC 3986: >>> >>> http://[fe80::a%25en1] >>> >>> Advantage: allows use of browser. >>> Disadvantage: ugly and confusing, doesn't allow simple cut and paste. >> >> if we went with option 2; considering that most browsers accept other inputs >> than URIs, >> could the UI input be as today (fe80::a%en1) and the URI representation as >> (fe80::a%25en1)? > > As far as I can tell, current browsers have dropped this, even if > Kerry still uses it in an ancient Firefox. IMHO this is not a viable > option for the browser folk.
perhaps I'm missing something, but this is what on the bleeding edge Chrome does too. >> presumably also with other characters in the interface name escaped. >> e.g. if I input "interface Dot11Radio0/0/0" in Chrome's address bar I get >> "interface+Dot11Radio0%2F0%2F0" > > There seems to be no way out of that whatever we do. if the string has to be escaped regardless, and that UI's may handle this for the end user, what would be the reason to not go with an escaped '%' (%25)? cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
