Re: [idn] opting out of SC/TC equivalence

[Patrik Fältström <paf@cisco.com>]

--On 2001-09-01 13.26 +0800 "tsenglm@????.??.tw" <tsenglm@cc.ncu.edu.tw>
wrote:

>           By this principle,  why partial set of CJK characters that are
> partial setted by local language tag can be used with different TLD
> (cn,jp,tw..). Because the TLD implied the language tag and will let them
> differentiable from other TLD .

You have to be more precise.

(A) In DNS, we can only use one character set. One only. We have picked
Unicode.

(B) In DNS, the matching algorithm have to be the same in every piece of
software which uses the DNS. It can NOT differ between different languages
used by the client. It can NOT differ between different domains. It can NOT
differ between geographical regions. The matching algorithm we have is
nameprep.

(C) A TLD CAN have a policy which says that only a subset of the characters
allowed according to (A) is allowed.


You don't specify when you say "TLD" and "language tag" above whether you
imply a restriction according to (C) (which is ok) or if you have a
requirement which is a vilation to (B), or if you have a violation to (A).

Be more specific.

The proposals I have seen maybe look nice from a functional standpoint, but
they all have completely ignored the technical constraints the DNS system
has. If some of you which oppse the use of one character set and nameprep
came up with a solution which makes sense technically, we could talk.

In this mail, you once again show that you completely have missed the point
of the comments from the other members of this working group.

You have to differ between comments on flaws in the technical solution
proposed and flaws in the functional specification you present.

>  The problems com from these contraints:
>           1. Big table of UNICODE let domain name can be mixing registed
> but viewed in part now.

Yes.

>           2. Many duplicate, easy-to-confuse and
> un-normalied/non-canonicalied scripts in UNICODE.

Correct. And your problem is? There is a reason why not more normalization
has been done in Unicode. UTC and ISO has been working for years on this
problem. Why do you think that IETF is better on doing the work than ISO
and UTC?

>           3. No one can change the coding at one night , you can only
> transit step by step.

That is why we propose the ACE encoding.

>           4. ML.com try to use all code point withou considering the
> troubles come from mixing.

If you use all code points without mixing them, what is the problem? The
problem comes when you try to mix characters from different scripts. The
problem comes when you try to normalize between characters in different
scripts. This is why UTC and ISO has not done more normalization. It is
also explained in the Unicode Standard 3.0 if I don't remember wrong. Yes,
on page 961 and 962 in the Unicode Standard 3.0.

What you and Liana are doing is claiming that the work the last 20 years,
the cooperation between all countries which use CJK characters in ISO is
wrong, and that IETF should do the job instead.

I think you should be VERY careful in your statements when you say that the
work in ISO has flaws.

This discussion has for me been a completely vaste of time, and I will
really think twice before I respond to another message in this thread.

I will not respond if not _constructive_ proposals which do work given the
technical constraints we have in DNS.

Just waving with hands doesn't work.

      paf