--On Tuesday, March 20, 2012 09:24 +0100 "t.petch" <daedulus@xxxxxxxxxxxxx> wrote: > There is currently a thread in 6man on > > Subject: Re: 6MAN WG Last Call: > draft-ietf-6man-uri-zoneid-00.txt > http://www.ietf.org/mail-archive/web/ipv6/current/msg15505.html > > on how to put this zoneid into a URI which, given that zone > ids start with a % and that RFC3986 gives that character > special, syntactical significance, would appear to verge on > the impossible. As and when IPv6 gets rolled out, I suspect > that this topic will bite, or haunt, an ever growing number of > people - which makes it worth some consideration now. Tom, FWIW, zoneids are nothing special in that regard. While it has been used less in recent years than a decade or two ago, "%" has had a special meaning in some email addresses for a long time, requiring either special treatment in MAILTO or that users know how to escape the character and that applications follow the decoding rules exactly and in the correct order. Tricky interpretation of "+" in HTML has also made it difficult to use that character in email addresses in many web-like contexts and, for it, incorrect interpretations of the decoding rules in applications has contributed to making escaping the character into %2B an insufficient workaround. While RFC 3986 makes the rules perfectly clear, we've seen applications get the coding and decoding wrong. Expecting end users to understand the rules about when escaping is required and to apply them correctly is, at least IMO, pretty hopeless. Having IRIs as an overlay on URIs that can, unbeknown to the user, create even more %-encodings, increases the risks and complications. We will almost certainly see applications that, in the hope of a better user experience (and regardless of what we tell them in standards) try to decode URIs that contain % characters into IRIs and getting that wrong. I think it is all a nightmare waiting to happen. You may or may not agree. Certainly those who are working on IRIs and URIs either don't see the risks or see them as acceptable. Either way, there is nothing particularly special about IPv6 zone identifiers in that regard. If nothing, interactions between those zone identifiers and presentation of IPv6 addresses to users (in URIs or otherwise) ought to reinforce a conclusion the IETF reached years ago but we seem to keep forgetting. That conclusion was that protocols and methods that expose IP addresses (whether IPv4 or IPv6) to users are generally a bad idea. If we believe it, we should be designing in ways that hide or abstract that information, whether into the DNS, into better location-identifier separation, or otherwise. That principle doesn't help with special syntax in email addresses or with the URI<->IRI<->user interactions, but might call for some careful thinking about zone identifiers and/or IPv6 addresses and URIs. The context in which many of us take the opportunity to pledge to the universal deployment of IPv6 is not intended to numb the pain of self-inflicted bullets to our feet. john