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

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

       Thanks for your comment ,  I  try to give some explanation  in
the
following.
----- Original Message -----
From: "Adam M. Costello" <amc@cs.berkeley.edu>
To: <idn@ops.ietf.org>
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