<p><font size=2 color=navy face=Arial>
This advice belongs in rationale I would think. V</font></p>
<p><hr size=2 width="100%" align=center tabindex=-1>
<font face=Tahoma size=2>
<b>From</b>: Lisa Dusseault <lisa.dusseault@gmail.com> <br><b>To</b>: Vint Cerf <br><b>Cc</b>: Markus Scherer <markus.icu@gmail.com>; idna-update@alvestrand.no <idna-update@alvestrand.no> <br><b>Sent</b>: Thu Dec 11 16:05:37 2008<br><b>Subject</b>: Re: IDNA2008: concerns about inconsistent mappings, and german sharp s <br></font></p>
<br>This conclusion came from the&nbsp; &quot;Tranche 8&quot; outcome, right? Based on your summary, we still need to provide the advice for registries around that.&nbsp; I don&#39;t know how obvious that can be made when somebody is looking at the new rules for Eszett, but it might help readers figure out that what the standard can do is limited, and what issues have to be dealt with by registries.<br>
<br>Lisa<br><br><div class="gmail_quote">On Thu, Dec 11, 2008 at 2:34 AM, Vint Cerf <span dir="ltr">&lt;<a href="mailto:vint@google.com">vint@google.com</a>&gt;</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;">
<div style="">
Markus,<div><br></div><div>this has been reviewed repeatedly and the conclusion is that because the sharp S is used differently in different jurisdictions, this needs to be a choice made at registration time, not at protocol time. Some jurisdictions will bundle the sharp S form and the &quot;ss&quot; form so that both forms of the domain name are registered in the name of the registrant. Upon introduction of sharp S, registries may need to use an introductory process that alerts all registrants relying on the mapping to register the sharp S form as well. This is &quot;sunrise-like&quot; in its behavior.&nbsp;</div>
<div><br></div><div>vint</div><div><br><font color="#888888"><div> <span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div>
<div><br>Vint Cerf</div><div>Google</div><div>1818 Library Street, Suite 400</div><div>Reston, VA 20190</div><div>202-370-5637</div><div><a>vint@google.com</a></div><div><br></div></div></span><br></span><br></span> </div>
<br></font><div><div><div></div><div class="Wj3C7c"><div>On Dec 11, 2008, at 12:42 AM, Markus Scherer wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div class="Wj3C7c">Dear IDNA-updaters,<div><br></div>
<div>I recently learned about some details about IDNA2008 and was encouraged to voice concerns on this list. </div><div><br></div><div>If I understand correctly, IDNA2008 -- unlike the 2003 version -- will not prescribe a particular set of character mappings. I am concerned that this will lead to implementations behaving inconsistently, and, for users, unpredictably, leading to navigation to the wrong web sites or getting an error message for what seems like (and used to be) a minor variation (for example, a casing difference).</div>
 <div><br></div><div>In particular, as a native German speaker, I am concerned about what I understand to be the effect on using German domain names -- regarding the &#39;ß&#39; (&quot;sharp s&quot;, also mis-named &quot;eszett&quot;).This character is mostly equivalent to &quot;ss&quot;, and normal uppercasing turns it into &quot;SS&quot; (except maybe on passports). Because of this near-equivalence, there is some amount of confusion about when to use &quot;ß&quot; vs. &quot;ss&quot;. In particular,</div>
 <div><ul><li>In Switzerland, &quot;ß&quot; is never used and always replaced with &quot;ss&quot;.</li><li>The orthography change of 1996 changed the rules about ß vs. ss and changed many very common words. Anyone who learned to write before the reform (like me) is prone to either still write the old way or be inconsistent, in addition to normal spelling&nbsp;imperfections.</li>
 <li>For several years, prominent newspapers and publishers refused to adopt the new orthography or flip-flopped in their adoption.</li></ul></div><div>The old IDNA standard mapped &quot;ß&quot; to &quot;ss&quot;. I understand that IDNA2008 does not include this mapping (or indeed any other), but does permit ß in unmapped domain names. This means that it will be possible for equivalent domain names (<a>fluß.de</a> vs. <a>fluss.de</a>) which used to be mapped to the same form (<a>fluss.de</a>) to now point to unrelated web sites (where one might be a phishing site mimicking the other), or a user who used to be successful following a link &quot;<a>fluß.de</a>&quot; may now find that their browser fails to connect.<br>
 </div><div><br></div><div>Please review this decision!</div><div><br></div><div>It seems like for best consistency and interoperability, the updated IDNA standard should include mappings that are compatible extensions of the 2003 version, except to fix errors and security issues, and in particular should maintain the folding of equivalent domain names to a common representative.</div>
 <div><br></div><div>Failing that, it would help to continue to not allow the &quot;ß&quot; in domain names, except as input to an implementation which maps it to &quot;ss&quot; as before.</div><div><br></div><div>If that were not adopted either, then users can only hope that all registrars either automatically treat all equivalent forms as aliases or forbid registering a domain name if an equivalent one exists already. (A connection error would be better than a phishing trap.) I am pessimistic about all relevant registrars to learn about this (or anything that&#39;s not required by the spec), understand it, and apply it consistently.</div>
 <div><br></div><div>Sincerely,</div><div>markus</div><div><br></div></div></div><div class="Ih2E3d"><div style="margin: 0px;">_______________________________________________</div><div style="margin: 0px;">Idna-update mailing list</div>
<div style="margin: 0px;"><a>Idna-update@alvestrand.no</a></div><div style="margin: 0px;"><a>http://www.alvestrand.no/mailman/listinfo/idna-update</a></div> </div></blockquote></div><br></div></div><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">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br></blockquote></div><br>