[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
Dear Edmon & Erik:
Sorry , I jump into your discussion. But this is first time, I
feel there are some honest engineer want to dig the true problem and not
only announce it is a forbidden area.
----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
To: "Edmon" <edmon@neteka.com>
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>; "Patrik Fältström"
<paf@cisco.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>; "IETF-IDN"
<idn@ops.ietf.org>
Sent: Friday, January 25, 2002 8:54 PM
Subject: Re: [idn] Re: Optional & Additional Character Equivalence
Preparations by Zone
>
> > Multilingual names that have character equivalency issues will have to
> > opt-out of DNSSEC.
>
> That shounds like a non-starter.
> We need to figure out how to provide better Internationalization of
> IETF protocols and we need to make the Internet more secure.
> Forcing users to choose between either IDN or secure doesn't accomplish
> this.
>
In my personal experimental implementation test and analysis.
I can make sure current UTF-8 DNS can be modified to work as a ML-DNS with
character equivalency capability and all of them should to form a core
tree. If these server are work as core server without working as a cache
to non-character-equivalency DNS server, the problems of mis-cache-data and
authorized tree relation check can be avoid.
>
> > Erik, honestly, I dont have the exact "best" solution yet. My point is
that
> > there are "possibilities" and we should not rule the entire thing out
just
> > because it might be a bit difficult.
>
> I think we've talked about this on the list for two years. Lots of folks
> have said "I have an idea" and further exploration on the list or in I-Ds
> have determined that when taking the details into account the idea
> doesn't fit with the constraints imposed by the DNS and the applications.
>
> So the problem isn't that it is a bit difficult, but that it can't be made
> to work given the constraints.
> That doesn't make the problem less important - but it means that it
doesn't
> fit into the DNS. Hence the work on layer 2 where more context can be
> taking into account when searching for names.
>
A core ML-UTF8-DNS tree is another Layer 2 server with more
character equivalent capability than current edge UTF-8 DNS server. But this
approach will not follow the layer relation . Actually, more lower layer
should more capability of equivalence to form a common base . The current
IDNA nameprep do not follow this rule , so it will force LDH-DNS can not
be work as a server with more capability of character equivalence . Even
Puny code have support this feature based on ASCII case insensitive
comparision of LDH-DNS server.
> > I really want to stop talking about
> > this subject on this list, but it seems to me very irresponsible,
especially
> > considering that I am an implementor of this technology that I would
have to
> > tell my customers that:
> > A.example is NOT the same as A.example
> > How can I do that? Any normal person in this world would not accept
this,
> > yet I am creating a system that force them to accept that. I could step
> > back and say, "o well, buyers beware", but it just doesnt seem right.
Do
> > you think it is right?
>
> Isn't much different than MICROSOFT.COM and MICR0S0FT.COM (digit 0 vs. O).
> But I think the problem is important.
> But I've come to the conclusion that solving the problem either requires
> - replacing the DNS with something else that can do approximate matching,
or
> - building a system on top of the DNS.
If it is out of control , it is no different with TLD string be
append with an additional domain name in client .
As I know , If on top of current DNS is need , taking ML-DNS approach as
the layer2 server is more save than other server.
Best regards,
L.M.Tseng