tedd <[EMAIL PROTECTED]> wrote: > Nameprep, in prohibiting the code point, has neither avoided an > alternate representation nor erased a case distinction -- it just said > "No".
Nameprep does not prohibit tilde or any ASCII character. ASCII characters are prohibited in ToASCII step 3, only if UseSTD3ASCIIRules is set. What I said about Nameprep was "The mapping step in Nameprep was designed to avoid alternate representations of the same characters, and to erase case distinctions, not to save typing." The other steps of Nameprep are there for other reasons. For example, the prohibition step of Nameprep is there to avoid names containing characters that you can't see. I focused on the mapping step because you were proposing to add a mapping. I don't understand the distinction between "save keyboard real estate" and "save typing". Tilde operator is allowed by IDNA, it's just difficult to type (probably involves typing the Unicode number or selecting from a menu). Adding a mapping from tilde to tilde operator would make it easier to type because it would allow the use of existing keyboard real estate. But it would not be compatible with the way ASCII names have always been treated. > it appears arbitrary to me until someone provides me with a reason > otherwise. The original restriction on host name syntax *was* arbitrary, but it was made thirty years ago (RFC-608) and has been with us ever since. It was not IDNA's place to change the basic rules of ASCII host names after all this time. It's quite possible that in thirty years some software has been created that depends on the fact that ASCII host names don't contain tilde. > 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. I don't see how that follows. The equivalence between A and a, and the prohibition of tilde, were both established at the same time in the same document thirty years ago. AMC
