<[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: [EMAIL PROTECTED] Precedence: bulk
> ACE will work with "EXISTING" systems but ALL client end(browser, MUA, etc) > and SOME server(Apache, etc) end software actually needs to upgrade in order > to be able to recognize IDN and convert it to ACE back and forth, unless we > want to say that www.ietf.org that we are using nowadays is IDN already : ) > > On the other hand, we see a lot of applications is moving towards the > support of UTF8/Unicode on the client side, and this is going to be the > future anyways... so why not just upgrade the server software, with one > server software upgraded it will serve many many users... I dont understand > why no one see this simple math : ) David, You seem to be assuming that there would be only two entities involved in the application protocol between the endpoints. The world isn't that simple. As an example, the mail I'm responding to contained 8 Received lines when I got it. Thus, assuming the return path have the same number of SMTP hops, if you had nameprepped-UTF-8 in your domain name in the from: line, if any of those 8 relays didn't handle UTF-8 properly, this mail would not have reached you. Thus it isn't just a question of upgrading two pieces of software. Likewise for http. Upgrading my browser wouldn't do much good when there are 2 caching proxies plus a socks host inside sun that look at the http headers, and some number of load balancers (global and local), ssl proxies, and akamai caches, that sit in front of many web servers. Dealing with this type of reality is part of the challenge in the transition to a scheme which uses nameprepped-UTF-8 in application protocols. Erik
