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
