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

From: [email-masked]
Date: Fri, 30 Nov 2001 17:40:03 EST

In a message dated 2001-11-30 13:43:35 Pacific Standard Time, 
[email-masked] writes:

> And Chinese TC/SC example:
> <wind> has four code points in Chinese:
> TC, SC, TC radical, SC radical.

This may work really nicely for cases like this, where there is exactly one 
TC character that maps 1-1 with an SC character.  But what about all the 
other cases where it's not 1-1?  And lots of people by now have stated that a 
partial solution is not desirable.

> If the "equivalent character set" is not a good term to group
> this codepoint normalization problem, I'd like to hear it. 
> No feed-back means agreeable  to the term.   

I doubt whether the rest of the working group will agree with a unilateral 
declaration such as that.

-Doug Ewell
 Fullerton, California

---

From: liana Ye <[email-masked]>
Date: Fri, 30 Nov 2001 16:48:27 -0600

I like the way you have summarized, and it is easier 
for me to address the real issue, and have a chance to 
post my thinking.

For the following issue in your post:

One way to look at the above is that the DNS just doesn't have
enough information available during matching.  The matching
algorithms don't have access to language information, country
information, or other things than could be used to sort out
similarities and variants.  And the DNS does exact matches -- no
ambiguities permitted.  If the needed information isn't there,
no matching tricks or "preparation" is going to help -- there is
no place in the DNS or either magic of "do what I mean"
capabilities either.

Discussion:
  The country information has been in TLD already, it can be 
addressed in Layer 3. 
  The language information is not coded in anyway except local
standard - that is the input processor.  
 The script information is implied by code blocks from UCS. 

There is no way to put country information back in DNS label.
There is a way to put language tag onto a label by using 
zh--china.com or mo--mongolian.com.  
There is a way to extract script imformation from UCS block #
by UCS codepoint itself.

Problems:
  Language infor is different from script infor.  Script infor can not
separate C,J,Ks with UCS codepoints, the only way to separate
them is stick with language infor and combine with codepoints 
to tell the difference. 

 For example, without input language information as UCS codepoints: 
  kana+CJK is Japanese, using Japanese rules;
  Hangul+CJK is Korean, using Korean rules;
  CJK only defaults to Chinese rules and subject to TC/SC equivalence
examination and label comparison. 

With input buffer protocol, the language infor. is easy and can be 
saved.  
 
If we are agree with this part, then I can continue.  Because this 
is the language tag I am proposing.  The tag can be saved as 
zh--china.com mo--mongolian.com to going into DNS for 
comparison.

I have something else to attend while I am doing this message, so
this did not get posted earlier.  I intend to discuss on your long 
post one point at a time. 

Liana

---

From: liana Ye <[email-masked]>
Date: Fri, 30 Nov 2001 18:35:27 -0600

On Fri, 30 Nov 2001 17:54:37 -0500 John C Klensin <[email-masked]>
writes:
> --On Friday, 30 November, 2001 13:21 -0600 liana Ye
> <[email-masked]> wrote:
> 
> > Thanks John for you are addressing what I am looking
> > for.   And I do think bottom up discussion hitting the 
> > wall after the introducing TC/SC, because it is a part of  the
> > CJK  problem that JET has been facing.   It is a good time to
> > look  at top-down wise.  And we will hit CJK problem
> > too as codepoint usage conflicts. 
> 
> But there is very little top-down where the DNS itself is
> concerned.  Despite upward-facing uses, it is fundamentally
> downward-facing, and that is, in different language, what the
> "identifier" discussion is all about. 
> 
> > So I think CJK code points usage conflicts should be 
> > resolved before this group can discuss solutions effectively.
> 
> I think that statement is equivalent to "the IDN WG should never
> finish its work, or at least should take years to do so". With
> the understanding that I don't read Han characters, I think
> there have been ample illustrations over the last several months
> that completely resolving "CJK code point(s) usage conflicts"
> will require that the Japanese and Korean languages be reformed,
> possibly to use a different character set base entirely.
>

That is the reason for me to ask "how different" the three 
languages are in using these codepoints?  Can we come up 
another way to look at these code points?  Since they have been 
through visual classificantion by Unicode Consortium already, 
should we pick another measure to look at them? 

Characters have four distincted espects: visual, phonetics, 
composition and semantics. The visual aspects of a character 
has been scrutinized by Unicode Consortium already.  The 
composition aspect of them is a subject for a long discussion
good enough for a book.

The common measure is along semantic similarity.  But how precise
can we classify them, synonyms like what is in a dictionary, used 
as keywords?  This is the layer 3 approach, it is may be effective
in free text, but as a structured domain names, different codepoints 
of a synonym set means different entities.  They can not be mixed 
or to reduce a search space needed as IDN identifiers.  

The next option along semantic classificantion is TC/SC
based codepoints, with demands from Chinese group.   To say 
they are the font difference is not the whole picture, but I have been
using it to STRESS they are "semantically equivalent" among 
Chinese, and serve a good purpose for internationization of 
domain names, and help to reduce trademark conflicts on the 
net.   I am trying to divide the problem up into separeted parts, 
for examination of the problem.   

1) Are these symbols semanticly equivalent among C,J,K?
2) If they are, we can do 

> > For example: 
> > One Latin case from [nameprep]:
> > 0048; 0068; Case map
> >...
> >...

3) If they are not equivalent, we should record their  
language context and handle them in a similar way 
with Bengali, Tibetan ...

I do not see what is so wrong with such a request to 
Unicode group.  Afterall the JET has been gone over 
this many times, can I have a look at what are these 
codepoints with an Acrobat Reader?

I don't feel like to get into more aspects of a character 
at this time, and raise more discussion points.  But since 
I have started the four aspects of a character, I will mention
the last aspect of a character is its phonetic attribute.  
If we can use it for character encoding, then we will have 
phonetic ACE at the end.

Liana

---

From: liana Ye <[email-masked]>
Date: Fri, 30 Nov 2001 18:42:56 -0600

On Fri, 30 Nov 2001 20:25:11 EST [email-masked] writes:
> In a message dated 2001-11-30 17:04:52 Pacific Standard Time, 
> Sorry, but I'm afraid that's not necessarily true either.  ".com", 
> ".net", 
> ".org" do not necessarily denote locations in the United States, nor 
> 
> locations that are intended to be accessed in English.  It is 
> entirely reasonable to expect people to want to register "<Han
character><Han 
> character><Han character>.com" and now our tagging scheme has fallen 
> apart.
> 
> -Doug Ewell
>  Fullerton, California

It is not fallen apart at all.  It is what I am arguing for.  
Here was my example:

zh-china/mo-mongolian/ja-japan.com  as the DNS ACE form,

with IDN form:
<HAN characters>/<mongolian characters>/<kana kana Kanji>.com

Liana