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"><<a href="mailto:vint@google.com">vint@google.com</a>></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 <<a href="mailto:alexander.mayrhofer@nic.at">alexander.mayrhofer@nic.at</a>><br>
To: Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>>; Shawn Steele<br>
<<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>><br>
</div><div><div></div><div class="h5">Cc: Harald Alvestrand <<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>>; <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a><br>
<<a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>>; lisa Dusseault <<a href="mailto:lisa.dusseault@gmail.com">lisa.dusseault@gmail.com</a>>; Mark<br>
Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>>; "Martin J. Dürst" <<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>>;<br>
Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>><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've spent quite some time on re-thinking the issue last night. It's a bit<br>
longish, and the promised proposal is at the end).<br>
<br>
I think i didn't make it clear enough in my previous messages that i'm not<br>
an opponent of the character Latin Sharp S itself. I'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 "ß" should be PVALID (i'm carefully<br>
avoiding the word "concensus" here, because it'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 "ß" 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's nearly 100%<br>
deployment. We can also err guesstimate that "ß" has only about 1% of the<br>
deployment of other german "umlauts", according to Erik's numbers (As Eric<br>
pointed out, those numbers have no indication of confidence, though). We<br>
don't know how many people type "ß" into their browser address bar, though,<br>
which is at least "unsatisfying" 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'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 "ß" is<br>
definitely part of the grammar.<br>
<br>
- Georg's argument that this would be "the last chance" to introduce "ß",<br>
got me thinking. If the "Exceptions" 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's perspective - one could<br>
argue whether or not that means the "protocol semantics" change, since the<br>
mapping step ist part of the protocol of IDNA2003.<br>
<br>
Regarding interopability, i'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 "ß-ss" 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>