Kerry, On 2012-04-29 23:50, Kerry Lynn wrote: > On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter < > [email protected]> wrote: > >> Hi, >> >> In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00, >> there was no clear consensus on the approach to pursue. In fact, >> almost the same discussion occurred around draft-fenner-literal-zone >> several years ago, but at that time the topic was simply dropped. >> >> This note summarises the main options. As a reminder, the problem to >> be solved is how to tell a browser which interface to use when sending >> packets to a literal link-local address. The reason for doing this is >> purely for diagnostic purposes, since the Zone ID that identifies an >> interface has no significance outside the sending host. > > > "Purely" may be overly strong here. When I mentioned in Paris that > my mom might like to configure her spanking new IPv6 homenet router > using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1, > it was met with much ROTFL'ing. But hey, my mom is no slouch. > > In a more immediate case, people are currently using browsers to connect > to embedded 6LoWPAN web servers. (Imagine a host with a 6LoWPAN > link on one interface and ethernet on another.) I use Firefox 3.2x for > this, > because it supports the syntax above just fine. > > Are such cases included in the "diagnostic" designation? It seems not.
Fair enough, this can easily be wordsmithed. > > For more details, >> see the two drafts mentioned above. >> >> What we have today: link local address with no Zone ID >> http://[fe80::a] >> >> The user cannot select the outgoing interface if there is more than one. >> >> The obvious solution would be to use the RFC4007 syntax (for an >> example Zone ID of en1): >> >> http://[fe80::a%en1] >> >> However, this is impossible because % is *always* an escape character in >> URI syntax [RFC3986]. There is no chance of the URI community accepting >> such a hack to the syntax, so it isn't an option for us. >> >> Well, this may be a case of "do what we mean, not what we say". I agree > that "%" is the first octet of pct-encoded, but it's not clear that > pct-encoded > is permissible in all productions. To wit, ( unreserved / sub-delims / ":" > ) and > ( unreserved / pct-encoded / sub-delims / ":" ) are apparently not > equivalent. > The basis of some comments in Paris was that escaped chars are currently > not permitted within IP-literal. But I agree, in the end this may be an un- > winnable battle. Exactly. I don't claim to understand every nook and cranny of the syntax, but in practice it's unwinnable. > >> The available options are therefore >> >> 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. >> >> And doesn't allow browsing; see above. So I don't like this option. Yes, I overlooked that rather obvious disadvantage... > > >> 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. >> >> Well, if we took a purely *user-centric* approach, then we'd use a > consistent syntax for all utilities. We have an existence proof (Firefox > 3.2x) that demonstrates the desired syntax is possible (and parsible). > This option is just ugly. If we have to map symbols, I'd rather use a > 1:1 mapping than a 1:3 mapping. If only we hadn't picked % in the first place... > > 3) With alternative separator such as _ >> http://[fe80::a_en1] >> >> Advantage: allows use of browser. >> Disadvantage: doesn't allow simple cut and paste. >> >> This is the simplest of the four alternatives. It seems at this point we > could just discuss whether "_" is the best alternative. > > >> 4) With the "IPvFuture" syntax left open in RFC 3986: >> >> http://[v6.fe80::a_en1] >> >> Advantage: allows use of browser. >> Disadvantage: ugly and redundant, doesn't allow simple cut and paste. >> >> Yikes! This one just screams OVERSIGHT. I would frankly prefer > option 1 over having two ways to represent IPv6address. > > Thanks, Brian and Bob, for taking this on. No problem. Brian > > -K- > > >> Thus, the WG has to choose between options 1), 2), 3) and 4). >> >> Opinions welcome! >> >> Brian Carpenter >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
