I'm not exactly seeing overwhelming consensus, but the loudest virtual hum was for
http://[fe80::a-en1] Advantage: allows use of browser. Disadvantage: doesn't allow simple cut and paste. There was a suggestion to encourage a fix to ping (and traceroute?) to allow the "-" separator, and we must note that in any case, strange characters in the interface ID will always have to be %-encoded. Regards Brian On 2012-04-29 08:54, 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). > > Opinions welcome! > > Brian Carpenter > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
