Re: [idn] URL encoding in html page

[Erik Nordmark <Erik.Nordmark@sun.com>]

<idn@ops.ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
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