To be complete, one would ban mapping not only of PVALID, but also of DISALLOWED (since those are in an indeterminate state, and could become PVALID).<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 05:22, 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;">
As john klensin has pointed out no mapping of pvalid chars has always been<br>
an intent of idnabis and there was even text to that effect I think. It is a<br>
good organizing principle<br>
<div class="im"><br>
----- Original Message -----<br>
From: Alexander Mayrhofer &lt;<a href="mailto:alexander.mayrhofer@nic.at">alexander.mayrhofer@nic.at</a>&gt;<br>
To: Patrik Fältström &lt;<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>&gt;; Shawn Steele<br>
&lt;<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>&gt;<br>
</div><div><div></div><div class="h5">Cc: Harald Alvestrand &lt;<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>&gt;; <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a><br>
&lt;<a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>&gt;; lisa Dusseault &lt;<a href="mailto:lisa.dusseault@gmail.com">lisa.dusseault@gmail.com</a>&gt;; Mark<br>
Davis ☕ &lt;<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>&gt;; &quot;Martin J. Dürst&quot; &lt;<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;;<br>
Vint Cerf &lt;<a href="mailto:vint@google.com">vint@google.com</a>&gt;<br>
Sent: Tue Dec 01 04:59:54 2009<br>
Subject: The real issue: interopability, and a proposal (Was: Consensus Call<br>
on Latin Sharp S and Greek Final Sigma)<br>
<br>
<br>
(I&#39;ve spent quite some time on re-thinking the issue last night. It&#39;s a bit<br>
longish, and the promised proposal is at the end).<br>
<br>
I think i didn&#39;t make it clear enough in my previous messages that i&#39;m not<br>
an opponent of the character Latin Sharp S itself. I&#39;m opposing against<br>
changes that have a high risk of introducing interopability, particularly in<br>
the long run.<br>
<br>
My *only* major concern is that the introduction of the Latin Sharp S is<br>
exactly such a case, but a particularly nasty one. I understand that the<br>
majority of WG participants think that &quot;ß&quot; should be PVALID (i&#39;m carefully<br>
avoiding the word &quot;concensus&quot; here, because it&#39;s obviously up to the WG<br>
chair to declare that).<br>
<br>
If i look at the issue in an isolated way, not considering any<br>
compatibility/interopability issues, then it makes perfectly sense to<br>
declare &quot;ß&quot; PVALID, because (this is sort of convincing myself here ;) :<br>
<br>
- There seems to be little existing deployment of ß-labels out there, at<br>
least on the web - the client side is a different issue, there&#39;s nearly 100%<br>
deployment. We can also err guesstimate that &quot;ß&quot; has only about 1% of the<br>
deployment of other german &quot;umlauts&quot;, according to Erik&#39;s numbers (As Eric<br>
pointed out, those numbers have no indication of confidence, though). We<br>
don&#39;t know how many people type &quot;ß&quot; into their browser address bar, though,<br>
which is at least &quot;unsatisfying&quot; from an engineering perspective.<br>
<br>
- The character is undoubtly part of German grammar, at least in two of the<br>
three countries where German is an official language - i don&#39;t know about<br>
the minorities in other countries. The upper case variant as well as the<br>
Unicode casing and folding is.. well, extravagant - but the lowercase &quot;ß&quot; is<br>
definitely part of the grammar.<br>
<br>
- Georg&#39;s argument that this would be &quot;the last chance&quot; to introduce &quot;ß&quot;,<br>
got me thinking. If the &quot;Exceptions&quot; would be implemented as an IANA<br>
registry, it would be much easier to add (and probably remove) characters.<br>
But given that changes to the Exceptions now require an update to the base<br>
specification, we should probably take this opportunity, rather than waiting<br>
for IDNA2015.<br>
<br>
So, as i said multiple times, the problem is changing the semantics of a<br>
part of the namespace, definitely from the user&#39;s perspective - one could<br>
argue whether or not that means the &quot;protocol semantics&quot; change, since the<br>
mapping step ist part of the protocol of IDNA2003.<br>
<br>
Regarding interopability, i&#39;m not so much concerned about the transition<br>
period between IDNA2003 and IDNAbis. This will be painful, but it will be<br>
(hopefully temporary).<br>
<br>
What i am more concerned is that the legacy of the &quot;ß-ss&quot; mapping would<br>
introduce incompatibility for an indefinite period of time, *after* all<br>
clients have switched over to IDNAbis. This could happen because some<br>
vendors would implement mappings to be fully IDNA2003 backwards compatible,<br>
and others would implements the informative idnabis-mappings only.<br>
<br>