Re: [idn] URL encoding in html page

["James Seng/Personal" <jseng@pobox.org.sg>]

> 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