On Sun, Apr 29, 2012 at 08:54:16AM +0100, Brian E Carpenter 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. 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. > > 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. > > 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. > > 3) With alternative separator such as _ > > http://[fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: doesn't allow simple cut and paste. > > 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. > > Thus, the WG has to choose between options 1), 2), 3) and 4).
If we want to solve this at all, I think 2) is the way to go since this format is after all easier to understand than format 3) or 4), which add yet another notation, and also because there might be other characters in the zone ID that need escaping as well. And since URLs are used not just by plain good old http and web browsers, I think we will have to find and document a common solution for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
