On 2012-03-21 04:11, John C Klensin wrote:
>
> --On Tuesday, March 20, 2012 09:24 +0100 "t.petch"
> <daedu...@btconnect.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
>
>
