[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] Fw: BOUNCE idn@ops.ietf.org: Non-member submission from ["tsenglm" <tsenglm@relay.csie.ncu.edu.tw>]



Approvws; root
From: "tsenglm" <tsenglm@relay.csie.ncu.edu.tw>
To: "\"IETF IDN WG\"" <idn@ops.ietf.org>
Subject:  Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
      (correction)
Date: Mon, 4 Feb 2002 09:07:40 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700

 Dear John:
                   I  read your note, we know it is SLT not the next
meeting
 in Minneapolis.
                   Actually,  we have similar concepts  about
multi-layer
architecture and external servers,  but  the client solution  of  some
company that using  the techniques of client domain name replacement and
appending  have been introduced the infringement  of  ML-TLD query.
Now,
the ASCII-IDN domain
are protected by case folding of nameprep mapping and  by the separation
of
basic codepoint part  of  Punycode encoding,  but most ML domain is not
.
               The ambiguity of  TC/SC cause it more serious and more
unpredictable to a user. The consideration of similar client solution to
reduce these ambiguity can not be avoid . Until now , there are little
design consideration of IDNA to protect ML-domain-name except the Kana
in
normalization . For other language characters, there are no explicit way
to
let local language related domain-name can be combined in this IDNA
approach
to reduce the ambiguity.  That is why many engineers of CNNIC/TWNIC
still to
find the client solution to reduce the ambiguity  of  TC/SC and to avoid
infringement from download module.
                  The RFC of IDN should be point out explicitly what
mapping
MUST  BE and what MUST  NOT BE.  To introduce more characters into DNS
is
not the correct reasons if  the stability and trusty  will be lost.

 L.M.Tseng
>
 > My apologies to everyone on this distribution whom I may have
> confused...
>
> I have been thinking about the upcoming IETF meeting in
> Minneapolis, and my note mentioned discussions in Minneapolis
> when I intended to say "Salt Lake City".  I don't know if this
> implies that I have lost track of where or when I am, but my
> apologies in any event.
>
>     john
>