Greek Casefolding sigma

Patrik Fältström patrik at
Sat Mar 29 17:04:36 CET 2008

On 29 mar 2008, at 16.47, Mark Davis wrote:

> Patrik, you misunderstand.

My apologies for this. Jalte helped clearing things up.

> I'm not saying that this should be part of the
> protocol. What I'm saying is that the protocol, *combined with a
> postprocessing step for UIs, *would handle the situation.

Now I understand.

What I reacted against (and misunderstood) was postprocessing on the  
"key" that is used in DNS.


> (In retrospect -- and water long under the bridge -- we would have  
> been
> better off to use one of the variants of Punycode, which has the  
> ability to
> encode case and other distinguishing information in the original  
> Unicode
> using case in the ASCII form. Had we gone that route, we could have
> maintained the visual distinctions on output of DNS for sigma and  
> similar
> cases, because the DNS does a caseless compare for A-Z.)
> Mark
> On Sat, Mar 29, 2008 at 2:00 AM, Patrik Fältström  
> <patrik at> wrote:
>> On 28 mar 2008, at 18.52, Mark Davis wrote:
>>> That would show
>>> σωτήρης<http://%CF%83%CF%89%CF%84%CE%AE%CF%81%CE%B7%CF%82 
>>>>properly, and maintain compatibility.
>> This is not about how to "show" things, as DNS is nothing else than a
>> storage / lookup mechanism.
>> You store a key, and together with that key some data. You can _NOT_
>> send in the data and get the key back.
>> The way IDNA2003 is designed is that the key does _NOT_ allow final
>> sigma, and this because of design of Unicode. Regardless of if "the
>> user typed" sigma or final sigma, the same key should match. Without
>> changing the matching algorithm (that is out), the key have to be
>> calculated on the client side. This key that is sent in is sigma,
>> never final sigma.
>> There is _no_ "reverse" mapping in DNS. Just lookup.
>> That said, one can do a lookup of a PTR record where the data is a
>> domain name. This domain name because of same rules as for the key  
>> can
>> not include the sigma, but the final sigma. And if that is the  
>> problem
>> people try to resolve, then that is what should be discussed, but  
>> that
>> has not much to do with the creation of the key used in the lookup.
>>   Patrik
> -- 
> Mark

More information about the Idna-update mailing list