Re: Layer 2 and "idn identities" (was: Re: [idn] what arethe IDN identifiers?)

["xiang deng" <deng@cnnic.net.cn>]

On Wednesday, December 05, 2001 12:14 AM, John C Klensin wrote:

> --On Monday, 03 December, 2001 15:46 +0800 xiang deng
> <deng@cnnic.net.cn> wrote:
> 
> > Correct except SC/TC conversion. There is solution on the desk,
> > so it isn't  possible, it's existence.
> 
> I'm unconvinced this is true.  Please convince me.

Mainly, there are four drafts which relate with this subject:
(1) draft-ietf-idn-tsconv-03.txt (HSE->Nameprep->Validation->AMCZ)
(2) draft-ietf-idn-tsconv-02.txt (Nameprep->HSE->AMCZ extension)
(3) draft-mealling-sls-01.txt  (Lay2->IDNA)
(4) draft-ietf-idn-lsb-ace-02.txt (Nameprep->Reordering->AMCZ)
If there is something wrong,  authors correct me please.

> What I think we have is:
> 
> (i) A partial solution on the desk, one that deals with
> the 1-1 cases that do not have overlap with Korean or
> Japanese.
>
> (ii) General agreement that, however many characters (i)
> covers, some Han characters, or even Han characters for
> which simplified forms (or traditional forms) exist, are
> not covered.

If you agree the two basic information I had mentioned.
So we have met the whole current Chinese character reform.
 
> (iii) No plan, at least none "on the desk", about how to
> deal with those other characters.
>
> (iv) Fairly general agreement that at least some of the
> problem must be dealt with at a different sublayer or, at
> least, in some non-DNS mechanism.

Not precision, About 200-300 Han characters are belong to 
1:n ,n:1,1:(n+1),(n+1):1  and so on. 
On Tang dynasty(A.D. 618-907), Chinese Traditional Character
spreads to Korea, Japan and other areas. For being widely used and
long distance and long history,  the meaning and form of Some TCs
begin change. One TC might have several forms, slowly and slowly,
the different forms have different connotation. So these TCs relate with
context.

For technical viewpoint, if we want to do something about it, we need 
artificial intelligence technic. If not, what we can do is very limited.
 
So if adding these information, Could you reconsider what
your conclusions ?

> It seems to me that, given the above, there are several possible
> paths forward, e.g.,
> 
> (1) Decide this is a client problem, to be used in special
> clients for Chinese-speaking people.   I would personally
> recommend again such a solution, both because I think it will
> tend to fragment the network and because client-based solutions
> are notoriously hard to maintain as one, e.g., figures out ways
> to deal with additional characters.   But, independent of that
> preference/ advice, the details of what one does in client
> software, especially client software that is not expected to be
> universal, is not an IETF problem and hence should be discussed
> somewhere other than on this list.
> 
> (2) Conclude that TC-SC matching is a sublayer 2 problem.  If so,
> please move this discussion to the IRNSS list and, as specified
> there, either recast it in the terminology of the "DNS Seearch"
> document or explain why the model of that document is
> inappropriate.
> 
> (3) Conclude that TS-SC matching is a sublayer 2 problem but that
> some machinery, beyond IDNA (with more or less the existing
> nameprep), needs to be put into the DNS sublayer to support it.
> If this is the case, we need better discussion of what additional
> machinery is needed and why on this list.  And, unless there is a
> flaw in the reasoning above, or a significant case not
> considered, the rest of the TC-SC discussion should still go
> elsewhere.
> 
>    john