It is not just a matter of "typographic convenience": the recognized standard German uppercase of "ß" <i>is</i> "SS". Unicode did not invent this relationship -- it is just following recognized German standards. In German orthography ß is not just an ordinary letter like any other. If in normal use ß were caseless, or if ß had a unique uppercase, we wouldn't be having this discussion. But it is not normal. And the previous behavior in IDNA2003 can't be simply discarded. There are two main issues:<br>
<br><b>1. IDNA compatibility. </b>Right now, all of the following point to the same website. If we make this exception for ß, then they won't. <br><br><a href="http://FASS.de">http://FASS.de</a><br><a href="http://Faß.de">http://Faß.de</a><br>
<a href="http://fass.de">http://fass.de</a><br><br>This is not just a UI issue, since the URLs above can be in all sorts of data (email, webpages, etc). And even if IDNA200x comes out soon, data and programs exist, that will only slowly be updated. So for an extended, perhaps indefinite, amount of time browsers and search engines (like ours at Google) will need to handle both IDNA2003 and IDNA200x URLs. When the results under each system point to different places, that is a significant problem and possible security issue.<br>
<br><b>2. Case insensitivity. </b>If we make this exception, then uppercasing a domain name causes it to go to a different place. Even if there were no compatibility issue, there is still the issue of whether it is more important to have ß or to have case-insensitivity.<br>
<br><br>While it would be possible to have an exception for ß, both of these issues need to be considered very carefully, and we should not make any decision lightly. Any proposal for an exception for ß really should get consensus from a broad set of stakeholders, including DENIC, <a href="http://NIC.AT">NIC.AT</a>, and SWITCH, as well as the standards bodies DIN, ÖN, and SNV.<br>
<br>Mark<br><br><div class="gmail_quote">On Tue, Mar 11, 2008 at 8:05 AM, John C Klensin <<a href="mailto:klensin@jck.com">klensin@jck.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(Harald,<br>
<br>
Thanks for this analysis.<br>
<br>
I'd like to make a case for your Alternative 2 (I do not fully<br>
understand the implications of Alternative 3). Let me try to<br>
state it as a principle because, as you know, I hate special<br>
cases. If we have to _implement_ that principle as a special<br>
case, that is a separate, and less significant, matter.<br>
<br>
I think that we need to accept the fact that there are some<br>
transformations and rules that work well for Unicode that do not<br>
work well for domain names. We also have a tool available to<br>
us (or the relevant registries) in the form of the JET "variant"<br>
model and its extensions and extrapolations (see, e.g., RFC 3473<br>
and 4290) that is obvious not applicable to general Unicode<br>
comparison use.<br>
<br>
Our general rule should be to avoid information loss. While we<br>
assume both for historical reasons and due to the symmetry of<br>
case folding them, that there is no information loss in<br>
transforming ordinary Latin upper case characters into lower<br>
case ones, when we start talking about non-reversible mappings<br>
and and spelling rules, we should keep the characters separate<br>
and registerable, rather than taking excursions into the<br>
peculiarities of casefolding (which the Unicode book<br>
acknowledges loses information and recommends against precisely<br>
the way we are using it if that can be avoided).<br>
<br>
This reasoning suggests that the<br>
ß -> ss<br>
mapping is really not, for our purposes, as case folding issue<br>
but a typographic convenience (acceptable in some places,<br>
distasteful in others and certainly not reversible) that is<br>
really no different from, e.g.,<br>
ö -> oe<br>
(acceptable in some places, distasteful in others, plain wrong<br>
in still others, and certainly not reversible).<br>
<br>
If a particular registry wants to treat these as the same, let<br>
them use variants. If we discard the information and treat<br>
them the same as a matter of protocol, there is no way for the<br>
registry to "fix" that. Maybe that distinction, for cases in<br>
which information loss actually occurs, is ultimately the<br>
compelling argument.<br>
<br>
Now, if we can agree on that principle, we need to examine the<br>
set of characters that are transformed in non-obvious ways by<br>
case folding. For those that are like this, we have to figure<br>
out how to implement the principle, which may require some<br>
additions to the exception list.<br>
<br>
john<br>
<br>
<br>
--On Tuesday, 11 March, 2008 10:20 -0400 Harald Tveit Alvestrand<br>
<div><div></div><div class="Wj3C7c"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>> wrote:<br>
<br>
><br>
><br>
> --On Tuesday, March 11, 2008 11:29:30 +0100 Georg Ochsner<br>
> <<a href="mailto:g.ochsner@revolistic.com">g.ochsner@revolistic.com</a>> wrote:<br>
><br>
>>> -----Ursprüngliche Nachricht-----<br>
>>> Von: Kenneth Whistler<br>
>>> Gesendet: Montag, 10. März 2008 21:55<br>
>><br>
>>> Jelte Jansen said:<br>
>><br>
>>> > So if IDNAbis would make an exception for the sharp S, and<br>
>>> > allow it as a separate symbol, would there be people<br>
>>> > running to their lawyers because they think it's<br>
>>> > equivalent to ss too ...<br>
>>><br>
>>> It *is* equivalent to ss, too. It just depends on what level<br>
>>> and type of equivalence you are talking about. They aren't<br>
>>> equivalent for spelling, obviously -- but they *are*<br>
>>> equivalent for some types of searching and sorting.<br>
>><br>
>> Why should they be equivalent in general just because there<br>
>> are equivalences for "some types of searching and sorting"?<br>
><br>
> Note: We're not talking about "equivalent in general" here,<br>
> we're talking about "permitted as a lookup key in the DNS".<br>
><br>
> Under IDNA2003, we were talking about "if the user gives us<br>
> ß, we will look up ss". Under IDNA200x, we're only talking<br>
> about "can ß be used to lookup information in the DNS?",<br>
> since mapping user expectations to lookup keys is considered<br>
> to be outside the protocol.<br>
><br>
> We have four alternatives:<br>
><br>
> 1 - No, it can't<br>
> 2 - Yes, it can, because we're adding a special case<br>
> 3 - Yes, it can, and because of this example, we'll throw away<br>
> the requirement that a character be stable under full<br>
> casefolding in order to be used as lookup<br>
> 4 - Yes, it can, and the Unicode tables should be changed to<br>
> make it stable under casefolding.<br>
><br>
> 1 is what's currently proposed, 2 and 3 can be accomplished by<br>
> changes to the idnabis documents (noting that 3 can have<br>
> unforeseen effects on other characters), 4 requires changes to<br>
> Unicode.<br>
><br>
> Note that if you're arguing the 4th case, that belongs on the<br>
> unicode@unicode list, not here.<br>
><br>
> Harald<br>
><br>
> _______________________________________________<br>
> Idna-update mailing list<br>
> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark