Consensus Call on Latin Sharp S and Greek Final Sigma

Shawn Steele Shawn.Steele at microsoft.com
Tue Dec 1 01:04:14 CET 2009


Sorry for the partial sentence.

And that’s the problem ☺

In Switzerland users would certainly expect eszett to map to ss.  In Germany and Austria they wouldn’t be too surprised by the behavior.

So if, in the “contextual user interface” (& IDNA2003), the eszett is mapped to ss, then there’s no point to having it be PVALID.  So the problem here is that the lack of mapping IS related to the PVALID decision.  And that’s the big change from IDNA2003 that’s causing problems.

If there is no mapping, then PVALID makes a little bit of sense.  If you want discrete, unique ID’s for IRI’s, then I’m not sure you want fussball and fuβball to go to different places.  If you do want mapping at some level, then mapping these and keeping IDNA2003 behavior is logical.

So I think these behavior of these 2 characters also depends on the mapping behavior.  IDNA2008 took a different direction in mapping, and that led to this behavior for these characters.  IDNA2003 went a different direction with mapping and that led to a different place.

-Shawn

From: Vint Cerf [mailto:vint at google.com]
Sent: ,  30,  2009 1:51
To: Shawn Steele
Cc: Mark Davis ☕; Harald Alvestrand; idna-update at alvestrand.no; lisa Dusseault
Subject: Re: Consensus Call on Latin Sharp S and Greek Final Sigma

the distinction is not between mapping.

the distinction is between allowing or not allowing these two characters as PVALID.

Mapping is not part of the IDNA2008 proposed standard. The mapping document and other references to mapping in rationale are not normative. Mapping may very well occur in consequence of contextual user interface treatments but such handling is outside the scope of the base standard.

vint


On Nov 30, 2009, at 2:45 AM, Shawn Steele wrote:


I agree with Mark that this is very badly worded.  Also, as Mark alludes, the distinction is between mapping.

(2) Both characters should be disallowed.  (and mapped as in 2003).

One would expect a swiss person typing "fussball.de" to continue to get to the expected site, even though the spelling isn't perfect by "de" standards.  The ONLY place where a distinction is interesting is in Germany and Austria, however Mark points out both of those NICs are against this change.

-Shawn
________________________________
From: idna-update-bounces at alvestrand.no<mailto:idna-update-bounces at alvestrand.no> [idna-update-bounces at alvestrand.no<mailto:idna-update-bounces at alvestrand.no>] on behalf of Mark Davis ☕ [mark at macchiato.com<mailto:mark at macchiato.com>]
Sent: Sunday, November 29, 2009 9:35 AM
To: Harald Alvestrand
Cc: idna-update at alvestrand.no<mailto:idna-update at alvestrand.no>; Vint Cerf; lisa Dusseault
Subject: Re: Consensus Call on Latin Sharp S and Greek Final Sigma
(2) Both characters should be DISALLOWED

I think the way the question is phrased may mislead some people on this list. The real choice is between having them mapped to "ss" vs having them distinguished from "ss", because all browser vendors are planning to provide mappings, and I think all other vendors will be drawn down that path, for compatibility with the browsers.

This standard is not written in a vacuum; whether or not eszett and final-sigma would have been a better choice 7 years ago, billions of current browsers and other programs use the 2003 policies, and those would take years to change. In the meantime, a change of this magnitude from 2003 will cause significant problems.

The people on this list need to carefully consider their positions, since they will not have to live with the compatibility and security problems; German and Greek speakers will. And it is telling that representatives like the German and Austrian NICs are in favor of continuing the 2003 policies of mapping the characters.

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091201/864c54e7/attachment-0001.htm 


More information about the Idna-update mailing list