> Edmon... I think it means every "human readable" UI has to be downgrade not > upgrade... we should have something readable that converts to something > unreadable so that web-designer dont know what they are putting in as URL > : )
UTF-8 does not imply "human readable". It means it is encoded in UTF-8. Dont continue confuse folk display and encoding. But I agree that ACE is one form of "downgrading" but the target is for machine readability, not human. > > This is a revealing point you have pointed out Adam. While you and some > ACE > > "everywhere" advocates maintain that ACE "everywhere" requires the least > > upgrade, this seems to jump back out at yourselves that afterall, it is > not > > as small a job as it was advertised. In IETF, when face with two proposals, we do engineering trade-off. Therefore, no one actually say it is "a small a job". Most say IDNA is a easier task. > 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 : ) You point out the cruial pros & cons over the ACE vs UTF-8. The differ in opinion is the last part with you dont understand. My take? If it were up to me, why stick to UTF-8? I'll say lets do one single upgrade to 128bit, lets called it UTF-128, just in case. -James Seng
