You are misinformed -- domains names, which include the TILDE OPERATOR, can be registered in both ".com" and ".net" TLD's and most likely other registrars as well.
This is not true. Please take a look at
http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_001382.html
This is the list of scripts which are supported in the .com and .net zones. Characters that don't belong to one of these scripts, or labels that draw characters from multiple of these scripts, cannot be registered. As TILDE OPERATOR is in none of the listed scripts, no label containing it can be registered with Verisign when IDNA leaves the testbed status in that zone.
For another example, please refer to DeNICs policies for the .de zone:
http://www.denic.de/de/richtlinien.html
In the section "Anlage", they list all characters supported. So you can only register labels with a few non-ASCII Latin characters, but no other scripts - let alone TILDE OPERATOR.
I don't see step #2.
If you're argument is "It won't work, because it doesn't", then I can't argue with that circular logic -- other than to say, I don't see any "valid" reason for its foundation.
No, that is not what I am arguing. I understood your proposal that you suggest a modification to Nameprep, i.e. to change the mapping. I'm saying that a change to Nameprep won't have any effect.
Please realize that you are correct in your claim *only* because the tilde (code point 07E) is prohibited in step 3.
Please realise that this is not the case. In step 1, step 2 is skipped if the character is in ASCII. So Nameprep is not even being invoked.
So, by design, the process prohibits the character, but it does so for no specific purpose that I am aware
The prohibition in step 3 is for backwards compatibility. Existing implementations are known to fail if confronted with a label that
contains the ASCII TILDE.
-- and that's my point -- and has remained my unanswered question. So, specifically why does the "process" (nameprep, rule #3, "plan 9 from outer space", or whatever) prohibit code point 07E?
Nameprep (RFC 1391) does not prohibit the character. Step 3 of ToASCII prohibits it for backwards compatibility, in order to protect the stability of the Domain Name System.
Also FYI, the character string "foo~" (where "~" is the TILDE OPERATOR) currently translates to xn--foo-ch2a, which can be registered as xn--foo-ch2a.com ("foo~.com). This domain is perfectly legal in both .com and .net TLD's -- in fact, it's currently open.
Did you try that? Even if it works, .com is still in testbed, and, according to the IANA rules, and the published Verisign policies, will not be allowed in production use.
If you just used some Web interface to find out whether it has not been registered yet, and could be, then you probably have used a Web interface which does not implement the Verisign policy correctly.
In summary, my claim is that if you can map uppercase "A" to lowercase "a", then you can map the TILDE to the TILDE OPERATOR.
Yes, but that would have no effect to IDNA, as I have explained. Even though Nameprep also maps "A" to "a", that mapping has no effect for a pure ASCII label. Nameprep simply does not affect pure ASCII labels.
So if you have a name such as MICROsoft.com, the protocol allows transmission of it as-is, and IDNA does not change that. Instead, RFC 1035 specifies (section 2.3.1) that this is treated the same way as, say, microsoft.com.
The point here is to save keyboard real estate if: a) there is no reason for it to be prohibited;
There is: allowing it would break compatibility with RFC 1035.
b) and if a simple mapping function (or whatever) can save a key without creating problems elsewhere; then why not?
A change to the mapping function would have no effect.
Please do read and understand the relevant internet standards first.
Regards, Martin
