I agree.<br><br><div class="gmail_quote">On Thu, May 8, 2008 at 4:01 PM, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.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;">
An unassigned codepoint may be assigned to an uppercase letter. So a<br>
piece of software that looks up purported U-labels must check whether<br>
it contains any unassigned codepoints. So we should recommend that<br>
such software be restricted (follow certain rules), in order to<br>
achieve interoperability. (MSIE7 refuses to look up domain names<br>
containing unassigned characters.)<br>
<br>
If we lock down the DISALLOWED set too tightly, we may regret it<br>
later. One way to avoid locking it down is to recommend that<br>
burned-in-ROM and other unupgradable software only use protocols that<br>
use LDH- and A-labels. All pieces of software, whether IDNA-aware or<br>
not, are explicitly permitted to look up Punycode labels, without<br>
decoding them to check for DISALLOWED, CONTEXT*, etc.<br>
<br>
On the other hand, we should recommend that protocol and application<br>
developers only use U-labels if they are willing to make their<br>
software upgradable. They need to do this for unassigned codepoints<br>
anyway. So we might as well allow for the possibility of moving some<br>
characters from DISALLOWED to other categories (if and when we<br>
determine that they should be moved, having come up with better<br>
criteria for use in IDNs, more information, clamoring users, etc).<br>
<br>
If we allow for this possibility, we don't need to fret so much about<br>
historic scripts right now. Just dump them in DISALLOWED for now, and<br>
deal with them later, if they ever need to be dealt with.<br>
<font color="#888888"><br>
Erik<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Thu, May 8, 2008 at 1:59 PM, Shawn Steele <<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>> wrote:<br>
> Erik wrote:<br>
><br>
> > This also neatly solves the problem of whether or not IDNA-unaware and<br>
> > IDNA-aware clients are allowed to look up labels with Punycode in<br>
> > them. They should always be allowed to do so. Only software that tries<br>
> > to convert from U-labels to A-labels needs to be restricted. This is<br>
> > how we can achieve the most reasonable level of interoperability, in<br>
> > my opinion.<br>
><br>
> I think that conversion U to A conversion does NOT need restriction. Assuming that the steps in conversion include NFKC or appropriate mappings, then if a character moves from disallowed to allowed, the conversion is already known. So no change is required for lookup, even if conversion is required. The only change would be the software the decides the legality of the name, which, IMO could be at a different layer.<br>
><br>
> - Shawn<br>
><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>
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><br clear="all"><br>-- <br>Mark