On 2012-03-21 04:11, John C Klensin wrote:
--On Tuesday, March 20, 2012 09:24 +0100 "t.petch"
<daedulus(_at_)btconnect(_dot_)com> 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.
Just to clarify: the authors of draft-ietf-6man-uri-zoneid
are well aware of the fact that the draft has to be updated
because of that issue, and that discussion is ongoing in the
6man WG for now.
It is also very clear that this whole proposal is only of value
for low-level connectivity diagnosis and has no meaning outside
that context.
Brian
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