First off, I have <i>not</i> been pushing for allowing UNASSIGNED on lookup in IDNA2008. This is for two reasons:<br><ol><li>We have had many Unicode versions since 3.2, so the urgency is not as prominent</li><li>Because IDNA2008 updates more regularly, there is less need.</li>
</ol><br>What I <i>have</i> been saying is that allowing UNASSIGNED on lookup wouldn't make a difference, and that's the case even if a character maps to ".".<br><br>Let's take a specific example: àbc<a href="http://xn--df-7ia.com">dèf.com</a>, where the middle character, \u0378, is currently unassigned as far as the client is concerned (because it is back-reved), while the registry is on Unicode 6.0. The XN form is <a href="http://xn--bcdf-zna5c481a.com">xn--bcdf-zna5c481a.com</a>.<br>
<br>Here's what happens when the client software (browser, emailer, etc) looks the domain name up, depending on what \u0378 turns into under 6.0. <ol><li> \u0378 becomes DISALLOWED. No problem. No conformant registry can support it, even on Unicode 6.0; the lookup is denied.<br>
</li><li>\u0378 becomes PVALID. No problem - the lookup works.<br></li><li>\u0378 becomes mapped to X (assuming we allow mapping on lookup)</li><ol><li>X is DISALLOWED, say "$". No problem. No conformant registry can support it, even on Unicode 6.0; the lookup is denied.</li>
<li>X is PVALID, say "X". The lookup fails. The remapped domain name would work as <a href="http://xn--bcxdf-qqa4d.com">xn--bcxdf-qqa4d.com</a>, but the original URL would not work until the client is updated, or unless the user learns to type X instead until s/he updates his/er client.<br>
</li><li>X is ".". The lookup fails. The remapped domain name would work as <a href="http://xn--bc-iia.xn--df-7ia.com">xn--bc-iia.xn--df-7ia.com</a>, but the original URL would not work until the client is updated, or unless the user learns to type X instead until s/he updates his/er client.</li>
</ol></ol>Whether the character maps to a dot or not in Unicode 6.0 doesn't make any difference in the scenario. It just fails the lookup in a different way (3.3 instead of 3.2), but the lookup fails in either case.<br>
<br clear="all">Mark<br><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 17:00, Erik van der Poel <span dir="ltr"><<a href="mailto:erikv@google.com">erikv@google.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;">
Hi again James, thank you for the email. I am quite aware of the dot<br>
issues in IDNA. I have first-hand experience with Japanese input<br>
methods and their modes, and I understand the motivation for the<br>
addition of non-ASCII dot processing in IDNA2003.<br>
<br>
The issue with U+2CFE COPTIC FULL STOP is a bit subtle, so let me<br>
explain. U+2CFE was added in Unicode 4.1. This means that, from the<br>
point of view of an IDNA2003 implementation, it is simply an<br>
unassigned character. Let's say we have a domain name like:<br>
<br>
aaa <U+2CFE> bbb . com<br>
<br>
Suppose that aaa and bbb are Coptic characters, and the typist<br>
happened to have a Coptic input method (though I have no idea whether<br>
such things exist!). Further, let's suppose that the client is using<br>
IDNA2003 with the flag "allow unassigned" set to true. If aaa and bbb<br>
are already lower-case, the client will do the right thing with them<br>
(leaving them as is). However, the client will not know that U+2CFE is<br>
a new dot-like character, so it will treat the entire sequence<br>
"aaa<U+2CFE>bbb" as a single label. It will then encode it in Punycode<br>
(including the dot-like character), and try to resolve that in DNS.<br>
<br>
Of course, this will not work because the intention was to resolve<br>
<a href="http://aaa.bbb.com" target="_blank">aaa.bbb.com</a>, not aaa<U+2CFE><a href="http://bbb.com" target="_blank">bbb.com</a>. In other words, a new client and<br>
an old client would resolve this name differently.<br>
<br>
I don't know how many IDNA2003 clients actually set the "allow<br>
unassigned" flag to true. It is obviously very dangerous, since the<br>
client cannot possibly know how to case-fold the new characters,<br>
including Coptic.<br>
<br>
(And this is also why Mark is wrong when he says that if clients are<br>
allowed to lookup XN-labels with unassigned characters, then they<br>
should also be allowed to lookup Unicode labels with unassigned<br>
characters.)<br>
<font color="#888888"><br>
Erik<br>
</font><div><div></div><div class="h5"><br>
On Sun, Mar 22, 2009 at 2:33 PM, James Seng <<a href="mailto:james@seng.sg">james@seng.sg</a>> wrote:<br>
> I think you misunderstood about the "dot" problem. It is not these<br>
> "dots" are allowed as domain name but they are identified as<br>
> "separator" like "."<br>
><br>
> The main reason is to because when a user switch to CJK inputs, when<br>
> he press ".", most IME will spur out U+3002 instead. If you do not<br>
> identify U+3002 as a separator, then a user will have to enter CJK<br>
> IME, switch back to English, enter a ".", switch back to CJK IME etc.<br>
><br>
> See <a href="http://tools.ietf.org/html/draft-jet-idnabis-cjk-localmapping-00" target="_blank">http://tools.ietf.org/html/draft-jet-idnabis-cjk-localmapping-00</a><br>
><br>
> -James Seng<br>
><br>
> On Mon, Mar 23, 2009 at 1:51 AM, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.com</a>> wrote:<br>
>> Another question from the summary:<br>
>><br>
>>> A. Multiple characters are allowed as "dots" in domain names under<br>
>>> IDNA2003 and presumably under IDNAV2. This is a general problem for<br>
>>> all versions of IDNA but may be exacerbated by the variants for "dots"<br>
>>> that are permitted under IDNA2003 and IDNAv2. What is the WG view?<br>
>><br>
>> In my view, non-ASCII dots should never have been allowed in IDNA2003.<br>
>> However, now that many IDNA2003 implementations have been distributed<br>
>> to users and a few stored domain names use these non-ASCII dots, some<br>
>> may feel that we have to support them (forever).<br>
>><br>
>> Having said that, I am quite concerned about adding yet another<br>
>> non-ASCII dot in IDNAv2 (U+2CFE COPTIC FULL STOP) because IDNA2003<br>
>> includes a flag that allows for the lookup of unassigned (in Unicode<br>
>> 3.2) characters. Such applications would not only fail to case-fold<br>
>> post-Unicode-3.2 characters correctly, they would fail to divide the<br>
>> full domain name into individual labels, and since DNS labels are<br>
>> "owned" by different owners, this just seems like an invitation to<br>
>> further problems.<br>
>><br>
>> In my view, the dot is a keyboard and UI issue. Of course, it would be<br>
>> nice if we could push ALL mappings out to the keyboard and UI, but, to<br>
>> use one of John's favorite words, this may be "unrealistic". ;-)<br>
>><br>
>> Erik<br>
>> _______________________________________________<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>
>><br>
><br>
_______________________________________________<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>