IDNA2008: concerns about inconsistent mappings, and german sharp s

[Vint Cerf]

This advice belongs in rationale I would think. V

________________________________

From: Lisa Dusseault 
To: Vint Cerf 
Cc: Markus Scherer ; idna-update at alvestrand.no 
Sent: Thu Dec 11 16:05:37 2008
Subject: Re: IDNA2008: concerns about inconsistent mappings, and german sharp s 



This conclusion came from the  "Tranche 8" outcome, right? Based on your summary, we still need to provide the advice for registries around that.  I don'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.

Lisa


On Thu, Dec 11, 2008 at 2:34 AM, Vint Cerf <vint at google.com> wrote:


	Markus,

	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 "ss" 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 "sunrise-like" in its behavior. 

	vint

	
	

	Vint Cerf
	Google
	1818 Library Street, Suite 400
	Reston, VA 20190
	202-370-5637
	vint at google.com




	On Dec 11, 2008, at 12:42 AM, Markus Scherer wrote:


		Dear IDNA-updaters,

		I recently learned about some details about IDNA2008 and was encouraged to voice concerns on this list. 

		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).

		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 'ß' ("sharp s", also mis-named "eszett").This character is mostly equivalent to "ss", and normal uppercasing turns it into "SS" (except maybe on passports). Because of this near-equivalence, there is some amount of confusion about when to use "ß" vs. "ss". In particular,

		*	In Switzerland, "ß" is never used and always replaced with "ss".
		*	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 imperfections.
		*	For several years, prominent newspapers and publishers refused to adopt the new orthography or flip-flopped in their adoption.

		The old IDNA standard mapped "ß" to "ss". 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 (fluß.de vs. fluss.de) which used to be mapped to the same form (fluss.de) 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 "fluß.de" may now find that their browser fails to connect.
		

		Please review this decision!

		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.

		Failing that, it would help to continue to not allow the "ß" in domain names, except as input to an implementation which maps it to "ss" as before.

		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's not required by the spec), understand it, and apply it consistently.

		Sincerely,
		markus

		_______________________________________________
		Idna-update mailing list
		Idna-update at alvestrand.no
		http://www.alvestrand.no/mailman/listinfo/idna-update



	_______________________________________________
	Idna-update mailing list
	Idna-update at alvestrand.no
	http://www.alvestrand.no/mailman/listinfo/idna-update
	
	


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081211/074dd02b/attachment-0001.htm