Re: [idn] draft about <draft-ietf-idn-uname-01.txt>

["tsenglm" <tsenglm@cc.ncu.edu.tw>]

----- Original Message -----
From: "Adam M. Costello" <amc@cs.berkeley.edu>
To: <idn@ops.ietf.org>
Sent: Sunday, July 15, 2001 5:42 AM
Subject: Re: [idn] draft about <draft-ietf-idn-uname-01.txt>


> tsenglm <tsenglm@cc.ncu.edu.tw> wrote:
>
> > Based on the DNS tree server, www.foo2.net www.foo-two.net will
> > be "replaced " by the same ACE unique-name/identifier in resoving
> > processing if they are mapped to the same ACE identifier.
>
> You mean replaced in the application layer, so that, for example, the
> browser knows that foo2.net and foo-two.net are the same?  For that to
> happen, the resolver interface must be changed.  Right now, even if
> foo.com and bar.com are both CNAME records for webhost.com, the
browser
> will not treat foo.com and bar.com as the same, which is good, because
> webhost.com is probably using virtual hosting, so that foo.com and
> bar.com really are logically separate sites.  If you want foo2.com and
> foo-two.com to be considered the same by the browser, you need some
> other relationship connecting them, not the alias (CNAME)
relationship.
> Even if you introduce a new resource record type (UNAME), the existing
> resolver interface has no way of expressing any connection between
> names other than the alias relationship, so you'd need a new resolver
> interface.  Or you could inform the browser of the name equivalence at
a
> higher layer, for example using HTTP redirects.
            IDN Name "replaced" by the idenetifier  is a necessary
effort
for backward compatibility.  For  cross visiting  of  different TC/SC
nodes,  the ACE identifier "replacement" can be used to help them
without
confusing in TC/SC translation.  DNS  UNAME records  are used to
indicate
that these IDN names are mapped to the same identifier .  How the
Application software (for ex. the browser) can kown it ?  There are many
different ways to implement it:
            1. The IDN-aware AP can recognize and do the right
interpretation.
            2. A pre-processing module between user input module and
Application . This preprocessing module query ML-DNS  with IDN and put
correct ACE identifier to IDN-unaware-AP. For forward compatibility, an
gateway to treat ACE identifier for  IDN-only  node may be required.
            3. A  browser user interface that uses HTTP protocol to
query
ML-DNS with  IDN and native-lang tag as parameter ,  the user interface
can
start up any  AP and put it with  correct  unique-name/identifier.

>
> AMC
>
            Thanks your comment, You get  all points.
            More precisely,  we treat the same meaning of characters as
one
way mapping to the same identifier.
The reverse mapping may be true or false in reverse way, so I do not
call
them  equivalence.

Li-Ming Tseng