AW: The real issue: interopability, and a proposal (Was: Consensus Call on Latin Sharp S and Greek Final Sigma)
g.ochsner at revolistic.com
Tue Dec 1 13:23:21 CET 2009
for me this is indeed a "way forward". This WG and IDNs came a VERY long way and it's not yet finished. We still have many browser out there not supporting IDNA2003. We will have IDN-TLDs next year. It Is obvious that many things got much more complex and dynamic with IDNs and it is not only a question of a single protocol or technical standard any more. Furthermore it regularly involves documentation, communication, organization, processes, patience and much more.
When I look at the intention of this WG, the intensive dialog and most of all at the involved people and companies they work for, it is really realistic to get the sharp s implemented as we would like to have it without the historical mapping of 2003. What I ask for is that it should be the ambition to get it right in the long term instead of sticking to an old mistake in order to avoid pain or work in the short term. This won't take decades BTW, it's a matter of some more years.
Now if I take ideas like those from Lisa ("what if registries could be relied upon to bundle a PVALID ß with 'ss' for a period" and " suggest a start date for registries to respond to requests for ß domains") and you ("characters that are PVALID MUST NOT be subject to mappings"), I see we can agree on a clever transition if we want to. Also browser developers could implement user education as easy as mapping. That could be simply asking the user if he is sure that he wants to navigate to a domain with sharp s or prefers to go to the ss sibling.
What else could make the transition more comfortable?
> -----Ursprüngliche Nachricht-----
> Von: idna-update-bounces at alvestrand.no [mailto:idna-update-
> bounces at alvestrand.no] Im Auftrag von Alexander Mayrhofer
> Gesendet: Dienstag, 1. Dezember 2009 11:00
> An: Patrik Fältström; Shawn Steele
> Cc: Harald Alvestrand; idna-update at alvestrand.no; lisa Dusseault; Mark
> Davis ☕; "Martin J. Dürst"; Vint Cerf
> Betreff: 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
> From a registry point of view, i would very much like to avoid any
> bundling. However, the "permanent" interopability issues outlined above
> are bound to "taint" labels with an "ß" for an indefinite period of
> time, with the most sensible option to disallow registration completely
> to avoid those problems.
> I think it's not very likely that all vendors agree on a single mapping
> - particularly with the WG scope of not dealing with a mapping as part
> of the protocol. However, i'd like to propose the following:
> - add text to Section 5 of idnabis-protocol that says
> "characters that are PVALID MUST NOT be subject to mappings".
> Or (more focused)
> "characters that are listed as Exceptions (F) in Section 2.6
> of [tables] MUST NOT be subject to mappings"
> I'm not sure whether that contradicts the "local matters" part in
> Section 5.1 (and i'm pretty sure it creates problems elsewhere), but i
> think it solves the "permanent interopability" problem outlined above.
> That means that "ß" stops working during the transition period, but also
> means that it can be treated as an independent character *after* the
> transition - bundling is not required, Mr Weiss and Mr Weiß can both
> have their distinct domain names, etc..
> Is that a way forward? Comments appreciated.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update