[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>]
- To: <idn@ops.ietf.org>
- Subject: [idn] Fw: BOUNCE idn@ops.ietf.org: Non-member submission from ["tsenglm" <tsenglm@relay.csie.ncu.edu.tw>]
- From: "James Seng/Personal" <jseng@pobox.org.sg>
- Date: Mon, 4 Feb 2002 09:58:36 +0800
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
>