Eric wrote:
>> ACE is suitable for backward compatibility, if used in the IDNA way. >> But is bad to restrict current or future needs just because of limits >> in a backwards compatible solution is bad. If ACE gives limits, one >> more reason to also have a solution that can handle more. > >There are multiple secondary ramifications from this approach. For >example, this requires that normalization occur before lowercasing. This >also requires that case conversion be removed from nameprep and moved to >the ACE encoding reference specifically. Everything depends on what nameprep is. The reason I have wanted us to separate out things in different drafts is because they need not be together. ACE is only how to encode non-ASCII into ASCII. It does not require things to be lower case. And what is nameprep? Of what I have seen nameprep is how to convert names into a format that is needed to make IDNA work for ACE encoded names. I have always worked for a wide base plattform to build on. IDNA by forcing us to use a binary comparabel label is removing some of the basics of DNS today. IDNA/ACE as a pure backward compatibility would be fine, those seeing ACE would never use anything else. IDNA/ACE as the base for non-ASCII in DNS does put restrictions where there isn't any in DNS now (like case-insensitivity). I do not want to remove nice features of DNS just because some people do not want to upgrade their DNS servers (and those people will never get DNSSEC or other new features). It is fine for those who want, to start with IDNA/ACE, but I do not want that to make it impossible for us who want to go for the DNS server solution to get the full benefits of that solution. Everybody have to accept to spend some CPU power when moving past ASCII. Dan
