Re: [idn] URL encoding in html page

[=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <tsenglm@cc.ncu.edu.tw>]

Dear Erik:
               Very interesting,  Your mail let my mail server to do a
specified mail-relay operation , Please see the following Cc:  messages.
But I found in the IDN mailing list , there are no relay assigned in the
mail header.
If there existed one technique to specified the relay path , then the UTF-8
domain name can work in this way !
               UTF-8 IDN have many compatible problems between client and
servers to identify the accepted name of server. The problems may happen in
ACE IDN when it is used in the identification of web/mail servers. Because
non-ASCII user will confused why the registered native coded-name can be
used as the name identification of the  servers .  That is why a replaced
corresponding ASCII URL of RealName will be work more easily.

L.M.Tseng
----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@sun.com>
To: "David Leung (Neteka Inc.)" <david@neteka.com>
Cc: "Edmon Chung" <edmon@neteka.com>;
<IETF.idn.working.group@dove.cc.ncu.edu.tw>
Sent: Saturday, March 30, 2002 4:22 PM
Subject: Re: [idn] URL encoding in html page


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