Dan Oscarsson 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. Comparison costs go up as well. An ACE-encoded name has to be decoded, and then compared in case-neutral form against the canonical UCS characters. Case-neutral comparison in ASCII is easy because there is only one bit difference between upper and lowercase forms, but for non-ASCII it is somewhat more expensive. This process may also introduce problems with caches and/or resolvers, where the same domain name can exist in multiple forms (normalized uppercase versus normalized lowercase). And of course it also means that a hostname which is case-specific will be neutered whenever ACE is used to encode that hostname, and this breaks case-sensitive applications. These are pretty high costs. It would be much more efficient and much simpler for implementations if the lowercase form were always used, regardless of the encoding. I think that we have both stated our position on this matter. I agree with you that it would be nice if we could have mixed case, but I think it will be too expensive. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
