[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Tilde

tedd wrote:
If, as you say, the mapping step is to avoid alternate representations and to erase case distinctions, then it has failed because it doesn't produced anything. 

Why do you say that? The mapping clearly avoids alternate
representations and erases case distinctions. For example,
"www.LÖWIS.de" is treated as if it was "www.löwis.de".

So I fail to see that the mapping step has failed. It is very
successful.

Now, if the tilde character is currently used in some fashion by behind the screens Internet techs, as Paul suggested, then I can understand why the tilde character is prohibited. 

I'd like to point out that it was always the intention, and is the
existing practice, that the IDNA RFCs are augmented by policies of the
registrars, which further constrain the set of characters that you can
use within a particular zone.

To my knowledge, none of the TLD registrars currently allows
registration of names which contain TILDE OPERATOR. So for
one-below-toplevel, the entire issue is irrelevant.

Please tell me why mapping the tilde to the tilde operator wouldn't work. 

Because it would not matter. Consider a domain label "foo~", and assume
we are applying the "ToAscii" function, trying to generate the IDNA
version of the label. Please follow me though chapter 4 of RFC 3490 now.
Further assume that UseSTD3ASCIIRules is true.

1. If the sequence contains any code points outside the ASCII range
   (0..7F) then proceed to step 2, otherwise skip to step 3.

   No, this label does not contain any code points outside the ASCII
   range. So we proceed to step 3

3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
   (a) Verify the absence of non-LDH ASCII code points; that is, the
         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

   UseSTD3ASCIIRules is true, so we check. The label contains a
   non-LDH code point, so ToASCII fails.

Now, your proposal is that TILDE was mapped to TILDE OPERATOR.
That would have happened in step 2. However, according to the
specification, we have *skipped* step 2. Therefore, your mapping
approach wouldn't work, and ToASCII would fail.

Regards,
Martin