Re: [idn] URL encoding in html page

["David Leung \(Neteka Inc.\)" <david@neteka.com>]

> > 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.

There are more than 2 entities involves in all protocol, but as you see in
my other mail that i posted, my thought is, for example(in mail header) the
FROM: will have ACE and have new header say X-UTF8FROM: to have UTF8, so
when all those clients and servers that use the protocol are ready to handle
the new commands or headers, the transition will be seemless... and old
software that doesnt support these new commands and headers and/or syntax
will simply just ignore them, and the everything just appears as the same as
today, is this thinking got anything wrong?

> 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.

Same as what i said above for SMTP, these entities use HTTP, so maybe for
HTTP we can add a new header to have IDNHOST as the UTF8 host and keep the
HOST line to have the ACE, so what's wrong again with this, and when doing
the initial HTTP session it will denotes the version as well, so when during
the process, no matter how many entites the request has been passed thru,
any compatible "new entities"(no matter client or server softwares), it will
maintain the new added command/header/syntax and for any entity thru out the
path that is not capable would be fallback automatically by the capable
entity into the ACE format again...

> 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.

Since i am facing the reality that "WE" should look for a solution that can
fallback and also step forward(expandable), and not limit ourselves to a
solution that only fallbacks.