Patrik, you misunderstand. I'm not saying that this should be part of the protocol. What I'm saying is that the protocol, <i>combined with a postprocessing step for UIs, </i>would handle the situation.<br><br>(In retrospect -- and water long under the bridge -- we would have been better off to use one of the variants of Punycode, which has the ability to encode case and other distinguishing information in the original Unicode using case in the ASCII form. Had we gone that route, we could have maintained the visual distinctions on output of DNS for sigma and similar cases, because the DNS does a caseless compare for A-Z.)<br>
<br>Mark<br><br><div class="gmail_quote">On Sat, Mar 29, 2008 at 2:00 AM, Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>> 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"><br>
On 28 mar 2008, at 18.52, Mark Davis wrote:<br>
<br>
> That would show<br>
> <a href="http://%CF%83%CF%89%CF%84%CE%AE%CF%81%CE%B7%CF%82.com.cy" target="_blank">σωτήρης.com.cy</a> properly, and maintain compatibility.<br>
<br>
</div>This is not about how to "show" things, as DNS is nothing else than a<br>
storage / lookup mechanism.<br>
<br>
You store a key, and together with that key some data. You can _NOT_<br>
send in the data and get the key back.<br>
<br>
The way IDNA2003 is designed is that the key does _NOT_ allow final<br>
sigma, and this because of design of Unicode. Regardless of if "the<br>
user typed" sigma or final sigma, the same key should match. Without<br>
changing the matching algorithm (that is out), the key have to be<br>
calculated on the client side. This key that is sent in is sigma,<br>
never final sigma.<br>
<br>
There is _no_ "reverse" mapping in DNS. Just lookup.<br>
<br>
That said, one can do a lookup of a PTR record where the data is a<br>
domain name. This domain name because of same rules as for the key can<br>
not include the sigma, but the final sigma. And if that is the problem<br>
people try to resolve, then that is what should be discussed, but that<br>
has not much to do with the creation of the key used in the lookup.<br>
<font color="#888888"><br>
Patrik<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mark