I think at least some of the problems we are having are in terms of communication. There are at least 3 cases that are important to separate:<br><br>A) Registration local mapping. <br><br>You request a registration of "Å.com", and the registry converts that to "<a href="http://aa.com">aa.com</a>" behind your back. They are allowed to do so by:<br>
<br><div style="margin-left: 40px;"><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-4.2">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-4.2</a><br></div><br>B) Registry local mapping. <br>
<br>You request a registration of "<a href="http://xn--5ca.com">å.com</a>" and the registry gives you both "<a href="http://xn--5ca.com">å.com</a>" and "<a href="http://aa.com">aa.com</a>" (bundling).<br>
<br><div style="text-align: left; margin-left: 40px;">The draft is silent on this aspect.<br></div><br>C) Client local mapping. <br><br>The web page you're looking at contains <a href="Å.com">, and your browser sends you to "<a href="http://aa.com">aa.com</a>" instead of "<a href="http://xn--5ca.com">å.com</a>", behind your back.<br>
<br><div style="margin-left: 40px;">In the above messages** I'm using the characters:<br><code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=00C5">U+00C5</a></code> ( Å ) LATIN CAPITAL LETTER A WITH RING ABOVE<br>
<code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=00E5">U+00E5</a></code> ( å ) LATIN SMALL LETTER A WITH RING ABOVE.<br></div>
<br>They are allowed to do so by:<br><br><div style="margin-left: 40px;"><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.3">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.3</a><br>
</div><br>===<br><br>For (A), I think we are in agreement; this is a bad idea. The registrant should supply exactly what they want, and if it is not an A-Label, it should be rejected, so that as a result the user only is able to register what s/he thinks is being registered.<br>
<br>For (B), I'm not sure what you think, but for me is clearly a case where local mappings make sense, and are being currently implemented (under a different name, bundling). So, for example, simplified Chinese characters in a label can be mapped to traditional, and both labels registered. Labels only differing by eszett and "ss" can be bundled (or blocked). That's up to the registry.<br>
<br>For (C), this is the area that the UTC position is actually addressing; where some client program implementing IDNA is doing a remapping. It is all in reference to (C) that my message to Cary is written. And it is here where the interoperability and security problems of local mappings surface.<br>
<br>At least in the current draft, we are not at a "no mappings" model - we
are at an "arbitrary conflicting mappings" model, because we allow
local mappings for (C).<br><br>And the thought of the thousands of user agents; browsers, IMers, emailers, plus search engines, (plus varying by versions!) sending <a href="Å.com"> to "<a href="http://aa.com">aa.com</a>" instead of "<a href="http://xn--5ca.com">å.com</a>" is a nightmare. Before allowing that nightmare, we really need to hear a compelling case for it!<br>
<br clear="all">Mark<br><br>** I included the spelled-out characters that because you misread my message above. You said "I find
your examples of someone mapping "a" with an acute accent into one with
a grave accent unpersuasive, partially because that is prohibited by
the current text (because both are PVALID characters) ".<br><br>What I
actually wrote was "Á should not map to à and not á". The character being mapped in my message is a <code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=00C1">U+00C1</a></code> ( Á ) LATIN CAPITAL LETTER A WITH ACUTE, which is *not* PVALID. I'm guessing your emailer mangled it. But Å is a better example anyway, because of the equivalence in some languages "aa" in some languages.<br>