>From: Patrik F�ltstr�m <[EMAIL PROTECTED]>
> >>> - Encoding into ACE must use Punycode WITH case marking so that >>> case can be restored when using ToUnicode. >>> >>> ToUnicode is fine, but decoding Punycode must restore case. >> >> I have already argued for mixed-case support as best I can. I couldn't >> quite get it *mentioned* in the IDNA and Nameprep documents. You don't >> have a prayer of getting it *required*. > >The problem is that the definition of "case" is very hard to make. And, if >you preserve case, why not preserve other steps of nameprep? Because Punycode have been selected and it only supports case preservation. If I remember correctely it is less than 1000 letters in UCS that has case, so the support is fairely simple to handle. It is also what RFC 1035 says: case should be preserved if possible. It is also good to have as long as some systems require e-mail addresses to be case sensitive and we have to handle those in DNS. > >Remember, nameprep is done before punycode, so when the string is passed to >the punycode (transport) encoding, the original string is lost. > That depends on implementation. In much software it would probably be best to combine "nameprep" with encoding to ACE. The order things are described in the document does not have to be followed as long as the result is the same. Changing order might make things much more efficient. For example the definition on what characters are forbidden I would have as an application matter while the rest could be done by a common routine for all software. Dan
