The real issue: interopability, and a proposal (Was: Consensus Call on Latin Sharp S and Greek Final Sigma)

[Vint Cerf]

As john klensin has pointed out no mapping of pvalid chars has always been
an intent of idnabis and there was even text to that effect I think. It is a
good organizing principle

----- Original Message -----
From: Alexander Mayrhofer <alexander.mayrhofer at nic.at>
To: Patrik Fältström <patrik at frobbit.se>; Shawn Steele
<Shawn.Steele at microsoft.com>
Cc: Harald Alvestrand <harald at alvestrand.no>; idna-update at alvestrand.no
<idna-update at alvestrand.no>; lisa Dusseault <lisa.dusseault at gmail.com>; Mark
Davis ☕ <mark at macchiato.com>; "Martin J. Dürst" <duerst at it.aoyama.ac.jp>;
Vint Cerf <vint at google.com>
Sent: Tue Dec 01 04:59:54 2009
Subject: The real issue: interopability, and a proposal (Was: Consensus Call
on Latin Sharp S and Greek Final Sigma)


(I've spent quite some time on re-thinking the issue last night. It's a bit
longish, and the promised proposal is at the end).

I think i didn't make it clear enough in my previous messages that i'm not
an opponent of the character Latin Sharp S itself. I'm opposing against
changes that have a high risk of introducing interopability, particularly in
the long run.

My *only* major concern is that the introduction of the Latin Sharp S is
exactly such a case, but a particularly nasty one. I understand that the
majority of WG participants think that "ß" should be PVALID (i'm carefully
avoiding the word "concensus" here, because it's obviously up to the WG
chair to declare that).

If i look at the issue in an isolated way, not considering any
compatibility/interopability issues, then it makes perfectly sense to
declare "ß" PVALID, because (this is sort of convincing myself here ;) :

- There seems to be little existing deployment of ß-labels out there, at
least on the web - the client side is a different issue, there's nearly 100%
deployment. We can also err guesstimate that "ß" has only about 1% of the
deployment of other german "umlauts", according to Erik's numbers (As Eric
pointed out, those numbers have no indication of confidence, though). We
don't know how many people type "ß" into their browser address bar, though,
which is at least "unsatisfying" from an engineering perspective.

- The character is undoubtly part of German grammar, at least in two of the
three countries where German is an official language - i don't know about
the minorities in other countries. The upper case variant as well as the
Unicode casing and folding is.. well, extravagant - but the lowercase "ß" is
definitely part of the grammar.

- Georg's argument that this would be "the last chance" to introduce "ß",
got me thinking. If the "Exceptions" would be implemented as an IANA
registry, it would be much easier to add (and probably remove) characters.
But given that changes to the Exceptions now require an update to the base
specification, we should probably take this opportunity, rather than waiting
for IDNA2015.

So, as i said multiple times, the problem is changing the semantics of a
part of the namespace, definitely from the user's perspective - one could
argue whether or not that means the "protocol semantics" change, since the
mapping step ist part of the protocol of IDNA2003.

Regarding interopability, i'm not so much concerned about the transition
period between IDNA2003 and IDNAbis. This will be painful, but it will be
(hopefully temporary).

What i am more concerned is that the legacy of the "ß-ss" mapping would
introduce incompatibility for an indefinite period of time, *after* all
clients have switched over to IDNAbis. This could happen because some
vendors would implement mappings to be fully IDNA2003 backwards compatible,
and others would implements the informative idnabis-mappings only.