There is only one case where locale-sensitive lowercasing is needed, and that is for Turkish (and related languages using the same conventions in Latin). There are some possible issues with uppercasing (typically in whether accents are retained, although there are clear differences of opinion on this topic, such as in French), but those are not relevant to IDNA since only the lowercasing is at issue.
<br><br>I am very concerned about the breakage that will occur if the folding operations are entirely freeform. See the mail discussion under "<span id="1fkq" class="VrHWId"><span class="nfakPe">IDNAbis</span> compatibility":
<br><br></span><div style="margin-left: 40px;"><a href="http://www.alvestrand.no/pipermail/idna-update/2007-March/000537.html">http://www.alvestrand.no/pipermail/idna-update/2007-March/000537.html</a><br><a href="http://www.alvestrand.no/pipermail/idna-update/2007-April/thread.html">
http://www.alvestrand.no/pipermail/idna-update/2007-April/thread.html</a><br></div><br><font size="2">I'll copy one portion. As of last March, "Out of a significantly large sampling of the web, there were
about 800,000 cases where an HTML document contained an href="..." that
contained a host name that was valid IDNA2003. We tested those host
names to see if they would also be valid under <span class="nfakPe">IDNAbis</span> (based on the current working proposals). About 85% were valid, about 8% more would be valid if <span class="nfakPe">IDNAbis</span> were changed to also do
<span class="nfakPe">case</span> and width <span class="nfakPe">folding</span>, and about 6% would still be invalid even if <span class="nfakPe">case</span>
and width foldings were applied. (The width foldings are applying NFKC
to just the half-width and full-width characters to get the normal
"<br><br>IDNAbis is already excluding thousands of characters that used to be valid. There is, however, rough consensus that symbol characters, punctuation, and others were ok to exclude, and their numbers are relatively small.
<br><br>But the folding case is different. </font><font size="2">The case/NFKC folding of IDNA is not just a UI issue; there are a huge number in email, web pages, and so on. </font><font size="2"> I'm very leary of causing 8% of embedded URLs to break. And we haven't seen any real evidence that case/width folding is a real, demonstrable problem.
<br></font><br>Now, one possibility is that we have a separate IDNA-Folding document that preserves the case/width folding of IDNA2003. Then other standards, protocols, and implementations (such as browsers) could also claim conformance to that. This wouldn't be as good as keeping it inside the IDNA umbrella, but would be better than a potential huge backwards compatibility breakage.
<br><font size="2"><br></font><font size="2">> </font>(given the requests I have got for example) <br>
<br>Patrik, can you be more specific about this? Numbers and examples to justify this would be useful.<br><br>Mark<br>
<br><div class="gmail_quote">On Nov 27, 2007 2:28 AM, Patrik Fältström <<a href="mailto:firstname.lastname@example.org">email@example.com</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 27 nov 2007, at 08.13, Martin Duerst wrote:<br><br>> With the current IDNA architecture, mapping happened at<br>> a single place in the protocol stack. Any idna library<br>> would do it, or it wouldn't want to call itself an idna
<br>> library. That leads to a consistent and predictable behavior<br>> from a user viewpoint.<br><br></div>The major argument for me to NOT include mapping in IDNAbis is that<br>IDNA(bis) is context free, while mappings that people want to have
<br>(given the requests I have got for example) require context dependent<br>mapping. For example based on what locale is in use.<br><br>That one might need well defined mapping mechanisms is of course<br>clear, but it can not be resolved as part of the context-free domain
<br>name layer in the chain of functions between user and wire.<br><font color="#888888"><br> Patrik<br></font><div><div></div><div class="Wj3C7c"><br>_______________________________________________<br>Idna-update mailing list
<br><a href="mailto:Idnafirstname.lastname@example.org">Idnaemail@example.com</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><br clear="all"><br>-- <br>Mark