<font size="2">First off, I&#39;m hopeful that at least one of the directions that Erik is exploring will work out. If we can give browser, etc, a way to show the preferred representation, then we can get out of security problem of IDNA2008 domains going to different IP addresses than IDNA2003 names for the four characters. Maybe something like the favicon.ico approach would work (eg <a href="http://mail.google.com/favicon.ico">http://mail.google.com/favicon.ico</a>), at a level above the DNS.<br>
<br>As far as eszett goes, a key issue is that IDNA is not guaranteed to make all distinctions that written language has.  There has been no uproar about the fact that IDNA2008 disables many, many names in English (especially Irish), French, Italian, and others. For example, all of the following are currently allowed in IDNA, but would be disallowed under IDNA2008.<br>
</font>
<ul><li><font size="2">
D’Angelo</font></li><li><font size="2">
d’Alembert</font></li><li><font size="2">
O’Connor</font></li><li><font size="2">
l’église</font></li><li><font size="2">
aujourd’hui</font></li><li><font size="2">
Elizabeth’s crown</font></li></ul><font size="2">These are all represented with the <code><a href="http://unicode.org/cldr/utility/character.jsp?a=2019" target="_blank">U+2019</a></code> ( ’ ) RIGHT SINGLE QUOTATION MARK = curly apostrophe in IDNA2003. </font><font size="2">Here is an example of  working currently: <a href="http://Mark">http://Mark</a>’<a href="http://s-Grill.blogspot.com">s-Grill.blogspot.com</a>. (Firefox isn&#39;t able to show this correctly, but Safari, Chrome, and IE all do.)</font><br>
<font size="2"><br>The apostrophes are disabled in IDNA2008 by:<br></font><ul><li><font size="2"><a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables" target="_blank">http://tools.ietf.org/html/draft-ietf-idnabis-tables</a></font></li>
<li><pre><font size="2">200E..2064  ; DISALLOWED  # LEFT-TO-RIGHT MARK..INVISIBLE PLUS</font></pre></li></ul>
<font size="2">
Mark<br><br>====<br><br>BTW, a few comments on Georg&#39;s message:<br><br>On Fri, Mar 13, 2009 at 01:40, Georg Ochsner &lt;<a href="mailto:g.ochsner@revolistic.com">g.ochsner@revolistic.com</a>&gt; wrote:<br>&gt;<br>&gt; &gt; 1.)<br>
&gt; &gt; - &quot;ß&quot; and &quot;ss&quot; are linguistically two different things.<br>&gt; &gt;<br>&gt; &gt; true: and so are &quot;Polish&quot; and &quot;polish&quot;, or &quot;therapist&quot; and &quot;the rapist&quot;<br>
&gt; &gt; - neither of these differences can be directly represented in domain<br>&gt; &gt; names.<br>&gt;<br>&gt; That kind of comparison is not getting truer by repeating it. ß is not simply the lowercase of SS or vice verse. ß used to have no uppercase (in Unicode), now IT HAS. <br>
<br>I well understand this; I&#39;m president and co-founder of the Unicode consortium.<br><br>Notwithstanding the introduction of the capital, which was done because there are some (but currently few) attested instances, the German national body&#39;s position remained that the normal uppercase of </font><font size="2">ß is SS.<br>
<br></font><font size="2">&gt; Regarding your second example do you mean that <a href="http://therapist.com">therapist.com</a> should be bundled with <a href="http://the-rapist.com">the-rapist.com</a>?? Or as another idea should <a href="http://wwwapple.com">wwwapple.com</a> be bundled with <a href="http://apple.com">apple.com</a>, because it is a very common typing error?<br>
<br>You misunderstand. The point is that IDNA does not, and cannot, guarantee that all distinctions possible in human languages are allowed in IDNAs.<br><br>&gt;<br>&gt;<br>&gt; &gt; - Many people do now think that the mapping in IDNA2003 was a (big)<br>
&gt; &gt; mistake, which can be corrected now.<br>&gt; &gt;<br>&gt; &gt; It may or may not have been a mistake. Having the uppercase of a string<br>&gt; &gt; map to a different place than the original is a bad thing, in many<br>
&gt; &gt; peoples&#39; minds. I think the real problem is not that &quot;ß&quot; and &quot;ss&quot; have<br>&gt; &gt; the same canonical form, it is that the preferred display form for a<br>&gt; &gt; given string is not maintained by the Punycode encoding.<br>
&gt; &gt;<br>&gt; &gt; And the &quot;can&quot; is at issue. It certainly can be done, but the cost is not<br>&gt; &gt; insignificant. At least some people are very worried about the<br>&gt; &gt; compatibility and security issues.<br>
&gt;<br>&gt; Sure the WG must address the compatibility and security issues, but making ß PVALID is a big gain. People in the future will be able to freely choose which domains they use, just like they can decide to use ß or ss when they are writing. I think people are intelligent enough to deal with ß in domains if they deal with it in everyday&#39;s life. That&#39;s nothing the protocol must dictate. People nowadays can also deal with similar issues e.g. <a href="http://www.whitehouse.org">www.whitehouse.org</a> leads to Mr. Bush while <a href="http://www.white-house.org">www.white-house.org</a> leads to advertisements. Choose yourself which one you like better.<br>
<br>The problem is compatibility with IDNA2003.<br><br>&gt;<br>&gt;<br>&gt; &gt; - There is consensus to make ß PVALID in IDNA2008.<br>&gt; &gt; I don&#39;t think the situation is that clear-cut: see Marcos&#39;s mail.<br>
&gt;<br>&gt; There has been a consensus call with a clear outcome.<br><br>There was a consensus call with a clear outcome, but the WG has also explored a lot of new ground since that consensus was arrived at. In particular, the security and compatibility impact of having a domain name lookup of D by client X go to a different location was not fully explored.<br>
<br>If we can solve the &quot;preferred display&quot; aspect of IDNA, then it appears that we can solve the technical aspect. The </font><a href="http://busse.de/" target="_blank">buße.de</a><font size="2"> domain could be displayed as </font><a href="http://busse.de/" target="_blank">buße.de</a>, and yet people could reach it by typing <a href="http://BUSSE.DE">BUSSE.DE</a> as well.<br>
<br><font size="2">&gt;<br>&gt;<br>&gt; &gt; - In the future domains with ß and ss should be autarchic domains in the<br>&gt; &gt; DNS.<br>&gt; &gt; Not sure what you mean by &quot;autarchic&quot;. Do you mean &quot;separate&quot;?<br>
&gt;<br>&gt; Yes, I mean separate by protocol. The registries can solve the rest (sunrise periods, cloning registrant and NS data etc.) And they have many native speakers and know best about their local situation.<br><br>
I just don&#39;t think that the magnitude of the issue is being faced. It is a problem for the entire ecosystem. Registries, but not only top level, but also the many sublevel registries like <a href="http://blogspot.com">blogspot.com</a>; intermediaries, but also huge numbers of instances of client software. Just look at how many people are still on IE6.<br>
<br>&gt;<br>&gt;<br>&gt; &gt; - As a registrant it can, but not necessarily must be interesting to<br>&gt; &gt; have two domains, that just vary in ß and ss. (e.g. <a href="http://busse.de">buße.de</a> means<br>&gt; &gt; <a href="http://penance.de">penance.de</a> where <a href="http://busse.de">busse.de</a> means <a href="http://busses.de">busses.de</a> in English - two completely<br>
&gt; &gt; different meanings)<br>&gt; &gt;<br>&gt; &gt; Yet somehow the Swiss manage to understand busse with both meanings, and<br>&gt; &gt; all Germans manage with BUSSE having both meanings. When I&#39;ve asked for<br>
&gt;<br>&gt; Yes, but &quot;somehow&quot; doesn&#39;t mean things can&#39;t be made better.<br><br>We have to consider the cost as well as the benefits. Suppose that we could show that traffic circulation could be improved by 3% in countries that drive on the left; it doesn&#39;t mean that the US or Germany should switch the way all their road systems work -- there would be a huge cost involved. The fact that the Swiss somehow manage (perhaps its that clean Alpine air) to do without the distinction means that there is a workaround.<br>
<br></font><font size="2">We can&#39;t distinguish between &quot;Van-Der-Poel&quot; and &quot;van-der-poel&quot;</font><font size="2"></font> either in IDNA, but people manage to work around that.<br>
<font size="2"><br>
</font><font size="2">&gt;<br>&gt;<br>&gt; &gt; examples, the number of cases where there are two distinct meanings<br>&gt; &gt; appears to be extremely small; any ambiguity introduced is orders of<br>&gt; &gt; magnitude smaller than ambiguities introduced by omitting spaces between<br>
&gt; &gt; words, for example.<br>&gt; &gt;<br>&gt; &gt; If you want to give some data as to the percentage of German words that<br>&gt; &gt; are distinguished in meaning by ß and ss -- and of course omitting those<br>&gt; &gt; affected by the latest spelling reform, which caused the preferred<br>
&gt; &gt; display form to shift from one to the other.<br>&gt;<br>&gt; Let me give you thousands of relevant examples at once. I am sure you agree that surnames are often used as (parts of) domain names e.g. <a href="http://smith-books.com">smith-books.com</a> . Now I queried the German telephone book and this is the result. 1,5 Mio Germans have a surname with ß. There are over 3&#39;100 different pairs of surnames (2 x 3&#39;100 names) which do only differ in ß and ss instead. Over 2,5 Mio people (!) have one of these surnames either with ß or ss. (e.g. Abeßer/Abesser, Ablaß/Ablass, Abstoß/Abstoss ...) I think it would be the right thing, if Mr. Weiß could register <a href="http://weiss.de">weiß.de</a> while Mr. Weiss has <a href="http://weiss.de">weiss.de</a>. For a user looking for the website it is just like looking up his number in a phonebook, he has to know if he is looking for Mr. Weiß or Mr. Weiss.<br>
<br>Your numbers are a bit unclear to me. You are saying that 0.4% of German names in the phonebook are distinguished only by </font><font size="2">ß vs ss</font>. You then say that 2.5M people have those names, which would be 3% of the German population. So you are saying that those people are proportionately overrepresented in the population by 700%? Or do you mean that 2.5M people have names containing either <font size="2">ß or ss</font>? (Could you point to your data sources also?)<br>
<br><font size="2"><br>
If we didn&#39;t have the compatibility problems, separating eszett from ss
would not be an issue. There would still be the issue of casing, but
that would be trumped by the reasonable desire to distinguish them. It is the compatibility issue that most concerns me.</font><br><font size="2"><br>&gt;<br>&gt;<br>&gt; Best regards<br>&gt; Georg<br>&gt;<br><br></font><font size="2"><br>

<br>
</font><br><font size="2"><br></font>