Logically speaking, there is no difference between a UTF-8 model and a Punycode model. Both can be thought of as transfer-encodings of Unicode. Punycode is arcane, but it is simply and fully a lossless encoding of Unicode.<br>
<br>The problems we are dealing with are not because of that, but because of the fact that we are mapping and restricting on the client side. That is, the encoding is orthogonal to the mapping/restricting. If we had UTF-8 in URLs we would be faced with the same issue: how do we we map/restrict labels, and where is it done. For example, the Greeks really want *more* mapping than is done by IDNA2003, not less.<br>
<br>The one difference, which is orthogonal to the encoding issue, is that the core DNS server-side lookup could require mapping/restricting, instead of burdening the clients and/or registries with it. But the mapping/restricting issues don't magically disappear... And it is unclear that every DNS server should be required to implement all of the mapping/restricting rules. And we still wouldn't want that to differ by language (for reasons outlined earlier).<br>
<br>Don't get me wrong; it would be great to have UTF-8 in the DNS at some point. It would make a number of things easier. But it would have no affect on the issues that are causing so many disagreements (and/or head-scratching).<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Fri, Feb 27, 2009 at 12:29, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Feb 27, 2009 at 01:17:47PM -0500, John C Klensin wrote:<br>
<br>
> Yes. And what you didn't call out,<br>
<br>
</div>[…]<br>
<br>
Oh, sure -- I can think of _lots_ of ways this is complicated by the<br>
actual way the world is. What you said, what Jaap said, the problem<br>
of getting all the right metadata in the first round (does anyone<br>
really think that once we open the "metadata for domain names" can,<br>
the only worm that will pop out is IDNs?) -- it's just a bad idea if<br>
we want to solve this problem quickly.<br>
<div class="Ih2E3d"><br>
> Conversely, if one can contemplate that radical a chance to the<br>
> DNS, then it is plausible to rethink the entire IDNA model and<br>
> start thinking about a transition to a UTF-8-native model<br>
<br>
</div>Right. I seem to recall asking some time ago whether that's what we<br>
need to start contemplating. It sounded to me like the answer was,<br>
"No." But if we're not willing to bite off that much, then we need to<br>
accept that we have to live with a bunch of limitations that are<br>
inherent in DNS.<br>
<div class="Ih2E3d"><br>
> Anyone who is willing to accept the 10 year (minimum) that<br>
> transition would take before we had stable IDNs should certainly<br>
> advocate just such a solution.<br>
<br>
</div>I agree completely.<br>
<br>
A<br>
--<br>
<div class="Ih2E3d">Andrew Sullivan<br>
<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a><br>
</div>Shinkuro, Inc.<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>