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

From: "tsenglm" <[email-masked]>
Date: Sat, 14 Jul 2001 02:43:34 -0700

Thanks for your comment ,  I  try to give some explanation  in
the
following.
----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 14, 2001 4:57 AM
Subject: Re: [idn] draft about <draft-ietf-idn-uname-01.txt>

> It is already permissible (I think) for DNS servers to perform more
> complex matching than the usual case-insensitive ASCII matching.  For
> example, a DNS server implementation could support master file entries
> whose keys are regular expressions, and it could compare incoming
> requests to those patterns.  For example, it could allow:
>
> foo-?(two|2)   A   1.2.3.4
>
> to be used as shorthand for:
>
> foo2      A   1.2.3.4
> footwo    A   1.2.3.4
> foo-2     A   1.2.3.4
> foo-two   A   1.2.3.4
      This is a very good representation for  OR operation on some set
of
equivalence meanning words(characters).
But it can be solved in nameprep by character normalization ,  because
CJK
character is  UCS-2 in 2 byte
form , so it is a  case of  normalization  to a set of  equivalent
byte-length characters. The  1-1 mapping  of equivalence meanning  words
is
the simplest case.  Uname draft treat another case of  chinese
character(words),
especially in  one to many(include none) & many to one mapping  ,  The
meanning is equivalent or not  is highly dependent on the context
sequence ,
these are not the case of  1-1 mapping & equivalence .
      To simplify the SC/TC  translation ,  one to many(include none)
mapping are  freely selected  one by register in registratin stage ,  so
they need a record to guide the resoving of  partial-different
character-string-name map to only one unique identifier .
>
> Similarly, if a DNS server implementation wants to perform
> simplified/traditional Chinese matching, or matching of names encoded
> in alternate charsets, isn't it already allowed to do so?  Is there
any
> need to standardize this?
>
> Note that using such a feature will cause problems at higher layers,
> because clients won't know the matching rules.  For example, if I
> follow a link to www.foo2.net, and later follow a different link to
> www.foo-two.net, the link will not be colored as visited.  If I tell
> my browser to accept cookies from foo2.net, it won't know to also
> accept cookies from foo-two.net.  Same problem with SSL certificates.
          You just describe the problem why  the authorized unique-root
based ML-DNS server is needed . 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.
> Therefore it would probably be desirable to deal with extended
matching
> not only in the DNS server but also at higher layers.  In these
> examples, one might want the HTTP server to redirect requests from the
> alternate server names to a single preferred server name.
>
> AMC
>
         The  TC/SC translation automatically occurs in  browser and
mail
agent,  but they translate it based on  ISO-10646 code font ,  A  TC
viewer
may get many ???  reading in SC content especially in receiver , subject
and
URL input field of  browser.  It is not just for not displayable ,  the
information in these field for identification is lost in cross TC/SC
visiting  or  mail reply ,  So a  mapping record is needed to help
mailing
system and browser to prevent the confusing in critical Domain Name
field is
very important.

Li-Ming Tseng

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 14 Jul 2001 21:42:22 +0000

tsenglm <[email-masked]> 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.

AMC

---

From: "tsenglm" <[email-masked]>
Date: Sat, 14 Jul 2001 18:34:08 -0700

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 15, 2001 5:42 AM
Subject: Re: [idn] draft about <draft-ietf-idn-uname-01.txt>

> 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