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

[liana Ye <liana.ydisg@juno.com>]

Hi, John,

  Excuse me for not putting my draft-liana-idn-map-00
to your attention.  To answer your questions I have 
following comments.

> > 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.
> 
> 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.

Please read draft-liana-idn-map-00.txt Section 2.1.2.  
Each language has its own column of codepoints. 
While  A  maps  a  for Chinese, A can be mapped to a' 
for Japanese, and a'' in Korean. 

> 
> 	(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.
> 	
> 	(iii) No plan, at least none "on the desk", about how to
> 	deal with those other characters.

draft-liana-idn-map-00.txt has been available in 
IDN directory since Step. 12.  

> 	
> 	(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.
> 
> 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.

I agree with you that  
> special clients for Chinese-speaking people 

> tend to fragment the network and because client-based solutions
> are notoriously hard to maintain as one, 

This has been the experience with many client servers
in CJK areas already.  Even among CJK only, it is hard 
to do so.  It is best to remain in IEFT.

> (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.
> 

Prof. Tseng has given another good explanation.  To me,
the key is moving IDN identifiers through minimum layers.
 

> (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

Draft-liana-idn-map-00.txt has described an IDNA equivalent 
interface to applications, but much earlier than IDNA described 
toASCII and toUnicode terms. 

Draft-liana-idn-map-00.txt has defined script and script-mix 
independent normalization interface within the structure, 
while IDNA trying to stay away from it.

Draft-liana-idn-map-00.txt has described solution to CJK 
problems, satisfys both TC/SC and Kanji, Hanja for 
independent interpretations,  which is the problem 
you are trying to put in layer two without even a clear 
picture how to deal with them, which is also this WG is 
trying to scope out of  this list at this moment. 

So, James:

I have been discussed in the last several months:
1)  from details of programming of a string  anaysis
   to codepoint flow in a system control;
2)  from UCS codepoint as an IDN identifier to what a 
   character real is about;   
3) from one script to scripts implied in UCS table
   to user requirements of using them;
4) from one codepoint flow from the user to IDN to
  DNS and back to IDN to web page to system analysis
5) from one codepoint in CJK leads to trademark 
 disbute concerned by WIPO;
6) from Armenian "n" mixed use with Latin "n" to 
 illustrate the CJK problem, to imply blanket treatment
 of UCS codepoint is dangerous; 
is just the fool jumps in, while DNS experts laughing 
in sleeves.

My discussion of expert linguists views on written
 languages in the world, 
My promotion on phonetic codepoint encoding for the 
 users and facilitating globle communication, 
My request for Unicode experts' help on codepoints 
 issues, 
My linguistic experiences shared on this list,
 are all multilingual and distructive to 
Internationalized Domain Names efforts, and belongs
to the "Tangled Web". 

I have been stupidly enough to believe that 
when I said "CJK has to be treated in a data-centric 
programming fashion" will help to communicate 
why TC/SC has to be in with [nameprep].  All of 
these are language related and so are out of the scope 
of this group.  Thanks, Chair, and the Sacred group!

Regards,

Liana