I agree that it would be nice, and it would be equally nice to lookup any Unicode-Label*. That is, if there is any reason to be suspicious of a Unicode label, then we should be equally suspicious of the corresponding XN-Label. If XN-Labels are presumed to be safe, then we have no reason to mistrust the corresponding Unicode label.<br>
<br>It may very well be that there there is a particular set of cooperating systems, with a gatekeeper, and that anything in XN-Label form has been validated as being an A-Label. And in that case, it clearly doesn't make any sense to validate over and over again. But you'd better validate on input to that set of systems, otherwise you have no guarantee that it is in fact an A-Label. <br>
<br>Similarly, you could have a particular set of cooperating
systems, with a gatekeeper, and that anything in Unicode-Label form has been
validated as being a U-Label. And in that case, it clearly doesn't
make any sense to validate over and over again. But you'd better
validate on input to that set of systems, otherwise you have no
guarantee that it is in fact an U-Label. <br>
<br>Mark<br>
<br><br><div class="gmail_quote">On Mon, Mar 23, 2009 at 10:09, 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 Mark,<br>
<br>
I was referring to your comment:<br>
<br>
"if it is important to check those requirements, then it is important<br>
to test both A and U Labels; if it is not important to test them, then<br>
it should not be a requirement for either one."<br>
<br>
All I'm saying is that it would be nice if a client could lookup any<br>
label that starts with "xn--". This would allow e.g. Google Search to<br>
convert legal U-labels to legal A-labels, and it would allow the<br>
browser to follow the links, even if the browser implemented an old<br>
version of IDNA.<br>
<br>
It would then be up to the browser to display the underlying Unicode<br>
string in a safe way. Note that browsers are already expected to apply<br>
certain restrictions when displaying the domain name.<br>
<br>
I do agree with your point that, now that we are at Unicode 5.1,<br>
future additions to Unicode are not quite as impactful to the DNS.<br>
We're in the "long tail".<br>
<br>
Erik<br>
<br>
On Mon, Mar 23, 2009 at 9:38 AM, Mark Davis <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
> First off, I have not been pushing for allowing UNASSIGNED on lookup in<br>
> IDNA2008. This is for two reasons:<br>
><br>
> We have had many Unicode versions since 3.2, so the urgency is not as<br>
> prominent<br>
> Because IDNA2008 updates more regularly, there is less need.<br>
><br>
> What I have been saying is that allowing UNASSIGNED on lookup wouldn't make<br>
> 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" target="_blank">dèf.com</a>, where the middle character,<br>
> \u0378, is currently unassigned as far as the client is concerned (because<br>
> it is back-reved), while the registry is on Unicode 6.0. The XN form is<br>
> <a href="http://xn--bcdf-zna5c481a.com" target="_blank">xn--bcdf-zna5c481a.com</a>.<br>
><br>
> Here's what happens when the client software (browser, emailer, etc) looks<br>
> the domain name up, depending on what \u0378 turns into under 6.0.<br>
><br>
> \u0378 becomes DISALLOWED. No problem. No conformant registry can support<br>
> it, even on Unicode 6.0; the lookup is denied.<br>
> \u0378 becomes PVALID. No problem - the lookup works.<br>
> \u0378 becomes mapped to X (assuming we allow mapping on lookup)<br>
><br>
> X is DISALLOWED, say "$". No problem. No conformant registry can support<br>
> it, even on Unicode 6.0; the lookup is denied.<br>
> X is PVALID, say "X". The lookup fails. The remapped domain name would work<br>
> as <a href="http://xn--bcxdf-qqa4d.com" target="_blank">xn--bcxdf-qqa4d.com</a>, but the original URL would not work until the client<br>
> is updated, or unless the user learns to type X instead until s/he updates<br>
> his/er client.<br>
> X is ".". The lookup fails. The remapped domain name would work as<br>
> <a href="http://xn--bc-iia.xn--df-7ia.com" target="_blank">xn--bc-iia.xn--df-7ia.com</a>, but the original URL would not work until the<br>
> client is updated, or unless the user learns to type X instead until s/he<br>
> updates his/er client.<br>
><br>
> Whether the character maps to a dot or not in Unicode 6.0 doesn't make any<br>
> difference in the scenario. It just fails the lookup in a different way (3.3<br>
> instead of 3.2), but the lookup fails in either case.<br>
><br>
> Mark<br>
><br>
> On Sun, Mar 22, 2009 at 17:00, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.com</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> Erik<br>
>><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>><br>
>> > 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>
><br>
><br>
</blockquote></div><br>